Merge pull request #37150 from onestone9900/feat-outdated-file
[ko] Update outdated files dev-1.25-ko.1 (M42 - M52)pull/37507/head
Kubernetes Prow Robot
GitHub
commit
5e4da45cdf
|
|
@ -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를 지원하는 다중 아키텍처 이미지를
|
||||
|
|
|
|||
|
|
@ -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 >}}
|
||||
|
||||
스케줄러는 파드를 노드에 할당할 때
|
||||
|
|
|
|||
|
|
@ -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/)를 활성화하면,
|
||||
크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나,
|
||||
|
|
|
|||
|
|
@ -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` 를 실행한다.
|
||||
다음과 유사하게 출력된다.
|
||||
|
|
|
|||
|
|
@ -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`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다.
|
||||
|
|
@ -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)를 참고한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다.
|
||||
|
||||
### 파드와 컨트롤러
|
||||
|
||||
워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
|
||||
|
|
|
|||
|
|
@ -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/#파드의-컨디션)이 추가되어
|
||||
{{<glossary_tooltip term_id="disruption" text="중단(disruption)">}}으로 인해 파드가 삭제될 예정임을 나타낸다.
|
||||
추가로 컨디션의 `reason` 필드는
|
||||
파드 종료에 대한 다음 원인 중 하나를 나타낸다.
|
||||
|
||||
`PreemptionByKubeScheduler`
|
||||
: 파드는 더 높은 우선순위를 가진 새 파드를 수용하기 위해 스케줄러에 의해 {{<glossary_tooltip term_id="preemption" text="선점(preempted)">}}된다. 자세한 내용은 [파드 우선순위(priority)와 선점(preemption)](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)을 참조해보자.
|
||||
|
||||
`DeletionByTaintManager`
|
||||
: 허용하지 않는 `NoExecute` 테인트(taint) 때문에 파드가 테인트 매니저(`kube-controller-manager` 내의 노드 라이프사이클 컨트롤러의 일부)에 의해 삭제될 예정이다. {{<glossary_tooltip term_id="taint" text="taint">}} 기반 축출을 참조해보자.
|
||||
|
||||
`EvictionByEvictionAPI`
|
||||
: 파드에 {{<glossary_tooltip term_id="api-eviction" text="쿠버네티스 API를 이용한 축출">}}이 표시되었다.
|
||||
|
||||
`DeletionByPodGC`
|
||||
: 더 이상 존재하지 않는 노드에 바인딩된 파드는 [파드의 가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)에 의해 삭제될 예정이다.
|
||||
|
||||
{{< note >}}
|
||||
파드 중단은 중단될 수 있다. 컨트롤 플레인은 동일한 파드의 중단을
|
||||
계속 다시 시도하지만, 파드의 중단이 보장되지는 않는다. 결과적으로,
|
||||
`DisruptionTarget` 컨디션이 파드에 추가될 수 있지만, 해당 파드는 사실상
|
||||
삭제되지 않았을 수 있다. 이러한 상황에서는, 일정 시간이 지난 뒤에
|
||||
파드 중단 상태가 해제된다.
|
||||
{{< /note >}}
|
||||
|
||||
잡(또는 크론잡(CronJob))을 사용할 때, 이러한 파드 중단 조건을 잡의
|
||||
[파드 실패 정책](/ko/docs/concepts/workloads/controllers/job#pod-failure-policy)의 일부로 사용할 수 있다.
|
||||
|
||||
## 클러스터 소유자와 애플리케이션 소유자의 역할 분리
|
||||
|
||||
보통 클러스터 매니저와 애플리케이션 소유자는
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 80
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.23" >}}
|
||||
{{< feature-state state="stable" for_k8s_version="v1.25" >}}
|
||||
|
||||
이 페이지는 임시 컨테이너에 대한 개요를 제공한다.
|
||||
이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해
|
||||
|
|
|
|||
|
|
@ -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="컨트롤러" >}} 프로세스가
|
||||
|
|
|
|||
|
|
@ -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 # 파드의 중단을 나타냄
|
||||
Loading…
Reference in New Issue