잔디심는 정원사

[CKA 준비] Scheduling

minsu20 — Sat, 11 Apr 2026 15:08:28 +0900

Pod를 수동으로 특정 Node에 배치하는 방법

이 강의는 스케줄러 없이 Pod를 Node에 배치하는 방법을 설명함.

보통 Kubernetes에서는 Scheduler가 어떤 Pod를 어떤 Node에 올릴지 결정함.
그런데 다음과 같은 상황이 있을 수 있음.

클러스터에 Scheduler가 없음
기본 Scheduler를 쓰지 않고
직접 Pod를 원하는 Node에 배치하고 싶음

이럴 때 사용할 수 있는 방법을 이해하는 것이 이 강의의 핵심임.

1. Scheduler는 원래 어떻게 동작하는가

먼저 기본 동작부터 보면 이해가 쉬움.

Pod 정의 파일에는 nodeName 이라는 필드가 있음.

spec:
 nodeName: ...

그런데 일반적으로는 이 값을 직접 적지 않음.
Pod를 생성할 때 보통 비워두고 생성함.

왜냐하면 원래는 Scheduler가 이 값을 채우기 때문임.

Scheduler의 동작 흐름은 대략 다음과 같음.

클러스터 안의 Pod들을 확인함
그중에서 nodeName이 아직 설정되지 않은 Pod를 찾음
그런 Pod들을 스케줄링 대상(candidate) 으로 봄
스케줄링 알고리즘으로 어떤 Node가 적절한지 결정함
적절한 Node를 찾으면 Pod를 그 Node에 배치함
이 과정에서 내부적으로 Binding Object를 만들어 연결함

즉, 핵심은 다음임.

nodeName이 없는 Pod = 아직 어느 Node에도 배치되지 않음
Scheduler가 적절한 Node를 골라서 nodeName을 설정해 줌

2. Scheduler가 없으면 무슨 일이 생기는가

클러스터에 Scheduler가 없으면,
nodeName이 비어 있는 Pod를 아무도 처리하지 못함.

그 결과 Pod는 계속 다음 상태로 남음.

Pending

즉, Pod는 생성되었지만
어느 Node에서 실행되어야 하는지 정해지지 않았기 때문에 실제로 올라가지 못하는 상태임.

3. Scheduler 없이 Pod를 수동으로 배치하는 가장 쉬운 방법

가장 쉬운 방법은 Pod 생성 시점에 nodeName을 직접 지정하는 것임.

예를 들어 Pod manifest에 이렇게 적을 수 있음.

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
 nodeName: node01
 containers:
 - name: nginx
 image: nginx

이렇게 하면 Scheduler가 없어도
Pod는 바로 node01에 배치됨.

즉,

Pod를 처음 만들 때
spec.nodeName에 원하는 Node 이름을 적으면
해당 Node에 직접 할당 가능함

4. 이미 생성된 Pod에는 nodeName을 바꿀 수 없음

여기서 중요한 제약이 있음.

Pod가 이미 생성된 뒤에는 nodeName을 수정할 수 없음.

즉 이런 식은 안 됨.

Pod를 먼저 만들고
나중에 nodeName만 수정해서 다른 Node에 붙이기

Kubernetes는 기존 Pod의 nodeName 변경을 허용하지 않음.

5. 이미 만들어진 Pod를 Node에 붙이고 싶다면

이미 생성된 Pod를 특정 Node에 연결하려면
실제 Scheduler가 하는 것처럼 Binding Object를 만들어서 API 요청을 보내야 함.

즉, 직접 Scheduler처럼 동작을 흉내 내는 방식임.

흐름은 다음과 같음.

Binding Object를 만듦
그 안에 목표 Node 이름을 적음
Pod의 Binding API로 POST 요청을 보냄
그러면 해당 Pod가 그 Node에 바인딩됨

Binding Object에는 어떤 Node에 붙일지에 대한 정보가 들어감.

예를 들어 개념적으로는 다음과 비슷함.

apiVersion: v1
kind: Binding
metadata:
 name: my-pod
target:
 apiVersion: v1
 kind: Node
 name: node01

그런데 API로 보낼 때는 보통 JSON 형식으로 보내야 하므로,
YAML을 그대로 보내는 것이 아니라 JSON으로 변환해서 POST 요청해야 함.

2. Labels and Selectors

1. Labels와 Selectors의 기본 개념

Labels와 Selectors는 대상을 분류하고 필터링하기 위한 방법임.

예를 들어 여러 동물이 있다고 하면, 다음과 같은 기준으로 나눌 수 있음.

class
kind
domestic / wild
color

이렇게 각 대상에 여러 속성을 붙여두면, 원하는 조건으로 쉽게 묶어서 볼 수 있음.

예를 들면 다음과 같음.

class = mammal → 포유류만 조회
color = green → 초록색 동물만 조회
class = bird, color = green → 초록색 새만 조회

즉, Labels는 속성을 붙이는 역할, Selectors는 그 속성을 기준으로 원하는 대상을 찾는 역할을 함.

2. Labels는 무엇인가

Labels는 각 객체에 붙이는 key-value 형태의 속성 정보임.

예를 들어 어떤 대상에 다음과 같은 label을 붙일 수 있음.

class: mammal
kind: dog
color: green

이런 식으로 label을 붙여두면, 나중에 여러 기준으로 객체를 구분할 수 있음.

핵심은 다음과 같음.

Labels는 객체를 설명하는 속성임
필요한 만큼 여러 개를 붙일 수 있음
객체를 그룹화할 때 기준이 됨

3. Selectors는 무엇인가

Selectors는 Labels를 기준으로 원하는 객체를 골라내는 조건임.

즉, Labels가 붙어 있어야 Selectors가 동작할 수 있음.

예를 들어 다음과 같이 사용할 수 있음.

class = mammal
app = app1
color = green

또는 여러 조건을 함께 사용할 수도 있음.

즉, Selectors는 단순히 객체를 보는 것이 아니라,
특정 조건에 맞는 객체만 선택하는 역할을 함.

4. 왜 Labels와 Selectors가 필요한가

Kubernetes에서는 다양한 객체를 생성하게 됨.

예를 들면 다음과 같음.

Pod
Service
ReplicaSet
Deployment

처음에는 객체 수가 적어서 직접 확인할 수 있지만, 시간이 지나면 클러스터 안에 수백 개, 수천 개의 객체가 생길 수 있음.

이때는 객체를 다음과 같은 기준으로 나눠서 봐야 함.

어떤 애플리케이션에 속하는지
어떤 기능을 담당하는지
어떤 종류의 객체인지

이런 구분을 위해 Labels와 Selectors를 사용함.

즉, Kubernetes에서 Labels와 Selectors는
객체를 체계적으로 관리하기 위한 핵심 수단임.

5. Kubernetes에서 Labels를 지정하는 위치

Kubernetes에서 Labels는 객체 정의 파일의 metadata 아래에 작성함.

예를 들어 Pod 정의 파일에서는 metadata.labels 아래에 label을 추가함.

형식은 key-value 방식임.

 apiVersion: v1
 kind: Pod
 metadata:
  name: simple-webapp
  labels:
    app: App1
    function: Front-end
 spec:
  containers:
  - name: simple-webapp
    image: simple-webapp
    ports:
    - containerPort: 8080

여기에 원하는 만큼 label을 추가할 수 있음.

즉, Pod를 만들 때부터 어떤 그룹에 속하는지 미리 표시해두는 것임.

6. Labels로 Pod를 조회하는 방법

Pod가 생성된 후에는 label을 기준으로 Pod를 조회할 수 있음.

이때 kubectl get pods 명령어와 --selector 옵션을 함께 사용함.

예를 들어 다음과 같은 조건으로 조회할 수 있음.

$ kubectl get pods --selector app=App1

이렇게 하면 해당 label을 가진 Pod만 확인할 수 있음.

즉, label은 단순한 메모가 아니라
실제로 원하는 객체를 찾는 기준으로 사용됨.

7. ReplicaSet에서 Labels와 Selectors가 어떻게 연결되는가

7. 1 metadata.labels → ReplicaSet 객체 자신에게 붙는 라벨

metadata:
  labels:
    app: myapp

-> 즉 ReplicaSet 리소스를 분류할 때 의미가 있음.

kubectl get rs --selector app=myapp

7.2 spec.template.metadata.labels → ReplicaSet이 생성할 Pod들에 붙는 라벨

selector:
  matchLabels:
    app: myapp

"label이 app=myapp인 Pod를 내가 관리하겠다."

7.3 spec.selector → ReplicaSet이 어떤 Pod를 자기 관리 대상으로 볼지 고르는 조건

template:
  metadata:
    labels:
      app: myapp

-> ReplicaSet이 Pod를 만들면, 그 Pod는 app=myapp label을 가지고 생성됨.

spec.selector.matchLabels와 spec.template.metadata.labels는 반드시 맞춰야 함

selector가 app=myapp인데,
template에서 생성되는 Pod label이 app=nginx라면 어떻게 되느냐?

ReplicaSet은 자기가 만든 Pod조차 자기 Pod로 인식하지 못할 수 있음!

metadata.labels는 달라도 ReplicaSet 동작에는 직접 문제 없음.

8. Service에서도 같은 방식이 사용됨

Service도 Labels와 Selectors를 이용해 Pod를 찾음.

동작 방식은 ReplicaSet과 거의 같음.

Pod에 labels가 붙어 있음
Service에 selector가 정의되어 있음
Service가 selector와 일치하는 Pod를 찾음
그 Pod들로 트래픽을 전달함

즉, Service도 Pod 이름이나 IP를 직접 기준으로 연결하는 것이 아니라
label 기준으로 연결 대상 Pod를 선택함

9. Labels와 Selectors의 핵심 역할 정리

Kubernetes에서 Labels와 Selectors는 다음 두 가지 목적으로 사용됨.

9-1. 객체를 조회하고 필터링하기 위해

예를 들어 특정 앱에 속한 Pod만 보고 싶을 때 사용함.

9-2. Kubernetes 객체끼리 연결하기 위해

예를 들어 다음과 같은 연결에 사용됨.

ReplicaSet → Pod 연결
Service → Pod 연결

즉, Kubernetes에서 Labels와 Selectors는
관리용 기능이면서 동시에 객체 연결의 기준이기도 함.

10. Annotations는 Labels와 어떻게 다른가

Annotations는 Labels와 목적이 다름.

Labels와 Selectors는 객체를 그룹화하고 선택하기 위한 것임.

반면 Annotations는 객체에 부가 정보를 기록하기 위한 것임.

예를 들면 다음과 같은 정보를 넣을 수 있음.

tool name
version
build information
contact details
phone numbers
email IDs

즉, Annotations는 객체를 선택하는 기준이 아니라
참고용 정보나 통합용 정보를 저장하는 용도임.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: simple-webapp
  labels:
    app: App1
    function: Front-end
  annotations:
     buildversion: 1.34
spec:
 replicas: 3
 selector:
   matchLabels:
    app: App1
template:
  metadata:
    labels:
      app: App1
      function: Front-end
  spec:
    containers:
    - name: simple-webapp
      image: simple-webapp

3. Taints and Tolerations

1. 목적

Taints와 Tolerations는 어떤 Pod가 어떤 Node에 스케줄될 수 있는지를 제한하는 기능임.

즉, 특정 Node에 아무 Pod나 올라가지 못하게 하고,
조건을 만족하는 Pod만 올라가게 할 때 사용함.

2. 어디에 설정하는가

2-1. Taint

Node에 설정함

2-2. Toleration

Pod에 설정함

즉, Node 쪽에는 “이런 Pod만 받을 수 있다”는 제한을 걸고,
Pod 쪽에는 “이 taint를 견딜 수 있다”는 설정을 넣는 구조임.

3. 핵심 동작

Node에 taint가 있으면,
그 taint를 toleration하지 못하는 Pod는 해당 Node에 스케줄되지 않음.

반대로 Pod에 해당 taint에 대한 toleration이 있으면,
그 Node에 스케줄될 수 있음.

중요한 점은 다음과 같음.

Taint는 Node가 Pod를 거부하는 기준
Toleration은 Pod가 그 거부 조건을 예외적으로 통과할 수 있게 하는 설정

4. Taint Effect 3가지

4-1. NoSchedule

해당 taint를 toleration하지 않는 Pod는
그 Node에 새로 스케줄되지 않음

4-2. PreferNoSchedule

가능하면 그 Node에 스케줄하지 않으려 하지만
강제는 아님

4-3. NoExecute

해당 taint를 toleration하지 않는 Pod는

새로 스케줄되지 않고
이미 그 Node에서 실행 중이던 Pod도 evict(제거) 됨

apiVersion: v1
kind: Pod
metadata:
 name: myapp-pod
spec:
 containers:
 - name: nginx-container
   image: nginx
 tolerations:
 - key: "app"
   operator: "Equal"
   value: "blue"
   effect: "NoSchedule"

5. 반드시 기억할 핵심

Taints와 Tolerations는
Pod를 특정 Node로 보내는 기능이 아님

즉, 이것은
“이 Pod는 반드시 이 Node로 가야 한다”를 의미하지 않음.

정확히는 다음 의미임.

해당 Node는 특정 toleration이 있는 Pod만 받을 수 있다

따라서 특정 Pod를 특정 Node에 반드시 배치하고 싶다면
그건 Node Affinity로 해결해야 함.

6. Master Node 관련

Kubernetes 클러스터에서는 보통 Master Node에 기본 taint가 설정되어 있음.

그래서 일반 Pod는 Master Node에 스케줄되지 않음.

즉, Master Node에 워크로드가 올라가지 않는 이유 중 하나가
바로 이 taint 설정 때문임.

4. Node Selectors

1. 목적

Node Selector는 특정 Pod가 특정 Node에서만 실행되도록 제한하는 기능임.

예를 들어 클러스터에 3개의 Node가 있고,

2개는 리소스가 적은 작은 Node
1개는 리소스가 많은 큰 Node

라고 할 때,
리소스를 많이 사용하는 데이터 처리 workload는 큰 Node에서만 실행되게 하고 싶을 수 있음.

기본 설정에서는 어떤 Pod든 어떤 Node에나 배치될 수 있기 때문에,
원하는 Pod가 작은 Node에 배치될 수도 있음.

이 문제를 해결하기 위해 Pod가 특정 Node에서만 실행되도록 제한하는 방법이 필요함.

2. Pod를 특정 Node에 배치하는 방법

이 강의에서는 그 방법 중 하나로 Node Selector를 설명함.

Pod를 특정 Node에서만 실행되게 하려면,
Pod 정의 파일의 spec 아래에 nodeSelector를 추가하면 됨.

예를 들어 다음과 같이 설정할 수 있음.

size: large

이 의미는:

size=large 라는 label이 붙은 Node에만 이 Pod를 배치하라

는 뜻임.

3. Node Selector의 동작 방식

동작 흐름은 아래와 같음.

3-1. Node에 label을 붙임

Syntax

$ kubectl label nodes <node-name> <label-key>=<label-value>

Example

$ kubectl label nodes node-1 size=Large

3-2. Pod에 nodeSelector를 설정함

To create a pod definition

apiVersion: v1
kind: Pod
metadata:
 name: myapp-pod
spec:
 containers:
 - name: data-processor
   image: data-processor
 nodeSelector:
  size: Large

$ kubectl create -f pod-definition.yml

3-3. Scheduler가 label과 selector를 비교함

3-4. 일치하는 Node에 Pod를 배치함

즉 핵심은:

Pod의 nodeSelector와 Node의 label이 일치해야 한다는 것임.

4. Node Selector의 한계

Node Selector는 단순하고 쉬운 방법이지만,
복잡한 조건을 표현하는 데는 한계가 있음.

예를 들어 아래와 같은 조건은 Node Selector로 처리하기 어려움.

large 또는 medium Node에 배치
small이 아닌 모든 Node에 배치

즉 Node Selector는
단순한 key-value 일치 조건만 사용할 수 있음.

더 복잡한 조건이 필요하면 Node Selector만으로는 부족함.

이런 경우에는 Node Affinity / Anti-Affinity 기능을 사용해야 함.

즉:

간단한 조건 → Node Selector
복잡한 조건 → Node Affinity / Anti-Affinity

[CKA 준비] Core Concepts - 3

minsu20 — Sun, 15 Mar 2026 22:44:08 +0900

Services

Kubernetes Service란 무엇인가

Kubernetes Service는 애플리케이션 내부와 외부의 컴포넌트 간 통신을 가능하게 하는 객체임.

즉 Service의 역할은 다음과 같음.

애플리케이션과 사용자 간 연결
애플리케이션 내부 서비스 간 연결
외부 데이터 소스와의 연결

예를 들어 애플리케이션이 다음과 같이 구성되어 있다고 가정함.

Frontend Pod 그룹 (사용자 요청 처리)
Backend Pod 그룹 (비즈니스 로직 처리)
외부 데이터베이스 연결

이때 각 Pod 그룹 간 연결을 담당하는 것이 Service임.

Service는 다음과 같은 역할을 수행함.

사용자 → Frontend 연결
Frontend → Backend 연결
Backend → 외부 데이터 연결

이렇게 마이크로서비스 간 느슨한 결합(loose coupling)을 가능하게 함.

외부에서 Pod에 접근하는 문제 해결

지금까지는 Pod끼리 내부 네트워크로 통신하는 방법을 설명했음.

하지만 이제 외부에서 Pod에 접근하는 방법을 살펴봄.

예를 들어 웹 애플리케이션 Pod가 하나 있다고 가정함.

현재 네트워크 구조는 다음과 같음.

Laptop IP : 192.168.1.1
Kubernetes Node IP : 192.168.1.2
Pod Network Range : 10.244.0.0/16
Pod IP : 10.244.0.2

문제는 다음과 같음.

Laptop → Pod 직접 접근 불가능

왜냐하면 Pod는 클러스터 내부 네트워크에 있기 때문임.

가능한 방법

노드에 SSH 접속 :ssh 192.168.1.2

그 후 Pod에 접근 : curl 10.244.0.2

하지만 이것은 노드 내부에서만 접근 가능함.

사용자는 노드에 SSH 없이 바로 웹 서비스에 접근해야 함.

Service는 Node의 포트를 Pod의 포트로 연결해주는 역할을 함.

즉 다음과 같은 구조가 됨.

Laptop
│
NodeIP:NodePort
│
Service
│
Pod:TargetPort

이렇게 외부 요청을 Pod로 전달함.

Kubernetes Service 종류

Kubernetes에는 3가지 주요 Service 타입이 있음.

1. NodePort

Pod를 Node의 포트를 통해 외부에 노출함.

External User
      │
NodeIP:NodePort
      │
Service
      │
Pod

2. ClusterIP

클러스터 내부에서만 사용되는 서비스임.

Frontend Pods → Backend Pods

서비스 간 내부 통신에 사용됨.

3. LoadBalancer

클라우드 환경에서 사용됨.

외부 Load Balancer를 생성하여 트래픽을 분산함.

Internet
│
LoadBalancer
│
Multiple Pods

NodePort Service

NodePort 서비스에는 3개의 포트가 있음.

출처 : https://github.com/kodekloudhub/certified-kubernetes-administrator-course/blob/master/docs/02-Core-Concepts/20-Services.md

1. TargetPort

Pod 내부 포트

targetPort: 80

웹 서버가 실제 실행되는 포트임.

2. Port

Service 자체의 포트

Service 내부에서 사용하는 포트임.

port: 80

3. NodePort

Node에서 외부 접근에 사용하는 포트

nodePort: 30008

외부 접근 방식

http://NodeIP:30008

NodePort는 다음 범위만 사용 가능함.

30000 ~ 32767

NodePort Service YAML 구조

Service도 Kubernetes 리소스이므로 기본 구조는 동일함.

apiVersion: v1
kind: Service
metadata:
  name: my-service

spec:
  type: NodePort
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008

  selector:
    app: myapp

Service YAML 핵심 요소

type: 서비스 타입 지정

NodePort
ClusterIP
LoadBalancer

ports : 포트 매핑 정보

targetPort → Pod
port → Service
nodePort → Node

selector : Service가 연결할 Pod를 선택함.

Pod의 label과 연결됨.

예

Pod

labels:
  app: myapp

Service

selector:
  app: myapp

이렇게 하면 Service가 Pod를 찾을 수 있음.

외부 접근 방법

웹 서비스 접근

http://NodeIP:NodePort

http://192.168.1.2:30008
curl 192.168.1.2:30008

Service 내부 Load Balancing

Service 뒤에 여러 Pod가 있을 경우 Kubernetes가 자동으로 로드 밸런싱함.

Pod가 요청을 보내면

Service
 │
 ├ Pod1
 ├ Pod2
 └ Pod3

중 하나로 전달됨.

이 작업은 kube-proxy가 수행함.

Pod가 여러 Node에 있을 경우

Node1 → Pod1
Node2 → Pod2
Node3 → Pod3

NodePort Service 생성 시

Node1:30008
Node2:30008
Node3:30008

모든 노드에서 동일한 포트가 열림.

하지만 중요한 점은 Node1로 요청이 들어와도 Pod1으로만 가는 것이 아님.

실제 흐름

Client
  │
Node1:30008
  │
Service
  │
├ Pod1
├ Pod2
└ Pod3

즉 Service가 Pod 레벨 Load Balancing 수행.

Service는 매우 유연함.

다음 상황 모두 동일하게 동작함.

Pod 1개
Pod 여러 개
여러 Node에 Pod 분산

그리고 Pod가 추가되거나 삭제되면 Service가 자동으로 업데이트됨.

추가 설정이 필요 없음.

EKS + Fargate

EKS Fargate에서는 NodePort를 사용하지 않음.

이유

Fargate에는 Node가 없음 (AWS도 Fargate는 노드를 AWS가 관리하는 serverless compute라고 설명함.)

컨테이너는 여전히 Pod 안에서 실행되고, Pod는 Kubernetes 관점에서는 Node에 스케줄링됨.
다만 EKS Fargate에서는 그 Node를 네가 관리하는 EC2 worker node로 보지 않는 것임. AWS가 Fargate용 스케줄러/컨트롤러로 Pod를 Fargate에 올리고, 각 Fargate Pod는 자기만의 compute boundary를 가지며 다른 Pod와 커널/CPU/메모리/ENI를 공유하지 않는다고 AWS가 설명함.

NodePort는 다음이 필요함.

Node network interface
Node IP
Node port open

하지만 Fargate는

Node IP 없음
Node network 없음
Node OS 접근 불가

즉 Node 자체가 없어서 NodePort 개념을 만들 수 없음.

그래서 AWS Load Balancer Controller도 Fargate에서는 target-type: ip 만 허용함.

그래서 구조는 다음과 같음.

Client
  ↓
ALB
  ↓
TargetGroup
  ↓
Pod IP
  ↓
Pod

ALB → Pod 직접

Service는 내부 routing과 DNS 역할을 담당함.

ClusterIP Service

일반적인 풀스택 웹 애플리케이션은 여러 종류의 Pod로 구성됨.

예를 들면 다음과 같음.

Frontend 웹 서버를 실행하는 Pod들
Backend 서버를 실행하는 Pod들
Redis 같은 Key-Value Store를 실행하는 Pod들
MySQL 같은 영속성 데이터베이스를 실행하는 Pod들

이처럼 애플리케이션은 여러 계층으로 나뉘어 동작함.

애플리케이션 내부 통신에서 생기는 문제

Frontend는 Backend와 통신해야 함.
Backend는 Database 및 Redis와 통신해야 함.

그렇다면 이런 계층 간 연결은 어떤 방식으로 해야 하는가가 문제임.

Pod는 각각 IP 주소를 할당받음.

하지만 이 IP들은 고정값이 아님.

즉,

Pod는 언제든지 내려갈 수 있음
새로운 Pod가 계속 생성될 수 있음
생성될 때마다 IP가 바뀔 수 있음

따라서 Pod IP를 기준으로 내부 통신을 구성하면 안정적이지 않음.

예를 들어 Frontend Pod가 Backend에 요청을 보내야 할 때, Backend Pod가 3개 있다면 다음과 같은 문제가 생김.

어떤 Backend Pod로 연결해야 하는가
그 선택은 누가 하는가

이 문제를 해결하는 것이 Kubernetes Service임.

Kubernetes Service는 여러 Pod를 하나의 그룹으로 묶고,
그 그룹에 접근할 수 있는 단일 인터페이스 제공함.

예를 들어 Backend용 Service를 만들면 다음과 같은 효과가 있음.

여러 Backend Pod를 하나로 묶음
다른 Pod가 Backend에 접근할 때 하나의 주소만 사용하면 됨
요청은 Service가 연결된 Pod들 중 하나로 전달됨
어떤 Pod로 보낼지는 Service가 알아서 처리함

즉, Frontend는 더 이상 특정 Backend Pod의 IP를 알 필요가 없음.
그냥 Backend Service만 바라보면 됨.

마찬가지로 Redis용 Service를 만들면 Backend Pod는 Redis Pod의 개별 IP가 아니라
Redis Service를 통해 접근하면 됨.

ClusterIP를 사용하는 이유

이 방식의 장점은 다음과 같음.

마이크로서비스 구조를 쉽게 구성 가능함
각 계층이 독립적으로 확장 가능함
Pod가 교체되거나 이동되어도 통신 방식은 유지됨
서비스 간 결합도를 낮출 수 있음

즉, 각 계층은 필요에 따라 확장(scale)되거나 재배치(move)될 수 있고,
그 과정에서 다른 서비스와의 통신에는 영향이 거의 없음.

ClusterIP의 핵심 개념

각 Service는 클러스터 내부에서 다음 두 가지를 가짐.

IP 주소
이름

그리고 다른 Pod들은 이 Service 이름 또는 ClusterIP를 사용해 접근함.

이런 유형의 Service를 ClusterIP라고 부름.

즉, ClusterIP는 클러스터 내부 통신용 Service 타입임.

ClusterIP Service Yaml구조

apiVersion: v1
kind: Service
metadata:
  name: back-end

spec:
  type: ClusterIP
  ports:
    - targetPort: 80
      port: 80

  selector:
    app: myapp
    type: back-end

ClusterIP Service도 다른 Kubernetes 리소스와 마찬가지로
정의 파일로 생성함.

기본 구조는 다음과 같음.

apiVersion
kind
metadata
spec

주요 설정

apiVersion: v1
kind: Service
metadata.name: backend

여기서는 Service 이름을 backend로 지정함.

spec 항목 설명

spec 아래에는 주로 다음 항목이 들어감.

1) type

Service 타입 지정함.

type: ClusterIP

사실 ClusterIP는 기본 타입임.
따라서 명시하지 않아도 자동으로 ClusterIP로 간주함.

2) ports

Service가 어떤 포트를 통해 연결되는지 정의함.

targetPort: 실제 Pod가 노출하는 포트
port: Service가 노출하는 포트

예시에서는 둘 다 80 사용함.

Backend 애플리케이션이 80 포트에서 동작함
Service도 80 포트로 요청 받음

3) selector

어떤 Pod들을 이 Service에 연결할지 정하는 항목임.

Pod 정의 파일에 있는 label 값을 복사해서 selector에 넣으면 됨.

즉, selector와 label이 일치하는 Pod들이 이 Service의 대상이 됨.

LoadBalancer

이번에는 LoadBalancer 타입의 Service를 살펴봄.

앞에서 NodePort Service를 통해 외부에서 애플리케이션에 접근할 수 있도록 만드는 방법을 봤음.
NodePort는 워커 노드의 특정 포트를 열어서 외부 요청을 Pod로 전달하는 방식임.

이제 여기서는 Frontend 애플리케이션, 즉 예시로 나온 Voting App과 Result App에 초점을 맞춤.

이 Pod들은 Kubernetes 클러스터의 워커 노드들 위에서 실행됨.

예를 들어 4개의 노드로 구성된 클러스터가 있다고 가정함.

그리고 외부 사용자가 애플리케이션에 접근할 수 있도록 하기 위해
각 애플리케이션에 대해 NodePort 타입 Service를 생성했다고 가정함.

이 NodePort Service는 다음 역할을 함.

각 노드의 특정 포트에서 외부 요청 받음
받은 요청을 해당 Pod로 전달함

즉, 외부 사용자는 노드의 IP와 NodePort를 이용해서 애플리케이션에 접속 가능함.

이 방식은 동작은 하지만, 사용자에게 제공할 URL이 불편함.

예를 들어 사용자가 Voting App과 Result App에 접속하려면
다음과 같은 형태의 주소를 사용해야 함.

노드 IP + 포트
다른 노드 IP + 포트
또 다른 노드 IP + 포트

즉, 애플리케이션 하나당 여러 개의 IP:Port 조합이 생길 수 있음.

예를 들어 Voting App의 Pod가 실제로는
IP가 70, 71인 두 노드에만 배포되어 있다고 하더라도,
Service 특성상 클러스터의 모든 노드 IP에서 접근 가능함.

즉, Pod가 특정 노드에만 떠 있어도
사용자는 모든 노드의 IP와 NodePort로 접근할 수 있음.

이론적으로는 문제없지만, 실제 사용자 입장에서는 매우 불편함.

사용자가 원하는 것은 다음과 같은 형태임.

voting-app.example.com
result-app.example.com

즉, 하나의 고정된 URL을 원함.

이 문제를 해결하는 한 가지 방법은
별도의 VM을 하나 만들어 외부 로드밸런서 용도로 사용하는 것임.

예를 들어 그 VM에 다음과 같은 소프트웨어를 설치할 수 있음.

HAProxy
NGINX

그리고 그 로드밸런서가 외부 요청을 받아서
클러스터 내부의 노드들로 트래픽을 분산하도록 설정할 수 있음.

하지만 이 방식은 다음과 같은 단점이 있음.

별도 VM 준비 필요함
로드밸런서 설치 필요함
라우팅 설정 필요함
지속적인 운영 및 관리 필요함

즉, 직접 구성하고 유지보수하기에는 번거롭고 부담이 큼.

Google Cloud
AWS
Azure

이런 클라우드들은 자체적으로 네이티브 Load Balancer 기능 제공함.

Kubernetes는 일부 클라우드 제공자의 네이티브 로드밸런서와 연동하는 기능을 지원함.

따라서 사용자는 직접 HAProxy나 NGINX를 설치하지 않아도 됨.

그 대신 Frontend Service의 타입을 NodePort가 아니라 LoadBalancer로 지정하면 됨.

즉,

type: NodePort 대신
type: LoadBalancer 사용함

그러면 Kubernetes가 클라우드 제공자의 로드밸런서와 연동하여
외부에서 접근 가능한 단일 진입점을 구성해줌.

LoadBalancer 타입을 사용하면
클라우드 환경에서 외부 로드밸런서를 자동으로 구성할 수 있음.

그 결과 사용자는 여러 노드의 IP와 포트를 알 필요가 없음.

대신 하나의 외부 주소를 통해 애플리케이션에 접근 가능함.

즉, 사용자 입장에서는 더 자연스럽고 실용적인 접근 방식이 됨.

이 기능은 지원되는 클라우드 환경에서만 제대로 동작함.

대표적으로 다음은 지원됨.

GCP
AWS
Azure

반대로 다음과 같은 환경에서는 기대한 방식으로 동작하지 않음.

VirtualBox
일반 로컬 환경
클라우드 로드밸런서 연동이 없는 환경

이런 비지원 환경에서 Service 타입을 LoadBalancer로 설정하더라도
실제로는 외부 클라우드 로드밸런서가 생성되지 않음.

결과적으로는 NodePort와 거의 같은 효과만 냄.

노드의 높은 포트로 서비스가 노출됨
하지만 별도의 외부 로드밸런서는 자동 생성되지 않음

따라서 LoadBalancer 타입이라고 해서
어떤 환경에서나 자동으로 단일 외부 주소가 생기는 것은 아님.

환경 지원 여부가 중요함.

Load Balancer Yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-service

spec:
  type: LoadBalancer
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008

Namespace

Kubernetes의 Namespace는 클러스터 안의 리소스를 논리적으로 구분하는 공간임.

예를 들어 Smith 가족의 집과 Williams 가족의 집이 있다고 하면,

같은 집 안에서는 사람을 이름만으로 부를 수 있음
다른 집 사람을 부를 때는 더 정확한 구분이 필요함
각 집마다 규칙과 자원이 따로 있음

Kubernetes에서도 Namespace가 이와 비슷한 역할 수행함.

즉, Namespace는

리소스를 구분함
서로 다른 환경을 격리함
정책과 자원 제한을 따로 적용 가능하게 함

지금까지 생성한 다음 리소스들은

Pod
Deployment
Service

모두 어떤 Namespace 안에서 생성된 것임.

지금까지 별도로 지정하지 않았다면
대부분 default namespace에서 작업한 것임.

이 default namespace는 Kubernetes가 자동으로 만들어주는 기본 Namespace임.

즉, 지금까지 계속 기본 집 안에서 작업하고 있었던 것과 같음.

Kubernetes는 클러스터가 처음 생성될 때 몇 가지 Namespace를 자동으로 만듦.

1) default

사용자가 별도 지정 없이 작업할 때 사용하는 기본 Namespace임.

2) kube-system

Kubernetes 내부 구성요소들이 사용하는 Namespace임.

예:

네트워크 관련 구성요소
DNS 서비스

이런 시스템 리소스를 사용자 리소스와 분리해서
실수로 수정하거나 삭제하지 않게 하기 위한 목적임.

3) kube-public

모든 사용자가 접근할 수 있어야 하는 리소스를 위한 Namespace임.

Namespace를 왜 사용하는가

Namespace를 사용하는 대표적인 이유는 격리(isolation) 때문임.

예를 들어 하나의 클러스터를 다음 두 환경이 함께 사용한다고 가정함.

dev
prod

이때 Namespace를 나누지 않으면
개발 작업 중 운영 리소스를 실수로 건드릴 수 있음.

그래서 다음처럼 나눌 수 있음.

dev namespace
prod namespace

이렇게 하면 환경별 리소스를 분리 가능함.

즉, Namespace는 같은 클러스터 안에서 환경을 안전하게 나누는 방법임.

Namespace마다 따로 적용할 수 있는 것

각 Namespace는 독립적으로 다음 설정을 가질 수 있음.

1) 정책(Policy)

누가 무엇을 할 수 있는지 정의 가능함.

즉, 접근 제어나 권한 정책을 Namespace 단위로 나눌 수 있음.

2) 자원 할당량(Resource Quota)

각 Namespace가 사용할 수 있는 자원의 한계를 정할 수 있음.

예를 들면 다음과 같음.

Pod 개수 제한
CPU 사용량 제한
Memory 사용량 제한

이렇게 하면 특정 Namespace가 과도하게 자원을 사용하지 못하게 할 수 있음.

같은 Namespace 안에서는 이름만으로 접근 가능함

같은 집 안에서는 사람을 이름만으로 부를 수 있다고 했듯이,
같은 Namespace 안의 리소스도 이름만으로 서로 접근 가능함.

예를 들어 webapp Pod가 같은 Namespace 안의 DB Service에 접근할 때는
그냥 서비스 이름만 사용하면 됨.

예: db-service

즉, 같은 Namespace 안에서는 이름만으로 충분함.

이유는 Kubernetes에서 namespace를 명시하지 않은 DNS query는 Pod 자신의 namespace 기준으로 해석되기 때문이다.
또한 공식문서에 따르면 kubelet은 각 Pod의 /etc/resolv.conf를 구성하며, 짧은 이름 질의는 search domain을 이용해 확장될 수 있다. 예를 들어 현재 Namespace가 test라면:

db-service
→ db-service.test.svc.cluster.local

예시 resolv.conf

nameserver 10.32.0.10
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

따라서 같은 Namespace 안의 Service 호출에는 FQDN을 항상 풀로 적을 필요가 없고,
<service-name>만으로도 충분하다.
다른 Namespace의 Service에 접근할 때만 <service-name>.<namespace> 또는 전체 FQDN을 사용하면 된다.

출처 : https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

다른 Namespace의 Service에 접근하는 방법

만약 다른 Namespace에 있는 Service에 접근하려면
서비스 이름만으로는 부족함.

이때는 다음 형식을 사용함.

service-name.namespace
or
service-name.namespace.svc.cluster.local

예를 들어 default namespace의 web Pod가
dev namespace에 있는 db-service에 접근하려면 다음처럼 사용함.

db-service.dev
or
db-service.dev.svc.cluster.local (FQDN, 명시적임)

이 형식은 Kubernetes가 Service 생성 시 자동으로 만든 DNS 이름임.

구성을 보면 다음과 같음.

db-service → 서비스 이름
dev → Namespace 이름
svc → 서비스 서브도메인
cluster.local → 클러스터 기본 도메인

다른 Namespace에서는 최소한 <service-name>.<namespace> 형태로 namespace를 명시해야 한다.
가장 명시적인 전체 이름은 <service-name>.<namespace>.svc.cluster.local 이다.

kubectl get pods

이 명령은 기본적으로 default namespace의 Pod만 조회함.

예를 들어 kube-system의 Pod를 보려면:

kubectl get pods --namespace kube-system

kubectl get pods -n kube-system

리소스를 다른 Namespace에 생성하는 방법

Pod 정의 파일로 리소스를 생성할 때
Namespace를 지정하지 않으면 기본적으로 default namespace에 생성됨.

방법 1) 명령어에서 지정

kubectl apply -f pod.yaml -n dev

방법 2) YAML 파일 안에 지정

metadata:
  name: my-pod
  namespace: dev

이렇게 해두면 항상 dev namespace에 생성됨.

실수 방지 측면에서 YAML에 명시하는 것이 유용함.

Namespace 생성 방법

Namespace도 Kubernetes 객체이므로 YAML로 생성 가능함.

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  
  
## 생성
kubectl create -f namespace.yaml

## 명령어로
kubectl create namespace dev

매번 -n dev를 붙이는 것이 번거로우면
현재 context의 기본 Namespace를 변경할 수 있음.

kubectl config set-context --current --namespace=dev

이렇게 하면 이후에는

kubectl get pods

만 입력해도 dev namespace 기준으로 동작함.

다른 Namespace를 보고 싶으면 그때만 -n 옵션을 사용하면 됨.

클러스터 전체 Pod를 보고 싶다면 다음 명령 사용함.

kubectl get pods --all-namespaces

또는

kubectl get pods -A

이 명령은 모든 Namespace의 Pod를 한 번에 보여줌.

ResourceQuota로 Namespace 자원 제한하기

특정 Namespace가 사용할 수 있는 자원을 제한하려면
ResourceQuota를 생성하면 됨.

예를 들어 다음과 같은 제한 설정 가능함.

Pod 10개
CPU 10개
Memory 10GB

이렇게 하면 해당 Namespace는 정해진 범위 내에서만 자원 사용 가능함.

즉, ResourceQuota는 Namespace 단위의 자원 통제 수단임.

apiVersion: v1
kind: ResourceQuota
metadata:
 name: compute-quota
 namespace: dev
 
spec: 
 hard:
   pods: "10"
   requests.cpu: "4
   requests.memory: 5Gi
   limits.cput: "10"
   limits.memory: 10Gi

[CKA 준비] - Core Concepts - 2

minsu20 — Sun, 15 Mar 2026 01:41:56 +0900

Yaml in Kubernets

apiVersion:
kind:
metadata:
spec

Kind	Version
Pod	v1
Service	v1
ReplicSet	apps/v1
Deployment	apps/v1

Pod yaml 구조

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
    - name: nginx-container
      image: nginx

Pod 관련 명령어

# Pod 목록 보기
kubectl get pods
kubectl get pods -o wide

# Pod 상세 보기
kubectl describe pod <pod-name>

# Pod YAML 초안 만들기
kubectl run <pod-name> --image=<image-name> --dry-run=client -o yaml > filename.yaml

# YAML로 Pod 생성
kubectl create -f filename.yaml

# YAML 수정 후 반영
vim filename.yaml
kubectl apply -f filename.yaml

# Pod 삭제
kubectl delete pod <pod-name>

# 로그 확인
kubectl logs <pod-name>

# Pod 내부 접속
kubectl exec -it <pod-name> -- /bin/sh

Replication Controller / ReplicaSet

1. 컨트롤러란?

컨트롤러는 Kubernetes에서 객체 상태를 계속 감시하고, 원하는 상태가 유지되도록 조치하는 구성요소이다.

즉, Kubernetes는 그냥 한 번 생성하고 끝나는 것이 아니라,

계속 상태를 확인하면서 부족하거나 문제가 생기면 자동으로 맞춰주는 방식으로 동작한다.

2. 왜 여러 Pod가 필요한가?

예를 들어 애플리케이션이 Pod 1개에서만 실행 중이라고 가정

이 경우 그 Pod가 죽으면:

애플리케이션이 중단되고
사용자는 접속할 수 없게 됨

그래서 같은 애플리케이션 Pod를 여러 개 유지하면:

하나가 실패해도
나머지 Pod가 계속 서비스할 수 있음

3. Replication Controller / ReplicaSet 의 역할

“지정한 개수만큼 Pod가 항상 실행되도록 유지한다.”

예를 들어 replicas를 3으로 설정하면:

정상일 때는 Pod 3개 유지
1개가 죽으면 새로 만들어서 다시 3개 유지

즉, Pod 개수를 자동으로 맞춰주는 관리자

Pod 가 1개여도 의미가 있다.

Pod 하나가 죽으면 새 Pod를 자동으로 다시 만들어주기 때문 -> 단일 Pod의 자동 복구 목적으로도 사용 가능

4. 차이점

Replication Controller

예전 방식
오래된 기술

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

selector를 생략 가능

replicas : 몇 개의 Pod를 유지할 것인가?
template: Replica 가 새 Pod를 만들어야 할 때 사용할 Pod 설계도
- Pod 템플릿을 이용해 나중에 Pod가 죽으면 새 Pod를 생성함

ReplicaSet

더 최신 방식
현재 권장 방식

즉, 지금은 ReplicaSet을 사용하는 것이 일반적

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

selector 가 필수

selector: 어떤 Pod 들을 내가 관리 대상으로 볼 것인가?
- label = Pod에 붙인 표식 (옷에 있는 라벨이랑 똑같음)
- selector = 그 표식을 보고 대상을 고르는 조건
- Pod에 라벨링을 하고, selector 에서 해당 라벨을 보고 내가 원하는 것만 다시 재생성하는 구조

ReplicaSet = apps/v1 + selector 필수

Deployment

실제 운영 환경에서는 애플리케이션을 Pod 1개만 띄워서 끝내는 경우가 거의 없음.

예를 들어 웹 서버를 운영한다고 하면:
- 인스턴스가 여러 개 있어야 함
- 새 버전이 나오면 서비스 중단 없이 업데이트하고 싶음
- 업데이트하다가 문제 생기면 이전 버전으로 되돌리고 싶음
- 여러 변경 사항을 한 번에 반영하고 싶음

-> 이런 운영상의 요구를 해결하는 객체가 Deployment

기능

1. 여러 인스턴스 운영

웹 서버를 실제 서비스에 배포할 때는 보통 여러 개의 인스턴스를 실행해야 함.
그래야 부하 분산도 되고, 일부 인스턴스에 문제가 생겨도 서비스가 계속 가능함.

2) Rolling Update

새 버전 이미지가 나오면 기존 인스턴스를 새 버전으로 바꿔야 함.
그런데 모든 인스턴스를 한 번에 바꾸면 서비스 영향이 클 수 있음.

그래서 보통은:

하나 업데이트
정상 확인
다음 것 업데이트

이런 식으로 순차적으로 교체함

3) Rollback

업데이트 후 문제가 생길 수 있음.
이 경우 최근 변경을 취소하고 이전 상태로 되돌릴 수 있어야 함.

4) Pause / Resume

운영 중에는 한 번에 여러 가지를 바꾸고 싶을 수 있음.

이미지 버전 변경
replicas 변경
리소스 설정 변경

이걸 하나씩 즉시 반영하는 대신,

잠시 배포를 멈추고
필요한 변경을 모아서 적용한 다음
다시 배포를 진행

하는 방식이 필요함.

Pod, ReplicaSet, Deployment 관계

Pod	ReplicaSet	Deployment
애플리케이션 하나의 실행 단위 컨테이너는 Pod 안에서 실행	같은 Pod 를 여러 개 유지하는 역할을 함 원하는 개수의 Pod 가 계속 유지하도록 관리	ReplicaSet 보다 한 단계 위에 있는 상위 객체 ReplciaSet을 관리하면서 운영에 필요한 기능까지 제공함

                Deployment
                    │
                    │ (관리 / 업데이트 전략)
                    ▼
               ReplicaSet
                    │
                    │ (Pod 개수 유지)
                    ▼
        ┌───────┬───────┬───────┬───────┐
        │  Pod  │  Pod  │  Pod  │  Pod  │
        └───────┴───────┴───────┴───────┘

Deployment → ReplicaSet → Pod

Deployment 가 하는 일

여러 Pod를 유지하게 함
새 버전으로 무중단 업데이트 가능하게 함
문제 생기면 롤백 가능하게 함
변경을 pause/resume 하며 제어 가능하게 함

즉 ReplicaSet이 “Pod 개수 유지”에 초점이 있다면,
Deployment는 그 위에서 배포 전략까지 관리하는 객체

Deployment Yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

ReplicaSet YAML과 거의 같고,
kind만 Deployment로 바꾸면 됨.

Deployment 생성 후

Deployment가 ReplicaSet을 만들고, ReplicaSet이 Pod를 만드는 구조

Deployment 생성
ReplicaSet 자동 생성
1. Deployment가 ReplicaSet을 자동으로 만듦.
2. 확인 명령: kubectl get rs
Pod 생성
1. ReplicaSet이 실제 Pod들을 생성함.
2. 확인 명령: kubectl get pods

하나의 Deployment를 만들었더니
그 아래에 ReplicaSet이 생기고, 그 아래에 Pod들이 생긴다.
Deployment는 ReplcaSet보다 상위객체이므로
ReplicaSet을 직접 쓰기보다는 운영에서는 Deployment을 더 많이 사용함

!! 실습 명령어 정리

NGINX Pod 생성

kubectl run nginx --image=nginx

Pod YAML Manifest 생성 (실제 생성하지 않음)

kubectl run nginx --image=nginx --dry-run=client -o yaml

옵션 설명

-o yaml → YAML 형식으로 출력
--dry-run=client → 실제로 리소스를 생성하지 않음

Deployment 생성

kubectl create deployment --image=nginx nginx

Deployment YAML 파일 생성 (실제 생성하지 않음)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Deployment YAML 생성 후 파일로 저장

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

YAML 파일 수정 후 Deployment 생성

예를 들어 replicas 수를 추가로 수정한 뒤

kubectl create -f nginx-deployment.yaml

Kubernetes 1.19 이상에서 replicas 옵션 사용

Kubernetes 1.19 이상에서는 --replicas 옵션을 직접 사용할 수 있음.

예: replicas 4개 Deployment 생성 YAML 만들기

kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

[CKA 준비] Core Conecepts - 1

minsu20 — Wed, 4 Mar 2026 23:19:09 +0900

Cluster Architecture

아키텍처 구조 개요

Kubernetes 클러스터는 크게 두 종류의 노드로 구성된다.

Master Node (Control Plane)
Worker Node

Master Node

1. etcd

etcd와 통신하는 유일한 Kubernetes 컴포넌트는 kube-apiserver이다.
고가용성 Key-Value 저장소
클러스터의 모든 상태 정보 저장
- 노드 정보
- Pod 정보
- 설정 데이터
- 메타데이터 등

2. kube-apiserver

모든 요청의 진입점
외부 사용자, 컨트롤러, kubelet 모두 이 API 서버를 통해 통신
클러스터 전체를 오케스트레이션하는 중앙 관리 서버

Controller-Manager / kube-scheduler / kubelet
                ↓
         kube-apiserver
                ↓
              etcd

3. kube-scheduler

Pod를 어떤 Worker Node에 배치할지 결정
스케줄러는 “어디에 배치할지 결정”만 하고, 실제 생성은 하지 않는다.

4. Controller Manager

Node Controller
- 노드 상태 감시
- 노드 장애 처리
- 신규 노드 등록 관리

Replication Controller
- 원하는 개수의 Pod가 항상 유지되도록 보장

Woker Node

1. Container Runtime

컨테이너를 실행하기 위한 엔진.

Docker
containerd
CRI-O 등

2. kubelet

각 노드에서 실행되는 에이전트
kube-apiserver로부터 명령 수신
Pod 생성/삭제 수행
노드 및 Pod 상태를 API 서버에 보고

3. kube-proxy

노드 간 네트워크 통신 지원
클러스터 내부 통신을 가능하게 함

Docker vs ContainerD

개요

초기 Kubernetes는 Docker 전용이었다.
다양한 런타임을 지원하기 위해 CRI(Container Runtime Interface) 도입.
Docker는 CRI를 직접 지원하지 않아 Dockershim을 사용.
Kubernetes 1.24에서 Dockershim 제거 → Docker 런타임 지원 종료. (단, 이미지는 사용 가능 ! OCI 표준 준수하므로)
현재 표준 런타임은 containerd.

Docker vs containerD

Docker는 여러 구성요소로 이루어져 있다:

Docker CLI
Docker API
Image Build Tools
Volume 관리
Security
containerd
runc

여기서 containerd는 실제 컨테이너 실행을 담당하는 런타임이다.

현재 containerd는:

독립 프로젝트
Docker 없이 단독 설치 가능

CLI 도구

1. ctr - containerd CLI

containerd 기본 디버깅 CLI
기능 제한적 / Docker와 문법 다름 / 실사용 비권장

이미지 pull	ctr images pull docker.io/library/nginx:latest
이미지 목록	ctr images ls
컨테이너 실행	ctr run IMAGE NAME
태스크 목록	ctr tasks ls
컨테이너 삭제	ctr containers rm NAME

2. nerdctl - containerd CLI

Docker 대체 CLI (containerd용)
일반 사용 가능 / Docker와 거의 동일

docker run	nerdctl run
docker ps	nerdctl ps
docker logs	nerdctl logs
docker exec	nerdctl exec
docker build	nerdctl build
docker pull	nerdctl pull
docker images	nerdctl images
docker network	nerdctl network
docker volume	nerdctl volume

추가 기능 (Docker보다 앞선 기능)

Lazy Pull
이미지 암호화
P2P 이미지 배포
image signing
containerd namespace 지원

목적: Docker 대체 실사용 CLI

3. crictl - Kubernetes 커뮤니티에서 제공.

Kubernetes 관점 디버깅 도구
CRI 인터페이스 기반
kubelet이 사용하는 런타임을 직접 조회

containerd 전용이 아니라:

CRI-O

기타 CRI 런타임

모두 지원.

이미지 목록	crictl images
컨테이너 목록	crictl ps
Pod 목록	crictl pods
로그 확인	crictl logs CONTAINER_ID
exec	crictl exec -it CONTAINER_ID sh
inspect	crictl inspect CONTAINER_ID
pull	crictl pull IMAGE

컨테이너 생성은 가능하지만 권장하지 않음 : kubelet은 자신이 모르는 컨테이너를 삭제하기 때문

ctr → containerd 내부 디버깅용
nerdctl → Docker 대체 CLI
crictl → Kubernetes 노드 디버깅용

Docker는 deprecated된 것이 아니라 Kubernetes에서 런타임으로서의 Docker 지원이 제거된 것이다.

-> containerd가 Kubernetes의 기본 런타임 역할을 한다.

Docker 런타임 지원 중단?

Kubernetes가 Docker Engine을 컨테이너 런타임으로 직접 사용하지 않는다는 뜻이다.

kubelet이 Docker daemon과 더 이상 통신하지 않는다.
Dockershim이 제거되었다. (v1.24)

과거 구조: kubelet → Dockershim → Docker Engine → containerd → runc
현재 구조: kubelet → CRI → containerd → runc

변경된 점:

Dockershim 제거
Docker Engine 경로 제거
kubelet이 Docker API를 더 이상 호출하지 않음

ETCD

etcd는 Kubernetes 클러스터 상태를 저장하는 분산형과 강한 일관성을 가진 Key-Value 데이터 저장소이다.

다음과 같은 특징을 가지고 있다.

특징 & 기본 개념

Distributed

여러 서버(노드)에 데이터 복제
하나의 인스턴스가 죽어도 동작 가능
클러스터 형태로 구성 가능

Strongly Consistent

한 번 write 가 성공하면 그 이후의 모든 read 는 항상 최신 값을 본다
Raft 기반이기 때문에 가능함

<-> Eventually Consistency: 시간이 지나면 결국 동일해지지만, 그 전까지는 다른 값을 볼 수도 있다.

<-> stale raed: 이미 업데이트된 데이터가 있는데, 이전 값을 읽는 것

Raft 기반

분산 노드들이 항상 동일한 상태를 유지하기 위해 만든 과반수 합의 알고리즘

Raft 클러스터는 보통 3개 또는 5개 노드로 구성된다.

        Client
          │
          ▼
      Leader (etcd)
       /      \
      /        \
Follower A     Follower B

Leader	모든 write 요청 처리
Follower	Leader 데이터를 복제
Client	kube-apiserver

Write는 항상 Leader만 처리한다

예를 들어, Kubernetes가 Pod 생성을 한다고 가정해보자

1. Leader가 요청을 받는다.

 Client (kube-apiserver)
        │
        ▼
      Leader

2. Leader → Followers 로그 전파

       Leader
       /    \
      /      \
Follower A    Follower B
   log         log

3. 과반수 확인

3개 노드라면 2개 이상 성공해야 commit된다.

즉, Leader, FollowerA 가 성공하면 commit 가능하다.

write 는 데이터를 변경하는 요청이고,
commit 은 write가 과반수 노드에 복제되어 클러스터 공식 상태로 확정되는 것

4. Commit 후 응답

Leader가 Client에게 성공 응답을 보내고, 이 시점부터 모든 read는 최신 데이터임

Q 1. 커밋을 못한 Follower B 로 인해 이전 데이터를 반환해서 정합성이 깨지는 일은 없을까?

-> Strong consistency 환경에서는 follower가 commit되지 않은 상태로 read를 직접 처리하지 않는다.

commit 이후 내부 동작

Leader가 commit을 선언하면 다음이 일어난다.

Leader → followers "commit index 업데이트"

Follower B는 이미 로그가 있으므로 바로 commit되지만, Follower C는 아직 로그가 없다.

하지만 Raft 규칙상, follower C는 이후 leader로부터 로그를 다시 받아 catch-up replication을 수행한다.

즉 시간이 지나면 모든 노드가 동일 상태로 수렴한다.

그런데 read가 follower C로 가면?

Raft에서는 읽기 전략이 여러 가지가 있다.

1. Leader Read (기본 / 강한 일관성)

모든 read 요청을 Leader가 처리한다.

Client → Leader → response

이 경우 stale read가 절대 발생하지 않는다.

2. Linearizable Read

Follower가 read 요청을 받으면

Follower → Leader 확인 → 최신 상태 확인 → 응답

즉 follower가 바로 응답하지 않는다.

그래서 stale read가 방지된다.

3. Stale Read (허용 모드)

성능을 위해 일부 시스템은

Follower가 바로 read

하지만 이 경우 eventual consistency가 된다.

-> 하지만, etcd의 기본 read는 linearizable이다.

etcd에서는 어떻게 처리되나?

client read 요청
↓
leader 확인
↓
commit index 확인
↓
응답

즉 뒤처진 follower가 바로 응답하지 않는다.

요약하자면

A: committed
B: committed
C: 아직 replication 안됨

이런 상황에서 read 요청이 C로 가면,

C → leader 확인해 leader가 최신 commit index를 알려준다.

C가 최신 로그가 없다면, replication → catch-up 후에 read 응답.

etcd의 기본 read는 linearizable이므로, leader 에게 확인하는 과정이 있어
C가 옛 데이터를 반환하는 일이 없다.

Q 2. 커밋을 못한 follwer B 가 리더가 되면 ?

leader가 죽으면 follower에서 랜덤 election timeout이 발생하고 가장 먼저 timeout된 노드가 candidate가 된다.
가장 먼저 candidate가 된 노드는 자기 자신에게 투표를 하고, RequestVote RPC로 다른 노드에게 투표를 요청한다.

이때, 투표할 때 follower는 다음을 확인한다.
candidate log ≥ follower log
즉 candidate가 더 오래된 로그면 vote를 거부함

과반수 투표를 받으면 leader가 된다.
이때 로그가 뒤처진 노드는 투표를 받지 못하기 때문에 commit 상태보다 오래된 노드는 leader가 될 수 없다.

Q 3. etcd가 왜 절대 split brain 이 발생하지 않을까?

split brain은 두 리더가 동시에 존재해서 ,

A : replicas = 5
B : replicas = 3

클러스터 상태가 갈라진다.

Raft는 두 가지 규칙으로 split brain을 막는다.

Leader는 quorum 투표로만 선출
Write도 quorum 필요

Network Partition 상황

5개의 노드: A B C D E
과반수 -> 3

partition

Group1 : A,B
Group2 : C,D,E

Group1

nodes = 2 quorum = 3
-> leader 불가.

Group2

nodes = 3 quorum = 3
-> leader 가능.

C,D,E → leader
A,B → follower

항상 한쪽만 leader 가능.

-> 수학적으로 두 개의 leader 는 절대로 불가능하다!

그래서 etcd는 split brain을 방지한다

Raft 규칙:

leader election → quorum 필요
commit → quorum 필요
quorum 집합은 항상 교집합 존재
로그 최신성 검증

Raft는 split brain 대신 availability를 포기한다.

cluster = 3 nodes
partition = 1 + 1 + 1

-> quorum 없음.

write 불가 leader 없기 때문에 시스템이 멈추게 됨

하지만, 데이터 불일치는 발생하지 않는다.

CAP 이론과 연결된다

분산 시스템은 세 가지 중 두 개만 선택 가능하다.

C	Consistency
A	Availability
P	Partition tolerance

etcd 는 CP 시스템

Consistency + Partition tolerance

대신에 Availability 일부 포기

Cluster State Store

etcd는 Kubernetes 클러스터의 모든 상태를 저장하는 저장소이다.

저장 대상:

Nodes
Pods
Deployments
ConfigMaps
Secrets
RBAC
Services
etc.

kubectl get으로 보는 모든 정보는 etcd에 저장되어 있다.

Q. Kubernetes는 모든 상태를 etcd에 저장할까?

Kubernetes는 클러스터 상태 기반(control loop) 시스템으로 설계되어 있다.

즉, 모든 컴포넌트가 동일한 상태를 기준으로 동작해야 한다.

그래서 하나의 신뢰 가능한 상태 저장소가 필요하고, 그것이 etcd이다.

etcd 배포 방식

클러스터를 어떻게 구성하느냐에 따라 etcd의 배포 방식도 달라진다.

1. From scratch 방식

직접 Kubernetes를 설치하는 방식이다.

직접 해야 하는 작업:

etcd 바이너리 다운로드
etcd 설치
systemd service 작성
etcd 실행 옵션 설정

etcd \
--advertise-client-urls=http://10.0.0.5:2379 \
--listen-client-urls=http://0.0.0.0:2379 \
--initial-cluster=...

즉 이런 옵션들을 직접 설정해야 한다.

대표적으로 설정하는 것

--advertise-client-urls	API server가 접근할 주소
--listen-client-urls	etcd가 실제 listen 하는 주소
--initial-cluster	HA etcd 클러스터 구성
TLS options	인증서

2. kubeadm 방식

kubeadm은 control plane 구성 자동화 도구다.

kubeadm이 하는 일:

etcd 설치
etcd 설정
TLS 인증서 생성
etcd cluster 구성
etcd 실행

사용자가 직접 설정 X, kubeadm이 자동 생성

3. etcd 실행 방식 차이

From scratch

보통 systemd service로 실행

/etc/systemd/system/etcd.service

kubeadm

etcd는 static pod로 실행된다.

/etc/kubernetes/manifests/etcd.yaml

kubelet이 이 파일을 보고 자동으로 pod를 실행한다.

kubectl get pods -n kube-system
-------------------------------
etcd-master
kube-apiserver
kube-controller-manager
kube-scheduler

4. kubeadm에서도 옵션은 존재한다

# /etc/kubernetes/manifests/etcd.yaml
----------------------------------------
containers:
- command:
- etcd
- --advertise-client-urls=https://10.0.0.5:2379
- --listen-client-urls=https://127.0.0.1:2379
- --initial-cluster=...
 

즉 옵션은 동일하지만 사용자가 직접 작성하지는 않는다.

5. etcd 데이터 구조

Kubernetes 리소스는 etcd에서 다음 구조로 저장된다.

root

/registry

예

/registry/nodes
/registry/pods
/registry/deployments
/registry/services
/registry/secrets

6. HA etcd 클러스터

HA 환경에서는 여러 etcd 노드가 있다.

이때 etcd는 서로를 알아야 함

--initial-cluster \
etcd1=http://10.0.0.5:2380,\
etcd2=http://10.0.0.6:2380,\
etcd3=http://10.0.0.7:2380

항목	From Scratch	Kubeadm
etcd 설치	직접	자동
etcd 옵션 설정	직접	kubeadm 자동
실행 방식	systemd	static pod
인증서	직접 생성	kubeadm 자동 생성
클러스터 구성	직접	kubeadm 자동

kube-api-server

Kubernetes의 중앙 관제 서버
모든 요청이 여기로 들어오고, 모든 컴포넌트가 여기와 통신한다.

왜 중요한가?

Kubernetes에는 여러 컴포넌트가 있다.

kubectl
scheduler
controller-manager
kubelet
etcd

이 컴포넌트들이 서로 직접 통신하는 게 아니라,
대부분 kube-apiserver를 중심으로 연결된다.

kube-apiserver가 하는 일

1. 요청 받기

kubectl get pods
kubectl apply -f pod.yaml

이 명령은 실제로 kube-apiserver로 간다.

2. 인증 / 권한 확인 / 유효성 검사

이 사용자가 누구인지
이 작업을 할 권한이 있는지
YAML이 올바른 형식인지

3. etcd와 통신

kube-apiserver는 etcd에 직접 접근하는 유일한 컴포넌트다.

데이터 읽기
데이터 저장
상태 업데이트

를 kube-apiserver가 담당한다.

4. 다른 컴포넌트와 연결

예를 들어 Pod 생성 시:

사용자가 Pod 생성 요청
kube-apiserver가 Pod 객체를 etcd에 저장
scheduler가 이 Pod를 보고 노드 선택
kube-apiserver가 그 결과를 etcd에 업데이트
kubelet이 자기 노드에 할당된 Pod를 보고 실행
kubelet이 상태를 kube-apiserver에 보고
kube-apiserver가 etcd에 상태 저장

즉, 모든 상태 변화의 중간 허브다.

Pod 생성 흐름을 아주 쉽게 보면

사용자 → kube-apiserver → etcd 저장
                    ↓
              scheduler가 노드 선택
                    ↓
              kube-apiserver 업데이트
                    ↓
                kubelet이 실행
                    ↓
              kube-apiserver에 상태 보고
                    ↓
                  etcd 업데이트

Pod 생성 과정 상세

1. 요청이 들어오면 먼저 인증과 검증이 수행된다.

2. kube-api-server는 Pod 객체를 생성한다.
3. 이때 아직 어떤 노드에도 할당되지 않은 상태이다.

4. 해당 정보를 etcd 서버에 저장한다.

5. 사용자에게 Pod가 생성되었다는 응답을 반환한다.

6. Scheduler는 계속해서 API Server를 모니터링하고 있다.

7. Scheduler는 다음 상태: 노드가 할당되지 않은 새로운 Pod 를 발견한다.

8. Scheduler는 적절한 노드를 선택하고 그 정보를 kube-api-server에 전달한다.

kube-api-server는 다음 작업을 수행한다.

10. etcd 클러스터에 노드 할당 정보를 업데이트한다.

11. 해당 워커 노드의 kubelet에게 정보를 전달한다.

kubelet은 다음 작업을 수행한다.

13. 해당 노드에 Pod를 생성한다.

14. 컨테이너 런타임 엔진(container runtime)을 사용해 애플리케이션 이미지를 실행한다.

16. 작업이 완료되면 kubelet은 Pod 상태 정보를 API Server에 전달한다.

17. 그리고 API Server는 etcd에 상태 정보를 다시 업데이트한다.

설치 방식에 따른 차이

1. kubeadm으로 설치한 경우

kube-apiserver를 kubeadm이 자동으로 구성
보통 kube-system 네임스페이스의 Pod로 실행

kubectl get pods -n kube-system

2. from scratch로 설치한 경우

kube-apiserver 바이너리를 직접 설치
Master 노드에서 서비스로 실행하도록 설정해야 함

ps -ef | grep kube-apiserver

또는 서비스 파일 확인.

인증서 옵션

Kubernetes의 각 컴포넌트에는 인증서가 존재한다

많은 옵션들이 TLS 인증서(certificates) 와 관련되어 있다.

이 인증서는 Kubernetes 컴포넌트 간 통신을 보안적으로 보호한다.

--etcd-servers : kube-api-server가 어떤 etcd 서버에 연결할지를 설정하는 옵션

기존 클러스터에서 kube-api-server 옵션 확인 방법

kubeadm으로 설치한 경우

kubeadm은 kube-api-server를 Pod 형태로 배포한다.

위치 : kube-system namespace

Pod 정의 파일 위치: /etc/kubernetes/manifests/

kubeadm이 아닌 경우 (from scratch)

이 경우 kube-api-server는 systemd 서비스로 실행된다.

서비스 파일 위치: /etc/systemd/system/kube-apiserver.service

또는 다음 명령어로 실행 중인 프로세스를 확인할 수도 있다.

ps -ef | grep kube-apiserver

이 명령어로 실제 실행 중인 옵션들을 확인할 수 있다.

kube-controller-manager

시스템의 다양한 컴포넌트 상태를 지속적으로 모니터링
시스템을 원하는 상태(desired state) 로 유지하도록 동작

Node Controller

역할

노드 상태 모니터링
애플리케이션이 정상적으로 실행되도록 유지

Node Controller는 kube-api-server를 통해 노드 상태를 확인한다.

동작 방식

Node Controller는 5초마다 노드 상태를 확인한다.

이 과정을 통해 노드의 건강 상태를 모니터링한다.

장애 처리

Node Controller가 어떤 노드에서 heartbeat를 받지 못하면

즉시 장애 처리하지 않는다. 먼저 40초 동안 기다린다.

그래도 heartbeat가 오지 않으면 해당 노드를 Unreachable 상태로 표시한다.

노드 복구 대기

노드가 Unreachable 상태가 되면 5분 동안 노드가 복구되기를 기다린다.

만약 복구되지 않으면

해당 노드에 있던 Pod들을 제거
다른 정상 노드에 Pod를 다시 생성

Replication Controller 예시

또 다른 컨트롤러는 Replication Controller이다.

이 컨트롤러의 역할:

ReplicaSet 상태 모니터링
항상 원하는 Pod 개수 유지

-> 만약 Pod 하나가 죽으면 새 Pod를 생성하여 개수를 맞춘다.

지금까지는 두 개만 설명했지만 Kubernetes에는 훨씬 많은 컨트롤러가 존재한다.

Deployment controller
Service controller
Namespace controller
Persistent Volume controller

Kubernetes의 많은 기능과 자동화 로직은 이 컨트롤러들로 구현되어 있다.

Controller = Kubernetes 자동화 로직의 핵심

Controller Manager

이 많은 컨트롤러들은 Kube Controller Manager 라는 하나의 프로세스 안에 포함되어 있다.

Controller Manager = 여러 Controller들의 집합

Controller Manager 설치

Controller Manager를 설치하면

여러 컨트롤러들이 함께 설치된다.

설치 방법:

Kubernetes 릴리스 페이지에서 kube-controller-manager 다운로드
압축 해제
서비스(service)로 실행

Controller Manager 실행 옵션

Controller Manager는 실행 시 다양한 옵션을 사용할 수 있다.

예를 들어 앞에서 설명한

node monitor period
grace period
eviction timeout

같은 설정을 옵션으로 지정할 수 있다.

특정 Controller만 활성화

다음 옵션을 사용하면

--controllers

활성화할 컨트롤러를 선택할 수 있다.

기본적으로는 모든 컨트롤러가 활성화되어 있다.

하지만 특정 컨트롤러만 활성화하도록 설정할 수도 있다.

만약 어떤 컨트롤러가 동작하지 않는다면

controllers 옵션

을 확인

Controller Manager 설정 확인 방법

클러스터 설정 방식에 따라 확인 방법이 다르다.

kubeadm으로 설치한 경우

kubeadm은 Controller Manager를 Pod로 실행한다.

위치 : kube-system namespace

Pod 설정 파일 위치: /etc/kubernetes/manifests/

kubeadm이 아닌 경우

Controller Manager는 서비스(service) 로 실행된다.

서비스 파일 위치 : /etc/systemd/system/

또는 실행 중인 프로세스를 확인할 수도 있다.

예: ps -ef | grep kube-controller-manager

이 명령으로 실행 옵션을 확인할 수 있다.

kube scheduler

Kubernetes Scheduler는 Pod를 어떤 Node에 배치할지 결정하는 역할을 한다.

Scheduler는 Pod를 실제로 Node에 배치하지 않는다.

Pod를 실제로 생성하는 것은 kubelet의 역할이다.

비유하자면,

Scheduler → 어떤 배(ship)에 어떤 컨테이너를 실을지 결정하는 사람
kubelet → 실제로 컨테이너를 배에 실어주는 선장(captain)

Scheduler = Pod 배치 결정
kubelet = Pod 실제 생성

Scheduler가 필요한 이유

클러스터에는 여러 개의 Node와 여러 개의 Pod가 있다.

Scheduler는 다음을 고려해야 한다.

Pod의 CPU / Memory 요구사항
Node의 리소스 용량
특정 Node에 배치해야 하는 애플리케이션
특정 Node를 피해야 하는 경우

즉 올바른 Pod가 올바른 Node에 배치되도록 결정한다.

Scheduler 동작 방식

Scheduler는 Pod를 Node에 배치할 때 두 단계를 거친다.

1. Filtering 단계

먼저 Pod의 요구사항을 만족하지 못하는 Node들을 제거한다.

예를 들어 Pod가 다음과 같은 리소스를 요구한다고 하자.

CPU: 4
Memory: 8GB

Scheduler는 Node들을 검사하면서

리소스가 부족한 Node
조건에 맞지 않는 Node

들을 제거한다.

즉 적합하지 않은 Node 제거이다.

2. Ranking 단계

Filtering을 통과한 Node들 중에서 가장 적합한 Node를 선택한다.

Scheduler는 Priority Function을 사용하여 Node에 점수를 매긴다.

점수 범위: 0 ~ 10

예를 들어 Pod를 배치했을 때 남는 리소스가 많은 Node가 더 높은 점수를 받을 수 있다.

예: Node남는 CPU

Node A	2
Node B	6

Node B가 더 높은 점수를 받게 된다.

그래서 Scheduler는 Node B를 선택한다.

Scheduler 커스터마이징

Scheduler 동작은 사용자가 커스터마이징할 수도 있다.

예를 들어:

Custom Scheduler 작성
스케줄링 정책 변경

Kubernetes에는 스케줄링과 관련된 많은 기능이 있다.

예:

Resource requests / limits
Taints and tolerations
Node selectors
Node affinity

Scheduler 설치

Scheduler를 직접 설치하려면 다음과 같은 과정을 거친다.

1. Kubernetes release 페이지에서 kube-scheduler 바이너리 다운로드

2. 압축 해제

3. 서비스(service)로 실행

Scheduler 실행 시에는 scheduler configuration 파일을 지정한다.

Scheduler 설정 확인 방법

클러스터 구성 방식에 따라 확인 방법이 다르다.

kubeadm으로 설치한 경우

kubeadm은 Scheduler를 Pod 형태로 배포한다.

위치: kube-system namespace

설정 파일 위치: /etc/kubernetes/manifests/

실행 중인 프로세스 확인

Master 노드에서 다음 명령으로 확인할 수도 있다.

ps -ef | grep kube-scheduler

이 명령으로 실행 옵션과 설정값을 확인할 수 있다.

kubelet

kubelet은 배(ship)의 선장(captain) 과 같다.

선장은 배에서 일어나는 모든 활동을 관리한다.

예를 들어:

클러스터에 참여하기 위해 필요한 모든 절차를 수행한다.
마스터와 통신하는 유일한 연락 창구 역할을 한다.
마스터의 스케줄러가 지시하면 컨테이너를 배에 싣거나 내린다.
배와 컨테이너 상태를 정기적으로 보고한다.

Kubernetes에서 kubelet 역할

Kubernetes에서 worker node에 있는 kubelet은 다음 역할을 한다.

1.노드를 Kubernetes 클러스터에 등록한다.

2. Pod나 컨테이너를 실행하라는 명령을 받으면

컨테이너 런타임 엔진(예: Docker)을 통해

필요한 이미지를 pull 하고
컨테이너를 실행한다.

3. 실행된 Pod와 컨테이너 상태를 지속적으로 모니터링한다.

4. 상태 정보를 kube-apiserver에 주기적으로 보고한다.

kubelet 설치

kubelet 설치 방법을 보자.

만약 kubeadm을 사용해 클러스터를 배포했다면

kubeadm은 kubelet을 자동으로 배포하지 않는다.

이것이 다른 컴포넌트와 다른 점이다.

kubelet은 항상 worker node에 직접 설치해야 한다.

설치 과정은 다음과 같다.

1. kubelet 설치 파일 다운로드
2. 압축 해제
3. 서비스(service)로 실행

kubelet 실행 상태 확인

worker node에서 다음 명령어로 실행 중인 kubelet을 확인할 수 있다.

ps -ef | grep kubelet

이 명령어를 사용하면

실행 중인 kubelet 프로세스
실행 옵션

을 확인할 수 있다.

kube proxy

Kubernetes에서는 모든 Pod가 다른 모든 Pod와 통신할 수 있다.

이것은 Pod 네트워크를 통해 가능하다.

Pod 네트워크는 클러스터의 모든 노드에 걸쳐 있는 내부 가상 네트워크이다.

모든 Pod는 이 네트워크에 연결되어 있고, 이 네트워크를 통해 서로 통신할 수 있다.

Service를 사용하는 이유

예를 들어 다음과 같은 상황을 생각해 보자.

첫 번째 노드에는 웹 애플리케이션 Pod
두 번째 노드에는 데이터베이스 Pod

웹 애플리케이션은 데이터베이스 Pod의 IP 주소를 사용해서 접근할 수 있다.

하지만 문제가 있다.

Pod의 IP 주소는 항상 동일하게 유지되지 않는다.

Pod가 재시작되거나 재생성되면 IP가 바뀔 수 있다.

그래서 Kubernetes에서는 Service를 사용한다.

Service를 생성하면 데이터베이스 애플리케이션을 클러스터 전체에서 접근 가능하게 노출할 수 있다.

예를 들어 Service 이름: DB라고 하자.

웹 애플리케이션은 이제 DB라는 서비스 이름으로 데이터베이스에 접근할 수 있다.

Service에는 IP 주소도 하나 할당된다.

Pod가 Service의 이름이나 IP로 요청을 보내면

Service는 해당 요청을 백엔드 Pod(데이터베이스 Pod) 로 전달한다.

단, Service는 실제 컨테이너가 아니다.

Pod처럼 실제로 실행되는 것이 아니다.
네트워크 인터페이스도 없다.
실제 프로세스도 없다.

Service는 Kubernetes 내부 메모리에 존재하는 가상 객체이다.

Service는 실제 실행되는 객체가 아니라,
백엔드 Pod 집합에 대해 고정된 이름/IP와 접근 경로를 제공하는 가상 리소스다.
실제 트래픽 전달은 kube-proxy 등의 네트워크 규칙이 수행한다.

Service 에 접근하는 방법

Service는 실제 프로세스가 아니지만 클러스터의 어떤 노드에서도 접근 가능해야 한다.

이 기능을 제공하는 것이 바로 kube-proxy 이다.

역할

새로운 Service가 생성되는지 감시한다.
Service가 생성되면 각 노드에 트래픽 전달 규칙을 만든다.
Service로 들어온 요청을 실제 Pod로 전달한다.

동작 방식

kube-proxy는 주로 iptables 규칙을 사용한다.

Service IP : 10.96.0.1
실제 Pod IP: 10.32.0.15

kube-proxy는 다음과 같은 규칙을 만든다.

Service IP로 들어온 트래픽

↓
실제 Pod IP로 전달

Service → Backend Pod 으로 트래픽을 전달하도록 설정한다.

kube-proxy 설치

kube-proxy 설치 방법은 다음과 같다.

Kubernetes release 페이지에서 kube-proxy 바이너리 다운로드
압축 해제
서비스(service)로 실행

kubeadm을 사용할 경우

kubeadm을 사용하면 kube-proxy는 Pod 형태로 자동 배포된다.

그리고 kube-proxy는 DaemonSet으로 배포된다.

DaemonSet이란 클러스터의 모든 노드에 하나씩 Pod가 실행되도록 보장하는 Kubernetes 객체이다.

각 노드마다 kube-proxy Pod 1개가 항상 실행된다.

pods

Pods를 이해하기 전에 몇 가지 전제가 있다.

우리는 이미 다음이 준비되어 있다고 가정한다.

애플리케이션이 개발되어 있다.
애플리케이션이 Docker 이미지로 빌드되어 있다.
Docker Hub 같은 Docker 레지스트리에 업로드되어 있다.
Kubernetes가 이미 이미지를 pull 할 수 있다.
Kubernetes 클러스터가 이미 구축되어 있다.

클러스터는 다음과 같을 수 있다.

단일 노드 클러스터
멀티 노드 클러스터

어떤 형태든 상관없다.

또한 Kubernetes의 모든 서비스가 정상적으로 실행 중이라고 가정한다.

목표 : Kubernetes 클러스터의 Worker Node에 컨테이너 형태로 애플리케이션을 배포하는 것

하지만 Kubernetes는 컨테이너를 직접 노드에 배포하지 않는다.

대신 컨테이너는 pod 객체 안에서 실행된다.

Pod 란?

Pod는 다음과 같다.

Kubernetes에서 생성할 수 있는 가장 작은 단위의 객체
애플리케이션의 단일 인스턴스

예를 들어 가장 간단한 구조는 다음과 같다.

Kubernetes Node
└ Pod
└ Container (App)

Pod 안에 컨테이너가 있고
컨테이너 안에서 애플리케이션이 실행된다.

애플리케이션 스케일링

웹 애플리케이션 트래픽이 증가하면 애플리케이션 인스턴스를 늘려야 한다.

이때 선택지는 두 가지가 있다.

기존 Pod 안에 컨테이너 추가
새로운 Pod 생성

정답은 새로운 Pod 생성 이다.

Node
 ├ Pod1 → App container
 └ Pod2 → App container

즉 Pod를 복제하여 스케일링한다.

노드 리소스 부족

만약 현재 노드에 리소스가 부족하면 어떻게 할까?

새로운 노드를 클러스터에 추가할 수 있다.

Node1
├ Pod1
└ Pod2

Node2
└ Pod3

Pod는 여러 노드에 분산 배치될 수 있다.

Pod와 Container 관계

대부분의 경우 다음 관계가 성립한다.

Pod : Container = 1 : 1

하나의 Pod
하나의 애플리케이션 컨테이너

스케일링 방법

스케일링은 다음과 같이 한다.

스케일 업

Pod 추가

스케일 다운

Pod 삭제

주의할 점:

기존 Pod에 컨테이너를 추가해서 스케일하지 않는다.

Pod에 여러 컨테이너가 가능할까?

가능하다.

Pod에는 여러 컨테이너가 들어갈 수 있다.

하지만 일반적으로 같은 종류의 컨테이너를 여러 개 넣지는 않는다.

대신 다음과 같은 경우가 있다.

Helper Container (Sidecar)

예를 들어

웹 애플리케이션 컨테이너
파일 처리 컨테이너
로그 처리 컨테이너

같이 보조 역할(helper) 을 하는 컨테이너가 있을 수 있다.

이 경우 같은 Pod에 넣는다.

Pod
├ App Container
└ Helper Container

같은 Pod의 컨테이너 특징

같은 Pod 안의 컨테이너는 다음을 공유한다.

네트워크: localhost로 서로 통신 가능
스토리지: 같은 볼륨 공유 가능
생명주기: 같이 생성, 같이 종료=

Kubernetes가 해결해주는 문제

만약 Kubernetes 없이 Docker만 사용한다면 다음을 직접 관리해야 한다.

컨테이너 연결 관계
네트워크 연결
볼륨 공유
컨테이너 상태 모니터링
컨테이너 종료 시 정리 작업

하지만 Kubernetes에서는 Pod 정의만 하면 자동으로 관리된다.

Multi Container Pod

여러 컨테이너가 있는 Pod는 가능하지만 실제 사용 사례는 많지 않다.

그래서 이 강의에서는 대부분 Pod = Container 1개 구조를 사용한다.

Pod 생성

Pod를 생성하려면 다음 명령어를 사용한다.

kubectl run nginx --image=nginx

이 명령은 내부적으로 다음을 수행한다.

Pod 생성
nginx 컨테이너 실행

이미지 다운로드

이미지는 DockerHub 위치에서 가져온다.

Docker Hub는 Docker 이미지 저장소이다.

사설 레지스트리
조직 내부 레지스트리

도 사용할 수 있다.

Pod 목록을 확인하려면 다음 명령어를 사용한다.

kubectl get pods
--------------------------------------
NAME     READY   STATUS
nginx    0/1     ContainerCreating

곧 상태가 Running으로 바뀐다.

지금 상태에서는 nginx 웹 서버가 외부에서 접근 가능하지 않다.

노드 내부에서는 접근할 수 있지만

외부 사용자에게 공개하려면 Service 가 필요하다.

KEDA 필요성, HPA 와의 차이점

minsu20 — Sun, 18 Jan 2026 23:24:42 +0900

Kubernetes를 운영하면서 가장 큰 장점 중 하나는 트래픽에 따라 파드(Pod)의 수를 자동으로 조절하는 Autoscaling 기능입니다. 우리는 보통 HPA(Horizontal Pod Autoscaler) 를 통해 이를 구현합니다. 하지만, CPU나 메모리 사용량은 낮은데 처리해야 할 작업(이벤트)이 쌓여 서비스가 지연되는 경험을 해보신 적이 있나요? 이번 글에서는 HPA의 한계를 짚어보고, 이를 보완하기 위해 등장한 KEDA(Kubernetes Event-driven Autoscaling)가 왜 필요한지, 그리고 둘의 차이점은 무엇인지 알아보겠습니다.

HPA 란?

HPA는 쿠버네티스의 기본 리소스 오토스케일러입니다.

작동 원리: 주로 CPU 사용량이나 메모리 사용량 같은 리소스 메트릭을 주기적으로 확인하여 스케일링을 결정합니다.
장점: 설정이 간편하고, 일반적인 웹 서버와 같이 리소스 사용량이 트래픽과 비례하는 애플리케이션에 적합합니다.

리소스 기반 스케일링의 한계

HPA는 훌륭하지만, 이벤트 기반 아키텍처에서는 한계가 있습니다.

반응 속도의 지연: 메시지 큐(Kafka, RabbitMQ 등)에 메시지가 1만 개가 쌓여도, 파드가 이를 처리하느라 CPU를 본격적으로 쓰기 전까지는 스케일링이 일어나지 않습니다.
외부 메트릭 연동의 복잡함: 기본 HPA로 특정 큐의 길이나 외부 API 수치를 기반으로 스케일링하려면, 별도의 Metrics Adapter를 구축해야 하는 등 설정이 매우 복잡해집니다.
Scale to Zero 불가: HPA는 기본적으로 최소 1개의 파드를 유지해야 합니다. 작업이 없을 때 아예 0개로 줄여 비용을 절감하는 것이 불가능합니다.

KEDA (Kubernetes Event-driven Autoscaling)

KEDA는 이름 그대로 "이벤트 기반"의 오토스케일링을 가능하게 해줍니다.

다양한 Scaler 지원: Kafka, AWS SQS, Prometheus, Redis 등 60개 이상의 외부 이벤트 소스를 기본적으로 지원합니다.
Scale to Zero: 처리할 이벤트가 없으면 파드 수를 0으로 줄였다가, 이벤트가 발생하면 즉시 파드를 생성합니다. (비용 절감 효과)
HPA와의 공존: KEDA는 HPA를 대체하는 것이 아니라, HPA에게 "언제 스케일링해야 하는지"에 대한 외부 메트릭을 제공하는 역할을 합니다. (실제 스케일링은 HPA가 수행)

ScaledObject(사용자 선언)
   ↓ (KEDA Operator)
HPA(자동 생성/관리)
   ↓ (HPA가 질의)
KEDA Metrics Server(external.metrics API)
   ↓ (KEDA Scaler가 이벤트 소스 조회)
Event Source(Kafka/RabbitMQ/Prometheus/CloudWatch/…)

KEDA는 다양한 이벤트 소스에 대응하는 scaler (공식문서 링크)를 제공하고, 각 scaler가 이벤트 기반 활성화 여부 판단과 메트릭 제공을 담당해 HPA가 이를 기반으로 스케일링하도록 연결합니다.

비교 항목	HPA (기본)	KEDA
스케일링 기준	CPU, Memory (리소스 중심)	Queue Length, Lag, Stream 등 (이벤트 중심)
반응성	리소스 사용량이 증가해야 반응 (Reactive)	이벤트 발생 즉시 반응 (Proactive)
Scale to Zero	불가능 (최소 1개 유지)	가능 (0개로 축소 가능)
외부 연동	복잡함 (Custom Metrics Adapter 필요)	간편함 (다양한 내장 Scaler 제공)
주요 사용처	일반적인 웹 애플리케이션	백그라운드 워커, 데이터 프로세싱, 큐 처리

[LIS] 최장 증가 부분 수열

minsu20 — Thu, 1 Aug 2024 16:02:29 +0900

최장 증가 부분 수열(LIS, Longest Increasing Subsequence)란?

원소가 n개인 배열의 일부 원소를 골라내서 만든 부분 수열 중, 다음 조건을 만족하는 수열이다.

각 원소가 이전 원소보다 크다. (증가하고 있다)
그 길이가 최대이다

예를 들어, { 6, 2, 5, 1, 7, 4, 8, 3} 이라는 배열이 있을 경우, LIS는 { 2, 5, 7, 8 } 이다.

구현 방법

DP를 이용한 방법
이분탐색을 이용한 방법

DP를 이용한 방법

알고리즘 설명

간단하지만 시간복잡도가 O(n^2)로 이분탐색보다는 큰 알고리즘이다

dp[i]: i번째 인덱스에서 끝나는 최장 증가 부분 수열의 길이

라고 한다면,

주어진 배열에서 인덱스를 한 칸씩(i+=1) 늘려가면서 확인합니다.
내부 반복문으로 i보다 작은 인덱스들을 하나씩 살펴(j+=1) 보면서 arr[j] < arr[i]인 것이 있을 경우
(내부 반복문 변수 j의 배열 값이 현재 인덱스 i 배열 값보다 작다면)
dp[i] = Math.max(dp[i], dp[j] + 1)로 업데이트한다.
1. dp[i]: 기존의 dp[i]값
2. dp[j]+1 : (내부 반복문 변수) j번째 인덱스에서 끝나는 최장 증가 부분 수열의 마지막에 arr[i]를 추가했을 때의 값 (+1)

이때 dp[i]값 중에서 가장 큰 값이 최장 증가 수열의 길이가 된다.

코드

public class LIS_DP {
    public static void main(String[] args) {
        int arr[] = {3, 2, 4, 1, 6};
        int dp[] = new int[arr.length];
        dp[0] = 1; // LIS의 첫 번째는 항상 1이다.
 
        for (int i = 1; i < arr.length; i++) {
            // 첫 원소부터 i원소 전까지 비교
            for (int j = 0; j < i; j++) {
                if (arr[j] < arr[i]) {
                    dp[i] = Math.max(dp[i], dp[j] + 1);
                }
                //  증가 부분 수열의 길이는 1부터 시작하므로 0인 값을 1으로 변경해준다.
                if (dp[i] == 0) {
                    dp[i] = 1;
                }
            }
        }
 
        System.out.println("arr : " + Arrays.toString(arr));
        System.out.println("DP  : " + Arrays.toString(dp));
    }
}

예시

이분탐색을 이용한 방법

알고리즘 설명

DP보다는 복잡하지만 시간복잡도가 O(nlogn)으로 DP보다 효율적이다.

LIS의 형태를 유지하기 위해 주어진 배열의 인덱스를 하나씩 살펴보면서 그 숫자가 들어갈 위치를 이분탐색으로 탐색해서 넣는다.

이분 탐색을 활용할 때는 정확한 수열 값이 아닌 길이를 구해야 할 때 사용한다.

코드

import java.io.*;
import java.util.StringTokenizer;

public class Main {
	
	static int[] memo;
	static int INF = Integer.MIN_VALUE;

	public static void main(String[] args) throws IOException{
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		int n = Integer.parseInt(br.readLine());
		int[] arr = new int[n];
		
		StringTokenizer st= new StringTokenizer(br.readLine());
		for(int i=0; i<n; i++) {
			arr[i] = Integer.parseInt(st.nextToken());
		}
		
		memo = new int[n+1];
		int len=0;
		int idx=0;
		for(int i=0; i<n; i++) {
			if(arr[i] > memo[len]) {
				len +=1;
				memo[len] = arr[i];
			}else {
				idx = binarySearch(0,len, arr[i]);
				memo[idx] = arr[i];
			}
		}
		System.out.println(len);
	}
	
	static int binarySearch(int left, int right, int key) {
		int mid =0;
		while(left<right) {
			mid = (left+right)/2;
			if(memo[mid] < key) {
				left = mid+1;
			}else {
				right = mid;
			}
		}
		return right;
	}
}

예시

[백준] 2225번: 합분해 -JAVA

minsu20 — Thu, 1 Aug 2024 13:59:37 +0900

문제 바로 가기 > 2225번: 합분해

다이나믹 프로그래밍을 풀 수 있는 문제이다.

알고리즘 풀이

만약 입력에 예제처럼 6, 4가 주어졌다면

6= 0(3번 더해서 0이 되는 경우) + 6
6= 1 (3번 더해서 1이 되는 경우) + 5
6= 2 (3번 더해서 2가 되는 경우) + 4
6= 3 (3번 더해서 3이 되는 경우) + 3
6= 4 (3번 더해서 4가 되는 경우) + 2
6= 5 (3번 더해서 5가 되는 경우) + 1
6= 6 (3번 더해서 6이 되는 경우) + 0

따라서

dp[K][N]: N이하의 정수를 K번 더해서 합이 N이 되는 경우의 수

라고 한다면 위의 경우에는 다음과 같이 표현할 수 있다.

dp[4][6]=dp[3][0]+dp[3][1]+dp[3][2]+dp[3][3]+dp[3][4]+dp[3][5]+dp[3][6];

이를 일반화한다면

dp[K][N]=dp[K-1][0]+dp[K-1][1]+dp[K-1][2]+...+dp[K-1][N-1]+dp[K-1][N]

이때

dp[K-1][0]+dp[K-1][1]+dp[K-1][2]+...+dp[K-1][N-1]=dp[K][N-1]이다.

따라서 dp[K][N]=dp[K][N-1]+dp[K-1][N]

전체 코드

import java.util.*;
import java.io.*;

public class _2225 {
    public static void main(String[] args) throws IOException {
        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st=new StringTokenizer(br.readLine());
        int n=Integer.parseInt(st.nextToken()); //최대수
        int k=Integer.parseInt(st.nextToken()); //가지수
        long DIV_NUM=1000000000;

        long max=0;
        long[][] dp=new long[k+1][n+1];
        for(int i=1;i<=k;i++){
            dp[i][0]=1;
        }

        for(int i=1;i<=k;i++){
            for(int j=1;j<=n;j++){
                dp[i][j]=(dp[i-1][j]+dp[i][j-1])%DIV_NUM;
            }
        }

        System.out.println(dp[k][n]);

    }
}

[백준] 4384번: 공평하게 팀 나누기 -JAVA

minsu20 — Wed, 31 Jul 2024 23:22:20 +0900

문제 바로 가기 > 4384번: 공평하게 팀 나누기

0/1 냅색 알고리즘으로, DP로 풀 수 있다.

이 문제는 '부분집합의 합' 문제의 변형으로 볼 수 있다. 우리의 목표는 전체 무게의 절반에 가장 가까운 부분집합을 찾는 것이다.

2차원 boolean 배열 dp를 사용합니다.
dp[i][j]는 i명의 사람을 선택하여 정확히 j 무게를 만들 수 있는지 여부를 나타낸다 (true/false)

알고리즘

1. dp 배열 초기화: dp[0][0] = true (0명으로 0kg을 만들 수 있음)

2. 각 참가자에 대해:

1명부터 전체 인원의 절반까지 선택하는 경우를 고려
가능한 모든 무게 조합을 계산하여 dp 배열 갱신

for(int i=0; i<n; i++){
    for(int j=n/2; j>0; j--){
        for(int k=totalWeight; k>=weights[i]; k--){
            dp[j][k] = dp[j][k] || dp[j-1][k-weights[i]];
        }
    }
}

3. dp[전체 인원의 절반][k]가 true인 k 중 전체 무게의 절반에 가장 가까운 값 선택

for(int k=0;k<=totalWeight;k++){
    if(dp[n/2][k]){
        int a=k;
        int b=totalWeight-a;
        int curDif=Math.abs(a-b);
        if(minDif>curDif){
            minDif=curDif;
            team1weight=k;
        }
    }
}

예시

입력이 다음과 같이 주어졌다.

4
30
40
50
60

Step1. 배열 초기화

j/k	0
0	T

Step2. dp배열 갱신

i = 0 (30kg 참가자 추가)

j = 2 (2명)
- k는 180부터 30까지 감소
j = 1 (2명)
- k는 180부터 30까지 감소
- dp[1][30] = dp[1][30] || dp[0][0] = true

j/k	0	30
0	T	F
1	F	T
2	F	F

i = 1 (40kg 참가자 추가)

j = 2 (2명)
- k는 180부터 40까지 감소
- dp[2][70] = dp[2][70] || dp[1][30] = true
j = 1 (1명)
- k는 180부터 40까지 감소
- dp[1][40] = dp[1][40] || dp[0][0] = true

j/k	0	30	40	70
0	T	F	F	F
1	F	T	T	F
2	F	F	F	T

i = 2 (50kg 참가자 추가)

j = 2 (2명)
- k는 180부터 50까지 감소
- dp[2][90] = dp[2][90] || dp[1][40] = true
- dp[2][80] = dp[2][80] || dp[1][30] = true
j = 1 (1명)
- k는 180부터 50까지 감소
- dp[1][50] = dp[1][50] || dp[0][0] = true

j/k	0	30	40	50	70	80	90
0	T	F	F	F	F	F	F
1	F	T	T	T	F	F	F
2	F	F	T	F	T	T	T

i = 3 (60kg 참가자 추가)

j= 2 (2명)
- k는 180부터 60까지 감소
- dp[2][120] = dp[2][120] || dp[1][60] = true
- dp[2][110] = dp[2][110] || dp[1][50] = true
- dp[2][100] = dp[2][100] || dp[1][40] = true
- dp[2][90] = dp[2][90] || dp[1][30] = true
j = 1 (1명)
- k는 180부터 60까지 감소
- dp[1][60] = dp[1][60] || dp[0][0] = true

j/k	0	30	40	50	60	70	80	90	100	110	120
0	T	F	F	F	F	F	F	F	F	F	F
1	F	T	T	T	T	F	F	T	F	F	F
2	F	F	T	F	F	T	T	T	T	T	T

Step3. dp[전체 인원의 절반][k]가 true인 k 중 전체 무게의 절반에 가장 가까운 값 선택

dp[2][k]가 true인 k중에서 무게의 절반(90)에 가장 가까운 값은 90이다.
따라서 답은 90 90이 된다.

j/k	0	30	40	50	60	70	80	90	100	110	120
2	F	F	T	F	F	T	T	T	T	T	T

전체 코드

import java.io.*;

public class _4384 {

    public static void main(String[] args) throws IOException {
        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
        int n=Integer.parseInt(br.readLine());
        int[] weights=new int[n+1];
        int totalWeight=0;
        int minDif=Integer.MAX_VALUE;
        int team1weight=0;
        int team2weight=0;

        for(int i=0;i<n;i++){
            weights[i]=Integer.parseInt(br.readLine());
            totalWeight+=weights[i];
        }
        boolean[][] dp=new boolean[n][totalWeight+1];


        dp[0][0]=true;

        for(int i=0;i<n;i++){
            for(int j=n/2;j>0;j--){
                for(int k=totalWeight;k>=weights[i];k--){
                    dp[j][k]=dp[j][k]||dp[j-1][k-weights[i]];
                }
            }
        }


        for(int k=0;k<=totalWeight;k++){
            if(dp[n/2][k]){
                int a=k;
                int b=totalWeight-a;
                int curDif=Math.abs(a-b);
                if(minDif>curDif){
                    minDif=curDif;
                    team1weight=k;
                }
            }
        }

        team2weight=totalWeight-team1weight;

        if(team1weight>team2weight){
            int temp=team1weight;
            team1weight=team2weight;
            team2weight=temp;
        }

        System.out.println(team1weight+" "+team2weight);

    }
}

[백준] 11000번: 강의실 배정 - JAVA

minsu20 — Mon, 29 Jul 2024 18:45:49 +0900

문제 바로가기> 11000번: 강의실 배정

그리디 알고리즘으로, 우선순위 큐를 이용해서 풀 수 있다.

1 ≤ N ≤ 200,000이므로 브루트포스를 돌리면 당연히 시간초과가 난다.
따라서 정렬을 이용한 우선순위 큐를 이용해 그리디 알고리즘으로 풀어야 한다.

정렬 기준

그렇다면 어떤 기준으로 정렬을 해야할까?

처음에 필자는 종료시각을 기준으로 (빨리 끝나는 시각 순으로 오름차순) 정렬을 해서 틀렸다...

시작 시각으로 정렬을 해야 앞에서부터 차곡 차곡 강의 간의 텀을 짧게 해 배정이 가능한 것이었다.

종료 시간을 우선순위 큐에 넣고 비교

정렬 자체는 시작 시각을 기준으로 하였지만, 결국 어떤 강의가 들어갈 자리를 찾기 위해서는 종료시각과 비교를 해야 한다.

따라서 그러기 위해서는 종료 시각을 담는 우선순위 큐가 필요하다. 이때 당연히 오름차순으로 정렬을 해야 한다.

그렇다면 우선순위 큐에서 top위치값은 종료시각이 가장 빠른 강의의 종료시각이 된다.

그리고 앞에서 정렬한 모든 강의의 시작 시각과 우선순위 큐의 top와 비교한다. (반복문)

만약, 현재 강의의 시작 시각 >= 우선순위 큐의 top (종료시각)

우선순위 큐에서 top에 있는 강의를 poll() (제거)
현재 강의의 종료시각을 우선순위 큐에 넣는다.

-> 원래 있던 강의실에 다음 강의를 배정하는 것이다. (우선순위 큐의 사이즈 변하지 않음)

아니라면

poll() x
현재 강의의 종료 시각을 우선순위 큐에 넣는다.

-> 새로운 강의실에 강의를 배정하는 것이다. (우선순위 큐의 사이즈 1 증가)

그리고 모든 강의가 배정이 되었다면, 우선순위 큐의 사이즈가 강의실의 개수가 된다.

왜 종료시각을 기준으로 오름차순하면 안될까?

반례를 통해 종료시각을 기준으로 오름차순 정렬을 하면 안되는 이유를 살펴보자.

1 3
2 5
4 12
7 8
7 11
9 10

이렇게 입력이 주어졌다고 하자

1) 시작시각 오름차순 정렬

오름차순으로 시작 시각을 정렬하면

1 3 - 강의 1
2 5 - 강의 2
4 12 - 강의 3
7 8 - 강의 4
7 11 - 강의 5
9 10 - 강의 6

이렇게 강의실이 저장이 된다.

강의 1부터 강의 6까지 반복해서 강의의 시작시각과 우선순위 큐의 종료시각을 비교하면 된다.

강의 1에서는

종료시각이 3이므로,

우선순위 큐: 3

1	2	3
강의실A	강의1

강의 2에서는

우선순위 큐의 top(3)>현재 강의실의 시작시각(2)이므로 poll x

우선순위 큐: 3, 5

1	2	3	4	5
강의실A	강의1
강의실B		강의2

강의 3에서는

우선순위 큐의 top(3)<현재 강의실의 시작시각(4)이므로 poll o

우선순위 큐: 5, 12

1	2	3	4	5	6	7	8	9	10	11	12
강의실A	강의1			강의3
강의실B		강의2

강의 4에서는

우선순위 큐의 top(5)<현재 강의실의 시작시각(7)이므로 poll o

우선순위 큐: 8, 12

1	2	3	4	5	6	7	8	9	10	11	12
강의실A	강의1			강의3
강의실B		강의2					강의4

강의 5에서는

우선순위 큐의 top(8)>현재 강의실의 시작시각이므로 poll x

우선순위 큐: 8, 11, 12

1	2	3	4	5	6	7	8	9	10	11	12
강의실A	강의1			강의3
강의실B		강의2					강의4
강의실C							강의5

강의 6에서는

우선순위 큐의 top(8)<현재 강의실의 시작시각이므로 poll o

우선순위 큐: 10, 11, 12

1	2	3	4	5	6	7	8	9	10	11	12
강의실A	강의1			강의3
강의실B		강의2					강의4		강의6
강의실C							강의5

따라서 강의실은 총 3개가 나온다.

2) 종료시각 오름차순 정렬

오름차순으로 종료 시각을 정렬하면

1 3 - 강의 1
2 5 - 강의 2
7 8 - 강의 3
9 10 - 강의 4
7 11 - 강의 5
4 12 - 강의 6

이렇게 강의실이 저장이 된다.

강의 1부터 강의 6까지 반복해서 강의의 시작시각과 우선순위 큐의 종료시각을 비교하면 된다.

강의 1에서는

종료시각이 3이므로,

우선순위 큐: 3

1	2	3
강의실A	강의1

강의 2에서는

우선순위 큐의 top(3)>현재 강의실의 시작시각(2)이므로 poll x

우선순위 큐: 3, 5

1	2	3	4	5
강의실A	강의1
강의실B		강의2

강의 3에서는

우선순위 큐의 top(3)<현재 강의실의 시작시각(7)이므로 poll o

우선순위 큐 : 5, 8

1	2	3	4	5	6	7	8
강의실A	강의1						강의3
강의실B		강의2

강의 4에서는

우선순위 큐의 top(5)<현재 강의실의 시작시각(9)이므로 poll o

우선순위 큐: 8, 10

1	2	3	4	5	6	7	8	9	10
강의실A	강의1						강의3
강의실B		강의2							강의 4

강의 5에서는

우선순위 큐의 top(8)>현재 강의실의 시작시각(7)이므로 poll x

우선순위 큐: 8, 10, 11

1	2	3	4	5	6	7	8	9	10	11
강의실A	강의1						강의3
강의실B		강의2							강의 4
강의실C							강의5

강의 6에서는

우선순위 큐의 top(8)>현재 강의실의 시작시각(4)이므로 poll x

우선순위 큐: 8, 10, 11, 12

1	2	3	4	5	6	7	8	9	10	11	12
강의실A	강의1						강의3
강의실B		강의2							강의 4
강의실C							강의5
강의실 D				강의6

따라서 종료시각을 기준으로 오름차순 정렬하면 총 4개의 강의실이 생기고 시작시각을 기준으로 오름차순 정렬하면 총 3개의 강의실이 생기므로 시작시간을 기준으로 오름차순해야 최소의 강의실 개수가 도출된다.

[백준] 20055번: 컨베이어 벨트 위의 로봇 - JAVA

minsu20 — Thu, 25 Jul 2024 15:58:01 +0900

문제 바로가기 > 20055번: 컨베이어 벨트 위의 로봇

단계마다 이동을 할 때 각 단계마다 다음 두 조건을 반드시 지켜야 한다.

1. 로봇은 1번칸인 올리는 위치에서만 올릴 수 있다.

2. 로봇은 N번칸인 내리는 위치에 도달하면 언제든지 내려야 한다.

각 단계마다 함수로 구현해준다.

Step 1 . 벨트와 로봇 회전

각 칸을 이동시켜준다
로봇을 이동시켜준다
이때, 위에 언급한 조건때문에 robot[N-1] (N칸) 위치와 robot[0] (1번째 칸) 위치를 false로 시켜줘야 한다.
- robot[N-1]=false: 내리는 위치에 도달하면 언제든 내려야 한다.
- robot[0]=false: 로봇은 올리는 위치에서 3번째 Step에서만 올릴 수 있지, 로봇이 2N칸에서 1칸으로 이동하면 안된다.

   public static void rotate() {
        //벨트가 각 칸 위에 있는 로봇과 함께 한 칸 회전한다.
        //언제든지 로봇이 내리는 위치에 도달하면 그 즉시 내린다.
        //이때 robot[2N-1]위치에 있는 로봇은 robot[0]에 추가하면 안된다.
        int temp = map[2 * N - 1];
        for (int i = 2 * N - 1; i > 0; i--) {
            map[i] = map[i - 1];
        }
        map[0] = temp;

        for (int i = N - 1; i > 0; i--) {
            robot[i] = robot[i - 1];
        }
        robot[0] = false;
        robot[N - 1] = false;
    }

Step 2. 로봇 이동

가장 먼저 벨트에 올라간 로봇부터, 벨트가 회전하는 방향으로 한 칸 이동할 수 있다면 이동한다.
만약 이동할 수 없다면 가만히 있는다.
- 로봇이 이동하기 위해서는 이동하려는 칸에 로봇이 없으며, 그 칸의 내구도가 1 이상 남아 있어야 한다.
- 이동하면 내구도는 1 감소한다.

public static void move() {
    //가장 먼저 벨트에 올라간 로봇부터, 벨트가 회전하는 방향으로 한 칸 이동할 수 있다면 이동한다.
    // 만약 이동할 수 없다면 가만히 있는다.
    //로봇이 이동하기 위해서는 이동하려는 칸에 로봇이 없으며, 그 칸의 내구도가 1 이상 남아 있어야 한다.
    for (int i = N - 2; i >= 0; i--) {
        if (robot[i]) {
            if (!robot[i + 1] && map[i + 1] >= 1) {
                robot[i + 1] = true;
                map[i + 1]--;
                robot[i] = false;
            }
        }

        robot[N - 1] = false;
    }

}

Step 3. 로봇 올리기

올리는 위치에 있는 칸의 내구도가 0이 아니면 올리는 위치에 로봇을 올린다.
- 이때도 내구도는 1 감소한다.

public static void addRobot() {
    //올리는 위치에 있는 칸의 내구도가 0이 아니면 올리는 위치에 로봇을 올린다.
    if (map[0] > 0) {
        map[0]--;
        robot[0] = true;
    }
}

Step 4. 내구도 검사

내구도가 0인 칸의 개수가 K개 이상이라면 과정을 종료한다. 그렇지 않다면 1번으로 돌아간다.

public static boolean check() {
    int zero = 0;
    for (int i = 0; i < 2 * N; i++) {
        if (map[i] == 0)
            zero++;
    }
    return zero >= K;
}

전체 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class _20055 {
    public static int[] map;
    public static boolean[] robot;
    public static int N, K;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        K = Integer.parseInt(st.nextToken());
        map = new int[N * 2];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < 2 * N; i++) {
            map[i] = Integer.parseInt(st.nextToken());
        }
        robot = new boolean[N];
        simulation();
    }

    public static void simulation() {
        int i = 0;
        while (!check()) {
            rotate();
            move();
            addRobot();
            i++;
        }
        System.out.println(i);
    }

    public static void rotate() {
        //벨트가 각 칸 위에 있는 로봇과 함께 한 칸 회전한다.
        //언제든지 로봇이 내리는 위치에 도달하면 그 즉시 내린다.
        //이때 robot[2N-1]위치에 있는 로봇은 robot[0]에 추가하면 안된다.
        int temp = map[2 * N - 1];
        for (int i = 2 * N - 1; i > 0; i--) {
            map[i] = map[i - 1];
        }
        map[0] = temp;

        for (int i = N - 1; i > 0; i--) {
            robot[i] = robot[i - 1];
        }
        robot[0] = false;
        robot[N - 1] = false;
    }

    public static void move() {
        //가장 먼저 벨트에 올라간 로봇부터, 벨트가 회전하는 방향으로 한 칸 이동할 수 있다면 이동한다.
        // 만약 이동할 수 없다면 가만히 있는다.
        //로봇이 이동하기 위해서는 이동하려는 칸에 로봇이 없으며, 그 칸의 내구도가 1 이상 남아 있어야 한다.
        for (int i = N - 2; i >= 0; i--) {
            if (robot[i]) {
                if (!robot[i + 1] && map[i + 1] >= 1) {
                    robot[i + 1] = true;
                    map[i + 1]--;
                    robot[i] = false;
                }
            }

            robot[N - 1] = false;
        }

    }

    public static void addRobot() {
        //올리는 위치에 있는 칸의 내구도가 0이 아니면 올리는 위치에 로봇을 올린다.
        if (map[0] > 0) {
            map[0]--;
            robot[0] = true;
        }
    }

    public static boolean check() {
        int zero = 0;
        for (int i = 0; i < 2 * N; i++) {
            if (map[i] == 0)
                zero++;
        }
        return zero >= K;
    }

}

j/k	0	30	40	50	60	70	80	90	100	110	120
0	T	F	F	F	F	F	F	F	F	F	F
1	F	T	T	T	T	F	F	T	F	F	F
2	F	F	T	F	F	T	T	T	T	T	T

j/k	0	30	40	50	60	70	80	90	100	110	120
0	T	F	F	F	F	F	F	F	F	F	F
1	F	T	T	T	T	F	F	T	F	F	F
2	F	F	T	F	F	T	T	T	T	T	T

j/k	0	30	40	50	60	70	80	90	100	110	120
0	T	F	F	F	F	F	F	F	F	F	F
1	F	T	T	T	T	F	F	T	F	F	F
2	F	F	T	F	F	T	T	T	T	T	T