Pod

Pod

Pod는 Kubernetes에서 생성하고 관리할 수 있는 가장 작은 배포 가능한 컴퓨트 단위예요.

Pod(고래 떼나 완두콩 껍질의 pod에서 유래한 이름)는 공유 스토리지와 네트워크 리소스, 그리고 컨테이너 실행 방법에 대한 스펙을 가진 하나 이상의 컨테이너 그룹이에요. Pod의 내용물은 항상 함께 위치하고(co-located) 함께 스케줄링되며, 공유 컨텍스트에서 실행돼요. Pod는 애플리케이션 특정의 "논리적 호스트"를 모델링해요. 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너를 포함해요. 클라우드가 아닌 컨텍스트에서 같은 물리적 또는 가상 머신에서 실행되는 애플리케이션은 같은 논리적 호스트에서 실행되는 클라우드 애플리케이션과 유사해요.

애플리케이션 컨테이너뿐 아니라 Pod는 Pod 시작 중에 실행되는 init 컨테이너를 포함할 수 있어요. 또한 실행 중인 Pod를 디버깅하기 위해 임시 컨테이너를 주입할 수도 있어요.

Pod란 무엇인가?

참고:

Pod가 실행될 수 있도록 클러스터의 각 노드에 컨테이너 런타임을 설치해야 해요.

Pod의 공유 컨텍스트는 Linux 네임스페이스, cgroups, 그리고 잠재적으로 다른 격리 측면의 집합이에요 — 컨테이너를 격리하는 것과 같은 것들이죠. Pod의 컨텍스트 안에서 개별 애플리케이션에는 추가 하위 격리가 적용될 수 있어요.

Pod는 공유 네임스페이스와 공유 파일시스템 볼륨을 가진 컨테이너 집합과 유사해요.

Kubernetes 클러스터의 Pod는 두 가지 주요 방식으로 사용돼요.

단일 컨테이너를 실행하는 Pod. "Pod당 컨테이너 하나" 모델은 가장 일반적인 Kubernetes 사용 사례예요. 이 경우 Pod를 단일 컨테이너를 감싸는 래퍼로 생각할 수 있어요. Kubernetes는 컨테이너를 직접 관리하는 대신 Pod를 관리해요.

함께 동작해야 하는 여러 컨테이너를 실행하는 Pod. Pod는 밀접하게 결합되고 리소스를 공유해야 하는 여러 함께 위치한 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있어요. 이러한 함께 위치한 컨테이너는 하나의 응집된 단위를 형성해요.

단일 Pod에 여러 함께 위치하고 함께 관리되는 컨테이너를 그룹화하는 것은 상대적으로 고급 사용 사례예요. 컨테이너가 밀접하게 결합된 특정 경우에만 이 패턴을 사용해야 해요.

복제(내결함성 또는 용량)를 제공하기 위해 여러 컨테이너를 실행할 필요는 없어요. 여러 복제본이 필요하면 "워크로드 관리"를 참고하세요.

Pod 사용

nginx:1.14.2 이미지를 실행하는 컨테이너로 구성된 Pod 예시를 볼게요.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

위 Pod를 만들려면 다음 명령을 실행해요.

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

Pod는 일반적으로 직접 생성되지 않고 워크로드 리소스를 사용해 생성돼요. Pod가 워크로드 리소스와 함께 어떻게 사용되는지에 대한 자세한 내용은 "Working with Pods"를 참고하세요.

pod 관리용 워크로드 리소스

보통 단일(singleton) Pod조차도 직접 만들 필요는 없어요. 대신 Deployment나 Job 같은 워크로드 리소스로 생성해요. Pod가 상태를 추적해야 한다면 StatefulSet 리소스를 고려하세요.

각 Pod는 주어진 애플리케이션의 단일 인스턴스를 실행하도록 의도됐어요. 애플리케이션을 수평으로 확장하려면(더 많은 인스턴스를 실행해 전체 리소스를 더 많이 제공) 인스턴스마다 여러 Pod를 사용해야 해요. Kubernetes에서는 이를 보통 *복제(replication)*라고 불러요. 복제된 Pod는 보통 워크로드 리소스와 그 컨트롤러가 그룹으로 생성하고 관리해요.

Kubernetes가 워크로드 리소스와 그 컨트롤러를 사용해 애플리케이션 확장과 자동 복구를 구현하는 방법에 대한 자세한 내용은 Pods and controllers를 참고하세요.

Pod는 구성 컨테이너를 위해 두 가지 종류의 공유 리소스, 네트워킹과 스토리지를 기본적으로 제공해요.

Pod 작업하기

Kubernetes에서 개별 Pod를 직접 만드는 일은 드물어요 — singleton Pod조차도요. Pod가 비교적 일시적이고 일회용인 엔티티로 설계됐기 때문이에요. Pod가 생성되면(여러분이 직접, 또는 컨트롤러가 간접적으로) 새 Pod는 클러스터의 Node에서 실행되도록 스케줄링돼요. Pod는 실행을 완료하거나, Pod 객체가 삭제되거나, 리소스 부족으로 퇴거(evict)되거나, 노드가 실패할 때까지 그 노드에 남아요.

참고: Pod의 컨테이너를 재시작하는 것은 Pod를 재시작하는 것과 혼동해서는 안 돼요. Pod는 프로세스가 아니라 컨테이너를 실행하기 위한 환경이에요. Pod는 삭제될 때까지 지속돼요.

Pod의 이름은 유효한 DNS 서브도메인 값이어야 하지만, 이는 Pod 호스트 이름에 예기치 않은 결과를 만들 수 있어요. 최상의 호환성을 위해 이름은 DNS 레이블의 더 제한적인 규칙을 따라야 해요.

Pod OS

기능 상태: Kubernetes v1.25부터 Stable

.spec.os.name 필드를 windows 또는 linux로 설정해서 해당 Pod의 컨테이너가 요구하는 운영 체제를 나타내야 해요. 이 두 가지는 현재 Kubernetes가 지원하는 유일한 운영 체제예요. 향후 이 목록은 확장될 수 있어요.

.spec.os.name 값이 노드의 운영 체제와 일치하지 않으면 kubelet은 Pod 실행을 거부해요. 다만 Kubernetes v1.37에서 .spec.os.name 값은 kube-scheduler가 Pod를 실행할 노드를 고르는 방식에는 영향을 주지 않아요. 실행 중인 노드의 운영 체제가 둘 이상인 클러스터에서는 각 노드에 kubernetes.io/os 레이블을 올바르게 설정하고, 운영 체제 레이블을 기반으로 하는 nodeSelector로 pod를 정의해야 해요. kube-scheduler는 다른 기준으로 pod를 노드에 할당하며, 해당 Pod의 컨테이너에 맞는 노드 OS가 있으면서 적합한 노드 배치를 고르는 데 성공할 수도 있고 실패할 수도 있어요. Pod security standards도 이 필드를 사용해 운영 체제와 관련 없는 정책을 시행하지 않도록 방지해요.

Pod와 컨트롤러

워크로드 리소스를 사용해 여러 Pod를 생성하고 관리할 수 있어요. 리소스의 컨트롤러가 복제, 롤아웃, Pod 실패 시 자동 복구를 처리해요. 예를 들어 Node가 실패하면 컨트롤러는 그 Node의 Pod가 작동을 멈춘 것을 알아차리고 대체 Pod를 만들어요. 스케줄러는 대체 Pod를 정상 Node에 배치해요.

하나 이상의 Pod를 관리하는 워크로드 리소스의 몇 가지 예시를 볼게요.

  • Deployment
  • StatefulSet
  • DaemonSet

스케줄링 그룹 지정

기능 상태: Kubernetes v1.37부터 Beta; 기본적으로 비활성화

기본적으로 Kubernetes는 모든 Pod를 개별적으로 스케줄링해요. 하지만 일부 밀접하게 결합된 애플리케이션은 제대로 동작하려면 Pod 그룹이 동시에 스케줄링되어야 해요.

스케줄링 그룹 필드(spec.schedulingGroup)를 사용해 Pod를 PodGroup에 연결할 수 있어요. 이는 kube-scheduler에 해당 Pod가 특정 그룹에 속한다는 것을 알려주며, 전체 그룹에 대해 그룹 수준의 조정된 배치 결정을 적용할 수 있게 해요.

Pod 템플릿

워크로드 리소스의 컨트롤러는 pod 템플릿에서 Pod를 만들고 여러분을 대신해 그 Pod들을 관리해요.

PodTemplate은 Pod를 만들기 위한 스펙이며, Deployment, Job, DaemonSet 같은 워크로드 리소스에 포함돼요.

워크로드 리소스의 각 컨트롤러는 워크로드 객체 안의 PodTemplate을 사용해 실제 Pod를 만들어요. PodTemplate은 앱을 실행하는 데 사용한 어떤 워크로드 리소스의 desired state 일부예요.

Pod를 만들 때 Pod에서 실행되는 컨테이너에 대한 환경 변수를 Pod 템플릿에 포함할 수 있어요.

아래 샘플은 하나의 컨테이너를 시작하는 템플릿이 있는 간단한 Job 매니페스트예요. Pod의 컨테이너는 메시지를 출력한 후 pauses해요.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # This is the pod template
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # The pod template ends here

pod 템플릿을 수정하거나 새 pod 템플릿으로 전환해도 이미 존재하는 Pod에는 직접 영향이 없어요. 워크로드 리소스의 pod 템플릿을 변경하면, 그 리소스는 갱신된 템플릿을 사용하는 대체 Pod를 만들어야 해요.

예를 들어 StatefulSet 컨트롤러는 각 StatefulSet 객체의 실행 중인 Pod가 현재 pod 템플릿과 일치하도록 보장해요. StatefulSet을 편집해 pod 템플릿을 바꾸면 StatefulSet이 갱신된 템플릿에 기반한 새 Pod를 만들기 시작해요. 결국 모든 이전 Pod가 새 Pod로 교체되고 갱신이 완료돼요.

각 워크로드 리소스는 Pod 템플릿 변경을 처리하는 고유한 규칙을 구현해요. StatefulSet에 대해 자세히 읽고 싶다면 StatefulSet Basics 튜토리얼의 Update strategy를 읽어 보세요.

Node에서 kubelet은 pod 템플릿과 갱신에 관한 세부 사항을 직접 관찰하거나 관리하지 않아요. 그 세부 사항은 추상화되어 있어요. 그 추상화와 관심사 분리는 시스템 의미론을 단순화하고, 기존 코드를 변경하지 않고 클러스터 동작을 확장하는 것을 가능하게 해요.

Pod 갱신과 교체

이전 섹션에서 언급했듯이 워크로드 리소스의 pod 템플릿이 변경되면 컨트롤러는 기존 Pod를 갱신하거나 패치하는 대신 갱신된 템플릿에 기반한 새 Pod를 만들어요.

Kubernetes는 Pod를 직접 관리하는 것을 막지 않아요. 실행 중인 Pod의 일부 필드를 제자리에서 갱신하는 것이 가능해요. 다만 patch, replace 같은 Pod 갱신 작업에는 몇 가지 제한이 있어요.

  • Pod의 메타데이터 대부분은 불변이에요. 예를 들어 namespace, name, uid, creationTimestamp 필드는 변경할 수 없어요.
  • metadata.deletionTimestamp가 설정되어 있으면 metadata.finalizers 목록에 새 항목을 추가할 수 없어요.
  • Pod 갱신은 spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds, spec.terminationGracePeriodSeconds, spec.tolerations, spec.schedulingGates 이외의 필드를 변경할 수 없어요. spec.tolerations의 경우 새 항목만 추가할 수 있어요.
  • spec.activeDeadlineSeconds 필드를 갱신할 때 두 가지 유형의 갱신이 허용돼요.
    • 미할당 필드를 양수로 설정하기
    • 양수에서 더 작은 비음수로 필드 갱신하기

Pod 하위 리소스

위의 갱신 규칙은 일반적인 pod 갱신에 적용되지만, 다른 pod 필드는 하위 리소스를 통해 갱신할 수 있어요.

  • Resize: resize 하위 리소스는 컨테이너 리소스(spec.containers[*].resources)를 갱신할 수 있게 해 줘요. 자세한 내용은 Resize Container Resources를 참고하세요.
  • Ephemeral Containers: ephemeralContainers 하위 리소스는 Pod에 임시 컨테이너를 추가할 수 있게 해 줘요. 자세한 내용은 Ephemeral Containers를 참고하세요.
  • Status: status 하위 리소스는 pod 상태를 갱신할 수 있게 해 줘요. 이는 일반적으로 kubelet과 다른 시스템 컨트롤러만 사용해요.
  • Binding: binding 하위 리소스는 Binding 요청을 통해 pod의 spec.nodeName을 설정할 수 있게 해 줘요. 이는 일반적으로 스케줄러만 사용해요.

Pod 세대 (generation)

metadata.generation 필드는 고유해요. 시스템이 자동으로 설정해서 새 pod는 metadata.generation이 1이고, pod 스펙의 변경 가능한 필드에 대한 모든 갱신은 metadata.generation을 1씩 증가시켜요.

기능 상태: Kubernetes v1.35부터 Stable

observedGeneration은 Pod 객체의 status 섹션에 포착되는 필드예요. kubelet은 status.observedGeneration을 설정해 pod 상태를 현재 pod 상태로 추적해요. pod의 status.observedGeneration은 pod 상태가 보고되는 시점의 pod metadata.generation을 반영해요.

참고: status.observedGeneration 필드는 kubelet이 관리하며 외부 컨트롤러가 이 필드를 수정해서는 안 돼요.

서로 다른 상태 필드는 현재 동기화 루프의 metadata.generation 또는 이전 동기화 루프의 metadata.generation과 연관될 수 있어요. 핵심 구분은 스펙의 변경이 상태에 직접 반영되는지, 아니면 실행 중인 프로세스의 간접 결과인지에 있어요.

직접 상태 갱신

할당된 스펙이 직접 반영되는 상태 필드의 경우 observedGeneration은 현재 metadata.generation(Generation N)과 연관돼요.

이 동작은 다음에 적용돼요.

  • Resize Status: 리소스 resize 작업의 상태.
  • Allocated Resources: resize 후 Pod에 할당된 리소스.
  • Ephemeral Containers: 새 임시 컨테이너가 추가되고 Waiting 상태일 때.

간접 상태 갱신

스펙 실행의 간접 결과인 상태 필드의 경우 observedGeneration은 이전 동기화 루프의 metadata.generation(Generation N-1)과 연관돼요.

이 동작은 다음에 적용돼요.

  • Container Image: ContainerStatus.ImageID는 새 이미지가 풀링되고 컨테이너가 갱신될 때까지 이전 세대의 이미지를 반영해요.
  • Actual Resources: 진행 중인 resize 중 실제 사용 중인 리소스는 여전히 이전 세대의 request에 속해요.
  • Container state: 진행 중인 resize 중 require restart policy를 가진 상태는 이전 세대의 request를 반영해요.
  • activeDeadlineSeconds, terminationGracePeriodSeconds, deletionTimestamp: 이 필드들이 Pod 상태에 미치는 영향은 이전에 관찰된 스펙의 결과예요.

리소스 공유와 통신

Pod는 구성 컨테이너 간의 데이터 공유와 통신을 가능하게 해요.

Pod의 스토리지

Pod는 공유 스토리지 볼륨 집합을 지정할 수 있어요. Pod의 모든 컨테이너는 공유 볼륨에 접근할 수 있어서, 컨테이너들이 데이터를 공유할 수 있어요. 볼륨은 또한 Pod 안의 컨테이너 중 하나가 재시작해야 할 경우 영구 데이터가 살아남도록 해요. Kubernetes가 공유 스토리지를 구현하고 Pod에 제공하는 방법에 대한 자세한 내용은 Storage를 참고하세요.

Pod 네트워킹

각 Pod는 각 주소 패밀리에 대해 고유한 IP 주소를 할당받아요. Pod의 모든 컨테이너는 IP 주소와 네트워크 포트를 포함한 네트워크 네임스페이스를 공유해요. Pod 안에서(그리고 그때만) Pod에 속한 컨테이너는 localhost를 사용해 서로 통신할 수 있어요. Pod의 컨테이너가 Pod 밖의 엔티티와 통신할 때는 공유 네트워크 리소스(포트 등)를 어떻게 사용할지 조정해야 해요. Pod 안에서 컨테이너는 IP 주소와 포트 공간을 공유하고 localhost로 서로를 찾을 수 있어요. Pod의 컨테이너는 SystemV 세마포어나 POSIX 공유 메모리 같은 표준 프로세스 간 통신도 사용해 서로 통신할 수 있어요. 서로 다른 Pod의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이는 OS 수준 IPC로 통신할 수 없어요. 다른 Pod에서 실행되는 컨테이너와 상호작용하려는 컨테이너는 IP 네트워킹을 사용해 통신할 수 있어요.

Pod 안의 컨테이너는 시스템 호스트 이름이 Pod의 구성된 이름과 동일한 것으로 봐요. 이에 대한 자세한 내용은 네트워킹 섹션에 있어요.

Pod 보안 설정

Pod와 컨테이너에 보안 제약을 설정하려면 Pod 스펙의 securityContext 필드를 사용해요. 이 필드는 Pod나 개별 컨테이너가 할 수 있는 일에 대해 세밀한 제어를 제공해요. 자세한 내용은 Advanced Pod Configuration을 참고하세요.

기본 보안 구성의 경우 Baseline Pod 보안 표준을 충족하고 컨테이너를 non-root로 실행해야 해요. 간단한 보안 컨텍스트를 설정할 수 있어요.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  -  name: sec-ctx-demo
     image: busybox
     command: ["sh", "-c", "sleep 1h"]

capabilities, seccomp 프로필, 세부 보안 옵션을 포함한 고급 보안 컨텍스트 구성은 security concepts 섹션을 참고하세요.

  • 사용할 수 있는 커널 수준 보안 제약에 대해 배우려면 Pod와 컨테이너의 Linux 커널 보안 제약을 참고하세요.
  • Pod 보안 컨텍스트에 대해 더 배우려면 Pod 또는 컨테이너에 대한 Security Context 구성을 참고하세요.

리소스 requests와 limits

Pod를 지정할 때 각 리소스에 대해 컨테이너가 얼마나 필요할지 선택적으로 지정할 수 있어요. 가장 흔히 지정하는 리소스는 CPU와 메모리(RAM)예요.

Pod의 컨테이너에 대한 리소스 request를 지정하면 kube-scheduler가 이 정보를 사용해 Pod를 배치할 노드를 결정해요. 컨테이너에 대한 리소스 limit를 지정하면 kubelet이 그 limits를 시행해서 실행 중인 컨테이너가 설정한 limit보다 더 많은 리소스를 사용하지 못하게 해요.

CPU limits는 CPU 스로틀링으로 시행돼요. 컨테이너가 CPU limit에 가까워지면 커널이 CPU 접근을 제한해요. 메모리 limits는 컨테이너가 limit를 초과하면 커널이 OOM(out-of-memory) kill으로 시행해요.

참고: CPU limits 설정은 트레이드오프를 수반해요. CPU limits는 단일 워크로드가 같은 노드의 다른 워크로드를 굶기게 하는 noisy neighbor 문제를 방지하는 데 도움이 돼요. 이는 특히 멀티 테넌트 환경에서 중요해요. 하지만 CPU limits는 노드에 여유 CPU 용량이 있어도 스로틀링을 일으켜 지연에 민감한 워크로드 성능을 저하시킬 수 있어요. CPU limits를 설정할지 여부는 환경, 워크로드 특성, 격리 요구사항에 따라 달라져요.

리소스 단위, 시행 동작, 구성 예시에 대한 자세한 내용은 Pod와 컨테이너의 리소스 관리를 참고하세요.

정적 Pod (Static Pods)

정적 Pod는 API 서버가 관찰하지 않고 특정 노드의 kubelet 데몬이 직접 관리해요. 대부분의 Pod가 컨트롤 플레인(예: Deployment)에 의해 관리되는 반면, 정적 Pod의 경우 kubelet이 각 정적 Pod를 직접 감독해요(실패하면 재시작).

정적 Pod는 항상 특정 노드의 하나의 kubelet에 바인딩돼요. 정적 Pod의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 거예요. 즉 kubelet을 사용해 개별 컨트롤 플레인 컴포넌트를 감독하는 거예요.

자세한 내용은 Static Pods를 참고하세요.

여러 컨테이너가 있는 Pod

Pod는 하나의 응집된 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너로)를 지원하도록 설계됐어요. Pod의 컨테이너는 클러스터의 같은 물리적 또는 가상 머신에 자동으로 함께 위치하고 함께 스케줄링돼요. 컨테이너는 리소스와 의존성을 공유하고, 서로 통신하며, 언제 어떻게 종료될지 조정할 수 있어요.

Kubernetes 클러스터의 Pod는 두 가지 주요 방식으로 사용돼요.

  • 단일 컨테이너를 실행하는 Pod. "Pod당 컨테이너 하나" 모델은 가장 일반적인 Kubernetes 사용 사례예요. 이 경우 Pod를 단일 컨테이너를 감싸는 래퍼로 생각할 수 있어요. Kubernetes는 컨테이너를 직접 관리하는 대신 Pod를 관리해요.
  • 함께 동작해야 하는 여러 컨테이너를 실행하는 Pod. Pod는 밀접하게 결합되고 리소스를 공유해야 하는 여러 함께 위치한 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있어요. 이러한 함께 위치한 컨테이너는 하나의 응집된 서비스 단위를 형성해요. 예를 들어 한 컨테이너가 공유 볼륨에 저장된 데이터를 공개적으로 서비스하고, 별도의 사이드카 컨테이너가 그 파일을 원격 소스에서 새로 고치거나 갱신하는 경우가 있어요. Pod는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 정체성을 단일 단위로 함께 감싸요.

예를 들어 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 그 파일을 갱신하는 별도의 사이드카 컨테이너가 있을 수 있어요. 아래 그림처럼요.

일부 Pod는 앱 컨테이너와 함께 init 컨테이너도 가져요. 기본적으로 init 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료돼요.

또한 메인 애플리케이션 Pod에 보조 서비스를 제공하는 사이드카 컨테이너도 가질 수 있어요(예: 서비스 메시).

기능 상태: Kubernetes v1.33부터 Stable

기본적으로 활성화된 SidecarContainers 기능 게이트는 init 컨테이너에 restartPolicy: Always를 지정할 수 있게 해 줘요. Always 재시작 정책을 설정하면 설정한 컨테이너가 Pod 수명 동안 계속 실행되는 사이드카로 취급되도록 보장해요. 사이드카 컨테이너로 명시적으로 정의한 컨테이너는 메인 애플리케이션 Pod보다 먼저 시작되어 Pod가 종료될 때까지 계속 실행돼요.

컨테이너 프로브 (Container probes)

프로브는 kubelet이 컨테이너에 대해 주기적으로 수행하는 진단이에요. 진단을 수행하기 위해 kubelet은 다른 작업을 호출할 수 있어요.

  • ExecAction (컨테이너 런타임의 도움으로 수행)
  • TCPSocketAction (kubelet이 직접 확인)
  • HTTPGetAction (kubelet이 직접 확인)

프로브에 대한 자세한 내용은 Pod Lifecycle 문서에서 읽을 수 있어요.

더 알아보기

  • Pod의 수명 주기에 대해 배워 보세요.
  • PodDisruptionBudget과 중단 중 애플리케이션 가용성 관리 방법에 대해 읽어 보세요.
  • Pod는 Kubernetes REST API의 최상위 리소스예요. Pod 객체 정의는 객체를 자세히 설명해요.
  • Distributed System Toolkit: Patterns for Composite Containers 는 컨테이너가 둘 이상인 Pod의 일반적인 레이아웃을 설명해요.
  • Pod 토폴로지 분산 제약에 대해 읽어 보세요.
  • 자세한 내용은 Advanced Pod Configuration을 읽어 보세요. 이 페이지는 필수 이상의 Pod 구성 측면을 다뤄요. 다음을 포함해요.
    • PriorityClasses
    • RuntimeClasses
    • 스케줄링을 구성하는 고급 방법: Kubernetes가 Pod를 실행할 노드를 결정하는 방식.

Kubernetes가 왜 공통 Pod API를 다른 리소스(StatefulSet이나 Deployment 같은)로 감싸는지의 맥락을 이해하려면 이전 사례(Aurora, Borg, Marathon, Omega, Tupperware)를 읽어 볼 수 있어요.