Cloud Native/K8s

k8s 이론: 워크로드

lys4321 2026. 2. 23. 18:44

워크로드란?

  • k8s에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 Pod와 이를 실행하는데 도움이 되는 상위단계를 추상화한 것
  • 클러스터에서 실행되는 애플리케이션을 관리, 유지, 배포, 확장하는 단위 리소스를 총칭하는 개념
  • k8s가 제공하는 built-in 워크로드 리소스
    • Deployment, ReplicaSet(레거시 :ReplicationController)
      • Deployment가 관리하는 Pod가 필요에 의하여 교체/상호교체가 용이하기 때문에 클러스터는 Stateless 애플레이션를 관리하기 좋다
    • StatefulSet
      • 데이터 지속성이 필요한 경우처럼 상태를 가지는 애플리케이션을 위한 Pod 집합을 관리
    • DaemonSet
      • 노드별로 하나씩 Pod를 실행해야 하는 경우 사용
      • 클러스터에 노드가 추가되면 자동으로 새 노드에 Pod를 생성
      • 시스템 구성요소나 에이전트 실행용으로 사용
    • Job, CronJob
      • 일회성이나 주기적 작업 실행에 사용
  • k8s에선 사용자 정의 워크로드 리소스를 생성 가능한데 이를 CRD(Custom Resource Definition) 이라 함

워크로드 - 사용자 네임스페이스

  • 네임스페이스 기능은 컨테이너 사용자(user) 와 호스트(node)의 사용자를 서로 다르게 매핑하도록 하는 기능
  • 이렇게 사용될 시, 만약 컨테이너 탈출(컨테이너의 권한을 가지고 컨테이너가 속한 상위 시스템으로 이동?)이 발생 시, 나타날 수 있는 현상을 방지
  • 사용자 네임스페이스는 본래 리눅스의 기능이지만 k8s 는 리눅스 커널을 기반으로 사용되기 때문에 사용이 가능
  • Pod는 pod.spec.hostUser 필드를 false로 설정하여 사용자 네임스페이스를 사용하도록 선택이 가능
  • kubelet은 동일 노드에 있는 두 개의 stateless Pod가 동일 매핑을 사용하지 않도록 Pod가 매핑된 UID, GID를 선택하여 겹치지 않도록 한다.
  • 주의
    • pod.spec.hostUser 를 false로 설정 시, 호스트 네임스페이스는 사용이 불가
      • hostNetwork
      • hostIPC
      • hostPID
        => 호스트의 네트워크, PID, IPC 등을 공유 불가
    • raw 블록 디바이스에 대한 마운트(volumeDevices)가 허용되지 않게됨
      • raw 블록 디바이스에 대한 마운트 : 파일시스템 계층을 거치지 않고 스토리지 장치에 대한 직접적인 접근

워크로드 - Pod

Pod 란?

  • k8s에서 관리하는 가장 작은 배포 가능한 컴퓨팅 단위
  • Pod는 1개 이상의 컨테이너 그룹으로 이 그룹은 스토리지와 네트워크를 공유하며 컨테이너들이 어떻게 구동할지 명세(Spec)을 가짐
  • Pod 내 컨테이너들을 같이 배치, 스케줄되며 공유 컨텍스트(범위)에서 실행 됨
  • Pod는 논리 포스트를 모델링하며 물리/가상 머신이 아닌 클라우드 환경에서의 호스트 개념
  • Pod는 애플리케이션 컨테이너 외에도 초기화 컨테이너를 가질 수도 있으며 임시 컨테이너를 삽입하기도 한다.
  • Pod 사용 방식
    • Pod 1개당 컨테이너 1개(one-container-per-Pod)
    • 여러 컨테이너를 함께 실행하는 Pod(리소스를 공유해야 할 때 사용)
  • Pod 리소스 공유 : 네트워크 & 스토리지
    • Pod 내 컨테이너들은 스토리지 볼륨과 네트워킹 리소스를 공유
    • 이로 인하여 Pod 내 컨테이너들은 localhost로 서로 통신이 가능

Pod 라이프사이클

Pod는 Self-Healing 되지 않고, 비교적 일시적인 수명을 가진 엔티티이다.

Pod 라이프사이클

  1. Pending
    • Pod가 k8s 클러스터에서 승인이 되었지만 컨테이터가 설정되지 않았고 실행할 준비가 되지 않았음을 의미
    • 이 정보에는 Pod가 스케줄되기 이전까지의 시간만이 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간이 포함
  2. Running
    • Pod가 노드에 바인딩되었고 모든 컨테이너가 생성됨을 의미
    • 1개 이상의 컨테이너가 실행중이거나 시작, 재시작 중에 있음
  3. 결과
  • Succeeded
    • Pod에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작이 되지 않을 것임을 의미
  • Failed
    • Pod 내 모든 컨테이너가 종료되었지만 1개 이상의 컨테이너가 실패로 종료되었음을 의미
    • 컨테이너가 exited 되었거나 시스템에 의해 terminated 되었음
  • Unknown
    • Pod의 상태를 얻을 수 없음을 의미
    • 노드와의 통신 오류로 발생

Pod 라이프사이클 훅

  • PostStart
    • 컨테이너가 생성된 직후에 실행
    • 컨테이너의 메인 EntryPoint가 실행되는 것과 병렬로 실행
    • 컨테이너가 시작된 후 초기화 작업에 사용되며 실패 시 재시작 정책에 따르게 됨
  • PreStop
    • 컨테이너가 종료되기 직전에 실행
    • Pod 삭제 요청 들어오면 SIGTERM 신호가 컨테이너에 전송되기 전에 PreStop 훅이 실행된다
    • 트래픽 처리를 중지하고 연결을 닫고 진행중인 요청을 완료하는 등 정리 작업을 수행하여 컨테이너가 정삭적으로 종료되도록 도움, 실패하더라도 SIGTERM 신호는 계속 전송

Pod의 컨디션

  • Pod는 하나의 PodStatus를 가지며 PodConditions 배열을 가짐
  • PodConditions 의 값 목록
    • PodScheduled : Pod가 노드에 스케줄 됨
    • PodHasNetwork : 샌드박스가 성공적으로 생성되고 네트워킹이 구성됨
    • ContainersReady : Pod의 모든 컨테이너가 준비됨
    • Initialized : 모든 초기화 컨테이너가 성공적으로 완료됨
    • Ready : Pod가 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드밸런싱 풀에 추가가 되어야 한다.

Pod의 Hostname

  • Pod 생성 시 k8s 는 특정 호스트 이름을 할당(기본적으로 Pod의 이름과 동일, pod-name)
  • 이 호스트 이름은 컨테이너 내부의 파일시스템에 있는 /etc/hostname에 기록
  • Pod의 서브도메인 이름 설정
    • pod.spec.subdomain 필드 정의 시, Fully Qualifiede Domain Name(FQDN)이 형성
      • 예 : <pod-name>.<subdomain-name>.<namespace-name>.svc.<cluster-domain>
    • 헤드리스 서비스 필요
  • Pod의 커스텀 hostname 설정
    • pod.spec.hostname 필드를 정의해 호스트 이름을 설정
    • RFC 952 및 RFC 1123에서 정의한 유효한 DNS 호스트 이름 규칙을 따라야함
    • /etc/hostname 파일에 기록

Pod 서비스 품질(QoS) 클래스

  • k8s 는 Pod 내 컨테이너의 리소스 요청과 제한 설정을 기반으로 QoS 클래스를 할당하는데 이 클래스는 리소스 부족 상황이 발생 시, Pod가 축출될 확률을 결정하는데 도움을 줌
  • QoS 클래스 종류
    • BestEffort
      • 다른 QoS 클래스의 Pod에 할당되지 않은 노드 리소스 사용이 가능
      • kubelet이 가장 먼저 축출하는 Pod
    • Burstable
      • 하한 리소스가 보장(requests 설정된 것을 의미)되지만 한도가 설정되지 않은(limits 설정 안됨) Pod를 의미
      • Pod가 QoS 클래스 Guaranteed 기준 미충족
      • Pod에 있는 하나 이상의 컨테이너에 메모리 또는 CPU 요청이나 한도 있음
      • BestEffort 다음 삭제 대상
    • Guaranteed
      • Pod의 모든 컨테이너에는 메모리 요청과 한도가 있어야하고 메모리 한도는 요청과 같아야 한다.
      • Pod의 모든 컨테이너에는 CPU 요청과 한도가 있어야하고 CPU 한도는 요청과 같아야 한다.
      • QoS 클래스 중 유일하게 Static CPU 관리 청잭을 사용해 독점적으로 CPU 사용이 가능

Pod 중단

  • Pod는 누군가 파괴하거나 불가피한 하드웨어 오류, 시스템 SW 오류가 아니면 사라지지 않는게 보통인데 만약 이런 경우이면 비자발적 중단(Involuntary Disruptions)이라하고 아니라면 자발적 중단(Voluntary Disruptions) 이라 한다.
  • Voluntary Disruptions의 예시
    • 복구나 업그레이드를 위한 노드 드레이닝(Draing)
    • Deployment나 Pod를 관리하는 컨트롤러의 제거
  • Involuntary Disruptions의 예시
    • 물리 머신의 하드웨어 오류
    • 커널 패닉
    • 리소스 부족으로 인한 Pod 축출
  • Pod Disruption Budget(PDB)
    • Voluntary Disruptions 으로 인한 애플리케이션의 서비스 중단 영향을 최소화하기 위해 사용하는 k8s 리소스
    • 최소한의 가용성 수준을 정의
    • 축출 API(Eviction API)와 연동하여 작동
      • 사용자나 자동화 프로세스가 Pod 축출을 요청
      • k8s 는 PDB를 확인하여 축출요청이 허용되었다면 Pod의 최소 가용성 제약 조건을 위반하는지 검사
      • PDB 제약 조건이 충족되지 않으면 축출 요청을 거부
      • 축출 요청을 해당 PDB 제약이 충족될 때까지 대기하거나 반복으로 재시도
    • 핵심 필드
      • 필드 중 1개만 정의가 가능
      • minAvailable
        • 항상 실행 상태여야하는 Pod의 최소 개수나 % 설정
      • maxUnavailable
        • 동시에 중단될 수 있는 Pod의 최대 개수나 % 정의

워크로드 - Container

컨테이너 상태

  • k8s 는 Pod 뿐만 아니라 컨테이너의 상태 또한 추적이 가능
  • 컨테이너 라이프사이클 훅을 사용해 컨테이너 라이프사이클의 특정 지점에서 이벤트 트리거가 가능
  • 스케줄러가 노드에 Pod를 할당하면 kubelet은 컨테이너 런타임을 사용해 Pod에 대한 컨테이너 생성을 시작하는데 이 때 컨테이너 상태가 표시된다.
  • 표시되는 컨테이너 상태 목록
    • Waiting
      • 컨테이너가 시작을 완료하는데 필요한 작업을 실행중임음 의미
    • Running
      • 컨테이너가 문제없이 실행중임을 의미
    • Terminated
      • 컨테이너가 종료되었음을 의미
      • 이 종료에는 정상 종료 + 비정상 종료가 포함

컨테이너 재시작 정책

Pod의 Spec 필드에는 restartPolicy 필드가 있는데 이 필드는 Pod내 모든 컨테이너에 적용이되는 재시작 정책을 의미한다.
사용 가능한 재시작 정책값

  • Always : 항상 재시작
  • OnFailure : 실패일 때만 재시작
  • Never : 재시작 없음

컨테이너 프로브

컨테이너 프로브(Probe)

  • 컨테이너에서 kubelet에 의하여 주기적으로 수행되는 진단(diagnostic)
  • 진단을 하기 위하여 kubelet은 컨테이너 안에서 코드를 실행하거나 네트워크 요청을 전송한다.
  • 체크 메커니즘 방법
    • exec
      • 컨테이너 내에서 지정된 명령어를 실행
      • 상태코드 0이면 진단 성공
    • grpc
      • gRPC를 사용해 원켴 프로시저 호출을 수행
      • 체크 대상이 gRPC 헬스체크를 구현해야 함
      • 응답의 status 가 SERVING이면 진단 성공
      • 2025.11.26. 기준 알파버전 기능이며 GRPCContainerProbe 기능 게이트를 활성화 해야 사용 가능
    • httpGet
      • 지정한 포트 및 경로에서 컨테이너 IP주소에 대한 HTTP GET 요청을 하여 진단하는 방법
      • 응답이 200 이상 400 미만이면 성공
    • tcpSocket
      • 지정 포트에서 컨테이너 IP주소에 대해 TCP 검사를 수행
      • 포트가 열려있다면 진단을 성공으로 간주하며 원격시스템이 연결을 열고 바로 닫아도 진단이 성공한걸로 판단
  • Probe 결과
    • Success
    • Failure
    • Unknown : 진단 자체가 실패
  • Probe 종류
    • livenessProbe
      • 컨테이너가 동작 중인지 여부 확인
      • 실패 시, kubelet이 컨테이너를 kill하고 재시작 정책의 대상이 되도록 함
    • readinessProbe
      • 컨테이너가 요청을 처리할 준비가 되었는지 여부확인
      • 실패 시, EndpointController는 Pod에 연결된 모든 Service들의 Endpoint에서 Pod의 IP주소를 제거하여 연결되지 않도록 함
    • startupProbe
      • 컨테이너 내 애플리케이션이 시작이 되었는지 나타냄
      • 이 프로브가 성공할 때까지 나머지 프로브는 활성화되지 않음 실패 시, livenessProbe의 처리와 동일
  • Pod의 종료
    • 사용자가 API 서버에 Pod 삭제를 요청
    • Pod 는 Terminating 상태가 되며 grace period 타이머가 시작
    • PreStop 훅 실행
    • kubeletdms Pod 컨테이너 프로세스에 SIGTERM 신호를 보냄
    • Grace Period 타이머에 설정한 시작이 초과되면 SIGKILL 신호를 전송하여 프로세스를 강제 종료하고 Pod는 API 서버에서 삭제

초기화 컨테이너(init Container)

  • Pod의 앱 컨테이너들이 실행되기 전, 실행되는 컨테이너
  • 앱 이미지에는 없는 유틸리티나 설정 스크립트 등을 포함
  • init 컨테이너는 순서가 있어서 앞순서가 성공적으로 완료되어야 한다.
  • init 컨테이너의 특징
    • init 컨테이너에 대한 리소스 요청 및 제한(requests, limits)을 정의할 수 있는데 k8s 클러스터 내에서 init 컨테이너에 설정된 리소스 요청/제한 중 가장 높은 비용을 기준으로 삼아 Pod 전체의 유효한 초기 리소스 요청 및 제한값으로 계산한다.
    • init 컨테이너 또한 restartPolicy 를 따르고 Pod 전체를 재시작한다.
  • init 컨테이너의 용도
    • 네트워크 설정
      • 외부 서비스에 대한 임시 접속 등을 수행
    • 볼륨 준비
      • Shared Volume 에 애플리케이션에 필요한 데이터나 파일을 준비
    • 사전 조건 대기
      • 외부 DB나 다른 MS(Micro Service)가 준비될 때까지 기다리는 작업 수행
    • 보안 관리 및 설정
      • init 컨테이너는 root 계정을 통해 초기화 작업을 수행하여서 애플리케이션 컨테이너의 권한을 미리 설정하는 작업을 할 수 있다.

Sidecar Container

  • Pod 디자인의 패턴으로 같은 Pod 내에서 실행되는 추가적인 보조 컨테이너
  • 메인 애플리케이션 컨테이너와 같은 수명, 네트워크 네임스페이스, 저장소 볼륨 등을 공유하며 함께 작동
  • Sidecar 컨테이너를 사용하는 이유는 책임을 분산시키기 위함이다.
  • Sidecar 컨테이너의 장점
    • 관점 분리(Separation of Concerns)
      • 메인 애플리케이션 컨테이너는 핵심 비즈니스 로직에 집중하게 하고 그 밖의 로킹이나 모니터링, 보안 등에 대해서는 Sidecar 컨테이너가 담당하게 되어 구분짓게 한다.
    • 재사용성 및 모듈성
      • 보조 기능을 별도의 컨테이너로 패키징해 여러 Pod에서 쉽게 재사용 하도록 한다.
        => 일종의 템플릿을 만들어 재사용하기
      • 느슨한 결합(Loose Coupling)
        • 메인 애플리케이션 컨테이너들은 Sidecar 컨테이너가 어떻게 동작하는지는 영향을 받지 않음
      • Lecacy 코드 통합
        • 레거시를 수정하지 않고 최신 버전을 추가 가능
  • Sidecar 컨테이너의 라이프사이클
    • 과거에는 일반 컨테이너처럼 실행되어 시점이 맞지 않는 문제가 있었지만 현재는 init 컨테이너처럼 실행되도록 변경되어 해결됨
    • init 컨테이너처럼 메인 애플리케이션 컨테이너 선언 전에 시작되고 init 컨테이너와는 다르게 종료되지 않고 계속 실행되다가 메인 애플리케이션 컨테이너와 같이 종료됨
    • 보통 initContainers 필드에 정의가 되지만 해당 컨테이너의 restartPolicy를 Always나 OmFailure로 설정해 재시작이 가능한 init 컨테이너로 만듦

임시 컨테이너(Ephemeral container)

  • 실행중인 Pod 내에서 문제해결(TroubleShooting)이나 검사(Inspection) 를 목적으로 임시로 추가되는 컨테이너
  • Emphemeral 컨테이너는 Pod 스펙에 저장되지 않으며 Pod 라이프사이클에 맞춰 실행되진 않음
  • 컨테이너는 기본적으로 볼변성 원칙을 따르기에 디버깅에 관련된 도구가 없는 경우가 많은데 이 임시 컨테이너에 그 디버깅 도구들을 넣어 임시로 사용하여 실행중인 컨테이너에 접근하도록 함
  • Ephemeral 컨테이너의 특징
    • 네임스페이스 공유
      • PID 네임스페이스 공유
        • 애플리케이션 컨테이너의 프로세스 트리를 볼 수 있게 되어 ps, strace 등의 도구로 프로세스를 검사가 가능
      • 네트워크 네임스페이스 공유
        • 애플리케이션 컨테이너의 네트워크 스택에 접근해 네트워크 문제에 대해 진단이 가능
    • 제한된 기능 및 리소스
      • 포트, 리소스, 프로브 설정 불가
      • Pod의 기존 Volume 마운트는 가능
  • Ephemeral 컨테이너의 라이프사이클
    • 사용자가 실행중인 Pod에 임시 컨테이너 추가 요청을 API서버에 보냄
    • kubelet이 Pod 내 임시 컨테이너 생성
    • 임시 컨테이너는 메인 프로세스를 실행하고 작업이 끝나면 종료(재시작 없음)

워크로드 - 리소스

  • Pod에 대한 메니페스트 파일을 작성해 생성할 수 있지만 워크로드 사용시에는 그보다 상위 레벨 메니페스트 파일에 추가하여 생성이 가능
    => Pod는 워크로드 리소스와 컨트롤러에 의해 관리됨
  • Deployment, Job 등의 워크로드 리소스를 생성해 Pod를 사용할 수 있고 만약, Pod의 상태를 추적해야한다면 StatefulSet 리소스도 사용할 수 있다.
  • 워크로드 리소스는 내부에 Pod 템플릿을 포함하여 Pod를 생성이 가능하며 Pod 템플릿이 변경되면 새 Pod를 생성하는 방식으로 업데이트함
  • Pod 를 관리하는 워크로드 리소스 예시
    • Deplyment
    • ReplicaSet
    • StatefulSet
    • DaemonSet
    • Job, Cron Job

Deplyment

  • 애플리케이션 워크로드를 실행하기 위해 Pod 집합을 관리
  • Pod와 ReplicaSet 에 대한 선언적 업데이트를 제공
  • Deployment는 Desired State를 정의하고 실제 업데이트 작업은 Deployment 컨트롤러가 함
  • 기능
    • ReplicaSet 관리
      • Deployment는 Pod 템플릿을 기반으로 ReplicaSet을 관리
      • ReplicaSet은 Pod를 재생성
      • 특정 조건에 따라 새 ReplicaSet을 만들고 이전의 것은 유지하거나 축소
    • 선언적 롤아웃
      • Deployment는 Pod 템플릿이 변경되면 자동으로 ReplicaSet을 생성하고 선택한 롤아웃 전략을 따름
  • Rollout 전략 종류
    • RollingUpdate
      • 업데이트 동안 가용성을 유지하면서 Pod를 점진적으로 변경하는 것
      • maxUnavailable : 업데이트 중 몇 개의 Pod를 비가용 상태로 허용할지
      • maxSurge : 지정한 복제본 수보다 얼마나 많은 Pod를 생성할 수 있는지
    • Recreate 전략(대체 롤아웃 방식)
      • 기존 Pod 모두 삭제 후 새 Pod 생성
      • 중단이 있어도 되는 워크로드에 사용될만 함
  • Rollback 개념
    • Deployment가 과거 ReplicaSet을 기록해 두었다가 문제 발생 시, 기존 상태로 되돌리는 것
    • revisionHistoryLimit 값으로 보유할 기록 수를 제어(0이면 롤백 불가)
  • Scaling 개념
    • Deployment는 복제본 수를 조절해 애플리케이션을 수평적으로 관리가 가능
    • Rollout 도중 Scaling이 들어오면 비례적 스케일링(proporitional scaling)으로 신규/이전 ReplicaSet 자원을 분배
    • HPA(오토 스케일러)가 Deployment 위에서 작동할 수도 있다.
  • Selector 개념
    • Deployment는 spec.selector라는 Label 기반 선택기로 어떤 Pod를 관리할지 결정이 가능
  • ReplicaSet 과의 관계
    • Deployment는 Revision 간 전환을 위해 여러 ReplicaSet을 유지
    • 현 버전의 ReplicaSet은 원하는 숫자만큼 유지되며 이전 버전의 ReplicaSet은 scale-down된 채로 남겨저 롤백에 사용된다.
  • Deployment가 관리하기 적합한 워크로드
    • Stateless 애플리케이션
    • 무중단 배포가 필요한 경우
    • Rollout/Rollback, Scaling, Revision 이 필요한 경우
    • Statefull 애플리케이션의 경우는 StatefulSet을 쓰는게 좋다.

ReplicaSet

  • 지정한 수만큼의 Pod를 유지하는 것
  • ReplicaSet 생성 시, Pod를 지정한 수만큼 ReplicaSet 컨트롤러가 생성/관리
  • 매니페스트 내 구성요소
    • Selector(spec.selector)
      • ReplicaSet이 관리할 Pod를 지정함
    • Pod Template(spec.template)
      • Pod 생성을 정의
    • Replicas(spec.replicas)
      • 복제할 Pod의 수를 지정
  • ReplicaSet을 사용하게 되는 상황
    • 기본적으로 Pod의 복제가 필요한 경우 사용
    • ReplicaSet은 Pod의 복제에 대한 단순한 관리만 지원하므로 세부적인 기능이 필요하다면 Deployment가 사용되어야 함

StatefulSet

  • Stateful 한 애플리케이션을 위한 워크로드 API 오브젝트
  • Deployment는 애플리케이션의 순서나 식별이 상관없을 때 사용한다면 StatefulSet은 반대로 순서나 식별이 필요 시 사용
  • 안정된 네트워크 ID, 지속적인 스토리지 볼륨 등이 필요 시 고려 가능
  • StatefulSet의 특징
    • 식별이 가능한 네트워크(Stable, unique network identity)
      • 각 Pod는 StatefulSet 이름 + 순서에 기반한 고정된 hostname 가지고 유지됨
    • 식별이 가능한 순서(index)
    • Stable, Persistance Storage(볼륨 + 스토리지 지속성)
      • spec.volumeClaimTemplate 로 정의되 PVC를 각 Pod에 자동으로 할당하게 되는데 이렇게 되면 각 Pod는 고유한 저장공간을 가지고 재생성 시에도 같은 스토리지를 사용함
    • 순차적 배포 및 스케일링 보장
      • 생성 시, 순서대로 생성하고 삭제 시, 역순으로 동작
    • 자동/순차 롤링 업데이트 지원

DaemonSet

  • 클러스터 내에서 각 노드나 일부 노드마다 해당 Pod 복제본 하나씩이 반드시 존재하도록 보장이 필요 시에 사용
  • 노드가 클러스터에 추가되면 그 노드에 파드가 스케줄되고 노드가 클러스터에서 제거되면 파드도 따라서 자동 정리
  • DaemonSet이 제거가 되면 그로 인하여 생성이 되었던 파드도 같이 제거
  • DaemonSet 특징
    • replicas 를 설정하지 않음
    • spec.template, spec.selector를 정의하며 이것을 기반으로 Pod를 생성
    • 특정 노드만 대상으로 하려면 nodeSelector, affinity, nodeLabel을 사용해 어떤 노드에만 파드를 만들지 설정이 가능
    • Pod의 RestartPolicy는 항상 always 여야 함
  • DaemonSet을 사용하는 경우
    • 클러스터의 각 노드에서 반드시 동작해야 하는 것이 필요 시
    • 노드와 같은 라이프사이클을 가지는 Pod가 필요 시
    • 노드 단위로 반복 실행이 되는 구성요소를 선언적으로 관리 시
  • DaemonSet의 업데이트 프로세스
    • 노드의 label이 변경 시, DaemonSet은 자동으로 일치하는 노드에만 Pod를 추가하고 조건에 맞지 않는 Pod를 제거
    • 기본적으로 DaemonSet 삭제 시 그에 해당하는 Pod도 삭제하지만 cascade옵션에 따라 Pod는 보존할 수 있다.

Job, Cron Job

  • 일회성, 일정에 따른 작업에 사용되는 워크로드 오브젝트
  • 단일/복수의 작업을 처리하고 사라지는 작업에 적합
  • 하나 이상의 Pod를 생성하고 지정 성공 횟수에 도달할 때까지 Pod 재시도 생성
  • 개념
    • Pod Template 기반 생성
      • spec.template 필으에 Pod 의 템플릿 정의
      • API 버전이나 종류는 포함하지 않음
    • RestartPolicy
      • Job은 반드시 RestartPolicy가 Never, OmFailure 여야함
  • 실행 방식
    • Non-parallel Job
      • 기본값. Pod 생성 후 성공적으로 종료 시 Job완료, 실패 시 재시도
    • 고정 완료 개수 병렬 Job
      • spec.completions 필드에 성공 Pod 개수 지정
      • spec.parallelism 필드에 병렬도 지정
    • work-queue Job
      • spec.completions 지정하지 않고 spec.parallelism만 설정
      • 하나라도 성공하면 나머지 Pod에 있는 작업은 모두 종료하거나 중단해야함
  • Job을 사용해야하는 상황
    • 한 번 실행하고 끝나는 작업인 경우
    • Pod 실패 시 재시도 해야하는 경우
  • Cron Job
    • 주기적 스케줄에 따라 자동으로 Job을 생성해 실행하게하는 k8s 리소스
    • 구성요소
      • spec.schedule
                  • 의 형식을 따름
      • spec.jobTemplate
        • Cron Job 이 생성하는 Job 에 대한 템플릿
    • Cron Job이 사용될 수 있는 상황
      • 정기적인 백업, 로그 정리 등 같은 반복 작업 필요 시
      • k8s 내부에서 스케줄 + 실행을 관리하려할 시
    • 주의점
      • 스케줄된 시간이 정확하게 지켜진다는 보장이 없음
      • 리소스 과부하 이슈 발생가능
  • 완료된 Job 자동 정리(TTL-after-finished)
    • Job 리소스의 생존기간을 설정해 이 기간 경과 후 정리하도록 하는 기술
    • 동작방식
      • Job 매니페스트나 이미 존재하는 Job에 spec.ttlSecondsAfterFinished 필드 설정 시 활성화
      • Job 완료 후 상태가 Complete, Failed 시점 후 TTL 카운팅 시작(0 설정 시 바로 삭제)
    • 주의점
      • TTL-after-finished 컨트롤러는 현재 Job 리소스에만 적용
      • TTL 값은 수정이 가능하지만 이미 만료된 후 수정하면 삭제를 보장하진 않음

워크로드 - Autoscaling

  • 워크로드가 리소스 변경 필요 시 자동으로 조정되는 기능
  • 수동 스케일링 방식
    • Horizontal scaling - Pod 수(Replicas) 조절
    • Vertical scaling - Pod에 할당된 리소스를 조절
    • 수평 , 수직 방식의 차이점
      • 수평은 kubectl 명령어로 Replicas 직접 지정
      • 수직은 워크로드 리소스 정의(pod spec)를 수정해야 함
  • 자동 스케일링 방식
    • HorizontalPodAutoscaler(HPA)
      • 워크로드의 Replicas 를 관측된 리소스 사용량에 맞춰 자동으로 조정하는 컨트롤러
      • Replicas 를 조절할 수 있는 워크로드만 가능
    • VerticalPodAutoscaler(VPA)
      • Pod에 할당된 리소스 요청을 자동으로 조정하는 도구(k8s에 미포함 되어있어 따로 추가해야함)

'Cloud Native > K8s' 카테고리의 다른 글

k8s 이론: 구성  (0) 2026.02.23
k8s 이론: 스토리지  (0) 2026.02.23
k8s 이론: 서비스, 로드밸런싱, 네트워킹  (0) 2026.02.23
k8s 이론: 아키텍처  (0) 2026.02.23
k8s 이론: 개요  (0) 2026.02.23

'Cloud Native/K8s'의 다른글

  • 현재글k8s 이론: 워크로드

관련글

티스토리툴바