파드

파드 (Pods)

파드 는 쿠버네티스에서 만들고 관리할 수 있는 가장 작은 컴퓨팅 배포 단위입니다.

파드(고래 떼나 완두콩 꼬투리에서처럼)는 공유 저장소와 네트워크 리소스, 그리고 컨테이너 실행 방법에 대한 명세를 가진 하나 이상의 컨테이너 그룹입니다. 파드의 내용은 항상 함께 위치하고 함께 스케줄링되며, 공유 컨텍스트에서 실행됩니다. 파드는 애플리케이션별 "논리 호스트"를 모델링합니다: 비교적 긴밀하게 결합된 하나 이상의 애플리케이션 컨테이너를 포함합니다. 비클라우드 컨텍스트에서 같은 물리적 또는 가상 머신에서 실행되는 애플리케이션은 클라우드 애플리케이션이 같은 논리 호스트에서 실행되는 것과 유사합니다.

애플리케이션 컨테이너 외에도 파드는 파드 시작 중에 실행되는 초기화 컨테이너를 포함할 수 있습니다. 또한 실행 중인 파드를 디버깅하기 위해 임시 컨테이너를 주입할 수 있습니다.

출처: 문서

본문

파드란 무엇인가?

클러스터의 각 노드에 컨테이너 런타임을 설치해야 파드가 그곳에서 실행될 수 있습니다.

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

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

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용됩니다:

단일 컨테이너를 실행하는 파드. "컨테이너당 파드 하나" 모델은 가장 흔한 쿠버네티스 사용 사례입니다. 이 경우 파드를 단일 컨테이너를 감싸는 래퍼로 생각할 수 있습니다. 쿠버네티스는 컨테이너를 직접 관리하는 것이 아니라 파드를 관리합니다.
함께 작동해야 하는 여러 컨테이너를 실행하는 파드. 파드는 긴밀하게 결합되고 리소스를 공유해야 하는 여러 공동 배치된 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있습니다. 이러한 공동 배치된 컨테이너는 단일 응집 단위를 형성합니다.

여러 공동 배치되고 공동 관리되는 컨테이너를 단일 파드로 그룹화하는 것은 비교적 고급 사용 사례입니다. 컨테이너가 긴밀하게 결합된 특정 경우에만 이 패턴을 사용해야 합니다.

복제를 위해 여러 컨테이너를 실행할 필요는 없습니다(복원력 또는 용량용). 여러 replica가 필요하면 워크로드 관리를 참조하세요.

파드 사용하기

다음은 nginx:1.14.2 이미지를 실행하는 컨테이너로 구성된 파드의 예시입니다.

위 파드를 만들려면 다음 명령을 실행합니다:

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

파드는 일반적으로 직접 만들어지지 않고 워크로드 리소스를 사용해 만들어집니다. 파드가 워크로드 리소스와 함께 어떻게 사용되는지에 대한 자세한 내용은 파드 작업을 참조하세요.

파드 관리를 위한 워크로드 리소스

보통 단일 파드(싱글톤 파드)조차도 파드를 직접 만들 필요가 없습니다. 대신 Deployment나 Job 같은 워크로드 리소스를 사용해 만듭니다. 파드가 상태를 추적해야 한다면 StatefulSet 리소스를 고려하세요.

각 파드는 주어진 애플리케이션의 단일 인스턴스를 실행하기 위한 것입니다. 애플리케이션을 수평으로 스케일링(더 많은 인스턴스를 실행해 더 많은 전체 리소스 제공)하려면 인스턴스당 파드 하나로 여러 파드를 사용해야 합니다. 쿠버네티스에서 이는 보통 복제 라고 합니다. 복제된 파드는 보통 워크로드 리소스와 그 컨트롤러가 그룹으로 만들고 관리합니다.

쿠버네티스가 워크로드 리소스와 그 컨트롤러를 사용해 애플리케이션 스케일링과 자동 복구를 구현하는 방법에 대한 자세한 내용은 파드와 컨트롤러를 참조하세요.

파드는 구성 컨테이너를 위해 네트워킹과 저장소라는 두 가지 종류의 공유 리소스를 기본 제공합니다.

파드 작업하기

쿠버네티스에서 개별 파드를 직접 만드는 경우는 드물 것입니다 — 싱글톤 파드도 마찬가지입니다. 이는 파드가 상대적으로 일시적이고 일회용인 엔티티로 설계되었기 때문입니다. 파드가 생성되면(직접 또는 컨트롤러에 의해 간접적으로), 새 파드는 클러스터의 노드에서 실행되도록 스케줄링됩니다. 파드는 실행을 마치고, 파드 객체가 삭제되거나, 리소스 부족으로 파드가 축출(evict) 되거나, 노드가 실패할 때까지 그 노드에 남아 있습니다.

파드의 컨테이너를 재시작하는 것은 파드를 재시작하는 것과 혼동하면 안 됩니다. 파드는 프로세스가 아니라 컨테이너를 실행하기 위한 환경입니다. 파드는 삭제될 때까지 지속됩니다.

파드의 이름은 유효한 DNS 서브도메인 값이어야 하지만, 이는 파드 호스트네임에 예상치 못한 결과를 초래할 수 있습니다. 최상의 호환성을 위해 이름은 DNS 라벨의 더 제한적인 규칙을 따라야 합니다.

파드 OS

.spec.os.name 필드를 windows 또는 linux 중 하나로 설정해 해당 파드의 컨테이너가 요구하는 운영 체제를 나타내야 합니다. 이 두 가지는 현재 쿠버네티스가 지원하는 유일한 운영 체제입니다. 향후 이 목록은 확장될 수 있습니다.

.spec.os.name의 값이 노드의 운영 체제와 일치하지 않으면 kubelet은 파드 실행을 거부합니다. 그러나 쿠버네티스 v1.37에서 .spec.os.name의 값은 스케줄러가 파드를 실행할 노드를 선택하는 방식을 변경하지 않습니다. 실행 노드에 둘 이상의 운영 체제가 있는 클러스터에서는 각 노드에 kubernetes.io/os 라벨을 올바르게 설정하고, 운영 체제 라벨을 기반으로 하는 nodeSelector로 파드를 정의해야 합니다. kube-scheduler는 다른 기준에 따라 노드에 파드를 할당하며, 파드의 컨테이너에 맞는 노드 OS인 적절한 노드 배치를 선택하는 데 성공할 수도 있고 아닐 수도 있습니다. Pod security standards도 이 필드를 사용해 운영 체제와 관련 없는 정책을 강제하지 않도록 합니다.

파드와 컨트롤러

워크로드 리소스를 사용해 여러 파드를 만들고 관리할 수 있습니다. 리소스의 컨트롤러가 복제, 롤아웃, 파드 실패 시 자동 복구를 처리합니다. 예를 들어 노드가 실패하면 컨트롤러는 그 노드의 파드가 작동을 멈췄음을 알아차리고 대체 파드를 만듭니다. 스케줄러는 대체 파드를 정상 노드에 배치합니다.

하나 이상의 파드를 관리하는 워크로드 리소스의 몇 가지 예시:

Deployment
StatefulSet
DaemonSet

스케줄링 그룹 지정

기본적으로 쿠버네티스는 모든 파드를 개별적으로 스케줄링합니다. 그러나 일부 긴밀하게 결합된 애플리케이션은 올바르게 작동하려면 파드 그룹이 동시에 스케줄링되어야 합니다.

scheduling group 필드(spec.schedulingGroup)를 사용해 파드를 PodGroup에 연결할 수 있습니다. 이는 kube-scheduler에 Pod가 특정 그룹에 속함을 알려, 전체 그룹에 대해 한 번에 그룹 수준의 조정된 배치 결정을 적용할 수 있게 합니다.

파드 템플릿

워크로드 리소스의 컨트롤러는 파드 템플릿 에서 파드를 만들고 사용자를 대신해 그 파드를 관리합니다.

PodTemplate은 파드 생성을 위한 명세이며 Deployment, Job, DaemonSet 같은 워크로드 리소스에 포함됩니다.

워크로드 리소스의 각 컨트롤러는 워크로드 객체 안의 PodTemplate을 사용해 실제 파드를 만듭니다. PodTemplate은 앱을 실행하는 데 사용하는 모든 워크로드 리소스의 원하는 상태의 일부입니다.

파드를 만들 때 파드에서 실행되는 컨테이너를 위해 파드 템플릿에 환경 변수를 포함할 수 있습니다.

아래 예시는 컨테이너 하나를 시작하는 template을 가진 간단한 Job의 매니페스트입니다. 그 파드의 컨테이너는 메시지를 출력한 뒤 일시 중지합니다.

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

파드 템플릿을 수정하거나 새 파드 템플릿으로 전환하는 것은 이미 존재하는 파드에 직접적인 영향을 주지 않습니다. 워크로드 리소스의 파드 템플릿을 변경하면 그 리소스는 업데이트된 템플릿을 사용하는 대체 파드를 만들어야 합니다.

예를 들어 StatefulSet 컨트롤러는 각 StatefulSet 객체에 대해 실행 중인 파드가 현재 파드 템플릿과 일치하도록 보장합니다. StatefulSet을 편집해 파드 템플릿을 변경하면 StatefulSet은 업데이트된 템플릿을 기반으로 새 파드를 만들기 시작합니다. 결국 모든 오래된 파드가 새 파드로 교체되고 업데이트가 완료됩니다.

각 워크로드 리소스는 파드 템플릿 변경 처리를 위한 자체 규칙을 구현합니다. StatefulSet에 대해 더 읽으려면 StatefulSet Basics 튜토리얼의 업데이트 전략을 읽어보세요.

노드에서 kubelet은 파드 템플릿과 업데이트에 관한 세부 사항을 직접 관찰하거나 관리하지 않습니다. 그 세부 사항은 추상화되어 있습니다. 그 추상화와 관심사의 분리는 시스템 의미론을 단순화하고, 기존 코드를 변경하지 않고 클러스터의 동작을 확장하는 것을 가능하게 합니다.

파드 업데이트와 교체

이전 섹션에서 언급했듯이 워크로드 리소스의 파드 템플릿이 변경되면 컨트롤러는 기존 파드를 업데이트하거나 패치하는 대신 업데이트된 템플릿을 기반으로 새 파드를 만듭니다.

쿠버네티스는 파드를 직접 관리하는 것을 막지 않습니다. 실행 중인 파드의 일부 필드를 제자리에서 업데이트하는 것이 가능합니다. 그러나 patch과 replace 같은 파드 업데이트 작업에는 몇 가지 제한이 있습니다:

파드에 대한 메타데이터의 대부분은 불변입니다. 예를 들어 namespace, name, uid, creationTimestamp 필드를 변경할 수 없습니다.
metadata.deletionTimestamp가 설정되면 metadata.finalizers 목록에 새 항목을 추가할 수 없습니다.
파드 업데이트는 spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds, spec.terminationGracePeriodSeconds, spec.tolerations, spec.schedulingGates 외의 필드를 변경할 수 없습니다. spec.tolerations의 경우 새 항목만 추가할 수 있습니다.
spec.activeDeadlineSeconds 필드를 업데이트할 때 두 가지 유형의 업데이트가 허용됩니다:
1. 할당되지 않은 필드를 양수로 설정;
2. 필드를 양수에서 더 작은 음이 아닌 수로 업데이트.

파드 서브리소스

위 업데이트 규칙은 일반적인 파드 업데이트에 적용되지만, 다른 파드 필드는 서브리소스 를 통해 업데이트될 수 있습니다.

Resize: resize 서브리소스는 컨테이너 리소스(spec.containers[*].resources)를 업데이트할 수 있게 합니다. 자세한 내용은 컨테이너 리소스 크기 조정을 참조하세요.
Ephemeral Containers: ephemeralContainers 서브리소스는 파드에 임시 컨테이너를 추가할 수 있게 합니다. 자세한 내용은 Ephemeral Containers를 참조하세요.
Status: status 서브리소스는 파드 상태의 업데이트를 허용합니다. 이는 보통 Kubelet과 다른 시스템 컨트롤러만 사용합니다.
Binding: binding 서브리소스는 Binding 요청을 통해 파드의 spec.nodeName 설정을 허용합니다. 이는 보통 스케줄러만 사용합니다.

파드 생성(generation)

metadata.generation 필드는 고유합니다. 시스템이 자동으로 설정하여 새 파드가 metadata.generation 1이 되고, 파드 스펙의 변경 가능한 필드에 대한 모든 업데이트는 metadata.generation을 1씩 증가시킵니다.
observedGeneration은 파드 객체의 status 섹션에 캡처되는 필드입니다. Kubelet은 status.observedGeneration을 설정해 파드 상태를 현재 파드 상태로 추적합니다. 파드의 status.observedGeneration은 파드 상태가 보고되는 시점의 파드의 metadata.generation을 반영합니다.

status.observedGeneration 필드는 kubelet이 관리하며 외부 컨트롤러는 이 필드를 수정해서는 안 됩니다.

다른 상태 필드는 현재 동기화 루프의 metadata.generation과 연관되거나 이전 동기화 루프의 metadata.generation과 연관될 수 있습니다. 핵심 차이는 spec의 변경이 status에 직접 반영되는지 아니면 실행 중인 프로세스의 간접적 결과인지입니다.

직접 상태 업데이트

할당된 spec이 직접 반영되는 상태 필드의 경우 observedGeneration은 현재 metadata.generation(Generation N)과 연관됩니다.

이 동작은 다음에 적용됩니다:

Resize Status: 리소스 크기 조정 작업의 상태.
Allocated Resources: 크기 조정 후 파드에 할당된 리소스.
Ephemeral Containers: 새 임시 컨테이너가 추가되고 Waiting 상태일 때.

간접 상태 업데이트

spec 실행의 간접적 결과인 상태 필드의 경우 observedGeneration은 이전 동기화 루프의 metadata.generation(Generation N-1)과 연관됩니다.

이 동작은 다음에 적용됩니다:

Container Image: ContainerStatus.ImageID는 새 이미지가 풀되고 컨테이너가 업데이트될 때까지 이전 세대의 이미지를 반영한다.
Actual Resources: 진행 중인 크기 조정 동안 사용 중인 실제 리소스는 여전히 이전 세대의 요청에 속한다.
Container state: 진행 중인 크기 조정 동안 restart 반영 요구 정책은 이전 세대의 요청을 반영한다.
activeDeadlineSeconds & terminationGracePeriodSeconds & deletionTimestamp: 이 필드들이 파드 상태에 미치는 영향은 이전에 관찰된 스펙의 결과이다.

리소스 공유와 통신

파드는 구성 컨테이너 간의 데이터 공유와 통신을 가능하게 합니다.

파드의 저장소 {#pod-storage}

파드는 공유 저장소 볼륨 집합을 지정할 수 있습니다. 파드의 모든 컨테이너는 공유 볼륨에 접근할 수 있어 컨테이너들이 데이터를 공유할 수 있습니다. 볼륨은 또한 파드의 영구 데이터가 그 안의 컨테이너 중 하나를 재시작해야 할 때 살아남게 합니다. 쿠버네티스가 공유 저장소를 구현하고 파드에 제공하는 방법에 대한 자세한 내용은 저장소를 참조하세요.

파드 네트워킹

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

파드 안의 컨테이너는 시스템 호스트네임을 파드의 구성된 name과 동일하게 봅니다. 이에 대한 더 자세한 내용은 네트워킹 섹션에 있습니다.

파드 보안 설정 {#pod-security}

파드와 컨테이너에 보안 제약을 설정하려면 파드 명세의 securityContext 필드를 사용합니다. 이 필드는 파드나 개별 컨테이너가 할 수 있는 것에 대한 세밀한 제어를 제공합니다. 자세한 내용은 고급 파드 구성을 참조하세요.

기본 보안 구성의 경우 Baseline Pod security standard를 충족하고 컨테이너를 비루트로 실행해야 합니다. 간단한 보안 컨텍스트를 설정할 수 있습니다:

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 프로필, 세부 보안 옵션을 포함한 고급 보안 컨텍스트 구성은 보안 개념 섹션을 참조하세요.

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

리소스 요청과 한도

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

파드의 컨테이너에 대한 리소스 요청 을 지정하면 kube-scheduler는 이 정보를 사용해 파드를 배치할 노드를 결정합니다. 컨테이너에 대한 리소스 한도 를 지정하면 kubelet은 실행 중인 컨테이너가 설정한 한도보다 더 많은 리소스를 사용하지 못하도록 해당 한도를 강제합니다.

CPU 한도는 CPU 스로틀링에 의해 강제됩니다. 컨테이너가 CPU 한도에 가까워지면 커널이 CPU 접근을 제한합니다. 메모리 한도는 컨테이너가 한도를 초과할 때 커널이 out-of-memory(OOM) 킬로 강제합니다.

CPU 한도 설정은 트레이드오프를 포함합니다. CPU 한도는 단일 워크로드가 같은 노드의 다른 것을 굶기게 하는 시끄러운 이웃 문제를 방지하는 데 도움이 됩니다. 이는 멀티테넌트 환경에서 특히 중요합니다. 그러나 CPU 한도는 노드에 여유 CPU 용량이 있어도 스로틀링을 일으켜 지연시간에 민감한 워크로드 성능을 저하시킬 수 있습니다. CPU 한도를 설정할지 여부는 환경, 워크로드 특성, 격리 요구 사항에 따라 다릅니다.

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

스태틱 파드

스태틱 파드 는 API 서버가 관찰하지 않고 특정 노드의 kubelet 데몬이 직접 관리합니다. 대부분의 파드는 컨트롤 플레인(예: Deployment)이 관리하지만, 스태틱 파드의 경우 kubelet이 각 스태틱 파드를 직접 감독합니다(실패하면 재시작).

스태틱 파드는 항상 특정 노드의 하나에 바인딩됩니다. 스태틱 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것입니다. 다시 말해 kubelet을 사용해 개별 컨트롤 플레인 구성 요소를 감독하는 것입니다.

자세한 내용은 스태틱 파드를 참조하세요.

여러 컨테이너가 있는 파드 {#how-pods-manage-multiple-containers}

파드는 응집 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너로서)를 지원하도록 설계되었습니다. 파드의 컨테이너는 클러스터의 같은 물리적 또는 가상 머신에 자동으로 공동 배치되고 공동 스케줄링됩니다. 컨테이너는 리소스와 종속성을 공유하고, 서로 통신하며, 언제 어떻게 종료될지 조정할 수 있습니다.

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용됩니다:

단일 컨테이너를 실행하는 파드. "컨테이너당 파드 하나" 모델은 가장 흔한 쿠버네티스 사용 사례입니다. 이 경우 파드를 단일 컨테이너를 감싸는 래퍼로 생각할 수 있습니다. 쿠버네티스는 컨테이너를 직접 관리하는 것이 아니라 파드를 관리합니다.
함께 작동해야 하는 여러 컨테이너를 실행하는 파드. 파드는 긴밀하게 결합되고 리소스를 공유해야 하는 여러 공동 배치된 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있습니다. 이러한 공동 배치된 컨테이너는 단일 응집 서비스 단위를 형성합니다 — 예를 들어 한 컨테이너가 공유 볼륨에 저장된 데이터를 대중에게 제공하고, 별도의 사이드카 컨테이너가 그 파일들을 새로 고치거나 업데이트합니다. 파드는 이러한 컨테이너, 저장소 리소스, 임시 네트워크 신원을 단일 단위로 감쌉니다.

예를 들어 공유 볼륨의 파일을 위한 웹 서버 역할을 하는 컨테이너와, 아래 다이어그램처럼 원격 소스에서 그 파일들을 업데이트하는 별도의 사이드카 컨테이너가 있을 수 있습니다.

일부 파드는 앱 컨테이너뿐만 아니라 초기화 컨테이너(init containers)도 가집니다. 기본적으로 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료됩니다.

또한 메인 애플리케이션 파드에 보조 서비스를 제공하는 사이드카 컨테이너(예: service mesh)를 가질 수 있습니다.

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

컨테이너 프로브

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

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

프로브에 대해 Pod Lifecycle 문서에서 더 읽을 수 있습니다.

더 알아보기 (Learn more)

파드의 라이프사이클 알아보기.
PodDisruptionBudget과 그것을 사용해 중단 중 애플리케이션 가용성을 관리하는 방법 읽기.
파드는 쿠버네티스 REST API의 최상위 수준 리소스입니다. Pod 객체 정의가 객체를 자세히 설명합니다.
분산 시스템 툴킷: 복합 컨테이너의 패턴은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명합니다.
Pod 토폴로지 분산 제약 읽기
고급 파드 구성을 읽어 주제를 자세히 배우세요. 그 페이지는 필수적인 것 이상의 파드 구성 측면을 다루며, 다음을 포함합니다:
- PriorityClasses
- RuntimeClasses
- 스케줄링 구성의 고급 방법: 쿠버네티스가 파드가 실행되어야 할 노드를 결정하는 방식.

쿠버네티스가 공통 파드 API를 다른 리소스(예: Deployment 또는 StatefulSet)로 감싸는 이유의 맥락을 이해하기 위해 이전 기술을 읽을 수 있습니다: