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

Sixth Korean l10n work for release-1.16 (#17962)

Browse Source 
* Update _index.md (#17762)
* Update apparmor.md (#17767)
* Update hello-minikube.md (#17771)
* Update guestbook.md (#17773)
* Update localization_ko.md (#17777)
* Fix grammatical errors (#17776)
* Translate /docs/reference/issues-security/security.md in Korea (#17763)
* Create issues.md (#17765)
* Update basic-stateful-set.md (#17774)
* Fixed typo ko/docs/concepts/overview/components.md (#17778)
* Modify typo. (#17802)
* Update cloud-controller.md (#17760)
* Update file outdated korean docs in dev-1.16-ko.6. (#17772)
* Translate concepts/services-networking/ingress-controller in Korean (#17858)
* Update ingress-controller.md
* Translate services-networking/ingress.md in Korean. (#17807)
* Fix grammatical errors (#17775)
* Translate docs/contribute/style/write-new-topic.md in Korean (#17758)

Co-Authored-By: const-k <kss07120@gmail.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: power8993 <37264128+power8993@users.noreply.github.com>
Co-Authored-By: reung37 <49059415+reung37@users.noreply.github.com>
Co-Authored-By: Chihoon-Sung <55041611+Chihoon-Sung@users.noreply.github.com>
Co-Authored-By: Claudia J.Kang <claudiajkang@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
This commit is contained in:
June Yi
2019-12-06 15:12:49 +09:00
committed by Kubernetes Prow Robot
parent cc79282861
commit cb559f13c2
33 changed files with 913 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+21 -21
View File
@@ -66,7 +66,7 @@ weight: 10
kubectl get pods -w -l app=nginx
```
두번째 터미널에서
두 번째 터미널에서
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로
`web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다.
@@ -92,7 +92,7 @@ web 2 1 20s
### 차례대로 파드 생성하기
N개의 레플리카를 가진 스테이트풀셋은 배포시에
N개의 레플리카를 가진 스테이트풀셋은 배포 시에
순차적으로 {0..N-1} 순으로 생성된다.
첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자.
결국 그 내용은 아래 예와 비슷할 것이다.
@@ -179,7 +179,7 @@ SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지
```shell
kubectl get pod -w -l app=nginx
```
두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해
두 번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기 위해
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를
이용하자.
@@ -234,7 +234,7 @@ Address 1: 10.244.2.8
스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다.
스테이트풀셋의 활성 맴버를 찾아 연결할 경우
스테이트풀셋의 활성 멤버를 찾아 연결할 경우
헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다.
CNAME과 연관된 SRV 레코드는 스테이트풀셋의
Running과 Ready 상태의 모든 파드들을
@@ -295,15 +295,15 @@ for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done
kubectl get pod -w -l app=nginx
```
두번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자.
두 번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자.
```shell
kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
```
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
모든 파드가 Running과 Ready 상태로 전환될때까지 기다리자.
첫 번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
모든 파드가 Running과 Ready 상태로 전환될 때까지 기다리자.
```shell
kubectl get pod -w -l app=nginx
@@ -353,8 +353,8 @@ kubectl scale sts web --replicas=5
statefulset.apps/web scaled
```
첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
3개의 추가 파드가 Running과 Ready 상태로 전환될때까지 기다리자.
첫 번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고,
3개의 추가 파드가 Running과 Ready 상태로 전환될 때까지 기다리자.
```shell
kubectl get pods -w -l app=nginx
@@ -379,7 +379,7 @@ web-4 1/1 Running 0 19s
스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는
각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
이전 파드가 Running과 Ready 상태가 될때까지
이전 파드가 Running과 Ready 상태가 될 때까지
기다린다.
### 스케일 다운 {#scaling-down}
@@ -418,7 +418,7 @@ web-3 1/1 Terminating 0 42s
### 순차 파드 종료
컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고
컨트롤러는 순번의 역순으로 한 번에 1개 파드를 삭제하고
다음 파드를 삭제하기 전에
각각이 완전하게 종료되기까지 기다린다.
@@ -508,7 +508,7 @@ web-0 1/1 Running 0 10s
스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다.
이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에
그것이 Running과 Ready 상태로 전환될때까지 기다린다.
그것이 Running과 Ready 상태로 전환될 때까지 기다린다.
알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지
다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다.
업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는
@@ -703,7 +703,7 @@ k8s.gcr.io/nginx-slim:0.7
`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서
업데이트 처리를 하도록 허용하였다.
### 삭제시 동작
### 삭제 시 동작
`OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로,
이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의
@@ -769,7 +769,7 @@ web-2 1/1 Running 0 7m
kubectl get pods -w -l app=nginx
```
두번째 터미널에서 스테이트풀셋을 다시 생성하자.
두 번째 터미널에서 스테이트풀셋을 다시 생성하자.
`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를
볼 것이라는 것을 명심하자.
@@ -800,7 +800,7 @@ web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
```
`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다.
`web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다.
`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
`web-0`을 재생성했다면 `web-1`이
@@ -816,7 +816,7 @@ web-0
web-1
```
스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던
스테이트풀셋과 `web-0` 파드를 둘 다 삭제했으나 여전히 `index.html` 파일에 입력했던
원래 호스트네임을 제공한다. 스테이트풀셋은
파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다.
다시 스테이트풀셋을 생성하면 `web-0`을 시작하며
@@ -838,7 +838,7 @@ kubectl delete statefulset web
statefulset.apps "web" deleted
```
첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고
모든 파드가 Terminating 상태로 전환될때까지 기다리자.
모든 파드가 Terminating 상태로 전환될 때까지 기다리자.
```shell
kubectl get pods -w -l app=nginx
@@ -958,9 +958,9 @@ web-0 1/1 Running 0 10s
web-1 1/1 Running 0 10s
```
스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘다 동시에 시작했다.
스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘 다 동시에 시작했다.
두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을
스케일링 하자.
```shell
@@ -980,8 +980,8 @@ web-3 1/1 Running 0 26s
```
스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다.
두번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 떄까지 기다리지 않는다.
스테이트풀 컨트롤러는 두 개의 새 파드를 시작하였다.
두 번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 때까지 기다리지 않는다.
이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자.
content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+2 -2
View File
@@ -15,7 +15,7 @@ card:
[퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
{{< warning >}}
이 배포는 프로덕션 사용예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자.
이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자.
{{< /warning >}}
{{< note >}}
@@ -221,7 +221,7 @@ kubectl apply -k ./
{{% capture cleanup %}}
1. 다음 명령을 실핼하여 시크릿, 디플로이먼트, 서비스와 퍼시스턴트볼륨클레임을 삭제하자.
1. 다음 명령을 실행하여 시크릿, 디플로이먼트, 서비스와 퍼시스턴트볼륨클레임을 삭제하자.
```shell
kubectl delete -k ./
content/ko/docs/tutorials/stateful-application/zookeeper.md
+16 -16
View File
@@ -13,7 +13,7 @@ weight: 40
{{% capture prerequisites %}}
이 튜토리얼을 시작하지 전에
이 튜토리얼을 시작하기 전에
다음 쿠버네티스 개념에 친숙해야 한다.
- [파드](/docs/user-guide/pods/single-container/)
@@ -26,7 +26,7 @@ weight: 40
- [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
- [kubectl CLI](/docs/user-guide/kubectl/)
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시적으로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 주는 혼란이 발생하지 않도록 해야합니다.
최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다.
그렇게 설정되어 있지 않다면
@@ -38,7 +38,7 @@ weight: 40
이 튜토리얼을 마치면 다음에 대해 알게 된다.
- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
- 어떻게 지속적으로 컨피그맵을 이용해서 앙상블을 설정하는가.
- 어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가.
- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
- 어떻게 파드디스룹션버짓을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
{{% /capture %}}
@@ -55,7 +55,7 @@ ZooKeeper는 데이터를 읽고 쓰고 갱신을 지켜보도록 한다. 데이
[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) 합의 프로토콜을
이용하여 앙상블 내에 모든 서버에 걸쳐 상태 머신을 복제하여 이를 보장한다.
앙상블은 리더 선출을 위해 Zab 프로토콜을 사용하고, 리더 선출과 선거가 완료되기 전까지 앙상블은 데이터를 쓸 수 없다. 완료되면 앙상블은 Zab을 이용하여 확인하고 클라이언트에 보여지도록 모든 쓰기를 쿼럼(quorum)에 복제한다. 가중치있는 쿼럼과 관련없이, 쿼럼은 현재 리더를 포함하는 앙상블의 대다수 컴포넌트이다. 예를 들어 앙상블이 3개 서버인 경우, 리더와 다른 서버로 쿼럼을 구성한다. 앙상블이 쿼럼을 달성할 수 없다면, 앙상블은 데이터를 쓸 수 없다.
앙상블은 리더 선출을 위해 Zab 프로토콜을 사용하고, 리더 선출과 선거가 완료되기 전까지 앙상블은 데이터를 쓸 수 없다. 완료되면 앙상블은 Zab을 이용하여 확인하고 클라이언트에 보이도록 모든 쓰기를 쿼럼(quorum)에 복제한다. 가중치있는 쿼럼과 관련 없이, 쿼럼은 현재 리더를 포함하는 앙상블의 대다수 컴포넌트이다. 예를 들어 앙상블이 3개 서버인 경우, 리더와 다른 서버로 쿼럼을 구성한다. 앙상블이 쿼럼을 달성할 수 없다면, 앙상블은 데이터를 쓸 수 없다.
ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변이를 저장 미디어의 내구성 있는 WAL(Write Ahead Log)에 기록한다. 서버 장애시 WAL을 재생하여 이전 상태를 복원할 수 있다. WAL이 무제한으로 커지는 것을 방지하기 위해 ZooKeeper는 주기적으로 저장 미디어에 메모리 상태의 스냅샷을 저장한다. 이 스냅샷은 메모리에 직접 적재할 수 있고 스냅샷 이전의 모든 WAL 항목은 삭제될 수 있다.
@@ -507,7 +507,7 @@ 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) 명령을 이용하자.
@@ -515,7 +515,7 @@ log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-
kubectl logs zk-0 --tail 20
```
`kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰여진 애플리케이션 로그를 볼 수 있다.
`kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰인 애플리케이션 로그를 볼 수 있다.
```shell
2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
@@ -546,11 +546,11 @@ kubectl logs zk-0 --tail 20
클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해
[사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다.
### 권한없는 사용자를 위해 구성하기
### 권한 없는 사용자를 위해 구성하기
컨테이너 내부의 권한있는 유저로 애플리케이션을 실행할 수 있도록 하는
최상의 방법은 논쟁거리이다.
조직에서 애플리케이션을 권한없는 사용자가 실행한다면,
조직에서 애플리케이션을 권한 없는 사용자가 실행한다면,
진입점을 실행할 사용자를 제어하기 위해
[시큐리티컨텍스트](/docs/tasks/configure-pod-container/security-context/)를 이용할 수 있다.
@@ -632,7 +632,7 @@ Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision zk-5db4499664...
```
이것은 파드를 역순으로 한번에 하나씩 종료하고, 새로운 구성으로 재생성한다. 이는 롤링업데이트 동안에 쿼럼을 유지하도록 보장한다.
이것은 파드를 역순으로 한 번에 하나씩 종료하고, 새로운 구성으로 재생성한다. 이는 롤링업데이트 동안에 쿼럼을 유지하도록 보장한다.
이력과 이전 구성을 보기 위해 `kubectl rollout history` 명령을 이용하자.
@@ -661,13 +661,13 @@ statefulset.apps/zk rolled back
이것이 기본 값이다. 상태가 유지되는 애플리케이션을 위해
기본 정책을 **절대로** 변경하지 말자.
`zk-0` 파드에서 실행중인 ZooKeeper 서버에서 프로세스 트리를 살펴보기 위해 다음 명령어를 이용하자.
`zk-0` 파드에서 실행 중인 ZooKeeper 서버에서 프로세스 트리를 살펴보기 위해 다음 명령어를 이용하자.
```shell
kubectl exec zk-0 -- ps -ef
```
컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되엇으며
컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며
ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다.
```shell
UID PID PPID C STIME TTY TIME CMD
@@ -772,7 +772,7 @@ zk-0 1/1 Running 1 1h
준비도는 활성도와 동일하지 않다. 프로세스가 살아 있다면, 스케쥴링되고 건강하다.
프로세스가 준비되면 입력을 처리할 수 있다. 활성도는 필수적이나 준비도의 조건으로는
충분하지 않다. 몇몇의 경우
충분하지 않다. 몇몇 경우
특별히 초기화와 종료 시에 프로세스는 살아있지만
준비되지 않을 수 있다.
@@ -855,7 +855,7 @@ kubernetes-node-2g2d
**이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면,
다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.**
이전 섹션은 계획되지 않은 노드 실패에서 살아 남도록
이전 섹션은 계획되지 않은 노드 실패에서 살아남도록
어떻게 파드를 확산할 것인가에 대해 알아보았다.
그러나 계획된 점검으로 인해 발생하는 일시적인 노드 실패에 대한 계획도 필요하다.
@@ -996,7 +996,7 @@ kubectl 을 종료하기 위해 `CTRL-C`를 이용하자.
kubectl exec zk-0 zkCli.sh get /hello
```
`PodDisruptionBudget`이 존중되기 떄문에 서비스는 여전히 가용하다.
`PodDisruptionBudget`이 존중되기 때문에 서비스는 여전히 가용하다.
```shell
WatchedEvent state:SyncConnected type:None path:null
@@ -1071,7 +1071,7 @@ node "kubernetes-node-i4c4" drained
이번엔 `kubectl drain` 이 성공한다.
`zk-2`가 재스케줄되도록 두번째 노드의 통제를 풀어보자.
`zk-2`가 재스케줄되도록 두 번째 노드의 통제를 풀어보자.
```shell
kubectl uncordon kubernetes-node-ixsl
@@ -1081,7 +1081,7 @@ kubectl uncordon kubernetes-node-ixsl
node "kubernetes-node-ixsl" uncordoned
```
`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
`kubectl drain`을 `PodDisruptionBudget`과 결합하면 유지보수 중에도 서비스를 가용하게 할 수 있다. drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인하기 전에 파드를 추출하기 위해 사용한다면 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다. 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
{{% /capture %}}
{{% capture cleanup %}}