[ko] Update outdated files in dev-1.23-ko.1 M38-42
Jihoon Seo
parent
0a2da8cb46
commit
f91f632287
|
|
@ -1,51 +1,48 @@
|
|||
---
|
||||
title: 완료된 리소스를 위한 TTL 컨트롤러
|
||||
|
||||
|
||||
title: 완료된 잡 자동 정리
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< 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) {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는
|
||||
실행이 완료된 리소스 오브젝트의 수명을 제한하는
|
||||
TTL (time to live) 메커니즘을 제공한다.
|
||||
TTL 컨트롤러는 {{< glossary_tooltip text="잡" term_id="job" >}}만을 제어한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 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을 설정할때는 이 위험에 대해 유의해야 한다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -128,8 +128,8 @@ Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적
|
|||
기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여
|
||||
소유하는 워크로드 리소스를 발견한다.
|
||||
|
||||
PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
|
||||
버짓이 차감된다.
|
||||
[비자발적 중단](#자발적-중단과-비자발적-중단)은 PDB로는 막을 수 없지만,
|
||||
버짓은 차감된다.
|
||||
|
||||
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
|
||||
그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
title: 임시(Ephemeral) 컨테이너
|
||||
content_type: concept
|
||||
weight: 80
|
||||
|
|
@ -6,22 +9,13 @@ weight: 80
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< 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 >}}
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 임시 컨테이너 이해하기
|
||||
|
|
|
|||
|
|
@ -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 레퍼런스 문서를 참고한다.
|
||||
|
|
|
|||
|
|
@ -234,6 +234,8 @@ graph BT
|
|||
|
||||
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
|
||||
|
||||
### 예시: TopologySpreadConstraints와 노드 어피니티
|
||||
|
||||
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
|
||||
|
||||
{{<mermaid>}}
|
||||
|
|
@ -349,12 +351,14 @@ defaultConstraints:
|
|||
비활성화된다.
|
||||
|
||||
{{< note >}}
|
||||
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
|
||||
없는 노드에 점수를 매기지 않는다.
|
||||
이로 인해 기본 토폴로지 제약을 사용하는 경우의
|
||||
레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
|
||||
|
||||
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
|
||||
레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
|
||||
대신 자체 제약 조건을 정의한다.
|
||||
|
||||
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
|
||||
없는 노드에 점수를 매기지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
|
||||
|
|
|
|||
Loading…
Reference in New Issue