First Korean l10n work for release-1.16 (#16551)
* Modify #16415, #16417 korean docs. (#16467) * Modify #16364 and links in korean docs. (#16508) * Translate concepts/workloads/controllers/statefulset.md in Korean (#16443) * Update outdated content in dev-1.16-ko.1 (#16502) * Translate concepts/workloads/controllers/daemonset.md in Korean (#16477) * Translate concepts/services-networking/dns-pod-service in Korean (#16299) Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: SoHye Choi <wergreat10@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
9b5a1768bd
commit
a36f83ed17
@@ -0,0 +1,238 @@
|
||||
---
|
||||
title: 데몬셋
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면
|
||||
파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로
|
||||
수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다.
|
||||
|
||||
데몬셋의 일부 대표적인 용도는 다음과 같다.
|
||||
|
||||
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
|
||||
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
|
||||
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
|
||||
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
|
||||
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
|
||||
각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 데몬셋 사양 작성
|
||||
|
||||
### 데몬셋 생성
|
||||
|
||||
YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
|
||||
|
||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||
|
||||
* YAML 파일을 기반으로 데몬셋을 생성한다.
|
||||
```
|
||||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
```
|
||||
|
||||
### 필수 필드
|
||||
|
||||
다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
|
||||
일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
|
||||
[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
|
||||
|
||||
데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
|
||||
|
||||
### 파드 템플릿
|
||||
|
||||
`.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
|
||||
|
||||
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
|
||||
|
||||
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
|
||||
한다([파드 셀렉터](#파드-셀렉터)를 본다).
|
||||
|
||||
데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/)는 `Always` 를 가져야 하며,
|
||||
명시되지 않은 경우 기본으로 `Always`가 된다.
|
||||
|
||||
### 파드 셀렉터
|
||||
|
||||
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
|
||||
[잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
|
||||
|
||||
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
|
||||
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
|
||||
셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다.
|
||||
또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다.
|
||||
파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
|
||||
|
||||
`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
|
||||
|
||||
* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다.
|
||||
* `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
|
||||
명시해서 보다 정교한 셀렉터를 만들 수 있다.
|
||||
|
||||
2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
|
||||
|
||||
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
|
||||
|
||||
또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
|
||||
레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
|
||||
컨트롤러는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
|
||||
막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
|
||||
수동으로 생성하는 것이다.
|
||||
|
||||
### 오직 일부 노드에서만 파드 실행
|
||||
|
||||
만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
|
||||
[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와
|
||||
일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
|
||||
데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다.
|
||||
만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
|
||||
|
||||
## 데몬 파드가 스케줄 되는 방법
|
||||
|
||||
### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함)
|
||||
|
||||
일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋
|
||||
컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이
|
||||
파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다.
|
||||
|
||||
- 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리)
|
||||
필드를 존중하지 않는다.
|
||||
- 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을
|
||||
도울 수도 있다.
|
||||
|
||||
|
||||
### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용)
|
||||
|
||||
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
|
||||
|
||||
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
|
||||
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
|
||||
데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
|
||||
이에 대한 이슈를 소개한다.
|
||||
|
||||
* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
|
||||
그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
|
||||
이것은 사용자에게 혼란을 준다.
|
||||
* [파드 선점](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
|
||||
파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
|
||||
|
||||
`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
|
||||
`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
|
||||
스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
|
||||
스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에
|
||||
이미 노드 선호도가 존재한다면 교체한다. 데몬셋 컨트롤러는
|
||||
데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
|
||||
데몬셋의 `spec.template` 은 변경되지 않는다.
|
||||
|
||||
```yaml
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchFields:
|
||||
- key: metadata.name
|
||||
operator: In
|
||||
values:
|
||||
- target-host-name
|
||||
```
|
||||
|
||||
또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로
|
||||
자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를
|
||||
스케줄링시 `unschedulable` 노드를 무시한다.
|
||||
|
||||
|
||||
### 테인트(taints)와 톨러레이션(tolerations)
|
||||
|
||||
데몬 파드는
|
||||
[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만,
|
||||
다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에
|
||||
톨러레이션을 추가한다.
|
||||
|
||||
| 톨러레이션 키 | 영향 | 버전 | 설명 |
|
||||
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
|
||||
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
|
||||
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
|
||||
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
|
||||
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |
|
||||
|
||||
|
||||
|
||||
|
||||
## 데몬 파드와 통신
|
||||
|
||||
데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.
|
||||
|
||||
- **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
|
||||
구성되어있다. 그들은 클라이언트들을 가지지 않는다.
|
||||
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
|
||||
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고,
|
||||
그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
|
||||
검색한다.
|
||||
- **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
|
||||
임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
|
||||
|
||||
## 데몬셋 업데이트
|
||||
|
||||
만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로
|
||||
일치하지 않는 노드에서 파드를 삭제한다.
|
||||
|
||||
사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든
|
||||
필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는
|
||||
다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다.
|
||||
|
||||
사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면
|
||||
파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면,
|
||||
새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은
|
||||
`updateStrategy` 에 따라 파드를 교체한다.
|
||||
|
||||
사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다.
|
||||
|
||||
## 데몬셋의 대안
|
||||
|
||||
### 초기화 스크립트
|
||||
|
||||
데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다.
|
||||
(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬
|
||||
프로세스를 실행하면 몇 가지 이점 있다.
|
||||
|
||||
- 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다.
|
||||
- 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`).
|
||||
- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서
|
||||
데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다
|
||||
(예: 도커에서 직접적으로 시작).
|
||||
|
||||
### 베어(Bare) 파드
|
||||
|
||||
직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나
|
||||
데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여
|
||||
어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
|
||||
생성하는 것보다는 데몬 셋을 사용해야 한다.
|
||||
|
||||
### 스태틱(static) 파드
|
||||
|
||||
Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
|
||||
[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
|
||||
데몬셋과는 다르게 스태틱 파드는 kubectl
|
||||
또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지
|
||||
않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다.
|
||||
|
||||
### 디플로이먼트
|
||||
|
||||
데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고,
|
||||
해당 파드에서는 프로세스가 종료되지 않을 것으로
|
||||
예상한다(예: 웹 서버).
|
||||
|
||||
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
|
||||
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
|
||||
디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
|
||||
다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -227,7 +227,7 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p
|
||||
다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다.
|
||||
|
||||
디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로
|
||||
적어도 의도한 파드 수의 25% 이상이 동작하도록 보장한다(최대 25% 이상 불가).
|
||||
적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 불가).
|
||||
|
||||
또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
|
||||
기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
|
||||
|
||||
@@ -0,0 +1,264 @@
|
||||
---
|
||||
title: 스테이트풀셋
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다.
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 스테이트풀셋 사용
|
||||
|
||||
스테이트풀셋은 다음 중 하나 또는 이상이 필요한 애플리케이션에
|
||||
유용하다.
|
||||
|
||||
* 안정된, 고유한 네트워크 식별자.
|
||||
* 안정된, 지속성을 갖는 스토리지.
|
||||
* 순차적인, 정상 배포(graceful deployment)와 스케일링.
|
||||
* 순차적인, 자동 롤링 업데이트.
|
||||
|
||||
위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다.
|
||||
만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포,
|
||||
삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을
|
||||
제공하는 컨트롤러로 애플리케이션을 배포해야 한다. 아마도
|
||||
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는
|
||||
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.
|
||||
|
||||
## 제한사항
|
||||
|
||||
* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
|
||||
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
|
||||
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
|
||||
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
|
||||
* [롤링 업데이트](#롤링-업데이트)와 기본
|
||||
[파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
|
||||
함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이
|
||||
필요한 파손 상태로 빠질 수 있다.
|
||||
|
||||
## 구성 요소
|
||||
아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
|
||||
|
||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
name: web
|
||||
clusterIP: None
|
||||
selector:
|
||||
app: nginx
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: web
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx # has to match .spec.template.metadata.labels
|
||||
serviceName: "nginx"
|
||||
replicas: 3 # by default is 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx # has to match .spec.selector.matchLabels
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- name: www
|
||||
mountPath: /usr/share/nginx/html
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "my-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
## 파드 셀렉터
|
||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||
|
||||
## 파드 신원
|
||||
스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고
|
||||
안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은
|
||||
파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다.
|
||||
|
||||
### 순서 색인
|
||||
|
||||
N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있는
|
||||
각 파드에 0에서 N-1 까지의 정수가 순서대로 할당되며 해당 스테이트풀셋 내에서 고유 하다.
|
||||
|
||||
### 안정적인 네트워크 신원
|
||||
|
||||
스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서
|
||||
호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은
|
||||
`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은
|
||||
`web-0,web-1,web-2` 이다.
|
||||
스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해
|
||||
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다.
|
||||
이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며,
|
||||
여기서 "cluster.local"은 클러스터 도메인이다.
|
||||
각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고
|
||||
일치되는 DNS 서브도메인을 가지며, 여기서 governing service는
|
||||
스테이트풀셋의 `serviceName` 필드에 의해 정의된다.
|
||||
|
||||
[제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
|
||||
파드의 네트워크 신원을 책임지는
|
||||
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다.
|
||||
|
||||
여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고,
|
||||
그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.
|
||||
|
||||
클러스터 도메인 | 서비스 (ns/이름) | 스테이트풀셋 (ns/이름) | 스테이트풀셋 도메인 | 파드 DNS | 파드 호스트 이름 |
|
||||
-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
|
||||
cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
|
||||
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
|
||||
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
|
||||
|
||||
{{< note >}}
|
||||
클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
|
||||
아니라면 `cluster.local`로 설정된다.
|
||||
{{< /note >}}
|
||||
|
||||
### 안정된 스토리지
|
||||
|
||||
쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을
|
||||
생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
|
||||
1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가
|
||||
명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면
|
||||
파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
|
||||
참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
|
||||
파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
|
||||
이것은 반드시 수동으로 해야한다.
|
||||
|
||||
### 파드 이름 레이블
|
||||
|
||||
스테이트풀셋 컨트롤러가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name`
|
||||
레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를
|
||||
연결할 수 있다.
|
||||
|
||||
## 디플로이먼트와 스케일링 보증
|
||||
|
||||
* N개의 레플리카가 있는 스테이트풀셋이 파드를 배포할 때 연속해서 {0..N-1}의 순서로 생성한다.
|
||||
* 파드가 삭제될 때는 {N-1..0}의 순서인 역순으로 종료된다.
|
||||
* 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
|
||||
* 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
|
||||
|
||||
스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
|
||||
|
||||
위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
|
||||
배포된다. web-1은 web-0이
|
||||
[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며,
|
||||
web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후,
|
||||
web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고,
|
||||
Running 및 Ready 상태가 되기 전까지 시작되지 않는다.
|
||||
|
||||
만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서
|
||||
스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기
|
||||
전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에
|
||||
web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
|
||||
되기 전까지 종료되지 않는다.
|
||||
|
||||
### 파드 관리 정책
|
||||
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를
|
||||
통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
|
||||
|
||||
#### OrderedReady 파드 관리
|
||||
|
||||
`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다.
|
||||
이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다.
|
||||
|
||||
#### 병렬 파드 관리
|
||||
|
||||
`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를
|
||||
병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나
|
||||
종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다.
|
||||
이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
|
||||
받지 않는다.
|
||||
|
||||
## 업데이트 전략
|
||||
|
||||
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
|
||||
파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
|
||||
구성하거나 비활성화 할 수 있다.
|
||||
|
||||
### 삭제 시(On Delete)
|
||||
|
||||
`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
|
||||
`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
|
||||
스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
|
||||
`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
|
||||
|
||||
### 롤링 업데이트
|
||||
|
||||
`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
|
||||
구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
|
||||
스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
|
||||
순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
|
||||
각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
|
||||
때까지 기다린다.
|
||||
|
||||
#### 파티션(Partition)
|
||||
|
||||
`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
|
||||
를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
|
||||
업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다.
|
||||
파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며,
|
||||
삭제 된 경우라도 이전 버전에서 재생성된다.
|
||||
만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이
|
||||
`.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다.
|
||||
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
|
||||
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
|
||||
|
||||
#### 강제 롤백
|
||||
|
||||
기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
|
||||
함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
|
||||
직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다.
|
||||
|
||||
만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는
|
||||
경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한)
|
||||
스테이트풀셋은 롤아웃을 중지하고 기다린다.
|
||||
|
||||
이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다.
|
||||
[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로
|
||||
인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며
|
||||
작동하는 구성으로 되돌아가는 시도를 하기
|
||||
전까지 기다린다.
|
||||
|
||||
템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
|
||||
실행하려고 시도한 모든 파드를 삭제해야 한다.
|
||||
그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
|
||||
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user