First Korean L10n Work For Relase 1.17 (#18226)
* Modified link between Korean documents. (#18072) * Translate services-networking/connect-applications-service.md in Korean. (#18087) * Translate services-networking/service-topology.md in Korean. (#18096) * Update to outdated files in the dev-1.17-ko.1 (#18070) Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
f21f4b2257
commit
d60ca0bea2
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
|
||||
|
||||
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
|
||||
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
|
||||
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `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/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `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/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
|
||||
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
|
||||
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
|
||||
@@ -95,21 +95,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
|
||||
## 데몬 파드가 스케줄 되는 방법
|
||||
|
||||
### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함)
|
||||
### 기본 스케줄러로 스케줄
|
||||
|
||||
일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋
|
||||
컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이
|
||||
파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다.
|
||||
|
||||
- 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리)
|
||||
필드를 존중하지 않는다.
|
||||
- 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을
|
||||
도울 수도 있다.
|
||||
|
||||
|
||||
### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용)
|
||||
|
||||
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
|
||||
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
|
||||
|
||||
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
|
||||
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
|
||||
|
||||
@@ -44,10 +44,6 @@ weight: 40
|
||||
## 구성 요소
|
||||
아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
|
||||
|
||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -99,6 +95,12 @@ spec:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
위의 예시에서:
|
||||
|
||||
* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
|
||||
* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
|
||||
* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
|
||||
|
||||
## 파드 셀렉터
|
||||
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
|
||||
|
||||
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
|
||||
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)가
|
||||
클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
|
||||
아니라면 `cluster.local`로 설정된다.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -260,7 +262,7 @@ 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-stateless-application-deployment/)의 예시를 따른다.
|
||||
* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
|
||||
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
|
||||
처리하도록 확장될 수 있다.
|
||||
|
||||
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고
|
||||
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
`TTLAfterFinished` 를 통해 활성화 될 수 있다.
|
||||
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
|
||||
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user