[ko] Update outdated files in dev-1.23-ko.1 M71-82
This commit is contained in:
Jihoon Seo
parent
b99aa2336a
commit
afe43b34e1
|
|
@ -1,4 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 윈도우 노드 추가
|
||||
min-kubernetes-server-version: 1.17
|
||||
content_type: tutorial
|
||||
|
|
|
|||
|
|
@ -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를 최신 패치 버전으로 바꾼다
|
||||
|
|
|
|||
|
|
@ -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 >}}
|
||||
파라미터의 영향을 파악한 후에만 운영체제가
|
||||
|
|
|
|||
|
|
@ -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 -->
|
||||
|
||||
|
|
|
|||
|
|
@ -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` 필드에 대해 읽어보기
|
||||
|
|
|
|||
|
|
@ -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` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다.
|
||||
먼저, 다음과 같이 파드를 추가한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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 서버 송신 구성 파일의 경로로 설정한다.
|
||||
|
|
|
|||
|
|
@ -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행)을 사용하여 각 잡 오브젝트에 대해
|
||||
|
|
|
|||
|
|
@ -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 -->
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Loading…
Reference in New Issue