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

[ko] Update outdated files in dev-1.24-ko.1 M49-M72

Browse Source
This commit is contained in:
Jihoon Seo
2022-05-27 11:23:37 +09:00
parent e6d993feb3
commit 360335002d
21 changed files with 283 additions and 192 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+16 -1
View File
@@ -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}
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
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
+16 -11
View File
@@ -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 >}}
이 기능이 활성화되지 않으면, 잡
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
+27 -4
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 파드 관리
@@ -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`)과