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

First Korean l10n work for release-1.19

Browse Source 
- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
June Yi
2020-09-11 23:21:22 +09:00
parent 94b2f857bb
commit 986be3462d
102 changed files with 1943 additions and 2452 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tutorials/stateful-application/cassandra.md
+29 -17
View File
@@ -7,9 +7,13 @@ weight: 30
<!-- overview -->
이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다.
이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다.
데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_).
이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다.
*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다.
*스테이트풀셋* 은 상태있는 애플리케이션을 쿠버네티스 클러스터에 쉽게 배포할 수 있게 한다.
이 튜토리얼에서 이용할 기능의 자세한 정보는
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 참조한다.
{{< note >}}
카산드라와 쿠버네티스는 클러스터 맴버라는 의미로 _노드_ 라는 용어를 사용한다. 이
@@ -38,12 +42,17 @@ weight: 30
{{< include "task-tutorial-prereqs.md" >}}
이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다.
이 튜토리얼을 완료하려면,
{{< glossary_tooltip text="파드" term_id="pod" >}},
{{< glossary_tooltip text="서비스" term_id="service" >}},
{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다.
### 추가적인 Minikube 설정 요령
{{< caution >}}
[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.
[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다.
이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가
발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자.
```shell
minikube start --memory 5120 --cpus=4
@@ -51,11 +60,11 @@ minikube start --memory 5120 --cpus=4
{{< /caution >}}
<!-- lessoncontent -->
## 카산드라를 위한 헤드리스 서비스 생성하기 {#creating-a-cassandra-headless-service}
쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다.
쿠버네티스 에서 {{< glossary_tooltip text="서비스" term_id="service" >}}는 동일 작업을 수행하는
{{< glossary_tooltip text="파드" term_id="pod" >}}의 집합을 기술한다.
다음의 서비스는 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다.
@@ -83,14 +92,17 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cassandra ClusterIP None <none> 9042/TCP 45s
```
이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 [서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를 읽어보자.
`cassandra` 서비스가 보이지 않는다면, 이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한
[서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를
읽어보자.
## 카산드라 링을 생성하는 스테이트풀셋 이용하기
스테이트풀셋 매니페스트에는 다음을 포함하는데 3개 파드로 구성된 카산드라 링을 생성한다.
{{< note >}}
이 예는 Minikube를 위한 기본 프로비저너이다. 다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다.
이 예는 Minikube를 위한 기본 프로비저너이다.
다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다.
{{< /note >}}
{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
@@ -182,12 +194,13 @@ kubectl apply -f cassandra-statefulset.yaml
kubectl edit statefulset cassandra
```
이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다. 다음 예제는 스테이트풀셋 파일에서 발췌했다.
이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다.
다음 예제는 스테이트풀셋 파일에서 발췌했다.
```yaml
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
# 다음의 오브젝트를 수정한다. '#'로 시작하는 행은 무시되고,
# 빈 파일은 편집을 중단한다. 저장할 때 오류가 발생하면 이 파일이
# 관련 실패와 함께 다시 열린다.
#
apiVersion: apps/v1
kind: StatefulSet
@@ -225,10 +238,12 @@ kubectl apply -f cassandra-statefulset.yaml
## {{% heading "cleanup" %}}
스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다. 당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다.
스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다.
당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다.
{{< warning >}}
스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도 삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자.
스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도
삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자.
{{< /warning >}}
1. 다음 명령어(한 줄로 연결된)를 실행하여 카산드라 스테이트풀셋을 모두 제거하자.
@@ -271,6 +286,3 @@ kubectl apply -f cassandra-statefulset.yaml
* 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다.
* [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다.
* 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다.
content/ko/docs/tutorials/stateful-application/zookeeper.md
+36 -29
View File
@@ -7,25 +7,23 @@ weight: 40
<!-- overview -->
이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org)
쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과
[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과
[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)과
[파드안티어피니티(PodAntiAffinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다.
## {{% heading "prerequisites" %}}
이 튜토리얼을 시작하기 전에
다음 쿠버네티스 개념에 친숙해야 한다.
- [파드](/docs/user-guide/pods/single-container/)
- [파드](/ko/docs/concepts/workloads/pods/)
- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
- [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/)
- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
- [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
- [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)
- [kubectl CLI](/docs/user-guide/kubectl/)
- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
- [kubectl CLI](/docs/reference/kubectl/kubectl/)
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
@@ -42,7 +40,7 @@ weight: 40
- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
- 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가.
- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
- 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
<!-- lessoncontent -->
@@ -63,17 +61,17 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변
## ZooKeeper 앙상블 생성하기
아래 메니페스트에는
아래 매니페스트에는
[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스),
[서비스](/ko/docs/concepts/services-networking/service/),
[파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
[PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets),
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다.
{{< codenew file="application/zookeeper/zookeeper.yaml" >}}
터미널을 열고
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) 명령어로
메니페스트를 생성하자.
매니페스트를 생성하자.
```shell
kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
@@ -118,7 +116,7 @@ zk-2 1/1 Running 0 40s
```
스테이트풀셋 컨트롤러는 3개의 파드를 생성하고, 각 파드는
[ZooKeeper](http://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
### 리더 선출 촉진
@@ -339,7 +337,7 @@ zk-0 0/1 Terminating 0 11m
zk-0 0/1 Terminating 0 11m
```
`zookeeper.yaml` 메니페스트를 다시 적용한다.
`zookeeper.yaml` 매니페스트를 다시 적용한다.
```shell
kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
@@ -446,7 +444,7 @@ volumeMounts:
`zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을
ZooKeeper의 서버 디렉터리에 마운트한다.
파드를 재스케쥴할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와
파드를 재스케줄할 때에도 ZooKeeper의 WAL을 통해 이뤄진 모든 쓰기와
모든 그 스냅샷도 내구성을 유지한다.
## 일관된 구성 보장하기
@@ -456,7 +454,7 @@ ZooKeeper의 서버 디렉터리에 마운트한다.
ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다.
또한 Zab 프로토콜의 일관된 설정도
네트워크에 걸쳐 올바르게 동작하기 위해서
필요하다. 이 예시에서는 메니페스트에 구성을 직접 포함시켜서 일관된 구성을
필요하다. 이 예시에서는 매니페스트에 구성을 직접 포함시켜서 일관된 구성을
달성한다.
`zk` 스테이트풀셋을 살펴보자.
@@ -495,7 +493,7 @@ ZooKeeper 서버를 시작하는데 사용한 명령어는 커맨드라인 파
### 로깅 설정하기
`zkGenConfig.sh` 스크립트로 생성된 파일 중 하나는 ZooKeeper의 로깅을 제어한다.
ZooKeeper는 [Log4j](http://logging.apache.org/log4j/2.x/)를 이용하며
ZooKeeper는 [Log4j](https://logging.apache.org/log4j/2.x/)를 이용하며
기본 로깅 구성으로는 시간과 파일 크기 기준의 롤링 파일 어펜더를 사용한다.
`zk` `스테이트풀셋`의 한 파드에서 로깅 설정을 살펴보는 아래 명령어를 이용하자.
@@ -517,7 +515,10 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
```
이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다. 표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다. 또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여 로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다.
이는 컨테이너 내에서 안전하게 로깅하는 가장 단순한 방법이다.
표준 출력으로 애플리케이션 로그를 작성하면, 쿠버네티스는 로그 로테이션을 처리한다.
또한 쿠버네티스는 애플리케이션이 표준 출력과 표준 오류에 쓰인 로그로 인하여
로컬 저장 미디어가 고갈되지 않도록 보장하는 정상적인 보존 정책을 구현한다.
파드의 마지막 20줄의 로그를 가져오는 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/#logs) 명령을 이용하자.
@@ -787,7 +788,7 @@ zk-0 1/1 Running 1 1h
### 준비도 테스트
준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케쥴링되고 건강하다.
준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케줄링되고 건강하다.
프로세스가 준비되면 입력을 처리할 수 있다. 활성도는 필수적이나 준비도의 조건으로는
충분하지 않다. 몇몇 경우
특별히 초기화와 종료 시에 프로세스는 살아있지만
@@ -796,7 +797,7 @@ zk-0 1/1 Running 1 1h
준비도 검사를 지정하면, 쿠버네티스는 준비도가 통과할 때까지
애플리케이션 프로세스가 네트워크 트래픽을 수신하지 않게 한다.
ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 메니페스트에서
ZooKeeper 서버에서는 준비도가 활성도를 내포한다. 그러므로 `zookeeper.yaml` 매니페스트에서
준비도 검사는 활성도 검사와 동일하다.
```yaml
@@ -823,7 +824,9 @@ ZooKeeper는 변조된 데이터를 성공적으로 커밋하기 위한 서버
중단을 방지하기 위해 개별 시스템의 손실로 인해 모범 사례에서는 동일한 시스템에
여러 인스턴스의 응용 프로그램을 함께 배치하는 것을 배제한다.
기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다. 생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고 ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케쥴링될 때까지 작동 중단을 경험할 것이다.
기본적으로 쿠버네티스는 동일 노드상에 `스테이트풀셋`의 파드를 위치시킬 수 있다.
생성한 3개의 서버 앙상블에서 2개의 서버가 같은 노드에 있다면, 그 노드는 실패하고
ZooKeeper 서비스 클라이언트는 그 파드들의 최소 하나가 재스케줄링될 때까지 작동 중단을 경험할 것이다.
노드 실패하는 사건 중에도 중요 시스템의 프로세스가 재스케줄될 수 있게
항상 추가적인 용량을 프로비전해야 한다. 그렇게 하면 쿠버네티스 스케줄러가
@@ -909,7 +912,7 @@ zk-pdb N/A 1 1
kubectl get pods -w -l app=zk
```
다른 터미널에서 현재 스케쥴되는 파드의 노드를 살펴보자.
다른 터미널에서 현재 스케줄되는 파드의 노드를 살펴보자.
```shell
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
@@ -921,7 +924,7 @@ kubernetes-node-ixsl
kubernetes-node-i4c4
```
`zk-0`파드가 스케쥴되는 노드를 통제하기 위해
`zk-0`파드가 스케줄되는 노드를 통제하기 위해
[`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자.
```shell
@@ -937,7 +940,7 @@ node "kubernetes-node-group-pb41" drained
```
클러스터에 4개 노드가 있기 때문에 `kubectl drain`이 성공하여
`zk-0`을 다른 노드로 재스케쥴링 된다.
`zk-0`을 다른 노드로 재스케줄링 된다.
```
NAME READY STATUS RESTARTS AGE
@@ -957,7 +960,7 @@ zk-0 1/1 Running 0 1m
```
계속해서 `스테이트풀셋`의 파드를 첫 터미널에서 지켜보고
`zk-1` 이 스케쥴된 노드를 비워보자.
`zk-1` 이 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
@@ -969,7 +972,8 @@ pod "zk-1" deleted
node "kubernetes-node-ixsl" drained
```
`zk-1` 파드는 스케쥴되지 않는데 이는 `zk` `스테이트풀셋`이 오직 2개 노드가 스케쥴되도록 파드를 위치시키는 것을 금하는 `파드안티어피니티` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.
`zk-1` 파드는 스케줄되지 않는데 이는 `zk` `StatefulSet`이 오직 2개 노드가 스케줄되도록 파드를 위치시키는 것을 금하는
`PodAntiAffinity` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.
```shell
kubectl get pods -w -l app=zk
@@ -1051,7 +1055,7 @@ kubectl uncordon kubernetes-node-pb41
node "kubernetes-node-pb41" uncordoned
```
`zk-1`은 이 노드에서 재스케쥴된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자.
`zk-1`은 이 노드에서 재스케줄된다. `zk-1`이 Running과 Ready가 될 때까지 기다리자.
```shell
kubectl get pods -w -l app=zk
@@ -1083,7 +1087,7 @@ zk-1 0/1 Running 0 13m
zk-1 1/1 Running 0 13m
```
`zk-2`가 스케쥴된 노드를 비워보자.
`zk-2`가 스케줄된 노드를 비워보자.
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
@@ -1111,7 +1115,10 @@ kubectl uncordon kubernetes-node-ixsl
node "kubernetes-node-ixsl" uncordoned
```
`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다.
drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면
서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다.
파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
## {{% heading "cleanup" %}}