Fourth Korean l10n work for release 1.18
- Translate docs/reference/issues-security/_index.md into Korean (#21145) - Translate tasks/administer-cluster/kubeadm/adding-windows-nodes.md into Korean (#21003) - Translate manage-resources/memory-default-namespace.md into Korean (#21089) - Translate tasks/configure-pod-container/pull-image-private-registry in Korean (#21036) - Translate contribute/advanced.md into Korean (#21002) - Update to Outdated files in the dev-1.18-ko.4 branch. (#21102) - Translate manage-resources/cpu-constraint-namespace.md into Korean (#21048) - Translate manage-resources/memory-constraint-namespace.md into Korean (#21091) - Translate setup/release/notes.md in Korean (#21158) - Translate manage-resources/quota-pod-namespace.md into Korean (#21087) - Translate tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md into Korean (#20999) - Translate tasks/administer-cluster/kubeadm/kubeadm-certs.md into Korean (#21000) - Translate manage-resources/quota-memory-cpu-namespace.md into Korean (#21088) - Translate manage-resources/cpu-default-namespace.md into Korean (#21090) - Translate contribute/suggesting-improvements.md into Korean (#21001) - Translate quality-service-pod in Korean (#21081) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: DongMoon Kim <dmoons.kim@gmail.com> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
@@ -0,0 +1,182 @@
|
||||
---
|
||||
title: Windows 노드 추가
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_template: templates/tutorial
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}} {{< version-check >}}
|
||||
|
||||
* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면
|
||||
[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
|
||||
VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다.
|
||||
|
||||
* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* 클러스터에 Windows 노드 등록
|
||||
* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## 시작하기: 클러스터에 Windows 노드 추가
|
||||
|
||||
### 네트워킹 구성
|
||||
|
||||
리눅스 기반 쿠버네티스 컨트롤 플레인 노드가 있으면 네트워킹 솔루션을 선택할 수 있다. 이 가이드는 VXLAN 모드의 플란넬(Flannel)을 사용하는 방법을 짧막하게 보여준다.
|
||||
|
||||
#### 플란넬 구성
|
||||
|
||||
1. 플란넬을 위한 쿠버네티스 컨트롤 플레인 준비
|
||||
|
||||
클러스터의 쿠버네티스 컨트롤 플레인에서 약간의 준비가 필요하다. 플란넬을 사용할 때 iptables 체인에 브릿지된 IPv4 트래픽을 활성화하는 것을 권장한다. 아래 명령을 모든 리눅스 노드에서 실행해야만 한다.
|
||||
|
||||
```bash
|
||||
sudo sysctl net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
|
||||
1. 리눅스용 플란넬 다운로드 및 구성
|
||||
|
||||
가장 최근의 플란넬 매니페스트를 다운로드한다.
|
||||
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
VNI를 4096으로 설정하고 포트를 4789로 설정하려면 플란넬 매니페스트의 `net-conf.json` 섹션을 수정한다. 다음과 같을 것이다.
|
||||
|
||||
```json
|
||||
net-conf.json: |
|
||||
{
|
||||
"Network": "10.244.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan",
|
||||
"VNI" : 4096,
|
||||
"Port": 4789
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
{{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
|
||||
참고한다.{{< /note >}}
|
||||
|
||||
{{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}}
|
||||
|
||||
1. 플란넬 매니페스트 적용 및 유효성 검사
|
||||
|
||||
플란넬 구성을 적용해보자.
|
||||
|
||||
```bash
|
||||
kubectl apply -f kube-flannel.yml
|
||||
```
|
||||
|
||||
몇 분 후에, 플란넬 파드 네트워크가 배포되었다면 모든 파드가 실행 중인 것으로 표시된다.
|
||||
|
||||
```bash
|
||||
kubectl get pods -n kube-system
|
||||
```
|
||||
|
||||
출력 결과에 리눅스 flannel 데몬셋(DaemonSet)이 실행 중인 것으로 나와야 한다.
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
...
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
1. Windows 플란넬 및 kube-proxy 데몬셋 추가
|
||||
|
||||
이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
|
||||
kube-proxy 버전을 얻으려면, 이미지의 태그를
|
||||
대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만,
|
||||
사용자의 배포에 맞게 버전을 조정해야 한다.
|
||||
|
||||
```bash
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
|
||||
```
|
||||
{{< note >}}
|
||||
host-gateway를 사용하는 경우 https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml 을 대신 사용한다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
|
||||
|
||||
```powershell
|
||||
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
|
||||
```
|
||||
|
||||
그리고, 이에 따라 인터페이스를 지정해야 한다.
|
||||
|
||||
```bash
|
||||
# 예시
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
### Windows 워커 노드 조인(joining)
|
||||
{{< note >}}
|
||||
`Containers` 기능을 설치하고 도커를 설치해야 한다.
|
||||
[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
|
||||
높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. wins, kubelet 및 kubeadm 설치
|
||||
|
||||
```PowerShell
|
||||
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
```
|
||||
|
||||
1. 노드에 조인하기 위해 `kubeadm` 실행
|
||||
|
||||
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
|
||||
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
|
||||
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
|
||||
|
||||
|
||||
#### 설치 확인
|
||||
이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다.
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o wide
|
||||
```
|
||||
|
||||
새 노드가 `NotReady` 상태인 경우 플란넬 이미지가 여전히 다운로드 중일 수 있다.
|
||||
`kube-system` 네임스페이스에서 flannel 파드를 확인하여 이전과 같이 진행 상황을 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl -n kube-system get pods -l app=flannel
|
||||
```
|
||||
|
||||
flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드를 처리할 수 있어야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,243 @@
|
||||
---
|
||||
title: kubeadm을 사용한 인증서 관리
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="stable" >}}
|
||||
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
[쿠버네티스의 PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)에 익숙해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 사용자 정의 인증서 사용 {#custom-certificates}
|
||||
|
||||
기본적으로, kubeadm은 클러스터를 실행하는 데 필요한 모든 인증서를 생성한다.
|
||||
사용자는 자체 인증서를 제공하여 이 동작을 무시할 수 있다.
|
||||
|
||||
이렇게 하려면, `--cert-dir` 플래그 또는 kubeadm `ClusterConfiguration` 의
|
||||
`certificatesDir` 필드에 지정된 디렉터리에 배치해야 한다.
|
||||
기본적으로 `/etc/kubernetes/pki` 이다.
|
||||
|
||||
`kubeadm init` 을 실행하기 전에 지정된 인증서와 개인 키(private key) 쌍이 존재하면,
|
||||
kubeadm은 이를 덮어 쓰지 않는다. 이는 예를 들어, 기존 CA를
|
||||
`/etc/kubernetes/pki/ca.crt` 와 `/etc/kubernetes/pki/ca.key` 에
|
||||
복사할 수 있고, kubeadm은 이 CA를 사용하여 나머지 인증서에 서명한다는 걸 의미한다.
|
||||
|
||||
## 외부 CA 모드 {#external-ca-mode}
|
||||
|
||||
`ca.key` 파일이 아닌 `ca.crt` 파일만 제공할
|
||||
수도 있다(이는 다른 인증서 쌍이 아닌 루트 CA 파일에만 사용 가능함).
|
||||
다른 모든 인증서와 kubeconfig 파일이 있으면, kubeadm은 이 조건을
|
||||
인식하고 "외부 CA" 모드를 활성화한다. kubeadm은 디스크에
|
||||
CA 키없이 진행한다.
|
||||
|
||||
대신, `--controllers=csrsigner` 사용하여 controller-manager를
|
||||
독립적으로 실행하고 CA 인증서와 키를 가리킨다.
|
||||
|
||||
[PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)은 외부 CA를
|
||||
사용하도록 클러스터 설정에 대한 지침을 포함한다.
|
||||
|
||||
## 인증서 만료 확인
|
||||
|
||||
`check-expiration` 하위 명령을 사용하여 인증서가 만료되는 시기를 확인할 수 있다.
|
||||
|
||||
```
|
||||
kubeadm alpha certs check-expiration
|
||||
```
|
||||
|
||||
출력 결과는 다음과 비슷하다.
|
||||
|
||||
```
|
||||
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
|
||||
admin.conf Dec 30, 2020 23:36 UTC 364d no
|
||||
apiserver Dec 30, 2020 23:36 UTC 364d ca no
|
||||
apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
|
||||
apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no
|
||||
controller-manager.conf Dec 30, 2020 23:36 UTC 364d no
|
||||
etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no
|
||||
etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no
|
||||
etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no
|
||||
front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no
|
||||
scheduler.conf Dec 30, 2020 23:36 UTC 364d no
|
||||
|
||||
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
|
||||
ca Dec 28, 2029 23:36 UTC 9y no
|
||||
etcd-ca Dec 28, 2029 23:36 UTC 9y no
|
||||
front-proxy-ca Dec 28, 2029 23:36 UTC 9y no
|
||||
```
|
||||
|
||||
이 명령은 `/etc/kubernetes/pki` 폴더의 클라이언트 인증서와 kubeadm이 사용하는 KUBECONFIG 파일(`admin.conf`, `controller-manager.conf` 및 `scheduler.conf`)에 포함된 클라이언트 인증서의 만료/잔여 기간을 표시한다.
|
||||
|
||||
또한, kubeadm은 인증서가 외부에서 관리되는지를 사용자에게 알린다. 이 경우 사용자는 수동으로 또는 다른 도구를 사용해서 인증서 갱신 관리를 해야 한다.
|
||||
|
||||
{{< warning >}}
|
||||
`kubeadm` 은 외부 CA가 서명한 인증서를 관리할 수 없다.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
kubeadm은 자동 인증서 갱신을 위해 kubelet을 구성하기 때문에 `kubelet.conf` 는 위 목록에 포함되어 있지 않다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
kubeadm 1.17 이전의 버전에서 `kubeadm init` 으로 작성된 노드에는
|
||||
`kubelet.conf` 의 내용을 수동으로 수정해야 하는 [버그](https://github.com/kubernetes/kubeadm/issues/1753)가 있다. `kubeadm init` 수행 완료 후, `client-certificate-data` 및 `client-key-data` 를 다음과 같이 교체하여,
|
||||
로테이트된 kubelet 클라이언트 인증서를 가리키도록 `kubelet.conf` 를 업데이트해야 한다.
|
||||
|
||||
```yaml
|
||||
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
|
||||
```
|
||||
{{< /warning >}}
|
||||
|
||||
## 자동 인증서 갱신
|
||||
|
||||
kubeadm은 컨트롤 플레인 [업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) 동안 모든 인증서를 갱신한다.
|
||||
|
||||
이 기능은 가장 간단한 유스케이스를 해결하기 위해 설계되었다.
|
||||
인증서 갱신에 대해 특별한 요구 사항이 없고 쿠버네티스 버전 업그레이드를 정기적으로(매 1년 이내 업그레이드 수행) 수행하는 경우, kubeadm은 클러스터를 최신 상태로 유지하고 합리적으로 보안을 유지한다.
|
||||
|
||||
{{< note >}}
|
||||
보안을 유지하려면 클러스터를 자주 업그레이드하는 것이 가장 좋다.
|
||||
{{< /note >}}
|
||||
|
||||
인증서 갱신에 대해 보다 복잡한 요구 사항이 있는 경우, `--certificate-renewal=false` 를 `kubeadm upgrade apply` 또는 `kubeadm upgrade node` 와 함께 사용하여 기본 동작이 수행되지 않도록 할 수 있다.
|
||||
|
||||
{{< warning >}}
|
||||
kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
|
||||
`--certificate-renewal` 의 기본값이 `false` 인 [버그](https://github.com/kubernetes/kubeadm/issues/1818)가
|
||||
있다. 이 경우 `--certificate-renewal=true` 를 명시적으로 설정해야 한다.
|
||||
{{< /warning >}}
|
||||
|
||||
## 수동 인증서 갱신
|
||||
|
||||
`kubeadm alpha certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
|
||||
|
||||
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
|
||||
|
||||
{{< warning >}}
|
||||
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
`alpha certs renew` 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
|
||||
{{< /note >}}
|
||||
|
||||
`kubeadm alpha certs renew` 는 다음의 옵션을 제공한다.
|
||||
|
||||
쿠버네티스 인증서는 일반적으로 1년 후 만료일에 도달한다.
|
||||
|
||||
- `--csr-only` 는 실제로 인증서를 갱신하지 않고 인증서 서명 요청을 생성하여 외부 CA로 인증서를 갱신하는 데 사용할 수 있다. 자세한 내용은 다음 단락을 참고한다.
|
||||
|
||||
- 모든 인증서 대신 단일 인증서를 갱신할 수도 있다.
|
||||
|
||||
## 쿠버네티스 인증서 API를 사용하여 인증서 갱신
|
||||
|
||||
이 섹션에서는 쿠버네티스 인증서 API를 사용하여 수동 인증서 갱신을 실행하는 방법에 대한 자세한 정보를 제공한다.
|
||||
|
||||
{{< caution >}}
|
||||
조직의 인증서 인프라를 kubeadm으로 생성된 클러스터에 통합해야 하는 사용자를 위한 고급 주제이다. 기본 kubeadm 구성이 요구 사항을 충족하면 kubeadm이 인증서를 대신 관리하도록 해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 서명자 설정
|
||||
|
||||
쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다.
|
||||
[cert-manager][cert-manager-issuer] 와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다.
|
||||
|
||||
빌트인 서명자는 [`kube-controller-manager`][kcm] 의 일부이다.
|
||||
|
||||
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.
|
||||
|
||||
새 클러스터를 생성하는 경우, kubeadm [구성 파일][config]을 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
|
||||
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
|
||||
```
|
||||
|
||||
[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html
|
||||
[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/
|
||||
[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
|
||||
|
||||
### 인증서 서명 요청(CSR) 생성
|
||||
|
||||
`kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
|
||||
|
||||
[cert-manager][cert-manager] 와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
|
||||
그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다.
|
||||
다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.
|
||||
|
||||
```shell
|
||||
sudo kubeadm alpha certs renew apiserver --use-api &
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
```
|
||||
[1] 2890
|
||||
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
|
||||
```
|
||||
|
||||
### 인증서 서명 요청(CSR) 승인
|
||||
|
||||
외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
|
||||
|
||||
그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
```
|
||||
출력 결과는 다음과 비슷하다.
|
||||
```shell
|
||||
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
|
||||
```
|
||||
|
||||
`kubectl get csr` 명령으로 보류 중인 인증서 목록을 볼 수 있다.
|
||||
|
||||
## 외부 CA로 인증서 갱신
|
||||
|
||||
이 섹션에서는 외부 CA를 사용하여 수동 인증서 갱신을 실행하는 방법에 대한 자세한 정보를 제공한다.
|
||||
|
||||
외부 CA와 보다 효과적으로 통합하기 위해 kubeadm은 인증서 서명 요청(CSR)을 생성할 수도 있다.
|
||||
CSR은 클라이언트의 서명된 인증서에 대한 CA 요청을 나타낸다.
|
||||
kubeadm 관점에서, 일반적으로 온-디스크(on-disk) CA에 의해 서명되는 모든 인증서는 CSR로 생성될 수 있다. 그러나 CA는 CSR로 생성될 수 없다.
|
||||
|
||||
### 인증서 서명 요청(CSR) 생성
|
||||
|
||||
`kubeadm alpha certs renew --csr-only` 로 인증서 서명 요청을 만들 수 있다.
|
||||
|
||||
CSR과 함께 제공되는 개인 키가 모두 출력된다.
|
||||
`--csr-dir` 로 사용할 디텍터리를 전달하여 지정된 위치로 CSR을 출력할 수 있다.
|
||||
`--csr-dir` 을 지정하지 않으면, 기본 인증서 디렉터리(`/etc/kubernetes/pki`)가 사용된다.
|
||||
|
||||
`kubeadm alpha certs renew --csr-only` 로 인증서를 갱신할 수 있다.
|
||||
`kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.
|
||||
|
||||
CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
|
||||
인증서를 발행할 때 [올바른 인증서 용도][cert-table]를 지정하는 것은 CA의 책임이다.
|
||||
|
||||
* `openssl` 의 경우 [`openssl ca` command][openssl-ca] 명령으로 수행한다.
|
||||
* `cfssl` 의 경우 [설정 파일에 용도][cfssl-usages]를 지정한다.
|
||||
|
||||
선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다.
|
||||
|
||||
[cert-manager]: https://github.com/jetstack/cert-manager
|
||||
[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension
|
||||
[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170
|
||||
[certs]: /ko/docs/setup/best-practices/certificates/
|
||||
[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca
|
||||
[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: Windows 노드 업그레이드
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 노드를 업그레이드하는 방법을 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에
|
||||
익숙해져야 한다. Windows 노드를
|
||||
업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 워커 노드 업그레이드
|
||||
|
||||
### kubeadm 업그레이드
|
||||
|
||||
1. Windows 노드에서, kubeadm을 업그레이드한다.
|
||||
|
||||
```powershell
|
||||
# replace {{< param "fullversion" >}} with your desired version
|
||||
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
|
||||
```
|
||||
|
||||
### 노드 드레인
|
||||
|
||||
1. 쿠버네티스 API에 접근할 수 있는 머신에서,
|
||||
스케줄 불가능한 것으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
|
||||
|
||||
```shell
|
||||
# <node-to-drain>을 드레이닝하려는 노드 이름으로 바꾼다
|
||||
kubectl drain <node-to-drain> --ignore-daemonsets
|
||||
```
|
||||
|
||||
다음과 비슷한 출력이 표시되어야 한다.
|
||||
|
||||
```
|
||||
node/ip-172-31-85-18 cordoned
|
||||
node/ip-172-31-85-18 drained
|
||||
```
|
||||
|
||||
### kubelet 구성 업그레이드
|
||||
|
||||
1. Windows 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다.
|
||||
|
||||
```powershell
|
||||
kubeadm upgrade node
|
||||
```
|
||||
|
||||
### kubelet 업그레이드
|
||||
|
||||
1. Windows 노드에서, kubelet을 업그레이드하고 다시 시작한다.
|
||||
|
||||
```powershell
|
||||
stop-service kubelet
|
||||
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
|
||||
restart-service kubelet
|
||||
```
|
||||
|
||||
### 노드에 적용된 cordon 해제
|
||||
|
||||
1. 쿠버네티스 API에 접근할 수 있는 머신에서,
|
||||
스케줄 가능으로 표시하여 노드를 다시 온라인으로 가져온다.
|
||||
|
||||
```shell
|
||||
# <node-to-drain>을 노드의 이름으로 바꾼다
|
||||
kubectl uncordon <node-to-drain>
|
||||
```
|
||||
### kube-proxy 업그레이드
|
||||
|
||||
1. 쿠버네티스 API에 접근할 수 있는 머신에서, 다음을 실행하여,
|
||||
{{< param "fullversion" >}}을 원하는 버전으로 다시 바꾼다.
|
||||
|
||||
```shell
|
||||
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
|
||||
```
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 메모리, CPU 와 API 리소스 관리
|
||||
weight: 20
|
||||
---
|
||||
+269
@@ -0,0 +1,269 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는
|
||||
방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
오브젝트에 CPU의 최솟값과 최댓값을
|
||||
지정한다. 리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, 네임스페이스에서
|
||||
생성될 수 없다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
태스크 예제를 실행하려면 클러스터에 적어도 1 CPU 이상이 사용 가능해야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 연습에서 생성한 리소스가 클러스터의 나머지와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace constraints-cpu-example
|
||||
```
|
||||
|
||||
## 리밋레인지와 파드 생성
|
||||
|
||||
다음은 리밋레인지에 대한 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints.yaml" >}}
|
||||
|
||||
리밋레인지를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
리밋레인지에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get limitrange cpu-min-max-demo-lr --output=yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 예상대로 CPU의 최소와 최대 제약 조건을 보여준다. 그러나
|
||||
참고로 리밋레인지에 대한 구성 파일에 기본값을
|
||||
지정하지 않아도 자동으로 생성된다.
|
||||
|
||||
```yaml
|
||||
limits:
|
||||
- default:
|
||||
cpu: 800m
|
||||
defaultRequest:
|
||||
cpu: 800m
|
||||
max:
|
||||
cpu: 800m
|
||||
min:
|
||||
cpu: 200m
|
||||
type: Container
|
||||
```
|
||||
|
||||
이제 constraints-cpu-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
|
||||
다음 단계를 수행한다.
|
||||
|
||||
* 컨테이너가 자체 CPU 요청량(request)과 상한(limit)을 지정하지 않으면, 컨테이너에
|
||||
CPU 요청량과 상한의 기본값(default)을 지정한다.
|
||||
|
||||
* 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다.
|
||||
|
||||
* 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
`LimitRange` 오브젝트를 생성할 때, huge-pages
|
||||
또는 GPU에도 상한을 지정할 수 있다. 그러나, 이 리소스들에 `default` 와 `defaultRequest` 가
|
||||
모두 지정되어 있으면, 두 값은 같아야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
|
||||
500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정한다. 이는 리밋레인지에
|
||||
의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
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
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을
|
||||
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 만족시킨다.
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
cpu: 800m
|
||||
requests:
|
||||
cpu: 500m
|
||||
```
|
||||
|
||||
## 파드 삭제
|
||||
|
||||
```shell
|
||||
kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
## CPU 최대 제약 조건을 초과하는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}}
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 큰 CPU 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
|
||||
표시된다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml":
|
||||
pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 800m, but limit is 1500m.
|
||||
```
|
||||
|
||||
## 최소 CPU 요청량을 충족하지 않는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}}
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 작은 CPU 요청량을 지정하므로, 출력 결과에 파드가 생성되지
|
||||
않은 것으로 표시된다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
|
||||
pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 200m, but request is 100m.
|
||||
```
|
||||
|
||||
## CPU 요청량 또는 상한을 지정하지 않은 파드 생성
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량을 지정하지 않으며, CPU 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 대한 CPU 요청량이 800 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다.
|
||||
컨테이너는 어떻게 이런 값을 얻었을까?
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
cpu: 800m
|
||||
requests:
|
||||
cpu: 800m
|
||||
```
|
||||
|
||||
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, 리밋레인지로부터
|
||||
[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)이
|
||||
주어졌다.
|
||||
|
||||
이 시점에서, 컨테이너는 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
```
|
||||
kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
## CPU의 최소 및 최대 제약 조건의 적용
|
||||
|
||||
리밋레인지에 의해 네임스페이스에 부과된 CPU의 최대 및 최소 제약 조건은
|
||||
파드를 생성하거나 업데이트할 때만 적용된다. 리밋레인지를 변경해도, 이전에 생성된 파드에는
|
||||
영향을 미치지 않는다.
|
||||
|
||||
## CPU의 최소 및 최대 제약 조건에 대한 동기
|
||||
|
||||
클러스터 관리자는 파드가 사용할 수 있는 CPU 리소스에 제한을 둘 수 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
* 클러스터의 각 노드에는 2 CPU가 있다. 클러스터의 어떤 노드도 요청량을 지원할 수 없기 때문에,
|
||||
2 CPU 이상을 요청하는 파드를 수락하지 않으려고 한다.
|
||||
|
||||
* 클러스터는 프로덕션과 개발 부서에서 공유한다.
|
||||
프로덕션 워크로드가 최대 3 CPU를 소비하도록 하고 싶지만, 개발 워크로드는 1 CPU로
|
||||
제한하려고 한다. 프로덕션과 개발을 위해 별도의 네임스페이스를 생성하고, 각 네임스페이스에 CPU 제약 조건을
|
||||
적용한다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace constraints-cpu-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
|
||||
쿠버네티스 클러스터는 네임스페이스로 나눌 수 있다. 기본 CPU 상한이 있는 네임스페이스에서
|
||||
컨테이너가 생성되고, 컨테이너가 자체 CPU 상한을 지정하지 않으면,
|
||||
컨테이너에 기본 CPU 상한이 할당된다. 쿠버네티스는 이 문서의 뒷부분에서
|
||||
설명하는 특정 조건에서 기본 CPU 요청량을 할당한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 연습에서 생성한 리소스가 클러스터의 나머지와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace default-cpu-example
|
||||
```
|
||||
|
||||
## 리밋레인지(LimitRange)와 파드 생성
|
||||
|
||||
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
|
||||
기본 CPU 요청량 및 기본 CPU 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults.yaml" >}}
|
||||
|
||||
default-cpu-example 네임스페이스에 리밋레인지를 생성한다.
|
||||
|
||||
```shell
|
||||
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이 부여된다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
파드의 사양을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 500 milicpu의 CPU 요청량과
|
||||
1 cpu의 CPU 상한이 있음을 나타낸다. 이것은 리밋레인지에 의해 지정된 기본값이다.
|
||||
|
||||
```shell
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: default-cpu-demo-ctr
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: 500m
|
||||
```
|
||||
|
||||
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 상한을 지정하지만, 요청량은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
파드 사양을 확인한다.
|
||||
|
||||
```
|
||||
kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 CPU 요청량이 CPU 상한과 일치하도록 설정되었음을 보여준다.
|
||||
참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 cpu가 할당되지 않았다.
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: "1"
|
||||
```
|
||||
|
||||
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량을 지정하지만, 상한은 지정하지 않았다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
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 상한 기본값이다.
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: 750m
|
||||
```
|
||||
|
||||
## CPU 상한 및 요청량의 기본값에 대한 동기
|
||||
|
||||
네임스페이스에 [리소스 쿼터](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)가 있는 경우,
|
||||
CPU 상한에 대해 기본값을 설정하는 것이 좋다.
|
||||
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
|
||||
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 CPU 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 컨테이너가 사용하는 총 CPU 양은 지정된 상한을 초과하지 않아야 한다.
|
||||
|
||||
컨테이너가 자체 CPU 상한을 지정하지 않으면, 상한 기본값이 부여되고, 쿼터에
|
||||
의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace default-cpu-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
+268
@@ -0,0 +1,268 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에서 실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을
|
||||
설정하는 방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
오브젝트에 최소 및 최대 메모리 값을
|
||||
지정한다. 파드가 리밋레인지에 의해 부과된 제약 조건을 충족하지 않으면,
|
||||
네임스페이스에서 생성될 수 없다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 연습에서 생성한 리소스가 클러스터의 나머지와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace constraints-mem-example
|
||||
```
|
||||
|
||||
## 리밋레인지와 파드 생성
|
||||
|
||||
다음은 리밋레인지의 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
|
||||
|
||||
리밋레인지를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
리밋레인지에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 예상대로 메모리의 최소 및 최대 제약 조건을 보여준다. 그러나
|
||||
참고로 리밋레인지의 구성 파일에 기본값(default)을
|
||||
지정하지 않아도 자동으로 생성된다.
|
||||
|
||||
```
|
||||
limits:
|
||||
- default:
|
||||
memory: 1Gi
|
||||
defaultRequest:
|
||||
memory: 1Gi
|
||||
max:
|
||||
memory: 1Gi
|
||||
min:
|
||||
memory: 500Mi
|
||||
type: Container
|
||||
```
|
||||
|
||||
이제 constraints-mem-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
|
||||
다음 단계를 수행한다.
|
||||
|
||||
* 컨테이너가 자체 메모리 요청량(request)과 상한(limit)을 지정하지 않으면, 기본 메모리 요청량과
|
||||
상한을 컨테이너에 지정한다.
|
||||
|
||||
* 컨테이너에 500MiB 이상의 메모리 요청량이 있는지 확인한다.
|
||||
|
||||
* 컨테이너의 메모리 상한이 1GiB 이하인지 확인한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
|
||||
600MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다. 이들은
|
||||
리밋레인지에 의해 부과된 메모리의 최소 및 최대 제약 조건을 충족한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 600MiB이고 메모리 상한이 800MiB임을
|
||||
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 충족한다.
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
memory: 800Mi
|
||||
requests:
|
||||
memory: 600Mi
|
||||
```
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
## 최대 메모리 제약 조건을 초과하는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
800MiB의 메모리 요청량과 1.5GiB의 메모리 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 큰 메모리 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
|
||||
표시된다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
|
||||
pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container is 1Gi, but limit is 1536Mi.
|
||||
```
|
||||
|
||||
## 최소 메모리 요청량을 충족하지 않는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 작은 메모리 요청량을 지정하므로, 출력 결과에 파드가 생성되지
|
||||
않은 것으로 표시된다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
|
||||
pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
|
||||
```
|
||||
|
||||
## 메모리 요청량 또는 상한을 지정하지 않은 파드 생성
|
||||
|
||||
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지 않으며, 메모리 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 1GiB의 메모리 요청량과 1GiB의 메모리 상한이 있음을 보여준다.
|
||||
컨테이너는 이러한 값을 어떻게 얻었을까?
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
memory: 1Gi
|
||||
requests:
|
||||
memory: 1Gi
|
||||
```
|
||||
|
||||
컨테이너가 자체 메모리 요청량과 상한을 지정하지 않았으므로,
|
||||
리밋레인지의 [메모리의 요청량과 상한 기본값](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)이
|
||||
제공되었다.
|
||||
|
||||
이 시점에서, 컨테이너가 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은
|
||||
노드에 최소 1GiB의 메모리가 있어야 한다는 것이다. 각 노드에
|
||||
1GiB의 메모리만 있는 경우, 노드에 할당할 수 있는 메모리가 1GiB의 메모리 요청량을 수용하기에 충분하지
|
||||
않을 수 있다. 메모리가 2GiB인 노드를 사용하는 경우에는, 메모리가
|
||||
1GiB 요청량을 수용하기에 충분할 것이다.
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
```
|
||||
kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
## 메모리의 최소 및 최대 제약 조건 적용
|
||||
|
||||
리밋레인지에 의해 네임스페이스에 부과된 메모리의 최대 및 최소 제약 조건은
|
||||
파드를 생성하거나 업데이트할 때만 적용된다. 리밋레인지를 변경해도, 이전에 생성된
|
||||
파드에는 영향을 미치지 않는다.
|
||||
|
||||
## 메모리의 최소 및 최대 제약 조건에 대한 동기
|
||||
|
||||
클러스터 관리자는 파드가 사용할 수 있는 메모리 양에 제한을 둘 수 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
* 클러스터의 각 노드에는 2GB의 메모리가 있다. 클러스터의 어떤 노드도 2GB 이상의 요청량을
|
||||
지원할 수 없으므로, 2GB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
|
||||
|
||||
* 클러스터는 운영 부서와 개발 부서에서 공유한다.
|
||||
프로덕션 워크로드가 최대 8GB의 메모리를 소비하도록 하려면,
|
||||
개발 워크로드를 512MB로 제한해야 한다. 프로덕션 및 개발을 위해
|
||||
별도의 네임스페이스를 만들고, 각 네임스페이스에 메모리 제약 조건을 적용한다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace constraints-mem-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
+199
@@ -0,0 +1,199 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 기본 메모리 요청량과 상한 구성
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 메모리 요청량(request)과 상한(limit)을 구성하는 방법을 보여준다.
|
||||
기본 메모리 상한이 있는 네임스페이스에서 컨테이너가 생성되고, 컨테이너가
|
||||
자체 메모리 상한을 지정하지 않으면, 컨테이너에 기본 메모리 상한이 할당된다.
|
||||
쿠버네티스는 이 문서의 뒷부분에서 설명하는 특정 조건에서 기본 메모리 요청량을 할당한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
클러스터의 각 노드에는 최소 2GiB의 메모리가 있어야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 연습에서 생성한 리소스가 클러스터의 다른 리소스와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace default-mem-example
|
||||
```
|
||||
|
||||
## 리밋레인지(LimitRange)와 파드 생성
|
||||
|
||||
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
|
||||
메모리 요청량 기본값(default)과 메모리 상한 기본값을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults.yaml" >}}
|
||||
|
||||
default-mem-example 네임스페이스에 리밋레인지를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
이제 컨테이너가 default-mem-example 네임스페이스에 생성되고,
|
||||
컨테이너가 메모리 요청량 및 메모리 상한에 대해 고유한 값을 지정하지 않으면,
|
||||
컨테이너에 메모리 요청량 기본값 256MiB와 메모리 상한 기본값
|
||||
512MiB가 지정된다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량 및 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 256MiB의 메모리 요청량과
|
||||
512MiB의 메모리 상한이 있음을 나타낸다. 이것은 리밋레인지에 의해 지정된 기본값이다.
|
||||
|
||||
```shell
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: default-mem-demo-ctr
|
||||
resources:
|
||||
limits:
|
||||
memory: 512Mi
|
||||
requests:
|
||||
memory: 256Mi
|
||||
```
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete pod default-mem-demo --namespace=default-mem-example
|
||||
```
|
||||
|
||||
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 상한을 지정하지만, 요청량은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 메모리 상한과 일치하도록 설정되었음을 보여준다.
|
||||
참고로 컨테이너에는 기본 메모리 요청량의 값인 256Mi가 할당되지 않았다.
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
memory: 1Gi
|
||||
requests:
|
||||
memory: 1Gi
|
||||
```
|
||||
|
||||
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지만, 상한은 지정하지 않았다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
파드 사양을 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 컨테이너의 구성 파일에 지정된 값으로
|
||||
설정되었음을 보여준다. 컨테이너의 메모리 상한은 네임스페이스의
|
||||
기본 메모리 상한인 512Mi로 설정되어 있다.
|
||||
|
||||
```
|
||||
resources:
|
||||
limits:
|
||||
memory: 512Mi
|
||||
requests:
|
||||
memory: 128Mi
|
||||
```
|
||||
|
||||
## 기본 메모리 상한 및 요청량에 대한 동기
|
||||
|
||||
네임스페이스에 리소스 쿼터가 있는 경우,
|
||||
메모리 상한에 기본값을 설정하는 것이 좋다.
|
||||
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
|
||||
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 메모리 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 컨테이너가 사용하는 총 메모리 양은 지정된 상한을 초과하지 않아야 한다.
|
||||
|
||||
컨테이너가 자체 메모리 상한을 지정하지 않으면, 기본 상한이 부여되고,
|
||||
쿼터에 의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace default-mem-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 메모리 및 CPU 쿼터 구성
|
||||
content_template: templates/task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에서 실행 중인 모든 컨테이너가 사용할 수 있는
|
||||
총 메모리 및 CPU 양에 대한 쿼터를 설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 연습에서 생성한 리소스가 클러스터의 나머지와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace quota-mem-cpu-example
|
||||
```
|
||||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu.yaml" >}}
|
||||
|
||||
리소스쿼터를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
리소스쿼터에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
리소스쿼터는 이러한 요구 사항을 quota-mem-cpu-example 네임스페이스에 배치한다.
|
||||
|
||||
* 모든 컨테이너에는 메모리 요청량(request), 메모리 상한(limit), CPU 요청량 및 CPU 상한이 있어야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 요청량은 1GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 상한은 2GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 CPU 요청량은 1 cpu를 초과해서는 안된다.
|
||||
* 모든 컨테이너에 대한 총 CPU 상한은 2 cpu를 초과해서는 안된다.
|
||||
|
||||
## 파드 생성
|
||||
|
||||
파드의 구성 파일은 다음과 같다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}}
|
||||
|
||||
|
||||
파드를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
|
||||
```
|
||||
kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
다시 한 번, 리소스쿼터에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 쿼터와 사용된 쿼터를 함께 보여준다.
|
||||
파드의 메모리와 CPU 요청량 및 상한이 쿼터를 초과하지 않은 것을
|
||||
볼 수 있다.
|
||||
|
||||
```
|
||||
status:
|
||||
hard:
|
||||
limits.cpu: "2"
|
||||
limits.memory: 2Gi
|
||||
requests.cpu: "1"
|
||||
requests.memory: 1Gi
|
||||
used:
|
||||
limits.cpu: 800m
|
||||
limits.memory: 800Mi
|
||||
requests.cpu: 400m
|
||||
requests.memory: 600Mi
|
||||
```
|
||||
|
||||
## 두 번째 파드 생성 시도
|
||||
|
||||
다음은 두 번째 파드의 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod-2.yaml" >}}
|
||||
|
||||
구성 파일에서, 파드의 메모리 요청량이 700MiB임을 알 수 있다.
|
||||
사용된 메모리 요청량과 이 새 메모리 요청량의 합계가
|
||||
메모리 요청량 쿼터를 초과한다. 600MiB + 700MiB > 1GiB
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
두 번째 파드는 생성되지 않는다. 출력 결과는 두 번째 파드를 생성하면
|
||||
메모리 요청량의 총 합계가 메모리 요청량 쿼터를 초과함을 보여준다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/quota-mem-cpu-pod-2.yaml":
|
||||
pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
|
||||
requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi
|
||||
```
|
||||
|
||||
## 토론
|
||||
|
||||
이 연습에서 보았듯이, 리소스쿼터를 사용하여
|
||||
네임스페이스에서 실행 중인 모든 컨테이너에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
|
||||
메모리 상한, CPU 요청량 및 CPU 상한의 총 합계를 제한할 수도 있다.
|
||||
|
||||
모든 컨테이너에 대한 합계 대신 개별 컨테이너를 제한하려면,
|
||||
[리밋레인지(LimitRange)](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)를 사용한다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace quota-mem-cpu-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 파드 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: 네임스페이스에 대한 파드 쿼터 구성
|
||||
content_template: templates/task
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지는 네임스페이스에서 실행할 수 있는 총 파드 수에 대한 쿼터를
|
||||
설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
||||
이 실습에서 생성한 리소스가 클러스터의 나머지와
|
||||
격리되도록 네임스페이스를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace quota-pod-example
|
||||
```
|
||||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod.yaml" >}}
|
||||
|
||||
리소스쿼터를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
리소스쿼터에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 네임스페이스에 두 개의 파드 쿼터가 있고, 현재 파드가 없음을
|
||||
보여준다. 즉, 쿼터 중 어느 것도 사용되지 않았다.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
hard:
|
||||
pods: "2"
|
||||
status:
|
||||
hard:
|
||||
pods: "2"
|
||||
used:
|
||||
pods: "0"
|
||||
```
|
||||
|
||||
다음은 디플로이먼트(Deployment) 구성 파일이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}}
|
||||
|
||||
구성 파일에서, `replicas: 3` 은 쿠버네티스가 모두 동일한 애플리케이션을 실행하는 세 개의 파드를 만들도록 지시한다.
|
||||
|
||||
디플로이먼트를 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
디플로이먼트에 대한 자세한 정보를 본다.
|
||||
|
||||
```shell
|
||||
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 디플로이먼트에서 3개의 레플리카를 지정하더라도, 쿼터로
|
||||
인해 2개의 파드만 생성되었음을 보여준다.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
...
|
||||
replicas: 3
|
||||
...
|
||||
status:
|
||||
availableReplicas: 2
|
||||
...
|
||||
lastUpdateTime: 2017-07-07T20:57:05Z
|
||||
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
|
||||
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
|
||||
```
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
||||
```shell
|
||||
kubectl delete namespace quota-pod-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 클러스터 관리자를 위한 문서
|
||||
|
||||
* [네임스페이스에 대한 기본 메모리 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 기본 CPU 요청량과 상한 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [네임스페이스에 대한 메모리 및 CPU 쿼터 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [API 오브젝트에 대한 쿼터 구성](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 앱 개발자를 위한 문서
|
||||
|
||||
* [컨테이너 및 파드 메모리 리소스 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user