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

Merge pull request #30412 from kubernetes/dev-1.22-ko.2

Browse Source 
[ko] 2nd Korean localization work for v1.22
This commit is contained in:
Kubernetes Prow Robot
2021-11-09 05:39:47 -08:00
committed by GitHub
parent 0e19aed5dc 7d7d0224f7
commit b81dcba911
82 changed files with 2255 additions and 503 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+25 -16
View File
@@ -17,6 +17,8 @@ _크론잡은_ 반복 일정에 따라 {{< 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" >}}의 시간대를 기준으로 한다.
@@ -53,15 +55,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
### 크론 스케줄 문법
```
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
# ┌────────────────── 타임존 (옵션)
# | ┌───────────── 분 (0 - 59)
# | │ ┌───────────── 시 (0 - 23)
# | │ │ ┌───────────── 일 (1 - 31)
# | │ │ │ ┌───────────── 월 (1 - 12)
# | │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# | │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# | │ │ │ │ │
# | │ │ │ │ │
# CRON_TZ=UTC * * * * *
```
@@ -74,9 +77,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
| @hourly | 매시 0분에 시작 | 0 * * * * |
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
`0 0 13 * 5`
`CRON_TZ=UTC 0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
@@ -132,8 +135,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
## {{% heading "whatsnext" %}}
[크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은
크론잡 `schedule` 필드의 포맷을 문서화 한다.
크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의
예는 [크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다.
* 크론잡이 의존하고 있는 [파드](/ko/docs/concepts/workloads/pods/)와
[잡](/ko/docs/concepts/workloads/controllers/job/) 두 개념에
대해 배운다.
* 크론잡 `.spec.schedule` 필드의 [형식](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)에
대해서 읽는다.
* 크론잡을 생성하고 다루기 위한 지침 및
크론잡 매니페스트의 예제로
[크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
* `CronJob`은 쿠버네티스 REST API의 일부이다.
{{< api-reference page="workload-resources/cron-job-v1" >}}
오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.
content/ko/docs/concepts/workloads/controllers/daemonset.md
+20 -2
View File
@@ -185,7 +185,7 @@ nodeAffinity:
필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는
다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다.
사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면
사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=orphan` 를 명시하면
파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면,
새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
`updateStrategy` 에 따라 파드를 교체한다.
@@ -213,7 +213,7 @@ nodeAffinity:
어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
생성하는 것보다는 데몬 셋을 사용해야 한다.
### 스태틱(static) 파드
### 스태틱(static) 파드 {#static-pods}
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
@@ -233,3 +233,21 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다.
* 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
컴포넌트를 기동하는데 유용한
[스태틱 파드](#static-pods)에 대해 배운다.
* 데몬셋을 어떻게 사용하는지 알아본다.
* [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/)
* [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)
(예를 들어, 롤 아웃이 예상대로 동작하지 않은 경우).
* [쿠버네티스가 파드를 노드에 할당하는 방법](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 이해한다.
* 데몬셋으로 구동되곤 하는, [디바이스 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)과
[애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다.
* `DaemonSet`은 쿠버네티스 REST API에서 상위-수준 리소스이다.
데몬셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/daemon-set-v1" >}}
오브젝트 정의를 읽는다.
content/ko/docs/concepts/workloads/controllers/deployment.md
+19 -13
View File
@@ -73,10 +73,6 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
`--record` 플래그를 지정해서 실행된 명령을 `kubernetes.io/change-cause` 리소스 어노테이션에 작성할 수 있다.
기록된 변경사항은 향후 인트로스펙션(introspection)에 유용하다. 예를 들면, 디플로이먼트의 각 수정 버전에서 실행된 명령을 볼 수 있다.
{{< /note >}}
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
@@ -167,13 +163,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
```shell
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
또는 다음의 명령어를 사용한다.
```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
다음과 유사하게 출력된다.
@@ -368,7 +364,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
```shell
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
```
이와 유사하게 출력된다.
@@ -483,15 +479,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
```
`CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
* 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
* `kubectl` 명령어 이용시 `--record` 플래그를 추가해서 리소스 변경을 저장한다.
* 수동으로 리소스 매니페스트 편집.
2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
@@ -504,7 +499,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@@ -565,7 +560,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@@ -1174,3 +1169,14 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은
일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* [디플로이먼트를 사용해서 상태를 유지하지 않는 애플리케이션을 구동한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
* `Deployment`는 쿠버네티스 REST API에서 상위-수준 리소스이다.
디플로이먼트 API를 이해하기 위해서
{{< api-reference page="workload-resources/deployment-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
content/ko/docs/concepts/workloads/controllers/job.md
+19 -4
View File
@@ -25,6 +25,8 @@ weight: 50
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
<!-- body -->
## 예시 잡 실행하기
@@ -294,7 +296,7 @@ spec:
`restartPolicy` 는 잡 자체에 적용되는 것이 아니라 파드에 적용된다는 점을 유념한다. 잡의 상태가 `type: Failed` 이 되면, 잡의 자동 재시작은 없다.
즉, `.spec.activeDeadlineSeconds` 와 `.spec.backoffLimit` 로 활성화된 잡의 종료 메커니즘은 영구적인 잡의 실패를 유발하며 이를 해결하기 위해 수동 개입이 필요하다.
## 완료된 잡을 자동으로 정리
## 완료된 잡을 자동으로 정리 {#clean-up-finished-jobs-automatically}
완료된 잡은 일반적으로 시스템에서 더 이상 필요로 하지 않는다. 시스템 내에
이를 유지한다면 API 서버에 부담이 된다.
@@ -522,7 +524,7 @@ Events:
실행되기를 원하지만, 잡이 생성한 나머지 파드에는 다른
파드 템플릿을 사용하고 잡으로 하여금 새 이름을 부여하기를 원한다.
그러나 관련된 필드들은 업데이트가 불가능하기 때문에 잡을 업데이트할 수 없다.
따라서 `kubectl delete jobs/old --cascade=false` 를 사용해서
따라서 `kubectl delete jobs/old --cascade=orphan` 명령을 사용해서
잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
@@ -638,6 +640,19 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다.
## 크론잡 {#cron-jobs}
## {{% heading "whatsnext" %}}
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
* [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
* 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.
* `Job`은 쿠버네티스 REST API의 일부이다.
잡 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/job-v1" >}}
오브젝트 정의를 읽은다.
* 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한
[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다.
content/ko/docs/concepts/workloads/controllers/replicaset.md
+13
View File
@@ -408,3 +408,16 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
* 레플리카셋에 의존해서 동작하는 [디플로이먼트로 스테이트리스 애플리케이션을 실행한다](/ko/docs/tasks/run-application/run-stateless-application-deployment/).
* `ReplicaSet`는 쿠버네티스 REST API의 상위-수준 리소스이다.
레플리카셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/replica-set-v1" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+8 -3
View File
@@ -193,7 +193,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적
해당 파드에 영향을 주지 않고 레플리케이션 컨트롤러를 삭제할 수 있다.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=false`를 지정하라.
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
@@ -285,6 +285,11 @@ API 오브젝트에 대한 더 자세한 것은
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
## 더 자세한 정보는
## {{% heading "whatsnext" %}}
[스테이트리스 애플리케이션 디플로이먼트 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)를 참고한다.
* [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
* 레플리케이션 컨트롤러를 대신하는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 배운다.
* `ReplicationController`는 쿠버네티스 REST API의 일부이다.
레플리케이션 컨트롤러 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/replication-controller-v1" >}}
오브젝트 정의를 읽는다.
content/ko/docs/concepts/workloads/controllers/statefulset.md
+16
View File
@@ -297,3 +297,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스테이트풀 애플리케이션의 배포](/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/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" >}}
오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
content/ko/docs/concepts/workloads/pods/_index.md
+10 -6
View File
@@ -258,11 +258,8 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
## 컨테이너에 대한 특권 모드
리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. 파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
{{< note >}}
이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -286,6 +283,13 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
{{< note >}}
스태틱 파드의 `스펙(spec)`은 다른 API 오브젝트
(예를 들면, {{< glossary_tooltip text="서비스어카운트" term_id="service-account" >}},
{{< glossary_tooltip text="컨피그맵" term_id="configmap" >}},
{{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다.
{{< /note >}}
## 컨테이너 프로브
_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
@@ -305,9 +309,9 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
[파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
{{< api-reference page="workload-resources/pod-v1" >}}
오브젝트 정의는 오브젝트를 상세히 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns/)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
content/ko/docs/concepts/workloads/pods/init-containers.md
+13 -9
View File
@@ -32,12 +32,14 @@ weight: 40
그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정하고, 해당 파드를 시작하는 동안 초기화 컨테이너가 실패하면, 쿠버네티스는 전체 파드를 실패한 것으로 처리한다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
타입 오브젝트들의 JSON 배열로서 추가한다.
초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를
통해서 컨테이너 상태 배열로 반환된다
(`.status.containerStatuses` 필드와 유사하게).
[파드 스펙](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 `initContainers` 필드를
`container` 항목(앱 `container` 필드 및 내용과 유사한)들의 배열로서 추가한다.
[컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)에 대한 더 상세한 사항은
API 레퍼런스를 참고한다.
초기화 컨테이너의 상태는 컨테이너
상태의 배열(`.status.containerStatuses` 필드와 유사)로 `.status.initContainerStatuses`
필드에 반환된다.
### 일반적인 컨테이너와의 차이점
@@ -278,9 +280,11 @@ myapp-pod 1/1 Running 0 9m
`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
초기화 컨테이너들이 실패를
영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다.
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`를 사용한다.
Active deadline은 초기화 컨테이너를 포함한다.
그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다.
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+17 -13
View File
@@ -230,20 +230,9 @@ graph BT
이 상황을 극복하기 위해서는 사용자가 `maxSkew` 의 증가 또는 `whenUnsatisfiable: ScheduleAnyway` 를 사용하도록 제약 조건 중 하나를 수정할 수 있다.
### 규칙
### 노드 어피니티(Affinity) 및 노드 셀렉터(Selector)와의 상호 작용
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
- 만약 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity` 가 정의되어 있으면, 일치하지 않는 노드는 무시하게 된다.
스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
@@ -283,6 +272,21 @@ graph BT
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
스케줄러는 클러스터에 있는 모든 영역(zone) 또는 다른 토폴로지 도메인에 대한 사전 지식이 없다. 스케줄링은 클러스터의 기존 노드에서 결정된다. 노드 풀(또는 노드 그룹)이 0개의 노드로 스케일(scale)되고 사용자는 노드가 확장될 것으로 예상하는 경우, 자동 스케일되는 클러스터에서 문제가 발생할 수 있다. 이러한 토폴로지 도메인은 스케줄링에서 해당 도메인에 노드가 하나 이상 있을 때까지 고려되지 않을 것이기 때문이다.
### 기타 눈에 띄는 의미(semantics)
여기에 주목할만한 몇 가지 암묵적인 규칙이 있다.
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
- 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다.
### 클러스터 수준의 기본 제약 조건
클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본