[쿠버네티스] 1. 컨테이너 기술 보급과 쿠버네티스

1.1 컨테이너란?

일반적인 가상머신은 호스트 OS에 하이퍼바이저(Hypervisor)를 설치하고 그 위에 게스트 OS를 동작시키는 형태로 동작한다.

컨테이너 기술은 호스트 OS에 컨테이너 런타임을 올리고 그 위에 프로그세스로서 컨테이너를 동작시킨다.

컨테이너란 호스트 OS의 커널을 공유하면서 분리된 프로세스로서 실행해 마치 가상머신이 움직이고 있는 것 처럼 보이게 하는 기술이다. 컨테이너의 실체는 단순한 프로세스이므로 가상 머신에 비해 매우 가볍고 빠르게 동작할 수 있다.

💡 컨테이너들은 호스트 OS의 커널을 공유하기 때문에, 가상머신과 달리 동립적인 운영체제를 가질 수 없다.

 

1.2 도커란?

1.2.1 도커의 특징과 장점

도커(Docker)는 컨테이너를 동작시키기 위한 엔진중 하나다. 도커의 가장 큰 특징 및 장점은 두 가지이다.

1. 컨테이너 관리 방식또, 컨테이너 이미지에는 애플리케이션과 그 실행 환경 설정이 포함되어 있기 때문에 도커 엔진만 설치되어 있다면 그 애플리케이션의 동작이 보장된다는 장점이 있다.
2. 도커에서는 Dockerfile이라는 정의 파일을 작성하여 동일한 컨테이너 이미지를 간단하게 만들 수 있다. 이는 IaC(Inflastructure as Code)를 구현하는데 매우 적합한 소프트웨어이다.
3. 컨테이너 이미지를 저장, 공유하기 위한 에코시스템즉, 개발 환경에서 스테이징 환경, 서비스 환셩으로 동일한 컨테이너 이미지를 배포할 수 있으므로 테스트를 거친 이미지를 서비스 환경에 안정적으로 배포할 수 있다.
4. 도커 허브(Docker Hub)라고 하는, 컨테이너 이미지를 저장 및 공유할 수 있는 컨테이너 리포지토리에 컨테이너 이미지를 전송하거나 다운로드 할 수 있다. 이를 통해 애플리케이션을 배포할 때 환경 설정 차이로 인해 발생하기 쉬운 문제를 해결할 수 있다.

 

1.2.2 도커의 과제와 오케스트레이션 도구의 필요성

시스템의 구성이 커지면 컨테이너 여러 개를 연결해 서비스를 만들게 된다. 이 구성일 때, 컨테이너 사이의 통신가 가용성이 보장되어야 하는데 이를 위해 오케이스트레이션 도구가 필요하다.

 

1.3 쿠버네티스란?

1.3.1 쿠버네티스의 개념

쿠버네티스에서는 데이터 플레인이라고 불리는 서버를 여러 대 실행시켜 그 위에 가상 오케스트레이션 계층을 구축하고 거기에서 컨테이너가 동작한다.

컨테이너 이용자는 이를 통해 컨테이너 그룹을 큰 머신 리소스로 볼 수 있어 인프라를 추상화 할 수 있다.

또한 쿠버네티스는 어떤 가상 머신에서 어느 정도의 컨테이너를 동작시킬지를 관리하거나, 새로운 컨테이너를 배포할 때 어떤 가상 머신에 배포하면 좋을지 등을 자동으로 판단한다.

이러한 기능은 컨트롤 플레인이라는 마스터 노드 그룹에서 구현된다.

 

1.3.2 쿠버네티스의 기본 오브젝트

쿠버네티스의 기본 오브젝트는 크게 네 가지가 있다.

1. 파드
   • 파드 하나 안에서는 하나 이상의 컨테이너를 동작시킬 수 있다. 파드에는 어떤 컨테이너 이미지를 사용할지 등을 설정한다.
   • 쿠버네티스의 최소 단위
2. 레플리카셋
   • 파드를 얼마나 동작시킬지 관리하는 오브젝트
   • 레플리카셋에서 파드의 수를 설정하면 그만큼의 파드가 동작하는 것을 보장한다.
3. 디플로이먼트
   • 배포 이력을 관리
   • 쿠버네티스 운영 중에는 애플리케이션의 새로운 버전을 릴리스(무중단 배포)하거나 부하 증가에 따라 레플리카셋 수를 변경하는 등의 여러 가지 동작이 발생하는데 이들을 디플로이먼트로 관리할 수 있다.서비스를 운영하느 상환 대부분에서 파드를 동작시킬 때는 디플로이먼트 단위로 관리한다.
   • 또한, 적용 이력을 관리하므로 문제 발생시 이전 버전으로 쉽게 롤백할 수 있다.
4. 서비스
   • 배포한 파드를 쿠버네티스 클러스터 외부에 공개하기 위한 구조 제공
   • 여러 방법 중 대표적인 방법으로 로드밸런스가 있다. 클러스터 내에 파드 여러 개를 동작시킨 경우 그 앞단에 로드밸러서를 배치하여 특정 클러스터 외부로 공개할 수 있다.

 

1.4 Amazon EKS란?

1.4.1 EKS는 무엇을 해결하는가

Amazon EKS(Elastic Kubernetes Service)는 쿠버네티스를 제어하는 컨트롤 플레인을 제공하는 관리형 서비스다. 쿠버네티스 도입을 검토할 때 가장 큰 장벽이 컨트롤 플레인의 유지 및 운영이다. 여러 컴포넌트들이 서로 독립적이고 비동기로 동작하며 전체를 구성한다. 그래서 각각의 구성요소를 정상적으로 동작시키기 위한 설정이나 유지, 운영 장애가 발생했을 때의 복구 방법은 결코 간단하지 않다. EKS는 이런 유지, 운영을 AWS에서 대신해준다.

💡 즉, EKS는 컨트롤 플레인의 역할을 한다.

 

1.4.2 EKS의 특징

EKS는 쿠버네티스와 완전한 호환성을 가지고 있다. 이미 구축된 쿠버네티스 클러스터에서 동작하는 애플리케이션을 수정하지 않고 동작시킬 수도 있다.

또한, AWS의 각종 서비스와 통합되고 있어 AWS의 다른 서비스들과 연결하거나 기존 구조와 같은 환경으로 이용할 수 있다.

 

1.4.2.1 VPC와 통합 일반적으로 쿠버네티스 클러스에서는 파드 네트워크로 데이터 플레인의 네트워크와는 다른 자체 네트워크를 배치한다. 그래서 클러스터 외부에서 파드에 명시적으로 엔드포인트를 생성하지 않으면 통신이 불가능하다.

EKS에서는 Amazon VPC(Amazon Virtual Private Cloud) 통합 네트워크를 지원하고 있어 파드에서 VPC 내부 주소 대역을 사용할 수 있고, 클러스터 외부와의 통신을 심리스(Seamless)하게 구현할 수 있다.

💡 심리스 : 서브스 접근을 단수하게 하는것 혹은 복잡한 기술이나 기능을 설명하지 않아도 서비스 기능을 직관적으로 구현하는 것

 

1.4.2.2 IAM을 통한 인증과 인가

쿠버네티스 클러스터는 kubectl이라는 명령줄 도구를 사용하여 조작한다. 이때 해당 조작이 허가된 사용자에 의한 것임을 올바르게 인증해야 한다. 또 인증된 사용자에게 어떤 조작을 허가할지에 대한 인가 구주도 필요하다.

EKS는 AWS의 IAM(Identity And Access Management)과 연결한 인증 및 인가 구조를 제공한다.

 

1.4.2.3 ELB와의 연계

쿠버네티스 클러스터 외부에서 접속할 때는 서비스(1.3.2 참고)를 사용해 엔드포인트를 생성해야 한다. 가장 대표적엔드포인트가 로드벨런서다.

EKS에서는 쿠버네티스의 서비스 타입 중 하나인 LoadBalancer를 설정하면 자동적으로 AWS의 로드밸런서 서비스인 ELB(Elastic Load Balancing)가 생성된다. 이것으로 HTTPS나 경로 기반 라우팅 등의 L7 로드밸런서 기능을 AWS 서비스로 구현할 수 있다.

 

1.4.2.4 데이터 플레인 선택

쿠버네티스는 컨트롤 플레인과 데이터 플레인으로 구성된다. 컨트롤 플레인은 EKS에서 관리형 서비스로 제공된다. 그러면 데이터 플레인은 어떨까? 사용자가 관리해야하는 것일까? 반은 Yes고 반은 No다.

초창기의 EKS는 AWS가 자동화된 구축 방식으로 데이터 플레인들 제공했고, EKS와는 별도로 EC2(데이터 플레인)를 관리해야 했다. 그러나 시간이 지나면서 데이터 플레인 관리를 도와주는 기능이 추가되었다.

EKS 클러스터의 유지 관리나 버전 업그레이드할 때 필요한 가상 머신 설정을 쉽게 해주는 관리형 노드 그룹 구조와 처음부터 가상 머신을 의식하지 않고 파드를 배포할 수 있는 파게이트(Fargate)라는 서비스가 여기에 속한다.

💡 파게이트는 데이터 플레인 관리가 필요없는 만큼 파드가 배포되는 호스트에 사용자 접근도 제한되며 거기에 따른 제약이 있다. (4.7.4 참고)

💡 파게이트를 사용하면 노드와 파드는 1:1로 매핑된다.