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

Merge pull request #31637 from kubernetes/dev-1.23-ko.1 

[ko] 1st Korean localization work for v1.23
This commit is contained in:
Kubernetes Prow Robot 2022-02-05 17:02:50 -08:00 committed by GitHub
parent e31ee88e15 80ca73cab3
commit fdd25460d8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
101 changed files with 2222 additions and 1389 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ko/_index.html
View File

@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
{{% blocks/feature image="suitcase" %}}
#### K8s를 어디서나 실행
쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.
{{% /blocks/feature %}}

1
content/ko/community/_index.html
View File

@ -19,6 +19,7 @@ cid: community
<div class="community__navbar">
<a href="https://www.kubernetes.dev/">기여자 커뮤니티</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#values">커뮤니티 가치</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

4
content/ko/docs/concepts/architecture/cloud-controller.md
View File

@ -44,10 +44,10 @@ weight: 40
### 노드 컨트롤러
노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}}
오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자
테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다.
1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다.
1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다.
2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를
사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다.
3. 노드의 호스트 이름과 네트워크 주소를 가져온다.

50
content/ko/docs/concepts/architecture/cri.md Normal file
View File

@ -0,0 +1,50 @@
---
title: 컨테이너 런타임 인터페이스(CRI)
content_type: concept
weight: 50
---
<!-- overview -->
컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한
컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다.
클러스터의 모든 노드에 동작 중인
{{<glossary_tooltip text="컨테이너 런타임" term_id="container-runtime">}}이 존재해야,
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이
{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을
구동할 수 있다.
{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
<!-- body -->
## API {#api}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
Kubelet은 gRPC를 통해 컨테이너 런타임과 연결할 때 클라이언트의 역할을 수행한다.
런타임과 이미지 서비스 엔드포인트는 컨테이너 런타임 내에서 사용 가능해야 하며,
이는 각각 Kubelet 내에서 `--image-service-endpoint`와 `--container-runtime-endpoint`
[커맨드라인 플래그](/docs/reference/command-line-tools-reference/kubelet)
를 통해 설정할 수 있다.
쿠버네티스 v{{< skew currentVersion >}}에서는, Kubelet은 CRI `v1`을 사용하는 것을 권장한다.
컨테이너 런타임이 CRI `v1` 버전을 지원하지 않는다면,
Kubelet은 지원 가능한 이전 지원 버전으로 협상을 시도한다.
또한 v{{< skew currentVersion >}} Kubelet은 CRI `v1alpha2`버전도 협상할 수 있지만,
해당 버전은 사용 중단(deprecated)으로 간주한다.
Kubelet이 지원되는 CRI 버전을 협상할 수 없는 경우,
Kubelet은 협상을 포기하고 노드로 등록하지 않는다.
## 업그레이드
쿠버네티스를 업그레이드할 때, Kubelet은 컴포넌트의 재시작 시점에서 최신 CRI 버전을 자동으로 선택하려고 시도한다.
이 과정이 실패하면 위에서 언급한 대로 이전 버전을 선택하는 과정을 거친다.
컨테이너 런타임이 업그레이드되어 gRPC 재다이얼이 필요하다면,
컨테이너 런타임도 처음에 선택된 버전을 지원해야 하며,
그렇지 못한 경우 재다이얼은 실패하게 될 것이다. 이 과정은 Kubelet의 재시작이 필요하다.
## {{% heading "whatsnext" %}}
- CRI [프로토콜 정의](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)를 자세히 알아보자.

117
content/ko/docs/concepts/architecture/nodes.md
View File

@ -385,7 +385,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
자세한 내용은
[노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown}
## 그레이스풀(Graceful) 노드 셧다운(shutdown) {#graceful-node-shutdown}
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
제어된다.
기본적으로, 아래 설명된 두 구성 옵션,
`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.
@ -412,32 +412,116 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `ShutdownGracePeriod`:
* `shutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* `ShutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
* `shutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다.
예를 들어, `ShutdownGracePeriod=30s`,
`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
예를 들어, `shutdownGracePeriod=30s`,
`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의
유예 종료에 할당되고, 마지막 10초는
[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.
`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다.
그레이스풀 노드 셧다운 과정에서 축출된 파드는 셧다운(shutdown)된 것으로 표시된다.
`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Terminated`으로 표시된다.
그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다.
```
Status: Failed
Reason: Shutdown
Message: Node is shutting, evicting pods
Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다.
이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
{{< /note >}}
### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
그레이스풀 노드 셧다운 시 파드 셧다운 순서에 더 많은 유연성을 제공할 수 있도록,
클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면
그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다.
이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가
[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)
기반으로 명시적으로 정할 수 있다.
위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를
중요하지 않은(non-critical) 파드와
중요한(critical) 파드 2단계(phase)로 구분하여 종료시킨다.
셧다운 시 파드가 종료되는 순서를 명시적으로 더 상세하게 정해야 한다면,
파드 우선순위 기반 그레이스풀 노드 셧다운을 사용할 수 있다.
그레이스풀 노드 셧다운 과정에서 파드 우선순위가 고려되기 때문에,
그레이스풀 노드 셧다운이 여러 단계로 일어날 수 있으며,
각 단계에서 특정 프라이어리티 클래스의 파드를 종료시킨다.
정확한 단계와 단계별 셧다운 시간은 kubelet에 설정할 수 있다.
다음과 같이 클러스터에 커스텀 파드
[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)가 있다고
가정하자.
|파드 프라이어리티 클래스 이름|파드 프라이어리티 클래스 값|
|-------------------------|------------------------|
|`custom-class-a` | 100000 |
|`custom-class-b` | 10000 |
|`custom-class-c` | 1000 |
|`regular/unset` | 0 |
[kubelet 환경 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 안의
`shutdownGracePeriodByPodPriority` 설정은 다음과 같을 수 있다.
|파드 프라이어리티 클래스 값|종료 대기 시간|
|------------------------|---------------|
| 100000 |10 seconds |
| 10000 |180 seconds |
| 1000 |120 seconds |
| 0 |60 seconds |
이를 나타내는 kubelet 환경 설정 YAML은 다음과 같다.
```yaml
shutdownGracePeriodByPodPriority:
- priority: 100000
shutdownGracePeriodSeconds: 10
- priority: 10000
shutdownGracePeriodSeconds: 180
- priority: 1000
shutdownGracePeriodSeconds: 120
- priority: 0
shutdownGracePeriodSeconds: 60
```
위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며,
10000 이상 ~ 100000 미만이면 180초,
1000 이상 ~ 10000 미만이면 120초가 주어진다.
마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다.
모든 클래스에 대해 값을 명시할 필요는 없다.
예를 들어, 대신 다음과 같은 구성을 사용할 수도 있다.
|파드 프라이어리티 클래스 값|종료 대기 시간|
|------------------------|---------------|
| 100000 |300 seconds |
| 1000 |120 seconds |
| 0 |60 seconds |
위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는
동일한 종료 대기 시간을 갖게 될 것이다.
특정 범위에 해당되는 파드가 없으면,
kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않는다.
대신, kubelet은 즉시 다음 프라이어리티 클래스 값 범위로 넘어간다.
기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면,
순서 지정 동작이 수행되지 않을 것이다.
이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고,
kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를
파드 프라이어리티 클래스 값과
각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다.
## 스왑(swap) 메모리 관리 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
@ -451,6 +535,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에
[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
false로 지정되어야 한다.
{{< warning >}}
메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은
tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다.
{{< /warning >}}
사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며,
이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,

5
content/ko/docs/concepts/cluster-administration/addons.md
View File

@ -45,6 +45,11 @@ content_type: concept
## 인프라스트럭처
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다.
* [node problem detector](https://github.com/kubernetes/node-problem-detector)는
리눅스 노드에서 실행되며,
시스템 이슈를
[이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는
[노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다.
## 레거시 애드온

55
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -64,7 +64,7 @@ weight: 50
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
한다.
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다.
`Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를
요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은
@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
충족하는 매우 간단한 오버레이 네트워크이다. 많은
경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.
### Google 컴퓨트 엔진(GCE)
Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급
라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여
각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된
모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는
아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본"
IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록
구성되며, 도커의 `--bridge` 플래그로 전달된다.
도커는 다음의 설정으로 시작한다.
```shell
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
```
이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet`
플래그로 제어되는)에 의해 생성된다.
도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를
통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크
내에서 라우팅할 수 있다.
그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해
IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여
GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을
마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼
보이게 함)한다.
```shell
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
```
마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에
대한 패킷을 처리한다.
```shell
sysctl net.ipv4.ip_forward=1
```
이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을
송신할 수 있다는 것이다.
### 재규어(Jaguar)
[재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
@ -260,12 +217,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://
[NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
### OpenVSwitch
[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만
오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇
"대형 벤더"에 의해 승인되었다.
### OVN(오픈 버추얼 네트워킹)
OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
@ -274,10 +225,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에
특정 쿠버네티스 플러그인 및 문서가 있다.
### 로마나
[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다.
### Weaveworks의 위브넷
[위브넷](https://www.weave.works/products/weave-net/)은

14
content/ko/docs/concepts/configuration/manage-resources-containers.md
View File

@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
수량이다. 이것은
[API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및
[서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는
쿠버네티스 API 서버를 통해 읽고 수정할 수
있는 오브젝트이다.
쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다.
## 파드와 컨테이너의 리소스 요청 및 제한
@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다.
쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다.
분수의 요청이 허용된다.
`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진
컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은
요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의
`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은,
`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다.
CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은
"백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은
"백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며,
@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
### 메모리의 의미
`memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를
E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를
일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
```shell
128974848, 129e6, 129M, 123Mi
128974848, 129e6, 129M, 128974848000m, 123Mi
```
다음은 예제이다.

2
content/ko/docs/concepts/configuration/overview.md
View File

@ -55,7 +55,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다.
만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다.
- `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다.

2
content/ko/docs/concepts/configuration/secret.md
View File

@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \
`kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기
위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가
다음의 두 키를 포함해야 한다.
다음의 두 키 중 하나를 포함해야 한다.
- `username`: 인증을 위한 사용자 이름
- `password`: 인증을 위한 암호나 토큰

85
content/ko/docs/concepts/containers/images.md
View File

@ -54,13 +54,15 @@ weight: 10
컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는
[kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다.
다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다.
다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과
효과이다.
`IfNotPresent`
: 이미지가 로컬에 없는 경우에만 내려받는다.
`Always`
: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의
: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너
이미지 레지스트리에 이름과 이미지의
[다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다.
일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다.
이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서
@ -78,7 +80,8 @@ weight: 10
{{< note >}}
프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데,
이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다.
이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고
제대로 롤백하기 어렵게 되기 때문이다.
대신, `v1.42.0`과 같이 의미있는 태그를 명기한다.
{{< /note >}}
@ -90,7 +93,8 @@ weight: 10
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.
파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가
태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다.
이는 레지스트리에서 태그가 변경되는 일이 발생해도
구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다.
@ -104,7 +108,9 @@ weight: 10
`:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다.
- `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우,
`imagePullPolicy`는 자동으로 `Always`로 설정된다.
- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다.
- `imagePullPolicy` 필드를 생략하고,
명기한 컨테이너 이미지의 태그가 `:latest`가 아니면,
`imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다.
{{< note >}}
컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상
@ -127,6 +133,7 @@ weight: 10
그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다.
### 이미지풀백오프(ImagePullBackOff)
kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때,
@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
### config.json 파일 해석 {#config-json}
`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다.
도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나,
쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다.
이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다.
```json
{
"auths": {
"*my-registry.io/images": {
"auth": "…"
}
}
}
```
루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다.
```
pattern:
{ term }
term:
'*' 구분자가 아닌 모든 문자와 매치됨
'?' 구분자가 아닌 문자 1개와 매치됨
'[' [ '^' ] { character-range } ']'
문자 클래스 (비어 있으면 안 됨))
c 문자 c에 매치됨 (c != '*', '?', '\\', '[')
'\\' c 문자 c에 매치됨
character-range:
c 문자 c에 매치됨 (c != '\\', '-', ']')
'\\' c 문자 c에 매치됨
lo '-' hi lo <= c <= hi 인 문자 c에 매치됨
```
이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다.
예를 들어 다음과 같은 컨테이너 이미지 이름은
성공적으로 매치될 것이다.
- `my-registry.io/images`
- `my-registry.io/images/my-image`
- `my-registry.io/images/another-image`
- `sub.my-registry.io/images/my-image`
- `a.sub.my-registry.io/images/my-image`
kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉,
`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다.
```json
{
"auths": {
"my-registry.io/images": {
"auth": "…"
},
"my-registry.io/images/subpath": {
"auth": "…"
}
}
}
```
이제 컨테이너가 `my-registry.io/images/subpath/my-image`
이미지를 풀 해야 한다고 명시하면,
kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
### 미리 내려받은 이미지 {#pre-pulled-images}
{{< note >}}
@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry)

6
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -77,7 +77,7 @@ no_list: true
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서 사용한다.
@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
### 인가
[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
### 동적 어드미션 컨트롤
@ -163,6 +163,8 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다.
### 장치 플러그인

7
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -37,7 +37,8 @@ _선언적(declarative) API_ 를 제공하게 된다.
쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는
책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다.
쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다.
쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가
선언한 의도한 상태에 동기화 되도록 한다.
이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다.
클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
@ -146,9 +147,9 @@ CRD 오브젝트의 이름은 유효한
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다.
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여
주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여
모든 클라이언트가 사용할 수 있게 한다.
## 커스텀 리소스를 추가할 방법 선택

34
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -197,6 +197,8 @@ service PodResourcesLister {
}
```
### `List` gRPC 엔드포인트 {#grpc-endpoint-list}
`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
@ -246,10 +248,35 @@ message ContainerDevices {
TopologyInfo topology = 3;
}
```
{{< note >}}
`List` 엔드포인트의 `ContainerResources` 내부에 있는 cpu_ids은 특정 컨테이너에 할당된
독점 CPU들에 해당한다. 만약 공유 풀(shared pool)에 있는 CPU들을 확인(evaluate)하는 것이 목적이라면, 해당 `List`
엔드포인트는 다음에 설명된 것과 같이, `GetAllocatableResources` 엔드포인트와 함께 사용되어야
한다.
1. `GetAllocatableResources`를 호출하여 할당 가능한 모든 CPU 목록을 조회
2. 시스템의 모든 `ContainerResources`에서 `GetCpuIds`를 호출
3. `GetAllocateableResources` 호출에서 `GetCpuIds` 호출로 얻은 모든 CPU를 빼기
{{< /note >}}
### `GetAllocatableResources` gRPC 엔드포인트 {#grpc-endpoint-getallocatableresources}
{{< feature-state state="beta" for_k8s_version="v1.23" >}}
GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다.
kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다.
{{< note >}}
`GetAllocatableResources`는 [할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스를 확인(evaluate)하기 위해서만
사용해야 한다. 만약 목적이 free/unallocated 리소스를 확인하기 위한 것이라면
List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`로 얻은 결과는 kubelet에
노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면
(예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를
호출할 것으로 가정한다.
그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는
충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다.
{{< /note >}}
```gRPC
// AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다.
message AllocatableResourcesResponse {
@ -259,6 +286,13 @@ message AllocatableResourcesResponse {
}
```
쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다.
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
끄면 된다.
쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다.
`--feature-gates=KubeletPodResourcesGetAllocatable=true`
`ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은

4
content/ko/docs/concepts/extend-kubernetes/operator.md
View File

@ -31,9 +31,7 @@ weight: 30
및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을
자동화할 수 있다.
쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}
개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을
확장할 수 있다.
쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다.
오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의
컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.

2
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -227,7 +227,7 @@ spec:
## {{% heading "whatsnext" %}}
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기

74
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -1,4 +1,6 @@
---
title: 쿠버네티스 API
content_type: concept
weight: 30
@ -35,36 +37,39 @@ card:
완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다.
OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.
### OpenAPI V2
쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해
통합된(aggregated) OpenAPI v2 스펙을 제공한다.
요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다.
<table>
<caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
<caption style="display:none"> OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
<thead>
<tr>
<th>Header</th>
<th style="min-width: 50%;">Possible values</th>
<th>Notes</th>
<th>헤더</th>
<th style="min-width: 50%;">사용할 수 있는 값</th>
<th>참고</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Accept-Encoding</code></td>
<td><code>gzip</code></td>
<td><em>not supplying this header is also acceptable</em></td>
<td><em>이 헤더를 제공하지 않는 것도 가능</em></td>
</tr>
<tr>
<td rowspan="3"><code>Accept</code></td>
<td><code>application/com.github.proto-openapi.spec.v2@v1.0+protobuf</code></td>
<td><em>mainly for intra-cluster use</em></td>
<td><em>주로 클러스터 내부 용도로 사용</em></td>
</tr>
<tr>
<td><code>application/json</code></td>
<td><em>default</em></td>
<td><em>기본값</em></td>
</tr>
<tr>
<td><code>*</code></td>
<td><em>serves </em><code>application/json</code></td>
<td><code>JSON으로 응답</em></td>
</tr>
</tbody>
</table>
@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
IDL(인터페이스 정의 언어) 파일을 참고한다.
### OpenAPI V3
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다.
이는 알파 기능이며 기본적으로 비활성화되어 있다.
kube-apiserver 구성 요소에
`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여
이 알파 기능을 활성화할 수 있다.
이 기능이 활성화되면, 쿠버네티스 API 서버는
통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로
`/openapi/v3/apis/<group>/<version>` 엔드포인트에 제공한다.
사용할 수 있는 요청 헤더는 아래의 표를 참고한다.
<table>
<caption style="display:none"> OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
<thead>
<tr>
<th>헤더</th>
<th style="min-width: 50%;">사용할 수 있는 값</th>
<th>참고</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Accept-Encoding</code></td>
<td><code>gzip</code></td>
<td><em>이 헤더를 제공하지 않는 것도 가능</em></td>
</tr>
<tr>
<td rowspan="3"><code>Accept</code></td>
<td><code>application/com.github.proto-openapi.spec.v3@v1.0+protobuf</code></td>
<td><em>주로 클러스터 내부 용도로 사용</em></td>
</tr>
<tr>
<td><code>application/json</code></td>
<td><em>기본값</em></td>
</tr>
<tr>
<td><code>*</code></td>
<td><code>JSON으로 응답</em></td>
</tr>
</tbody>
</table>
`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든
그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
## 지속성
쿠버네티스는 오브젝트의 직렬화된 상태를

2
content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
View File

@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기

4
content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
View File

@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면,
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
@ -161,4 +161,4 @@ percentageOfNodesToScore: 50
## {{% heading "whatsnext" %}}
* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인
* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인

16
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -203,7 +203,7 @@ tolerations:
* `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된
시간 동안 바인딩된 상태로 유지된다.
노드 컨트롤러는 특정 조건이 참일 때 자동으로
노드 컨트롤러는 특정 컨디션이 참일 때 자동으로
노드를 테인트시킨다. 다음은 빌트인 테인트이다.
* `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition
@ -264,19 +264,19 @@ tolerations:
이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
## 조건(condition)을 기준으로 노드 테인트하기
## 컨디션(condition)을 기준으로 노드 테인트하기
컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여
[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
예를 들어 `DiskPressure` 노드 조건이 활성화된 경우
스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다.
예를 들어 `DiskPressure` 노드 컨디션이 활성화된 경우
컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다.
`MemoryPressure` 노드 조건이 활성화되면
`MemoryPressure` 노드 컨디션이 활성화되면
컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다.
새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다.
새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 컨디션을 무시하도록 할 수 있다.
또한 컨트롤 플레인은 `BestEffort` 이외의
{{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에
`node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다.

6
content/ko/docs/concepts/services-networking/connect-applications-service.md
View File

@ -1,4 +1,8 @@
---
title: 서비스와 애플리케이션 연결하기
content_type: concept
weight: 30
@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다.
만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.
## 서비스 생성하기

2
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다
DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은
각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는
`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은
`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은
쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
[`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다.

16
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -1,4 +1,9 @@
---
title: IPv4/IPv6 이중 스택
feature:
title: IPv4/IPv6 이중 스택
@ -11,7 +16,7 @@ weight: 70
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다.
@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
## IPv4/IPv6 이중 스택 구성
IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.)
IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다.
* kube-apiserver:
@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도
IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.)
1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다.
필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에
`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다.
{{< /note >}}
## 서비스
@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
* `PreferDualStack`:
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.)
* 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
* `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서
#### 기존 서비스의 이중 스택 기본값
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.)
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.)
1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.

1
content/ko/docs/concepts/services-networking/ingress-controllers.md
View File

@ -28,6 +28,7 @@ weight: 40
컨트롤러다.
* [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
* [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다.
* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.

104
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -51,7 +51,7 @@ graph LR;
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는
[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는
[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다.
## 전제 조건들
@ -219,20 +219,98 @@ Events: <none>
{{< codenew file="service/networking/external-lb.yaml" >}}
IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한
추가 구현 별 구성을 참조하는데 사용할 수 있다.
인그레스클래스의 `.spec.parameters` 필드를 사용하여
해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다.
#### 네임스페이스 범위의 파라미터
사용 가능한 파라미터의 상세한 타입은
인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다.
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
### 인그레스클래스 범위
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의
리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를
설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다.
인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고,
또는 한 네임스페이스에서만 사용 가능할 수도 있다.
{{< codenew file="service/networking/namespaced-params.yaml" >}}
{{< tabs name="tabs_ingressclass_parameter_scope" >}}
{{% tab name="클러스터" %}}
인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다.
`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나,
`.spec.parameters.scope` 필드를 `Cluster`로 지정하면,
인그레스클래스는 클러스터 범위의 리소스를 참조한다.
파라미터의 `kind`(+`apiGroup`)는
클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며,
파라미터의 `name`은
해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다.
예시는 다음과 같다.
```yaml
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb-1
spec:
controller: example.com/ingress-controller
parameters:
# 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는
# ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다.
# 이 정의는 쿠버네티스가
# 클러스터 범위의 파라미터 리소스를 검색하도록 한다.
scope: Cluster
apiGroup: k8s.example.net
kind: ClusterIngressParameter
name: external-config-1
```
{{% /tab %}}
{{% tab name="네임스페이스" %}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
`.spec.parameters` 필드를 설정하고
`.spec.parameters.scope` 필드를 `Namespace`로 지정하면,
인그레스클래스는 네임스페이스 범위의 리소스를 참조한다.
사용하고자 하는 파라미터가 속한 네임스페이스를
`.spec.parameters` 의 `namespace` 필드에 설정해야 한다.
파라미터의 `kind`(+`apiGroup`)는
네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며,
파라미터의 `name`은
`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다.
네임스페이스 범위의 파라미터를 이용하여,
클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다.
클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다.
- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다
클러스터 운영 팀이 매번 승인을 해야 한다. 또는,
- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는
[RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를
클러스터 운영자가 정의해야 한다.
인그레스클래스 API 자신은 항상 클러스터 범위이다.
네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가
다음과 같다.
```yaml
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: external-lb-2
spec:
controller: example.com/ingress-controller
parameters:
# 이 인그레스클래스에 대한 파라미터는
# "external-configuration" 환경 설정 네임스페이스에 있는
# "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
scope: Namespace
apiGroup: k8s.example.com
kind: IngressParameter
namespace: external-configuration
name: external-config
```
{{% /tab %}}
{{< /tabs >}}
### 사용중단(Deprecated) 어노테이션
@ -559,12 +637,12 @@ Events:
사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다.
* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용.
* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용.
* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 사용.
## {{% heading "whatsnext" %}}
* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기
* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/)

2
content/ko/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기
* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

4
content/ko/docs/concepts/services-networking/service.md
View File

@ -550,7 +550,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
* `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
`ServiceTypes`의 기본 값이다.
* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를
노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가
자동으로 생성된다. `<NodeIP>:<NodePort>`를 요청하여,
클러스터 외부에서
@ -568,7 +568,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
[인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
### NodePort 유형 {#nodeport}
### NodePort 유형 {#type-nodeport}
`type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은
`--service-node-port-range` 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767).

58
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -10,14 +10,13 @@ feature:
title: 스토리지 오케스트레이션
description: >
로컬 스토리지, <a href="https://cloud.google.com/storage/">GCP</a>나 <a href="https://aws.amazon.com/products/storage/">AWS</a>와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다.
content_type: concept
weight: 20
---
<!-- overview -->
이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
<!-- body -->
@ -221,19 +220,19 @@ spec:
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의
퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의
볼륨을 확장할 수 있다.
* gcePersistentDisk
* azureDisk
* azureFile
* awsElasticBlockStore
* Cinder
* cinder (deprecated)
* {{< glossary_tooltip text="csi" term_id="csi" >}}
* flexVolume (deprecated)
* gcePersistentDisk
* glusterfs
* rbd
* Azure File
* Azure Disk
* Portworx
* FlexVolumes
* {{< glossary_tooltip text="CSI" term_id="csi" >}}
* portworxVolume
스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다.
@ -270,7 +269,7 @@ CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확
경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나
파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다.
FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다.
FlexVolumes(쿠버네티스 v1.23부터 사용 중단됨)는 드라이버의 `RequiresFSResize` 기능이 `true`로 설정된 경우 크기 조정을 허용한다.
FlexVolume은 파드 재시작 시 크기를 조정할 수 있다.
#### 사용 중인 퍼시스턴트볼륨클레임 크기 조정
@ -299,6 +298,11 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
#### 볼륨 확장 시 오류 복구
사용자가 기반 스토리지 시스템이 제공할 수 있는 것보다 더 큰 사이즈를 지정하면, 사용자 또는 클러스터 관리자가 조치를 취하기 전까지 PVC 확장을 계속 시도한다. 이는 바람직하지 않으며 따라서 쿠버네티스는 이러한 오류 상황에서 벗어나기 위해 다음과 같은 방법을 제공한다.
{{< tabs name="recovery_methods" >}}
{{% tab name="클러스터 관리자 접근 권한을 이용하여 수동으로" %}}
기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다.
1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다.
@ -307,6 +311,30 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다.
5. PV의 반환 정책을 복원하는 것을 잊지 않는다.
{{% /tab %}}
{{% tab name="더 작은 크기로의 확장을 요청하여" %}}
{{% feature-state for_k8s_version="v1.23" state="alpha" %}}
{{< note >}}
PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다.
{{< /note >}}
클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure`
기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면
이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다.
더 작은 크기를 지정하여 확장 시도를 요청하려면,
이전에 요청했던 값보다 작은 크기로 PVC의 `.spec.resources` 값을 수정한다.
이는 총 용량 제한(capacity constraint)으로 인해 큰 값으로의 확장이 실패한 경우에 유용하다.
만약 확장이 실패했다면, 또는 실패한 것 같다면, 기반 스토리지 공급자의 용량 제한보다 작은 값으로 확장을 재시도할 수 있다.
`.status.resizeStatus`와 PVC의 이벤트를 감시하여 리사이즈 작업의 상태를 모니터할 수 있다.
참고:
이전에 요청했던 값보다 작은 크기를 요청했더라도,
새로운 값이 여전히 `.status.capacity`보다 클 수 있다.
쿠버네티스는 PVC를 현재 크기보다 더 작게 축소하는 것은 지원하지 않는다.
{{% /tab %}}
{{% /tabs %}}
## 퍼시스턴트 볼륨의 유형
@ -318,7 +346,6 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
@ -336,6 +363,8 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
(v1.18에서 **사용 중단**)
* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume
(v1.23에서 **사용 중단**)
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
(v1.22에서 **사용 중단**)
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
@ -417,9 +446,12 @@ spec:
`ReadWriteOnce`
: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.
`ReadWriteMany`
`ReadOnlyMany`
: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.
`ReadWriteMany`
: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다.
`ReadWriteOncePod`
: 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다.

3
content/ko/docs/concepts/storage/storage-capacity.md
View File

@ -7,7 +7,7 @@
title: 스토리지 용량
content_type: concept
weight: 45
weight: 70
---
<!-- overview -->
@ -16,7 +16,6 @@ weight: 45
예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고

4
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -470,14 +470,14 @@ parameters:
vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다.
- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com`
- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com`
- [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume`
인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다.
#### CSI 프로비저닝 도구 {#vsphere-provisioner-csi}
vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다.
vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다.
#### vCP 프로비저닝 도구

7
content/ko/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -1,7 +1,12 @@
---
title: CSI 볼륨 복제하기
content_type: concept
weight: 30
weight: 60
---
<!-- overview -->

2
content/ko/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -8,7 +8,7 @@
title: 볼륨 스냅샷 클래스
content_type: concept
weight: 30
weight: 41 # just after volume snapshots
---
<!-- overview -->

9
content/ko/docs/concepts/storage/volume-snapshots.md
View File

@ -1,7 +1,14 @@
---
title: 볼륨 스냅샷
content_type: concept
weight: 20
weight: 40
---
<!-- overview -->

221
content/ko/docs/concepts/storage/volumes.md
View File

@ -44,12 +44,21 @@ weight: 10
볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고
`.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는
파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를
가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로
지정해야 한다.
컨테이너의 프로세스는
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과
컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다.
프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을
보게 된다.
쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면
추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다.
볼륨은 이미지의 [특정 경로](#using-subpath)에
마운트된다.
파드에 정의된 각 컨테이너에 대해,
컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다.
볼륨은 다른 볼륨 안에 마운트될 수 없다
(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다).
또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다.
## 볼륨 유형들 {#volume-types}
@ -802,142 +811,7 @@ spec:
### projected
`Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다.
현재, 다음 유형의 볼륨 소스를 프로젝티드한다.
* [`secret`](#secret)
* [`downwardAPI`](#downwardapi)
* [`configMap`](#configmap)
* `serviceAccountToken`
모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "cpu_limit"
resourceFieldRef:
containerName: container-test
resource: limits.cpu
- configMap:
name: myconfigmap
items:
- key: config
path: my-group/my-config
```
#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- secret:
name: mysecret2
items:
- key: password
path: my-group/my-password
mode: 511
```
각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다.
파라미터는 두 가지 예외를 제외하고 거의 동일하다.
* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록
`name` 으로 변경되었다.
* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만
지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode`
를 명시적으로 설정할 수 있다.
`TokenRequestProjection` 기능이 활성화 되면, 현재
[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에
대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: sa-token-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: token-vol
mountPath: "/service-account"
readOnly: true
volumes:
- name: token-vol
projected:
sources:
- serviceAccountToken:
audience: api
expirationSeconds: 3600
path: token
```
예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이
있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데
사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을
포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며,
그렇지 않으면 토큰을 거부해야 한다. 이 필드는
선택 사항이며 기본값은 API 서버의 식별자이다.
`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효
기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는
API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서
최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한
상대 경로를 지정한다.
{{< note >}}
projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는
해당 볼륨 소스의 업데이트를 수신하지 않는다.
{{< /note >}}
더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다.
### quobyte (사용 중단됨) {#quobyte}
@ -975,6 +849,38 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를
참고한다.
#### RBD CSI 마이그레이션 {#rbd-csi-migration}
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
`RBD`를 위한 `CSIMigration` 기능이 활성화되어 있으면,
사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을
`rbd.csi.ceph.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}
드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에
[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고
`CSIMigration`, `CSIMigrationRBD`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
{{< note >}}
스토리지를 관리하는 쿠버네티스 클러스터 관리자는,
RBD CSI 드라이버로의 마이그레이션을 시도하기 전에
다음의 선행 사항을 완료해야 한다.
* 쿠버네티스 클러스터에 Ceph CSI 드라이버 (`rbd.csi.ceph.com`) v3.5.0
이상을 설치해야 한다.
* CSI 드라이버가 동작하기 위해 `clusterID` 필드가 필수이지만
트리 내(in-tree) 스토리지클래스는 `monitors` 필드가 필수임을 감안하여,
쿠버네티스 저장소 관리자는 monitors 값의
해시(예: `#echo -n '<monitors_string>' | md5sum`)
기반으로 clusterID를 CSI 컨피그맵 내에 만들고
이 clusterID 환경 설정 아래에 monitors 필드를 유지해야 한다.
* 또한, 트리 내(in-tree) 스토리지클래스의
`adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의
`adminSecretName` 값이 `adminId` 파라미터 값의
base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다.
### secret
`secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
@ -1144,6 +1050,16 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를
`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다.
#### Portworx CSI 마이그레이션
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만
알파 상태이기 때문에 기본적으로는 비활성화되어 있다.
이 기능은 사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을
`pxd.portworx.com` CSI 드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에 [Portworx CSI 드라이버](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)가
설치되어 있고, kube-controller-manager와 kubelet에 `CSIMigrationPortworx=true`로 설정해야 한다.
## subPath 사용하기 {#using-subpath}
때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다.
@ -1239,8 +1155,7 @@ spec:
## 아웃-오브-트리(out-of-tree) 볼륨 플러그인
아웃-오브-트리 볼륨 플러그인에는
{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고
FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에
{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 FlexVolume(사용 중단됨)이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에
추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다.
이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와
@ -1373,13 +1288,21 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트
### flexVolume
FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는
아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에
접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의
미리 정의된 볼륨 플러그인 경로에 설치해야 한다.
{{< feature-state for_k8s_version="v1.23" state="deprecated" >}}
FlexVolume은 스토리지 드라이버와 인터페이싱하기 위해 exec 기반 모델을 사용하는 아웃-오브-트리 플러그인 인터페이스이다.
FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 볼륨 플러그인 경로에 설치되어야 하며,
일부 경우에는 컨트롤 플레인 노드에도 설치되어야 한다.
파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다.
더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다.
더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다.
{{< note >}}
FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다.
FlexVolume 드라이버 메인테이너는 CSI 드라이버를 구현하고 사용자들이 FlexVolume 드라이버에서 CSI로 마이그레이트할 수 있도록 지원해야 한다.
FlexVolume 사용자는 워크로드가 동등한 CSI 드라이버를 사용하도록 이전해야 한다.
{{< /note >}}
## 마운트 전파(propagation)

37
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="
하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=<time zone>"을 추가해서 타임존을 명기할 수 있으며, 항상 `CRON_TZ`를 설정하는 것을 권장한다.
{{< caution >}}
모든 **크론잡** `일정:` 시간은
{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
@ -28,6 +26,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
크론잡 컨트롤러가 사용하는 시간대로 결정한다.
{{< /caution >}}
{{< caution >}}
[v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)은
위에서 설명한 타임존 설정을 공식적으로 지원하지는 않는다.
`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 쿠버네티스 프로젝트에서 공식적으로 지원하지는 않는다.
`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은
크론탭을 파싱하고 다음 잡 생성 시간을 계산하는 내부 라이브러리의 구현 상세사항이다.
프로덕션 클러스터에서는 사용을 권장하지 않는다.
{{< /caution >}}
크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
@ -55,16 +63,15 @@ kube-controller-manager 컨테이너에 설정된 시간대는
### 크론 스케줄 문법
```
# ┌────────────────── 타임존 (옵션)
# | ┌───────────── 분 (0 - 59)
# | │ ┌───────────── 시 (0 - 23)
# | │ │ ┌───────────── 일 (1 - 31)
# | │ │ │ ┌───────────── 월 (1 - 12)
# | │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# | │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# | │ │ │ │ │
# | │ │ │ │ │
# CRON_TZ=UTC * * * * *
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
```
@ -78,9 +85,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
`CRON_TZ=UTC 0 0 13 * 5`
`0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
@ -144,6 +151,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
* 크론잡을 생성하고 다루기 위한 지침 및
크론잡 매니페스트의 예제로
[크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
* 실패했거나 완료된 잡을 자동으로 정리하도록 하려면,
[완료된 잡을 자동으로 정리](/ko/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)를 확인한다.
* `CronJob`은 쿠버네티스 REST API의 일부이다.
{{< api-reference page="workload-resources/cron-job-v1" >}}
오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.

39
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -32,7 +32,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
* 디플로이먼트의 PodTemplateSpec을 업데이트해서 [파드의 새로운 상태를 선언한다](#디플로이먼트-업데이트). 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
* 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 [디플로이먼트의 이전 버전으로 롤백](#디플로이먼트-롤백)한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
* [더 많은 로드를 위해 디플로이먼트의 스케일 업](#디플로이먼트-스케일링).
* [디플로이먼트 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 새로운 롤아웃의 시작을 재개한다.
* [디플로이먼트 롤아웃 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
* 롤아웃이 막혀있는지를 나타내는 [디플로이먼트 상태를 이용](#디플로이먼트-상태).
* 더 이상 필요 없는 [이전 레플리카셋 정리](#정책-초기화).
@ -697,12 +697,16 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## 디플로이먼트의 일시 중지와 재개
## 디플로이먼트 롤아웃 일시 중지와 재개 {#pausing-and-resuming-a-deployment}
하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
디플로이먼트를 업데이트할 때 (또는 계획할 때),
하나 이상의 업데이트를 트리거하기 전에 해당 디플로이먼트에 대한 롤아웃을 일시 중지할 수 있다.
변경 사항을 적용할 준비가 되면, 디플로이먼트 롤아웃을 재개한다.
이러한 방법으로, 불필요한 롤아웃을 트리거하지 않고
롤아웃 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
* 예를 들어, 생성된 디플로이먼트의 경우
디플로이먼트 상세 정보를 가져온다.
```shell
kubectl get deploy
@ -753,7 +757,7 @@ nginx-deployment-618515232 11 11 11 7m
REVISION CHANGE-CAUSE
1 <none>
```
* 롤아웃 상태를 가져와서 디플로이먼트 업데이트가 성공적인지 확인한다.
* 기존 레플리카셋이 변경되지 않았는지 확인하기 위해 롤아웃 상태를 출력한다.
```shell
kubectl get rs
```
@ -774,10 +778,10 @@ nginx-deployment-618515232 11 11 11 7m
deployment.apps/nginx-deployment resource requirements updated
```
디플로이먼트를 일시 중지하기 전의 초기 상태는 해당 기능을 지속한다.
그러나 디플로이먼트가 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
디플로이먼트 롤아웃을 일시 중지하기 전 디플로이먼트의 초기 상태는 해당 기능을 지속한다.
그러나 디플로이먼트 롤아웃이 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
* 결국, 디플로이먼트 롤아웃을 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
```shell
kubectl rollout resume deployment/nginx-deployment
```
@ -911,8 +915,8 @@ deployment.apps/nginx-deployment patched
{{< /note >}}
{{< note >}}
만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
만약 디플로이먼트 롤아웃을 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
롤아웃 중에 디플로이먼트 롤아웃을 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
재개할 수 있다.
{{< /note >}}
@ -1052,8 +1056,7 @@ echo $?
`.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
@ -1065,6 +1068,18 @@ echo $?
`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다.
예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로
디플로이먼트의 크기를 수동으로 조정한 뒤,
매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행),
수동으로 설정했던 디플로이먼트의 크기가 오버라이드된다.
[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가
디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
대신, 쿠버네티스
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
`.spec.replicas` 필드를 자동으로 관리한다.
### 셀렉터
`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를

64
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -25,7 +25,8 @@ weight: 50
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든),
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
<!-- body -->
@ -206,6 +207,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된
호스트네임을 사용할 수 있다.
- 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@ -249,7 +251,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
{{< note >}}
만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록
하려면 `restartPolicy = "Never"` 로 설정하는 것을 권장한다.
{{< /note >}}
@ -344,6 +346,25 @@ spec:
삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
후에 TTL 컨트롤러에 의해 정리되지 않는다.
{{< note >}}
`ttlSecondsAfterFinished` 필드를 설정하는 것을 권장하는데,
이는 관리되지 않는 잡(직접 생성한,
크론잡 등 다른 워크로드 API를 통해 간접적으로 생성하지 않은 잡)의
기본 삭제 정책이 `orphanDependents`(관리되지 않는 잡이 완전히 삭제되어도
해당 잡에 의해 생성된 파드를 남겨둠)이기 때문이다.
삭제된 잡의 파드가 실패하거나 완료된 뒤
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 언젠가
[가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)을 한다고 해도,
이렇게 남아 있는 파드는 클러스터의 성능을 저하시키거나
최악의 경우에는 이 성능 저하로 인해 클러스터가 중단될 수도 있다.
[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)와
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여
특정 네임스페이스가 사용할 수 있는 자원량을 제한할 수
있다.
{{< /note >}}
## 잡 패턴
잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다. 잡 오브젝트는 과학
@ -415,8 +436,11 @@ spec:
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
즉시 파드 생성을 시작하고 잡이 완료될 때까지
계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에
다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다.
재개하거나, 잡을 중단 상태로 생성하고 언제 시작할지를
커스텀 컨트롤러가 나중에 결정하도록 하고 싶을 수도 있다.
잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 이후에, 다시 재개하려면, false로 업데이트한다.
`.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로
생성된다.
@ -501,6 +525,32 @@ Events:
파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시
시작되었음을 알 수 있다.
### 가변적 스케줄링 지시
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
이 기능을 사용하려면,
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)에
`JobMutableNodeSchedulingDirectives` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
이 기능은 기본적으로 활성화되어 있다.
{{< /note >}}
병렬 잡에서 대부분의 경우 파드를 특정 제약 조건 하에서 실행하고 싶을 것이다.
(예를 들면 동일 존에서 실행하거나, 또는 GPU 모델 x 또는 y를 사용하지만 둘을 혼합하지는 않는 등)
[suspend](#suspending-a-job) 필드는 이러한 목적을 달성하기 위한 첫 번째 단계이다.
이 필드를 사용하면 커스텀 큐(queue) 컨트롤러가 잡이 언제 시작될지를 결정할 수 있다.
그러나, 잡이 재개된 이후에는, 커스텀 큐 컨트롤러는 잡의 파드가 실제로 어디에 할당되는지에 대해서는 영향을 주지 않는다.
이 기능을 이용하여 잡이 실행되기 전에 잡의 스케줄링 지시를 업데이트할 수 있으며,
이를 통해 커스텀 큐 컨트롤러가 파드 배치에 영향을 줌과 동시에
노드로의 파드 실제 할당 작업을 kube-scheduler로부터 경감시켜 줄 수 있도록 한다.
이는 이전에 재개된 적이 없는 중지된 잡에 대해서만 허용된다.
잡의 파드 템플릿 필드 중, 노드 어피니티(node affinity), 노드 셀렉터(node selector),
톨러레이션(toleration), 레이블(label), 어노테이션(annotation)은 업데이트가 가능하다.
### 자신의 파드 셀렉터를 지정하기
일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다.
@ -570,17 +620,17 @@ spec:
### 종료자(finalizers)를 이용한 잡 추적
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
이 기능을 이용하기 위해서는
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와
[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해
`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
기본적으로는 비활성화되어 있다.
기본적으로는 활성화되어 있다.
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
기존에 존재하던 잡은 영향을 받지 않는다.
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
{{< /note >}}

146
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -1,4 +1,11 @@
---
title: 스테이트풀셋
content_type: concept
weight: 30
@ -67,13 +74,14 @@ metadata:
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
app: nginx # .spec.template.metadata.labels 와 일치해야 한다
serviceName: "nginx"
replicas: 3 # by default is 1
replicas: 3 # 기본값은 1
minReadySeconds: 10 # 기본값은 0
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
app: nginx # .spec.selector.matchLabels 와 일치해야 한다
spec:
terminationGracePeriodSeconds: 10
containers:
@ -105,9 +113,24 @@ spec:
스테이트풀셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
## 파드 셀렉터
### 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
### 볼륨 클레임 템플릿
`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를 제공할 수 있다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
`.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가
문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어
있음에 유의한다. 이 기능을 사용하지 않으려면 StatefulSetMinReadySeconds 플래그를 설정 해제한다.
이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.)
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
## 파드 신원
@ -166,9 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
### 안정된 스토리지
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을
생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@ -279,37 +300,114 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
실행하려고 시도한 모든 파드를 삭제해야 한다.
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
## 퍼시스턴트볼륨클레임 유보
`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록
컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
선택적 필드인 `.spec.persistentVolumeClaimRetentionPolicy` 는
스테이트풀셋의 생애주기동안 PVC를 삭제할 것인지,
삭제한다면 어떻게 삭제하는지를 관리한다.
이 필드를 사용하려면 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
활성화 시, 각 스테이트풀셋에 대해 두 가지 정책을 설정할 수 있다.
`whenDeleted`
: 스테이트풀셋이 삭제될 때 적용될 볼륨 유보 동작을 설정한다.
`whenScaled`
: 스테이트풀셋의 레플리카 수가 줄어들 때, 예를 들면 스테이트풀셋을 스케일 다운할 때
적용될 볼륨 유보 동작을 설정한다.
설정 가능한 각 정책에 대해, 그 값을 `Delete` 또는 `Retain` 으로 설정할 수 있다.
`Delete`
: `volumeClaimTemplate` 스테이트풀셋으로부터 생성된 PVC는 정책에 영향을 받는 각 파드에 대해 삭제된다.
`whenDeleted` 가 이 값으로 설정되어 있으면
`volumeClaimTemplate` 으로부터 생성된 모든 PVC는 파드가 삭제된 뒤에 삭제된다.
`whenScaled` 가 이 값으로 설정되어 있으면
스케일 다운된 파드 레플리카가 삭제된 뒤, 삭제된 파드에 해당되는 PVC만 삭제된다.
`Retain` (기본값)
: 파드가 삭제되어도 `volumeClaimTemplate` 으로부터 생성된 PVC는 영향을 받지 않는다.
이는 이 신기능이 도입되기 전의 기본 동작이다.
이러한 정책은 파드의 삭제가 스테이트풀셋 삭제 또는 스케일 다운으로 인한 것일 때**에만** 적용됨에 유의한다.
예를 들어, 스테이트풀셋의 파드가 노드 실패로 인해 실패했고,
컨트롤 플레인이 대체 파드를 생성했다면, 스테이트풀셋은 기존 PVC를 유지한다.
기존 볼륨은 영향을 받지 않으며,
새 파드가 실행될 노드에 클러스터가 볼륨을 연결(attach)한다.
정책의 기본값은 `Retain` 이며, 이는 이 신기능이 도입되기 전의 스테이트풀셋 기본 동작이다.
다음은 정책 예시이다.
```yaml
apiVersion: apps/v1
kind: StatefulSet
...
spec:
persistentVolumeClaimRetentionPolicy:
whenDeleted: Retain
whenScaled: Delete
...
```
스테이트풀셋 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는 자신이 소유한 PVC에
[소유자 정보(reference)](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)를
추가하며, 파드가 종료된 이후에는 {{<glossary_tooltip text="가비지 콜렉터" term_id="garbage-collection">}}가 이 정보를 삭제한다.
이로 인해 PVC가 삭제되기 전에
(그리고 유보 정책에 따라, 매칭되는 기반 PV와 볼륨이 삭제되기 전에)
파드가 모든 볼륨을 깨끗하게 언마운트할 수 있다.
`whenDeleted` 정책을 `Delete` 로 설정하면,
해당 스테이트풀셋에 연결된 모든 PVC에 스테이트풀셋 인스턴스의 소유자 정보가 기록된다.
`whenScaled` 정책은 파드가 스케일 다운되었을 때에만 PVC를 삭제하며,
파드가 다른 원인으로 삭제되면 PVC를 삭제하지 않는다.
조정 상황 발생 시, 스테이트풀셋 컨트롤러는 목표 레플리카 수와 클러스터 상의 실제 파드 수를 비교한다.
레플리카 카운트보다 큰 ID를 갖는 스테이트풀셋 파드는 부적격 판정을 받으며 삭제 대상으로 표시된다.
`whenScaled` 정책이 `Delete` 이면, 부적격 파드는 삭제되기 전에,
연결된 스테이트풀셋 템플릿 PVC의 소유자로 지정된다.
이로 인해, 부적격 파드가 종료된 이후에만 PVC가 가비지 콜렉트된다.
이는 곧 만약 컨트롤러가 강제 종료되어 재시작되면,
파드의 소유자 정보가 정책에 적합하게 업데이트되기 전에는 어떤 파드도 삭제되지 않을 것임을 의미한다.
만약 컨트롤러가 다운된 동안 부적격 파드가 강제로 삭제되면,
컨트롤러가 강제 종료된 시점에 따라 소유자 정보가 설정되었을 수도 있고 설정되지 않았을 수도 있다.
소유자 정보가 업데이트되기까지 몇 번의 조정 절차가 필요할 수 있으며,
따라서 일부 부적격 파드는 소유자 정보 설정을 완료하고 나머지는 그러지 못했을 수 있다.
이러한 이유로, 컨트롤러가 다시 켜져서 파드를 종료하기 전에
소유자 정보를 검증할 때까지 기다리는 것을 추천한다.
이것이 불가능하다면, 관리자는 PVC의 소유자 정보를 확인하여 파드가 강제 삭제되었을 때 해당되는 오브젝트가 삭제되도록 해야 한다.
### 레플리카
`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 기본값은 1이다.
예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로
디플로이먼트의 크기를 수동으로 조정한 뒤,
매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행),
수동으로 설정했던 디플로이먼트의 크기가
오버라이드된다.
[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가
디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
대신, 쿠버네티스
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
`.spec.replicas` 필드를 자동으로 관리한다.
## {{% heading "whatsnext" %}}
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 스테이트풀셋을 사용하는 방법을 알아본다.
* [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
* [스테이트풀셋으로 카산드라 배포](/ko/docs/tutorials/stateful-application/cassandra/) 예제를 따라한다.
* [복제된 스테이트풀셋 애플리케이션 구동하기](/docs/tasks/run-application/run-replicated-stateful-application/) 예제를 따라한다.
* [스테이트풀셋 확장하기](/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
스테이트풀셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/stateful-set-v1" >}}
오브젝트 정의를 읽는다.
{{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.

53
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
View File

@ -1,51 +1,48 @@
---
title: 완료된 리소스를 위한 TTL 컨트롤러
title: 완료된 잡 자동 정리
content_type: concept
weight: 70
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
이 기능은 현재 베타이고 기본적으로 활성화되어 있다.
kube-apiserver와 kube-controller-manager에서 `TTLAfterFinished`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
완료-이후-TTL(TTL-after-finished) {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는
실행이 완료된 리소스 오브젝트의 수명을 제한하는
TTL (time to live) 메커니즘을 제공한다.
TTL 컨트롤러는 {{< glossary_tooltip text="잡" term_id="job" >}}만을 제어한다.
<!-- body -->
## TTL 컨트롤러
## 완료-이후-TTL 컨트롤러
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
완료-이후-TTL 컨트롤러는 잡만을 지원한다. 클러스터 운영자는
[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다.
TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 이는
의존하는 오브젝트도 해당 리소스와 함께 삭제되는 것을 의미한다. 리소스가 삭제되면 완료자(finalizers)와
잡의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
완료-이후-TTL 컨트롤러는 해당 잡이 정리될 수 있다고 가정한다.
완료-이후-TTL 컨트롤러가 잡을 정리할때 잡을 연속적으로 삭제한다. 이는
의존하는 오브젝트도 해당 잡과 함께 삭제되는 것을 의미한다. 잡이 삭제되면 완료자(finalizers)와
같은 라이프 사이클 보증이 적용 된다.
TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중
`.spec.ttlSecondsAfterFinished` 를 설정하는 몇 가지 예시가 있다.
* 작업이 완료된 다음, 일정 시간 후에 자동으로 잡이 정리될 수 있도록
리소스 메니페스트에 이 필드를 지정한다.
* 이미 완료된 기존 리소스에 이 새 기능을 적용하기 위해서 이 필드를
잡 메니페스트에 이 필드를 지정한다.
* 이미 완료된 기존 잡에 이 새 기능을 적용하기 위해서 이 필드를
설정한다.
* [어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
을 사용해서
리소스 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을
사용해서 완료된 리소스에 대해 TTL 정책을 적용할 수 있다.
* 리소스가 완료된 이후에
잡 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을
사용해서 완료된 잡에 대해 TTL 정책을 적용할 수 있다.
* 잡이 완료된 이후에
[어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
을 사용해서 이 필드를 동적으로 설정하고, 리소스의 상태,
을 사용해서 이 필드를 동적으로 설정하고, 잡의 상태,
레이블 등에 따라 다른 TTL 값을 선택한다.
## 경고
@ -53,21 +50,19 @@ TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중
### TTL 초(sec) 업데이트
TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는
리소스를 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을
잡을 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을
삭제할 수 있게 되면(TTL이 만료된 경우) 시스템은 TTL을 연장하기
위한 업데이트가 성공적인 API 응답을 리턴하더라도
작업이 유지되도록 보장하지 않는다.
### 시간 차이(Skew)
TTL 컨트롤러는 쿠버네티스 리소스에
완료-이후-TTL 컨트롤러는 쿠버네티스 잡에
저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의
시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스
시간 차이에 민감하며, 시간 차이에 의해서 완료-이후-TTL 컨트롤러가 잘못된 시간에 잡
오브젝트를 정리하게 될 수 있다.
쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드
([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다)
에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는
시계가 항상 정확한 것은 아니지만, 그 차이는
아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다.

4
content/ko/docs/concepts/workloads/pods/disruptions.md
View File

@ -128,8 +128,8 @@ Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적
기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여
소유하는 워크로드 리소스를 발견한다.
PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
버짓이 차감된다.
[비자발적 중단](#자발적-중단과-비자발적-중단)은 PDB로는 막을 수 없지만,
버짓은 차감된다.
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는

14
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -1,4 +1,7 @@
---
title: 임시(Ephemeral) 컨테이너
content_type: concept
weight: 80
@ -6,22 +9,13 @@ weight: 80
<!-- overview -->
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
{{< feature-state state="beta" for_k8s_version="v1.23" >}}
이 페이지는 임시 컨테이너에 대한 개요를 제공한다.
이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해
기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다.
임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.
{{< warning >}}
임시 컨테이너 기능은 알파 상태이며,
프로덕션 클러스터에는 적합하지 않다.
[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
{{< /warning >}}
<!-- body -->
## 임시 컨테이너 이해하기

118
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -17,8 +17,8 @@ weight: 30
결정한다.
쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다.
사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에
파드 오브젝트의 상태는 일련의 [파드 컨디션](#파드의-컨디션)으로 구성된다.
사용자의 애플리케이션에 유용한 경우, 파드의 컨디션 데이터에
[사용자 정의 준비성 정보](#pod-readiness-gate)를 삽입할 수도 있다.
파드는 파드의 수명 중 한 번만 [스케줄](/ko/docs/concepts/scheduling-eviction/)된다.
@ -150,26 +150,26 @@ Never이다. 기본값은 Always이다.
컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면,
kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한다.
## 파드의 조건
## 파드의 컨디션
파드는 하나의 PodStatus를 가지며,
그것은 파드가 통과했거나 통과하지 못한 조건에 대한
그것은 파드가 통과했거나 통과하지 못한
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다.
* `PodScheduled`: 파드가 노드에 스케줄되었다.
* `ContainersReady`: 파드의 모든 컨테이너가 준비되었다.
* `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
성공적으로 시작되었다.
성공적으로 완료(completed)되었다.
* `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
밸런싱 풀에 추가되어야 한다.
필드 이름 | 설명
:--------------------|:-----------
`type` | 이 파드 조건의 이름이다.
`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 조건이 적용 가능한지 여부를 나타낸다.
`lastProbeTime` | 파드 조건이 마지막으로 프로브된 시간의 타임스탬프이다.
`type` | 이 파드 컨디션의 이름이다.
`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 컨디션이 적용 가능한지 여부를 나타낸다.
`lastProbeTime` | 파드 컨디션이 마지막으로 프로브된 시간의 타임스탬프이다.
`lastTransitionTime` | 파드가 한 상태에서 다른 상태로 전환된 마지막 시간에 대한 타임스탬프이다.
`reason` | 조건의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다.
`reason` | 컨디션의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다.
`message` | 마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지이다.
@ -179,11 +179,11 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한
애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_
와 같이 주입할 수 있다. 이를 사용하기 위해, kubelet이 파드의 준비성을 평가하기
위한 추가적인 조건들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다.
위한 추가적인 컨디션들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다.
준비성 게이트는 파드에 대한 `status.condition` 필드의 현재
상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는
조건을 찾지 못한다면, 그 조건의 상태는
컨디션을 찾지 못한다면, 그 컨디션의 상태는
기본 값인 "`False`"가 된다.
여기 예제가 있다.
@ -220,70 +220,100 @@ status:
{{< glossary_tooltip term_id="operator-pattern" text="오퍼레이터">}}의
`PATCH` 액션을 필요로 한다.
[쿠버네티스 클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를
사용해서 파드 준비성에 대한 사용자 지정 파드 조건을 설정하는 코드를 작성할 수 있다.
사용해서 파드 준비성에 대한 사용자 지정 파드 컨디션을 설정하는 코드를 작성할 수 있다.
사용자 지정 조건을 사용하는 파드의 경우, 다음 두 조건이 모두 적용되는
사용자 지정 컨디션을 사용하는 파드의 경우, 다음 두 컨디션이 모두 적용되는
경우에 **만** 해당 파드가 준비된 것으로 평가된다.
* 파드 내의 모든 컨테이너들이 준비 상태이다.
* `readinessGates`에 지정된 모든 조건들이 `True` 이다.
* `readinessGates`에 지정된 모든 컨디션들이 `True` 이다.
파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면,
kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정한다.
파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 컨디션이 빠졌거나 `False` 이면,
kubelet은 파드의 [컨디션](#파드의-컨디션)을 `ContainerReady` 로 설정한다.
## 컨테이너 프로브(probe)
[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는
_프로브_ 는
컨테이너에서 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해
주기적으로 수행되는 진단(diagnostic)이다.
진단을 수행하기 위해서,
kubelet은 컨테이너에 의해서 구현된
[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
핸들러에는 다음과 같이 세 가지 타입이 있다.
kubelet은 컨테이너 안에서 코드를 실행하거나,
또는 네트워크 요청을 전송한다.
* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)은
컨테이너 내에서 지정된 명령어를 실행한다.
### 체크 메커니즘 {#probe-check-methods}
프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다.
각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다.
`exec`
: 컨테이너 내에서 지정된 명령어를 실행한다.
명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)은
지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
`grpc`
: [gRPC](https://grpc.io/)를 사용하여
원격 프로시저 호출을 수행한다.
체크 대상이 [gRPC 헬스 체크](https://grpc.io/grpc/core/md_doc_health-checking.html)를 구현해야 한다.
응답의 `status` 가 `SERVING` 이면
진단이 성공했다고 간주한다.
gRPC 프로브는 알파 기능이며
`GRPCContainerProbe` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 사용할 수 있다.
* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)은
지정한 포트 및 경로에서 컨테이너의 IP주소에
대한 HTTP `GET` 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
`httpGet`
: 지정한 포트 및 경로에서 컨테이너의 IP주소에 대한
HTTP `GET` 요청을 수행한다.
응답의 상태 코드가 200 이상 400 미만이면
진단이 성공한 것으로 간주한다.
`tcpSocket`
: 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면,
이 또한 진단이 성공한 것으로 간주한다.
### 프로브 결과
각 probe는 다음 세 가지 결과 중 하나를 가진다.
* `Success`: 컨테이너가 진단을 통과함.
* `Failure`: 컨테이너가 진단에 실패함.
* `Unknown`: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
`Success`
: 컨테이너가 진단을 통과함.
`Failure`
: 컨테이너가 진단에 실패함.
`Unknown`
: 진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이
추가 체크를 수행할 것이다)
### 프로브 종류
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
그에 반응할 수 있다.
* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
`livenessProbe`
: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
[재시작 정책](#restart-policy)의 대상이 된다. 만약 컨테이너가
활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다.
활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success` 이다.
* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
`readinessProbe`
: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를
지원하지 않는다면, 기본 상태는 `Success`이다.
초기 지연 이전의 기본 상태는 `Failure` 이다. 만약 컨테이너가 준비성 프로브를
지원하지 않는다면, 기본 상태는 `Success` 이다.
* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
`startupProbe`
: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는
활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
컨테이너는 [재시작 정책](#restart-policy)에 따라 처리된다. 컨테이너에 스타트업
프로브가 없는 경우, 기본 상태는 `Success`이다.
프로브가 없는 경우, 기본 상태는 `Success` 이다.
활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는,
[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
### 언제 활성 프로브를 사용해야 하는가?
#### 언제 활성 프로브를 사용해야 하는가?
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
@ -295,7 +325,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
### 언제 준비성 프로브를 사용해야 하는가?
#### 언제 준비성 프로브를 사용해야 하는가?
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
@ -329,7 +359,7 @@ failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있
남아 있다.
{{< /note >}}
### 언제 스타트업 프로브를 사용해야 하는가?
#### 언제 스타트업 프로브를 사용해야 하는가?
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
@ -458,6 +488,6 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
* [컨테이너 라이프사이클 훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.
* API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
그리고
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참고한다.
* API의 파드와 컨테이너 상태에 대한 자세한 내용은
파드의 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus)에 대해 다루는
API 레퍼런스 문서를 참고한다.

10
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -234,6 +234,8 @@ graph BT
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
### 예시: TopologySpreadConstraints와 노드 어피니티
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
{{<mermaid>}}
@ -349,12 +351,14 @@ defaultConstraints:
비활성화된다.
{{< note >}}
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
없는 노드에 점수를 매기지 않는다.
이로 인해 기본 토폴로지 제약을 사용하는 경우의
레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
대신 자체 제약 조건을 정의한다.
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
없는 노드에 점수를 매기지 않는다.
{{< /note >}}
클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,

8
content/ko/docs/contribute/advanced.md
View File

@ -13,8 +13,6 @@ weight: 98
이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한
작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다.
<!-- body -->
## 개선 제안
@ -29,8 +27,8 @@ website 스타일, 풀 리퀘스트 리뷰와 병합
프로세스 또는 문서 작성의 다른 측면을 개선하기 위한 아이디어가 있을 수 있다. 투명성을 극대화하려면,
이러한 유형의 제안을 SIG Docs 회의나
[kubernetes-sig-docs 메일링리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 논의해야 한다.
또한, 현재의 작업 방식과 과거의 결정이 왜 획기적인 변경을
제안하기 전에 결정되었는지에 대한 맥락을 이해하는 데 실제로
또한, 획기적인 변경을 제안하기 전에, 현재의 작업 방식과 과거의 결정이
어떻게 정해졌는지에 대한 맥락을 이해하는 데 실제로
도움이 될 수 있다. 현재의 문서 작업이 어떻게 진행되는지에 대한 질문의
답변을 얻는 가장 빠른 방법은 [kubernetes.slack.com](https://kubernetes.slack.com)의
`#sig-docs` 슬랙 채널에 문의하는 것이다.
@ -84,7 +82,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/
새로운 기여자 홍보대사의 책임은 다음과 같다.
- [#sig-docs 슬랙 채널](https://kubernetes.slack.com)에서 새로운 기여자의 질문을 모니터링한다.
- PR 랭글러와 협력하여 새로운 기여자에게 좋은 첫 이슈를 파악한다.
- PR 랭글러와 협력하여 새로운 기여자에게 [좋은 첫 이슈](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue)를 파악한다.
- 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다.
- 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다.
- 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다.

6
content/ko/docs/contribute/new-content/_index.md
View File

@ -56,12 +56,14 @@ prior to submitting new content. The information details follow.
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고
[Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- 쿠버네티스 문서는 마크다운 스펙으로 [CommonMark](https://commonmark.org/)를 사용한다.
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다.
쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다.
일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여
자동으로 생성된다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은
Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
- [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)은
Hugo에서 문서 콘텐츠가 표시되는 방식을 기술한다.
- 쿠버네티스 문서 기여 시 [Docsy shortcodes](https://www.docsy.dev/docs/adding-content/shortcodes/) 또는 [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/)를 사용할 수 있다.
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
[사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여
콘텐츠 표시를 제어한다.

7
content/ko/docs/contribute/participate/pr-wranglers.md
View File

@ -26,9 +26,16 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
- 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
- 관련 `sig/` 레이블을 할당한다.
- 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
- PR에 `@kubernetes/<sig>-pr-reviews` 코멘트를 남겨 [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md)에 리뷰를 요청할 수도 있다.
- PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다.
- 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다.
- [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다.
- [스타일 지침](/docs/contribute/style/style-guide/)을 충족하지 않지만
기술적으로는 정확한 PR은 수락하는 쪽으로 고려한다.
변경 사항을 승인하면, 스타일 이슈에 대한 새 이슈를 연다.
보통 이러한 스타일 수정 이슈는 [좋은 첫 이슈](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue)로 지정할 수 있다.
- 스타일 수정 이슈를 좋은 첫 이슈로 표시하면 비교적 쉬운 작업을 공급하여
새로운 기여자가 참여하는 것을 장려할 수 있다.
### 랭글러를 위해 도움이 되는 GitHub 쿼리

2
content/ko/docs/contribute/review/for-approvers.md
View File

@ -121,7 +121,7 @@ PR에서 사용할 수 있는 명령의 전체 목록을 보려면
`priority/important-longterm` | 6개월 이내에 이 작업을 수행한다.
`priority/backlog` | 무기한 연기할 수 있다. 자원이 있을 때 수행한다.
`priority/awaiting-more-evidence` | 잠재적으로 좋은 이슈에 대해 잊지 않도록 표시한다.
`help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)을 참고한다.
`help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://kubernetes.dev/docs/guide/help-wanted/)을 참고한다.
{{< /table >}}

6
content/ko/docs/reference/_index.md
View File

@ -65,7 +65,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
* [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
* 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
[포트와 프로토콜](/docs/reference/ports-and-protocols/) 리스트
[포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
## API 설정
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
@ -73,10 +73,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
* [kube-apiserver 환경설정 (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/)
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
* [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)

2
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -134,7 +134,7 @@ kubectl auth can-i list secrets --namespace dev --as dave
no
```
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스 어카운트가
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가
`target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.
```bash

90
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -71,20 +71,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigration` | `true` | 베타 | 1.17 | |
| `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
| `CSIMigrationAWS` | `false` | 베타 | 1.17 | |
| `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 |
| `CSIMigrationAWS` | `true` | 베타 | 1.23 | |
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 |
| `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | |
| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 |
| `CSIMigrationGCE` | `true` | 베타 | 1.23 | |
| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | |
| `CSIMigrationRBD` | `false` | 알파 | 1.23 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
| `CSRDuration` | `true` | 베타 | 1.22 | |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
@ -92,6 +95,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
| `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | |
| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 |
| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
@ -108,7 +112,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `EfficientWatchResumption` | `true` | 베타 | 1.21 | |
| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | |
| `EphemeralContainers` | `false` | 알파 | 1.16 | |
| `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 |
| `EphemeralContainers` | `true` | 베타 | 1.23 | |
| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
| `ExpandedDNSConfig` | `false` | 알파 | 1.22 | |
@ -117,25 +122,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 |
| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | |
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `GRPCContainerProbe` | `false` | 알파 | 1.23 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `IdentifyPodOS` | `false` | 알파 | 1.23 | |
| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
| `IndexedJob` | `true` | 베타 | 1.22 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | |
| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | |
| `JobReadyPods` | `false` | 알파 | 1.23 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | 1.22 |
| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
@ -159,7 +163,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | |
| `PodSecurity` | `false` | 알파 | 1.22 | |
| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 |
| `PodSecurity` | `true` | 베타 | 1.23 | |
| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 |
| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
@ -168,6 +173,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
| `QOSReserved` | `false` | 알파 | 1.11 | |
| `ReadWriteOncePod` | `false` | 알파 | 1.22 | |
| `RecoverVolumeExpansionFailure` | `false` | 알파 | 1.23 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
| `RemainingItemCount` | `true` | 베타 | 1.16 | |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
@ -183,22 +189,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | |
| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 |
| `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | |
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
| `SuspendJob` | `true` | 베타 | 1.22 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
| `TTLAfterFinished` | `true` | 베타 | 1.21 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | 1.22 |
| `TopologyAwareHints` | `true` | 베타 | 1.23 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
| `WinDSR` | `false` | 알파 | 1.14 | |
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | |
| `WindowsHostProcessContainers` | `false` | 베타 | 1.23 | |
{{< /table >}}
### GA 또는 사용 중단된 기능을 위한 기능 게이트
@ -227,6 +233,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 |
| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
| `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
@ -257,6 +264,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 |
| `CSIServiceAccountToken` | `true` | GA | 1.22 | |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 |
| `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 |
| `CronJobControllerV2` | `true` | GA | 1.22 | - |
@ -311,6 +321,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 |
| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | 1.22 |
| `GenericEphemeralVolume` | `true` | GA | 1.23 | - |
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
@ -325,8 +338,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 |
| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 |
| `IngressClassNamespacedParams` | `true` | GA | 1.23 | - |
| `Initializers` | `false` | 알파 | 1.7 | 1.13 |
| `Initializers` | - | 사용중단 | 1.14 | - |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 |
| `IPv6DualStack` | `true` | GA | 1.23 | - |
| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
| `KubeletConfigFile` | - | 사용중단 | 1.10 | - |
| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
@ -356,6 +375,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 |
| `PodDisruptionBudget` | `true` | GA | 1.21 | - |
@ -435,6 +455,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
| `Sysctls` | `true` | 베타 | 1.11 | 1.20 |
| `Sysctls` | `true` | GA | 1.21 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
| `TTLAfterFinished` | `true` | 베타 | 1.21 | 1.22 |
| `TTLAfterFinished` | `true` | GA | 1.23 | - |
| `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 |
| `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 |
| `TaintBasedEvictions` | `true` | GA | 1.18 | - |
@ -615,6 +638,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
지원한다. CSIMigration 기능 플래그가 필요하다.
- `CSIMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
클러스터에 CSIMigration 및 CSIMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는
`InTreePluginRBDUnregister` 기능 플래그에 의해
사용 중단되었다.
- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
@ -641,6 +671,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
Portworx CSI 드라이버가 설치 및 설정되어 있어야 하며, kube-controller-manager와 kubelet 환경 설정 내에 `CSIMigrationPortworx=true` 기능 게이트가 활성화되어 있어야 한다.
- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
@ -669,6 +702,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
동일한 컨트롤러의 버전 1이 선택된다.
- `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
`cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다.
- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
확인한다.
@ -758,7 +792,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
[Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을
참조한다.
- `HPAContainerMetrics`: `HorizontalPodAutoscaler`를 활성화하여 대상 파드의
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
- `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
개별 컨테이너 메트릭을 기반으로 확장한다.
- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
`minReplicas` 를 0으로 설정한다.
@ -769,6 +804,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `HyperVContainer`: 윈도우 컨테이너를 위한
[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
기능을 활성화한다.
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다.
쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
@ -792,6 +829,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
비동기 조정을 허용한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의
파드 템플릿에 있는 노드 스케줄링 지시를 업데이트할 수 있게 한다.
- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이
`Ready`인 파드의 수를 추적하는 기능을 활성화한다.
`Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의
[status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus)
필드에 기록된다.
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
잡 컨트롤러는 완료된 파드를 추적하기 위해
@ -851,6 +895,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
[파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
`local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라
CRI 컨테이너 런타임으로부터 수집하도록 설정한다.
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
@ -880,6 +926,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
(현재 메모리만 해당).
- `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를
사용한다.
- `RecoverVolumeExpansionFailure`: 이전에 실패했던 볼륨 확장으로부터 복구할 수 있도록,
사용자가 PVC를 더 작은 크기로 변경할 수 있도록 한다.
[볼륨 확장 시 오류 복구](/ko/docs/concepts/storage/persistent-volumes/#볼륨-확장-시-오류-복구)에서
자세한 사항을 확인한다.
- `RemainingItemCount`: API 서버가
[청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
응답에서 남은 항목 수를 표시하도록 허용한다.

114
content/ko/docs/reference/command-line-tools-reference/kube-proxy.md
View File

File diff suppressed because one or more lines are too long

22
content/ko/docs/reference/glossary/container-runtime-interface.md Normal file
View File

@ -0,0 +1,22 @@
---
title: 컨테이너 런타임 인터페이스(Container Runtime Interface)
id: container-runtime-interface
date: 2022-01-10
full_link: /ko/docs/concepts/architecture/cri/
short_description: >
Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다.
aka:
tags:
- cri
---
Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다.
<!--more-->
쿠버네티스 컨테이너 런타임 인터페이스(CRI)는
[클러스터 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의
통신을 위한 주요 [gRPC](https://grpc.io) 프로토콜을 정의한다.

9
content/ko/docs/reference/glossary/pod-disruption.md
View File

@ -14,6 +14,11 @@ tags:
- operation
---
[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.
[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은
노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.
자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다.
<!--more-->
자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다.
비자발적 중단은 의도하지 않은 것이며,
노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거가 될 수 있다.

5
content/ko/docs/reference/glossary/quantity.md
View File

@ -10,7 +10,7 @@ aka:
tags:
- core-object
---
SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.
[SI](https://en.wikipedia.org/wiki/International_System_of_Units) 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.
<!--more-->
@ -19,9 +19,8 @@ tags:
큰 숫자는 킬로(kilo), 메가(mega), 또는 기가(giga)
단위로 표시할 수 있다.
예를 들어, 숫자 `1.5`는 `1500m`으로, 숫자 `1000`은 `1k`로, `1000000`은
`1M`으로 표시할 수 있다. 또한, 이진 표기법 접미사도 명시 가능하므로,
`1M`으로 표시할 수 있다. 또한, [이진 표기법](https://en.wikipedia.org/wiki/Binary_prefix) 접미사도 명시 가능하므로,
숫자 2048은 `2Ki`로 표기될 수 있다.
허용되는 10진수(10의 거듭 제곱) 단위는 `m` (밀리), `k` (킬로, 의도적인 소문자),

2
content/ko/docs/reference/glossary/secret.md
View File

@ -15,4 +15,4 @@ tags:
<!--more-->
민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 유휴 상태의 [암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)를 포함하여 우발적인 노출 위험을 줄인다. {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}}는 시크릿을 마운트된 볼륨의 파일로 참조하거나, 파드의 이미지를 풀링하는 kubelet이 시크릿을 참조한다. 시크릿은 기밀 데이터에 적합하고 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터에 적합하다.
민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 우발적인 노출 위험을 줄인다. 시크릿 값은 기본적으로 base64 문자열로 인코딩되어 암호화되지 않은 채로 저장되지만, [안전하게 암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)되도록 설정할 수 있다. {{< glossary_tooltip text="파드" term_id="pod" >}}는 볼륨 마운트 내의 파일 형태로 시크릿에 접근하며, 시크릿은 또한 kubelet이 파드를 위해 이미지를 풀링할 때에도 사용될 수 있다. 시크릿은 기밀 데이터를 다루는 용도로 적합하며, [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터를 다루는 용도로 적합하다.

31
content/ko/docs/reference/kubectl/cheatsheet.md
View File

@ -1,5 +1,9 @@
---
title: kubectl 치트 시트
content_type: concept
card:
name: reference
@ -215,7 +219,7 @@ kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정).
# `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다.
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done
```
## 리소스 업데이트
@ -286,10 +290,10 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개
```bash
kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제
kubectl delete pod unwanted --now # 유예 시간 없이 즉시 파드 삭제
kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel --include-uninitialized # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl -n my-ns delete pod,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제
kubectl -n my-ns delete pod,svc --all # my-ns 네임스페이스 내 모든 파드와 서비스 삭제
# awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
```
@ -307,8 +311,7 @@ kubectl logs -f my-pod # 실시간 스트림 파드
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행
kubectl run nginx --image=nginx -n
mynamespace # 특정 네임스페이스에서 nginx 파드 실행
kubectl run nginx --image=nginx -n mynamespace # mynamespace 네임스페이스에서 nginx 파드 1개 실행
kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
--dry-run=client -o yaml > pod.yaml
@ -320,6 +323,24 @@ kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령
kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
```
## 컨테이너로/컨테이너에서 파일과 디렉터리 복사
```bash
kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # 로컬 디렉토리 /tmp/foo_dir 를 현재 네임스페이스의 my-pod 파드 안의 /tmp/bar_dir 로 복사
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # 로컬 파일 /tmp/foo 를 my-pod 파드의 my-container 컨테이너 안의 /tmp/bar 로 복사
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
```
{{< note >}}
`kubectl cp` 명령을 사용하려면 컨테이너 이미지에 'tar' 바이너리가 포함되어 있어야 한다. 'tar'가 없으면, `kubectl cp`는 실패할 것이다.
심볼릭 링크, 와일드카드 확장, 파일 모드 보존과 같은 고급 사용 사례에 대해서는 `kubectl exec` 를 고려해 볼 수 있다.
{{< /note >}}
```bash
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
```
## 디플로이먼트, 서비스와 상호 작용
```bash

1
content/ko/docs/reference/kubectl/overview.md
View File

@ -91,6 +91,7 @@ kubectl [command] [TYPE] [NAME] [flags]
* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
* kubectl 명령에 네임스페이스를 명시하지 않으면
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
이는 클러스터 외부에서 실행되었을 때와는 다른데,

33
content/ko/docs/reference/labels-annotations-taints.md
View File

@ -36,10 +36,9 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블
적용 대상: 네임스페이스
`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어 있으면,
쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다.
레이블의 값은 네임스페이스의 이름으로 적용된다.
({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인)
쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다.
레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다.
레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면
이 레이블이 유용할 수 있다.
@ -63,6 +62,16 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k
이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다.
## kubernetes.io/change-cause {#change-cause}
예시: `kubernetes.io/change-cause=kubectl edit --record deployment foo`
적용 대상: 모든 오브젝트
이 어노테이션은 어떤 오브젝트가 왜 변경되었는지 그 이유를 담는다.
어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다.
## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
예시: `controller.kubernetes.io/pod-deletion-cost=10`
@ -426,3 +435,19 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
참고한다.
## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod}
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다.
파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다.
[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면,
해당 설정이 파드 내의 모든 컨테이너에 적용된다.
## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io}
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/clusters/seccomp/) 튜토리얼에서
seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다.
튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며,
이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다.

222
content/ko/docs/reference/scheduling/config.md
View File

@ -18,8 +18,8 @@ weight: 20
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/))
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
구조에 맞게 파일을 작성하고,
`kube-scheduler --config <filename>`을 실행하여
스케줄링 프로파일을 지정할 수 있다.
@ -78,6 +78,8 @@ clientConnection:
플러그인은 적어도 하나 이상 필요하다.
1. `postBind`: 파드가 바인드된 후 호출되는
정보성 익스텐션 포인트이다.
1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해
플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다.
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.
@ -101,7 +103,7 @@ profiles:
모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데
사용할 수도 있다.
### 스케줄링 플러그인
### 스케줄링 플러그인 {#scheduling-plugins}
기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중
하나 이상을 구현한다.
@ -179,30 +181,6 @@ profiles:
볼륨 제한이 충족될 수 있는지 확인한다.
익스텐션 포인트: `filter`.
다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만
사용할 수 있다.
- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를
선호한다.
Extension points: `score`.
- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를
선호한다.
익스텐션 포인트: `score`.
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
익스텐션 포인트: `score`.
- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라
노드를 필터링하거나 스코어링한다.
익스텐션 포인트: `Filter`, `Score`.
- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에
속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에
분산하는 것을 선호한다.
익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
노드의 우선 순위를 지정한다.
익스텐션 포인트: `score`.
### 여러 프로파일
둘 이상의 프로파일을 실행하도록 `kube-scheduler` 를 구성할 수 있다.
@ -251,6 +229,186 @@ profiles:
단 하나만 가질 수 있기 때문이다.
{{< /note >}}
### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint}
`kubescheduler.config.k8s.io/v1beta3` 부터,
다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나
비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다.
이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다.
`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자.
모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면,
다음과 같은 프로파일 환경 설정을 사용한다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: MyPlugin
```
위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과
동일한 효과를 갖는다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
preScore:
enabled:
- name: MyPlugin
score:
enabled:
- name: MyPlugin
preFilter:
enabled:
- name: MyPlugin
filter:
enabled:
- name: MyPlugin
```
여기서 `multiPoint` 를 사용했을 때의 이점은,
추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때,
새로운 익스텐션에 대해서도 `multiPoint` 환경 설정이 자동으로 활성화될 것이라는 점이다.
`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다.
기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나,
와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다.
다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'MyPlugin'
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다.
그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다.
예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고
각각의 가중치가 `1` 이라고 하자.
이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
score:
enabled:
- name: 'DefaultScore2'
weight: 5
```
이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데,
이는 이 플러그인들이 기본 플러그인이기 때문이다.
그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다.
이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다.
결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다.
`MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다.
1. 명시된 익스텐션 포인트가 먼저 실행되며, 여기에 명시된 환경 설정은 다른 모든 곳에 설정된 내용보다 우선한다.
2. `MultiPoint` 및 플러그인 설정을 통해 수동으로 구성된 플러그인
3. 기본 플러그인 및 기본 플러그인의 기본 설정
위의 우선 순위를 설명하기 위해, 다음과 같은 예시를 가정한다.
| 플러그인 | 익스텐션 포인트 |
|---|---|
|`DefaultQueueSort`|`QueueSort`|
|`CustomQueueSort`|`QueueSort`|
|`DefaultPlugin1`|`Score`, `Filter`|
|`DefaultPlugin2`|`Score`|
|`CustomPlugin1`|`Score`, `Filter`|
|`CustomPlugin2`|`Score`, `Filter`|
이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'CustomQueueSort'
- name: 'CustomPlugin1'
weight: 3
- name: 'CustomPlugin2'
disabled:
- name: 'DefaultQueueSort'
filter:
disabled:
- name: 'DefaultPlugin1'
score:
enabled:
- name: 'DefaultPlugin2'
```
명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다.
명시한 익스텐션 포인트의 우선 순위가 더 높으므로,
이 재정의는 무시되고 로그에만 기록된다.
대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다.
* 커스텀 `queueSort` 플러그인을 활성화하고 기존의 기본 플러그인을 비활성화한다
* `CustomPlugin1` 과 `CustomPlugin2` 플러그인을 활성화하며, 이 플러그인에 연결된 모든 익스텐션 포인트를 위해 이 플러그인들이 먼저 실행된다
* `filter` 에 대해서만 `DefaultPlugin1` 을 비활성화한다
* `score` 에 대해, `DefaultPlugin2` 플러그인이 (심지어 커스텀 플러그인보다도) 가장 먼저 실행되도록 순서를 조정한다
`multiPoint` 필드가 없는 `v1beta3` 이전 버전의 환경 설정에서는, 위의 스니펫을 다음과 같이 표현할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
# 기본 QueueSort 플러그인을 비활성화한다
queueSort:
enabled:
- name: 'CustomQueueSort'
disabled:
- name: 'DefaultQueueSort'
# 커스텀 Filter 플러그인을 활성화한다
filter:
enabled:
- name: 'CustomPlugin1'
- name: 'CustomPlugin2'
- name: 'DefaultPlugin2'
disabled:
- name: 'DefaultPlugin1'
# 커스텀 score 플러그인을 활성화하고 순서를 조정한다
score:
enabled:
- name: 'DefaultPlugin2'
weight: 1
- name: 'DefaultPlugin1'
weight: 3
```
다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과
기존 방법과의 끊김없는 통합을 확인할 수 있다.
## 스케줄러 설정 전환
{{< tabs name="tab_with_md" >}}
@ -284,8 +442,14 @@ profiles:
* v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다.
* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다.
* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port` 가 잘못 설정되면 검증 실패를 유발한다.
{{% /tab %}}
{{% tab name="v1beta2 → v1beta3" %}}
* 세 플러그인의 가중치 기본값이 다음과 같이 증가한다.
* `InterPodAffinity`: 1 에서 2 로
* `NodeAffinity`: 1 에서 2 로
* `TaintToleration`: 1 에서 3 으로
{{% /tab %}}
{{< /tabs >}}
@ -293,5 +457,5 @@ profiles:
* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
* [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
* [kube-scheduler 설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽어보기

94
content/ko/docs/reference/scheduling/policies.md
View File

@ -1,102 +1,20 @@
---
title: 스케줄링 정책
content_type: concept
weight: 10
sitemap:
priority: 0.2 # Scheduling priorities are deprecated
---
<!-- overview -->
스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.
쿠버네티스 v1.23 이전 버전에서는, *단정(predicates)* 및 *우선순위(priorities)* 프로세스를 지정하기 위해 스케줄링 정책을 사용할 수 있다.
예를 들어, `kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>` 명령을 실행하여 스케줄링 정책을 설정할 수 있다.
`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다.
<!-- body -->
## 단정 {#predicates}
다음의 *단정* 은 필터링을 구현한다.
- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는
포트(네트워크 프로토콜 종류)가 있는지 확인한다.
- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다.
- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
리소스(예: CPU 및 메모리)가 있는지 확인한다.
- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지
평가한다.
- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해
파드가 노드에 적합한지 평가한다.
- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와
구성된 제한을 초과하는지 여부를 결정한다.
- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이
노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다.
- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다.
이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와
바인딩되지 않은 PVC 모두에 적용된다.
## 우선순위 {#priorities}
다음의 *우선순위* 는 스코어링을 구현한다.
- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}},
{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는
{{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는
파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다.
- `InterPodAffinityPriority`: 선호된
[파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다.
- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉,
노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가
많을수록 이 정책이 부여하는 순위가 낮아진다.
- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다.
이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된
파드를 맞춘다.
- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.
- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다.
- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가
동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.
- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링
설정에 따라 노드의 우선순위를 지정한다.
이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다.
- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로,
모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을
고려하여 노드의 순위를 조정한다.
- `ImageLocalityPriority`: 해당 파드의
{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된
노드를 선호한다.
- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한
파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한
파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는
서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.
- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다.
- `EvenPodsSpreadPriority`: 선호된
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.
이러한 스케줄링 정책은 쿠버네티스 v1.23 버전부터 지원되지 않는다. 관련된 플래그인 `policy-config-file`, `policy-configmap`, `policy-configmap-namespace`, `use-legacy-policy-config` 플래그도 지원되지 않는다. 대신, 비슷한 효과를 얻기 위해 [스케줄러 구성](/ko/docs/reference/scheduling/config/)을 사용한다.
## {{% heading "whatsnext" %}}
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기
* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기

16
content/ko/docs/reference/tools/_index.md
View File

@ -49,3 +49,19 @@ Kompose의 용도
* 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환
* 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전
* V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환
## Kui
[`Kui`](https://github.com/kubernetes-sigs/kui)는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고
출력으로 그래픽적인 응답을 제공하는 GUI 도구이다.
Kui는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 출력으로 그래픽적인 응답을 제공한다.
Kui는 ASCII 표 대신 정렬 가능한 표를 GUI로 제공한다.
Kui를 사용하면 다음의 작업이 가능하다.
* 자동으로 생성되어 길이가 긴 리소스 이름을 클릭하여 복사할 수 있다.
* `kubectl` 명령을 입력하면 실행되는 모습을 볼 수 있으며, `kubectl` 보다 더 빠른 경우도 있다.
* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여
실행 형상을 워터폴 그림으로 확인한다.
* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다.

4
content/ko/docs/reference/using-api/client-libraries.md
View File

@ -1,5 +1,7 @@
---
title: 클라이언트 라이브러리
content_type: concept
weight: 30
---
@ -35,7 +37,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples)
| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples)
## 커뮤니티에 의해 관리되는 클라이언트 라이브러리
{{% thirdparty-content %}}
@ -70,7 +71,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
| Ruby | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) |
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
| Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |

8
content/ko/docs/reference/using-api/health-checks.md
View File

@ -1,5 +1,7 @@
---
title: 쿠버네티스 API 헬스(health) 엔드포인트
content_type: concept
weight: 50
---
@ -18,11 +20,11 @@ weight: 50
`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
API 서버의 `healthz`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다.
다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.
모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
모든 엔드포인트에 대해, `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.
```shell
@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
{{< feature-state state="alpha" >}}
각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
각 개별 헬스 체크는 HTTP 엔드포인트를 노출하며 개별적으로 체크할 수 있다.
개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

4
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -67,7 +67,7 @@ sudo sysctl --system
자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
## 필수 포트 확인 {#check-required-ports}
[필수 포트들](/docs/reference/ports-and-protocols/)은
[필수 포트들](/ko/docs/reference/ports-and-protocols/)은
쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR
crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요)
```bash
CRICTL_VERSION="v1.17.0"
CRICTL_VERSION="v1.22.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```

4
content/ko/docs/setup/production-environment/tools/kubespray.md
View File

@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:

2
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -998,7 +998,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
쿠버네티스 클러스터 트러블슈팅을 위한 기본
도움말은 이
[섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이
[섹션](/ko/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이
섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다.
로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른
기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야

19
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -1,4 +1,9 @@
---
title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
content_type: concept
weight: 75
@ -155,7 +160,21 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
{{< note >}}
`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면,
파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다).
리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다.
윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을
`windows`로 설정한다.
스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다.
컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면,
[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는
일반적인 쿠버네티스 메카니즘을 사용해야 한다.
`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에,
윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트,
톨러레이션 및 노드 셀렉터가 여전히 필요하다.
{{< /note >}}
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.

112
content/ko/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -214,117 +214,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
## 클러스터에서 실행되는 서비스로 접근
이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은
쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다.
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.
쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/),
[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는
클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을
할 수 없을 것이다.
### 통신을 위한 방식들
클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다.
- 공인 IP를 통해 서비스에 접근.
- 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의
서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다.
- 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며,
인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다.
해당 서비스는 자체적으로 인증을 수행하는가?
- 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면
해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다.
- 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에
접근할 필요는 없다.
- Proxy Verb를 사용하여 서비스, 노드, 파드에 접근.
- 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다.
서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에
접근을 하려고 하거나 debugging을 하려면 이를 사용한다.
- 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다.
- HTTP/HTTPS에서만 동작한다.
- [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다.
- 클러스터 내 노드 또는 파드에서 접근.
- 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다.
해당 셸에서 다른 노드, 파드, 서비스에 연결한다.
- 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는
클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만
다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다.
### 빌트인 서비스 검색
일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다.
`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다.
```shell
kubectl cluster-info
```
결괏값은 다음과 같을 것이다.
```
Kubernetes master is running at https://104.197.5.247
elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
```
이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다.
예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여
`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다.
(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.)
#### 수작업으로 apiserver proxy URL을 구축
위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다.
당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다.
기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다.
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
URL의 네임 부분에 지원되는 양식은 다음과 같다.
* `<service_name>` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다.
* `<service_name>:<port_name>` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
* `https:<service_name>:` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의)
* `https:<service_name>:<port_name>` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다.
##### 예제들
* Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다.
* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다.
```json
{
"cluster_name" : "kubernetes_logging",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 5,
"active_shards" : 5,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5
}
```
### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근
브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만
- 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만,
당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다.
- 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을
구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다.
## 요청 redirect
## redirect 요청하기
redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다.

2
content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md
View File

@ -26,7 +26,7 @@ weight: 70
이 작업은
지원되는 환경이 필요한
[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#nodeport) 서비스 타입을
[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스 타입을
대신 사용할 수 있다.
<!-- lessoncontent -->

4
content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md
View File

@ -70,7 +70,7 @@ jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가
반복하여 출력할 수 있다.
```shell
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
```
@ -80,7 +80,7 @@ sort
명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다.
```shell
kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
```
## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기

12
content/ko/docs/tasks/administer-cluster/access-cluster-services.md
View File

@ -86,7 +86,17 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi
위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다.
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다.
포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 또한, 이름이 지정된 포트와 지정되지 않은 포트 모두에 대해, *port_name* 자리에 포트 번호를 기재할 수도 있다.
기본적으로, API 서버는 서비스로의 프록시를 HTTP로 제공한다. HTTPS를 사용하려면, 서비스 이름 앞에 `https:`를 추가한다.
`http://<쿠버네티스_컨트롤_플레인_주소>/api/v1/namespaces/<네임스페이스_이름>/services/<서비스_이름>/proxy`
URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다.
* `<서비스_이름>` - 기본 포트 또는 이름이 지정되지 않은 포트로 http를 사용하여 프록시
* `<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 http를 사용하여 프록시
* `https:<서비스_이름>:` - 기본 포트 또는 이름이 지정되지 않은 포트로 https를 사용하여 프록시(맨 끝의 콜론에 유의)
* `https:<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 https를 사용하여 프록시
##### 예제

38
content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md
View File

@ -1,38 +0,0 @@
---
title: 토폴로지 인지 힌트 활성화하기
content_type: task
min-kubernetes-server-version: 1.21
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
_토폴로지 인지 힌트_ 는 {{< glossary_tooltip text="엔드포인트슬라이스(EndpointSlices)" term_id="endpoint-slice" >}}에 포함되어 있는
토폴로지 정보를 이용해 토폴로지 인지 라우팅을 가능하게 한다.
이 방법은 트래픽을 해당 트래픽이 시작된 곳과 최대한 근접하도록 라우팅하는데,
이를 통해 비용을 줄이거나 네트워크 성능을 향상시킬 수 있다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
토폴로지 인지 힌트를 활성화하기 위해서는 다음의 필수 구성 요소가 필요하다.
* {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가
iptables 모드 혹은 IPVS 모드로 동작하도록 설정
* 엔드포인트슬라이스가 비활성화되지 않았는지 확인
## 토폴로지 인지 힌트 활성화하기
서비스 토폴로지 힌트를 활성화하기 위해서는 kube-apiserver, kube-controller-manager, kube-proxy에 대해
`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화한다.
```
--feature-gates="TopologyAwareHints=true"
```
## {{% heading "whatsnext" %}}
* 서비스 항목 아래의 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints)를 참고
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 참고

224
content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md
View File

@ -1,224 +0,0 @@
---
title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
content_type: task
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 컨트롤 플레인 노드를 복제할 수 있다. 하지만 이러한 스크립트들은 프로덕션 용도로 사용하기에 적합하지 않으며, 프로젝트의 CI에서만 주로 사용된다.
이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 컨트롤 플레인을 관리하는 방법과 GCE와 함께 사용하기 위해 HA 컨트롤 플레인을 구현하는 방법에 관해 설명한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## HA 호환 클러스터 시작
새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다.
* `MULTIZONE=true` - 서버의 기본 영역(zone)과 다른 영역에서 컨트롤 플레인 kubelet이 제거되지 않도록 한다.
여러 영역에서 컨트롤 플레인 노드를 실행(권장됨)하려는 경우에 필요하다.
* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
true인 경우, Etcd의 리더 복제본에서 읽는다.
이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
선택적으로, 첫 번째 컨트롤 플레인 노드가 생성될 GCE 영역을 지정할 수 있다.
다음 플래그를 설정한다.
* `KUBE_GCE_ZONE=zone` - 첫 번째 컨트롤 플레인 노드가 실행될 영역.
다음 샘플 커맨드는 europe-west1-b GCE 영역에 HA 호환 클러스터를 구성한다.
```shell
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
```
위의 커맨드는 하나의 컨트롤 플레인 노드를 포함하는 클러스터를 생성한다.
그러나 후속 커맨드로 새 컨트롤 플레인 노드를 추가할 수 있다.
## 새 컨트롤 플레인 노드 추가
HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드를 추가할 수 있다.
`kube-up` 스크립트에 다음 플래그를 사용하여 컨트롤 플레인 노드를 추가한다.
* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 컨트롤 플레인 노드의 복제본을
만든다.
* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 실행될 영역.
반드시 다른 컨트롤 플레인 노드가 존재하는 영역과 동일한 지역(region)에 있어야 한다.
HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
설정할 필요는 없다.
다음 샘플 커맨드는 기존 HA 호환 클러스터에서
컨트롤 플레인 노드를 복제한다.
```shell
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
```
## 컨트롤 플레인 노드 제거
다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 컨트롤 플레인 노드를 제거할 수 있다.
* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다.
* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 제거될 영역.
* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 컨트롤 플레인 노드의 이름.
명시하지 않으면, 해당 영역의 모든 복제본이 제거된다.
다음 샘플 커맨드는 기존 HA 클러스터에서 컨트롤 플레인 노드를 제거한다.
```shell
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
```
## 동작에 실패한 컨트롤 플레인 노드 처리
HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면,
클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인
노드를 추가하는 것이 가장 좋다.
다음 샘플 커맨드로 이 과정을 시연한다.
1. 손상된 복제본을 제거한다.
```shell
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
```
<ol start="2"><li>기존 복제본을 대신할 새 노드를 추가한다.</li></ol>
```shell
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
```
## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례
* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안,
해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다.
영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다
(더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된
컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다.
결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도
클러스터의 심각한 장애 상태를 초래한다.
따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은
단일 노드로 구성된 컨트롤 플레인보다도 못하다.
* 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로
Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다.
(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다)
<!-- discussion -->
## 구현 지침
![ha-control-plane](/docs/images/ha-control-plane.svg)
### 개요
위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다.
- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다.
- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다.
- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다.
추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다.
각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다.
* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
### 로드 밸런싱
두 번째 컨트롤 플레인 노드를 배치할 때, 두 개의 복제본에 대한 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
비슷하게 끝에서 두 번째의 컨트롤 플레인 노드를 제거한 후에는 로드 밸런서가 제거되고
해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
### 컨트롤 플레인 서비스와 Kubelet
쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
* 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다.
* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다.
마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다.
### 컨트롤 플레인 노드 인증서
쿠버네티스는 각 컨트롤 플레인 노드의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 TLS 인증서를 발급한다.
컨트롤 플레인 노드의 임시 퍼블릭 IP 주소에 대한 인증서는 없다.
임시 퍼블릭 IP 주소를 통해 컨트롤 플레인 노드에 접근하려면, TLS 검증을 건너뛰어야 한다.
### 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)

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` 필드에 대해 읽어보기

124
content/ko/docs/tasks/debug-application-cluster/debug-cluster.md Normal file
View File

@ -0,0 +1,124 @@
---
title: 클러스터 트러블슈팅
content_type: concept
---
<!-- overview -->
이 문서는 클러스터 트러블슈팅에 대해 설명한다. 사용자가 겪고 있는 문제의 근본 원인으로서 사용자의 애플리케이션을
이미 배제했다고 가정한다.
애플리케이션 디버깅에 대한 팁은 [애플리케이션 트러블슈팅 가이드](/docs/tasks/debug-application-cluster/debug-application/)를 참조한다.
자세한 내용은 [트러블슈팅 문서](/ko/docs/tasks/debug-application-cluster/troubleshooting/)를 참조한다.
<!-- body -->
## 클러스터 나열하기
클러스터에서 가장 먼저 디버그해야 할 것은 노드가 모두 올바르게 등록되었는지 여부이다.
다음을 실행한다.
```shell
kubectl get nodes
```
그리고 보일 것으로 예상되는 모든 노드가 존재하고 모두 `Ready` 상태인지 확인한다.
클러스터의 전반적인 상태에 대한 자세한 정보를 얻으려면 다음을 실행할 수 있다.
```shell
kubectl cluster-info dump
```
## 로그 보기
현재로서는 클러스터를 더 깊이 파고들려면 관련 머신에서 로그 확인이 필요하다. 관련 로그 파일
위치는 다음과 같다. (systemd 기반 시스템에서는 `journalctl`을 대신 사용해야 할 수도 있다.)
### 마스터
* `/var/log/kube-apiserver.log` - API 서버, API 제공을 담당
* `/var/log/kube-scheduler.log` - 스케줄러, 스케줄 결정을 담당
* `/var/log/kube-controller-manager.log` - 레플리케이션 컨트롤러를 담당하는 컨트롤러
### 워커 노드
* `/var/log/kubelet.log` - Kubelet, 노드에서 컨테이너 실행을 담당
* `/var/log/kube-proxy.log` - Kube Proxy, 서비스 로드밸런싱을 담당
## 클러스터 장애 모드의 일반적인 개요
아래에 일부 오류 상황 예시 및 문제를 완화하기 위해 클러스터 설정을 조정하는 방법을 나열한다.
### 근본 원인
- VM(들) 종료
- 클러스터 내 또는 클러스터와 사용자 간의 네트워크 분할
- 쿠버네티스 소프트웨어의 충돌
- 데이터 손실 또는 퍼시스턴트 스토리지 사용 불가 (e.g. GCE PD 또는 AWS EBS 볼륨)
- 운영자 오류, 예를 들면 잘못 구성된 쿠버네티스 소프트웨어 또는 애플리케이션 소프트웨어
### 특정 시나리오
- API 서버 VM 종료 또는 API 서버 충돌
- 다음의 현상을 유발함
- 새로운 파드, 서비스, 레플리케이션 컨트롤러를 중지, 업데이트 또는 시작할 수 없다.
- 쿠버네티스 API에 의존하지 않는 기존 파드 및 서비스는 계속 정상적으로 작동할 것이다.
- API 서버 백업 스토리지 손실
- 다음의 현상을 유발함
- API 서버가 구동되지 않을 것이다.
- kubelet에 도달할 수 없게 되지만, kubelet이 여전히 동일한 파드를 계속 실행하고 동일한 서비스 프록시를 제공할 것이다.
- API 서버를 재시작하기 전에, 수동으로 복구하거나 API서버 상태를 재생성해야 한다.
- 지원 서비스 (노드 컨트롤러, 레플리케이션 컨트롤러 매니저, 스케쥴러 등) VM 종료 또는 충돌
- 현재 그것들은 API 서버와 같은 위치에 있기 때문에 API 서버와 비슷한 상황을 겪을 것이다.
- 미래에는 이들도 복제본을 가질 것이며 API서버와 별도로 배치될 수도 있다.
- 지원 서비스들은 상태(persistent state)를 자체적으로 유지하지는 않는다.
- 개별 노드 (VM 또는 물리적 머신) 종료
- 다음의 현상을 유발함
- 해당 노드의 파드가 실행을 중지
- 네트워크 분할
- 다음의 현상을 유발함
- 파티션 A는 파티션 B의 노드가 다운되었다고 생각한다. 파티션 B는 API 서버가 다운되었다고 생각한다. (마스터 VM이 파티션 A에 있다고 가정)
- Kubelet 소프트웨어 오류
- 다음의 현상을 유발함
- 충돌한 kubelet은 노드에서 새 파드를 시작할 수 없다.
- kubelet이 파드를 삭제할 수도 있고 삭제하지 않을 수도 있다.
- 노드는 비정상으로 표시된다.
- 레플리케이션 컨트롤러는 다른 곳에서 새 파드를 시작한다.
- 클러스터 운영자 오류
- 다음의 현상을 유발함
- 파드, 서비스 등의 손실
- API 서버 백업 저장소 분실
- API를 읽을 수 없는 사용자
- 기타
### 완화
- 조치: IaaS VM을 위한 IaaS 공급자의 자동 VM 다시 시작 기능을 사용한다.
- 다음을 완화할 수 있음: API 서버 VM 종료 또는 API 서버 충돌
- 다음을 완화할 수 있음: 지원 서비스 VM 종료 또는 충돌
- 조치: API 서버+etcd가 있는 VM에 IaaS 제공자의 안정적인 스토리지(예: GCE PD 또는 AWS EBS 볼륨)를 사용한다.
- 다음을 완화할 수 있음: API 서버 백업 스토리지 손실
- 조치: [고가용성](/docs/setup/production-environment/tools/kubeadm/high-availability/) 구성을 사용한다.
- 다음을 완화할 수 있음: 컨트롤 플레인 노드 종료 또는 컨트롤 플레인 구성 요소(스케줄러, API 서버, 컨트롤러 매니저) 충돌
- 동시에 발생하는 하나 이상의 노드 또는 구성 요소 오류를 허용한다.
- 다음을 완화할 수 있음: API 서버 백업 스토리지(i.e., etcd의 데이터 디렉터리) 손실
- 고가용성 etcd 구성을 사용하고 있다고 가정
- 조치: API 서버 PD/EBS 볼륨의 주기적인 스냅샷
- 다음을 완화할 수 있음: API 서버 백업 스토리지 손실
- 다음을 완화할 수 있음: 일부 운영자 오류 사례
- 다음을 완화할 수 있음: 일부 쿠버네티스 소프트웨어 오류 사례
- 조치: 파드 앞에 레플리케이션 컨트롤러와 서비스 사용
- 다음을 완화할 수 있음: 노드 종료
- 다음을 완화할 수 있음: Kubelet 소프트웨어 오류
- 조치: 예기치 않은 재시작을 허용하도록 설계된 애플리케이션(컨테이너)
- 다음을 완화할 수 있음: 노드 종료
- 다음을 완화할 수 있음: Kubelet 소프트웨어 오류

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).

107
content/ko/docs/tasks/debug-application-cluster/troubleshooting.md Normal file
View File

@ -0,0 +1,107 @@
---
content_type: concept
title: 트러블슈팅하기
---
<!-- overview -->
때때로 문제가 발생할 수 있다. 이 가이드는 이러한 상황을 해결하기 위해 작성되었다. 문제 해결에는
다음 두 가지를 참고해 볼 수 있다.
* [애플리케이션 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-application/) - 쿠버네티스에
코드를 배포하였지만 제대로 동작하지 않는 사용자들에게 유용한 가이드이다.
* [클러스터 트러블슈팅하기](/ko/docs/tasks/debug-application-cluster/debug-cluster/) - 쿠버네티스 클러스터에
문제를 겪고 있는 클러스터 관리자 혹은 기분이 나쁜 사람들에게 유용한 가이드이다.
여러분이 현재 사용중인 릴리스에 대한 알려진 이슈들을 다음의 [릴리스](https://github.com/kubernetes/kubernetes/releases)
페이지에서 확인해 볼 수도 있다.
<!-- body -->
## 도움 받기
여러분의 문제가 위에 소개된 어떠한 가이드로도 해결할 수 없다면,
쿠버네티스 커뮤니티로부터 도움을 받을 수 있는 다양한 방법들을 시도해 볼 수 있다.
### 질문
이 사이트의 문서들은 다양한 질문들에 대한 답변을 제공할 수 있도록 구성되어 있다.
[개념](/ko/docs/concepts/)은 쿠버네티스의 아키텍처와 각 컴포넌트들이 어떻게 동작하는지에 대해 설명하고,
[시작하기](/ko/docs/setup/)는 쿠버네티스를 시작하는 데 유용한 지침들을 제공한다.
[태스크](/ko/docs/tasks/)는 흔히 사용되는 작업들을 수행하는 방법에 대해 소개하고,
[튜토리얼](/ko/docs/tutorials/)은 실무, 산업 특화 혹은 종단간 개발에 특화된 시나리오를 통해 차근차근 설명한다.
[레퍼런스](/ko/docs/reference/) 섹션에서는
[쿠버네티스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)와
[`kubectl`](/ko/docs/reference/kubectl/overview/)과 같은 커맨드 라인 인터페이스(CLI)에 대한
상세한 설명을 다룬다.
## 도와주세요! 내 질문이 다뤄지지 않았어요! 도움이 필요해요!
### 스택 오버플로우
여러분들이 겪고 있는 문제와 동일한 문제에 대한 도움을 위해 커뮤니티의 다른 사람들이 이미
질문을 올렸을 수 있다. 쿠버네티스 팀은
[쿠버네티스 태그가 등록된 글](https://stackoverflow.com/questions/tagged/kubernetes)들을 모니터링하고 있다.
발생한 문제와 도움이 되는 질문이 없다면,
[새로운 질문](https://stackoverflow.com/questions/ask?tags=kubernetes)을 올려라!
### 슬랙
쿠버네티스 슬랙의 `#kubernetes-users` 채널을 통해 쿠버네티스 커뮤니티의 여러 사람들을 접할 수도 있다.
쿠버네티스 슬랙을 사용하기 위해서는 등록이 필요한데, 다음을 통해 [채널 초대 요청](https://slack.kubernetes.io)을 할 수 있다.
(누구나 가입할 수 있다). 슬랙 채널은 여러분이 어떠한 질문을 할 수 있도록 언제나 열려있다.
가입하고 나면 여러분의 웹 브라우저나 슬랙 앱을 통해 [쿠버네티스 슬랙](https://kubernetes.slack.com)
에 참여할 수 있다.
쿠버네티스 슬랙에 참여하게 된다면, 다양한 주제의 흥미와 관련된 여러 채널들에 대해
살펴본다. 가령, 쿠버네티스를 처음 접하는 사람이라면
[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) 채널에 가입할 수 있다. 혹은, 만약 당신이 개발자라면
[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev) 채널에 가입할 수 있다.
또한 각 국가 및 사용 언어별 채널들이 여럿 존재한다. 사용하는 언어로 도움을 받거나 정보를
얻기 위해서는 다음의 채널에 참가한다.
{{< table caption="국가 / 언어별 슬랙 채널" >}}
국가 | 채널
:---------|:------------
China(중국) | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events)
Finland(핀란드) | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users)
France(프랑스) | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events)
Germany(독일) | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events)
India(인도) | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events)
Italy(이탈리아) | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events)
Japan(일본) | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events)
Korea(한국) | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users)
Netherlands(네덜란드) | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users)
Norway(노르웨이) | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users)
Poland(폴란드) | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users)
Russia(러시아) | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users)
Spain(스페인) | [`#es-users`](https://kubernetes.slack.com/messages/es-users)
Sweden(스웨덴) | [`#se-users`](https://kubernetes.slack.com/messages/se-users)
Turkey(터키) | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events)
{{< /table >}}
### 포럼
공식 쿠버네티스 포럼에 참여하는 것도 추천되는 방법이다. [discuss.kubernetes.io](https://discuss.kubernetes.io).
### 버그와 기능 추가 요청
만약 여러분이 버그처럼 보이는 것을 발견했거나, 기능 추가 요청을 하기 위해서는
[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 사용한다.
이슈를 작성하기 전에는, 여러분의 이슈가 기존 이슈에서 이미
다뤄졌는지 검색해 본다.
버그를 보고하는 경우에는, 해당 문제를 어떻게 재현할 수 있는지에 관련된 상세한 정보를 포함한다.
포함되어야 하는 정보들은 다음과 같다.
* 쿠버네티스 버전: `kubectl version`
* 클라우드 프로바이더, OS 배포판, 네트워크 구성, 및 도커 버전
* 문제를 재현하기 위한 절차

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 -->

160
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

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

@ -3,41 +3,59 @@
title: Horizontal Pod Autoscaler
title: Horizontal Pod Autoscaling
feature:
title: Horizontal 스케일링
description: >
간단한 명령어나 UI를 통해서 또는 CPU 사용량에 따라 자동으로 애플리케이션의 스케일을 업 또는 다운한다.
content_type: concept
weight: 90
---
<!-- overview -->
Horizontal Pod Autoscaler는 CPU 사용량
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다.
쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예:
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며,
워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다.
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
수평 스케일링은 부하 증가에 대해
{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다.
이는 _수직_ 스케일링(쿠버네티스에서는,
해당 워크로드를 위해 이미 실행 중인 파드에
더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.
부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우,
HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋,
또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.
Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예:
{{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다.
HorizontalPodAutoscaler는 쿠버네티스 API 자원 및
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다.
HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다.
쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률,
또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해
목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다.
Horizontal Pod Autoscaling을 활용하는
[연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)가 존재한다.
<!-- body -->
## Horizontal Pod Autoscaler는 어떻게 작동하는가?
## HorizontalPodAutoscaler는 어떻게 작동하는가?
![Horizontal Pod Autoscaler 다이어그램](/images/docs/horizontal-pod-autoscaler.svg)
{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}}
Horizontal Pod Autoscaler는 컨트롤러
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
쿠버네티스는 Horizontal Pod Autoscaling을
간헐적으로(intermittently) 실행되는
컨트롤 루프 형태로 구현했다(지숙적인 프로세스가 아니다).
실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의
`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다).
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
각 주기마다, 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
메트릭 API(파드 단위 리소스 메트릭 용)
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
@ -45,7 +63,8 @@ Horizontal Pod Autoscaler는 컨트롤러
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을
퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
@ -54,32 +73,36 @@ Horizontal Pod Autoscaler는 컨트롤러
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
섹션을 참조하기 바란다.
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) 섹션을 참조하기 바란다.
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2` API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다.
HorizontalPodAutoscaler를 사용하는 일반적인 방법은
{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`,
`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다.
`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며,
Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는
[Metrics Server](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참고한다.
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다.
[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를
확인할 수 있다.
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
하위 리소스 스케일에 대한 자세한 내용은
[여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다.
HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는
워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다.
이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며,
이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다.
쿠버네티스 API의 하위 리소스에 대한 일반적인 정보는 [쿠버네티스 API 개념](/docs/reference/using-api/api-concepts/)에서 확인할 수 있다.
### 알고리즘 세부 정보
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는
가장 기본적인 관점에서, HorizontalPodAutoscaler 컨트롤러는
원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로
작동한다.
@ -90,28 +113,30 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이
`100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가
된다. 만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로
복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는
복제본 수를 반으로 줄일 것이다. 컨트롤 플레인은 비율이 1.0(기본값이 0.1인
`-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여
전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
`targetAverageValue` 또는 `targetAverageUtilization`가 지정되면,
`currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표
안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.
허용치를 확인하고 최종 값을 결정하기 전에, 파드
준비 상태와 누락된 메트릭을 고려한다.
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료
중인 파드) 및 실패한 파드는 모두 폐기된다.
허용치를 확인하고 최종 값을 결정하기 전에,
컨트롤 플레인은 누락된 메트릭이 있는지,
그리고 몇 개의 파드가 [`Ready`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)인지도 고려한다.
삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면
셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는
버려진다.
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와
같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히
초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기
CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히
초기화중이거나, unhealthy하여서) *또는* 파드의 최신 메트릭 포인트가 준비되기
전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
@ -124,20 +149,21 @@ CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
누락된 메트릭이 있는 경우, 컨트롤 플레인은 파드가 스케일 다운의 경우
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
스케일의 크기를 약화시킨다.
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나
아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우,
컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
비율을 다시 계산한다. 새 비율이 스케일 방향을
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
비율을 사용하여 스케일한다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에,
컨트롤러가 사용률을 다시 계산한다.
새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면,
컨트롤러가 스케일링을 건너뛴다.
그렇지 않으면, 새로 계산한 사용률를 이용하여 파드 수 변경 결정을 내린다.
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
@ -161,32 +187,25 @@ HPA가 여전히 확장할 수 있음을 의미한다.
## API 오브젝트
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
`autoscaling/v1` API 버전에서 찾을 수 있다.
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
Horizontal Pod Autoscaler는
쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
현재의 안정 버전은 `autoscaling/v2` API 버전이며,
메모리와 커스텀 메트릭에 대한 스케일링을 지원한다.
`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는
어노테이션으로 보존된다.
HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)에서 찾을 수 있다.
## 워크로드 스케일링의 안정성 {#flapping}
## kubectl에서 Horizontal Pod Autoscaler 지원
HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때,
측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다.
이는 종종 *thrashing* 또는 *flapping*이라고 불린다.
이는 사이버네틱스 분야의 *이력 현상(hysteresis)* 개념과 비슷하다.
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
`kubectl autoscale`에 대한 자세한 문서는 [여기](/docs/reference/generated/kubectl/kubectl-commands/#autoscale)에서 찾을 수 있다.
## 롤링 업데이트 중 오토스케일링
@ -203,31 +222,6 @@ HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
레플리카셋과 같은 중간 리소스가 없다).
## 쿨-다운 / 지연에 대한 지원
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로
노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
안정화되기까지의 시간 간격을 지정한다.
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다.
{{< note >}}
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
있다.
{{< /note >}}
## 리소스 메트릭 지원
모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
@ -260,7 +254,7 @@ resource:
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
HorizontalPodAutoscaler API는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
@ -272,6 +266,7 @@ resource:
해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
메트릭 소스를 정의한다.
```yaml
type: ContainerResource
containerResource:
@ -297,27 +292,31 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는
이전 컨테이너 이름을 제거하여 정리한다.
{{< /note >}}
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod
Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다.
제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
## 사용자 정의 메트릭을 이용하는 스케일링
## 사용자 정의 메트릭을 위한 지원
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
{{< note >}}
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
{{< /note >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
`autoscaling/v2beta2` API 버전을 사용하는 경우,
(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은)
커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다.
이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회한다.
요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
## 복수의 메트릭을 이용하는 스케일링
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
`autoscaling/v2beta2` API 버전을 사용하는 경우,
HorizontalPodAutoscaler가 스케일링에 사용할 복수의 메트릭을 설정할 수 있다.
이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다.
HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를
조정한다(이 값이 이전에 설정한 '총 최대값(overall maximum)'보다는 크지 않을 때에만).
## 메트릭 API를 위한 지원
@ -332,8 +331,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
클러스터 애드온으로 시작할 수 있다.
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다.
메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다.
직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다.
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
@ -345,16 +343,21 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과
[외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다.
## 구성가능한 스케일링 동작 지원
## 구성가능한 스케일링 동작
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면,
`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를
사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있다.
각 방향에 대한 동작은 `behavior` 필드 아래의
`scaleUp` / `scaleDown`를 설정하여 지정할 수 있다.
_안정화 윈도우_ 를 명시하여 스케일링 목적물의
레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시
레플리카 수 변화 속도를 조절할 수도 있다.
### 스케일링 정책
@ -391,23 +394,29 @@ behavior:
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
비활성화 된다.
비활성화된다.
### 안정화 윈도우
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때
레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다.
오토스케일링 알고리즘은 이전의 목표 상태를 추론하고
워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다.
예를 들어, 다음 예제 스니펫에서, `scaleDown`에 대해 안정화 윈도우가 설정되었다.
```yaml
scaleDown:
behavior:
scaleDown:
stabilizationWindowSeconds: 300
```
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우,
알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다.
위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다.
이를 통해 동적 최대값(rolling maximum)을 근사화하여,
스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다.
### 기본 동작
@ -453,7 +462,7 @@ behavior:
stabilizationWindowSeconds: 60
```
### 예시: 스케일 다운 비율 제한
### 예시: 스케일 다운 속도 제한
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
다음 동작이 HPA에 추가된다.
@ -467,9 +476,7 @@ behavior:
periodSeconds: 60
```
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
전략을 추가할 수 있다.
분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소
정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
@ -497,6 +504,18 @@ behavior:
selectPolicy: Disabled
```
## kubectl의 HorizontalPodAutoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
## 암시적 유지 관리 모드 비활성화
HPA 구성 자체를 변경할 필요없이 대상에 대한
@ -506,9 +525,54 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
다시 활성화할 때까지 HPA는 대상 조정을
중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).
### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기
HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의
{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서
`spec.replicas`의 값을 삭제하는 것이 바람직하다.
이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로)
오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를
`spec.replicas`에 기재된 값으로 조정할 것이다.
이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다.
`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데,
이는 이 키의 기본값이 1이기 때문이다(레퍼런스:
[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)).
값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다.
이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다.
이러한 1회성 저하를 방지하는 방법이 존재하며,
디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다.
{{< tabs name="fix_replicas_instructions" >}}
{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}}
1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>`
2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이
업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다.
3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다.
소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록
변경 사항을 커밋하고 추가 필요 단계를 수행한다.
4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다.
{{% /tab %}}
{{% tab name="서버 쪽에 적용하기" %}}
[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면,
정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership)
가이드라인을 참조한다.
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은
클러스터 수준의 오토스케일러 사용을 고려해 볼 수 있다.
* 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
* kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.
HorizontalPodAutoscaler에 대한 더 많은 정보는 아래를 참고한다.
* horizontal pod autoscaling에 대한 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 확인한다.
* [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 문서를 확인한다.
* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면,
[샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
* HorizontalPodAutoscaler [API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)를 확인한다.

100
content/ko/docs/tasks/run-application/scale-stateful-set.md Normal file
View File

@ -0,0 +1,100 @@
---
title: 스테이트풀셋(StatefulSet) 확장하기
content_type: task
weight: 50
---
<!-- overview -->
이 작업은 스테이트풀셋을 확장하는 방법을 보여준다. 스테이트풀셋 확장은 레플리카 수를 늘리거나 줄이는 것을 의미한다.
## {{% heading "prerequisites" %}}
* 스테이트풀셋은 쿠버네티스 버전 1.5 이상에서만 사용할 수 있다.
쿠버네티스 버전을 확인하려면 `kubectl version`을 실행한다.
* 모든 스테이트풀 애플리케이션이 제대로 확장되는 것은 아니다. 스테이트풀셋을 확장할지 여부가 확실하지 않은 경우에 자세한 내용은 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 또는 [스테이트풀셋 튜토리얼](/ko/docs/tutorials/stateful-application/basic-stateful-set/)을 참조한다.
* 스테이트풀 애플리케이션 클러스터가 완전히 정상이라고 확신할 때만
확장을 수행해야 한다.
<!-- steps -->
## 스테이트풀셋 확장하기
### kubectl을 사용하여 스테이트풀셋 확장
먼저 확장하려는 스테이트풀셋을 찾는다.
```shell
kubectl get statefulsets <stateful-set-name>
```
스테이트풀셋의 레플리카 수를 변경한다.
```shell
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
```
### 스테이트풀셋 인플레이스(in-place) 업데이트
대안으로 스테이트풀셋에 [인플레이스 업데이트](/ko/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)를 수행할 수 있다.
스테이트풀셋이 처음에 `kubectl apply`로 생성된 경우,
스테이트풀셋 매니페스트의 `.spec.replicas`를 업데이트한 다음 `kubectl apply`를 수행한다.
```shell
kubectl apply -f <stateful-set-file-updated>
```
그렇지 않으면 `kubectl edit`로 해당 필드를 편집한다.
```shell
kubectl edit statefulsets <stateful-set-name>
```
또는 `kubectl patch`를 사용한다.
```shell
kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}'
```
## 트러블슈팅
### 축소가 제대로 작동하지 않음
스테이트풀셋에서 관리하는 스테이트풀 파드가 비정상인 경우에는 스테이트풀셋을 축소할 수 없다. 축소는
스테이트풀 파드가 실행되고 준비된 후에만 발생한다.
spec.replicas > 1인 경우 쿠버네티스는 비정상 파드의 원인을 결정할 수 없다. 영구적인 오류 또는 일시적인 오류의 결과일 수 있다. 일시적인 오류는 업그레이드 또는 유지 관리에 필요한 재시작으로 인해 발생할 수 있다.
영구적인 오류로 인해 파드가 비정상인 경우
오류를 수정하지 않고 확장하면 스테이트풀셋 멤버십이 올바르게 작동하는 데 필요한
특정 최소 레플리카 수 아래로 떨어지는 상태로 이어질 수 있다.
이로 인해 스테이트풀셋을 사용할 수 없게 될 수 있다.
일시적인 오류로 인해 파드가 비정상 상태이고 파드를 다시 사용할 수 있게 되면
일시적인 오류가 확장 또는 축소 작업을 방해할 수 있다. 일부 분산
데이터베이스에는 노드가 동시에 가입 및 탈퇴할 때 문제가 있다. 이러한 경우
애플리케이션 수준에서 확장 작업에 대해 추론하고 스테이트풀 애플리케이션 클러스터가
완전히 정상이라고 확신할 때만 확장을 수행하는 것이 좋다.
## {{% heading "whatsnext" %}}
* [스테이트풀셋 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기

20
content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -1,6 +1,10 @@
---
title: 클러스터에서 TLS 인증서 관리
content_type: task
---
<!-- overview -->
@ -158,9 +162,19 @@ Events: <none>
## 인증서 서명 요청 승인 받기
인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나
클러스터 관리자에 의해 일회성으로 수행한다. 여기에
관련된 내용에 대한 자세한 내용은 아래에서 설명한다.
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은
자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다.
인증서 요청 승인 권한을 갖고 있다면,
`kubectl`을 이용하여 다음과 같이 수동으로 승인할 수 있다.
```shell
kubectl certificate approve my-svc.my-namespace
```
```none
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
```
## 인증서 다운로드 및 사용

23
content/ko/docs/tasks/tools/included/optional-kubectl-configs-pwsh.md Normal file
View File

@ -0,0 +1,23 @@
---
title: "PowerShell 자동 완성"
description: "PowerShell 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다."
headless: true
---
PowerShell용 kubectl 자동 완성 스크립트는 `kubectl completion powershell` 명령으로 생성할 수 있다.
모든 셸 세션에서 사용하려면, `$PROFILE` 파일에 다음을 추가한다.
```powershell
kubectl completion powershell | Out-String | Invoke-Expression
```
이 명령은 PowerShell을 실행할 때마다 자동 완성 스크립트를 재생성한다. 아니면, 생성된 스크립트를 `$PROFILE` 파일에 직접 추가할 수도 있다.
생성된 스크립트를 `$PROFILE` 파일에 직접 추가하려면, PowerShell 프롬프트에서 다음 명령줄을 실행한다.
```powershell
kubectl completion powershell >> $PROFILE
```
셸을 다시 불러오면, kubectl 자동 완성이 동작할 것이다.

2
content/ko/docs/tasks/tools/install-kubectl-linux.md
View File

@ -176,7 +176,7 @@ kubectl version --client
### 셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.

2
content/ko/docs/tasks/tools/install-kubectl-macos.md
View File

@ -159,7 +159,7 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
### 셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.

7
content/ko/docs/tasks/tools/install-kubectl-windows.md
View File

@ -22,7 +22,6 @@ card:
- [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows)
- [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop)
### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows}
1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다.
@ -134,11 +133,11 @@ card:
### 셸 자동 완성 활성화
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
다음은 Zsh에 대한 자동 완성을 설정하는 절차이다.
다음은 PowerShell에 대한 자동 완성을 설정하는 절차이다.
{{< include "included/optional-kubectl-configs-zsh.md" >}}
{{< include "included/optional-kubectl-configs-pwsh.md" >}}
### `kubectl convert` 플러그인 설치

6
content/ko/docs/tutorials/_index.md
View File

@ -52,10 +52,16 @@ content_type: concept
* [AppArmor](/ko/docs/tutorials/clusters/apparmor/)
* [seccomp](/docs/tutorials/clusters/seccomp/)
## 서비스
* [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/)
## 보안
* [파드 보안 표준을 클러스터 수준으로 적용하기](/docs/tutorials/security/cluster-level-pss/)
* [파드 보안 표준을 네임스페이스 수준으로 적용하기](/docs/tutorials/security/ns-level-pss/)
## {{% heading "whatsnext" %}}
튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는

4
content/ko/docs/tutorials/clusters/apparmor.md
View File

@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor
proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다.
```shell
kubectl exec hello-apparmor cat /proc/1/attr/current
kubectl exec hello-apparmor -- cat /proc/1/attr/current
```
```
k8s-apparmor-example-deny-write (enforce)
@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce)
마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다.
```shell
kubectl exec hello-apparmor touch /tmp/test
kubectl exec hello-apparmor -- touch /tmp/test
```
```
touch: /tmp/test: Permission denied

2
content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
View File

@ -72,7 +72,7 @@ weight: 10
<div class="row">
<div class="col-md-8">
<p><b>컨트롤 플레인은 클러스터 관리를 담당한다.</b> 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다.</p>
</div>
<div class="col-md-4">

2
content/ko/docs/tutorials/services/source-ip.md
View File

@ -163,7 +163,7 @@ command=GET
## `Type=NodePort` 인 서비스에서 소스 IP
[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#nodeport)인
[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#type-nodeport)인
서비스로 보내진 패킷은
소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.

4
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
View File

@ -127,8 +127,8 @@ web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
```
참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고)
및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고)
및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자.
## 스테이트풀셋 안에 파드

2
content/ko/docs/tutorials/stateful-application/cassandra.md
View File

@ -283,6 +283,6 @@ kubectl apply -f cassandra-statefulset.yaml
## {{% heading "whatsnext" %}}
* 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다.
* 어떻게 [스테이트풀셋 스케일](/ko/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다.
* [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다.
* 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다.

3
content/ko/docs/tutorials/stateful-application/zookeeper.md
View File

@ -894,8 +894,7 @@ kubernetes-node-2g2d
kubectl get nodes
```
[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여
클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자.
이 튜토리얼에서는 클러스터가 최소 4개의 노드로 구성되었다고 가정한다. 클러스터의 노드가 4개보다 많다면, [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) 명령을 이용하여 4개 노드를 제외하고 다른 모든 노드를 통제(cordon)한다. 이렇게 4개 노드만 사용하도록 제한하여, 다음의 유지보수 시뮬레이션 예시에서 주키퍼 파드를 스케줄링할 때 어피니티와 PodDisruptionBudget 제약이 발생하도록 할 수 있다.
```shell
kubectl cordon <노드-이름>

Some files were not shown because too many files have changed in this diff Show More