Update outdated files in dev-1.20-ko.5 (2)

2021-02-21 07:57:46 +09:00
parent fd8ee1d068
commit 82355b4bac
27 changed files with 89 additions and 60 deletions
@@ -132,7 +132,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
 API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.

-기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
+기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.

  1. `로컬호스트 포트`:

@@ -119,6 +119,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r
 컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다.
 이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다.
 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다.
+더 강력한 격리로 컨테이너 런타임 사용 | 더 강력한 격리를 제공하는 [컨테이너 런타임 클래스](/ko/docs/concepts/containers/runtime-class/)를 선택한다.

 ## 코드

@@ -151,3 +152,4 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
+* [런타임 클래스](/ko/docs/concepts/containers/runtime-class)
@@ -35,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음

   * 쿠버네티스 1.20 이상
     이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
-     쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 
+     쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
     문서 참조
   * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
   * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
@@ -69,9 +69,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,

 클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.

-서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성)
+서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)

-서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 
+서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
 다음 값 중 하나로 설정한다.

 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
@@ -158,7 +158,7 @@ status:
  loadBalancer: {}
 ```

-1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
+1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.

 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}

@@ -23,7 +23,7 @@ weight: 40

 {{% thirdparty-content %}}

-* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
  컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
@@ -31,13 +31,14 @@ weight: 40
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
+* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
  이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
  오픈소스 인그레스 컨트롤러다.
-* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
+* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](https://www.haproxy.org/#desc)의
  인그레스 컨트롤러다.
-* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
+* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](https://www.haproxy.org/#desc) 용
  인그레스 컨트롤러이기도 하다.
 * [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
  기반 인그레스 컨트롤러다.
@@ -48,8 +49,9 @@ weight: 40
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
  [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
+* [Tyk 오퍼레이터](https://github.com/TykTechnologies/tyk-operator)는 사용자 지정 리소스로 인그레스를 확장하여 API 관리 기능을 인그레스로 가져온다. Tyk 오퍼레이터는 오픈 소스 Tyk 게이트웨이 및 Tyk 클라우드 컨트롤 플레인과 함께 작동한다.
 * [Voyager](https://appscode.com/products/voyager)는
-  [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다.
+  [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다.

 ## 여러 인그레스 컨트롤러 사용

@@ -430,8 +430,8 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
 예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
 `my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
-간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다
-(`my-service.my-ns` 역시 동작함).
+`my-service`(`my-service.my-ns` 역시 동작함)에 대한 이름 조회를
+수행하여 서비스를 찾을 수 있어야 한다.

 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
 서비스에 할당된 클러스터 IP로 변환된다.
@@ -463,7 +463,7 @@ DNS SRV 쿼리를 수행할 수 있다.

 셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
 API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여
-`서비스` 를 지원하는 `파드` 를 직접 가리키는 레코드 (주소)를 반환한다.
+`서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.

 ### 셀렉터가 없는 경우

@@ -1164,7 +1164,7 @@ IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정

 이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
 의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
-간단히 연결할 수 있다.
+연결할 수 있다.

 #### iptables

@@ -487,7 +487,7 @@ PV는 `storageClassName` 속성을
 * VsphereVolume
 * iSCSI

-마운트 옵션의 유효성이 검사되지 않으므로 마운트 옵션이 유효하지 않으면 마운트가 실패한다.
+마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.

 이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이
 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
@@ -629,6 +629,11 @@ spec:

 퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다.

+### `hostPath` 유형의 퍼시스턴트볼륨
+
+`hostPath` 퍼시스턴트볼륨은 노드의 파일이나 디렉터리를 사용하여 네트워크 연결 스토리지를 에뮬레이션한다.
+[`hostPath` 유형 볼륨의 예](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)를 참고한다.
+
 ## 원시 블록 볼륨 지원

 {{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -143,8 +143,8 @@ CSI | 1.14 (alpha), 1.16 (beta)
 클래스의 `mountOptions` 필드에 지정된 마운트 옵션을 가진다.

 만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트
-옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV 에서
-검증되지 않으므로 PV 마운트가 유효하지 않으면 마운트가 실패하게 된다.
+옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV에서
+검증되지 않는다. PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다.

 ### 볼륨 바인딩 모드

@@ -19,7 +19,7 @@ weight: 30

 복제는 표준 볼륨처럼 소비할 수 있는 쿠버네티스 볼륨의 복제본으로 정의된다.  유일한 차이점은 프로비저닝할 때 "새" 빈 볼륨을 생성하는 대신에 백엔드 장치가 지정된 볼륨의 정확한 복제본을 생성한다는 것이다.

-쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어있고, 사용가능해야 한다(사용 중이 아니어야함).
+쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어 있고, 사용 가능해야 한다(사용 중이 아니어야 함).

 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.

@@ -64,5 +64,3 @@ spec:
 ## 사용

 새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다.  또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다.  원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다.  이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다.
-
-
@@ -103,6 +103,8 @@ spec:
      fsType: ext4
 ```

+EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition number>"` 를 제공하여 마운트할 파티션을 지정할 수 있다.
+
 #### AWS EBS CSI 마이그레이션

 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
@@ -207,8 +209,8 @@ spec:
 Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI
-드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
-를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
+드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를
+설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
 베타 기능을 활성화해야 한다.

 ### 컨피그맵(configMap) {#configmap}
@@ -89,6 +89,11 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 `concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은
 실행될 것이다.

+{{< caution >}}
+`startingDeadlineSeconds` 가 10초 미만의 값으로 설정되면, 크론잡이 스케줄되지 않을 수 있다. 이는 크론잡 컨트롤러가 10초마다 항목을 확인하기 때문이다.
+{{< /caution >}}
+
+
 모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.

 ````
@@ -141,8 +141,8 @@ nodeAffinity:
 | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
 | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
 | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | 데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다. |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | 데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다. |
 | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
 | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |

@@ -45,7 +45,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
 * `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다.
 * `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다.
 * `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다.
-  이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다.
+  이 사례에서는 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다.
  그러나 파드 템플릿 자체의 규칙이 만족되는 한,
  보다 정교한 선택 규칙의 적용이 가능하다.

@@ -169,13 +169,15 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    ```shell
    kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
    ```
-    또는 간단하게 다음의 명령어를 사용한다.
+
+    또는 다음의 명령어를 사용한다.

    ```shell
    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
    ```

-    이와 유사하게 출력된다.
+    다음과 유사하게 출력된다.
+
    ```
    deployment.apps/nginx-deployment image updated
    ```
@@ -186,7 +188,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    kubectl edit deployment.v1.apps/nginx-deployment
    ```

-    이와 유사하게 출력된다.
+    다음과 유사하게 출력된다.
+
    ```
    deployment.apps/nginx-deployment edited
    ```
@@ -198,10 +201,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    ```

    이와 유사하게 출력된다.
+
    ```
    Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
    ```
+
    또는
+
    ```
    deployment "nginx-deployment" successfully rolled out
    ```
@@ -210,10 +216,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

 * 롤아웃이 성공하면 `kubectl get deployments` 를 실행해서 디플로이먼트를 볼 수 있다.
    이와 유사하게 출력된다.
-    ```
-    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
-    nginx-deployment   3/3     3            3           36s
-    ```
+
+  ```ini
+  NAME               READY   UP-TO-DATE   AVAILABLE   AGE
+  nginx-deployment   3/3     3            3           36s
+  ```

 * `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고,
 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다.
@@ -180,7 +180,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.

-REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다 (레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
+REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
 레플리케이션 컨트롤러를 삭제).

 ### 레플리케이션 컨트롤러만 삭제
@@ -189,7 +189,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 명시적

 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.

-REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 레플리케이션 컨트롤러 오브젝트를 삭제하라.
+REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.

 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
@@ -208,7 +208,8 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히

 ### 스케일링

-레플리케이션 컨트롤러는 `replicas` 필드를 업데이트함으로써 수동으로 또는 오토 스케일링 제어 에이전트로 레플리카의 수를 쉽게 스케일 업하거나 스케일 다운할 수 있다.
+레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
+레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.

 ### 롤링 업데이트

@@ -239,7 +240,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히

 ## 레플리케이션 컨트롤러의 책임

-레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
+레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 셀렉터와 일치하고 동작하는지를 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.

 레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된)가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019))을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170))까지도 고려해야 한다.

@@ -76,7 +76,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지

 임시 컨테이너를 사용해서 문제를 해결하는 예시는
 [임시 디버깅 컨테이너로 디버깅하기]
-(/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다.
+(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.

 ## 임시 컨테이너 API

@@ -100,7 +100,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
-            "name": "example-pod"
+        "name": "example-pod"
    },
    "ephemeralContainers": [{
        "command": [