컨테이너 오케스트레이션
컨테이너 오케스트레이션은 중앙관리자로 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구입니다.
컨테이너 오케스트레이션은 아래와 같은 기능을 제공해줍니다.
- 상태관리
- 배포관리
- 배포 버전 관리
- 서비스 등록 및 조회
쿠버네티스
컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템
컨테이너 오케스트레이션 중 하나가 쿠버네티스입니다.
Pod 란
쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위입니다.
그리고 하나 이상의 컨테이너 그룹을 뜻합니다.
파드-컨테이너 개념정리
- 컨테이너는 애플리케이션을 뜻합니다. 이는 완전한 어플리케이션의 일부 기능일 수도 있고, 완전한 어플리케이션 그 자체일 수 있습니다.
- 만약 컨테이너가 완전한 어플리케이션의 일부 기능이라면?
- 여러 개의 컨테이너들이 모여 하나의 완전한 어플리케이션을 구성할 것입니다.
- 이때 여러 개의 컨테이너가 모여 하나의 파드가 됩니다. (그럼 이 파드가 완전한 어플리케이션이 됩니다.) - 만약 컨테이너 1개가 완전한 어플리케이션 기능을 갖추고 있다면?
- 하나의 컨테이너로도 하나의 파드를 구성할 수 있습니다. - 즉, 파드에 정의된 여러 개의 컨테이너는 하나의 완전한 애플리케이션으로서 동작합니다
node 란
클러스터 내 가상 서버
즉, 컴퓨팅 엔진 단위라고 이해하면 됩니다.
클러스터 다음으로 큰 단위이며, 마스터 노드와 워커 노드로 분리되어 있습니다.
마스터 노드가 죽으면 클러스터를 관리할 노드가 없기에, 일반적으로는 3개 정도의 마스터 노드를 띄어 관리하는 것으로 알려져 있습니다
Cluster 란
쿠버네티스 내 가장 큰 단위로, 가상 서버들이 속한 클라우드를 뜻합니다.
쿠버네티스에서 서버는 노드 라는 단위로 불리므로,
클러스터란 마스터 노드와 워커노드를 합친 것 이라 해석할 수 있습니다.
쿠버네티스 클러스터 구성
Master node : 워커 노드들의 상태를 관리하고 제어
- etcd : key-value 타입의 저장소. worker node, 쿠버네티스의 상태정보를 가지고 있습니다.
- kube - apiserver : 사용자와 클러스터 간의 통신 인터페이스, scheduler에게 요청
- kube - scheduler : 새로 생성된 Pod의 배치를 결정.
- kube - controller - manager : 클러스터 상태를 유지하도록 관리(복제본, 노드 상태 등).
Worker node : 실제 애플리케이션이 실행되는 곳
- kubelet : 마스터와 통신하여 Pod의 생애 주기를 관리
- Container Runtime : 컨테이너(Docker, containerd)를 실행.
- Kube Proxy : 네트워크 트래픽을 관리하고, 서비스 간 통신을 지원.
CNI 란?
CNI(Container Network Interface)는 컨테이너 네트워크를 관리하기 위한 표준 인터페이스를 정의한 사양입니다.
CNI 역할
- 컨테이너 네트워크 설정 : 컨테이너 생성 시 네트워크 인터페이스를 추가하고 IP 주소 및 라우팅 설정
- 컨테이너 네트워크 삭제 : 컨테이너 종료 시 네트워크 설정 제거
- 네트워크 플러그인 관리 : 다양한 네트워크 플러그인과의 호환성 제공
쿠버네티스에서 CNI
- 쿠버네티스는 CNI를 통해 Pod 간 통신을 설정합니다.
- Pod는 기본적으로 오버레이 네트워크를 사용하여 클러스터 내 다른 노드와 통신합니다.
- CNI 플러그인을 설치해야 Pod 간의 통신과 네트워킹이 제대로 작동합니다.
CNI의 주요 구성 요소
CNI 플러그인 :
네트워크를 실제로 구성하는 도구.
- Calico: 네트워크 정책과 보안을 중점으로 둔 플러그인.
- Flannel: 간단하고 빠른 네트워크 플러그인.
- Weave Net: 자동화된 클러스터 네트워크 생성.
CNI 사양:
- 플러그인은 반드시 CNI 사양을 준수해야 하며, 네트워크 인터페이스 추가/삭제를 위한 명령을 구현.
CNI 실행 바이너리:
- 컨테이너 런타임(Docker, containerd)에서 CNI 플러그인을 호출하여 네트워크 설정.
쿠버네티스에서 컨테이너 동작 Flow
1. 사용자 요청 -> API Server
-
사용자가 kubectl 명령어 또는 API 요청을 통해 쿠버네티스 클러스터에 작업 요청
- 요청 내용은 YAML/JSON 형식으로 정의
-
API Server가 요청을 받아들이고, 요청을 etcd(분산 저장소)에 저장.
- API Server는 쿠버네티스의 중앙 컨트롤 인터페이스 역할.
2. 스케줄링 단계
- Scheduler가 클러스터의 모든 워커 노드를 확인하여 적합한 노드를 선택.
- 리소스상태, 태그, 우선 순위 등 기준으로 노드 결정.
- 선택된 노드에 Pod가 배치됨.
3. 컨테이너 생성 및 실행
- 워커 노드의 kubelet이 API Server로 부터 작업 명령을 받음.
- kubelet은 각 워커 노드에서 실행되는 에이전트로, Pod 관리
- kubelet이 다음 작업 수행 :
- Pod 사양 확인 : 생성할 컨테이너 이미지, 리소스 요청, 볼륨 마운트 정보 확인.
- Container Runtime 호출 : Docker 또는 containerd와 같은 런타임을 호출하여 컨테이너 실행
- 컨테이너 생성 및 네트워크 설정 :
- CNI 플러그인이 호출되어 네트워크 인터페이스를 설정.
- 컨테이너가 지정된 IP를 할당받고, 네트워크 경로 설정.
4. Pod의 상태 확인 및 유지
- 컨테이너가 실행되면, Kubelet은 Pod의 상태를 지속적으로 모니터링.
-
Probe(헬스체크)로 상태 확인:
Liveness Probe: 컨테이너가 살아 있는지 확인. Readiness Probe: 컨테이너가 요청을 처리할 준비가 되었는지 확인. -
만약 컨테이너가 종료되거나 실패하면:
Restart Policy에 따라 재시작. 문제가 지속될 경우, Scheduler가 다른 노드에 Pod를 재배치.
5. 서비스(네트워크) 연결
-
Service 생성 및 연결 :
- Pod가 외부 트래픽을 처리할 수 있도록 Service 객체를 생성.
- ClusterIP, NodePort, LoadBalancer 등 다양한 타입 사용 가능.
-
DNS 서비스:
- 쿠버네티스 내에서 CoreDNS를 사용해 Pod 이름으로 통신 가능.
- Ingress 설정(선택 사항):
- 외부 트래픽을 특정 Service로 라우팅하기 위해 Ingress 리소스를 설정.
6. 로깅 및 모니터링
-
실행 중인 컨테이너의 로그 및 메트릭 수집:
- kubectl logs로 Pod 로그 확인.
-
모니터링 툴을 통해 상태를 실시간으로 확인:
- Prometheus + Grafana.
- 쿠버네티스 이벤트 추적.
