4 min to read
Kubernetes? #1 / TIL
Kubernetes?
Kubernetes
오픈 소스로 만들어진 컨테이너 *오케스트레이션 도구로, 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공한다. 쿠버네티스는 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응이 가능하다.
아키텍처의 트렌드가 모놀리식에서 마이크로서비스로 바뀌고, 이로 인해 컨테이너 개수가 증가하고, 여기에 확장성을 고려해 스케일링까지 더할 경우 수십, 수백개의 컨테이너가 생길 수 있다. 컨테이너 오케스트레이션 도구는 수많은 컨테이너를 관리하고자 할 때, 보다 더 잘 관리하기 위한 툴이다.
쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성하고, 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성하기도 하며, 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 * 마이그레이션 한다. (이식성) 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원한다. 예) AWS EKS
쿠버네티스는 사용하지 말아야 할 경우가 존재한다.
- 여러 Tier(단계)로 나뉘지 않은 모놀리식 아키텍처에는 적합하지 않다. 모놀리식 아키텍처는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선이다.
- 적은 양의 컨테이너를 다룰 때에 적합하지 않다. (docker-compose로 충분히 관리할 수 있다.)
- 비교적 단순한 아키텍처에 스케일링이 필요한 경우, 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공된다.
Kubernetes 작동 원리
위 사진은 쿠버네티스 아키텍처의 모습이다.
- Cluster : 최소 하나 이상의 제어판(Control Plane) 컴포넌트와, 이것과 연결된 몇 개의 워커 노드로 구성되어 있다.
- Control Plane : 관리를 위해 필요한 프로세스들이 있으며, 클러스터가 잘 작동할 수 있게 돕는다.
- Worker Node : 한 개 이상의 컨테이너가 자리잡고 있으며, 애플리케이션이 실행되고 있는 곳이다. 워커노드는 kubelet이라는 프로세스가 돌아가고 있고, 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 한다.
- Pod : 컨테이너 그룹과 컨테이너가 사용하는 볼륨, 컨테이너의 작동 정보
제어판 컴포넌트 프로세스
Kube-APIServer
모든 클러스터 관리의 입구로서, 명령을 내릴 수 있는 관문이다. 실제로 쿠버네티스에서 제공되는 UI나 CLI 등에서 클러스터 관리를 위해 뭔가 명령을 내리면 API가 호출된다. 직접 호출도 가능하다.
Kube-Controller-Manager
클러스터에서 무슨 일이 발생하는지를 추적하는 역할을 한다. 컨테이너가 죽거나 재시작되었을 경우, 컨트롤러 매니저는 이를 알 수 있다.
Kube-Scheduler
서버(노드) 리소스를 바탕으로 컨테이너(pod)가 노드에 배치되게 만드는 역할을 담당한다. 새로 생성된 컨테이너를 찾아 노드에 할당한다.
Key-Value 저장소 ETCD
클러스터 관리에 필요한 모든 데이터를 저장하는 공간이다. 인프라를 원하는 상태로 만들기 위해서는, 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터가 어딘가에 저장되어야 하는데, ETCD가 이를 담당한다.
Question
Q1. Deployment가 지원하는 배포 전략에서 블루/그린이나 카나리는 찾아볼 수 없다. 어떻게 블루/그린이나 카나리 배포를 할 수 있을까?
A1.
블루/그린 또는 카나리아 배포 전략에 대한 기본 제공 지원이 없지만 다른 Kubernetes 리소스 및 기술을 사용하여 이러한 배포 패턴을 달성할 수 있다.
블루/그린 배포
- 애플리케이션의 블루, 그린 두 개 버전의 배포 리소스를 만든다.
- 서비스 또는 Ingress를 사용하여 애플리케이션을 외부 트래픽에 노출한다.
- 처음에는 모든 트래픽을 애플리케이션의 블루 버전으로 보내고, 그린 버전이 준비되면 서비스 또는 Ingress를 업데이트하여 트래픽을 그린 버전으로 리디렉션한다.
- 그린 버전에서 애플리케이션의 동작을 모니터링하고 문제가 발생하면 서비스 또는 Ingress를 다시 업데이트하여 블루 버전으로 빠르게 전환할 수 있다.
카나리 배포
- 응용 프로그램의 최신 버전을 나타내는 카나리 릴리스에 대한 새 배포 리소스를 만든다.
- 서비스 또는 Ingress를 사용하여 기존 안정 버전과 카나리 버전 간에 트래픽을 분할한다.
- 카나리 버전으로 라우팅되는 트래픽의 비율을 점진적으로 늘린다.
- 카나리 릴리스의 성능과 동작을 모니터링하고, 카나리 버전이 성공하면 트래픽 비율을 계속 높인다.
- 문제가 발생하면 카나리 배포를 축소하거나 안정적인 버전으로 되돌린다.
블루/그린 및 카나리 배포를 용이하게 하기 위해 서비스, 수신 및 추가 Kubernetes 리소스를 사용하여 특정 요구 사항에 따라 트래픽 라우팅, 로드 밸런싱 및 확장을 관리할 수 있다.
Kubernetes에서 블루/그린 및 카나리 배포를 위한 고급 배포 전략 및 자동화를 제공하는 타사 도구 및 플랫폼도 사용할 수 있다. 이러한 도구는 프로세스를 단순화하고 자동 롤백, 고급 트래픽 분할 및 모니터링 기능과 같은 추가 기능을 제공한다.
Q2. 서비스의 타입은 ClusterIP, NodePort, LoadBalancer, ExternalName 네 가지가 있다. 이들은 어떻게 다른가?
A2.
질문의 네 가지 서비스 유형은 Kubernetes 클러스터 내의 서비스 액세스 및 노출을 위한 서로 다른 기능을 제공한다. 각 서비스 유형은 다양한 수준의 접근성과 기능을 제공하므로 특정 요구 사항 및 쿠버네티스 내 배포 시나리오에 따라 적절한 유형을 선택할 수 있다.
-
Cluster IP
기본 서비스 유형으로 클러스터 내 서비스에 대한 내부 액세스를 제공한다. 클라이언트가 서비스에 연결하는 데 사용할 수 있는 안정적인 클러스터 IP 주소가 서비스에 할당된다. 클러스터 IP는 클러스터 내 서비스 간 통신에 적합하나 클러스터 외부에서는 접근이 불가하다. -
Node Port
클러스터의 모든 노드에서 특정 포트의 서비스를 노출하며, 각 노드의 상위 포트에서 서비스로 트래픽을 전달한다. 클라이언트는 클러스터 노드의 IP 주소와 할당된 노드 포트를 사용하여 서비스에 액세스할 수 있다. 또한 클러스터 외부에서 서비스에 접근해야할 때 유용하지만 보안상의 이유로 프로덕션 환경에서는 권장하지 않는다. -
Load Balancer
일반적으로 클라우드 제공업체의 로드밸런서 서비스에서 제공하고, 외부 액세스 및 부하 분산이 필요한 프로덕션 환경에서 사용된다. 외부 로드 밸런서를 자동으로 프로비저닝하여 서비스에 트래픽을 분산한다. 로드 밸런서에는 공개적으로 액세스 가능한 IP 주소가 있으므로 클러스터 외부의 클라이언트가 서비스에 액세스할 수 있다. -
External Name
외부 서비스의 별칭 역할을 하는 특수 서비스 유형이며, 로드 밸런싱 또는 프록시 기능을 제공하지 않는다. 대신 External Name을 사용하면 클러스터 내의 서비스가 외부 이름(예. DNS 이름)으로 서비스에 액세스할 수 있다. 쿠버네티스 서비스를 외부 데이터베이스나 API 등 클러스터 외부에 위치한 서비스에 매핑하고자 할 때 유용하다.
*마이그레이션 : 최소한의 중단과 중단 시간을 보장하면서 한 노드 또는 클러스터에서 다른 노드 또는 클러스터로 워크로드(애플리케이션)를 이동하는 프로세스를 의미한다. 여기에는 워크로드와 관련된 상태 및 리소스를 새 대상으로 전송하는 작업이 포함된다.