Ko: Third Korean l10n work for release-1.20

- Update outdated files in the dev-1.20-ko.3 (1) (#26131) - Update outdated files in the dev-1.20-ko.3 branch (2) (#26122) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com>
2021-01-18 15:46:35 +09:00
parent 8cf053698d
commit 05da4dd669
46 changed files with 354 additions and 213 deletions
@@ -150,9 +150,12 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep
 ```

 kubectl도 캐스케이딩 삭제를 지원한다.
-kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을
-분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은
-true 이다.
+
+kubectl을 사용해서 포어그라운드의 종속 항목을 삭제하려면 `--cascade=foreground` 를 설정한다. 종속 항목을
+분리하기 위해서는 `--cascade=orphan` 를 설정한다.
+
+기본 동작은 백그라운드의 종속 항목을 삭제하는 것이며,
+이는 `--cascade` 를 생략하거나 명시적으로 `background` 를 설정한 경우의 동작에 해당한다.

 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.

@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 레플리카셋
 content_type: concept
 weight: 20
@@ -279,7 +283,7 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron

 ### 레플리카셋만 삭제하기

-레플리카셋을 `--cascade=false` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
+레플리카셋을 `--cascade=orphan` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
 REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다.
 예시:
 ```shell
@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 레플리케이션 컨트롤러
 feature:
  title: 자가 치유
@@ -51,15 +54,17 @@ kubectl 명령에서 숏컷으로 사용된다.
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 replicationcontroller/nginx created
 ```

-다음 명령을 사용하여 레플리케이션 컨트롤러의 상태를 확인하라.
+다음 명령을 사용하여 레플리케이션 컨트롤러의 상태를 확인하자.

 ```shell
 kubectl describe replicationcontrollers/nginx
 ```
+출력 결과는 다음과 같다.
 ```
 Name:        nginx
 Namespace:   default
@@ -98,6 +103,7 @@ Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
 echo $pods
 ```
+출력 결과는 다음과 같다.
 ```
 nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 ```
@@ -15,8 +15,7 @@ card:
 _파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.

 _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
-[컨테이너](/ko/docs/concepts/containers/)의 그룹이다.
-이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
+[컨테이너](/ko/docs/concepts/containers/)의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
 함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
 애플리케이션 컨테이너가 포함된다.
@@ -217,7 +216,8 @@ spec:
  허용한다.

  1. 지정되지 않은 필드를 양수로 설정;
-  1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
+  1. 필드의 양수를 음수가 아닌 더 작은 숫자로
+     갱신.

 ## 리소스 공유와 통신

@@ -294,9 +294,10 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
  오브젝트 정의는 오브젝트를 상세히 설명한다.
 * [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.

-쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음을 포함한 선행 기술에 대해 읽어볼 수 있다.
-  * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
-  * [Borg](https://research.google.com/pubs/pub43438.html)
-  * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
-  * [Omega](https://research.google/pubs/pub41684/)
-  * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
+쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
+
+* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+* [Borg](https://research.google.com/pubs/pub43438.html)
+* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+* [Omega](https://research.google/pubs/pub41684/)
+* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 중단(disruption)
 content_type: concept
 weight: 60
@@ -45,7 +49,7 @@ weight: 60

 - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
 - 클러스터의 스케일 축소를 위한
-  노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기
+  노드 드레이닝([클러스터 오토스케일링](https://github.com/kubernetes/autoscaler/#readme)에 대해 알아보기
  ).
 - 노드에 다른 무언가를 추가하기 위해 파드를 제거.

@@ -133,6 +133,7 @@ spec:
 ```shell
 kubectl apply -f myapp.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 pod/myapp-pod created
 ```
@@ -141,6 +142,7 @@ pod/myapp-pod created
 ```shell
 kubectl get -f myapp.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 NAME        READY     STATUS     RESTARTS   AGE
 myapp-pod   0/1       Init:0/2   0          6m
@@ -150,6 +152,7 @@ myapp-pod   0/1       Init:0/2   0          6m
 ```shell
 kubectl describe -f myapp.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 Name:          myapp-pod
 Namespace:     default
@@ -224,6 +227,7 @@ spec:
 ```shell
 kubectl apply -f services.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 service/myservice created
 service/mydb created
@@ -235,6 +239,7 @@ service/mydb created
 ```shell
 kubectl get -f myapp.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
@@ -257,7 +262,7 @@ myapp-pod   1/1       Running   0          9m

 파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는
 서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
-`Initialized` 가 참이 되는 조건을 가져야 한다.
+`Initialized` 가 거짓이 되는 조건을 가져야 한다.

 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
 반드시 다시 실행된다.
@@ -85,6 +85,13 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 `Failed`    | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
 `Unknown`   | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.

+{{< note >}}
+파드가 삭제될 때, 일부 kubectl 커맨드에서 `Terminating` 이 표시된다.
+이 `Terminating` 상태는 파드의 단계에 해당하지 않는다.
+파드에는 그레이스풀하게(gracefully) 종료되도록 기간이 부여되며, 그 기본값은 30초이다.
+[강제로 파드를 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)하려면 `--force` 플래그를 설정하면 된다.
+{{< /note >}}
+
 노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는
 손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다.

@@ -142,8 +149,7 @@ Never이다. 기본값은 Always이다.
 동일한 노드에서 kubelet에 의한 컨테이너 재시작만을 의미한다. 파드의 컨테이너가
 종료된 후, kubelet은 5분으로 제한되는 지수 백오프 지연(10초, 20초, 40초, …)으로
 컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면,
-kubelet은 해당 컨테이너의 재시작 백오프 타이머를
-재설정한다.
+kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한다.

 ## 파드의 조건

@@ -326,7 +332,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds`
 이후에 기동된다면, 스타트업 프로브가
 활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다.
-`periodSeconds`의 기본값은 30s 이다. 이 때 컨테이너가 활성화 프로브의
+`periodSeconds`의 기본값은 10s 이다. 이 때 컨테이너가 활성화 프로브의
 기본값 변경 없이 기동되도록 하려면, `failureThreshold` 를 충분히 높게 설정해주어야
 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.