From 593bef6bfec1b0d25d7a1de2537b92e44e6fb718 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 17 Jan 2022 17:53:52 +0900 Subject: [PATCH] [ko] Fix wrong Korean translations --- .../taint-and-toleration.md | 16 +++++----- .../concepts/workloads/pods/pod-lifecycle.md | 30 +++++++++---------- .../basic-stateful-set.md | 4 +-- 3 files changed, 25 insertions(+), 25 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index f6d8c13a19..f6321e4aa7 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -203,7 +203,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -노드 컨트롤러는 특정 조건이 참일 때 자동으로 +노드 컨트롤러는 특정 컨디션이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -264,19 +264,19 @@ tolerations: 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다. -## 조건(condition)을 기준으로 노드 테인트하기 +## 컨디션(condition)을 기준으로 노드 테인트하기 컨트롤 플레인은 노드 {{}}를 이용하여 -[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. +[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. -스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. -이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다. -예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 +스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다. +이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다. +예를 들어 `DiskPressure` 노드 컨디션이 활성화된 경우 컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. -`MemoryPressure` 노드 조건이 활성화되면 +`MemoryPressure` 노드 컨디션이 활성화되면 컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다. -새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. +새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 컨디션을 무시하도록 할 수 있다. 또한 컨트롤 플레인은 `BestEffort` 이외의 {{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 `node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 54af7521d5..4315cfc2cb 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -17,8 +17,8 @@ weight: 30 결정한다. 쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다. -파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다. -사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에 +파드 오브젝트의 상태는 일련의 [파드 컨디션](#파드의-컨디션)으로 구성된다. +사용자의 애플리케이션에 유용한 경우, 파드의 컨디션 데이터에 [사용자 정의 준비성 정보](#pod-readiness-gate)를 삽입할 수도 있다. 파드는 파드의 수명 중 한 번만 [스케줄](/ko/docs/concepts/scheduling-eviction/)된다. @@ -150,10 +150,10 @@ Never이다. 기본값은 Always이다. 컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면, kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한다. -## 파드의 조건 +## 파드의 컨디션 파드는 하나의 PodStatus를 가지며, -그것은 파드가 통과했거나 통과하지 못한 조건에 대한 +그것은 파드가 통과했거나 통과하지 못한 [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. * `PodScheduled`: 파드가 노드에 스케줄되었다. @@ -165,11 +165,11 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한 필드 이름 | 설명 :--------------------|:----------- -`type` | 이 파드 조건의 이름이다. -`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 조건이 적용 가능한지 여부를 나타낸다. -`lastProbeTime` | 파드 조건이 마지막으로 프로브된 시간의 타임스탬프이다. +`type` | 이 파드 컨디션의 이름이다. +`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 컨디션이 적용 가능한지 여부를 나타낸다. +`lastProbeTime` | 파드 컨디션이 마지막으로 프로브된 시간의 타임스탬프이다. `lastTransitionTime` | 파드가 한 상태에서 다른 상태로 전환된 마지막 시간에 대한 타임스탬프이다. -`reason` | 조건의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다. +`reason` | 컨디션의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다. `message` | 마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지이다. @@ -179,11 +179,11 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한 애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ 와 같이 주입할 수 있다. 이를 사용하기 위해, kubelet이 파드의 준비성을 평가하기 -위한 추가적인 조건들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다. +위한 추가적인 컨디션들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다. 준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 -조건을 찾지 못한다면, 그 조건의 상태는 +컨디션을 찾지 못한다면, 그 컨디션의 상태는 기본 값인 "`False`"가 된다. 여기 예제가 있다. @@ -220,16 +220,16 @@ status: {{< glossary_tooltip term_id="operator-pattern" text="오퍼레이터">}}의 `PATCH` 액션을 필요로 한다. [쿠버네티스 클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 -사용해서 파드 준비성에 대한 사용자 지정 파드 조건을 설정하는 코드를 작성할 수 있다. +사용해서 파드 준비성에 대한 사용자 지정 파드 컨디션을 설정하는 코드를 작성할 수 있다. -사용자 지정 조건을 사용하는 파드의 경우, 다음 두 조건이 모두 적용되는 +사용자 지정 컨디션을 사용하는 파드의 경우, 다음 두 컨디션이 모두 적용되는 경우에 **만** 해당 파드가 준비된 것으로 평가된다. * 파드 내의 모든 컨테이너들이 준비 상태이다. -* `readinessGates`에 지정된 모든 조건들이 `True` 이다. +* `readinessGates`에 지정된 모든 컨디션들이 `True` 이다. -파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면, -kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정한다. +파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 컨디션이 빠졌거나 `False` 이면, +kubelet은 파드의 [컨디션](#파드의-컨디션)을 `ContainerReady` 로 설정한다. ## 컨테이너 프로브(probe) diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index db500f5699..c2e16a86f1 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -127,8 +127,8 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) -및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고) +및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드