k8s 이론: 아키텍처

클러스터란?

• k8s를 구성하는 기본 단위로, 클러스터에선 컨트롤 플레인과 노드 사이에선 지속적인 통신이 이뤄짐
• 이것의 목적은 컨테이너화된 애플리케이션을 안정적으로 배포 스케일, 관리하는 것

출처: https://kubernetes.io/ko/docs/concepts/overview/components/

---

클러스터 동작 에시

1. 사용자가 Deployment 생성 요청
2. kube-apiserver가 이를 받아 상태를 etcd에 기록
3. kube-apiserver가 kube-scheduler에게 전달
4. kube-scheduler가 파드를 노드에 배치
5. kube-scheduler가 kube-apiserver에게 보고
6. kube-apiserver가 노드에게 응답
7. 노드 내 kubelet이 노드에서 파드를 실행하고 상태를 보고
8. kube-apiserver가 보고를 받아 kube-controller-manager 에게 전달
9. kube-controller-manager가 실제 상태와 의도한 상태를 비교해서 부족한 파드를 생성하거나 삭제

---

클러스터 내 구성 요소

• 컨트롤 플레인(Control Plane)
• 노드(Node)

---

컨트롤 플레인(Control Plane)

클러스터를 관리하고 의도한 상태를 유지하는 중심 컴포넌트
컨트롤 플레인은 클러스터의 상태를 관리하며 노드와 지속적인 통신이 이뤄진다.

구성요소

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager

---

kube-apiserver

• 클러스터의 중앙허브 역할을 담당하며 노드와의 통신을 담당한다.
• 모든 REST API 요청을 담당하며 각 상황에 맞는 곳에 전달 및 취합해 노드에 전달
• 노드에게서 상태 데이터가 들어오면 그 상태 데이터를 etcd에 저장하고 인증, 인가 검사를 수행한다.

노드에게서 받는 데이터

• 상태 데이터
  • 주소, 컨디션, 용량, 정보 등
• heartbeat
  • 클러스터가 노드가 가용가능한지 판단하거나 조치를 취하는데 도움을 준믄 데이터
  • 상태에 대한 데이터, kube-node-lease 내의 Lease 오브젝트 등

---

etcd

• 클러스터 상태를 저장하는 분산 키-값 저장소
• etcd에서 kube-apiserver는 데이터를 읽기/쓰기를 하며, 내부 모델 기준으로 버전을 변환한다.

---

kube-scheduler

• 노드가 배정이 되지 않은 Pod를 감지하고 이를 실행할 노드를 선택해 배정해주는 역할
• 리소스 요구량, 정책 및 affinity/anti-affinity 등 고려한다.

affinity/anti-affinity 란?

• k8s에서 Pod가 어떤 노드에 스케줄링이 될지 결정하는 규칙
• 종류
  • Node Affinity : 노드에 붙은 label 기반 규칙을 사용해 어떤 노드에 Pod가 스케줄링되기 적합한지 정의
  • Pod Affinity : 다른 Pod의 label을 기반으로 특정 Pod가 있는 노드나 토폴로지에서 실행되어야 한다는 규칙
  • Pod Anti Affinity : 특정 Pod와 같은 노드나 토폴로지에 함께 두지 않도록 하는 규칙

각 Affinity/Anti Affinity는 아래 규칙을 따름

• requiredDuringSchedulingIgnoredDuringExecution : 조건을 모두 만족해야 노드에 Pod 생성
• preferredDuringSchedulingIgnoredDuringExecution : 조건을 만족하면 좋지만 만족하지 않아도 Pod 생성은 됨

---

kube-controller-manager

• 선언적 상태(desired state)와 실제 상태(actual state)를 맞추는 담당하며 이를 위해 다양한 컨트롤러 프로세스를 실행
• 각 컨트롤러는 프로세스이며 단일 바이너리로 컴파일되고 단일 프로세스에서 실행

컨트롤러의 유형

• Node Controller : 노드 다운 시, 감시하여 대응
• Job Controller : 일회성 작업(Job) 오브젝트를 감시하고 해당 작업 실행을 위한 Pod를 생성
• EndpointSlice Controller : EndpointSlice 오브젝트를 채워 Pod와 Service 사이의 연결을 제공
• ServiceAccount Controller : 신규 Namespace에 기본 ServiceAccount를 생성

---

cloud-controller-manager(CCM)

• 클라우드 인프라와 연동 및 관리를 담당하며, 여러 컨트롤 루프를 단일 바이너리로 결합해 하나의 프로세스로 실행
• 클라우드 플랫폼과 상호 작용하는 구성요소를 포함하며, 클라우드 인프라와 통신하는 부분과 클러스터 내부와 통신하는 것을 분리하는 구성을 가짐
  • 이 구성으로 인하여 k8s 본체 프로젝트의 속도와는 상관없이 별개의 속도로 기능을 릴리스 가능

각 컨트롤러가 가질 수 있는 Cloud Provider 의존성

• Node Controller : 노드가 멈춘 뒤, 클라우드에서 해당 노드가 삭제되었는지 확인하기 위해 Cloud Provider를 확인
• Route Controller : 클라우드 인프라스트럭쳐 기반에서 라우터를 설정
• Service Controller : Cloud Provider의 로드밸런서를 관리

CCM이 구현하는 주요 컨트롤러 기능

• Node Controller(Node lifecycle controller)
  • 클라우드 인프라에서 새 서버가 생성되면 Cloud Provider API에서 고유 ID를 받아와 k8s의 Node 객체에 기록
  • 클라우드 관련 정보를 사용해서 노드 오브젝트에 어노테이션과 레이블에 정보를 작성
  • 노드의 호스트 이름과 네트워크 주소를 가져옴
  • 노드의 상태를 확인하여 응답하지 않는 경우 이 컨트롤러는 Cloud Provider API를 통해 서버의 상태를 확인하여 노드가 클라우드에서 삭제된 경우 사용자의 k8s 클러스터에서 노드 오브젝트를 삭제
• Route Controller
  • 클러스터 내 서로 다른 노드에 있는 컨테이너들이 통신할 수 있도록 클라우드 쪽에서 네트워크 라우트를 설정해야함
  • Cloud Provider에 따라서 Pod 네트워크를 위한 IP 블록을 할당할 수도 있다
• Service Controller
  • 서비스는 클라우드 인프라의 관리형 로드밸런서, IP주소, 네트워크 패킷 필터링, 대상 상태 확인과 같은 클라우드 인프라스트럭쳐 컴포넌트와 통합됨
  • 서비스 컨트롤러는 사용자의 Cloud Provider API와 상호 작용하여 서비스 리소스를 선언 시, 클라우드에서 로드밸런서를 생성하거나 설정하는 작업을 처리

컨트롤러

• k8s에서 클러스터의 Desired State와 Current State 를 지속적으로 비교하고 차이가 있을 시 자동으로 조정(Reconcile)
• 이미 만들어진(Built In)방식과 사용자 정의 방식이 존재
• 특징
  • API 서버를 통해 제어
  • 이벤트 + 루프 기반
    • Watch 이벤트로 API 오브젝트 변경을 감지
    • 지속적으로 루프를 돌며 상태가 원하는 상태인지 감시
• 컨트롤러의 종류
  • Deployment Controller: ReplicaSet 관리
  • Replica Controller: Pod 개수 조정
  • Job Controller: 일정 횟수의 Pod 실행/완료 보장
  • Node Controller: 노드 상태 감지, 노드 장애 시 조치
  • Service Controller: 클라우드 로드밸런서 등 외부 리소스 생성
  • Namespace Controller: 삭제된 네임스페이스 내 리소스 정리

---

노드(Node)

• 애플리케이션이 실제 실행되는 서버 단위이자, Pod를 유지하고 k8s 런타임 환경을 제공하는 요소
• 물리 서버, 가상머신 모두 가능
• 하나의 클러스터에는 여러 노드가 존재 가능하며, 각 노드는 컨테이너화 된 애플리케이션(Pod)을 호스팅

구성요소

• kubelet
  • 컨테이너 런타임(Container Runtime)
• kube-proxy

Lease 오브젝트

• k8s 에서 리소스 상태 유지와 주기적 갱신(heartbeat) 정보를 관리하기 위한 API 오브젝트
  • 모든 노드에는 같은 이름을 가진 Lease 오브젝트가 네임스페이스에 kube-node-lease 로 존재
  • kubelet 하트비트는 Lease 오브젝트에 대한 업데이트 요청이다.
    • spec.renewTime 필드를 업데이트 하여 Control Plane가 노드의 가용성을 확인하는 용도로 사용
• 주로 Node Lease 형태로 사용되며 노드의 생존상태(node heartbeat) 를 추적하는 용도로 사용
  • 컨트롤 플레인이 노드가 살아있는지 확인하는 용도로도 사용
• 컴포넌트 수준의 리더 선출에도 사용
  • k8s에서 특정 시간에 컴포넌트의 인스턴스가 하나만 실행되도록 보장할 때 Lease 오브젝트를 사용
  • kube-controller-manager, kube-scheduler 에서 사용됨

---

kubelet

• 노드에서 실행되는 에이전트이며 파드가 정상 실행이 되는지 감시하고 상태를 API 서버에 보고한다.
• 여러 메커니즘을 통해 얻은 PodSpec의 집합을 받아 제대로 동작하도록 한다.
• k8s를 통해 생성되지 않은 컨테이너는 관리하지 않는다.
• Pod 스펙에 따라 컨테이너 런타임에 명령 전달

컨테이너 런타임(Container Runtime)

실제 컨테이너를 실행하는 엔진이며 도커, containerd, CRI-O 등이 있음

컨테이너 런타임 인터페이스(CRI)

• CRI는 플러그인 인터페이스로 kubelet이 다양한 컨테이너 런타임을 사용하게 돕는다
  • 이를 통해 클러스터 컴포넌트를 다시 컴파일 없이 런타임 변경하게 한다.
• 모든 노드에는 컨테이너 런타임이 있어야하며 kubelet은 이를 사용해 Pod와 컨테이너를 실행
• CRI는 kubelet과 컨테이너 런타임 간 통신을 위한 프로토콜
• k8s의 CRI는 gRPC기반 프로토콜을 정의

---

kube-proxy

• 각 노드에서 실행되는 네트워크 프록시, Service의 실제 구현부
• Service IP와 파드 간 연결 유지
• 로드밸런싱 수행
• 클러스터 내/외부 트래픽 관리

---

클러스터 내 통신

• 컨트롤 플레인 -> 노드

  • Pod에 대한 연결, 로그 확인 및 kubelet의 포트포워딩 기능을 제공하기 위해 이뤄짐
  • api 서버를 통한 kubelet과의 간접 통신 방식을 사용한다.
    • HTTPS 통신이지만 kubelet의 인증서를 검증하지 않기 때문에 보안을 위해 ssh 터널링이나 kubelet의 TLS 인증서를 사용해야 한다.

• 노드(kubelet 중심) -> 컨트롤 플레인

  • 노드 및 Pod 상태, 리소스 사용량 등을 컨트롤 플레인에 주기적으로 보고
  • 컨트롤 플레인에게 Desired State와 Actual State를 비교한 정보를 제공
  • 기본적으로 HTTP 통신을 사용하기 때문에 공용 네트워크가 아닌 사설 네트워크에서 사용해야 한다.

---

Self-Healing

• 시스템이 Desired State를 유지하도록 보장하는 기능이며 이로인하여 워크로드의 상태와 가용성이 유지
• 주요 기능
  • 컨테이너 단위 재시작
    • Pod 안의 컨테이너가 실패하면 재시작 정책(restartPolicy)에 따라 자동으로 재시작
  • 레플리카(Replica) 교체
    • Deployment, StatefulSet의 Pod가 실패 시, 지정 Replica 수를 유지하기 위해 대체 Pod를 생성
    • DeamonSet의 일부인 Pod가 실패 시, Control-Plane이 대체 Pod를 생성하여 동일 노드에 다시 연결
  • Persistance Storage(영구 스토리지) 복구
    • Persistance Volume이 연결된 파드를 실행 중일 때 노드에 장애가 발생하면 k8s는 다른 노드에 있는 새 Pod에 재연결
  • Service Load Balancing
    • Service 뒤에 있는(연결된) Pod 장애 시, k8s는 자동으로 Service의 Endpoint에서 해당 Pod를 제거해 정상 Pod로만 트래픽을 라우팅
• k8s에서 자가 치유를 제공하는 컴포넌트
  • kubelet
    • 컨테이너가 실행 중인지 확인 후, 실패한 컨테이너를 재시작
  • ReplicaSet, StatefulSet, DeamonSet의 컨트롤러
    • Pod Replic를 원하는 수로 유지
  • Persistance Volume 컨트롤러
    • 상태 저장 워크로드에서 volume 연결에 대하여 연결 및 해제를 관리