Merge pull request #37150 from onestone9900/feat-outdated-file

[ko] Update outdated files dev-1.25-ko.1 (M42 - M52)

Author: k8s-ci-robot

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를 지원하는 다중 아키텍처 이미지를 

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 >}}
 
 스케줄러는 파드를 노드에 할당할 때 

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/)를 활성화하면, 
 크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, 

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` 를 실행한다.
    다음과 유사하게 출력된다.

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`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다.

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)를 참고한다.
 

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/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다.
+
 ### 파드와 컨트롤러
 
 워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는

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/#파드의-컨디션)이 추가되어
+{{<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)의 일부로 사용할 수 있다.
+
 ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리
 
 보통 클러스터 매니저와 애플리케이션 소유자는

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/)

content/ko/docs/concepts/workloads/pods/ephemeral-containers.md

@@ -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" >}}
 
 이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 
 이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해