[ko] Update outdated files in dev-1.24-ko.1 M49-M72
This commit is contained in:
Jihoon Seo
@@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
|
||||
# │ │ │ ┌───────────── 월 (1 - 12)
|
||||
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
|
||||
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
|
||||
# │ │ │ │ │
|
||||
# │ │ │ │ │ 또는 sun, mon, tue, wed, thu, fri, sat
|
||||
# │ │ │ │ │
|
||||
# * * * * *
|
||||
```
|
||||
@@ -91,6 +91,21 @@ kube-controller-manager 컨테이너에 설정된 시간대는
|
||||
|
||||
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
|
||||
|
||||
## 타임 존
|
||||
크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
|
||||
|
||||
`CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면,
|
||||
크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나,
|
||||
타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우,
|
||||
클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다).
|
||||
|
||||
이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다.
|
||||
예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다.
|
||||
|
||||
Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다.
|
||||
|
||||
## 크론잡의 한계 {#cron-job-limitations}
|
||||
|
||||
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
|
||||
|
||||
@@ -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" >}}
|
||||
|
||||
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
|
||||
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
|
||||
|
||||
@@ -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 >}}
|
||||
|
||||
### 롤오버(일명 인-플라이트 다중 업데이트)
|
||||
|
||||
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
|
||||
|
||||
@@ -42,7 +42,9 @@ weight: 50
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
job.batch/pi created
|
||||
```
|
||||
@@ -52,7 +54,9 @@ job.batch/pi created
|
||||
```shell
|
||||
kubectl describe jobs/pi
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
Name: pi
|
||||
Namespace: default
|
||||
@@ -97,7 +101,9 @@ Events:
|
||||
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
|
||||
echo $pods
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```
|
||||
pi-5rwd7
|
||||
```
|
||||
@@ -110,7 +116,9 @@ pi-5rwd7
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```shell
|
||||
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
|
||||
```
|
||||
@@ -190,7 +198,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
|
||||
|
||||
### 완료 모드
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
|
||||
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
|
||||
@@ -308,7 +316,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` 필드를 지정해서 완료된 리소스에 대해
|
||||
@@ -425,13 +433,7 @@ spec:
|
||||
|
||||
### 잡 일시 중지
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며,
|
||||
이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다.
|
||||
[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
|
||||
{{< /note >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
|
||||
즉시 파드 생성을 시작하고 잡이 완료될 때까지
|
||||
@@ -482,7 +484,7 @@ spec:
|
||||
kubectl get jobs/myjob -o yaml
|
||||
```
|
||||
|
||||
```json
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
# .metadata and .spec omitted
|
||||
@@ -581,7 +583,9 @@ Events:
|
||||
```shell
|
||||
kubectl get job old -o yaml
|
||||
```
|
||||
|
||||
출력 결과는 다음과 같다.
|
||||
|
||||
```yaml
|
||||
kind: Job
|
||||
metadata:
|
||||
@@ -631,7 +635,8 @@ spec:
|
||||
|
||||
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
|
||||
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
|
||||
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
|
||||
사용자가 느낄 수 있는 유일한 차이점은
|
||||
컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
이 기능이 활성화되지 않으면, 잡
|
||||
|
||||
@@ -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-서브도메인-이름)이어야 한다.
|
||||
|
||||
@@ -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` 가 동일하다면,
|
||||
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
|
||||
|
||||
@@ -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 파드 관리
|
||||
|
||||
@@ -266,7 +266,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
각 파드의 업데이트는 한 번에 하나씩 한다.
|
||||
|
||||
쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
|
||||
`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
|
||||
`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를
|
||||
설정한 경우,
|
||||
컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
|
||||
|
||||
### 파티션 롤링 업데이트 {#partitions}
|
||||
|
||||
@@ -280,6 +282,27 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
|
||||
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
|
||||
|
||||
### 최대 사용 불가능(unavailable) 파드 수
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
|
||||
|
||||
`.spec.updateStrategy.rollingUpdate.maxUnavailable` 필드를 명시하여,
|
||||
업데이트 과정에서 사용 불가능(unavailable) 파드를 최대 몇 개까지 허용할 것인지를 조절할 수 있다.
|
||||
값은 절대값(예: `5`) 또는 목표 파드 퍼센티지(예: `10%`)로 명시할 수 있다.
|
||||
절대값은 퍼센티지 값으로 계산한 뒤 올림하여 얻는다.
|
||||
이 필드는 0일 수 없다. 기본값은 1이다.
|
||||
|
||||
이 필드는 `0` 에서 `replicas - 1` 사이 범위에 있는 모든 파드에 적용된다.
|
||||
이 범위 내에 사용 불가능한 파드가 있으면,
|
||||
`maxUnavailable`로 집계된다.
|
||||
|
||||
{{< note >}}
|
||||
`maxUnavailable` 필드는 현재 알파 단계이며
|
||||
`MaxUnavailableStatefulSet`
|
||||
[기능 게이트](/ko/docs/reference/commmand-line-tools-reference/feature-gates/)가 활성화된 API 서버에서만
|
||||
동작한다.
|
||||
{{< /note >}}
|
||||
|
||||
### 강제 롤백
|
||||
|
||||
기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
|
||||
|
||||
@@ -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/) 섹션에 이에 대한
|
||||
|
||||
@@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
|
||||
쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
|
||||
종료 시간이 표시된다.
|
||||
|
||||
컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
|
||||
실행된다.
|
||||
컨테이너에 구성된 `preStop` 훅이 있는 경우,
|
||||
이 혹은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다.
|
||||
|
||||
## 컨테이너 재시작 정책 {#restart-policy}
|
||||
|
||||
|
||||
@@ -4,21 +4,11 @@ content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
<!-- leave this shortcode in place until the note about EvenPodsSpread is
|
||||
obsolete -->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
|
||||
|
||||
{{< 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 -->
|
||||
|
||||
@@ -83,16 +73,42 @@ spec:
|
||||
|
||||
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
|
||||
이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
|
||||
|
||||
- `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
|
||||
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
|
||||
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0)
|
||||
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수.
|
||||
예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면,
|
||||
전역 최솟값은 0)
|
||||
사이에 허용되는 최대 차이이다.
|
||||
- `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
|
||||
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
|
||||
|
||||
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다.
|
||||
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
|
||||
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
|
||||
|
||||
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
|
||||
파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다.
|
||||
"글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며,
|
||||
적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
|
||||
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
|
||||
이 값은 스케줄링에 영향을 미치지 않는다.
|
||||
- `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다.
|
||||
- `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다.
|
||||
|
||||
{{< note >}}
|
||||
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
|
||||
이를 사용하려면 `MinDomainsInPodToplogySpread`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
- **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
|
||||
|
||||
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
|
||||
- `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
|
||||
- `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
|
||||
|
||||
- **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
|
||||
|
||||
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
|
||||
@@ -306,11 +322,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:
|
||||
@@ -321,21 +338,17 @@ profiles:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
기본 스케줄링 제약 조건에 의해 생성된 점수는
|
||||
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
|
||||
의해 생성된 점수와 충돌 할 수 있다.
|
||||
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
|
||||
이 플러그인을 비활성화 하는 것을 권장한다.
|
||||
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
|
||||
기본적으로 비활성화되어 있다.
|
||||
비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 내부 기본 제약
|
||||
#### 내장 기본 제약 {#internal-default-constraints}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
|
||||
`SelectorSpread` 플러그인이 비활성화된다.
|
||||
kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
|
||||
기본 토폴로지 제약 조건을 사용한다.
|
||||
파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
|
||||
kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다.
|
||||
|
||||
```yaml
|
||||
defaultConstraints:
|
||||
@@ -347,8 +360,8 @@ defaultConstraints:
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이
|
||||
비활성화된다.
|
||||
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은
|
||||
기본적으로 비활성화되어 있다.
|
||||
|
||||
{{< note >}}
|
||||
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
|
||||
@@ -366,11 +379,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: []
|
||||
|
||||
Reference in New Issue
Block a user