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
@@ -223,13 +223,14 @@ rules:
|
||||
|
||||
다음은 클라우드 제공사업자들이 구현한 CCM들이다.
|
||||
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
|
||||
## 클러스터 관리
|
||||
|
||||
|
||||
@@ -190,9 +190,20 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
|
||||
|
||||
파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
|
||||
|
||||
## 노드 토폴로지
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
`TopologyManager`
|
||||
[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
|
||||
|
||||
## API 오브젝트
|
||||
|
||||
노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한 보다 자세한 내용은 [노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* [노드 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/#node-components)에 대해 읽기
|
||||
* 노드 수준 토폴로지에 대해 읽기: [노드의 토폴로지 정책 제어하기](/docs/tasks/administer-cluster/topology-manager/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -54,10 +54,9 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
|
||||
연관된 문서를 통해서 확인한다([아래](#cri-configuration)).
|
||||
|
||||
{{< note >}}
|
||||
런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
|
||||
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
|
||||
설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
|
||||
([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
|
||||
런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
|
||||
(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
|
||||
이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
|
||||
@@ -144,6 +143,42 @@ https://github.com/containerd/cri/blob/master/docs/config.md
|
||||
더 자세한 cri-o의 구성 문서를 살펴본다.
|
||||
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
|
||||
|
||||
### 스케줄
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다.
|
||||
이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다.
|
||||
이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
|
||||
|
||||
파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
|
||||
해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
|
||||
런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로
|
||||
각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.
|
||||
|
||||
지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면,
|
||||
`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시
|
||||
해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된
|
||||
노드의 합집합을 취한다.
|
||||
|
||||
노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
|
||||
[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다.
|
||||
|
||||
[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/
|
||||
|
||||
### 파드 오버헤드
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를
|
||||
지정할 수 있는 기능이 [`PodOverhead`](/docs/concepts/configuration/pod-overhead.md) 기능을 통해 지원된다.
|
||||
`PodOverhead`를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.)
|
||||
|
||||
|
||||
파드 오버헤드는 런타임 클래스에서 `Overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
|
||||
해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
|
||||
쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
|
||||
|
||||
### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
|
||||
|
||||
@@ -172,4 +207,11 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
|
||||
더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
|
||||
(위를 참조).
|
||||
|
||||
### 더 읽기
|
||||
|
||||
- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
|
||||
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -148,7 +148,7 @@ _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할
|
||||
|
||||
### LIST와 WATCH 필터링
|
||||
|
||||
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
|
||||
LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
|
||||
|
||||
* _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
@@ -181,11 +181,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
|
||||
[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
|
||||
|
||||
#### 서비스와 리플리케이션 컨트롤러
|
||||
#### 서비스와 레플리케이션 컨트롤러
|
||||
|
||||
`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
||||
`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
|
||||
|
||||
서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
||||
서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
|
||||
|
||||
```json
|
||||
"selector": {
|
||||
|
||||
@@ -27,16 +27,16 @@ weight: 30
|
||||
|
||||
네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
|
||||
|
||||
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 제어 정책을 갖게 된다.
|
||||
다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근 제어 정책을 갖게 된다.
|
||||
네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
|
||||
|
||||
같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
|
||||
복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
|
||||
구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
|
||||
구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
|
||||
|
||||
## 네임스페이스 다루기
|
||||
|
||||
네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
|
||||
네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
|
||||
기술되어 있다.
|
||||
|
||||
### 네임스페이스 조회
|
||||
@@ -94,7 +94,7 @@ kubectl config view | grep namespace:
|
||||
|
||||
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
|
||||
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
|
||||
그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
|
||||
그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
|
||||
네임스페이스에도 속하지 않는다.
|
||||
|
||||
네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "서비스, 로드밸런싱, 네트워킹"
|
||||
weight: 60
|
||||
---
|
||||
@@ -0,0 +1,273 @@
|
||||
---
|
||||
title: 서비스 및 파드용 DNS
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 소개
|
||||
|
||||
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
|
||||
개별 컨테이너들이 DNS 네임을 해석할 때
|
||||
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
|
||||
|
||||
### DNS 네임이 할당되는 것들
|
||||
|
||||
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
|
||||
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
|
||||
클러스터의 기본 도메인을 포함한다.
|
||||
이 예시는 다음과 같다.
|
||||
|
||||
쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는
|
||||
단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다.
|
||||
네임스페이스 `quux`에서 실행 중인 파드는
|
||||
`foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다.
|
||||
|
||||
다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다.
|
||||
이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다.
|
||||
최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다.
|
||||
|
||||
[쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
|
||||
|
||||
## 서비스
|
||||
|
||||
### A 레코드
|
||||
|
||||
"노멀"(헤드리스가 아닌) 서비스는
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다.
|
||||
|
||||
"헤드리스"(클러스터 IP가 없는) 서비스 또한
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`
|
||||
형식의 이름을 가진 DNS A 레코드가 할당된다.
|
||||
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
|
||||
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다.
|
||||
|
||||
### SRV 레코드
|
||||
|
||||
SRV 레코드는 노멀 서비스 또는
|
||||
[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에
|
||||
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
|
||||
`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
|
||||
포트 번호와 도메인 이름을 포함한다.
|
||||
`auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
|
||||
|
||||
## 파드
|
||||
|
||||
### 파드의 hostname 및 subdomain 필드
|
||||
|
||||
파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다.
|
||||
|
||||
파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다.
|
||||
이 필드는 파드의 호스트네임을 지정할 수 있다.
|
||||
`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
|
||||
예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다.
|
||||
|
||||
또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다.
|
||||
예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고,
|
||||
`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
|
||||
"`foo.bar.my-namespace.svc.cluster-domain.example`".
|
||||
|
||||
예시:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: default-subdomain
|
||||
spec:
|
||||
selector:
|
||||
name: busybox
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: foo # 사실 포트는 필요하지 않다.
|
||||
port: 1234
|
||||
targetPort: 1234
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox1
|
||||
labels:
|
||||
name: busybox
|
||||
spec:
|
||||
hostname: busybox-1
|
||||
subdomain: default-subdomain
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
name: busybox
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox2
|
||||
labels:
|
||||
name: busybox
|
||||
spec:
|
||||
hostname: busybox-2
|
||||
subdomain: default-subdomain
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
name: busybox
|
||||
```
|
||||
|
||||
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
|
||||
클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다.
|
||||
예를 들어 호스트네임이 "`busybox-1`"이고,
|
||||
서브도메인이 "`default-subdomain`"이고,
|
||||
같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면,
|
||||
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
|
||||
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`".
|
||||
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다.
|
||||
"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다.
|
||||
|
||||
엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
A 레코드는 파드의 이름으로 생성되지 않기 때문에
|
||||
파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다.
|
||||
`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
|
||||
A 레코드만 생성할 수 있다.
|
||||
(`default-subdomain.my-namespace.svc.cluster-domain.example`)
|
||||
또한 레코드를 가지기 위해서는 파드가 준비되어야 한다.
|
||||
그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다.
|
||||
{{< /note >}}
|
||||
|
||||
### 파드의 DNS 정책
|
||||
|
||||
DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
|
||||
이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다.
|
||||
|
||||
- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
|
||||
자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
|
||||
에서 확인할 수 있다.
|
||||
- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과
|
||||
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
|
||||
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
|
||||
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
|
||||
[관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
|
||||
에서 확인할 수 있다.
|
||||
- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
|
||||
"`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다.
|
||||
- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
|
||||
모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다.
|
||||
아래 절인
|
||||
[파드의 DNS 설정](#파드의-dns-설정)
|
||||
에서 자세한 내용을 확인할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
|
||||
“ClusterFirst”가 기본값으로 사용된다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서
|
||||
DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: busybox
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- image: busybox:1.28
|
||||
command:
|
||||
- sleep
|
||||
- "3600"
|
||||
imagePullPolicy: IfNotPresent
|
||||
name: busybox
|
||||
restartPolicy: Always
|
||||
hostNetwork: true
|
||||
dnsPolicy: ClusterFirstWithHostNet
|
||||
```
|
||||
|
||||
### 파드의 DNS 설정
|
||||
|
||||
사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다.
|
||||
|
||||
`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다.
|
||||
이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다.
|
||||
|
||||
사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다.
|
||||
|
||||
- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다.
|
||||
파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는
|
||||
적어도 하나의 IP 주소가 포함되어야 하며,
|
||||
그렇지 않으면 이 속성은 생략할 수 있다.
|
||||
`nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다.
|
||||
- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
|
||||
이 속성은 생략이 가능하며,
|
||||
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
|
||||
병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
|
||||
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
|
||||
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
|
||||
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
|
||||
병합 시 중복되는 항목은 제거된다.
|
||||
|
||||
다음은 커스텀 DNS 세팅을 한 파드의 예시이다.
|
||||
|
||||
{{< codenew file="service/networking/custom-dns.yaml" >}}
|
||||
|
||||
위에서 파드가 생성되면,
|
||||
컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다.
|
||||
|
||||
```
|
||||
nameserver 1.2.3.4
|
||||
search ns1.svc.cluster-domain.example my.dns.search.suffix
|
||||
options ndots:2 edns0
|
||||
```
|
||||
|
||||
IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같아야 한다:
|
||||
|
||||
```shell
|
||||
kubectl exec -it dns-example -- cat /etc/resolv.conf
|
||||
```
|
||||
|
||||
출력은 다음과 같은 형식일 것이다.
|
||||
|
||||
```shell
|
||||
nameserver fd00:79:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
options ndots:5
|
||||
```
|
||||
|
||||
### 기능 지원 여부
|
||||
|
||||
파드 DNS 구성 및 DNS 정책 "`None`"에 대한 지원 정보는 아래에서 확인 할 수 있다.
|
||||
|
||||
| k8s 버전 | 기능 지원 |
|
||||
| :---------: |:-----------:|
|
||||
| 1.14 | 안정 |
|
||||
| 1.10 | 베타 (기본)|
|
||||
| 1.9 | 알파 |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
DNS 구성 관리에 대한 지침은
|
||||
[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)
|
||||
에서 확인 할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
@@ -101,21 +101,29 @@ kubelet은 컨테이너에 의해서 구현된
|
||||
* Failure: 컨테이너가 진단에 실패함.
|
||||
* Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
|
||||
|
||||
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고
|
||||
kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
|
||||
그에 반응할 수 있다.
|
||||
|
||||
* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약
|
||||
* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
|
||||
활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
|
||||
[재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가
|
||||
활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다.
|
||||
|
||||
* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
|
||||
* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
|
||||
만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
|
||||
파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
|
||||
초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를
|
||||
지원하지 않는다면, 기본 상태는 `Success`이다.
|
||||
|
||||
### 언제 활성 또는 준비성 프로브를 사용해야 하는가?
|
||||
* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
|
||||
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는
|
||||
활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
|
||||
컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업
|
||||
프로브가 없는 경우, 기본 상태는 `Success`이다.
|
||||
|
||||
### 언제 활성 프로브를 사용해야 하는가?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
|
||||
|
||||
만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한
|
||||
상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가
|
||||
@@ -125,6 +133,10 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
|
||||
프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
|
||||
지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
|
||||
|
||||
### 언제 준비성 프로브를 사용해야 하는가?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
|
||||
|
||||
프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다.
|
||||
이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만,
|
||||
스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서
|
||||
@@ -142,6 +154,13 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
|
||||
파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
|
||||
남아있는다.
|
||||
|
||||
### 언제 스타트업 프로브를 사용해야 하는가?
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다.
|
||||
이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
|
||||
|
||||
활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는,
|
||||
[활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user