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

[ko] Update outdated files in dev-1.23-ko.3 (M44-M77)

Browse Source
This commit is contained in:
Jihoon Seo
2022-06-20 22:34:23 +09:00
parent 04e900f07b
commit 6d6a8be31b
30 changed files with 858 additions and 760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/storage/storage-classes.md
+3 -3
View File
@@ -87,7 +87,7 @@ volumeBindingMode: Immediate
여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이
이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와
함께 제공된다). 또한, 쿠버네티스에서 정의한
[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을
[사양](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)을
따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다.
외부 프로비저너의 작성자는 코드의 수명, 프로비저너의
배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인
@@ -241,8 +241,8 @@ allowedTopologies:
- matchLabelExpressions:
- key: failure-domain.beta.kubernetes.io/zone
values:
- us-central1-a
- us-central1-b
- us-central-1a
- us-central-1b
```
## 파라미터
content/ko/docs/concepts/storage/volumes.md
+29 -17
View File
@@ -145,12 +145,19 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI
드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk`
기능을 활성화해야 한다.
`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우,
기존 인-트리 플러그인의 모든 플러그인 작업을
`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에
[Azure Disk CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고
`CSIMigration` 및 `CSIMigrationAzureDisk` 기능을 활성화해야 한다.
#### azureDisk CSI 마이그레이션 완료
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면,
`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다.
### azureFile {#azurefile}
@@ -163,15 +170,22 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI
드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver)
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
`azureFile` 의 `CSIMigration` 기능이 활성화된 경우,
기존 인-트리 플러그인의 모든 플러그인 작업을
`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에
[Azure File CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고
`CSIMigration` 및 `CSIMigrationAzureFile` 기능을 활성화해야 한다.
Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
#### azureFile CSI 마이그레이션 완료
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면,
`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다.
### cephfs
`cephfs` 볼륨은 기존 CephFS 볼륨을
@@ -251,7 +265,7 @@ metadata:
spec:
containers:
- name: test
image: busybox
image: busybox:1.28
volumeMounts:
- name: config-vol
mountPath: /etc/config
@@ -879,9 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에
* 또한, 트리 내(in-tree) 스토리지클래스의
`adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의
`adminSecretName` 값이 `adminId` 파라미터 값의
base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다.
{{< /note >}}
base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}}
### secret
@@ -1130,7 +1142,7 @@ spec:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
volumeMounts:
- name: workdir1
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+1 -1
View File
@@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │ 또는 sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *
```
content/ko/docs/concepts/workloads/controllers/daemonset.md
+8 -8
View File
@@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
[잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다.
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다.
또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다.
파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
`.spec.template`의 레이블과 매치되는
파드 셀렉터를 명시해야 한다.
또한, 한 번 데몬셋이 만들어지면
`.spec.selector` 는 바꿀 수 없다.
파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
@@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다.
일치하지 않는 구성은 API에 의해 거부된다.
`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다.
이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다.
### 오직 일부 노드에서만 파드 실행
@@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 기본 스케줄러로 스케줄
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
{{< feature-state for_k8s_version="1.17" state="stable" >}}
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
content/ko/docs/concepts/workloads/controllers/deployment.md
+17 -9
View File
@@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음,
이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다.
충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다.
* 디플로이먼트의 세부 정보 가져오기
```shell
@@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
```
처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서
3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음
이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다.
이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고
3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다.
그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다.
이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다.
{{< note >}}
쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며,
이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다.
그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며,
종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다.
{{< /note >}}
### 롤오버(일명 인-플라이트 다중 업데이트)
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
content/ko/docs/concepts/workloads/controllers/job.md
+3 -2
View File
@@ -308,7 +308,7 @@ spec:
### 완료된 잡을 위한 TTL 메커니즘
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@@ -631,7 +631,8 @@ spec:
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
사용자가 느낄 수 있는 유일한 차이점은
컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
{{< /note >}}
이 기능이 활성화되지 않으면, 잡
content/ko/docs/concepts/workloads/controllers/replicaset.md
-2
View File
@@ -223,8 +223,6 @@ pod2 1/1 Running 0 36s
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
레플리카셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+3 -3
View File
@@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
레플리케이션 컨트롤러를 삭제).
REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우
명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제).
### 레플리케이션 컨트롤러만 삭제
@@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
content/ko/docs/concepts/workloads/controllers/statefulset.md
+5 -5
View File
@@ -115,7 +115,7 @@ spec:
### 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
### 볼륨 클레임 템플릿
@@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
되기 전까지 종료되지 않는다.
### 파드 관리 정책
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를
통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해
고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
#### OrderedReady 파드 관리
@@ -242,6 +242,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
받지 않는다.
## 업데이트 전략
스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
@@ -255,8 +256,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
`RollingUpdate`(롤링 업데이트)
: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
`RollingUpdate` 업데이트 전략은 스테이트풀셋의 파드에 대한 자동화된 롤링 업데이트를 구현한다. 이는 기본 업데이트 전략이다.
## 롤링 업데이트
content/ko/docs/concepts/workloads/pods/_index.md
+14 -15
View File
@@ -180,7 +180,7 @@ spec:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# 여기까지 파드 템플릿이다
@@ -251,20 +251,19 @@ spec:
### 파드 네트워킹
각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한
컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
*파드 외부의* 엔티티와 통신할 때,
공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
통신할 수도 있다. 다른 파드의 컨테이너는
고유한 IP 주소를 가지며
[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다.
다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
사용하여 통신할 수 있다.
각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다.
파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며,
여기에는 IP 주소와 네트워크 포트가 포함된다.
파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는
`localhost` 를 사용하여 서로 통신할 수 있다.
파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때,
공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
`localhost` 를 통해 서로를 찾을 수 있다.
파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은
표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다.
다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다.
다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.
파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
`name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+2 -2
View File
@@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
종료 시간이 표시된다.
컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
실행된다.
컨테이너에 구성된 `preStop` 훅이 있는 경우,
이 훅은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다.
## 컨테이너 재시작 정책 {#restart-policy}
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+6 -12
View File
@@ -12,14 +12,6 @@ obsolete -->
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
{{< note >}}
v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다
{{< /note >}}
<!-- body -->
## 필수 구성 요소
@@ -306,11 +298,12 @@ class zoneC cluster;
예시 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
@@ -366,11 +359,12 @@ defaultConstraints:
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []