쿠버네티스 구조와 핵심 개념

쿠버네티스란

쿠버네티스(Kubernetes, k8s)는 컨테이너의 배포·확장·복구를 자동화하는 오케스트레이터다. 사용자는 "이 이미지로 파드 3개"처럼 원하는 상태(desired state) 를 선언하고, 쿠버네티스는 실제 상태가 그와 다르면 계속 맞춘다. 파드가 죽으면 다시 띄우고, 노드가 사라지면 다른 노드에 옮긴다. 구글의 사내 시스템 Borg에서 나왔고 지금은 CNCF가 관리한다. 컨테이너와 오케스트레이션이 왜 필요한지는 VM과 컨테이너에 있다.

클러스터 구조

flowchart TB
  subgraph cp["컨트롤 플레인"]
    api["kube-apiserver"]
    api --- etcd["etcd (클러스터 상태 저장)"]
    api --- sch["kube-scheduler (파드 → 노드 배정)"]
    api --- cm["kube-controller-manager (상태 맞추기)"]
  end
  clients["kubectl, 다른 모든 구성 요소"] --> api
  cp ---|"API 호출"| w1["노드 1<br/>kubelet<br/>kube-proxy<br/>컨테이너 런타임<br/>파드 파드"]
  cp ---|"API 호출"| w2["노드 2<br/>kubelet<br/>kube-proxy<br/>컨테이너 런타임<br/>파드"]
  cp ---|"API 호출"| wn["노드 N<br/>..."]

운영 환경에서는 컨트롤 플레인을 여러 대에 나눠 두고 노드도 여러 대로 구성해 장애를 견딘다. 관리형 쿠버네티스(EKS·GKE·AKS)는 컨트롤 플레인을 클라우드가 맡는다.

구성 요소의 동작

kube-apiserver는 상태를 갖지 않는 REST 서버다. 요청 하나는 다음 단계를 거쳐 etcd에 저장되고, 저장된 변경은 watch로 구독 중인 컨트롤러·스케줄러·kubelet에 스트리밍된다. 여러 대를 띄워 로드 밸런서 뒤에 둘 수 있다.

flowchart TB
  a["요청"] --> b["인증<br/>누구인가: 인증서·토큰·OIDC"]
  b --> c["인가<br/>할 수 있나: RBAC"]
  c --> d["변경 어드미션<br/>기본값 주입, 사이드카 주입"]
  d --> e["스키마 검증"]
  e --> f["검증 어드미션<br/>정책 검사"]
  f --> g["etcd 저장"]
  g --> h["watch 중인 구성 요소에 이벤트 전달"]

인증·인가의 세부는 쿠버네티스 보안에 있다.

etcd는 Raft 합의로 복제되는 키-값 저장소다. 쓰기는 과반수(quorum)가 기록해야 확정되므로 멤버는 3·5대처럼 홀수로 두고, 3대면 1대, 5대면 2대 장애까지 견딘다. 과반수를 잃으면 클러스터 상태를 바꿀 수 없다(이미 떠 있는 파드는 계속 돈다). etcd에는 모든 오브젝트와 Secret이 들어 있어, etcd를 잃으면 클러스터 정의 전체를 잃는다. 그래서 정기 스냅숏 백업이 클러스터 복구의 마지막 수단이다. 백업·복구 명령은 쿠버네티스 운영에 있다.

kube-scheduler는 spec.nodeName이 빈 파드를 하나씩 골라 노드를 정한다.

후보가 하나도 없으면 파드는 Pending으로 남고, 우선순위가 높으면 낮은 파드를 밀어내는 선점(preemption)을 시도한다. 배치 조건을 거는 방법은 쿠버네티스 스케줄링과 자원 관리에 있다.

kube-controller-manager는 여러 컨트롤러를 한 프로세스로 묶어 돌린다.

cloud-controller-manager는 클라우드 API에 의존하는 컨트롤러를 따로 떼어 낸 것이다. LoadBalancer 서비스가 생기면 클라우드 로드 밸런서를 만들고(서비스 컨트롤러), 노드가 클라우드에서 사라졌는지 확인해 노드 오브젝트를 지우고(노드 컨트롤러), VPC 라우팅을 설정한다(라우트 컨트롤러). 클라우드마다 구현을 따로 두므로 쿠버네티스 본체에 클라우드별 코드가 없다.

kubelet은 API 서버에서 자기 노드에 배정된 파드 명세를 받아 CRI로 런타임에 컨테이너 생성을 맡기고, 프로브를 실행하고, 파드·노드 상태를 API 서버에 보고한다. 컨테이너가 죽으면 restartPolicy에 따라 다시 띄운다. API 서버 없이 노드의 매니페스트 디렉터리(/etc/kubernetes/manifests)만 보고 띄우는 스태틱 파드도 있는데, kubeadm은 컨트롤 플레인 구성 요소를 이 방식으로 띄운다.

CRI(Container Runtime Interface) 는 kubelet이 런타임을 부르는 gRPC 규격이다. 쿠버네티스 1.24에서 Docker 엔진용 어댑터(dockershim)가 제거되어, 지금은 CRI를 직접 구현한 런타임을 쓴다. Docker로 빌드한 이미지도 OCI 표준 이미지라 그대로 돈다.

두 런타임 모두 실제 컨테이너 생성은 runc 같은 OCI 저수준 런타임에 맡긴다. kube-proxy와 CNI는 쿠버네티스 네트워킹에 있다.

조정 루프: 쿠버네티스의 기본 동작

flowchart TB
  desired["원하는 상태<br/>(etcd에 저장된 선언)"] -->|"비교"| actual["실제 상태<br/>(노드가 보고)"]
  actual -->|"다르면"| act["컨트롤러가 행동<br/>(파드 생성·삭제·재시작)"]
  act -->|"다시 비교 (무한 반복)"| desired

명령형으로 "파드를 하나 띄워라"가 아니라 선언형으로 "파드는 3개여야 한다"고 쓰는 이유가 이 루프다. 이 원리를 사용자 정의 리소스로 넓힌 것이 아래 디자인 패턴의 컨트롤러·오퍼레이터 패턴이다.

구성 요소끼리는 서로 직접 부르지 않는다. 모두 API 서버를 통해 etcd의 상태를 읽고 쓰며, 자기가 맡은 오브젝트만 지켜본다(watch). 파드 하나가 뜨는 과정도 그렇다.

flowchart TB
  a["kubectl apply (Deployment)"] --> b["API 서버"]
  b --> c["etcd에 저장"]
  c --> d["Deployment 컨트롤러: #quot;ReplicaSet이 없네#quot;"]
  d -->|"ReplicaSet 생성"| e["ReplicaSet 컨트롤러: #quot;파드가 모자라네#quot;"]
  e -->|"노드 미지정 파드 생성"| f["스케줄러: #quot;노드 미지정 파드가 있네#quot;"]
  f -->|"자원·조건에 맞는 노드를 적어 넣음"| g["그 노드의 kubelet: #quot;내게 배정된 파드가 있네#quot;"]
  g --> h["런타임으로 컨테이너 실행, 상태 보고"]

새 기능을 넣어도 "상태를 지켜보고 맞추는 컨트롤러 하나"를 더하는 것으로 끝나는 구조라 확장이 쉽다.

왜 이렇게 복잡한가

쿠버네티스의 복잡함은 우연이 아니라 목표에서 나온다.

그래서 서비스 몇 개를 띄우는 정도라면 관리형 컨테이너 서비스(ECS, Cloud Run 등)나 PaaS가 더 단순할 수 있다(스타트업 인프라 선택 원칙).

파드와 워크로드 리소스

파드(Pod)는 쿠버네티스가 다루는 가장 작은 단위다. 컨테이너 하나 이상의 묶음으로, 파드 안 컨테이너들은 IP 하나와 네트워크 네임스페이스를 공유해 localhost로 통신하고 볼륨을 함께 쓴다. 파드는 언제든 죽고 새로 생기는 일회용이라, 직접 만들기보다 워크로드 리소스가 관리하게 한다. 컨테이너가 아니라 파드를 단위로 삼는 이유는 반드시 같은 노드에서 함께 떠야 하는 컨테이너 묶음(앱과 로그 전달기, 앱과 프록시)을 하나로 스케줄하고 수명·네트워크·볼륨을 공유시키기 위해서다. 보통은 파드 하나에 앱 컨테이너 하나를 두고, 보조 컨테이너만 곁들인다.

파드가 네트워크를 공유하는 방법: 파드마다 아무 일도 하지 않는 pause 컨테이너가 먼저 떠서 네트워크 네임스페이스를 만들고 쥐고 있다. 앱 컨테이너들은 그 네임스페이스에 합류하므로 IP와 포트 공간을 공유한다. 그래서 같은 파드 안의 두 컨테이너는 localhost로 통신하지만, 같은 포트를 둘이 열 수는 없다. 앱 컨테이너가 재시작돼도 파드 IP는 pause 컨테이너가 유지한다. 파드 네임스페이스는 veth 쌍으로 노드의 브리지에 연결되고, 노드마다 겹치지 않는 파드 대역을 받아 노드 사이 라우팅(또는 오버레이)으로 다른 노드의 파드와 통신한다. 이 배선은 CNI 플러그인(Calico, Cilium 등)이 맡는다. 네임스페이스와 veth의 원리는 리눅스 네트워크 네임스페이스와 ip 명령에 있다.

파드 생명주기, 프로브, 각 워크로드의 세부 설정은 쿠버네티스 워크로드와 파드 생명주기, 볼륨과 설정 주입은 쿠버네티스 저장소와 설정에 있다. 요청 경로에서 Service·HPA·Helm이 맡는 역할은 쿠버네티스 위 웹 서비스의 요청 경로에 있다.

서비스: 파드를 네트워크에 노출하는 네 가지 방법

파드 IP는 파드가 바뀔 때마다 달라진다. 서비스(Service)는 라벨로 고른 파드 집합 앞에 고정된 이름과 주소를 붙인다. spec.type이 노출 범위를 정한다.

ClusterIP ⊂ NodePort ⊂ LoadBalancer   (앞의 것을 포함하며 범위를 넓힌다)

• clusterIP: None으로 만든 헤드리스 서비스는 가상 IP 없이 DNS로 파드 주소를 직접 돌려준다. StatefulSet이 파드별 고정 이름을 얻는 방법이다.
• HTTP 호스트·경로 단위의 라우팅은 서비스가 아니라 Ingress나 Gateway API가 맡는다. 서비스가 패킷을 파드로 보내는 원리(kube-proxy), DNS, Ingress, NetworkPolicy는 쿠버네티스 네트워킹에 있다.

쿠버네티스 디자인 패턴

쿠버네티스 위에서 앱을 설계할 때 반복되는 해법을 네 묶음으로 나눈다. 『Kubernetes Patterns』(Bilgin Ibryam, Roland Huß)의 분류다.

자주 쓰는 kubectl 명령

# 클러스터·컨텍스트
kubectl config get-contexts                 # 연결할 수 있는 클러스터 목록
kubectl config use-context <이름>           # 대상 클러스터 바꾸기
kubectl get nodes -o wide                   # 노드 상태
 
# 조회
kubectl get pods -n <네임스페이스>           # -A면 모든 네임스페이스
kubectl get deploy,svc,ingress
kubectl describe pod <파드>                 # 이벤트까지 보여 줘 장애 원인 찾기의 출발점
kubectl get pod <파드> -o yaml              # 실제 적용된 명세
 
# 배포
kubectl apply -f manifest.yaml              # 선언한 상태로 맞추기
kubectl rollout status deploy/<이름>
kubectl rollout undo deploy/<이름>          # 직전 리비전으로 되돌리기
kubectl scale deploy/<이름> --replicas=5
 
# 디버깅
kubectl logs <파드> -c <컨테이너> -f --previous   # 직전에 죽은 컨테이너 로그
kubectl exec -it <파드> -- sh
kubectl port-forward svc/<서비스> 8080:80   # 로컬에서 클러스터 서비스 접속
kubectl get events --sort-by=.metadata.creationTimestamp
kubectl top pod                             # metrics-server 필요
 
# 설정
kubectl create configmap app-config --from-file=config.yaml
kubectl create secret generic db --from-literal=password=...

배포판과 관리형 서비스

쿠버네티스는 모든 것을 갖춘 PaaS가 아니다. 컨테이너를 배치하고 살려 두는 핵심만 제공하고, 소스 코드를 이미지로 만드는 빌드, 앱 카탈로그, 로그·모니터링·알림, 기술 지원은 들어 있지 않다. 이 빈칸을 채워 묶은 것이 배포판(distribution)과 관리형 서비스다.

OpenShift의 커뮤니티 업스트림은 OKD다(과거 이름은 OpenShift Origin). GKE는 처음 Google Container Engine이라는 이름으로 나왔다가 Google Kubernetes Engine으로 바뀌었다. 직접 설치든 관리형이든 위 빈칸을 플랫폼 팀이 채워 개발자에게 내미는 것이 플랫폼 엔지니어링이다.

컨테이너 전용 OS

노드에 올라가는 OS도 컨테이너에 맞춰 줄어들었다. 시작은 CoreOS Container Linux(2013)였다. 패키지 관리자 없이 앱을 모두 컨테이너로 돌리고, etcd·systemd·fleet으로 클러스터를 이뤘다.

CoreOS사는 2018년 Red Hat에 인수됐고 Container Linux는 2020년 5월 지원이 끝났다. 뒤를 Fedora CoreOS, OpenShift 노드용 RHEL CoreOS, 포크인 Flatcar Container Linux가 잇고, AWS Bottlerocket, 쿠버네티스 전용 Talos Linux도 같은 계열이다. 같은 생각은 불변 인프라를 OS 단위로 적용한 것이다.

생태계 지도

쿠버네티스 자체는 핵심 기능만 갖고, 나머지는 플러그인과 주변 도구가 채운다. 구성 요소가 100개가 넘어 원소 주기율표처럼 정리한 지도가 있을 정도다. 도구 이름은 자주 바뀌므로 범주로 기억하고, 범주마다 무엇이 필요한지에서 출발해 고른다.

역사

etcd도 바뀌었다. 초기 v2 API는 디렉터리형 키와 TTL(etcdctl set /foo bar --ttl 60, ls)을 썼고, 지금의 v3는 평평한 키 공간에 접두사 조회(etcdctl put, get --prefix, watch)와 TTL 대신 리스(lease)를 쓴다. v2 API는 제거됐다. 초기 클러스터는 discovery.etcd.io 토큰으로 서로를 찾아 형성했다.

정리

• 쿠버네티스는 원하는 상태를 선언받아 조정 루프로 계속 맞추는 시스템이다.
• 컨트롤 플레인은 API 서버를 중심으로 etcd·스케줄러·컨트롤러가 돌고, 노드에서는 kubelet·kube-proxy·런타임이 일한다.
• 파드는 일회용이다. 워크로드 리소스가 관리하고, 서비스가 고정 주소를 준다.
• 서비스 유형은 ClusterIP → NodePort → LoadBalancer 순으로 노출 범위를 넓히고, ExternalName은 외부 이름을 가리킨다.
• 설계는 프로브·자원 선언 같은 기초 패턴부터 지킨다. 그래야 플랫폼이 자동으로 관리할 수 있다.

관련 노트: VM과 컨테이너, 쿠버네티스 워크로드, 쿠버네티스 네트워킹, 쿠버네티스 스케줄링과 자원 관리, 쿠버네티스 보안, 쿠버네티스 운영, 쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소, 배포 전략, 관측 가능성: 로그, 트레이스, 메트릭, 리눅스 네트워크 네임스페이스와 ip 명령