Merge pull request #31793 from jihoon-seo/220218_Outdated_M50-M58
[ko] Update outdated files in `dev-1.23-ko.2` (M50-M59)pull/32789/head
Kubernetes Prow Robot
GitHub
commit
a6c1cf30c4
|
|
@ -15,12 +15,19 @@ weight: 20
|
|||
|
||||
<!-- body -->
|
||||
|
||||
쿠버네티스 {{< 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 <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
EOF
|
||||
```
|
||||
지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(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에 포함되어 있다.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
|
|||
|
||||
## 클러스터에서 실행되는 서비스로 접근
|
||||
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
|
||||
|
||||
## redirect 요청하기
|
||||
|
||||
|
|
|
|||
|
|
@ -218,8 +218,8 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
|||
#### 워크로드
|
||||
|
||||
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
|
||||
애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고
|
||||
각각의 워크로드 종류는 따로 보여진다.
|
||||
해당 뷰는 애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여준다.
|
||||
각각의 워크로드 종류는 분리하여 볼 수 있다.
|
||||
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
|
||||
워크로드에 대한 실용적인 정보를 요약한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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 및 도메인 네임을
|
||||
모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가
|
||||
|
|
|
|||
|
|
@ -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/)를 참조한다.
|
||||
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
|
||||
|
||||
<!-- steps -->
|
||||
|
|
|
|||
|
|
@ -2,16 +2,20 @@
|
|||
title: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성
|
||||
content_type: task
|
||||
weight: 40
|
||||
description: >-
|
||||
한 네임스페이스 내에서 CPU 리소스 제한의 유효한 범위를 정의하며,
|
||||
이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 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의-의미)를 참조한다.
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
|
@ -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 요청량을 수용하기에 충분할 것이다.
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,23 +2,36 @@
|
|||
title: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성
|
||||
content_type: task
|
||||
weight: 20
|
||||
description: >-
|
||||
한 네임스페이스에 CPU 리소스 상한의 기본값을 정의하며,
|
||||
이를 통해 미리 설정한 CPU 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 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의-의미)를 참조한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -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 상한을 지정하지 않으면, 상한 기본값이 부여되고, 쿼터에
|
||||
의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue