Pod - 기초 동작과 Controller

inuit·2025년 4월 2일

kubernetes

All about 쿠버네티스

목록 보기

4/21

최근 업데이트일 2024-11-01

실습 동영상 따라하며 배우는 쿠버네티스

Pod가 어떻게 동작하는지 간단히 알아보고 Pod를 배포하는 conroller에 대해서 살펴보자.

Pod

쿠버네티스에서 배포할 수 있는 최소 객체 단위로 하나 이상의 컨테이너(애플리케이션 단위)로 이루어진다.

Pod의 특정 container가 종료되면 선언한 restartPolicy에 따라 재시작 여부를 결정한다.
- Exponential back-off delay 마다 시도한다.
같은 pod 내 container는 IP를 공유하기 때문에 컨테이너 안에서 다른 컨테이너 접속 가능하다.
scheduling 전까지 Pending 상태이다가 Running or Succeeded or Failed가 된다.
Pod은 자체 IP를 가지고 다른 Pod과 통신할 수 있지만, 쉽게 사라지고 생성되는 특징 때문에 직접 통신하는 방법은 권장하지 않는다.

livenessProbe

livenessProbe와 readinessProbe를 같이 적용해서 컨테이너 상태 모니터링하고 self-healing 할 수 있다.
쿠버네티스가 컨테이너 안에서 실행 중인 애플리케이션에 HTTP 요청을 보내서, 정상 응답이 오는지 확인한다.

yaml의 containers.livenessProbe에서 요청 방법 및 path와 port를 설정하고, 요청에 대한 응답이 오지 않으면 재시작한다.
- httpGet: web server에 get 요청을 보내서 200번 상태 코드를 받으면 정상
- tcpSocket: 네트워크, 지정된 포트에 TCP 연결되면 정상
- exec : 명령 코드를 보내서 종료 코드가 0이면 정상
- 또 다른 매개변수 etc
  - periodSeconds: health check 반복 실행 시간
  - initialDelaySeconds: Pod 실행 후 delay할 시간
  - timeoutSeconds: health check 후 응답을 기다리는 시간
  - failureThreshold: health check 실패 횟수

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

init container: 선행되어야 하는 작업을 담은 컨테이너, 먼저 실행 성공해야 main container 실행한다. 쿠버네티스: Init Containers
infra(pause) container: Pod마다 존재하여 infra를 관리한다.
- Pod는 격리된 IPC, Network namespace를 생성하는 Pause 컨테이너를 생성하고 유지한다.
- 항상 실행되어 특정 컨테이너가 비정상 종료되면서 컨테이너 전체에서 공유되는 namespace 문제 발생을 방지한다.
- 무한 루프를 돌며 SIGINT, SIGTERM 받으면 종료한다.
- Zombie process 발생 우려가 있으면 PID namespace sharing을 활성화해서 Pause가 Zombie process reaping 역할(좀비 프로세스를 정리)을 위임할 수 있다.

백엔드 Pod: 특정 Pod의 역할을 나타내는 것으로, 주로 사용자에게 직접적으로 노출되지 않는 서버 측 컴포넌트이다.
- 일반적으로 데이터 처리, 비즈니스 로직 실행, 데이터베이스 관리, API 서비스 제공 등의 역할을 수행한다.
Static Pod: API에게 요청을 보내지 않고, kubelet이 관리하는 static pod directory에 yaml 파일 저장하면 실행되는 Pod
- 보통 /etc/kubernetes/manifests/에 저장, var/lib/kubelet/config.yaml에서 디렉토리 확인
Pod에 resource를 할당하여 CPU와 Memory 최소량을 scheduler에 request하거나 최대량을 제한할 수 있다.
- limit을 초과하면 종료되고 다시 스케줄링한다.
- cpu는 코어 개수나 밀리코어(m, 1 core = 1000m core)으로 표현하고, 메모리는 Mi(1Mi = 1024KiB)단위이다.
- 이를 containers.resources.limits or requests에서 요청한다.
환경 변수: Pod 내 컨테이너가 실행될 때 필요로 하는 변수, 환경변수 설정해서 버전 변경 가능
Pod가 여러 컨테이너일 경우 주로 Primary Container와 Sidecar Containers로 구성한다.
- Sidecar: 단독 실행 불가, 컨테이너가 특정 컨테이너의 로그 파일 수집 혹은 호스트 디렉토리를 컨테이너 디렉토리에 연결하는 역할
- Adapter: 매개체, e.g. 모니터링 데이터를 데이터 받아서 Web UI로 전달
- Ambassador: DB 연결, e.g. Web server 데이터를 내부로 전달

Pod Controller

Pod을 단독으로 만들면 Pod에 어떤 문제가 생겼을 때 자동으로 복구되지 않기 때문에, 다양한 conroller를 사용하여 Pod를 배포한다.

ReplicationController

Pod 개수를 보장하는 가장 기본적인 controller

yaml에서 selector, replicas, template 설정이 필수이다.
replicas 수 만큼 template 형태의 container를 유지하기 위해 selector의 label을 확인한다.
- label이 같은 container는 replicas 보다 더 생성될 수 없다.

kubectl create rc rc-nginx —image=nginx —replicas=3 —selector=app=webui
kubectl scale rc rc-nginx —replicas=2: repliacas 축소·확장

ReplicaSet

ReplicationController와 같지만, 더 풍부한 selector를 지원한다.

matchLabels: 해당 label을 가지면 ReplicaSet의 대상이 된다.
matchExpressions: label이 수식에 맞으면 ReplicaSet의 대상이 된다.
- In: key-value 지정해서 일치하는 Pod 연결
- NotIn: key는 일치하지만 value는 일치하지 않으면 연결
- Exists: key에 맞는 label의 pod 연결
- DoesNotExist: key와 다른 label의 pod 연결

kubectl delete rs [NAME] --cascade=false: controller가 삭제되도 Pod는 유지
Pod를 업데이트하고 이력을 관리하여 Rollback하거나 특정 버전으로 돌아갈 수 있다.

Deployment

ReplicaSet을 제어하는 역할을 하며, Pod instance를 서비스 중단 없이 버전을 바꾸는 Rolling Update & Back을 지원한다.

kubectl set image deployment [NAME] [container_name]=[new version image] --record # 업데이트 후 기록
kubectl rollout history deployment [NAME]
kubectl rollout undo deploy [NAME] --to-revision=3` # 롤백 (버전 선택 가능) REVISION 인덱스 업데이트 주의
kubectl rollout history pauser / resume # 일시정지 / 재시작 → 상태 모니터링

다양한 배포 전략이 존재한다.
spec.strategy.rollingUpdate
- maxSurge: 업데이트 도중 동시에 추가로 생성할 수 있는 Pod의 최대 개수
- maxUnavailable: 업데이트 도중 동시에 사용할 수 없는 Pod의 최대 개수
spec.strategy.type: RollingUpdate
- spec.progressDeadlineSeconds이나spec.revisionHistoryLimit로 조절한다.
metadata.annotations: kubernetes.io/change-cause: version 1.14: 이후 yaml의 image version 바꾸고 적용 시 해당 Deployment 업데이트

DaemonSet

노드 당 Pod 한 개씩 실행되도록 보장하는 controller

로그 수집기나 모니터링 Agent에 사용하고, edit을 통한 RollingUpdate와 Rollback이 가능하다.

StatefulSet

Stateful application(Client와 서버의 Application에서 업데이트되는 내용이 항상 서로에게 영향을 주는 Application)을 실행하는 Pod를 관리하는 Contoller

Pod의 상태(name과 volume 등)를 유지한다.
원래는 controller로 만든 pod의 이름은 random한 hash 값이지만 StatefulSet은 0부터 시작하는 연속한 숫자로 자동 지정된다.
RollingUpdate 및 Rollback이 가능하다.
각 Pod에 고유하고 지속적인 네트워크 ID와 DNS 이름을 제공하기 위해 spec.serviceName을 명시해서 service의 DNS의 이름을 지정해야 한다.
spec.podManagementPolicy가 OrderedReady(기본값)면 순차적으로 실행하고, Parallel이면 병렬적으로 실행한다.

Job

Batch 처리에 적합한 controller, Batch 처리 작업이 완료되면 없어진다.

원래 쿠버네티스는 Pod 종료 시 재시작하지만 Job은 정상 종료 시 완료된다.
백업, 청소 등의 작업에 사용되며, Pod가 끝나도 로그를 볼 수 있도록 job은 존재한다.
spec.restartPolicy: Never(기본값) or Onfailure(비정상 종료 시 container를 restart)
spec.backoffLimit: 재시작 횟수
spec.completion: Pod 완료 횟수
spec.parallelism: Pod 유지 개수
spec.activeDeadlineSeconds: n초 안에 안끝나면 강제 종료

Cronjob

Job을 controll하여 원하는 시간에 실행 예약을 지원하고, 주기적으로 반복하는 Job이 필요할 때 사용하는 Conroller

백업이나 이메일 전송 등에 사용된다.
spec.schedule: */5 3 1,2 * 1-5 (Minites, Hours, Day of the month, Month, Day of the week)
spec.jobTemplate: Job에 대한 명세
spec.concurrentyPolicy: Allow or Forbid, Job이 실행중이여도 주기가 돌면 실행할지 말지를 결정
spec.startingDeadlineSeconds

Controller는 API version에 유의해야 한다.
- controller 마다 apiVersion이 상이하며, 버전마다 갱신될 수 있기 때문에 유의해야 한다. (kubectl explain [TYPE]으로 확인)
- Deployment: apps/v1, Pod: v1, ReplicaSet: apps/v1, ReplicationController: v1, Service: v1, PersistentVolume: v1