1-2. Control Plane 컴포넌트 (etcd, API Server, Controller Manager, Scheduler)

이 글은 “[Udemy] CKA with Practice Tests” 강의를 수강하며 정리한 내용을 바탕으로 작성한 내용입니다.

---

etcd

etcd는 쿠버네티스의 데이터 저장소로 쿠버네티스 마스터 노드에서 실행됩니다.

etcd 데이터 저장소는 PODS, Configs, Secrets, Accounts, Roles, Bindings와 같은 클러스터에 대한 정보를 저장합니다.

kubectl get으로 조회하는 모든 정보는 etcd에서 가져오는 것이며, 노드 추가, 파드 배포 등 클러스터에서 발생하는 모든 변경 사항도 etcd에 기록됩니다.

데이터베이스의 형태로 key-value 값으로 저장되기 때문에, /var/lib/etcd에 저장 가능하고, 별도의 파일로 백업(스냅샷) 가능합니다.

 

설치 방법

# *바이너리 설치*
wget -q --https-only "<https://github.com/etcd-io/etcd/releases/download/v3.3.11/etcd-v3.3.11-linux-amd64.tar.gz>"

# *kubeadm 설치
kubectl get pods -n kube-system*

• 클러스터를 처음부터 직접 구성하는 경우에는 etcd 바이너리를 직접 다운로드해 마스터 노드에 서비스로 설치합니다.
• kubeadm으로 클러스터를 구성하면 etcd를 kube-system 네임스페이스의 파드로 자동 배포합니다.

etcd 데이터 탐색

클러스터에 저장된 모든 키를 조회하려면 아래 명령어를 사용합니다.

kubectl exec etcd-master -n kube-system -- sh -c \\\\
  "ETCDCTL_API=3 etcdctl \\\\
  --cert=/etc/kubernetes/pki/etcd/server.crt \\\\
  --key=/etc/kubernetes/pki/etcd/server.key \\\\
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \\\\
  get / --prefix --keys-only"

쿠버네티스는 특정 디렉터리 구조로 데이터를 저장합니다.

루트 디렉터리는 registry이며, 그 아래에 파드, 노드, 시크릿 등의 리소스가 분류되어 있습니다.

 

HA(고가용성) 환경에서의 etcd

고가용성 환경에서는 여러 개의 마스터 노드에 etcd 인스턴스가 분산 배치됩니다. etcd.service 설정에서 --initial-cluster 옵션으로 각 etcd 인스턴스가 서로를 인식하도록 설정합니다.

---

kube-apiserver

kube-apiserver는 Control Plane의 핵심 컴포넌트로, 클러스터와의 모든 통신을 담당하는 중앙 게이트웨이 역할을 합니다.

kubelet, kube-scheduler, kube-controller-manager 같은 내부 컴포넌트는 물론, 외부 사용자도 모두 kube-apiserver를 통해 클러스터와 상호작용합니다.

 

주요 역할

역할	설명
클러스터 게이트웨이	사용자와 내부 컴포넌트의 모든 요청을 처리하는 진입점
인증/인가 처리	요청 주체의 신원 확인(Authentication)과 권한 검사(Authorization) 수행
Admission Control	요청이 클러스터에 반영되기 전 정책 기반 검증 실행
etcd와 통신	클러스터의 상태 정보를 etcd에 읽고 쓰기
REST API 제공	RESTful API를 통해 JSON 기반 응답 반환

 

작동 흐름

1. 사용자가 kubectl get pods 실행
2. kubectl이 kubeconfig를 이용해 kube-apiserver로 HTTPS 요청
3. API Server가 인증 → 인가 → Admission Control 순으로 검증
4. etcd에서 데이터 조회
5. 결과를 JSON으로 반환 → kubectl이 사람이 읽을 수 있는 형태로 출력

설치 방법

# *바이너리 설치*
wget <https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kube-apiserver>

# *kubeadm 설치*
kubeadm init --pod-network-cidr=10.244.0.0/16

 

주요 실행 옵션

kube-apiserver \\\\
  --advertise-address=192.168.0.100 \\\\        # 다른 컴포넌트가 접근할 API 서버 IP
  --etcd-servers=https://127.0.0.1:2379 \\\\    # etcd 클러스터 주소
  --service-cluster-ip-range=10.96.0.0/12 \\\\ # 서비스 클러스터 IP 범위
  --client-ca-file=/etc/kubernetes/pki/ca.crt \\\\
  --tls-cert-file=/etc/kubernetes/pki/apiserver.crt \\\\
  --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

 

상태 확인 및 점검

# kube-apiserver Pod 확인
kubectl get pods -n kube-system -l component=kube-apiserver

# 로그 확인
journalctl -u kube-apiserver

# Static Pod manifest 위치
cat /etc/kubernetes/manifests/kube-apiserver.yaml

# 마스터 노드에서 프로세스 옵션 확인
ps -aux | grep kube-apiserver

 

자주 사용하는 명령어

# 리소스 종류 확인
kubectl api-resources

# 지원되는 API 버전 확인
kubectl api-versions

# API 서버에 직접 요청
curl --cacert /etc/kubernetes/pki/ca.crt \\\\
     --cert /etc/kubernetes/pki/apiserver.crt \\\\
     --key /etc/kubernetes/pki/apiserver.key \\\\
     <https://127.0.0.1:6443/api>

---

kube-controller-manager

kube-controller-manager는 쿠버네티스의 다양한 컨트롤러를 하나의 프로세스로 묶어 실행하는 컴포넌트입니다.

컨트롤러란 클러스터 내 구성 요소의 상태를 지속적으로 감시하고, 현재 상태(actual state)가 원하는 상태(desired state)와 다를 경우 이를 맞추기 위해 동작하는 프로세스입니다.

 

Node Controller

노드 상태를 모니터링하고 애플리케이션이 계속 실행되도록 필요한 조치를 취하는 역할을 담당합니다.

• 노드가 일정 시간 동안 heartbeat(상태 보고)를 보내지 않으면 NotReady 상태로 변경
• 일정 시간이 더 지나면 해당 노드에서 실행 중이던 Pod들을 제거하고, 다른 정상 노드로 재스케줄
• 클러스터의 가용성과 안정성을 유지하기 위한 핵심 컨트롤러

관련 파라미터: --node-monitor-period, --node-monitor-grace-period, --pod-eviction-timeout

 

Replication Controller

ReplicaSet의 상태를 감시하고, 항상 원하는 수의 파드가 실행되도록 보장합니다. 파드 수가 부족하면 새로 생성하고, 초과하면 불필요한 파드를 삭제합니다.

• 사용자가 원하는 복제 수(replicas)와 실제 Pod 수를 비교
• 부족한 경우 새로운 Pod 생성, 초과된 경우 불필요한 Pod 삭제
• ReplicaSet은 ReplicationController의 향상된 버전이며, Deployment와 함께 사용됨

주로 스케일링(수평 확장) 시 활용되며, Pod의 수를 자동으로 관리합니다.

 

Deployment Controller

Deployment 리소스를 기반으로 애플리케이션의 롤링 업데이트, 롤백을 관리합니다.

• 새로운 버전의 Pod로 순차적으로 업데이트(무중단 배포)
• 이전 버전으로 손쉽게 롤백 가능(kubectl rollout undo)
• Canary 배포, Blue-Green 배포 전략 구현 시 핵심

복잡한 애플리케이션 배포 전략을 선언형으로 다룰 수 있게 해줍니다.

 

DaemonSet Controller

클러스터 내 모든 노드(또는 조건에 맞는 노드)에 1개의 Pod를 강제 배포합니다.

• 노드가 추가되면 자동으로 DaemonSet의 Pod가 함께 생성
• 로그 수집, 모니터링, 보안 에이전트 등 노드 단위 작업에 필수

예시: fluentd, filebeat, node-exporter, kube-proxy

 

Job Controller

일회성 작업을 실행하고, 그 작업이 성공적으로 완료될 때까지 상태를 추적합니다.

• 지정된 Pod가 1회 실행되고 성공적으로 종료되었는지 확인
• 실패할 경우 재시도 (backoffLimit, restartPolicy)
• 병렬로 여러 작업을 실행할 수 있는 설정 지원

백업 작업, 데이터 처리, 마이그레이션 스크립트 등에 사용됩니다.

 

CronJob Controller

Job을 주기적으로 실행하기 위한 컨트롤러 입니다.

• Cron 표현식으로 실행 주기를 정의 (/5 * * * * 등)
• 정해진 시간마다 Job을 생성하여 실행
• 과거 스케줄 실패 여부도 관리(startingDeadlineSeconds, concurrencyPolicy 등)

배치 작업 자동화에 이상적 (예: 매일 자정 데이터 정리)

 

StatefulSet Controller

상태 저장 애플리케이션을 위해 고유성, 순서, 저장소 유지를 보장합니다.

• 각 Pod는 고유 이름(web-0, web-1)을 가짐
• 각 Pod는 전용 PVC(영구 볼륨)를 사용하고, 삭제 후에도 재사용
• 배포 및 종료 순서를 보장

데이터베이스(MySQL, MongoDB), Zookeeper, Kafka 등의 배포에 적합합니다.

 

Endpoint Controller

Service 리소스와 관련된 실제 Pod들의 IP 주소(Endpoint)를 관리합니다.

• Service가 선택한 Label과 일치하는 Pod의 IP를 Endpoint에 등록
• Pod 변경 시 실시간으로 반영

ClusterIP/NodePort 서비스가 정상 작동하기 위한 핵심 연결고리입니다.

 

Service Account & Token Controller

Pod가 Kubernetes API에 접근할 수 있도록 ServiceAccount와 인증 토큰을 자동 생성 및 주입합니다.

• Pod 생성 시 ServiceAccount가 없으면 default 계정 자동 생성
• API 인증용 토큰이 자동으로 마운트됨 (/var/run/secrets/kubernetes.io/serviceaccount/token)

Pod가 API에 접근할 수 있게 하며, RBAC과 연계하여 보안 제어가 가능

 

Namespace Controller

네임스페이스 삭제 시, 해당 네임스페이스 안의 모든 리소스를 정리하고 마지막에 네임스페이스를 삭제합니다.

• 종속된 모든 리소스를 순차적으로 삭제
• 일부 리소스가 남아 있으면 Namespace가 Terminating 상태에서 멈춤

네임스페이스의 정합성과 리소스 누수 방지에 중요한 역할

 

Garbage Collector Controller

ownerReferences 필드에 기반하여 참조되지 않는 리소스들을 자동으로 정리합니다.

• 예: ReplicaSet 삭제 시, 해당 ReplicaSet이 생성한 Pod들도 자동 삭제
• 의존 관계를 명시해 리소스 정리를 자동화

복잡한 리소스 간 의존성을 안전하게 관리할 수 있게 해줍니다.

 

설치 및 상태 확인

# 바이너리 설치 - kube-controller-Manager를 설치하면, 다양한 컨트롤러도 함께 설치됩니다.
wget https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kube-controller-manager

# Pod 확인
kubectl get pods -n kube-system -l component=kube-controller-manager

# 로그 확인
journalctl -u kube-controller-manager

# Static Pod manifest 위치
cat /etc/kubernetes/manifests/kube-controller-manager.yaml

# 마스터 노드에서 프로세스 옵션 확인
ps -aux | grep kube-controller-manager

---

kube-scheduler

kube-scheduler는 새로 생성된 파드에 대해 어떤 노드에 배치할지를 결정하는 컴포넌트입니다.

스스로 파드를 실행하지는 않으며, 스케줄링 로직을 통해 가장 적합한 노드를 선정하고 해당 정보만 API Server에 반영합니다.

 

주요 역할

역할	설명
후보 노드 필터링	자원 부족, Taints, Affinity 등 조건에 따라 후보 노드를 걸러냄
노드 점수화	각 후보 노드에 점수를 매겨 가장 적합한 노드를 선택
바인딩	선택된 노드에 파드를 바인딩하여 실행 요청

 

스케줄링 흐름

1. 사용자가 Deployment, Job, Pod 등을 생성
2. Pod는 Pending 상태로 생성되고, etcd에 저장됨
3. kube-scheduler는 Pending 상태의 Pod를 감지
4. 여러 알고리즘을 통해 적합한 노드를 선택
5. 선택된 노드를 .spec.nodeName에 설정 (바인딩)
6. kubelet이 해당 노드에서 Pod를 실행

 

스케줄링 알고리즘

1. Filtering
   조건에 맞지 않는 노드들을 걸러냅니다.
   
   • 리소스 부족 여부 (CPU, Memory)
   • Taints & Tolerations 일치 여부
   • Node Affinity 조건 만족 여부
   • Volume Attach 가능 여부
2. Scoring
   필터링을 통과한 노드들에 점수를 매겨 가장 적합한 노드를 선정합니다. 남은 자원이 많은 노드, 동일한 이미지가 이미 캐시된 노드 등에 높은 점수를 부여합니다. 각 알고리즘에 Weight를 부여해 종합 평가합니다.
3. Binding
   점수가 가장 높은 노드를 파드의 .spec.nodeName에 기록합니다. 이후 해당 노드의 kubelet이 이를 감지하고 파드를 실행합니다.

설치 및 상태 확인

# 바이너리 설치
wget <https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kube-scheduler>

# Pod 확인
kubectl get pods -n kube-system -l component=kube-scheduler

# 로그 확인
journalctl -u kube-scheduler

# Static Pod manifest 위치
cat /etc/kubernetes/manifests/kube-scheduler.yaml

# 마스터 노드에서 프로세스 옵션 확인
ps -aux | grep kube-scheduler