diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 4703b63b4a..4923afadd0 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,51 +1,48 @@ --- -title: 완료된 리소스를 위한 TTL 컨트롤러 + + +title: 완료된 잡 자동 정리 content_type: concept weight: 70 --- -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} -TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 -제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 -{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만 -처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 -처리하도록 확장될 수 있다. - -이 기능은 현재 베타이고 기본적으로 활성화되어 있다. -kube-apiserver와 kube-controller-manager에서 `TTLAfterFinished` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다. +완료-이후-TTL(TTL-after-finished) {{}}는 +실행이 완료된 리소스 오브젝트의 수명을 제한하는 +TTL (time to live) 메커니즘을 제공한다. +TTL 컨트롤러는 {{< glossary_tooltip text="잡" term_id="job" >}}만을 제어한다. -## TTL 컨트롤러 +## 완료-이후-TTL 컨트롤러 -현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는 +완료-이후-TTL 컨트롤러는 잡만을 지원한다. 클러스터 운영자는 [예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리) 와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다. -리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), -TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다. -TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 이는 -의존하는 오브젝트도 해당 리소스와 함께 삭제되는 것을 의미한다. 리소스가 삭제되면 완료자(finalizers)와 +잡의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), +완료-이후-TTL 컨트롤러는 해당 잡이 정리될 수 있다고 가정한다. +완료-이후-TTL 컨트롤러가 잡을 정리할때 잡을 연속적으로 삭제한다. 이는 +의존하는 오브젝트도 해당 잡과 함께 삭제되는 것을 의미한다. 잡이 삭제되면 완료자(finalizers)와 같은 라이프 사이클 보증이 적용 된다. TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중 `.spec.ttlSecondsAfterFinished` 를 설정하는 몇 가지 예시가 있다. * 작업이 완료된 다음, 일정 시간 후에 자동으로 잡이 정리될 수 있도록 - 리소스 메니페스트에 이 필드를 지정한다. -* 이미 완료된 기존 리소스에 이 새 기능을 적용하기 위해서 이 필드를 + 잡 메니페스트에 이 필드를 지정한다. +* 이미 완료된 기존 잡에 이 새 기능을 적용하기 위해서 이 필드를 설정한다. * [어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 을 사용해서 - 리소스 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을 - 사용해서 완료된 리소스에 대해 TTL 정책을 적용할 수 있다. -* 리소스가 완료된 이후에 + 잡 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을 + 사용해서 완료된 잡에 대해 TTL 정책을 적용할 수 있다. +* 잡이 완료된 이후에 [어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) - 을 사용해서 이 필드를 동적으로 설정하고, 리소스의 상태, + 을 사용해서 이 필드를 동적으로 설정하고, 잡의 상태, 레이블 등에 따라 다른 TTL 값을 선택한다. ## 경고 @@ -53,21 +50,19 @@ TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중 ### TTL 초(sec) 업데이트 TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는 -리소스를 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을 +잡을 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을 삭제할 수 있게 되면(TTL이 만료된 경우) 시스템은 TTL을 연장하기 위한 업데이트가 성공적인 API 응답을 리턴하더라도 작업이 유지되도록 보장하지 않는다. ### 시간 차이(Skew) -TTL 컨트롤러는 쿠버네티스 리소스에 +완료-이후-TTL 컨트롤러는 쿠버네티스 잡에 저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 -시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스 +시간 차이에 민감하며, 시간 차이에 의해서 완료-이후-TTL 컨트롤러가 잘못된 시간에 잡 오브젝트를 정리하게 될 수 있다. -쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드 -([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다) -에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 +시계가 항상 정확한 것은 아니지만, 그 차이는 아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 4a5452a826..ad099f96c7 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -128,8 +128,8 @@ Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적 기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여 소유하는 워크로드 리소스를 발견한다. -PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만, -버짓이 차감된다. +[비자발적 중단](#자발적-중단과-비자발적-중단)은 PDB로는 막을 수 없지만, +버짓은 차감된다. 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. 그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는 diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index cda62ef09b..90d881d0c0 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -1,4 +1,7 @@ --- + + + title: 임시(Ephemeral) 컨테이너 content_type: concept weight: 80 @@ -6,22 +9,13 @@ weight: 80 -{{< feature-state state="alpha" for_k8s_version="v1.22" >}} +{{< feature-state state="beta" for_k8s_version="v1.23" >}} 이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. 임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다. -{{< warning >}} -임시 컨테이너 기능은 알파 상태이며, -프로덕션 클러스터에는 적합하지 않다. -[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 -이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. -{{< /warning >}} - - - ## 임시 컨테이너 이해하기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 54af7521d5..a5ade44e3a 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -159,7 +159,7 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한 * `PodScheduled`: 파드가 노드에 스케줄되었다. * `ContainersReady`: 파드의 모든 컨테이너가 준비되었다. * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가 - 성공적으로 시작되었다. + 성공적으로 완료(completed)되었다. * `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드 밸런싱 풀에 추가되어야 한다. @@ -233,57 +233,87 @@ kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정 ## 컨테이너 프로브(probe) -[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 +_프로브_ 는 컨테이너에서 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, -kubelet은 컨테이너에 의해서 구현된 -[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. -핸들러에는 다음과 같이 세 가지 타입이 있다. +kubelet은 컨테이너 안에서 코드를 실행하거나, +또는 네트워크 요청을 전송한다. -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)은 - 컨테이너 내에서 지정된 명령어를 실행한다. +### 체크 메커니즘 {#probe-check-methods} + +프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다. +각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다. + +`exec` +: 컨테이너 내에서 지정된 명령어를 실행한다. 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)은 - 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. - 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. +`grpc` +: [gRPC](https://grpc.io/)를 사용하여 + 원격 프로시저 호출을 수행한다. + 체크 대상이 [gRPC 헬스 체크](https://grpc.io/grpc/core/md_doc_health-checking.html)를 구현해야 한다. + 응답의 `status` 가 `SERVING` 이면 + 진단이 성공했다고 간주한다. + gRPC 프로브는 알파 기능이며 + `GRPCContainerProbe` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 + 활성화해야 사용할 수 있다. -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)은 - 지정한 포트 및 경로에서 컨테이너의 IP주소에 - 대한 HTTP `GET` 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 +`httpGet` +: 지정한 포트 및 경로에서 컨테이너의 IP주소에 대한 + HTTP `GET` 요청을 수행한다. + 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다. +`tcpSocket` +: 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. + 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. + 원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면, + 이 또한 진단이 성공한 것으로 간주한다. + +### 프로브 결과 + 각 probe는 다음 세 가지 결과 중 하나를 가진다. -* `Success`: 컨테이너가 진단을 통과함. -* `Failure`: 컨테이너가 진단에 실패함. -* `Unknown`: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. +`Success` +: 컨테이너가 진단을 통과함. + +`Failure` +: 컨테이너가 진단에 실패함. + +`Unknown` +: 진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이 + 추가 체크를 수행할 것이다) + +### 프로브 종류 kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있다. -* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 - 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 - [재시작 정책](#restart-policy)의 대상이 된다. 만약 컨테이너가 - 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. +`livenessProbe` +: 컨테이너가 동작 중인지 여부를 나타낸다. 만약 + 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 + [재시작 정책](#restart-policy)의 대상이 된다. 만약 컨테이너가 + 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success` 이다. -* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. - 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 - 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 - 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 - 지원하지 않는다면, 기본 상태는 `Success`이다. +`readinessProbe` +: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. + 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 + 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 + 초기 지연 이전의 기본 상태는 `Failure` 이다. 만약 컨테이너가 준비성 프로브를 + 지원하지 않는다면, 기본 상태는 `Success` 이다. -* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. - 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 - 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, - 컨테이너는 [재시작 정책](#restart-policy)에 따라 처리된다. 컨테이너에 스타트업 - 프로브가 없는 경우, 기본 상태는 `Success`이다. +`startupProbe` +: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는 + 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, + 컨테이너는 [재시작 정책](#restart-policy)에 따라 처리된다. 컨테이너에 스타트업 + 프로브가 없는 경우, 기본 상태는 `Success` 이다. 활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는, [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. -### 언제 활성 프로브를 사용해야 하는가? +#### 언제 활성 프로브를 사용해야 하는가? {{< feature-state for_k8s_version="v1.0" state="stable" >}} @@ -295,7 +325,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. -### 언제 준비성 프로브를 사용해야 하는가? +#### 언제 준비성 프로브를 사용해야 하는가? {{< feature-state for_k8s_version="v1.0" state="stable" >}} @@ -329,7 +359,7 @@ failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있 남아 있다. {{< /note >}} -### 언제 스타트업 프로브를 사용해야 하는가? +#### 언제 스타트업 프로브를 사용해야 하는가? {{< feature-state for_k8s_version="v1.20" state="stable" >}} @@ -458,6 +488,6 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파 * [컨테이너 라이프사이클 훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자. -* API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) -그리고 -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참고한다. +* API의 파드와 컨테이너 상태에 대한 자세한 내용은 + 파드의 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus)에 대해 다루는 + API 레퍼런스 문서를 참고한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 865a7cd7c2..f7593c48dd 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -234,6 +234,8 @@ graph BT 스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다. +### 예시: TopologySpreadConstraints와 노드 어피니티 + zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다. {{}} @@ -349,12 +351,14 @@ defaultConstraints: 비활성화된다. {{< note >}} +`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가 +없는 노드에 점수를 매기지 않는다. +이로 인해 기본 토폴로지 제약을 사용하는 경우의 +레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다. + 노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone` 레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는 대신 자체 제약 조건을 정의한다. - -`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가 -없는 노드에 점수를 매기지 않는다. {{< /note >}} 클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,