k8s Pod 생성 과정 정리

1. 사용자가 Deployment, Pod 생성 요청 (kubectl, API call)

2. API Server가 요청을 받아 etcd에 저장 (클러스터 상태 반영)

3. Scheduler가 적절한 노드를 선택하여 Pod 배치

4. kubelet이 해당 노드에서 Pod 실행 요청 처리 (이 요청은 gRPC 프로토콜을 통해 전달됨)

5. CRI(Container Runtime Interface)를 통해 containerd와 통신

   CRI는 Kubernetes가 Container Runtime(여기서는 containerd)와 통신할 수 있도록 해주는 인터페이스. CRI-containerd는 이 인터페이스를 통해 containerd에 요청을 전달하여 컨테이너 실행을 요청

6. containerd는 먼저 sandbox container(보통 pause 컨테이너)를 생성하여 Pod의 네트워크 및 기본 환경을 설정

   • Pod 내부 컨테이너들이 동일한 네트워크를 쓰게 하려면, 네트워크 네임스페이스를 공유해야 함. 이 역할을 하는 것이 바로 sandbox 컨테이너
   • Pod 내부 컨테이너들은 이 sandbox 컨테이너의 네트워크를 공유하게됨

7. CNI(Container Network Interface)를 통해 네트워크 설정 (sandbox container에 적용)

   • CNI는 네트워크 설정을 담당하는 플러그인. sandbox 컨테이너에 IP 할당, 네트워크 라우팅 등을 설정하여 Pod 내부의 컨테이너들이 동일한 네트워크를 공유하도록 함

8. containerd가 OCI Runtime(runc)을 사용하여 애플리케이션 컨테이너 실행

   • runc는 컨테이너를 실제로 실행하고 관리하는 역할을 함

9. cgroup, namespace를 사용해 컨테이너 격리

10. 모든 컨테이너가 정상적으로 실행되면 Pod가 Ready 상태가 됨

컴포넌트	역할 및 기능
kubelet	- 해당 노드에서 Pod 실행을 관리하는 Kubernetes 에이전트- API Server로부터 Pod 실행 요청을 받고, 컨테이너 런타임(containerd 등)에게 컨테이너 실행 요청을 전달
CRI (Container Runtime Interface)	- kubelet과 컨테이너 런타임(containerd, CRI-O 등) 간의 표준 API 인터페이스- Kubernetes가 다양한 컨테이너 런타임을 지원할 수 있도록 설계됨
CRI-containerd	- containerd가 CRI 요청을 처리할 수 있도록 지원하는 플러그인- kubelet이 CRI를 통해 컨테이너를 실행할 수 있도록 함
OCI (Open Container Initiative)	- 컨테이너 런타임 및 이미지 포맷을 표준화하는 조직- runc, crun 같은 실행 환경을 제공
CNI (Container Network Interface)	- 컨테이너의 네트워크 설정을 담당하여 Pod 간 통신을 가능하게 함- Calico, Flannel 같은 네트워크 플러그인 사용
gRPC	- kubelet과 containerd가 통신할 때 사용하는 RPC(Remote Procedure Call) 프로토콜
containerd client	- kubelet이 containerd에게 컨테이너 생성/삭제 요청을 하는 클라이언트
cgroup	- 컨테이너의 CPU, 메모리 등 리소스를 제한 및 관리
namespace	- 컨테이너마다 격리된 실행 환경을 제공하여 다른 컨테이너와 분리
sandbox container	- Pod 내 네트워크 및 보안 환경을 설정하는 컨테이너 (pause 컨테이너)