From 267a904afecb1898f8fd1efbaa9d0ca07f34fd32 Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Tue, 4 Oct 2022 22:59:45 +0900 Subject: [PATCH] outdated M42 - M52 --- content/ko/docs/concepts/windows/intro.md | 7 +- .../ko/docs/concepts/windows/user-guide.md | 5 +- .../workloads/controllers/cron-jobs.md | 2 +- .../workloads/controllers/deployment.md | 4 +- .../concepts/workloads/controllers/job.md | 86 ++++++++++++++++++- .../workloads/controllers/statefulset.md | 11 ++- .../ko/docs/concepts/workloads/pods/_index.md | 17 ++++ .../concepts/workloads/pods/disruptions.md | 38 ++++++++ .../concepts/workloads/pods/downward-api.md | 4 +- .../workloads/pods/ephemeral-containers.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 37 +++++++- .../job-pod-failure-policy-example.yaml | 28 ++++++ 12 files changed, 219 insertions(+), 22 deletions(-) create mode 100644 content/ko/examples/controllers/job-pod-failure-policy-example.yaml diff --git a/content/ko/docs/concepts/windows/intro.md b/content/ko/docs/concepts/windows/intro.md index 4cdae9af3f..42eabf61b6 100644 --- a/content/ko/docs/concepts/windows/intro.md +++ b/content/ko/docs/concepts/windows/intro.md @@ -88,13 +88,12 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * OS 필드: 특정 파드가 윈도우 컨테이너를 사용하고 있다는 것을 나타내려면 `.spec.os.name` 필드를 `windows`로 설정해야 한다. - 이 필드가 인식되도록 하기 위해서는 `IdentifyPodOS` 기능 게이트가 활성화되어야 한다. {{< note >}} - 쿠버네티스 1.24부터, `IdentifyPodOS` 기능 게이트는 베타 단계이며 기본적으로 활성화되어 있다. + 쿠버네티스 1.25부터, `IdentifyPodOS` 기능 게이트는 GA 단계이며 기본적으로 활성화되어 있다. {{< /note >}} - `IdentifyPodOS` 기능 게이트가 활성화되어 있고 `.spec.os.name` 필드를 `windows`로 설정했다면, + `.spec.os.name` 필드를 `windows`로 설정했다면, 해당 파드의 `.spec` 내의 다음 필드는 설정하지 않아야 한다. * `spec.hostPID` @@ -285,7 +284,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다. 쿠버네티스 v{{< skew currentVersion >}}의 경우 -권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.6`이다. +권장 퍼즈 이미지는 `registry.k8s.io/pause:3.6`이다. [소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는 GitHub에서 찾을 수 있다. Microsoft는 리눅스 및 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 diff --git a/content/ko/docs/concepts/windows/user-guide.md b/content/ko/docs/concepts/windows/user-guide.md index 1ecb608480..8321d70cde 100644 --- a/content/ko/docs/concepts/windows/user-guide.md +++ b/content/ko/docs/concepts/windows/user-guide.md @@ -158,14 +158,13 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. -`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, -파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). +1.25부터, 파드의 컨테이너가 어떤 운영체제 용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). 리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. 윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `windows`로 설정한다. {{< note >}} -1.24부터, `IdentifyPodOS` 기능은 베타 단계이며 기본적으로 활성화되어 있다. +1.25부터, `IdentifyPodOS` 기능은 GA 단계이며 기본적으로 활성화되어 있다. {{< /note >}} 스케줄러는 파드를 노드에 할당할 때 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 7a28dd02e0..4979858b41 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -94,7 +94,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ## 타임 존 크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다. -{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +{{< feature-state for_k8s_version="v1.25" state="beta" >}} `CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, 크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index f808131e9e..10651aa8e9 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -121,8 +121,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. * `AGE` 는 애플리케이션의 실행된 시간을 표시한다. - 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은 - 무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다. + 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[HASH]` 형식으로 된 것을 알 수 있다. + `HASH` 문자열은 레플리카셋의 `pod-template-hash` 레이블과 같다. 6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 3d97110871..4535674af1 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -695,6 +695,89 @@ spec: `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있으며 이런 불일치를 허용한다고 알릴 수 있다. +### 파드 실패 정책{#pod-failure-policy} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +{{< note >}} +잡(Job)에 대한 파드 실패 정책은 +`JobPodFailurePolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +클러스터에서 활성화됐을 경우에만 구성할 수 있다. 추가적으로, +파드 장애 정책의 파드 중단 조건 (참조: +[파드 중단 조건](/ko/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions))을 +감지하고 처리할 수 있도록 `PodDisruptionConditions` 기능 게이트를 활성화하는 것을 권장한다. 두 기능 게이트 모두 +쿠버네티스 v1.25에서 사용할 수 있다. +{{< /note >}} + +`.spec.podFailurePolicy` 필드로 정의되는 파드 실패 정책은, 클러스터가 +컨테이너 종료 코드와 파드 상태를 기반으로 파드의 실패를 +처리하도록 활성화한다. + +어떤 상황에서는, 파드의 실패를 처리할 때 잡(Job)의 `.spec.backoffLimit`을 기반으로 하는 +[파드 백오프(backoff) 실패 정책](#pod-backoff-failure-policy)에서 +제공하는 제어보다 더 나은 제어를 원할 수 있다. 다음은 사용 사례의 몇 가지 예시다. +* 불필요한 파드 재시작을 방지하여 워크로드 실행 비용을 최적화하려면, + 파드 중 하나가 소프트웨어 버그를 나타내는 종료 코드와 함께 실패하는 즉시 + 잡을 종료할 수 있다. +* 중단이 있더라도 잡이 완료되도록 하려면, + 중단(예: {{< glossary_tooltip text="선점(preemption)" term_id="preemption" >}}, + {{< glossary_tooltip text="API를 이용한 축출(API-initiated Eviction)" term_id="api-eviction" >}} + 또는 축출 기반 {{< glossary_tooltip text="테인트(Taints)" term_id="taint" >}})으로 인한 + 파드 실패를 무시하여 `.spec.backoffLimit` 재시도 한도에 포함되지 않도록 할 수 있다. + +위의 사용 사례를 충족하기 위해 +`.spec.podFailurePolicy` 필드에 파드 실패 정책을 구성할 수 있다. +이 정책은 컨테이너 종료 코드 및 파드 상태를 기반으로 파드 실패를 처리할 수 있다. + +다음은 `podFailurePolicy`를 정의하는 잡의 매니페스트이다. + +{{< codenew file="/controllers/job-pod-failure-policy-example.yaml" >}} + +위 예시에서, 파드 실패 정책의 첫 번째 규칙은 `main` 컨테이너가 42 종료코드와 +함께 실패하면 잡도 실패로 표시되는 것으로 +지정한다. 다음은 구체적으로 `main` 컨테이너에 대한 규칙이다. + +- 종료 코드 0은 컨테이너가 성공했음을 의미한다. +- 종료 코드 42는 **전체 잡**이 실패했음을 의미한다. +- 다른 모든 종료 코드는 컨테이너 및 전체 파드가 실패했음을 + 나타낸다. 재시작 횟수인 `backoffLimit`까지 파드가 + 다시 생성된다. 만약 `backoffLimit`에 도달하면 **전체 잡**이 실패한다. + +{{< note >}} +파드 템플릿이 `restartPolicy: Never`로 지정되었기 때문에, +kubelet은 특정 파드에서 `main` 컨테이너를 재시작하지 않는다. +{{< /note >}} + +`DisruptionTarget` 컨디션을 갖는 실패한 파드에 대해 +`Ignore` 동작을 하도록 명시하고 있는 파드 실패 정책의 두 번째 규칙으로 인해, +`.spec.backoffLimit` 재시도 한도 계산 시 파드 중단(disruption)은 횟수에서 제외된다. + +{{< note >}} +파드 실패 정책 또는 파드 백오프 실패 정책에 의해 잡이 실패하고, +잡이 여러 파드를 실행중이면, 쿠버네티스는 아직 보류(Pending) 또는 +실행(Running) 중인 해당 잡의 모든 파드를 종료한다. +{{< /note >}} + +다음은 API의 몇 가지 요구 사항 및 의미이다. +- 잡에 `.spec.podFailurePolicy` 필드를 사용하려면, + `.spec.restartPolicy`가 `Never`로 설정된 잡의 파드 템플릿 또한 정의해야 한다. +- `spec.podFailurePolicy.rules`에 기재한 파드 실패 정책 규칙은 기재한 순서대로 평가된다. + 파드 실패 정책 규칙이 파드 실패와 매치되면 나머지 규칙은 무시된다. + 파드 실패와 매치되는 파드 실패 정책 규칙이 없으면 + 기본 처리 방식이 적용된다. +- `spec.podFailurePolicy.rules[*].containerName`에 컨테이너 이름을 지정하여 파드 실패 규칙을 특정 컨테이너에게만 제한할 수 있다. + 컨테이너 이름을 지정하지 않으면 파드 실패 규칙은 모든 컨테이너에 적용된다. + 컨테이너 이름을 지정한 경우, + 이는 파드 템플릿의 컨테이너 또는 `initContainer` 이름 중 하나와 일치해야 한다. +- 파드 실패 정책이 `spec.podFailurePolicy.rules[*].action`과 일치할 때 취할 동작을 지정할 수 있다. + 사용 가능한 값은 다음과 같다. + - `FailJob`: 파드의 잡을 `Failed`로 표시하고 + 실행 중인 모든 파드를 종료해야 함을 나타낸다. + - `Ignore`: `.spec.backoffLimit`에 대한 카운터가 증가하지 않아야 하고 + 대체 파드가 생성되어야 함을 나타낸다. + - `Count`: 파드가 기본 방식으로 처리되어야 함을 나타낸다. + `.spec.backoffLimit`에 대한 카운터가 증가해야 한다. + ### 종료자(finalizers)를 이용한 잡 추적 {{< feature-state for_k8s_version="v1.23" state="beta" >}} @@ -740,7 +823,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다. ### 베어(Bare) 파드 파드가 실행 중인 노드가 재부팅되거나 실패하면 파드가 종료되고 -다시 시작되지 않는다. 그러나 잡은 종료된 항목을 대체하기 위해 새 파드를 생성한다. +재시작되지 않는다. 그러나 잡은 종료된 항목을 대체하기 위해 새 파드를 생성한다. 따라서, 애플리케이션에 단일 파드만 필요한 경우에도 베어 파드 대신 잡을 사용하는 것을 권장한다. @@ -783,3 +866,4 @@ API 서버에서 파드가 제거되면 이를 알아챈다. 오브젝트 정의를 읽은다. * 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한 [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다. +* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해, `podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다. \ No newline at end of file diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index cc571ffab4..b01aca022c 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -94,7 +94,7 @@ spec: terminationGracePeriodSeconds: 10 containers: - name: nginx - image: k8s.gcr.io/nginx-slim:0.8 + image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web @@ -138,13 +138,12 @@ spec: ### 최소 준비 시간 초 {#minimum-ready-seconds} -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} `.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가 -문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어 -있음에 유의한다. 이 기능을 사용하지 않으려면 -StatefulSetMinReadySeconds 플래그를 설정 해제한다. -이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) +문제 없이 실행되고 준비되는 최소 시간(초)을 나타내는 선택적인 필드이다. +[롤링 업데이트](#롤링-업데이트) 전략을 사용할 때 롤아웃 진행 상황을 확인하는 데 사용된다. +이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) 파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 54c91e5f35..2338eccc4c 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -138,6 +138,23 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다. +### 파드 OS + +{{< feature-state state="stable" for_k8s_version="v1.25" >}} + +파드를 실행할 때 OS를 표시하려면 `.spec.os.name` 필드를 `windows` 또는 +`linux`로 설정해야 한다. 이 두 가지 운영체제는 현재 쿠버네티스에서 지원되는 +유일한 운영체제이다. 앞으로 이 목록이 확장될 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서, 이 필드에 대해 설정한 값은 +파드의 {{< glossary_tooltip text="스케줄링" term_id="kube-scheduler" >}}에 영향을 미치지 않는다. +`.spec.os.name`을 설정하면 파드 검증 시 +OS를 식별하는 데 도움이 된다. +kubelet은 +자신이 실행되고 있는 노드의 운영체제와 +동일하지 않은 파드 OS가 명시된 파드의 실행을 거부한다. +[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다. + ### 파드와 컨트롤러 워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index ea0536ae96..c53dd81358 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -227,6 +227,44 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다. - 컨트롤러의 유형 - 클러스터의 리소스 용량 +## 파드 중단 조건 {#pod-disruption-conditions} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +{{< note >}} +클러스터에서 이 동작을 사용하려면 `PodDisruptionConditions` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +{{< /note >}} + +이 기능이 활성화되면, 파드 전용 `DisruptionTarget` [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)이 추가되어 +{{}}으로 인해 파드가 삭제될 예정임을 나타낸다. +추가로 컨디션의 `reason` 필드는 +파드 종료에 대한 다음 원인 중 하나를 나타낸다. + +`PreemptionByKubeScheduler` +: 파드는 더 높은 우선순위를 가진 새 파드를 수용하기 위해 스케줄러에 의해 {{}}된다. 자세한 내용은 [파드 우선순위(priority)와 선점(preemption)](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)을 참조해보자. + +`DeletionByTaintManager` +: 허용하지 않는 `NoExecute` 테인트(taint) 때문에 파드가 테인트 매니저(`kube-controller-manager` 내의 노드 라이프사이클 컨트롤러의 일부)에 의해 삭제될 예정이다. {{}} 기반 축출을 참조해보자. + +`EvictionByEvictionAPI` +: 파드에 {{}}이 표시되었다. + +`DeletionByPodGC` +: 더 이상 존재하지 않는 노드에 바인딩된 파드는 [파드의 가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)에 의해 삭제될 예정이다. + +{{< note >}} +파드 중단은 중단될 수 있다. 컨트롤 플레인은 동일한 파드의 중단을 +계속 다시 시도하지만, 파드의 중단이 보장되지는 않는다. 결과적으로, +`DisruptionTarget` 컨디션이 파드에 추가될 수 있지만, 해당 파드는 사실상 +삭제되지 않았을 수 있다. 이러한 상황에서는, 일정 시간이 지난 뒤에 +파드 중단 상태가 해제된다. +{{< /note >}} + +잡(또는 크론잡(CronJob))을 사용할 때, 이러한 파드 중단 조건을 잡의 +[파드 실패 정책](/ko/docs/concepts/workloads/controllers/job#pod-failure-policy)의 일부로 사용할 수 있다. + ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 보통 클러스터 매니저와 애플리케이션 소유자는 diff --git a/content/ko/docs/concepts/workloads/pods/downward-api.md b/content/ko/docs/concepts/workloads/pods/downward-api.md index 5b1af7bbd1..8d458f52d4 100644 --- a/content/ko/docs/concepts/workloads/pods/downward-api.md +++ b/content/ko/docs/concepts/workloads/pods/downward-api.md @@ -22,7 +22,7 @@ description: > 쿠버네티스에는 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 @@ -127,5 +127,5 @@ CPU와 메모리에 할당 가능한 최댓값을 노출시킨다. 자세한 정보는 [`다운워드API` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)를 참고한다. 다운워드 API를 사용하여 파드 및 컨테이너 정보를 노출시켜보자. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index c90bd72bc8..4d1a0d80c5 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -9,7 +9,7 @@ weight: 80 -{{< feature-state state="beta" for_k8s_version="v1.23" >}} +{{< feature-state state="stable" for_k8s_version="v1.25" >}} 이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index b5a83a7720..1c42f27982 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -154,9 +154,12 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한 파드는 하나의 PodStatus를 가지며, 그것은 파드가 통과했거나 통과하지 못한 -[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. +[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. kubelet은 다음 +PodConditions를 관리한다. * `PodScheduled`: 파드가 노드에 스케줄되었다. +* `PodHasNetwork`: (알파 기능; 반드시 [명시적으로 활성화](#pod-has-network)해야 함) +샌드박스가 성공적으로 생성되고 네트워킹이 구성되었다. * `ContainersReady`: 파드의 모든 컨테이너가 준비되었다. * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가 성공적으로 완료(completed)되었다. @@ -231,6 +234,36 @@ status: 파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 컨디션이 빠졌거나 `False` 이면, kubelet은 파드의 [컨디션](#파드의-컨디션)을 `ContainerReady` 로 설정한다. +### 파드 네트워크 준비성(readiness) {#pod-has-network} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +파드가 노드에 스케줄링되면, kubelet이 이 파드를 승인해야 하고 +모든 볼륨이 마운트되어야 한다. 이러한 단계가 완료되면 kubelet은 +({{< glossary_tooltip term_id="cri" >}}를 사용하여) 컨테이너 런타임과 +통신하여 런타임 샌드박스를 설정하고 파드에 대한 네트워킹을 구성한다. 만약 +`PodHasNetworkCondition` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, +Kubelet은 파드의 `status.conditions` 필드에 있는 `PodHasNetwork` 컨디션을 통해 +파드가 초기화 마일스톤에 도달했는지 여부를 보고한다. + +Kubelet이 파드에 네트워킹이 구성된 런타임 샌드박스가 +없음을 탐지했을 때 `PodHasNetwork` 컨디션은 `False`로 설정된다. 이것은 다음 +시나리오에서 발생한다. +* 파드 라이프사이클 초기에, kubelet이 컨테이너 런타임을 사용하여 파드를 위한 샌드박스 생성을 아직 ​​시작하지 않은 때. +* 파드 라이프사이클 후기에, 파드 샌드박스가 다음중 하나의 이유로 +파괴되었을 때. + * 파드 축출 없이, 노드가 재부팅됨 + * 격리를 위해 가상 머신을 사용하는 컨테이너 런타임을 사용하는 경우, + 파드 샌드박스 가상 머신이 재부팅됨(이후, 새로운 샌드박스 및 새로운 컨테이너 네트워크 구성 생성이 필요함) + +런타임 플러그인이 파드를 위한 샌드박스 생성 및 네트워크 구성을 성공적으로 완료하면 +kubelet이 `PodHasNetwork` 컨디션을 `True`로 설정한다. +`PodHasNetwork` 컨디션이 `True`로 설정되면 kubelet이 컨테이너 이미지를 풀링하고 컨테이너를 생성할 수 있다. + +초기화 컨테이너가 있는 파드의 경우, kubelet은 초기화 컨테이너가 성공적으로 완료(런타임 플러그인에 의한 성공적인 샌드박스 생성 및 네트워크 구성이 완료되었음을 의미)된 후 `Initialized` 컨디션을 `True`로 설정한다. +초기화 컨테이너가 없는 파드의 경우, kubelet은 샌드박스 생성 및 네트워크 구성이 시작되기 전에 `Initialized` 컨디션을 `True`로 설정한다. + + ## 컨테이너 프로브(probe) _프로브_ 는 @@ -466,7 +499,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파 [스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 태스크 문서를 참고한다. -### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection} +### 종료된 파드의 가비지 콜렉션 {#pod-garbage-collection} 실패한 파드의 경우, API 오브젝트는 사람이나 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 프로세스가 diff --git a/content/ko/examples/controllers/job-pod-failure-policy-example.yaml b/content/ko/examples/controllers/job-pod-failure-policy-example.yaml new file mode 100644 index 0000000000..6e846d9ecd --- /dev/null +++ b/content/ko/examples/controllers/job-pod-failure-policy-example.yaml @@ -0,0 +1,28 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-pod-failure-policy-example +spec: + completions: 12 + parallelism: 3 + template: + spec: + restartPolicy: Never + containers: + - name: main + image: docker.io/library/bash:5 + command: ["bash"] # FailJob 액션을 트리거시키는 버그를 만들어내는 예제 명령어 + args: + - -c + - echo "Hello world!" && sleep 5 && exit 42 + backoffLimit: 6 + podFailurePolicy: + rules: + - action: FailJob + onExitCodes: + containerName: main # 선택 사항 + operator: In # [In / NotIn] 중 하나 + values: [42] + - action: Ignore # [Ignore, FailJob, Count] 중 하나 + onPodConditions: + - type: DisruptionTarget # 파드의 중단을 나타냄