Merge pull request #24833 from kubernetes/dev-1.19-ko.4

Forth Korean l10n work for release-1.19
2020-11-02 03:28:52 -08:00
parent 2217a60568 6d27247c1e
commit 803cadf059
69 changed files with 3977 additions and 963 deletions
@@ -13,7 +13,7 @@ card:
 _파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.

 _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
-{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다.
+[컨테이너](/ko/docs/concepts/containers/)의 그룹이다.
 이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
 함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
@@ -26,8 +26,8 @@ weight: 40
 * 초기화 컨테이너는 항상 완료를 목표로 실행된다.
 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.

-만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
-반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
+만약 파드의 초기화 컨테이너가 실패하면, kubelet은 초기화 컨테이너가 성공할 때까지 반복적으로 재시작한다.
+그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.

 컨테이너를 초기화 컨테이너로 지정하기 위해서는,
 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
@@ -13,7 +13,8 @@ weight: 30

 파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시
 시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너
-[상태](#컨테이너-상태)와 핸들을 추적한다.
+[상태](#컨테이너-상태)를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를
+결정한다.

 쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
 파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다.
@@ -314,7 +315,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지

 ### 언제 스타트업 프로브를 사용해야 하는가?

-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}

 스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
 파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
@@ -342,7 +343,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 종료를 시도한다.

 일반적으로, 컨테이너 런타임은 각 컨테이너의 기본 프로세스에 TERM 신호를
-전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
+전송한다. 많은 컨테이너 런타임은 컨테이너 이미지에 정의된 `STOPSIGNAL` 값을 존중하며
+TERM 대신 이 값을 보낸다.
+일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
 전송되고, 그런 다음 파드는
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가
 종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는
@@ -192,7 +192,7 @@ graph BT

 {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}}

-이 경우에는, 첫번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.
+이 경우에는, 첫 번째 제약 조건에 부합시키려면, 신규 파드는 오직 "zoneB"에만 배치할 수 있다. 두 번째 제약 조건에서는 신규 파드는 오직 "node4"에만 배치할 수 있다. 그런 다음 두 가지 제약 조건의 결과는 AND 가 되므로, 실행 가능한 유일한 옵션은 "node4"에 배치하는 것이다.

 다중 제약 조건은 충돌로 이어질 수 있다. 3개의 노드를 가지는 클러스터 하나가 2개의 영역에 걸쳐 있다고 가정한다.