k8s (2) | elecbrandy

2026.03.21

k8s (2)

🦋 SKALA: SK AX AI Leader Academy

1. 소개

k8s의 내부 동작을 공부해보자.

사용자가 작성한 코드가 어떻게 실제 서버(노드)까지 도달하는지 흐름을 알아보자

1단계: 사용자 및 앱 정의(App Descriptor)
- 사용자가 원하는 상태(Pod 개수, 사용할 이미지 등)를 YAML 파일로 작성
- 보라색/주황색 도형들은 서로 다른 종류의 컨테이너 이미지를 의미
2단계: 이미지 레지스트리(Image Registry)
- 사용자가 빌드한 컨테이너 이미지들을 저장소(Docker Hub 등)에 업로드
- 나중에 워커 노드들이 여기서 이미지를 받아오게 됨
3단계: 컨트롤 플레인(Control Plane)
- 사용자가 보낸 YAML 파일을 받아 “누가, 어디서 실행될지” 전체적인 지휘를 내림
4단계: 워커 노드(Worker Nodes) 배포
- 컨트롤 플레인의 명령에 따라 여러 대의 워커 노드에 작업이 분산됨
  - kubelet 마스터와 소통하며 명령을 수행
  - kube-proxy 네트워크 통신을 담당
  - docker 실제 컨테이너를 실행
5단계: Pod와 컨테이너 구성
- 한 Pod 안에 여러 컨테이너가 묶여서 실행될 수 있음

마스터 노드 내부의 컴포넌트들의 서로 통신 구조를 알아보자

1~2단계: Deployment 생성 및 감지
- kubectl 명령이 API Server에 전달되어 Deployment 오브젝트가 생성
- Controller Manager는 Watch 기능을 통해 이를 감지
3~4단계: ReplicaSet 생성
- Deployment 컨트롤러가 Pod를 관리할 ReplicaSet이 필요해! 라고 판단
- API 서버를 통해 이를 생성
5~6단계: Pod 생성 및 대기
- ReplicaSet 컨트롤러가 정의된 개수만큼 Pod 오브젝트를 생성
- 이때 Pod는 아직 어느 노드에 갈지 정해지지 않은 Pending 상태
7단계: 스케줄링(Scheduler)
- Scheduler가 주인 없는 Pod가 있네? Node X가 널널하니까 거기로 보내자! 라고 결정
8단계: 노드로 통지(kubelet)
- 배정된 노드의 kubelet이 API 서버를 지켜보다가…
- 내 노드에 Pod A를 띄우라는 명령이 왔네? 라고 확인
9~10단계: 실제 컨테이너 가동
- kubelet이 노드 내의 containerd/cri-o에게 명령
- 이미지를 다운로드하고 Container를 실제로 실행하게 시킴

k8s는 RBAC를 통해 접근을 관리
- RBAC(Role-Based Access Control, 역할 기반 접근 제어)
- 누가(Subject), 어떤 리소스(Resource)에, 어떤 권한(Verb)을 가질 것인가?
핵심 구성 요소 (누가, 무엇을, 어떻게?)
- k8s Resource
  - 접근 대상 -> Pod, Service, Secret 등
- 권한 목록
  - Role -> namespacse 안에서만 통하는 신분증
  - ClusterRole -> 클러스터 전체에서 통하는 프리패스권
- Binding
  - 특정 사용자나 서비스 계정에 역할을 묶어주는 역할
- Service Account (사용자)
  - 실제 접근을 시도하는 주체
  - 사람이 쓰는 계정 또는 Pod 안에서 돌아가는 프로그램일 수도 있음
이렇게 복잡하게 나누는 이유?
- 사용자에게 직접 너는 Pod를 볼 수 있어라고 권한을 주는 것이 아니라, 역할이라는 중간 단계를 두는 이유는 관리가 편하기 때문
- 간단한 예시
  - 회사(클러스터)에 신입사원이라는 역할(Role)을 미리 만들자 (Pod 읽기 권한만 포함)
  - 새로운 사람이 올 때마다 일일이 권한을 주는 게 아니라, 그 사람을 신입사원 역할에 바인딩만 시켜주면 끝
  - 나중에 신입사원의 권한을 바꾸고 싶다면? 한 명씩 고칠 필요 없이 신입사원 Role 하나만 수정하면 모두에게 적용

사용자가 설정한 Replicas 개수를 확인하고, 부족하면 새로 만들고 많으면 삭제하여 항상 원하는 개수를 유지함
각 Pod는 서로 다른 이름과 고유 IP를 가지며, 사용자는 3개의 Pod IP를 일일히 알 필요 X
대표 입구인 Service 의 IP로만 요청을 보내면, 서비스가 알아서 3개의 Pod에 요청을 골고루 분산(Load Balancing)함