whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fourth Korean l10n work for release-1.15 (#16063)

Browse Source 
* ko: update translation in reference/glossary/* (#15776)
* Update outdated files partly in dev-1.15-ko.4 (#15856)
* ko: update translation in tasks/debug-application-cluster/resource-metrics-pipeline (#15798)
* ko: translate setup/production-environment/tools/control-plane-flags (#15820)
* ko: translate user-guide-windows-containers (#15730)
* ko: update translation in reference/glossary/* (#15761)
* ko: Update outdated files partly in dev-1.15-ko.4 (#15790)
* ko: fix corrupt date in glossary/static-pod (#15911)
* ko: translate user-guide-windows-nodes (#15759)
* Translate /docs/concepts/configuration/overview/ in Korean (#15803)
* ko: translate setup/production-environment/tools/ha-topology (#15819)
* ko: translate tasks/administer-cluster/network-policy-provider (#15846)
* Translate tasks/inject-data-application/define-command-argument-container in Korea (#15933)
* ko: translate concepts/configuration/organize-cluster-access-kubeconfig (#15871)
* Translate working-with-objects/common-labels.md in Korean (#15832)
* Translate concepts/workloads/pods/disruptions.md in Korean (#15926)
* Translate tasks/access-application-cluster/web-ui/dashboard in Korean (#15852)
* Translate concepts/overview/working-with-objects/labels.md in Korean (#15831)
* ko: translate guestbook-logs-metrics-with-elk (#15894)
* ko: translate tasks/administer-cluster/highly-available-master (#15928)

Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Eden <longlg88@naver.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-By: alice_k106 <alice_k106@naver.com>
Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
This commit is contained in:
Seokho Son
2019-08-25 20:10:21 +09:00
committed by Kubernetes Prow Robot
parent 270aaf1f16
commit c82a912e29
57 changed files with 2893 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/pods/disruptions.md
+252
View File
@@ -0,0 +1,252 @@
---
title: 중단(disruption)
content_template: templates/concept
weight: 60
---
{{% capture overview %}}
이 가이드는 고가용성 애플리케이션을 구성하려는 소유자와
파드에서 발생하는 장애 유형을 이해하기
원하는 애플리케이션 소유자를 위한 것이다.
또한 클러스터의 업그레이드와 오토스케일링과 같은
클러스터의 자동화 작업을 하려는 관리자를 위한 것이다.
{{% /capture %}}
{{% capture body %}}
## 자발적 중단과 비자발적 중단
파드는 누군가(사람 또는 컨트롤러)가 파괴하거나
불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다.
우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다.
예시:
- 노드를 지원하는 물리 머신의 하드웨어 오류
- 클러스터 관리자의 실수로 VM(인스턴스) 삭제
- 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
- 커널 패닉
- 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다.
우리는 다른 상황을 *자발적인 중단* 으로 부른다.
여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다.
다음은 대표적인 애플리케이션 소유자의 작업이다.
- 디플로이먼트 제거 또는 다른 파드를 관리하는 컨트롤러의 제거
- 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트
- 파드를 직접 삭제(예: 우연히)
클러스터 관리자의 작업:
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
클러스터 호스팅 공급자에 의해서도 수행된다.
클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지
클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다.
만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다.
{{< caution >}}
모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다.
예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다.
{{< /caution >}}
## 중단 다루기
비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다.
- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는
영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에
애플리케이션을 분산해야 한다.
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을
실행 할 수 있는 기능을 제공한다.
우리는 이 기능을 *Disruption Budgets* 이라 부른다.
## Disruption Budgets의 작동 방식
애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
예를 들어 정족수 기반의 애플리케이션이
실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다.
예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다.
클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다.
해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다.
축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나
설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다.
파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다.
컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다.
PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
버짓이 차감된다.
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.)
파드를 Eviction API로 축출하면 정상적으로 종료된다.
([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)
## PDB 예시
`node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자.
클러스터에는 여러 애플리케이션을 실행하고 있다.
여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다.
초기에 파드는 다음과 같이 배치된다.
| node-1 | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| pod-a *available* | pod-b *available* | pod-c *available* |
| pod-x *available* | | |
전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자.
클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다.
`kubectl` 은 `pod-a` 과 `pod-x` 를 축출하려고 한다. 이는 즉시 성공한다.
두 파드는 동시에 `terminating` 상태로 진입한다.
이렇게 하면 클러스터는 다음의 상태가 된다.
| node-1 *draining* | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| pod-a *terminating* | pod-b *available* | pod-c *available* |
| pod-x *terminating* | | |
디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다.
`node-1` 은 차단되어 있어 다른 노드에 위치한다.
무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다.
(참고: 스테이트풀 셋은 `pod-1`처럼 불릴, `pod-a`를
교체하기 전에 완전히 중지해야 하며, `pod-1` 로 불리지만, 다른 UID로 생성된다.
그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.)
이제 클러스터는 다음과 같은 상태이다.
| node-1 *draining* | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| pod-a *terminating* | pod-b *available* | pod-c *available* |
| pod-x *terminating* | pod-d *starting* | pod-y |
어느 순간 파드가 종료되고, 클러스터는 다음과 같은 상태가 된다.
| node-1 *drained* | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| | pod-b *available* | pod-c *available* |
| | pod-d *starting* | pod-y |
이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을
비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고,
PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다.
이제 클러스터는 다음과 같은 상태이다.
| node-1 *drained* | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| | pod-b *available* | pod-c *available* |
| | pod-d *available* | pod-y |
이제 클러스터 관리자는 `node-2` 를 비우려고 한다.
drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다.
drain 커멘드는 `pod-b`를 축출하는데 성공했다.
그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우
디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다.
디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다.
클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에
드레이닝 명령어는 차단된다.
클러스터는 다음 상태로 끝나게 된다.
| node-1 *drained* | node-2 | node-3 | *no node* |
|:--------------------:|:-------------------:|:------------------:|:------------------:|
| | pod-b *available* | pod-c *available* | pod-e *pending* |
| | pod-d *available* | pod-y | |
이 시점에서 클러스터 관리자는
클러스터에 노드를 추가해서 업그레이드를 진행해야 한다.
쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지
다음의 사례를 통해 알 수 있다.
- 애플리케이션에 필요한 레플리카의 수
- 인스턴스를 정상적으로 종료하는데 소요되는 시간
- 새 인스턴스를 시작하는데 소요되는 시간
- 컨트롤러의 유형
- 클러스터의 리소스 용량
## 클러스터 소유자와 애플리케이션 소유자의 역할 분리
보통 클러스터 매니저와 애플리케이션 소유자는
서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다.
이와 같은 책임의 분리는
다음의 시나리오에서 타당할 수 있다.
- 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우
- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우
Pod Disruption Budgets는 역할 분리에 따라
역할에 맞는 인터페이스를 제공한다.
만약 조직에 역할 분리에 따른 책임의 분리가 없다면
Pod Disruption Budgets를 사용할 필요가 없다.
## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법
만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은
중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다.
- 업그레이드 하는 동안 다운타임을 허용한다.
- 다른 레플리카 클러스터로 장애조치를 한다.
- 다운타임은 없지만, 노드 사본과
전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다.
- PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다.
- 다운타임 없음
- 최소한의 리소스 중복
- 클러스터 관리의 자동화 확대 적용
- 내결함성이 있는 애플리케이션의 작성은 까다롭지만
자발적 중단를 허용하는 작업의 대부분은 오토스케일링과
비자발적 중단를 지원하는 작업과 겹친다.
{{% /capture %}}
{{% capture whatsnext %}}
* [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다.
* [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기
{{% /capture %}}
content/ko/docs/concepts/workloads/pods/pod-overview.md
+1 -1
View File
@@ -19,7 +19,7 @@ card:
파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함.
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다.
쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다.
content/ko/docs/concepts/workloads/pods/pod.md
+2 -2
View File
@@ -139,7 +139,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
위와 같은 기능 제공을 할 수 있다.
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
@@ -176,7 +176,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
### 파드 강제 삭제
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, apiserver는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다.
노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.