kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #30988 from jihoon-seo/211215_Outdated_M34 

[ko] Update outdated files in dev-1.23-ko.1 (M34-M37)
pull/31418/head
Kubernetes Prow Robot 2022-01-20 01:35:53 -08:00 committed by GitHub
parent 90c780b133 b928e5c8de
commit 220a2586b4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 228 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< 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" >}}의 시간대를 기준으로 한다.
@ -28,6 +26,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
크론잡 컨트롤러가 사용하는 시간대로 결정한다.
{{< /caution >}}
{{< caution >}}
[v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)은
위에서 설명한 타임존 설정을 공식적으로 지원하지는 않는다.
`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 쿠버네티스 프로젝트에서 공식적으로 지원하지는 않는다.
`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은
크론탭을 파싱하고 다음 잡 생성 시간을 계산하는 내부 라이브러리의 구현 상세사항이다.
프로덕션 클러스터에서는 사용을 권장하지 않는다.
{{< /caution >}}
크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
@ -55,16 +63,15 @@ kube-controller-manager 컨테이너에 설정된 시간대는
### 크론 스케줄 문법
```
# ┌────────────────── 타임존 (옵션)
# | ┌───────────── 분 (0 - 59)
# | │ ┌───────────── 시 (0 - 23)
# | │ │ ┌───────────── 일 (1 - 31)
# | │ │ │ ┌───────────── 월 (1 - 12)
# | │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# | │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# | │ │ │ │ │
# | │ │ │ │ │
# CRON_TZ=UTC * * * * *
# ┌───────────── 분 (0 - 59)
# │ ┌───────────── 시 (0 - 23)
# │ │ ┌───────────── 일 (1 - 31)
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
```
@ -78,9 +85,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
`CRON_TZ=UTC 0 0 13 * 5`
`0 0 13 * 5`
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
@ -144,6 +151,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
* 크론잡을 생성하고 다루기 위한 지침 및
크론잡 매니페스트의 예제로
[크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
* 실패했거나 완료된 잡을 자동으로 정리하도록 하려면,
[완료된 잡을 자동으로 정리](/ko/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)를 확인한다.
* `CronJob`은 쿠버네티스 REST API의 일부이다.
{{< api-reference page="workload-resources/cron-job-v1" >}}
오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.

39
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -32,7 +32,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
* 디플로이먼트의 PodTemplateSpec을 업데이트해서 [파드의 새로운 상태를 선언한다](#디플로이먼트-업데이트). 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
* 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 [디플로이먼트의 이전 버전으로 롤백](#디플로이먼트-롤백)한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
* [더 많은 로드를 위해 디플로이먼트의 스케일 업](#디플로이먼트-스케일링).
* [디플로이먼트 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 새로운 롤아웃의 시작을 재개한다.
* [디플로이먼트 롤아웃 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
* 롤아웃이 막혀있는지를 나타내는 [디플로이먼트 상태를 이용](#디플로이먼트-상태).
* 더 이상 필요 없는 [이전 레플리카셋 정리](#정책-초기화).
@ -697,12 +697,16 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## 디플로이먼트의 일시 중지와 재개
## 디플로이먼트 롤아웃 일시 중지와 재개 {#pausing-and-resuming-a-deployment}
하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
디플로이먼트를 업데이트할 때 (또는 계획할 때),
하나 이상의 업데이트를 트리거하기 전에 해당 디플로이먼트에 대한 롤아웃을 일시 중지할 수 있다.
변경 사항을 적용할 준비가 되면, 디플로이먼트 롤아웃을 재개한다.
이러한 방법으로, 불필요한 롤아웃을 트리거하지 않고
롤아웃 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
* 예를 들어, 생성된 디플로이먼트의 경우
디플로이먼트 상세 정보를 가져온다.
```shell
kubectl get deploy
@ -753,7 +757,7 @@ nginx-deployment-618515232 11 11 11 7m
REVISION CHANGE-CAUSE
1 <none>
```
* 롤아웃 상태를 가져와서 디플로이먼트 업데이트가 성공적인지 확인한다.
* 기존 레플리카셋이 변경되지 않았는지 확인하기 위해 롤아웃 상태를 출력한다.
```shell
kubectl get rs
```
@ -774,10 +778,10 @@ nginx-deployment-618515232 11 11 11 7m
deployment.apps/nginx-deployment resource requirements updated
```
디플로이먼트를 일시 중지하기 전의 초기 상태는 해당 기능을 지속한다.
그러나 디플로이먼트가 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
디플로이먼트 롤아웃을 일시 중지하기 전 디플로이먼트의 초기 상태는 해당 기능을 지속한다.
그러나 디플로이먼트 롤아웃이 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
* 결국, 디플로이먼트 롤아웃을 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
```shell
kubectl rollout resume deployment/nginx-deployment
```
@ -911,8 +915,8 @@ deployment.apps/nginx-deployment patched
{{< /note >}}
{{< note >}}
만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
만약 디플로이먼트 롤아웃을 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
롤아웃 중에 디플로이먼트 롤아웃을 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
재개할 수 있다.
{{< /note >}}
@ -1052,8 +1056,7 @@ echo $?
`.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
@ -1065,6 +1068,18 @@ echo $?
`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다.
예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로
디플로이먼트의 크기를 수동으로 조정한 뒤,
매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행),
수동으로 설정했던 디플로이먼트의 크기가 오버라이드된다.
[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가
디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
대신, 쿠버네티스
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
`.spec.replicas` 필드를 자동으로 관리한다.
### 셀렉터
`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를

64
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -25,7 +25,8 @@ weight: 50
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든),
[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
<!-- body -->
@ -206,6 +207,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된
호스트네임을 사용할 수 있다.
- 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@ -249,7 +251,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
{{< note >}}
만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록
하려면 `restartPolicy = "Never"` 로 설정하는 것을 권장한다.
{{< /note >}}
@ -344,6 +346,25 @@ spec:
삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
후에 TTL 컨트롤러에 의해 정리되지 않는다.
{{< note >}}
`ttlSecondsAfterFinished` 필드를 설정하는 것을 권장하는데,
이는 관리되지 않는 잡(직접 생성한,
크론잡 등 다른 워크로드 API를 통해 간접적으로 생성하지 않은 잡)의
기본 삭제 정책이 `orphanDependents`(관리되지 않는 잡이 완전히 삭제되어도
해당 잡에 의해 생성된 파드를 남겨둠)이기 때문이다.
삭제된 잡의 파드가 실패하거나 완료된 뒤
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 언젠가
[가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)을 한다고 해도,
이렇게 남아 있는 파드는 클러스터의 성능을 저하시키거나
최악의 경우에는 이 성능 저하로 인해 클러스터가 중단될 수도 있다.
[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)와
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여
특정 네임스페이스가 사용할 수 있는 자원량을 제한할 수
있다.
{{< /note >}}
## 잡 패턴
잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다. 잡 오브젝트는 과학
@ -415,8 +436,11 @@ spec:
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
즉시 파드 생성을 시작하고 잡이 완료될 때까지
계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에
다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다.
재개하거나, 잡을 중단 상태로 생성하고 언제 시작할지를
커스텀 컨트롤러가 나중에 결정하도록 하고 싶을 수도 있다.
잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
업데이트할 수 있다. 이후에, 다시 재개하려면, false로 업데이트한다.
`.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로
생성된다.
@ -501,6 +525,32 @@ Events:
파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시
시작되었음을 알 수 있다.
### 가변적 스케줄링 지시
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
이 기능을 사용하려면,
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)에
`JobMutableNodeSchedulingDirectives` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
이 기능은 기본적으로 활성화되어 있다.
{{< /note >}}
병렬 잡에서 대부분의 경우 파드를 특정 제약 조건 하에서 실행하고 싶을 것이다.
(예를 들면 동일 존에서 실행하거나, 또는 GPU 모델 x 또는 y를 사용하지만 둘을 혼합하지는 않는 등)
[suspend](#suspending-a-job) 필드는 이러한 목적을 달성하기 위한 첫 번째 단계이다.
이 필드를 사용하면 커스텀 큐(queue) 컨트롤러가 잡이 언제 시작될지를 결정할 수 있다.
그러나, 잡이 재개된 이후에는, 커스텀 큐 컨트롤러는 잡의 파드가 실제로 어디에 할당되는지에 대해서는 영향을 주지 않는다.
이 기능을 이용하여 잡이 실행되기 전에 잡의 스케줄링 지시를 업데이트할 수 있으며,
이를 통해 커스텀 큐 컨트롤러가 파드 배치에 영향을 줌과 동시에
노드로의 파드 실제 할당 작업을 kube-scheduler로부터 경감시켜 줄 수 있도록 한다.
이는 이전에 재개된 적이 없는 중지된 잡에 대해서만 허용된다.
잡의 파드 템플릿 필드 중, 노드 어피니티(node affinity), 노드 셀렉터(node selector),
톨러레이션(toleration), 레이블(label), 어노테이션(annotation)은 업데이트가 가능하다.
### 자신의 파드 셀렉터를 지정하기
일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다.
@ -570,17 +620,17 @@ spec:
### 종료자(finalizers)를 이용한 잡 추적
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
이 기능을 이용하기 위해서는
[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와
[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해
`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
기본적으로는 비활성화되어 있다.
기본적으로는 활성화되어 있다.
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
기존에 존재하던 잡은 영향을 받지 않는다.
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
{{< /note >}}

144
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -1,4 +1,11 @@
---
title: 스테이트풀셋
content_type: concept
weight: 30
@ -67,13 +74,14 @@ metadata:
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
app: nginx # .spec.template.metadata.labels 와 일치해야 한다
serviceName: "nginx"
replicas: 3 # by default is 1
replicas: 3 # 기본값은 1
minReadySeconds: 10 # 기본값은 0
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
app: nginx # .spec.selector.matchLabels 와 일치해야 한다
spec:
terminationGracePeriodSeconds: 10
containers:
@ -105,9 +113,24 @@ spec:
스테이트풀셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
## 파드 셀렉터
### 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
### 볼륨 클레임 템플릿
`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를 제공할 수 있다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
`.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가
문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어
있음에 유의한다. 이 기능을 사용하지 않으려면 StatefulSetMinReadySeconds 플래그를 설정 해제한다.
이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.)
파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
## 파드 신원
@ -166,9 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
### 안정된 스토리지
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을
생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@ -279,25 +300,103 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
실행하려고 시도한 모든 파드를 삭제해야 한다.
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
### 최소 준비 시간 초 {#minimum-ready-seconds}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
## 퍼시스턴트볼륨클레임 유보
`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록
컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
선택적 필드인 `.spec.persistentVolumeClaimRetentionPolicy` 는
스테이트풀셋의 생애주기동안 PVC를 삭제할 것인지,
삭제한다면 어떻게 삭제하는지를 관리한다.
이 필드를 사용하려면 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
활성화 시, 각 스테이트풀셋에 대해 두 가지 정책을 설정할 수 있다.
`whenDeleted`
: 스테이트풀셋이 삭제될 때 적용될 볼륨 유보 동작을 설정한다.
`whenScaled`
: 스테이트풀셋의 레플리카 수가 줄어들 때, 예를 들면 스테이트풀셋을 스케일 다운할 때
적용될 볼륨 유보 동작을 설정한다.
설정 가능한 각 정책에 대해, 그 값을 `Delete` 또는 `Retain` 으로 설정할 수 있다.
`Delete`
: `volumeClaimTemplate` 스테이트풀셋으로부터 생성된 PVC는 정책에 영향을 받는 각 파드에 대해 삭제된다.
`whenDeleted` 가 이 값으로 설정되어 있으면
`volumeClaimTemplate` 으로부터 생성된 모든 PVC는 파드가 삭제된 뒤에 삭제된다.
`whenScaled` 가 이 값으로 설정되어 있으면
스케일 다운된 파드 레플리카가 삭제된 뒤, 삭제된 파드에 해당되는 PVC만 삭제된다.
`Retain` (기본값)
: 파드가 삭제되어도 `volumeClaimTemplate` 으로부터 생성된 PVC는 영향을 받지 않는다.
이는 이 신기능이 도입되기 전의 기본 동작이다.
이러한 정책은 파드의 삭제가 스테이트풀셋 삭제 또는 스케일 다운으로 인한 것일 때**에만** 적용됨에 유의한다.
예를 들어, 스테이트풀셋의 파드가 노드 실패로 인해 실패했고,
컨트롤 플레인이 대체 파드를 생성했다면, 스테이트풀셋은 기존 PVC를 유지한다.
기존 볼륨은 영향을 받지 않으며,
새 파드가 실행될 노드에 클러스터가 볼륨을 연결(attach)한다.
정책의 기본값은 `Retain` 이며, 이는 이 신기능이 도입되기 전의 스테이트풀셋 기본 동작이다.
다음은 정책 예시이다.
```yaml
apiVersion: apps/v1
kind: StatefulSet
...
spec:
persistentVolumeClaimRetentionPolicy:
whenDeleted: Retain
whenScaled: Delete
...
```
스테이트풀셋 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는 자신이 소유한 PVC에
[소유자 정보(reference)](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)를
추가하며, 파드가 종료된 이후에는 {{<glossary_tooltip text="가비지 콜렉터" term_id="garbage-collection">}}가 이 정보를 삭제한다.
이로 인해 PVC가 삭제되기 전에
(그리고 유보 정책에 따라, 매칭되는 기반 PV와 볼륨이 삭제되기 전에)
파드가 모든 볼륨을 깨끗하게 언마운트할 수 있다.
`whenDeleted` 정책을 `Delete` 로 설정하면,
해당 스테이트풀셋에 연결된 모든 PVC에 스테이트풀셋 인스턴스의 소유자 정보가 기록된다.
`whenScaled` 정책은 파드가 스케일 다운되었을 때에만 PVC를 삭제하며,
파드가 다른 원인으로 삭제되면 PVC를 삭제하지 않는다.
조정 상황 발생 시, 스테이트풀셋 컨트롤러는 목표 레플리카 수와 클러스터 상의 실제 파드 수를 비교한다.
레플리카 카운트보다 큰 ID를 갖는 스테이트풀셋 파드는 부적격 판정을 받으며 삭제 대상으로 표시된다.
`whenScaled` 정책이 `Delete` 이면, 부적격 파드는 삭제되기 전에,
연결된 스테이트풀셋 템플릿 PVC의 소유자로 지정된다.
이로 인해, 부적격 파드가 종료된 이후에만 PVC가 가비지 콜렉트된다.
이는 곧 만약 컨트롤러가 강제 종료되어 재시작되면,
파드의 소유자 정보가 정책에 적합하게 업데이트되기 전에는 어떤 파드도 삭제되지 않을 것임을 의미한다.
만약 컨트롤러가 다운된 동안 부적격 파드가 강제로 삭제되면,
컨트롤러가 강제 종료된 시점에 따라 소유자 정보가 설정되었을 수도 있고 설정되지 않았을 수도 있다.
소유자 정보가 업데이트되기까지 몇 번의 조정 절차가 필요할 수 있으며,
따라서 일부 부적격 파드는 소유자 정보 설정을 완료하고 나머지는 그러지 못했을 수 있다.
이러한 이유로, 컨트롤러가 다시 켜져서 파드를 종료하기 전에
소유자 정보를 검증할 때까지 기다리는 것을 추천한다.
이것이 불가능하다면, 관리자는 PVC의 소유자 정보를 확인하여 파드가 강제 삭제되었을 때 해당되는 오브젝트가 삭제되도록 해야 한다.
### 레플리카
`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 기본값은 1이다.
예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로
디플로이먼트의 크기를 수동으로 조정한 뒤,
매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행),
수동으로 설정했던 디플로이먼트의 크기가
오버라이드된다.
[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가
디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
대신, 쿠버네티스
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
`.spec.replicas` 필드를 자동으로 관리한다.
## {{% heading "whatsnext" %}}
* [스테이트풀 애플리케이션의 배포](/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/) 예제를 따라한다.
@ -309,7 +408,6 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
스테이트풀셋 API에 대해 이해하기 위해
{{< api-reference page="workload-resources/stateful-set-v1" >}}
오브젝트 정의를 읽는다.
{{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.