Kubernetes

Kubernetes Cluster & Nodes

id1112 2025. 4. 14. 15:30

1.Cluster

Kubernetes는 여러 대의 서버들을 묶어서 Cluster 형태로 구성한다. Kubernetes는 Cluster 내부의 Node들을 효율적으로 관리하면서 애플리케이션을 실행하고 트래픽 분산, 스케일링, 장애 복구와 같은 기능들을 자동을 지원한다.

Kubernetes Cluster는 여러 대의 서버를 하나로 묶어 컨테이너를 효율적으로 배포, 실행, 관리할 수 있도록 만드는 환경이다. 클러스터 내부에는 애플리케이션 실행을 담당하는 Worker Node 와 Cluster 자체를 제어하는 Control Plane 이 포함된다.

 

Kubernetes Cluster의 주요 특징은 다음과 같다.

1) High Availability

여러 노드를 운영해 장애에 대응할 수 있으며, Node 중에 일부가 장애가 발생하더라도 나머지 노드에서 애플리케이션이 계속해서 동작할 수 있다.

2) Auto Scaling (clustser autoscaler)

Kubernetes 에는 두 가지 대표적인 Auto Scaling 이 있는 데 이는 Pod Scaling (HPA) 와 Node Scaling (Cluster Autoscaler)이다.

HPA 는 CPU 사용량이나 Custom Metrics 등을 기준으로 리소스 사용량에 따라 동일한 애플리케이션 Pod 를 여러 개로 늘리거나 줄이는 기능인데, 이 때 내부 리소스가 충분이 있다는 가정을 바탕으로 하고 있다.

Cluster Autoscaler는 클러스터 내에 Node 의 수(VM, 서버) 의 수를 자동으로 늘리거나 줄이는 방식으로 일반적으로 클라우드 환경과 연동해서 필요 시 새로운 VM 을 추가하거나 줄이는 방식으로 동작한다.

그래서 위의 두 가지 Auto Scaling 방식은 병행해서 같이 사용하는 데 HPA 를 통해 트래픽 처리 능력을 자동으로 조절할 때 Cluster 가 이미 충분한 Node 자원을 가지고 있어야 안정적으로 Pod 를 늘릴 수 있다. 하지만 이때 필요한 Pod 에 비해 Cluster Resource 가 부족하게 되면 Cluster Autoscaler를 통해 자동으로 AWS EKS 등과 연동해서 VM을 동적으로 추가 및 삭제하는 방식으로 필요한 Cluster Node 를 추가 및 삭제한다.

3) Self - Healing

장애가 발생한 Node를 감지해 해당 Node에서 실행하던 Pod를 자동으로 Reschedule 해 다른 Node에서 애플리케이션이 계속 실행되게 한다.

Self Healing 은 여러 계층에서 동작한다.

- Node Level

Kubernetes Control Plane 에서는 각 Node 에 kubelet 이 주기적으로 Hearbeat(상태 보고)를 한다.

일정 시간 동안 Node 에서 응답이 없는 경우(보통 기본적으로 40초 내외이다.) Kubernetes는 해당 node를 NotReady 혹은 Unreachable 상태로 간주한다.

해당 Node 에서 실행 중이던 Pod들이 정상적으로 동작한다고 볼 수 없으며 ReplicaSet, StatefulSet 등 Controller 가 감지 후 다른 정상적인 Node 에서 새로운 Pod를 생성한다. 이 과정을 통해 장애가 있는 Node 에서 실행되던 Workload를 자동으로 복구한다.

Node Level는 Hearbeat 감시를 통해 감지되고 Node 가 죽으면 Reschedule를 진행해 Self Healing 을 수행하는 것이다.

 

- Pod Level

Liveness Probe / Readiness Probe

livenessProbe 가 실패하면 kubelet 이 해당 Pod를 재시작한다.

readinessProbe가 실패하면 Service Load Balancing 대상에서 제외되어 트래픽으 들어가지 않게 된다.

 

이처럼 Self Healing 은 Node Level + Pod Level 모두 관여한다.

 

4) Scalability

Kubernetes는 수십, 수백 대 이상의 노드가 붙어 있는 대규모 환경에서도 동일한 사용자 경험과 운영 방식을 유지할 수 있도록 설계되어있다.

왜 kubernetes가 대규모 환겨에서 동일한 사용자 경험과 운영 방식을 유지할 수 있는 것일까?

- 분산 아키텍쳐와 Control Plane 구조

 

- Worker Node 구조와 동작

node를 유연하게 추가 및 삭제가 가능하고 각 Node가 독립적으로 동작한다.

 

- Watch와 Event 기반 메커니즘으로 부하 최소화

Kubernetes는 내부적으로 Event 와 Watcher 방식으로 작동한다.

 

- Controller 기반의 유연한 확

2. Node

Kubernetes 에서 Node는 애플리케이션 Pod가 실제로 실행되는 서버를 의미한다.

보통 Worker Node라고 부르면 실제 Workload를 수행한다. 컨테이너 실행환경(Runtime)과 kubelet( Kubernetes agent)

kube-proxy (network proxy) 등 필수적인 component들이 동작한다.

 

2.1  Node의 구성 요소

1) Conatiner Runtime

Docker, containerd, CRI-O 등 컨테이너를 실행 및 관리하는 Software 이다. Kubernetes 가 Pod Deployment 명령을 내리면 이 runtime이 실제로 container를 생성하고 실행한다.

 

2) kubelet

Node에서 동작하는 핵심 Agent 이다. 컨테이너 생성, 모니터링, 라이프사이클 관리 등을 수행한다.

Control Plane 과 통신하면서 노드에 대한 정보를 주고 받는다.

 

3) kube-proxy

Kubernetes의 Service(service discovery & Load Balancing)을 지원하기 위한 Network Proxy

Node로 들어오거나 나가는 트래픽을 적절한 pod 로 Routing 해준다.

 

4) Node 구성 파일 & Metadata

Node에는 Host OS, CPU/memory, Network Interface, Disk 등 Resource Information 이 있다.

Node는 Kubernetes API에 자신의 상태 (Ready State, 사용가능한 리소스, OS version 등)을 보고하고 스케줄러는 이를 참고하여 Pod 배치를 결정한다.

 

2.2 Node work flow

1) Control Plane 이 "어떤 Pods를 어느 노드에 배치할지" 결정한다.

2) 배치 명령이 떨어지면 해당 Node의 kubelet이 이를 감지해 Container Runtime 에게 Pod를 생성하라고 요청한다.

3) 새로 생성된 Pod는 Service와 연동되어 kube-proxy를 통해 외부 혹은 다른 pod로부터의 트래픽을 받는다.

4) Node state나 Pod state에 이상이 생기면 kubelet은 이를 Control Plane에 보고하고 필요하다면 Pod가 다른 Node로 다시 Scheduling 한다.

 

3. Control Plane 

Control Plane 은 Cluster 를 제어하고 관리하는 핵심 Component의 집합을 말한다. 

Contorl Plane이 각 Node 에게 무엇을 실행하지 지시하고 Cluster State를 모니터링 및 조정하며 사용자의 명령을 받아 Cluster 에 반영하는 역할을 한다.

 

3.1 Control Plane 의 workload

1) Cluster State 유지 및 관리

어떤 Pod를 어느 Node 에서 몇 개를 실행하지, 현재 Node 나 Pod 상태가 정상인지 사용자가 원하는 Desired State (목표 상태)에 맞춰 실제 상태를 조정한다.

2) 사용자 요청 처리

kubectl apply, kubectl create 같은 요청이 들어오게되면 Control Plane의 API Server 가 이를 받아서 Cluster Resource 를 생성, 수정 그리고 삭제를 한다.

3) 분산 스케줄링

Pod들이 어디서 실행될지를 결정하고 Node Resource 부족 등 문제가 있을 경우 대안을 찾는다.

4) Node 와 지속적으로 통신

각 Node에 설치된 kubelet 과 통신하며 Node나 Pod 의 상태를 보고 받고 이상이 생기면 Reschedule 등의 복구를 수행한다.

 

3.2 Control Plane main component

1) API Server

Kubernetes Cluster 와 외부 간의 central entry point 역할을 한다.

Kubernetes API Server 는 Kubernetes의 central control plane component로 Cluster의 모든 관리 작업은 API 서버를 통해 수행된다. kubectl 명령어, Dashboard, 기타 자동화 tool 등이 API Server 에 요청을 보내 Cluster를 제어한다.

- Kubernetes에서 API server 는 REST API Endpoint를 제공한다. 내부적으로 모든 자원(Pod, Service 등)을 REST API Object로 다룬다.

 

- etcd 와 통신

etcd: kubernetes의 영속적 상태 저장소

API Server는 Cluster 상태를 etcd 에서 조회하거나 갱신한다. 새로운 Pod가 생성되면 API Server가 이를 etcd에 저장한다.

 

- Cluster Component 간 중개자 역할

API Server 는 Control Plane의 다른 구성 요소 (Controller Manager, Scheduler 등)와도 통신한다.

예를 들어 스케줄러는 API Server를 통해 실행되지 않은 Pod 정보를 받아오고 어떤 Node에 실행할지 결정하 뒤 다시 API Server 에 결과를 전달한다.

 

- 인증, 권한 부여, 검증 및 변형 처리

Authentication, Authorization, Admission Control, Validation & Mutation

 

2) etcd

Kubernetes의 Cluster State를 영구적으로 저장하는 분산방식의 Key - Value Store 이다.

이 때 분산(distributed) 의 뜻은 여러 Node에 데이터가 분산되어있다는 뜻이다.

High Availability 와 Fault Tolerance 를 위해 필수적이다.

etcd는 여러 Node 로 구성된 Cluster 이며, 데이터는 Replication 해서 각 Node 에 저장한다. 그래서 하나의 Node 가 다운되더라도 다른 노드들이 데이터를 유지하고 서비스를 지속할 수 있다.

key - value store의 의미는 데이터를 key 와 value 쌍으로 저장한다는 것이고 이는 마치 dictionary 나 map 처럼 동작한다.

 

3) Scheduler 

새로운 Pod를 어느 Node 에 배치할 지를 결정하는 Scheduling 담당

Node 자원 (CPU, Memory), Label, taint 등을 고려해 가장 적합한 Node 를 선정한다.

 

4) Controller Manager 

다양한 Controller (ReplicaSet, Deployment, StatefulSet 등)을 실행하는 Process 모음이다.

ReplicaSet Controller 가 Pod를 N개로 유지하라는 설정을 부여하면 Desired State와 Actual State를 비교하여 맞춰준다.

 

5) Cloud Controller Manager

Cloud Resource(Load Balaner, Volumes 등)과 연동하기 위한 Controller 집합

Cloud 환경에서 Node를 자동으로 추가 및 제거하거나 LB를 Provisioning 할때 사용한다.

 

3.3 Control Plane과 Node의 관계

Node(Worker)는 단독으로 동작하지 않고 반드시 Control Plane의 관리 감독하에 동작한다. Node는 Control Plane으로부터 Pod Scheduling 지시를 받고 실행 상태 및 Resource 사용량을 재보고함으로써 Cluster 전반을 Central Control 할 수 있게 해준다.

앞서 살펴보았듯이 Control Plane은 Cluster State를 관리하는 논리적인 기능의 집합이다. "무엇을 하는지?가 초점이며 기능적인 부분을 이야기한다. 

이때 Control Plane 구성 요소들이 실행되는 실제 Node 를 Master Node 라고 부르는 데
Master Node는 보통 실행보다는 관리목적으로 한 Node 들이다. 사용자의 직접적인 요청을 API로 처리하고  Worker Node를 관리해서 사용자의 요청을 처리하고 실제 Pod를 생성하고 앱을 실행하는 등의 동작을 하게 한다.

이처럼 Master과 Worker 의 대표적인 차이는 Control Plane Component의 유무 + 무슨 역할을 하는 가? 이다.

다른 말로 표현하면 Control Plane 은 기능적인 뇌이고

Master Node는 그 뇌가 돌아가는 물리적인 몸이다.

 

Control Plane 의 Component들은 아래 표처럼 Master Node 에서 실행된다.

 

아래 표를 보면 Worker Node는 실제 Pod가 실행되는 곳이기 때문에 Control Plane Component 가 없는 것을 볼 수 있다.

 

                     [ 사용자 / kubectl ]
                             │
                    [ Load Balancer ]
                             │
        ┌──────────┬──────────┬──────────┐
        │ API 서버 │ API 서버 │ API 서버 │   ← Control Plane (다중화)
        └────┬─────┴────┬─────┴────┬─────┘
             ↓              ↓             ↓
        ┌────────────── Master Node ──────────────┐
        │   kube-apiserver (1~n개)                                                  │
        │   kube-scheduler (1개 활성)                                              │
        │   kube-controller-manager (1개 활성)                               │
        │   etcd 클러스터 (보통 3개 구성)                                         │
        └─────────────────────────────────────────┘
                                                    │
                         ┌─────────┴─────────┐
                         ↓                                                  ↓
             Worker Node 1                           Worker Node 2 ...
        ┌──────────────┐     ┌──────────────┐
        │ kubelet                        │     │ kubelet                       │
        │ kube-proxy                  │     │ kube-proxy                 │
        │ containerd                   │     │ containerd                  │
        └──────────────┘     └──────────────┘

 

 

3.4 Control Plane 의 확장 (HA, High Availability)

etcd 와 API server 는 단일 실패 지점 (SPoF)이 될 수 있기 때문에 반드시 다중화 HA 구성이 필요하다

1) etcd Clustering 

단독 구성 시에 장애가 발생하면 매우 치명적이기 때문에 3개 이상의 Node로 Cluster로 구성한다.

Raft Algorithm 을 사용해서 Leader 와 Follwer 간 데이터 복제와 정합성을 유지한다.

오직 하나의 Node만 Leader 로 (Writing 이 가능하다) 나머지는 Follower로 (읽기 전용 + 복제)

Leader에서 장애가 발생하면 자동으로 다른 Node가 리더로 선출된다.

다수의 노드에 복제되어 데이터 유실 가능성이 낮아진다.

Raft 특성으로 Strong Consistency를 보장한다.

 

2) API Server의 다중화 (Replication / Load balancing)

API Server는 Kubernetes의 Cluster의 모든 요청을 처리하는 입구이기 때문에 단일 인스턴스로 운영할 경우 성능과 가용성에 한계가 생긴다.

따라서 여러 대의 API Server Instance를 사용해서 부하를 분산하고 다른 인스턴스로 요청을 처리할 수 있게 되어있다.

[kubectl/유저]
       ↓
[Load Balancer]
   ↓     ↓     ↓

Replication 을 통해 여러 개의 Replica 를 생성하고 Load Balancer 를 앞단에 위치시켜 트래픽을 고르게 분산시킨다.

모든 API Server는 동일한 etcd Cluster 에 연결된다.

 

3) Control Plane Component의 수평적 확장

Raft 를통한 Leader 선출 방식은 장애 대비를 위한 HA는 가능하지만 동시 병렬 처리 (확장성)는 불가능하다.

API Server만 Scale Out 이 가능하다.

 

왜 Control Plane HA 에서는 여러 API Server가 있음에도 불과하고 하나의 etcd Cluster 만 사용할까?

이는 Kubernetes의 일관성(Consistency)과 신뢰성(Reliability)을 위해서 이다.

1) 일관성을 위해서

Kubernetes는 Cluster의 전체 상태를 하나의 etcd에 저장함으로 모든 API Server는 항상 같은 상태를 보고 동작할 수 있다.

2) etcd cluster가 multi node 로 구성되어있기 때문에

etcd 자체가 이미 장애대비와 고가용성을 위해서 3개 이상의 node 로 구성된 cluster에서 동작하기 때문에 API server가 하나의 etcd cluster에만 접근해도 그 안에서 알아서 데이터 복제 및 장애 대응 등을 처리한다.

그리고 etcd 에서 Raft 알고르지므을 사용하고 있기 때문에 해당 Raft 특성에 여러 etcd cluster로 데이터를 분산시키는 것은 구조적으로 맞지 않다.

4. Kubernetes Cluster 와 Node 의 상호작용

1) Control Plane -> Node  (명령 전달)

Control Plane의 Component (API server, Shceduler, Controller 등)는 Cluster의 상태를 판단하고 작업 명령을 생성한다. 그리고 kubelet 라는 Node 내부 Component로 명령을 전달하게 된다. 해당 명령은 API Server 를 통해 HTTP 방식으로 통신한다.

 

2) Node -> Control Plane (상태 보고)

Node들은 주기적으로 자신의 상태를 Cluster에게 report한다. 

주로 보고 내용은 CPU, 메모리 사용량, Pod 실행상태, Error Log

이 정보를 기반으로 Scheduler 나 Controller 가 적절한 조치를 취한다.

 

3) Pod 생성 및 관리

사용자가

kubectl apply -f pod.yaml

와 같은 명령으로 Pod를 요청할 시에

- API Server 가 요청을 수신한다

- Scheduler 가 어떤 Node 에 배치할지를 결정한다

- kubelet 이 해당 Pod를 실제로 실행 ( Container Runtime 사용 : Containerd, Docker 등)

- kubelet이 해당 결과를 다시 API Server 로 전달한다.

 

4) Service Networking (kube-proxy)

각 Node에는 kube-proxy 가 설치되어있다. ClusterIP 같은 서비스 요청을 올바른 Pod 로 전달해준다 ( Network Routing 담당)

Cluster 내에서 Pod 간, 외부 요청 간의 통신을 가능하게 한다.

 

이를 정리하자면 

사용자가 kubectl apply -f pod.yaml 명령어를 실행하면 이 명령은 쿠버네티스의 API Server로 전달된다.  API Server는 쿠버네티스 클러스터의 모든 요청을 받아들이는 Cetral Entry Point 이자 REST API Endpoint 역할을 합니다. 요청을 수신한 API Server는 먼저 인증(Authentication) → 권한 확인(Authorization) → 어드미션 컨트롤(Admission Control) → 입력 검증/디폴트 값 설정(Validation & Mutation) 등의 절차를 거치게 된다.

이 Pod Object를 클러스터의 공식 상태로 기록하기 위해 etcd에 저장한다. etcd는 쿠버네티스 클러스터의 모든 상태 정보를 보존하는 분산 Key-Value 스토어이며, 이때 저장되는 정보에는 파드 이름, 네임스페이스, 컨테이너 이미지 정보, 리소스 요청/제한 등이 포함된다.

Pod가 저장되었다고 바로 실행되는 것이 아니다. 아직 이 파드는 "스케줄되지 않음(Pending)" 상태이다. Scheduler는 etcd에서 갱신된 파드 정보를 API Server를 통해 감지한다. Scheduler는 현재 클러스터의 노드 상태(리소스 사용량, 파드 수, 태그 등)를 고려해 해당 파드를 어떤 노드에 배치할지를 결정한다. 그후 Scheduler는 API Server를 통해 Pod Object의 spec.nodeName Field를 갱신하고, 다시 etcd에 반영한다.

이제 파드가 어떤 노드에 실행될지 결정되었기 때문에 해당 노드의 kubelet이 API Server를 주기적으로 조회(polling)하거나 워치(watch) 방식으로 새로운 작업을 인지한다. kubelet은 API Server를 통해 자신에게 할당된 파드 정보를 받아온 후, 파드를 실행시키기 위해 컨테이너 런타임(containerd, Docker 등) 을 호출한다. 이 런타임이 실제로 컨테이너를 생성하고 실행하며, 그 결과를 kubelet이 감지해서 다시 API Server에 상태를 업데이트한다.

이 모든 파드/노드/컨테이너의 상태 변화는 다시 etcd에 저장되어, Kubernetes Cluster의 최신 상태로 유지된다. 그리고 이 상태를 기반으로 Controller Manager는 계속 감시를 이어가며, 예를 들어 파드가 죽었을 경우 자동으로 다시 생성하거나, Deployment 상태와 일치하지 않으면 재조정하는 역할을 합니다.

각 노드에는 kube-proxy가 함께 실행되며, 클러스터 내부에서 서비스(ClusterIP 등) 간 트래픽을 적절한 파드로 라우팅된다. 예를 들어 클러스터 내부 서비스가 특정 파드를 호출하면, kube-proxy가 NAT 또는 IP테이블을 사용해 올바른 파드로 트래픽을 전달해준다.