[ko] Update outdated files in dev-1.23-ko.3 (M44-M77)
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
|
||||
# │ │ │ │ │
|
||||
# * * * * *
|
||||
```
|
||||
|
||||
@@ -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 >}}
|
||||
|
||||
### 롤오버(일명 인-플라이트 다중 업데이트)
|
||||
|
||||
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
|
||||
|
||||
@@ -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 >}}
|
||||
|
||||
이 기능이 활성화되지 않으면, 잡
|
||||
|
||||
@@ -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 파드 관리
|
||||
|
||||
@@ -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` 업데이트 전략은 스테이트풀셋의 파드에 대한 자동화된 롤링 업데이트를 구현한다. 이는 기본 업데이트 전략이다.
|
||||
|
||||
## 롤링 업데이트
|
||||
|
||||
|
||||
Reference in New Issue
Block a user