From 3c29f6858612e9d6ade12d4629a256d3d8d78083 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 18 Feb 2022 18:27:49 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.23-ko.2 M50-59 --- .../container-runtimes.md | 87 ++++++++++--------- .../tools/kubeadm/control-plane-flags.md | 2 - .../access-cluster.md | 2 +- .../web-ui-dashboard.md | 4 +- .../kubeadm/kubeadm-certs.md | 4 +- .../kubeadm/kubeadm-upgrade.md | 7 +- .../cpu-constraint-namespace.md | 79 +++++++++-------- .../manage-resources/cpu-default-namespace.md | 87 ++++++++++++------- 8 files changed, 155 insertions(+), 117 deletions(-) diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 97be57a3c4..b5ec7c8423 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -15,12 +15,19 @@ weight: 20 +쿠버네티스 {{< skew currentVersion >}}에서는 +{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는 +런타임을 사용해야 한다. + +더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다. + 이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 세부 정보가 있다. - [containerd](#containerd) - [CRI-O](#cri-o) -- [도커](#도커) +- [도커 엔진](#docker) +- [미란티스 컨테이너 런타임](#mcr) {{< note >}} 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. @@ -76,13 +83,17 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명 추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다. ```shell -# dnf install -y grubby && \ +# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다. +# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해 +# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다. +sudo dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ --args="systemd.unified_cgroup_hierarchy=1" ``` -구성을 적용하려면 노드를 재부팅해야 한다. +커널이 사용하는 커맨드 라인을 업데이트하려면, +변경 사항을 적용하기 위해 노드를 재시작해야 한다. cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다. @@ -94,13 +105,24 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면 [변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. +## CRI 버전 지원 {#cri-versions} + +사용할 컨테이너 런타임이 적어도 CRI의 v1alpha2 이상을 지원해야 한다. + +쿠버네티스 {{< skew currentVersion >}} 버전에서는 기본적으로 CRI API 중 v1을 사용한다. +컨테이너 런타임이 v1 API를 지원하지 않으면, +kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된다. + ## 컨테이너 런타임 {{% thirdparty-content %}} + ### containerd -이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. +이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. + +다음 명령을 사용하여 시스템에 containerd를 설치한다. 필수 구성 요소를 설치 및 구성한다. @@ -151,13 +173,12 @@ containerd를 설치한다. {{% tab name="Windows (PowerShell)" %}} PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로 -설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다. +설정(예: `$Version:"1.4.3"`)한 후 다음 명령을 실행한다. 1. containerd 다운로드 ```powershell - curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar. -gz + curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz tar.exe xvf .\containerd-windows-amd64.tar.gz ``` @@ -393,44 +414,28 @@ cgroup_manager = "cgroupfs" CRI-O의 cgroup 드라이버 구성을 동기화 상태로 유지해야 한다. -### 도커 +### 도커 엔진 {#docker} -1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 -리눅스 배포판용 도커를 설치한다. -이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 -검증된 최신 버전의 도커를 찾을 수 있다. +도커 엔진은 모든 것을 시작한 컨테이너 런타임이다. +이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다. +[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서 +이 런타임 설치의 옵션들을 확인할 수 있다. -2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다. +도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다. +더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다. - ```shell - sudo mkdir /etc/docker - cat <}}(CRI)를 통해 +쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는 +써드파티 어댑터를 찾아볼 수도 있다. - {{< note >}} - `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL - 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. - {{< /note >}} +다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다. -3. 도커 재시작과 부팅시 실행되게 설정 +- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) - ```shell - sudo systemctl enable docker - sudo systemctl daemon-reload - sudo systemctl restart docker - ``` +### 미란티스 컨테이너 런타임 {#mcr} -{{< note >}} -더 자세한 내용은 - - [도커 데몬 설정](https://docs.docker.com/config/daemon/) - - [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/) -{{< /note >}} +[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 +이전에는 도커 엔터프라이즈 에디션으로 알려져 있었다. + +오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며, +이 컴포넌트는 MCR에 포함되어 있다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 615b874284..51d8009e83 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -144,7 +144,6 @@ Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 ```yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration -nodeRegistration: patches: directory: /home/user/somedir ``` @@ -159,7 +158,6 @@ nodeRegistration: ```yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: JoinConfiguration -nodeRegistration: patches: directory: /home/user/somedir ``` diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 810259621a..46003991ae 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -214,7 +214,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 -이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다. +이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다. ## redirect 요청하기 diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 888ed2323a..ae1cf08fdd 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -218,8 +218,8 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더 #### 워크로드 선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. -애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고 -각각의 워크로드 종류는 따로 보여진다. +해당 뷰는 애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여준다. +각각의 워크로드 종류는 분리하여 볼 수 있다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index ebcc09b9fc..ca47aa5345 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -282,8 +282,8 @@ CSR 서명자를 가지고 있는지 문의하는 것을 추천한다. {{% thirdparty-content %}} -제 3 자 커스텀 컨트롤러도 사용될 수 있다. -- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp) +써드파티 커스텀 컨트롤러도 사용될 수 있다. +- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver) 이러한 컨트롤러는 CSR의 CommonName과 요청된 IPs 및 도메인 네임을 모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 440f9d5026..941ccefb2d 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -37,8 +37,11 @@ weight: 20 ### 추가 정보 -- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이 - 필요하다. 컨트롤 플레인 노드의 경우 CoreDNS 파드 또는 기타 중요한 워크로드를 실행할 수 있다. +- 아래의 지침은 업그레이드 과정 중 언제 각 노드를 드레인해야 하는지를 제시한다. + kubelet에 대해 **마이너** 버전 업그레이드를 하는 경우, + 먼저 업그레이드할 노드(들)을 드레인**해야 한다**. + 컨트롤 플레인 노드의 경우, CoreDNS 파드 또는 다른 중요한 워크로드를 실행 중일 수 있다. + 더 많은 정보는 [노드 드레인하기](/docs/tasks/administer-cluster/safely-drain-node/)를 참조한다. - 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다. diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 43160db786..c6677c7ddd 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -2,16 +2,20 @@ title: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성 content_type: task weight: 40 +description: >- + 한 네임스페이스 내에서 CPU 리소스 제한의 유효한 범위를 정의하며, + 이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다. --- -이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는 -방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) -오브젝트에 CPU의 최솟값과 최댓값을 -지정한다. 리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, 네임스페이스에서 -생성될 수 없다. +이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서 +컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는 방법을 보여준다. +[리밋레인지(LimitRange)](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) 오브젝트에 +CPU의 최솟값과 최댓값을 지정한다. +리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, +해당 네임스페이스에 생성될 수 없다. @@ -19,11 +23,13 @@ weight: 40 ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -태스크 예제를 실행하려면 클러스터에 적어도 1 CPU 이상이 사용 가능해야 한다. +{{< include "task-tutorial-prereqs.md" >}} +클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다. +태스크 예제를 실행하려면 클러스터에 적어도 1.0 CPU 이상이 사용 가능해야 한다. +쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면 +[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다. @@ -39,7 +45,7 @@ kubectl create namespace constraints-cpu-example ## 리밋레인지와 파드 생성 -다음은 리밋레인지에 대한 구성 파일이다. +다음은 리밋레인지에 대한 예시 매니페스트이다. {{< codenew file="admin/resource/cpu-constraints.yaml" >}} @@ -72,15 +78,15 @@ limits: type: Container ``` -이제 constraints-cpu-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는 -다음 단계를 수행한다. +이제 `constraints-cpu-example` 네임스페이스에 파드를 생성할 때마다(또는 +다른 쿠버네티스 API 클라이언트가 동일한 파드를 생성할 때마다), 쿠버네티스는 다음 단계를 수행한다. -* 컨테이너가 자체 CPU 요청량(request)과 상한(limit)을 지정하지 않으면, 컨테이너에 -CPU 요청량과 상한의 기본값(default)을 지정한다. +* 해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면, + 컨트롤 플레인이 해당 컨테이너에 CPU 요청량과 상한의 기본값(default)을 지정한다. -* 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다. +* 해당 파드의 모든 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다. -* 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다. +* 해당 파드의 모든 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다. {{< note >}} `LimitRange` 오브젝트를 생성할 때, huge-pages @@ -88,8 +94,8 @@ CPU 요청량과 상한의 기본값(default)을 지정한다. 모두 지정되어 있으면, 두 값은 같아야 한다. {{< /note >}} -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는 -500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정한다. 이는 리밋레인지에 +다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너 매니페스트는 +500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 리밋레인지에 의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다. {{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}} @@ -100,7 +106,7 @@ CPU 요청량과 상한의 기본값(default)을 지정한다. kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example ``` -파드의 컨테이너가 실행 중인지 확인한다. +파드가 실행 중이고 컨테이너의 상태가 정상인지 확인한다. ```shell kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example @@ -112,7 +118,7 @@ kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example ``` -출력 결과는 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을 +출력 결과는 파드 내 유일한 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 만족시킨다. ```yaml @@ -131,8 +137,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example ## CPU 최대 제약 조건을 초과하는 파드 생성 시도 -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정한다. +다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는 +500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정하고 있다. {{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}} @@ -142,8 +148,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example ``` -컨테이너가 너무 큰 CPU 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로 -표시된다. +결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다. +해당 컨테이너가 수용 불가능한 이유는 너무 큰 CPU 상한을 지정하고 있기 때문이다. ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml": @@ -152,8 +158,8 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8 ## 최소 CPU 요청량을 충족하지 않는 파드 생성 시도 -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정한다. +다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는 +100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정하고 있다. {{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}} @@ -163,8 +169,9 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8 kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example ``` -컨테이너가 너무 작은 CPU 요청량을 지정하므로, 출력 결과에 파드가 생성되지 -않은 것으로 표시된다. +결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다. +해당 컨테이너가 수용 불가능한 이유는 +지정된 최저 CPU 상한보다도 낮은 CPU 상한을 지정하고 있기 때문이다. ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml": @@ -173,8 +180,8 @@ pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 2 ## CPU 요청량 또는 상한을 지정하지 않은 파드 생성 -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -CPU 요청량을 지정하지 않으며, CPU 상한을 지정하지 않는다. +다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는 +CPU 요청량을 지정하지 않았으며, CPU 상한도 지정하지 않았다. {{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}} @@ -190,8 +197,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.ya kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml ``` -출력 결과는 파드의 컨테이너에 대한 CPU 요청량이 800 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다. -컨테이너는 어떻게 이런 값을 얻었을까? +출력을 보면 파드의 유일한 컨테이너에 대한 CPU 요청량이 800 millicpu이고, +CPU 상한이 800 millicpu이다. +이 컨테이너는 어떻게 이런 값을 얻었을까? ```yaml resources: @@ -201,11 +209,12 @@ resources: cpu: 800m ``` -컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, 리밋레인지로부터 -[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)이 -주어졌다. +컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, +컨테이너가 이 네임스페이스에 대해 리밋레인지로부터 +[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을 +적용했다. -이 시점에서, 컨테이너는 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다. +이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다. 파드를 삭제한다. diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index ab77c226b0..f7c09e159d 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -2,23 +2,36 @@ title: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성 content_type: task weight: 20 +description: >- + 한 네임스페이스에 CPU 리소스 상한의 기본값을 정의하며, + 이를 통해 미리 설정한 CPU 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다. --- -이 페이지는 네임스페이스에 대한 기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다. -쿠버네티스 클러스터는 네임스페이스로 나눌 수 있다. 기본 CPU 상한이 있는 네임스페이스에서 -컨테이너가 생성되고, 컨테이너가 자체 CPU 상한을 지정하지 않으면, -컨테이너에 기본 CPU 상한이 할당된다. 쿠버네티스는 이 문서의 뒷부분에서 -설명하는 특정 조건에서 기본 CPU 요청량을 할당한다. +이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 대한 +기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다. +쿠버네티스 클러스터를 여러 네임스페이스로 나눌 수 있다. +기본 CPU [상한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)이 +설정되어 있는 네임스페이스에 파드를 생성했는데, +해당 파드의 모든 컨테이너에 CPU 상한이 명시되어 있지 않다면, +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 +해당 컨테이너에 기본 CPU 상한을 할당한다. +쿠버네티스는 기본 CPU +[사용량](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 할당하는데, +이는 이 페이지의 이후 부분에서 설명될 특정 조건 하에서만 수행된다. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} +클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다. + +쿠버네티스에서 “1.0 CPU”가 무엇을 의미하는지 익숙하지 않다면, +[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다. @@ -33,8 +46,8 @@ kubectl create namespace default-cpu-example ## 리밋레인지(LimitRange)와 파드 생성 -다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은 -기본 CPU 요청량 및 기본 CPU 상한을 지정한다. +다음은 예시 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}}에 대한 매니페스트이다. +이 매니페스트는 기본 CPU 요청량 및 기본 CPU 상한을 지정한다. {{< codenew file="admin/resource/cpu-defaults.yaml" >}} @@ -44,13 +57,13 @@ default-cpu-example 네임스페이스에 리밋레인지를 생성한다. kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example ``` -이제 컨테이너가 default-cpu-example 네임스페이스에 생성되고, -컨테이너가 CPU 요청량 및 CPU 상한에 대해 고유한 값을 지정하지 않으면, -컨테이너에 CPU 요청량의 기본값 0.5와 CPU 상한 -기본값 1이 부여된다. +이제 파드를 `default-cpu-example` 네임스페이스에 생성하고, +해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면, +컨트롤 플레인이 해당 컨테이너에 CPU 요청량의 기본값(0.5)과 +상한의 기본값(1)을 지정한다. -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -CPU 요청량과 상한을 지정하지 않는다. +다음은 컨테이너가 하나인 파드의 매니페스트이다. +해당 컨테이너는 CPU 요청량과 상한을 지정하지 않는다. {{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}} @@ -66,8 +79,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml -- kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example ``` -출력 결과는 파드의 컨테이너에 500 milicpu의 CPU 요청량과 -1 cpu의 CPU 상한이 있음을 나타낸다. 이것은 리밋레인지에 의해 지정된 기본값이다. +출력을 보면 파드 내 유일한 컨테이너의 CPU 요청량이 500m `cpu`("500 밀리cpu"로 읽을 수 있음)이고, +CPU 상한이 1 `cpu`임을 알 수 있다. +이것은 리밋레인지에 의해 지정된 기본값이다. ```shell containers: @@ -83,8 +97,8 @@ containers: ## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나? -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -CPU 상한을 지정하지만, 요청량은 지정하지 않는다. +다음은 컨테이너가 하나인 파드의 매니페스트이다. +해당 컨테이너는 CPU 상한은 지정하지만, 요청량은 지정하지 않는다. {{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}} @@ -95,14 +109,15 @@ CPU 상한을 지정하지만, 요청량은 지정하지 않는다. kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example ``` -파드 사양을 확인한다. +생성한 파드의 +[명세](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)를 확인한다. ``` kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example ``` 출력 결과는 컨테이너의 CPU 요청량이 CPU 상한과 일치하도록 설정되었음을 보여준다. -참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 cpu가 할당되지 않았다. +참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 `cpu`가 할당되지 않았다. ``` resources: @@ -114,8 +129,8 @@ resources: ## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나? -컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는 -CPU 요청량을 지정하지만, 상한은 지정하지 않았다. +다음은 컨테이너가 하나인 파드의 예시 매니페스트이다. +해당 컨테이너는 CPU 요청량은 지정하지만, 상한은 지정하지 않는다. {{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}} @@ -125,15 +140,16 @@ CPU 요청량을 지정하지만, 상한은 지정하지 않았다. kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example ``` -파드 사양을 확인한다. +생성한 파드의 명세를 확인한다. ``` kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example ``` -출력 결과는 컨테이너의 CPU 요청량이 컨테이너의 구성 파일에 지정된 값으로 -설정되었음을 보여준다. 컨테이너의 CPU 상한은 1 cpu로 설정되며, 이는 -네임스페이스의 CPU 상한 기본값이다. +출력을 보면 파드 생성 시 명시한 값대로 +컨테이너의 CPU 요청량이 설정된 것을 알 수 있다(다시 말해, 매니페스트와 일치한다). +그러나, 해당 컨테이너의 CPU 상한은 1 `cpu`로 설정되며, +이는 네임스페이스의 CPU 상한 기본값이다. ``` resources: @@ -145,15 +161,22 @@ resources: ## CPU 상한 및 요청량의 기본값에 대한 동기 -네임스페이스에 [리소스 쿼터](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)가 있는 경우, +네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가 +설정되어 있는 경우, CPU 상한에 대해 기본값을 설정하는 것이 좋다. -다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다. +다음은 CPU 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다. -* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 CPU 상한이 있어야 한다. -* 네임스페이스의 모든 컨테이너가 사용하는 총 CPU 양은 지정된 상한을 초과하지 않아야 한다. +* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 CPU 상한이 있어야 한다. +* CPU 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다. + 해당 네임스페이스의 모든 파드에 대해 예약된 CPU 총량이 + 지정된 상한을 초과하지 않아야 한다. + +리밋레인지를 추가할 때에는 다음을 고려해야 한다. + +컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 CPU 상한을 지정하지 않았다면, +컨트롤 플레인이 해당 컨테이너에 CPU 상한 기본값을 적용하며, +해당 파드는 CPU 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다. -컨테이너가 자체 CPU 상한을 지정하지 않으면, 상한 기본값이 부여되고, 쿼터에 -의해 제한되는 네임스페이스에서 실행될 수 있다. ## 정리