대세는 쿠버네티스 (초급~중급편) 을 듣고 정리한 포스트입니다.

1. Container

Pod는 컨테이너를 1개 이상 담는 최소 배포 단위다. 쿠버네티스는 컨테이너를 직접 관리하지 않고 항상 Pod 단위로 다룬다.
컨테이너는 서비스가 연결될 수 있도록 포트를 가진다. 한 컨테이너가 여러 포트를 가질 수 있지만, 같은 Pod 안에서는 포트가 중복될 수 없다.
- 이유: Pod 내 컨테이너들은 네트워크 네임스페이스를 공유한다. 즉 포트 공간이 Pod 단위로 하나뿐이라 8080을 두 컨테이너가 동시에 쓸 수 없다.
네임스페이스를 공유하므로 Pod 내 컨테이너끼리는 localhost:포트로 서로 접근 가능하다.
Pod 생성 시 IP가 자동 할당되며, 이 IP는 클러스터 내부에서만 접근 가능하다. (외부 노출은 Service — NodePort/LoadBalancer/Ingress 필요)

2. Label

Pod뿐 아니라 Node, Service, Deployment 등 대부분의 오브젝트에 사용 가능.
목적에 따라 오브젝트를 분류하고, 분류된 것만 골라 연결하기 위해 사용한다.
key: value 형태, 한 오브젝트에 여러 개 부착 가능.
Pod에 라벨을 달고, Service의 selector에 같은 라벨을 명시하면 그 라벨을 가진 Pod들로 트래픽이 연결된다.

# Pod
metadata:
  labels:
    type: web
    ver: v1
---
# Service
spec:
  selector:
    type: web      # type: web 라벨을 가진 모든 Pod에 연결

보충

selector는 AND 조건이다. type: web과 ver: v1을 둘 다 쓰면 두 라벨을 모두 가진 Pod만 선택된다.
라벨은 동적이다. Pod의 라벨을 나중에 바꾸면 Service의 연결 대상도 즉시 바뀐다. (v1 → v2 전환, 문제 Pod를 Service에서 떼어내 디버깅하는 데 활용)
조회에 그대로 쓸 수 있다: kubectl get pods -l type=web
비슷하지만 다른 것 — Annotation: 형식은 같은 key:value지만 selector로 선택할 수 없다. 라벨은 "선택/연결용", 어노테이션은 "설명·메타정보 기록용"으로 구분하면 된다.
왜 Pod는 여러 Node 중 하나에 올라가야 하는가
- Node = 실제로 일하는 머신(물리 서버 또는 VM)이다. 클러스터는 마스터 노드(컨트롤 플레인) + 여러 워커 노드로 구성된다.
- 컨테이너는 결국 어떤 머신의 CPU·메모리·디스크를 실제로 소비해야 돌아간다. 따라서 모든 Pod는 반드시 특정 노드 하나에 배치(bind)되어야 실행될 수 있다.
- Pod는 여러 노드에 걸칠 수 없다. Pod 안의 컨테이너들은 네트워크·볼륨을 공유하므로 물리적으로 같은 노드에 있어야 한다. (Pod가 "한 호스트로 묶여있다"는 게 이 의미)
- 한 번 배치된 Pod는 다른 노드로 이동하지 않는다. 노드를 옮기려면 삭제 후 새로 생성하는 것뿐이다.
- 아직 노드가 정해지지 않은 Pod는 Pending 상태에 머문다.

방법 1) 직접 선택 — nodeSelector

노드에 라벨을 달고, Pod 생성 시 nodeSelector에 그 라벨을 명시한다.

kubectl label nodes node1 os=ubuntu

spec:
  nodeSelector:
    os: ubuntu

주의: 조건에 맞는 노드가 없으면 스케줄링이 실패하고 Pod는 계속 Pending으로 남는다. (다른 노드에 여유가 있어도 배치되지 않음)
용도: GPU가 달린 노드, SSD가 달린 노드, 특정 리전/OS 노드에만 올려야 할 때.

방법 2) 스케줄러가 판단 — resources

Pod에 필요한 자원량을 명시하면 kube-scheduler가 노드의 남은 자원을 보고 적절한 노드를 고른다.

spec:
  containers:
  - name: container
    resources:
      requests:        # 스케줄링 기준: 최소 이만큼 여유 있는 노드에 배치
        memory: "2Gi"
        cpu: "1"
      limits:          # 실행 중 상한
        memory: "4Gi"
        cpu: "2"

requests vs limits

	의미	초과 시
requests	스케줄링에 쓰이는 값. "이만큼은 보장받아야 한다"	(스케줄링 단계 값이라 런타임에 직접 작용 X)
limits	런타임 상한	메모리: 컨테이너 강제 종료(OOMKilled)<br>CPU: 종료 대신 throttling(속도 제한)

스케줄러는 노드의 requests 합계를 기준으로 판단한다. 현재 실제 사용량이 아니다.
limits 합계는 노드 용량을 넘길 수 있다(over-commit). 이 상태에서 Pod들이 실제로 한꺼번에 많이 쓰면 노드 메모리가 고갈되고, kubelet이 우선순위 낮은 Pod를 축출(eviction) 한다.
CPU는 압축 가능한 자원(넘으면 느려짐), 메모리는 불가능한 자원(넘으면 죽음)이라는 차이를 기억하면 위 표가 자연스럽다.

대세는 쿠버네티스 - [기초] Object - POD

대세는 쿠버네티스 - [기초] Object - POD