Merge pull request #31365 from jihoon-seo/220117_Fix_wrong_Korean_translations

[ko] Fix wrong Korean translations

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)을 기준으로 노드 테인트하기
 
 컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
-[노드 조건](/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` 톨러레이션을 추가한다. 

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)
 

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` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
 
 ## 스테이트풀셋 안에 파드