이번 포스트에서는 쿠버네티스의 기본적인 리소스와 아키텍처에 관해 공부한다.

  • Architecture, Minikube, kubectl, Namespace, Pod

 

Architecture

공식 문서에서 설명하는 Kubernetes Architecture

 

쿠버네티스는 크게 클라우드의 전체적인 리소스를 관리하는 Control Plane, 실제 서비스가 동작하는 Node Plane으로 구성되어 있다. 두 부분을 합쳐 클러스터로 구성한다. 참고로 Control Plane, Node Plane 각각 클러스터로 구성할 수 있다.

Controle Plane과 Node Plane 각각에 대해 알아보자.

 

📍 Control Plane Component

클러스터를 관리하는 컴포넌트 집단이다. 여러 대의 컴퓨터가 합쳐져서 각각의 컴포넌트를 실행한다.

컨트롤 플레인 컴포넌트를 실행하는 여러 대의 컴퓨터는 노드로써 실행되지는 않는다. 각각의 컴포넌트는 다음과 같다.

 

 

1️⃣ kube-apiserver

  • 쿠버네티스 클러스터를 진입하기 위한 API 서버. 클러스터의 프론트엔드이다.
  • 다른 사용자들이 클러스터에 관해 정보를 얻고 싶을 때 이용하는 API 서버다.
  • kube-apiserver는 수평적으로 (수평적 확장, 기기의 대수를 늘린다.) 확장되도록 설계되었다. (AWS auto-scaling)

 

2️⃣ etcd

  • 모든 클러스터의 데이터를 담는 뒷단의 저장소로 키-값 저장소이다.
$ etcdctl --endpoints=$ENDPOINTS --write-out="json" get foo
{"header":{"cluster_id":289318470931837780,"member_id":14947050114012957595,"revision":3,"raft_term":4,
"kvs":[{"key":"Zm9v","create_revision":2,"mod_revision":3,"version":2,"value":"SGVsbG8gV29ybGQh"}]}}
$
  • etcd도 클러스터로 구성할 수 있다.

 

3️⃣ kube-scheduler

  • 어느 pod가 어느 node에서 실행할지 결정해주는 컴포넌트, 실행을 담당하는 건 아니고 그냥 이름표만 붙여주는거다.
  • 이 작업을 하기 위해선 모든 노드의 컴퓨팅 자원 현황에 대한 정보가 있어야 한다.
    • 각 노드들의 자원 현황을 확인한 다음 점수를 매겨 최적의 노드를 설정한다.

 

4️⃣ kube-controller-manager

  • Cloud Controller Manager랑 헷갈릴 수 있는데, 얘는 클러스터 안의 자원과 모든 데이터를 관리하는 컴포넌트다.
    • 노드 컨트롤러: 노드가 응답이 없으면 상태를 확인하고 대응한다.
    • 레플리케이션 컨트롤러: 파드(Pod)의 개수가 설정한 대로 유지되는지 감시한다.
    • 엔드포인트 컨트롤러: 서비스(Service)와 파드를 연결한다.
    • 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
  • 어느 노드가 죽었는지, 어느 노드가 살아있는지, 전체 노드 클러스터에서 원하는 수의 pod가 살아있는지, Service에 대한 파드가 연결되어 있는지 등을 확인한다.
  • 클러스터 내부에 총 책임자라 할 수 있다.

5️⃣ cloud-controller-manager

  • 외부 클라우드 서비스 (AWS, GCS 등)과 통신하는 외부 관리용 컴포넌트이다.
  • 클라우드 환경에서 노드가 실제로 살아있는지 확인한다.
  • 클라우드 네트워크 인프라에 경로를 설정한다.
  • 로드밸런서를 자동으로 프로비저닝한다.

⇒ KCM과 CCM은 동시에 돌아갈 수 있다! 클라우드 환경에서 쿠버네티스를 실행한다면, KCM이 CCM에게 자신의 역할을 일부 위임한다.

  • KCM → 쿠버네티스 본연의 기능 : 파드의 갯수, 노드의 헬스 체크, 토큰 발행
  • CCM → 클라우드 API랑 통신해서 리소스 관리

AI가 설명한 CCM, KCM 역할 비유

 

 

 

📍 Node Plane Component

노드 단에서 실행되는 컴포넌트이다. 서비스 서버나 서비스에 필요한 여러 리소스의 실행과 관리를 담당한다.

노드는 하나의 컴퓨터이다. CPU, RAM, SSD 등의 물리적인 자원을 가진 실제 컴퓨터이다. 이 노드 안에 수십, 수백개의 Pod들이 실행된다.

 

1️⃣ kubelet

  • 쿠버네티스의 모든 노드에서 실행되는 컴포넌트, 참고로 노드도 클러스터로 구성할 수 있다.
  • 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
  • 각 노드나 컴포넌트가 살아있음을 확인하는 과정을 ‘헬스 체크’라고 하는데, 각 파드들이 잘 생성되어 있는지 헬스 체크를 한 다음, 이를 api-server로 보내 데이터를 저장한다.
    • 이로 인해 etcd에 관련 데이터가 쌓이게 되고, 컨트롤 플레인에서 각 노드와 파드들에 대한 정보를 볼 수 있게 된다.

 

2️⃣ kube-proxy

  • 이를 이해하기 위해선 Service를 알아야 한다.
    • Service는 etcd에 저장된 각 노드들의 주소를 담는 객체다.
    • 사용자가 Service IP로 요청을 보내면, 컨트롤 플레인은 Service 객체를 확인해 적절한 내부 IP로 요청을 보내게 된다.
    • 전화번호부를 생각하면 쉬울 것이다.
  • Proxy는 Service의 요청을 받는 노드의 가장 앞단이다.
    • 네트워크의 NAT를 생각하면 쉬울 것이다, 얘가 L4 로드 밸런서이다.
    • 여기서 모든 네트워크 처리를 담당한다.
    • 또한 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의 추가와 제거를 감시한다.

⇒ 참고로 모든 노드가 kube-proxy를 갖추고 있으며 DNAT(분산형 NAT)처럼 행동한다.

 

네트워크 NAT 도식

 

 

 

Minikube & Kubectl

Minikube는 규모가 큰 Kubenetes 리소스를 로컬에서 돌려볼 수 있게 구성한 가상의 클러스터이다.

 

 

1️⃣ Minikube

  • 로컬 컴퓨터에서 쿠버네티스를 실행할 수 있게 구성한 가상의 클러스터이다.
    • 1개의 노드 클러스터와 1개의 컨트롤 클러스터로 구성된다.
    • 쿠버네티스 미니어처라고 생각하면 된다.

 

2️⃣ kubectl

  • 사용자가 api-server 보내기 위해 작성하는 bash창이다.
  • 명령어 칠 때 치는 거라고 보면된다. 더 깊게 들어가면 사용자가 쿠버네티스 클러스터에 접속하기 위한 인터페이스이다.

 

 

Namespace

클러스터 안에서 설정하는 가상의 클러스터이다. 컴퓨터로 따지면 폴더 정도?

네임스페이스 기반 오브젝트(Deployment, Service)에만 적용가능하며, 클러스터 범위 오브젝트(Storage Class, Node, PV)에는 적용이 불가능하다.

 

1️⃣ Namespace와 DNS

  • Namespace를 할당하면 DNS가 생성된다.
  • Kubectl에서 DNS를 통해 사용자가 네임스페이스 오브젝트에 명령을 보낼 수 있게 된다.
    • DNS 엔트리는 꼭 RFC 1123 DNS 레이블의 형식을 지켜야 한다.
    • FQDN

 

 

💡 접근 방식

  • 하나의 노드 클러스터에 여러 개의 네임스페이스가 존재할 수 있다. 이럴 때 각 노드나 Pod 컴포넌트에 어떻게 접근할 수 있는지 살펴보자.
  • 예를 들어, 서비스명이 동일하지만, Namespace가 다르다면 어떻게 접근할 수 있는지 구상할 수 있다.
모든 주소를 전부 적을 수도 있고 아니면 부분적으로만 적을 수 있다.

1. $ curl {서비스명}.{네임스페이스명}.svc.cluster.local:{포트}
2. $ curl {서비스명}.{네임스페이스명}.svc:{포트}
3. $ curl {서비스명}.{네임스페이스명}:{포트}
4. $ curl {서비스명}:{포트}
    • 1번은 FQDN이 사용되는 예시이다. 풀 주소를 적고 해당 컴포넌트로 요청을 보낸다.
    • 2, 3, 4 번은 Domain Chain이 사용되는 경우다. 이 경우 도메인 서버를 이용해 적절한 FQDN 주소로 바꿔 전송하게 된다.

 

 

Pod

쿠버네티스의 가장 작은 배포 단위이자 관리 단위다. 쿠버네티스는 컨테이너를 하나의 단위라고 보지 않는다.

단일 컨테이너 및 컨테이너 묶음이 하나의 Pod가 될 수 있으며 하나의 Pod를 공유하는 컨테이너들은 같은 IP, 같은 볼륨(저장소)를 가지게 된다.

공식 문서에서 설명하는 Pod 사진

 

 

Pod를 구성하는 하나의 예시



💡 Probe

  • 노드 컴포넌트 Kubelet이 각각의 컨테이너가 잘 작동하고 있는지 전송하는 컨디션 체크
  • 전에 컨트롤 컴포넌트 클러스터에서 노드가 api-server에게 자신이 살아있음을 알리는 신호를 보냈는데 그거랑 같다.
  • Probe는 노드 컴포넌트 kubelet이 pod 안에서 실행되고 있는 각각의 컨테이너가 살아있는지 요청을 보내는 것이다.

'DevOps > Kubernetes' 카테고리의 다른 글

[Kubernetes] Labels & Selectors  (0) 2026.04.08
[Kubernetes] 쿠버네티스 네트워크 개요(CNI, Pod-to-Pod, Service, Ingress)  (0) 2026.03.30

티스토리툴바