kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #31176 from jihoon-seo/220103_Update_outdated_M71 

[ko] Update outdated files in dev-1.23-ko.1 (M71-M82)
This commit is contained in:
Kubernetes Prow Robot 2022-01-06 00:36:28 -08:00 committed by GitHub
parent 9c8e4184ed afe43b34e1
commit 4d7f985b7a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 214 additions and 122 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
View File

@ -1,4 +1,9 @@
---
title: 윈도우 노드 추가
min-kubernetes-server-version: 1.17
content_type: tutorial

16
content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
View File

@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
@ -175,10 +171,6 @@ sudo kubeadm upgrade apply
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
@ -218,10 +210,6 @@ sudo systemctl restart kubelet
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubeadm
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
@ -256,10 +244,6 @@ sudo systemctl restart kubelet
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
apt-mark hold kubelet kubectl
-
# apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
apt-get update && \
apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
{{% /tab %}}
{{% tab name="CentOS, RHEL 또는 Fedora" %}}
# {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다

25
content/ko/docs/tasks/administer-cluster/sysctl-cluster.md
View File

@ -10,8 +10,20 @@ content_type: task
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여
커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다.
커널 파라미터를 어떻게 구성하고, 사용하는지를
설명한다.
{{< note >}}
쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를
sysctl 이름의 구분자로 사용하는 것을 지원한다.
예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나
`kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다.
sysctl 파라미터 변환에 대한 세부 사항은
리눅스 맨페이지 프로젝트의
[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다.
파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는
아직 슬래시 구분자를 지원하지 않는다.
{{< /note >}}
## {{% heading "prerequisites" %}}
@ -20,6 +32,7 @@ content_type: task
일부 단계에서는 실행 중인 클러스터의 kubelet에서
커맨드 라인 옵션을 재구성할 필요가 있다.
<!-- steps -->
## 모든 sysctl 파라미터 나열
@ -52,12 +65,13 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl
허용하지 않아야 한다
아직까지 대부분 _네임스페이스된_ sysctl은 _safe_ sysctl로 고려되지 않았다.
>>> 다음 sysctl은 _safe_ 명령을 지원한다.
다음 sysctl은 _safe_ 명령을 지원한다.
- `kernel.shm_rmid_forced`,
- `net.ipv4.ip_local_port_range`,
- `net.ipv4.tcp_syncookies`,
- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후).
- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후),
- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후).
{{< note >}}
`net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다.
@ -112,10 +126,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다.
이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나
특권있는 컨테이너의 데몬셋을 사용하여야 한다.
네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다.
네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다.
securityContext는 동일한 파드의 모든 컨테이너에 적용된다.
이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인
`net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다.
스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간
차이는 없다.
{{< warning >}}
파라미터의 영향을 파악한 후에만 운영체제가

11
content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
View File

@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다.
설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고
지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가
읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를
지정한다. 여기서는
읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는
퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을
`manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을
이 퍼시스턴트볼륨에 바인딩하는데 사용한다.
이 퍼시스턴트볼륨에 바인딩하는 데 사용한다.
퍼시스턴트볼륨을 생성한다.
@ -237,8 +236,14 @@ sudo rmdir /mnt/data
이제 사용자 노드에서 셸을 종료해도 된다.
## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기
{{< codenew file="pods/storage/pv-duplicate.yaml" >}}
하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다.
`/usr/share/nginx/html` - 정적 웹사이트 용
`/etc/nginx/nginx.conf` - 기본 환경 설정 용
<!-- discussion -->

33
content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
View File

@ -6,29 +6,36 @@ weight: 100
<!-- overview -->
이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을
이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해
{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을
사용하는 파드를 생성하는 방법을 보여준다.
{{% thirdparty-content single="true" %}}
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* {{< include "task-tutorial-prereqs.md" >}}
* 이 실습을 수행하기 위해,
[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.
* 이 실습을 수행하기 위해, `docker` 명령줄 도구와
[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.
<!-- steps -->
## 도커 로그인
## 도커 허브 로그인
노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다.
`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는
[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다.
```shell
docker login
```
프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자.
프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰,
또는 도커 ID의 비밀번호)을 입력한다.
로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다.
로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다.
`config.json` 파일을 확인하자.
@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx
## 시크릿을 사용하는 파드 생성하기
다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다.
다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다.
{{< codenew file="pods/private-reg-pod.yaml" >}}
아래의 파일을 다운로드받는다.
위 파일을 컴퓨터에 다운로드한다.
```shell
wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml
```
`my-private-reg-pod.yaml` 파일 안에서, `<your-private-image>` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다.
@ -200,9 +207,9 @@ kubectl get pod private-reg
## {{% heading "whatsnext" %}}
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기
* 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기
* [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
* [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
* [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.
* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기

18
content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md
View File

@ -73,24 +73,16 @@ kubectl exec -it cassandra -- sh
## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
{{< feature-state state="beta" for_k8s_version="v1.23" >}}
컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼
컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아
`kubectl exec`가 충분하지 않을 경우에는
컨테이너가 크래시 됐거나
[distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼
컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 `kubectl exec`로는 충분하지 않은 경우에는
{{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이
인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18`
버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의
명령어가 있다.
인터랙티브한 트러블슈팅에 유용하다.
### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example}
{{< note >}}
이 섹션에서 소개하는 예시를 사용하기 위해서는
여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
{{< /note >}}
`kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다.
먼저, 다음과 같이 파드를 추가한다.

12
content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
View File

@ -1,4 +1,7 @@
---
title: 리소스 메트릭 파이프라인
content_type: concept
---
@ -62,3 +65,12 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다.
[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서
메트릭 서버에 대해 자세하게 배울 수 있다.
### 요약(Summary) API 소스
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며,
소비자(consumer)가 읽을 수 있도록 이를
[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다.
1.23 이전에는 이러한 자원들은 기본적으로 [cAdvisor](https://github.com/google/cadvisor)에 의해 수집되었다.
그러나, 1.23에서 `PodAndContainerStatsFromCRI` 기능 게이트가 추가되면서, 컨테이너 및 파드 수준 통계를 CRI 구현에서 수집할 수 있게 되었다.
참고: 이를 위해서는 CRI 구현에서도 이 기능을 지원해야 한다(containerd >= 1.6.0, CRI-O >= 1.23.0).

19
content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md
View File

@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가
클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌
두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다.
클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를
이용하여 생성할 수 있다.
<!-- steps -->
@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T
Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록
API 서버를 구성해야 한다.
1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있는지
확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여
[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를
활성화할 수 있다.
```
--service-account-issuer=api
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
--api-audiences=system:konnectivity-server
```
1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
기능이 활성화되어 있는지 확인한다.
쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다.
1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다.
1. API 서버의 `--egress-selector-config-file` 플래그를
API 서버 송신 구성 파일의 경로로 설정한다.

10
content/ko/docs/tasks/job/parallel-processing-expansion.md
View File

@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample
```liquid
{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", },
{ "name": "banana", "url": "http://dbpedia.org/resource/Banana", },
{ "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }]
%}
{%- for p in params %}
{%- set name = p["name"] %}
{%- set url = p["url"] %}
{% for p in params %}
{% set name = p["name"] %}
{% set url = p["url"] %}
---
apiVersion: batch/v1
kind: Job
@ -204,7 +204,7 @@ spec:
image: busybox
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
{%- endfor %}
{% endfor %}
```
위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해

5
content/ko/docs/tasks/network/validate-dual-stack.md
View File

@ -3,7 +3,7 @@
min-kubernetes-server-version: v1.20
min-kubernetes-server-version: v1.23
title: IPv4/IPv6 이중 스택 검증
content_type: task
---
@ -21,6 +21,9 @@ content_type: task
{{< version-check >}}
{{< note >}}
v1.23 이전 버전에서도 검증을 수행할 수 있지만 GA 기능으로만 제공되며, v1.23부터 공식적으로 지원된다.
{{< /note >}}
<!-- steps -->

162
content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -4,42 +4,59 @@
title: Horizontal Pod Autoscaler 연습
title: HorizontalPodAutoscaler 연습
content_type: task
weight: 100
min-kubernetes-server-version: 1.23
---
<!-- overview -->
Horizontal Pod Autoscaler는
CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(약어: HPA)는
워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를
자동으로 업데이트하며,
워크로드의 크기를 수요에 맞게
자동으로 스케일링하는 것을 목표로 한다.
이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다.
Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는
[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
수평 스케일링은 부하 증가에 대해
{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다.
이는 _수직_ 스케일링(쿠버네티스에서는,
해당 워크로드를 위해 이미 실행 중인 파드에
더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.
부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우,
HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋,
또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.
이 문서는 예제 웹 앱의 크기를 자동으로 조절하도록
HorizontalPodAutoscaler를 설정하는 예시를 다룬다.
이 예시 워크로드는 PHP 코드를 실행하는 아파치 httpd이다.
## {{% heading "prerequisites" %}}
이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다.
[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여
[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다.
Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면,
[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이전 버전의
쿠버네티스를 사용하고 있다면, 해당 버전의 문서를
참고한다([사용 가능한 문서의 버전](/ko/docs/home/supported-doc-versions/) 참고).
Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우,
버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가
사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부
메트릭 API와 통신이 가능해야 한다.
자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다.
이 예제를 실행하기 위해, 클러스터에 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme)가
배포 및 구성되어 있어야 한다. 쿠버네티스 Metrics Server는 클러스터의
{{<glossary_tooltip term_id="kubelet" text="kubelet">}}으로부터
리소스 메트릭을 수집하고, 수집한 메트릭을
[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 통해 노출시키며,
메트릭 수치를 나타내는 새로운 종류의 리소스를 추가하기 위해
[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용할 수 있다.
Metrics Server를 실행하는 방법을 보려면
[metrics-server 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다.
<!-- steps -->
## php-apache 서버 구동 및 노출
Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다.
HorizontalPodAutoscaler 예시에서,
먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다.
`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다.
```dockerfile
FROM php:5-apache
@ -47,7 +64,8 @@ COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
index.php는 CPU 과부하 연산을 수행한다.
아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며,
이를 이용해 클러스터에 부하를 시뮬레이트한다.
```php
<?php
@ -59,12 +77,13 @@ index.php는 CPU 과부하 연산을 수행한다.
?>
```
첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를
시작하고 서비스로 노출시킨다.
컨테이너 이미지를 만들었다면,
방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를
{{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다.
{{< codenew file="application/php-apache.yaml" >}}
다음의 명령어를 실행한다.
이를 위해, 다음의 명령어를 실행한다.
```shell
kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
@ -75,16 +94,27 @@ deployment.apps/php-apache created
service/php-apache created
```
## Horizontal Pod Autoscaler 생성
## HorizontalPodAutoscaler 생성 {#create-horizontal-pod-autoscaler}
이제 서비스가 동작중이므로,
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다.
다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
kubectl run으로 각 파드는 200 밀리코어를 요청하므로,
여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.
이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다.
이제 서비스가 동작중이므로,
`kubectl`을 사용하여 오토스케일러를 생성한다. 이를 위해
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다.
아래에서는 첫 번째 단계에서 만든 php-apache
디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는
Horizontal Pod Autoscaler를 생성하는 명령어를 실행할 것이다.
간단히 이야기하면, HPA {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는
평균 CPU 사용량을 50%로 유지하기 위해 (디플로이먼트를 업데이트하여) 레플리카의 개수를 늘리고 줄인다.
그러면 디플로이먼트는 레플리카셋을 업데이트하며(이는 모든 쿠버네티스 디플로이먼트의 동작 방식 중 일부이다),
레플리카셋은 자신의 `.spec` 필드의 변경 사항에 따라 파드를 추가하거나 제거한다.
`kubectl run`으로 각 파드는 200 밀리코어를 요청하므로, 평균 CPU 사용은 100 밀리코어이다.
알고리즘에 대한 세부 사항은
[알고리즘 세부 정보](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고한다.
HorizontalPodAutoscaler를 생성한다.
```shell
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
@ -94,47 +124,64 @@ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
horizontalpodautoscaler.autoscaling/php-apache autoscaled
```
실행 중인 오토스케일러의 현재 상태를 확인해본다.
다음을 실행하여, 새로 만들어진 HorizontalPodAutoscaler의 현재 상태를 확인할 수 있다.
```shell
# "hpa" 또는 "horizontalpodautoscaler" 둘 다 사용 가능하다.
kubectl get hpa
```
출력은 다음과 같다.
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
```
아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다.
(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다)
(HorizontalPodAutoscalers 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며,
보통은 문제가 되지 않는다.)
## 부하 증가
아직 서버로 요청을 보내는 클라이언트가 없기 때문에, 현재 CPU 사용량이 0%임을 확인할 수 있다.
(``TARGET`` 열은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다)
이번에는 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. 먼저 컨테이너를 하나 실행하고, php-apache 서비스에 무한루프의 쿼리를 전송한다(다른 터미널을 열어 수행하기 바란다).
## 부하 증가시키기 {#increase-load}
다음으로, 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다.
이를 위해, 클라이언트 역할을 하는 다른 파드를 실행할 것이다.
클라이언트 파드 안의 컨테이너가 php-apache 서비스에 쿼리를 보내는 무한 루프를 실행한다.
```shell
# 부하 생성을 유지하면서 나머지 스텝을 수행할 수 있도록,
# 다음의 명령을 별도의 터미널에서 실행한다.
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
```
실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다.
이제 아래 명령을 실행한다.
```shell
# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다.
kubectl get hpa
```
1분 쯤 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다.
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m
```
CPU 소비가 305%까지 증가하였다.
결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다.
그리고 다음과 같이 레플리카의 수가 증가한 것도 볼 수 있다.
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 305% / 50% 1 10 7 3m
```
CPU 사용률이 305%까지 증가하였다.
결과적으로, 디플로이먼트의 레플리카 개수가 7개까지 증가하였다.
```shell
kubectl get deployment php-apache
```
HorizontalPodAutoscaler를 조회했을 때와 동일한 레플리카 수를 확인할 수 있다.
```
NAME READY UP-TO-DATE AVAILABLE AGE
php-apache 7/7 7 7 19m
@ -146,24 +193,27 @@ php-apache 7/7 7 7 19m
최종 레플리카의 개수는 본 예제와 다를 수 있다.
{{< /note >}}
## 부하 중지
## 부하 발생 중지하기 {#stop-load}
본 예제를 마무리하기 위해 부하를 중단시킨다.
`busybox` 컨테이너를 띄운 터미널에서,
`busybox` 파드를 띄운 터미널에서,
`<Ctrl> + C`로 부하 발생을 중단시킨다.
그런 다음 (몇 분 후에) 결과를 확인한다.
```shell
kubectl get hpa
# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다.
kubectl get hpa php-apache --watch
```
출력은 다음과 같다.
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
```
디플로이먼트도 스케일 다운 했음을 볼 수 있다.
```shell
kubectl get deployment php-apache
```
@ -173,7 +223,7 @@ NAME READY UP-TO-DATE AVAILABLE AGE
php-apache 1/1 1 1 27m
```
CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다.
CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카의 개수를 1로 줄였다.
{{< note >}}
레플리카 오토스케일링은 몇 분 정도 소요된다.
@ -184,9 +234,9 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링
`php-apache` 디플로이먼트를 오토스케일링할 때,
`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다.
`autoscaling/v2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다.
첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
첫 번째로, `autoscaling/v2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
```shell
kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
@ -195,7 +245,7 @@ kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.
```yaml
apiVersion: autoscaling/v2beta2
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
@ -287,7 +337,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수
`kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다.
```yaml
apiVersion: autoscaling/v2beta2
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
@ -411,7 +461,7 @@ object:
## 부록: Horizontal Pod Autoscaler 상태 조건
HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면,
HorizontalPodAutoscaler의 `autoscaling/v2` 형식을 사용하면,
HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다.
이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지,
어떤 방식으로든 제한되어 있는지 여부를 나타낸다.
@ -449,12 +499,12 @@ Events:
백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지),
원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
일반적으로 메트릭을 가져오는데 문제가 있다.
일반적으로 메트릭을 가져오는 데 문제가 있다.
마지막으로, 마지막 조건인 `ScalingLimited`는
원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다.
이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다.
## 부록: 수량
## 수량
HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
쿠버네티스에서 사용하는
@ -464,16 +514,16 @@ HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
일반적으로 수량을 밀리단위로 반환한다.
10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다.
## 부록: 다른 가능한 시나리오
## 다른 가능한 시나리오
### 명시적으로 오토스케일러 만들기
HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고,
명시적으로 다음 파일을 사용하여 만들 수 있다.
명시적으로 다음 매니페스트를 사용하여 만들 수 있다.
{{< codenew file="application/hpa/php-apache.yaml" >}}
다음 명령어를 실행하여 오토스케일러를 생성할 것이다.
다음으로, 아래의 명령어를 실행하여 오토스케일러를 생성한다.
```shell
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml

20
content/ko/examples/pods/storage/pv-duplicate.yaml Normal file
View File

@ -0,0 +1,20 @@
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: test
image: nginx
volumeMounts:
- name: site-data
mountPath: /usr/share/nginx/html
subPath: html
- name: config
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: config
persistentVolumeClaim:
claimName: test-nfs-claim