[DOIK2] 스터디: Kubernetes 의 Component와 멱등성에 대한 이해

주의사항

이 글은 DIOK2 스터디에서 진행한 내용을 바탕으로 작성한 내용입니다. 공부중인 내용이기때문에, 틀린 부분이 있을수 있습니다.

 

 

쿠버네티스의 구성요소(컴포넌트)

공식사이트: https://kubernetes.io/ko/docs/concepts/overview/components/

일반적으로 쿠버네티스를 “노드” 에 설치한다고하면, 마스터와 워커로 구성된다고만 알고있다. 좀더 자세하게 표현하면 다음과같다.

K8s Cluster == 1개이상의 노드로 구성 == 1개이상의 (Control Plane + Node Component)

 

Control Plane’s Component

기능: 클러스터에 대한 전반적인 결정(e.g. 스케쥴링), 클러스터 이벤트(e.g. 파드생성) 등을 담당한다.

 

kube-apiserver(중요)

쿠버네티스 API 를 노출하는 컴포넌트역할을 한다. 쿠버네티스 컨트롤플레인의 프론트엔드를 담당하게 구현되어있다.

수평확장을 하도록 디자인 되어있고, 인스턴스간 트래픽을 균형있게 조절하게하는 역할을 한다.

실제 작동체계: 명령어(kubectl) → ControlPlaneComponentkube-apiserver → NodeComponent kubelet ⇒ 작동

• 모든 명령어는 kube-apiserver를 통해서 작동함

 

etcd

모든 클러스터 데이터를 담는 key-value 저장소

 

kube-scheduler

노드가 배정되지 않은 새로 생성된 파드를 감지하고 → 실행할 노드를 결정하는 컴포넌트

스케쥴링 하는 역할을 담당하며 해당되는 요소는 리소스, 하드웨어 제약, 어피니티 등등을 포함한다.

 

kube-controller-manager

컨트롤러 프로세스를 실행하는 컴포넌트.

• 컨트롤러 프로세스: 클러스터의 상태를 확인하고, 현재 상태를 desire state로 변화하게하는 프로세스. 종류는 4가지(Node Controller, Job Controller, Endpoint-slice Controller, Service-Account Controller)로 구성됨.

 

cloud-controller-manager

클라우드별 공급자(e.g. aws, gcp, ms …) 컨트롤 로직을 포함하는 컴포넌트.

온프렘의 경우는 제공되지않고, cloud-controller-manager를 사용해서 클라우드 공급자의 API 에 접근할수 있다.

 

NODE’s Component(Worker node)

기능: 동작중인 파드를 유지시키고, 쿠버네티스 런타임환경을 제공함

 

kubelet(중요)

노드에서 실행되는 Agent. Pod에서 Container가 제대로 동작하도록 관리하는 역할

ControlPlane의 Scheduler가 Pod를 NodeComponent에 할당하면, kubelet이 Pod와 컨테이너를 배치함

 

kube-proxy

네트워크 프록시, 쿠버네티스 서비스개념의 구현체 부분

노드의 네트워크 규칙을 유지관리. 네트워크 규칙을 통해서 내부네트워크, 클러스터 외부에서 Pod에 접근하게함

 

Container Runtime

컨테이너 실행을 담당하는 소프트웨어.

e.g. containerd, CRI-O

• docker 는 제거되었다

 

Namespace(NS) 리소스

NS가 중요한 이유: K8s의 리소스를 구분할때 사용하기 때문

1. namespace level resource: “어디위치해 있는지” 가 중요한 object들. (Pod, Deployment, Service…)
2. Cluster lvel resource: “대충 클러스터내부에 있겠지”싶은 objecte들. (Node, PV, StorageClass …)

 

 

쿠버네티스의 성질: 선언형(멱등성)

Container: 가장 최소 기능단위. 일종의 소프트웨어 패키지

Pod: 쿠버네티스에서 생성하고 관리할수 있는 가장작은 컴퓨팅 단위

Replicaset: 레플리카 파드(쉽게말하면 파드의 복제본) 을 항상 안정적으로 유지하도록 제공

Deployment: 파드와 레플리카셋 을 안정적으로 유지하도록 제공

 

Replicaset vs Deployment

Replicaset과 Deployment는 가끔 헷갈릴때가있는데, 자세히 살펴보면 다음과 같다.

Replicaset: 레플리카 파드 집합 실행을 안정적으로 유지하는 것

Deployment: Pod와 Replicaset에 대한 선언적 업데이트를 제공

정확히 따지자면 Deployment가 Replicaset보다 상위개념에 존재한다고 보는게맞는것같다.

 

Controller

 쿠버네티스에는 Pod의 상태를 확인하고, 관리자가 선언한 Pod의 갯수를 보장해 주는 컴포넌트가 있는데, 이 컴포넌트의 이름이 Controller 임

 Replicaset과 Deployment는 Controller의 한 종류임

 Controller의 역할은 AutoHealing, Software Update, AutoScaling, Job(크론같은거)

 

Replicaset

 Replicaset 오브젝트를 선언하고, Replicas에서 template로 파드를 정의함

 Pod의 숫자가 보장된다는점에서 안정적으로 배포할수 있어서 좋은데, Replicaset은 파드 업데이트에 대한 배포를 지원하지않음

 

Deployment

 Pod와 Replicaset에 대한 선언적 업데이트를 제공함

 Replicaset이 Pod를 조절하지만, Replicaset을 조절하는것은 Deployment라는것

 Deployment에서 Replicaset을 조절해서 Pod를 업데이트하는 방식으로 배포하는게 가능한거임

 업데이트 방법(Rolling Update, Recreate, Blue/Green, Canary) 이 존재함