diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 5a3fdc477e..97753165f1 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -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 >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 61f1dbc758..a3c6285aac 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -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을 확인할 수 있다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index b4cc1b3be5..bc39ab4d91 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -1,4 +1,8 @@ --- + + + + title: Horizontal Pod Autoscaler feature: title: Horizontal 스케일링 @@ -9,10 +13,6 @@ content_type: concept weight: 90 --- - - - - 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가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다. +오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, +스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, +레플리카셋과 같은 중간 리소스가 없다). ## 쿨-다운 / 지연에 대한 지원 diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index 90fefb0c3a..cd03eb91b7 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -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 ``` diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 43b07e293b..a8facdaa67 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -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: @@ -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} 아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기