[kubernetes] 쿠버네티스의 핵심 구성요소 완벽 이해: kube-system, api-server, etcd

쿠버네티스(Kubernetes, K8s)는 현대적인 컨테이너 오케스트레이션 시스템의 사실상 표준이 되었습니다. 수많은 개발자와 운영자가 이 강력한 플랫폼을 사용하여 애플리케이션을 배포하고 관리하고 있지만, 정작 그 핵심이 어떻게 구성되고 동작하는지에 대해서는 깊이 이해하지 못한 경우가 많습니다.

쿠버네티스의 진정한 강력함을 이해하고, 안정적이며 효율적인 클러스터를 운영하기 위해서는 Control Plane 구성요소들의 역할과 상호작용을 깊이 이해해야 합니다.

오늘 포스팅에서는 쿠버네티스의 핵심 중의 핵심인 kube-system 네임스페이스, 모든 요청의 게이트웨이 kube-apiserver, 그리고 클러스터의 상태를 저장하는 **etcd**에 대해 상세히 알아보고, 실제 실습을 통해 그 동작 과정을 눈으로 확인해 보겠습니다.

이전에 학습한 [kubernetes] 쿠버네티스 논리적 공간 관리 (멀티테넌시) 네임스페이스 알아보기

 

---

1. kube-system 네임스페이스: 시스템의 전용 공간

쿠버네티스에서 네임스페이스(Namespace)는 클러스터 내의 리소스를 논리적으로 격리하는 논리적인 영역입니다. 그중에서도 **kube-system**은 쿠버네티스 시스템 자체를 위한 전용 네임스페이스입니다.

kube-system이 중요한 이유

• 시스템 보호: 사용자의 실수나 악의적인 애플리케이션으로부터 쿠버네티스 핵심 구성요소들을 보호합니다. 사용자가 배포하는 애플리케이션 포드(Pod)들과 시스템 포드들을 격리하여 안정성을 확보합니다.
• 핵심 구성요소 실행: 쿠버네티스 클러스터 운영에 필수적인 제어 평면 구성요소들이 이 네임스페이스 안에서 포드로 실행됩니다. 우리가 흔히 알고 있는 kube-apiserver, kube-scheduler, kube-controller-manager 등이 여기에 포함됩니다.

kube-system 네임스페이스 내부 엿보기

실제로 kubectl 명령어를 통해 kube-system 네임스페이스를 확인해 볼까요?

Bash

# kube-system 네임스페이스의 포드 확인
kubectl get pods -n kube-system

 

[테스트 결과 예시]

Plaintext

NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-787d4945fb-2p8xm                   1/1     Running   0          5d1h
kube-system   etcd-k8s-master                             1/1     Running   0          5d1h
kube-system   kube-apiserver-k8s-master                  1/1     Running   0          5d1h
kube-system   kube-controller-manager-k8s-master        1/1     Running   0          5d1h
kube-system   kube-proxy-abcde                           1/1     Running   0          5d1h
kube-system   kube-scheduler-k8s-master                  1/1     Running   0          5d1h

(결과는 사용자 클러스터 구성에 따라 다를 수 있습니다.)

출력 결과를 보면, 클러스터 운영의 주축인 kube-apiserver, etcd, coredns 등이 kube-system 아래에 안정적으로 실행 중임을 확인할 수 있습니다.

---

2. kube-apiserver: 클러스터의 전면 게이트웨이

쿠버네티스의 모든 상호작용은 하나의 중앙 통신 허브를 통해 이루어집니다. 그 허브가 바로 **kube-apiserver**입니다.

kube-apiserver의 역할

• 유일한 접점: 외부 사용자(kubectl), 대시보드, 그리고 다른 내부 구성요소들이 클러스터와 상호작용하는 유일한 인터페이스입니다.
• 검증 및 보안: 모든 요청은 api-server를 통과하며 인증(Authentication), 인가(Authorization), 입학 제어(Admission Control) 단계를 거칩니다. 즉, 요청이 정당한지, 권한이 있는지, 클러스터 규칙에 맞는지 확인합니다.
• 상태 업데이트의 핵심: 사용자의 의도(예: "Pod 생성 요청")를 수신하고, 이 상태 변화를 유일한 저장소인 etcd에 업데이트하는 유일한 존재입니다. 다른 구성요소는 etcd에 직접 접근할 수 없습니다.

kube-apiserver 동작 예시: kubectl get pods

사용자가 kubectl get pods 명령을 실행할 때 어떤 일이 일어날까요?

1. 사용자 요청: kubectl은 API 서버로 REST 요청을 보냅니다.
2. 인증/인가: API 서버는 사용자의 신원을 확인하고 권한을 검사합니다.
3. 상태 조회: API 서버는 etcd에 저장된 현재 클러스터의 포드 정보를 조회합니다.
4. 응답: API 서버는 etcd로부터 받은 정보를 포맷하여 사용자에게 응답합니다.

모든 동작의 중심에 API 서버가 있음을 알 수 있습니다.

---

3. etcd: 클러스터의 유일한 공급원

쿠버네티스 클러스터의 모든 상태 정보(포드, 서비스, 배치, 노드 정보, 비밀 키 등)는 어디에 저장될까요? 바로 **etcd**입니다.

etcd의 역할

• 분산 키-값 저장소: etcd는 고가용성(High Availability, HA)을 제공하는 오픈소스 분산 키-값 저장소입니다. 쿠버네티스의 전용 데이터베이스라고 생각하면 됩니다.
• 상태 영속성: 클러스터에 배포된 모든 리소스의 "원하는 상태(Desired State)"와 "현재 상태(Current State)" 정보가 이곳에 영구적으로 저장됩니다. API 서버가 중단되어도 etcd 데이터가 남아있으면 클러스터 상태를 복구할 수 있습니다.
• 강력한 일관성 (Raft 합의 알고리즘): etcd는 Raft 합의 알고리즘을 사용하여 여러 노드에 데이터를 복제하고, 클러스터의 일관성을 보장합니다.

[Hands-on] etcd 내부 데이터 직접 들여다보기

일반적으로는 API 서버를 통해서만 데이터에 접근하지만, 실습을 위해 etcdctl 도구를 사용하여 etcd에 저장된 쿠버네티스 포드 정보를 직접 조회해 보겠습니다.

(주의: 운영 환경에서는 etcd를 직접 조작하지 마십시오.)

Bash

# etcdctl 명령어로 쿠버네티스 포드 리스트 조회
# API 서버를 통해 조회하는 것이 아니라, etcd 서버 자체에서 데이터를 꺼냅니다.
ETCDCTL_API=3 etcdctl get /registry/pods --prefix --keys-only

[테스트 결과 예시]

Plaintext

/registry/pods/default/nginx-deployment-74f4b9f698-pjkj8
/registry/pods/kube-system/coredns-787d4945fb-2p8xm
/registry/pods/kube-system/etcd-k8s-master
/registry/pods/kube-system/kube-apiserver-k8s-master
/registry/pods/kube-system/kube-controller-manager-k8s-master
/registry/pods/kube-system/kube-scheduler-k8s-master

결과를 보면, 우리가 API 서버를 통해 보았던 모든 포드 정보가 etcd 내부의 키-값 경로로 저장되어 있음을 알 수 있습니다. 이 경로 정보 자체가 쿠버네티스의 자산입니다.

---

4. 핵심 구성요소 상호작용: 포드 생성 워크플로우

이제 지금까지 배운 구성요소들이 어떻게 협력하여 사용자의 의도를 실현하는지, **"포드 생성 과정"**을 통해 통합적으로 이해해 보겠습니다.

포드 생성 단계별 워크플로우

1. 사용자 요청: 사용자가 kubectl apply -f pod.yaml 명령을 실행합니다. kubectl은 API 서버로 포드 생성 REST 요청을 보냅니다.
2. API 서버 수신 및 검증: kube-apiserver는 요청을 인증하고 인가합니다. 유효하면, **etcd**에 포드 리소스의 상태를 "Pending(보류 중)"으로 업데이트합니다.
3. kube-scheduler 관찰: 스케줄러는 API 서버를 통해 클러스터 상태를 지속적으로 관찰(Watching)합니다. "Pending" 상태의 포드를 발견하면 최적의 노드를 선택합니다.
4. 스케줄링 완료: 스케줄러는 선택된 노드 정보를 API 서버로 전송합니다. API 서버는 이 정보를 **etcd**에 업데이트합니다.
5. Kubelet 관찰: 해당 노드의 Kubelet은 API 서버를 관찰하다가 자신에게 할당된 새로운 포드를 발견합니다.
6. 포드 실행: Kubelet은 컨테이너 런타임에 명령하여 컨테이너를 실행하고, 포드 상태를 API 서버에 보고합니다. API 서버는 이 "현재 상태"를 **etcd**에 최종 업데이트합니다.

이 과정에서 **모든 데이터의 저장은 etcd**가, **모든 통신의 중심은 api-server**가 담당하고 있음을 알 수 있습니다.

 

(그림 1: 쿠버네티스의 핵심: kube-system, api-server, etcd 및 상호작용)

 

마무리하며: 클러스터의 안정을 위한 통찰 (Insights)

 

오늘 포스팅에서는 쿠버네티스의 심장부인 kube-system, api-server, etcd에 대해 깊이 알아보았습니다. 이 핵심 구성요소들에 대한 이해는 단순히 이론적인 지식에 그치지 않고, 실제 클러스터 운영 및 문제 해결에 중요한 통찰을 제공합니다.

 

1. etcd는 클러스터의 생명줄입니다: etcd의 데이터가 손실되면 클러스터는 모든 상태 정보를 잃게 됩니다. 운영 환경에서는 반드시 etcd를 고가용성으로 구성하고(최소 3개 노드), 주기적인 백업을 수행해야 합니다.

 

2. api-server는 보안의 첫걸음입니다: 모든 요청이 통과하는 유일한 관문이므로, API 서버에 대한 접근 제어는 쿠버네티스 보안의 가장 기초적이고 강력한 방법입니다.

 

3. kube-system은: 시스템의 안정성을 위해 kube-system 네임스페이스에는 절대로 사용자의 애플리케이션을 배포하지 마십시오.

쿠버네티스는 복잡해 보이지만, 그 핵심을 뚫고 들어가 보면 명확한 역할 분담과 논리적인 워크플로우를 가지고 있습니다.

이 근본적인 아키텍처를 이해하는 것이 쿠버네티스 마스터로 가는 첫걸음입니다.