Kubernetes Architecture

 

Kubernetes 클러스터의 전체 구조를 알아보자.

k8s의 클러스터는 control plane과 worker node로 나뉜다.

control plane에는 cm, ccm, api-server, etcd, scheduler로 구성되어있고,

worker node에는 kubelet, kube-proxy, CRI로 구성되어있다.

 

api-server의 역할

모든 요청의 출입문.

클러스터의 진입점 역할을 하며 모든건 api-server를 통해서만 통신한다.

요청을 수신 받으면 인증(IAM) -> 인가(RBAC)를 통해 etcd 순서로 처리된다.

(~/.kube/config 파일 참고)

 

etcd의 역할

클러스터의 모든 상태를 저장하는 key-value 저장소.

모든 오브젝트 정보를 저장하고 죽게되면 클러스터 상태를 조회할 수 없다.

Raft 합의 알고리즘으로 고가용성을 보장한다.

#Raft 알고리즘: etcd가 고가용성을 보장하게 함.
여러 서버가 같은 데이터를 유지하는 방법
ex)반장 선출 + 다수결

리더는 무조건 1명, 리더가 물어보면 follower 들이 동의/반대를 함 (홀수/과반수)
리더가 죽으면 follower가 새로운 리더를 선출

 

EKS에서는 etcd를 AWS가 관리하기 때문에 직접 접근은 불가능하다.

 

scheduler의 역할

pod를 적절한 노드에 배치하는 역할을 한다.

필터링 -> 점수부여를 통해 api-server에 전달하고 실행된다.

 

controller-manager(CM)의 역할

여러 컨트롤러를 하나의 프로세스로 묶어 실행.

Deployment, Replicaset, Node, Job 등 묶어서 실행.

 

cloud-controller-manager의 역할

클라우드 프로바이더 전용 컨트롤러

 

kubelet의 역할

각 노드에서 실행되는 에이전트로, control plane의 지시를 받아 파드를 실행.

api-server를 보면서 변화를 감지해서 CRI를 통해 컨테이너를 실행

*CRI: container Runtime Interface

파드 상태를 주기적으로 api-server에 보낸다.

 

kube-proxy의 역할

service의 네트워크 규칙을 노드에 적용

api-server의 service/endpoint를 감지해서 변경 시 업데이트

 

--

 

- kubectl apply 하면 발생하는 일

* Reconcile Loop : 각 컴포넌트들이 etcd 변화를 감지하고 맞추는 것

1. kubectl -> api-server (인증 -> 인가 -> 유효성 검사 -> etcd 저장)

2. api-server -> CM (Deployment 생성됐다는 걸 감지)

 -> Replicaset 생성

-> pod 생성

-> etcd 저장

3. api-server -> scheduler (nodeName이 없는 pod가 있다는 걸 감지)

-> 필터링 : 리소스 부족한 노드 제거

-> 점수: 여유가 많은 노드에 가산점 부여

-> api-server에 노드 1순위 전달

-> etcd 업데이트 (해당 파드는 해당 노드에 배치) 

-> CRI 에 컨테이너 실행 요청

 

- CRI (Container Runtime Interface) 컨테이너가 실제로 어떻게 뜨는가

kubelet (CRI 표준 인터페이스)

-> containerd (OCI 표준) : 컨테이너 런타임

-> runc : 실제 컨테이너 실행

-> kernel (namespace: 프로세스 격리 cgroup: 리소스 제한)

 

- kube-proxy : iptables가 실제로 하는 일

Service clusterIP: 10.96.0.1:80 이 생성되면 kube-proxy가 각 노드에 iptables 규칙 추가.

실제로 service IP는 존재하지 않고 iptables가 패킷을 가로채서 Pod IP로 바꿔준다.

iptables 모드가 기본이며 고성능으로 IPVS 가 있다.