Merge pull request #30418 from seokho-son/out-1.21-ko.8-m41

[ko] Update outdated in dev-1.21-ko.8 (M41-M45)
2021-11-14 18:46:47 -08:00
parent 7827c02b8e b1bacf38e2
commit 1e35724ca0
5 changed files with 30 additions and 21 deletions
@@ -16,7 +16,7 @@ content_type: task


 * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
-* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예. Kubenet 또는 Calico)
+* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예: Calico, Cilium 또는 Kubenet)
 * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터

 {{< version-check >}}
@@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
 첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.

 ```shell
-kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
+kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
 ```

 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.
@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: Horizontal Pod Autoscaler
 feature:
  title: Horizontal 스케일링
@@ -9,10 +13,6 @@ content_type: concept
 weight: 90
 ---

-
-
-
-
 <!-- overview -->

 Horizontal Pod Autoscaler는 CPU 사용량
@@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
 API 오브젝트에 대한 자세한 내용은
 [HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.

+
 ## kubectl에서 Horizontal Pod Autoscaler 지원

 Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
@@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`

 ## 롤링 업데이트 중 오토스케일링

-현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
-Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
-디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
+쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다. 
+이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다. 
+디플로이먼트에 오토스케일링을 설정하려면, 
+각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다. 
+HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다. 
+디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여 
+롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.

-Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
-즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
-작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
-Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
+오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, 
+스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, 
+레플리카셋과 같은 중간 리소스가 없다).

 ## 쿨-다운 / 지연에 대한 지원

@@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
 1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.

   ```bash
-   sudo mv ./kubectl /usr/local/bin/kubectl-convert
+   sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
   sudo chown root: /usr/local/bin/kubectl-convert
   ```

@@ -346,16 +346,21 @@ Events:
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.

-### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
+### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}

-만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
-PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
+{{< note >}}
+파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. 
+더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
+{{< /note >}}
+
+만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
+파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.

 ```
 --enable-admission-plugins=PodSecurityPolicy[,others...]
 ```

-AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
+AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.

 ```yaml
 apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
@@ -385,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
 ### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}

 클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
-그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
+그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
 그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
 파드의 권한을 docker-default 보다 높일 수 있다.
 이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
@@ -434,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 ### 프로파일 참조 {#profile-reference}

 - `runtime/default`: 기본 런타임 프로파일을 참조한다.
-  - (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
+  - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
    AppArmor를 사용하는 것과 동등하다.
  - 도커에서는 권한 없는 컨테이너의 경우는
    [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
@@ -446,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나

 다른 어떤 프로파일 참조 형식도 유효하지 않다.

-### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
+### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}

 아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기