whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ko: 1st Korean l10n work for release-1.20

Browse Source 
- Translate reference/glossary/persistent-volume.md in Korean (#25474)
- Update outdated files in the dev-1.20-ko.1 branch (1) (#25576)
- Translate blog/dont-panic-kubernetes-and-docker into Korean (#25596)
- Update outdated files in the dev-1.20-ko.1 branch(3) (#25728)
- Ko: enhance tutorials//cluster-intro translation (#25754)
- Fix Outdated files in the dev-1.20-ko.1 branch (2) (#25765)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>
Co-authored-by: SEUNGHYUN KO <kosehy@gmail.com>
Co-authored-by: June Yi <gochist@gmail.com>
This commit is contained in:
Jerry Park
2020-12-14 00:16:04 +00:00
committed by seokho-son
parent 8fd80c3e35
commit 0ed380d4aa
60 changed files with 1290 additions and 731 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/administer-cluster/highly-available-master.md
+33 -2
View File
@@ -169,8 +169,39 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있
etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
### API 서버 신원
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
API 서버 식별 기능은
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
의해 제어되며 기본적으로 활성화되지 않는다.
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다.
```shell
kube-apiserver \
--feature-gates=APIServerIdentity=true \
# …다른 플래그는 평소와 같다.
```
부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는
`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는
_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에
[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다.
임대 이름은 kube-apiserver의 고유 ID이다. 임대에는
`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는
`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각
kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다
모든 kube-apiserver 식별 ID 임대를 확인하고,
`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다.
`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는
kube-apiserver 플래그 `identity-lease-renew-interval-seconds`
및 `identity-lease-duration-seconds`로 구성된다.
이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을
사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트).
## 추가 자료
[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+67 -10
View File
@@ -135,31 +135,91 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### 윈도우 워커 노드 조인(joining)
{{< note >}}
`Containers` 기능을 설치하고 도커를 설치해야 한다.
[윈도우 서버에 Docker Engine - Enterprise 설치](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 설치에 대한 내용을 참고할 수 있다.
{{< /note >}}
{{< note >}}
윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
{{< /note >}}
1. wins, kubelet 및 kubeadm 설치
{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
{{% tab name="Docker EE" %}}
#### Docker EE 설치
`컨테이너` 기능 설치
```powershell
Install-WindowsFeature -Name containers
```
도커 설치
자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 확인할 수 있다.
#### 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` 실행하여 노드에 조인
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
{{% /tab %}}
{{% tab name="CRI-containerD" %}}
#### containerD 설치
```powershell
curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
.\Install-Containerd.ps1
```
{{< note >}}
특정 버전의 containerD를 설치하려면 -ContainerDVersion를 사용하여 버전을 지정한다.
```powershell
# 예
.\Install-Containerd.ps1 -ContainerDVersion v1.4.1
```
{{< /note >}}
{{< note >}}
윈도우 노드에서 이더넷(예: "Ethernet0 2")이 아닌 다른 인터페이스를 사용하는 경우, `-netAdapterName` 으로 이름을 지정한다.
```powershell
# 예
.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2"
```
{{< /note >}}
#### 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" >}} -ContainerRuntime containerD
```
#### `kubeadm` 실행하여 노드에 조인
컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
{{< note >}}
**CRI-containerD** 를 사용하는 경우 kubeadm 호출에 `--cri-socket "npipe:////./pipe/containerd-containerd"` 를 추가한다
{{< /note >}}
{{% /tab %}}
{{< /tabs >}}
### 설치 확인
#### 설치 확인
이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.
```bash
@@ -175,9 +235,6 @@ kubectl -n kube-system get pods -l app=flannel
flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드를 처리할 수 있어야 한다.
## {{% heading "whatsnext" %}}
- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+8 -8
View File
@@ -50,7 +50,7 @@ CA 키없이 진행한다.
`check-expiration` 하위 명령을 사용하여 인증서가 만료되는 시기를 확인할 수 있다.
```
kubeadm alpha certs check-expiration
kubeadm certs check-expiration
```
출력 결과는 다음과 비슷하다.
@@ -118,7 +118,7 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
## 수동 인증서 갱신
`kubeadm alpha certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
@@ -127,10 +127,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
{{< /warning >}}
{{< note >}}
`alpha certs renew` 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
`certs renew` 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
{{< /note >}}
`kubeadm alpha certs renew` 는 다음의 옵션을 제공한다.
`kubeadm certs renew` 는 다음의 옵션을 제공한다.
쿠버네티스 인증서는 일반적으로 1년 후 만료일에 도달한다.
@@ -168,14 +168,14 @@ controllerManager:
### 인증서 서명 요청(CSR) 생성
`kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
`kubeadm certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.
```shell
sudo kubeadm alpha certs renew apiserver --use-api &
sudo kubeadm certs renew apiserver --use-api &
```
출력 결과는 다음과 비슷하다.
```
@@ -209,13 +209,13 @@ kubeadm 관점에서, 일반적으로 온-디스크(on-disk) CA에 의해 서명
### 인증서 서명 요청(CSR) 생성
`kubeadm alpha certs renew --csr-only` 로 인증서 서명 요청을 만들 수 있다.
`kubeadm certs renew --csr-only` 로 인증서 서명 요청을 만들 수 있다.
CSR과 함께 제공되는 개인 키가 모두 출력된다.
`--csr-dir` 로 사용할 디텍터리를 전달하여 지정된 위치로 CSR을 출력할 수 있다.
`--csr-dir` 을 지정하지 않으면, 기본 인증서 디렉터리(`/etc/kubernetes/pki`)가 사용된다.
`kubeadm alpha certs renew --csr-only` 로 인증서를 갱신할 수 있다.
`kubeadm certs renew --csr-only` 로 인증서를 갱신할 수 있다.
`kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.
CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+83 -205
View File
@@ -2,22 +2,22 @@
title: kubeadm 클러스터 업그레이드
content_type: task
weight: 20
min-kubernetes-server-version: 1.19
---
<!-- overview -->
이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
1.18.x 버전에서 1.19.x 버전으로, 1.19.x 버전에서 1.19.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로,
{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는 경우
마이너 버전을 건너뛴다.
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
이 페이지 대신 다음의 페이지들을 참고한다.
- [kubeadm 클러스터를 1.17에서 1.18로 업그레이드](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
- [kubeadm 클러스터를 1.13에서 1.14로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
추상적인 업그레이드 작업 절차는 다음과 같다.
@@ -27,60 +27,63 @@ min-kubernetes-server-version: 1.19
## {{% heading "prerequisites" %}}
- 1.18.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다.
- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
- 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다.
`kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다.
- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
### 추가 정보
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이
필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
- 하나의 MINOR 버전에서 다음 MINOR 버전으로,
또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다.
예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다.
<!-- steps -->
## 업그레이드할 버전 결정
최신의 안정 버전인 1.19를 찾는다.
OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다.
{{< tabs name="k8s_install_versions" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
apt update
apt-cache madison kubeadm
# 목록에서 최신 버전 1.19를 찾는다
# 1.19.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
# {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
yum list --showduplicates kubeadm --disableexcludes=kubernetes
# 목록에서 최신 버전 1.19를 찾는다
# 1.19.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
# 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
# {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
{{% /tab %}}
{{< /tabs >}}
## 컨트롤 플레인 노드 업그레이드
### 첫 번째 컨트롤 플레인 노드 업그레이드
컨트롤 플레인 노드의 업그레이드 절차는 한 번에 한 노드씩 실행해야 한다.
먼저 업그레이드할 컨트롤 플레인 노드를 선택한다. `/etc/kubernetes/admin.conf` 파일이 있어야 한다.
- 첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다.
### "kubeadm upgrade" 호출
**첫 번째 컨트롤 플레인 노드의 경우**
- kubeadm 업그레이드
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.19.x-00에서 x를 최신 패치 버전으로 바꾼다.
# {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -90,63 +93,10 @@ min-kubernetes-server-version: 1.19
kubeadm version
```
- 컨트롤 플레인 노드를 드레인(drain)한다.
- 업그레이드 계획을 확인한다.
```shell
# <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
kubectl drain <cp-node-name> --ignore-daemonsets
```
- 컨트롤 플레인 노드에서 다음을 실행한다.
```shell
sudo kubeadm upgrade plan
```
다음과 비슷한 출력이 표시되어야 한다.
```
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.18.4
[upgrade/versions] kubeadm version: v1.19.0
[upgrade/versions] Latest stable version: v1.19.0
[upgrade/versions] Latest version in the v1.18 series: v1.19.0
Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT CURRENT AVAILABLE
Kubelet 1 x v1.18.4 v1.19.0
Upgrade to the latest version in the v1.18 series:
COMPONENT CURRENT AVAILABLE
API Server v1.18.4 v1.19.0
Controller Manager v1.18.4 v1.19.0
Scheduler v1.18.4 v1.19.0
Kube Proxy v1.18.4 v1.19.0
CoreDNS 1.6.7 1.7.0
Etcd 3.4.3-0 3.4.7-0
You can now apply the upgrade by executing the following command:
kubeadm upgrade apply v1.19.0
_____________________________________________________________________
아래 표는 이 버전의 kubeadm에서 이해하는 컴포넌트 구성의 현재 상태를 보여준다.
"MANUAL UPGRADE REQUIRED" 열에 "yes" 표시가 있는 구성은 성공적인 업그레이드를
수행하기 전에 수동 구성 업그레이드 또는 kubeadm 기본값으로 재설정이 필요하다. 수동으로
업그레이드할 버전은 "PREFERRED VERSION" 열에 표시된다.
API GROUP CURRENT VERSION PREFERRED VERSION MANUAL UPGRADE REQUIRED
kubeproxy.config.k8s.io v1alpha1 v1alpha1 no
kubelet.config.k8s.io v1beta1 v1beta1 no
_____________________________________________________________________
kubeadm upgrade plan
```
이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
@@ -168,90 +118,13 @@ min-kubernetes-server-version: 1.19
```shell
# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v1.19.x
sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
```
다음과 비슷한 출력이 표시되어야 한다.
명령이 완료되면 다음을 확인해야 한다.
```
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks.
[upgrade] Running cluster health checks
[upgrade/version] You have chosen to change the cluster version to "v1.19.0"
[upgrade/versions] Cluster version: v1.18.4
[upgrade/versions] kubeadm version: v1.19.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
[upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
[upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
[upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"...
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
[upgrade/staticpods] Preparing for "etcd" upgrade
[upgrade/staticpods] Renewing etcd-server certificate
[upgrade/staticpods] Renewing etcd-peer certificate
[upgrade/staticpods] Renewing etcd-healthcheck-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980"
[upgrade/staticpods] Preparing for "kube-apiserver" upgrade
[upgrade/staticpods] Renewing apiserver certificate
[upgrade/staticpods] Renewing apiserver-kubelet-client certificate
[upgrade/staticpods] Renewing front-proxy-client certificate
[upgrade/staticpods] Renewing apiserver-etcd-client certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
[upgrade/staticpods] Renewing controller-manager.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Preparing for "kube-scheduler" upgrade
[upgrade/staticpods] Renewing scheduler.conf certificate
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31
[apiclient] Found 1 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
W0713 16:26:14.074656 2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained.
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy!
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
```
@@ -264,14 +137,7 @@ min-kubernetes-server-version: 1.19
CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.
- 컨트롤 플레인 노드에 적용된 cordon을 해제한다.
```shell
# <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
kubectl uncordon <cp-node-name>
```
### 추가 컨트롤 플레인 노드 업그레이드
**다른 컨트롤 플레인 노드의 경우**
첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다.
@@ -285,36 +151,58 @@ sudo kubeadm upgrade node
sudo kubeadm upgrade apply
```
또한 `sudo kubeadm upgrade plan` 은 필요하지 않다.
`kubeadm upgrade plan` 을 호출하고 CNI 공급자 플러그인을 업그레이드할 필요가 없다.
### 노드 드레인
- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
```shell
# <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
kubectl drain <node-to-drain> --ignore-daemonsets
```
### kubelet과 kubectl 업그레이드
모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
- 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
<pre>>
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
{{% /tab %}}
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
</pre>
{{< /tab >}}
{{< tab name="CentOS, RHEL 또는 Fedora" >}}
<pre>
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
</pre>
{{< /tab >}}
{{< /tabs >}}
kubelet을 다시 시작한다.
- kubelet을 다시 시작한다.
```shell
sudo systemctl daemon-reload
sudo systemctl restart kubelet
```
### 노드 uncordon
- 노드를 스케줄 가능으로 표시하여 노드를 다시 온라인 상태로 전환한다.
```shell
# <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
kubectl uncordon <node-to-drain>
```
## 워커 노드 업그레이드
워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서,
@@ -326,18 +214,18 @@ sudo systemctl restart kubelet
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -350,17 +238,9 @@ sudo systemctl restart kubelet
kubectl drain <node-to-drain> --ignore-daemonsets
```
다음과 비슷한 출력이 표시되어야 한다.
### kubeadm 업그레이드 호출
```
node/ip-172-31-85-18 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
node/ip-172-31-85-18 drained
```
### kubelet 구성 업그레이드
1. 다음의 명령을 호출한다.
- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
```shell
sudo kubeadm upgrade node
@@ -368,22 +248,22 @@ sudo systemctl restart kubelet
### kubelet과 kubectl 업그레이드
- 모든 워커 노드에서 kubelet 및 kubectl을 업그레이드한다.
- kubelet 및 kubectl을 업그레이드한다.
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
# 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
# {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
# {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
@@ -405,7 +285,8 @@ sudo systemctl restart kubelet
## 클러스터 상태 확인
모든 노드에서 kubelet을 업그레이드 한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다.
모든 노드에서 kubelet을 업그레이드한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여
모든 노드를 다시 사용할 수 있는지 확인한다.
```shell
kubectl get nodes
@@ -413,8 +294,6 @@ kubectl get nodes
모든 노드에 대해 `STATUS` 열에 `Ready` 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다.
## 장애 상태에서의 복구
예를 들어 `kubeadm upgrade` 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, `kubeadm upgrade` 를 다시 실행할 수 있다.
@@ -423,7 +302,6 @@ kubectl get nodes
잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다.
업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다.
- `kubeadm-backup-etcd-<date>-<time>`
- `kubeadm-backup-manifests-<date>-<time>`
content/ko/docs/tasks/network/validate-dual-stack.md
+94 -23
View File
@@ -1,5 +1,5 @@
---
min-kubernetes-server-version: v1.16
min-kubernetes-server-version: v1.20
title: IPv4/IPv6 이중 스택 검증
content_type: task
---
@@ -94,31 +94,31 @@ a00:100::4 pod01
## 서비스 검증
`ipFamily` 필드 세트 없이 다음 서비스를 생성한다. 필드가 구성되지 않았으면 서비스는 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 범위 내 첫 IP를 할당받는다.
`.spec.ipFamilyPolicy` 를 명시적으로 정의하지 않은 다음의 서비스를 생성한다. 쿠버네티스는 처음 구성된 `service-cluster-ip-range` 에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정한다.
{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
해당 서비스의 YAML을 보면, 서비스의 `ipFamily` 필드가 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 첫 번째 설정된 범위의 주소 패밀리를 반영하도록 설정되어 있음을 확인할 수 있다.
`kubectl` 을 사용하여 서비스의 YAML을 확인한다.
```shell
kubectl get svc my-service -o yaml
```
이 서비스에서 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정하고 `.spec.clusterIP` 를 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 첫 번째 구성 범위에서 IPv4 주소로 설정한다.
```yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2019-09-03T20:45:13Z"
labels:
app: MyApp
name: my-service
namespace: default
resourceVersion: "485836"
selfLink: /api/v1/namespaces/default/services/my-service
uid: b6fa83ef-fe7e-47a3-96a1-ac212fa5b030
spec:
clusterIP: 10.0.29.179
ipFamily: IPv4
clusterIP: 10.0.217.164
clusterIPs:
- 10.0.217.164
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
@@ -131,26 +131,97 @@ status:
loadBalancer: {}
```
`ipFamily` 필드를 `IPv6`로 설정하여 다음의 서비스를 생성한다.
`.spec.ipFamilies` 의 첫 번째 배열 요소로 `IPv6` 을 명시적으로 정의하는 다음 서비스를 생성한다. Kubernetes는 `service-cluster-ip-range`로 구성된 IPv6 범위에서 서비스용 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정한다.
{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
{{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}}
서비스가 IPv6 주소 블록에서 클러스터 IP 주소를 할당받는 것을 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
`kubectl` 를 사용하여 서비스의 YAML을 확인한다.
```shell
kubectl get svc my-service -o yaml
```
이 서비스에서 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정하고 `.spec.clusterIP` 를 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 IPv6 범위에서 IPv6 주소로 설정한다.
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: MyApp
name: my-service
spec:
clusterIP: fd00::5118
clusterIPs:
- fd00::5118
ipFamilies:
- IPv6
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: MyApp
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
```
`PreferDualStack` 에 `.spec.ipFamilyPolicy` 을 명시적으로 정의하는 다음 서비스를 생성한다. 쿠버네티스는 IPv4 및 IPv6 주소를 모두 할당하고 (이 클러스터에는 이중 스택을 사용하도록 설정되었으므로) `.spec.ipFamilies` 배열에 있는 첫 번째 요소의 주소 계열을 기반으로`.spec.ClusterIP` 목록에서 `.spec.ClusterIPs` 를 선택한다.
{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
{{< note >}}
`kubectl get svc` 명령어는 오직 `CLUSTER-IP` 필드에 주요 IP만 표시한다.
```shell
kubectl get svc -l app=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
```
{{< /note >}}
서비스가 `kubectl describe` 를 사용하여 IPv4 및 IPv6 주소 블록에서 클러스터 IP를 가져오는지 확인한다. 그런 다음 IP 및 포트를 통해 서비스에 대한 접속을 확인할 수 있다.
```shell
kubectl describe svc -l app=MyApp
```
```
Name: my-service
Namespace: default
Labels: app=MyApp
Annotations: <none>
Selector: app=MyApp
Type: ClusterIP
IP Family Policy: PreferDualStack
IP Families: IPv4,IPv6
IP: 10.0.216.242
IPs: 10.0.216.242,fd00::af55
Port: <unset> 80/TCP
TargetPort: 9376/TCP
Endpoints: <none>
Session Affinity: None
Events: <none>
```
### 이중 스택 로드 밸런싱 서비스 생성
만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 `ipFamily` 필드를 `IPv6`로, `type` 필드를 `LoadBalancer` 로 설정하여 다음의 서비스를 생성한다.
만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 `.spec.ipFamilyPolicy` 의 `PreferDualStack` 과 `.spec.ipFamilies` 배열의 첫 번째 요소로 `IPv6` 및 `LoadBalancer` 로 설정된 `type` 필드를 사용하여 다음 서비스를 생성한다.
{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}}
Check the Service:
```shell
kubectl get svc -l app=MyApp
```
서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
```
kubectl get svc -l app=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
```
```shell
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+69
View File
@@ -233,6 +233,75 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
있다.
{{< /note >}}
## 리소스 메트릭 지원
모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
파드의 명세를 정의할 때는 `cpu` 및 `memory` 와 같은 리소스 요청을
지정해야 한다. 이것은 리소스 사용률을 결정하는 데 사용되며 HPA 컨트롤러에서 대상을
스케일링하거나 축소하는 데 사용한다. 리소스 사용률 기반 스케일링을 사용하려면 다음과 같은 메트릭 소스를
지정해야 한다.
```yaml
type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
```
이 메트릭을 사용하면 HPA 컨트롤러는 스케일링 대상에서 파드의 평균 사용률을
60%로 유지한다. 사용률은 파드의 요청된 리소스에 대한 현재 리소스 사용량 간의
비율이다. 사용률 계산 및 평균 산출 방법에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
참조한다.
{{< note >}}
모든 컨테이너의 리소스 사용량이 합산되므로 총 파드 사용량이 개별 컨테이너 리소스 사용량을
정확하게 나타내지 못할 수 있다. 이로 인해 단일 컨테이너가
높은 사용량으로 실행될 수 있고 전체 파드 사용량이 여전히 허용 가능한 한도 내에 있기 때문에 HPA가 스케일링되지 않는
상황이 발생할 수 있다.
{{< /note >}}
### 컨테이너 리소스 메트릭
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
웹 애플리케이션의 리소스 사용을 기준으로 스케일링할 수 있다.
대상 리소스를 다른 컨테이너 세트를 사용하여 새 파드 명세를 갖도록 수정하는 경우
새로 추가된 컨테이너도 스케일링에 사용해야 한다면 HPA 사양을 수정해야 한다.
메트릭 소스에 지정된 컨테이너가 없거나 파드의 하위 집합에만 있는 경우
해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
메트릭 소스를 정의한다.
```yaml
type: ContainerResource
containerResource:
name: cpu
container: application
target:
type: Utilization
averageUtilization: 60
```
위의 예에서 HPA 컨트롤러는 모든 파드의 `application` 컨테이너에 있는 CPU의 평균 사용률이
60%가 되도록 대상을 조정한다.
{{< note >}}
HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 경우
특정 순서로 변경을 수행하여 변경 사항이 적용되는 동안 스케일링을 계속 사용할 수 있고
효율적으로 유지할 수 있다. 컨테이너를 정의하는 리소스(예: 배포)를
업데이트하기 전에 연결된 HPA를 업데이트하여 새 컨테이너 이름과 이전 컨테이너 이름을
모두 추적해야 한다. 이러한 방식으로 HPA는 업데이트 프로세스 전반에 걸쳐 스케일링 권장 사항을
계산할 수 있다.
컨테이너 이름 변경을 워크로드 리소스로 롤아웃한 후에는 HPA 사양에서
이전 컨테이너 이름을 제거하여 정리한다.
{{< /note >}}
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API