Seventh Korean L10n Work for Release 1.16 (#18494)
* (fix) Broken links in Korean documentation. (#18179) * Modified link between Korean documents. (#18152) * Update to outdated files in the dev-1.16-ko.7 (#18146) * Updates to documents that do not reflect the original text - 1.16 (#18166) * Update path of referenced links in translated documents - 1.16. (#18164) Co-Authored-By: Oleg Butuzov <butuzov@users.noreply.github.com> Co-Authored-By: Seokho Son <shsongist@gmail.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com> Co-authored-by: Seokho Son <shsongist@gmail.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
c2ff814a1c
commit
21f774fd23
@@ -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/) 와 같은 노드 모니터링 데몬의 실행.
|
||||
|
||||
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
|
||||
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
|
||||
|
||||
@@ -277,7 +277,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
|
||||
원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
|
||||
기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
|
||||
하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
|
||||
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다.
|
||||
컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
|
||||
이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
|
||||
|
||||
### 레플리카셋에서 파드 격리
|
||||
|
||||
@@ -16,7 +16,7 @@ weight: 20
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
|
||||
[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
|
||||
{{< /note >}}
|
||||
|
||||
_레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가
|
||||
@@ -143,7 +143,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
|
||||
|
||||
### 파드 셀렉터
|
||||
|
||||
`.spec.selector` 필드는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
|
||||
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
|
||||
직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
|
||||
삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
|
||||
레플리케이션 컨트롤러를 교체할 수 있다.
|
||||
@@ -257,14 +257,14 @@ API 오브젝트에 대한 더 자세한 것은
|
||||
|
||||
### 레플리카셋
|
||||
|
||||
[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 이다.
|
||||
이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
|
||||
[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
|
||||
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
|
||||
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
|
||||
|
||||
|
||||
### 디플로이먼트 (권장되는)
|
||||
|
||||
[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
|
||||
[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
|
||||
`kubectl rolling-update` 와는 다르게 선언적이며, 서버 사이드이고,
|
||||
추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
|
||||
|
||||
@@ -280,12 +280,12 @@ API 오브젝트에 대한 더 자세한 것은
|
||||
### 데몬셋
|
||||
|
||||
머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
|
||||
[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
|
||||
[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
|
||||
다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
|
||||
머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
|
||||
|
||||
## 더 자세한 정보는
|
||||
|
||||
[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
|
||||
[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -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