[Kubernetes] Kubernetes(K8s)에서 Pod가 생성될 때 내부동작

출저 : https://kubernetes.io/docs/concepts/architecture/

Pod가 생성될 때 내부동작

쿠버네티스에서 pod가 생성될 때 내부적으로 어떤 과정이 진행되는지 이해하는 것은 중요합니다. 사용자가 pod 생성을 요청했을 때 kuberntes 클러스터 내부에서 어떤 동작이 수행되는지 단계별로 알아보겠습니다.

 

 

Pod 생성 과정 (요청흐름)

1. 사용자가 kube-apiserver에 요청(Authenticat user)

• 사용자는 kubectl apply -f pod.yaml 또는 API 요청을 통해 pod 생성을 요청합니다.

curl -X POST /api/v1/namespaces/default/pods -d '{...}'

kube-apiserver는 Kubernetes 클러스터의 중심 API 엔드포인트이며, 모든 요청을 관리합니다. 이때 사용자 인증 및 권한부여 단계를 수행합니다.

 

2. API 서버가 요청을 검증 (Validate Request)

• kube-apiserver는 요청이 올바른 포맷인지 확인하고, RBAC(Role-Based Access Control) 등의 정책을 적용하여 사용자가 해당 작업을 수행할 수 있는지 검증합니다.

3. etcd에서 기존 데이터를 조회 (Retrieve Data)

• kube-apiserver는 etcd에서 현재 상태를 가져오고, etcd는 Kubernetes의 분산 Key-Value 저장소로, 모든 클러스터 상태 정보를 저장합니다.
• 새로운 Pod가 추가되기 전에 현재 클러스터 상태와 비교하여 충돌이 없는지 확인합니다.

4. etcd 업데이트 (Update ETCD)

• 요청이 검증되면 kube-apiserver는 etcd에 새로운 Pod 객체를 저장합니다.
• 이때 etcd에 새로운 pod를 만든다고 선언했기 때문에 쿠버네티스는 새로운 pod가 있어야 한다는 것을 인지합니다.
• 이렇게 원하는 상태로 만드는것을 Desired State 라고 합니다.

5. 스케줄러가 적절한 워커 노드를 선택 (Scheduler)

• 업데이트된 데이터를 확인하고, 새로 생성된 Pod가 어떤 워커 노드(Worker Node)에 배치될지 결정합니다.
• 스케줄링 기준은 노드의 리소스(cpu, 메모리), 노드의 taint/tolerations, affinity 규칙를 고려해서 결정됩니다.

6. 선택된 노드의 Kubelet이 Pod를 실행 (Kubelet)

• kubelet은 해당 워커 노드에서 실행되는 에이전트로 kube-apiserver에서 전달받은 정보를 바탕으로 컨테이너 런타임(Docker, containerd)을 사용하여 Pod를 실행합니다.
• 즉, kubelet은 스케줄러가 선택한 노드에서 컨테이너를 생성하고 실행하는 역할을 합니다.

 

예제

# 1. Pod를 정의한 YAML 파일 생성
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: default
spec:
  containers:
  - name: mycontainer
    image: nginx
EOF

# 2. kubectl을 사용해 Pod 생성 요청
kubectl apply -f pod.yaml

 

위 명령어를 실행한다면 간단하게 아래와 같이 실행됩니다.

1. kubectl -> kubeapiserver로 요청전송

2. api 서버가 요청을 검증

3. etcd에서 데이터 조회 후 etcd 업데이트

4. 스케줄러가 노드를 선택

5. 선택된 노드에서 kubelet이 pod를 실행

 

쿠버네티스에서 단순히 kubectl apply -f 명령어를 실행하는 것만으로도 쿠버네티스 백엔드에서는 복잡한 과정이 진행됩니다.

핵심 아키텍처

 

쿠버네티스의 핵심 아키텍처는 Declarative  방식, 스케줄링, 분산아키텍처를 사용하는 것입니다.

1. Declarative 방식

• 사용자는 “이런 상태를 원한다"고 선언하면 Kubernetes가 이를 만족하도록 조정합니다.
• etcd는 클러스터의 현재 상태(Current State)와 원하는 상태(Desired State)를 저장하며, 컨트롤러들이 이를 자동 조정합니다.

2. 자동화된 스케줄링 및 배포

• 관리자가 직접 노드를 선택하는 것이 아니라 스케줄러가 자동으로 최적의 노드를 선택합니다.

3. 분산 아키텍처

• etcd를 통해 클러스터의 모든 상태를 저장하고 관리합니다.
• kube-apiserver는 클러스터의 모든 요청을 처리하는 중앙 허브 역할을 합니다

 

결론 및 추가정보

Kubernetes를 설치할 때 kubeadm을 사용했다면 kube-apiserver-master Pod가 실행되는 것을 확인할 수 있습니다. 또한 해당 Pod를 정의하는 매니페스트 파일은 /etc/kubernetes/manifests/kube-apiserver.yaml에 위치해 있습니다. 이를 직접 수정하면 API 서버의 설정을 변경할 수도 있습니다.

 

정리하자면, kubernetes는 kube apiserver에 Pod 생성요청을 받으면 권한 검증을 마치고, etcd를 확인하고 업데이트합니다. 원하는 상태를 선언하면 kube-Scheduler가 적절한 노드에 pod를 생성하라고 요청하고, 이를 kubelet이 받아 컨테이너 런타임 엔진(docker, containerd)를 사용하여 최종적으로 pod를 생성하게 됩니다.

 

**참고자료**

https://kubernetes.io/docs/concepts/architecture/

https://kubernetes.io/docs/concepts/workloads/pods/

https://velog.io/@neity16/핵심만-콕-쿠버네티스-2-k8s-기본-개념