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

Sixth Korean l10n work for release 1.18

Browse Source 
- Update outdated files in dev-1.18-ko.6 partly (#21714)
- Translate StorageClass to Korean word (#21805)
- Translate StatefulSet to Korean word in pods.md (#21794)
- Translate tasks/run-application/delete-stateful-set/ in Korean (#21686)
- Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801)
- update outdated docs (#21940)
- Modify spacing term StatefulSet in Korean (#21871)
- Translate /tasks/administer-cluster/coredns in Korean (#21876)
- Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975)
- Translation error correction in /concepts/containers/runtime-class.md (#21868)
- Translate tasks/tls/certificate-rotation/ in Korean (#21838)
- Translate /tasks/configure-pod-container/static-pod in Korean (#21798)
- Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911)
- Fix English bugs in Korean documentation (#21994)
- Update outdated dev-1.18-ko.6 partly (#22067)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Jordy Ruiter <jordy.ruiter@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: Dajin Gwon <d.gweon@samsung.com>
Co-authored-by: Hyungseok Lee <hs0426.lee@samsung.com>
Co-authored-by: Jihoon Seo <jihoon.seo@etri.re.kr>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
2020-06-14 01:11:06 +09:00
parent a78456d87c
commit 34be3c1d39
133 changed files with 2074 additions and 1226 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/pods/disruptions.md
+61 -47
View File
@@ -9,7 +9,7 @@ weight: 60
파드에서 발생하는 장애 유형을 이해하기
원하는 애플리케이션 소유자를 위한 것이다.
또한 클러스터의 업그레이드와 오토스케일링과 같은
또한 클러스터의 업그레이드와 오토스케일링과 같은
클러스터의 자동화 작업을 하려는 관리자를 위한 것이다.
@@ -19,7 +19,7 @@ weight: 60
## 자발적 중단과 비자발적 중단
파드는 누군가(사람 또는 컨트롤러)가 파괴하거나
파드는 누군가(사람 또는 컨트롤러)가 파괴하거나
불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다.
우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다.
@@ -33,7 +33,8 @@ weight: 60
- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨
리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다.
왜냐하면
그 조건은 쿠버네티스에 국한되지 않기 때문이다.
우리는 다른 상황을 *자발적인 중단* 으로 부른다.
여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다.
@@ -46,19 +47,21 @@ weight: 60
클러스터 관리자의 작업:
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기).
- 클러스터의 스케일 축소를 위한
노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기
).
- 노드에 다른 무언가를 추가하기 위해 파드를 제거.
위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며,
클러스터 호스팅 공급자에 의해서도 수행된다.
클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지
클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지
클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다.
만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다.
{{< caution >}}
모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다.
예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다.
예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다.
{{< /caution >}}
## 중단 다루기
@@ -66,48 +69,58 @@ weight: 60
비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다.
- 파드가 필요로 하는 [리소스를 요청](/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) 이용) 또는
영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에
애플리케이션을 분산해야 한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
[스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
또는 영역 간
([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
애플리케이션을 분산해야 한다.
자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
또한 클러스터(노드) 오토스케일링의 일부 구현에서는
단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
클러스터 관리자 또는 호스팅 공급자는
예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을
실행 할 수 있는 기능을 제공한다.
실행 할 수 있는 기능을 제공한다.
우리는 이 기능을 *Disruption Budgets* 이라 부른다.
## Disruption Budgets의 작동 방식
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
예를 들어 정족수 기반의 애플리케이션이
PDB는 자발적 중단으로
일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
예를 들어 정족수 기반의 애플리케이션이
실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다.
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다.
예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다.
클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다.
해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다.
축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나
축출 요청은 일시적으로 거부될 수 있으며,
도구는 모든 파드가 종료되거나
설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면,
Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다.
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다.
파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다.
컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다.
@@ -116,7 +129,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
버짓이 차감된다.
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는
롤링 업데이트시 PDB의 제한을 받지 않는다.
애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)
@@ -126,7 +140,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
## PDB 예시
`node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자.
클러스터에는 여러 애플리케이션을 실행하고 있다.
클러스터에는 여러 애플리케이션을 실행하고 있다.
여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다.
초기에 파드는 다음과 같이 배치된다.
@@ -135,7 +149,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
| pod-a *available* | pod-b *available* | pod-c *available* |
| pod-x *available* | | |
전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
전체 3개 파드는 디플로이먼트의 일부분으로
전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다.
예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자.
클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다.
@@ -149,12 +164,12 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
| pod-x *terminating* | | |
디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다.
`node-1` 은 차단되어 있어 다른 노드에 위치한다.
`node-1` 은 차단되어 있어 다른 노드에 위치한다.
무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다.
(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를
(참고: 스테이트풀셋은 `pod-0` 처럼 불릴, `pod-a` 를
교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다.
그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.)
그렇지 않으면 이 예시는 스테이트풀셋에도 적용된다.)
이제 클러스터는 다음과 같은 상태이다.
@@ -170,9 +185,9 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
| | pod-b *available* | pod-c *available* |
| | pod-d *starting* | pod-y |
이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을
비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고,
PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다.
이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을
비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고,
PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d` 가 available 상태가 된다.
이제 클러스터는 다음과 같은 상태이다.
@@ -182,13 +197,13 @@ PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된
| | pod-d *available* | pod-y |
이제 클러스터 관리자는 `node-2` 를 비우려고 한다.
drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다.
drain 커멘드는 `pod-b`를 축출하는데 성공했다.
그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우
drain 커멘드는 `pod-b` 에서 `pod-d` 와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다.
drain 커멘드는 `pod-b` 를 축출하는데 성공했다.
그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우
디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다.
디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다.
클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에
디플로이먼트는`pod-b` 를 대체할 `pod-e` 라는 파드를 생성한다.
클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에
드레이닝 명령어는 차단된다.
클러스터는 다음 상태로 끝나게 된다.
@@ -200,7 +215,7 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다.
이 시점에서 클러스터 관리자는
클러스터에 노드를 추가해서 업그레이드를 진행해야 한다.
쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지
쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지
다음의 사례를 통해 알 수 있다.
- 애플리케이션에 필요한 레플리카의 수
@@ -211,28 +226,29 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다.
## 클러스터 소유자와 애플리케이션 소유자의 역할 분리
보통 클러스터 매니저와 애플리케이션 소유자는
보통 클러스터 매니저와 애플리케이션 소유자는
서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다.
이와 같은 책임의 분리는
이와 같은 책임의 분리는
다음의 시나리오에서 타당할 수 있다.
- 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우
- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우
- 타사 도구 또는 타사 서비스를 이용해서
클러스터 관리를 자동화 하는 경우
Pod Disruption Budgets는 역할 분리에 따라
Pod Disruption Budget은 역할 분리에 따라
역할에 맞는 인터페이스를 제공한다.
만약 조직에 역할 분리에 따른 책임의 분리가 없다면
Pod Disruption Budgets를 사용할 필요가 없다.
Pod Disruption Budget을 사용할 필요가 없다.
## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법
만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은
만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은
중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다.
- 업그레이드 하는 동안 다운타임을 허용한다.
- 다른 레플리카 클러스터로 장애조치를 한다.
- 다운타임은 없지만, 노드 사본과
- 다운타임은 없지만, 노드 사본과
전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다.
- PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다.
- 다운타임 없음
@@ -251,5 +267,3 @@ Pod Disruption Budgets를 사용할 필요가 없다.
* [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다.
* [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+26 -27
View File
@@ -9,13 +9,14 @@ weight: 80
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
컨테이너를 사용한다.
{{< warning >}}
임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는
적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
임시 컨테이너는 초기 알파 상태이며,
프로덕션 클러스터에는 적합하지 않다.
[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
{{< /warning >}}
@@ -25,23 +26,23 @@ weight: 80
## 임시 컨테이너 이해하기
{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의
기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기
{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의
기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기
때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다.
대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를
대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를
사용해서 제어하는 방식으로 파드를 삭제하고 교체한다.
그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해
기존 파드의 상태를 검사해야할 수 있다. 이 경우 사용자는
기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을
그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해
기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는
기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을
실행할 수 있다.
### 임시 컨테이너는 무엇인가?
임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서
다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서
애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는
일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가
임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서
다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서
애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는
일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가
호환되지 않으며 임시 컨테이너에는 허용되지 않는다.
- 임시 컨테이너는 포트를 가지지 않을 수 있으므로, `ports`,
@@ -60,20 +61,20 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
## 임시 컨테이너의 사용
임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에
디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때
디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때
대화형 문제 해결에 유용하다.
특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless)
를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의
컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를
포함하지 않기 때문에, `kubectl exec` 만으로는 distroless
를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의
컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를
포함하지 않기 때문에, `kubectl exec` 만으로는 distroless
이미지의 문제 해결이 어렵다.
임시 컨테이너 사용시 [프로세스 네임스페이스
공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
임시 컨테이너 사용 시 [프로세스 네임스페이스
공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
임시 컨테이너를 사용해서 문제를 해결하는 예시는
임시 컨테이너를 사용해서 문제를 해결하는 예시는
[임시 디버깅 컨테이너로 디버깅하기]
(/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다.
@@ -81,17 +82,17 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
{{< note >}}
이 섹션의 예시는 `EphemeralContainers` [기능
게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
게이트](/docs/reference/command-line-tools-reference/feature-gates/)의
활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
{{< /note >}}
이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지
이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 일반적으로 `kubectl alpha debug` 또는
다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을
다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
```json
@@ -187,5 +188,3 @@ Ephemeral Containers:
```shell
kubectl attach -it example-pod -c debugger
```
content/ko/docs/concepts/workloads/pods/init-containers.md
+18 -19
View File
@@ -27,7 +27,7 @@ weight: 40
* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다.
만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를
반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다.
컨테이너를 초기화 컨테이너로 지정하기 위해서는,
파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를
@@ -63,7 +63,7 @@ weight: 40
* 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서
공동의 단일 앱 이미지 형태로 빌드될 필요가 없다.
* 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다.
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는
결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는
{{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다.
* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱
컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이
@@ -102,7 +102,7 @@ weight: 40
### 사용 중인 초기화 컨테이너
쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다.
첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이
첫 번째는 `myservice` 를 기다리고 두 번째는 `mydb` 를 기다린다. 두 컨테이너들이
완료되면, 파드가 시작될 것이다.
```yaml
@@ -190,7 +190,7 @@ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
```
`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고
`myapp-pod`가 생성된 것을 볼 수 있다.
`myapp-pod` 가 생성된 것을 볼 수 있다.
여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다.
@@ -217,7 +217,7 @@ spec:
targetPort: 9377
```
`mydb`와 `myservice` 서비스 생성하기.
`mydb` 와 `myservice` 서비스 생성하기.
```shell
kubectl apply -f services.yaml
@@ -227,7 +227,7 @@ service/myservice created
service/mydb created
```
초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로
초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Running 상태로
변경되는 것을 볼 것이다.
```shell
@@ -249,13 +249,13 @@ myapp-pod 1/1 Running 0 9m
각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로
종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이
실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만,
파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
`restartPolicy`을 실패 시(OnFailure)로 사용한다.
실패된다면, 초기화 컨테이너는 파드의 `restartPolicy` 에 따라서 재시도 된다. 다만,
파드의 `restartPolicy` 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는
`restartPolicy` 를 실패 시(OnFailure)로 사용한다.
파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는
파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는
서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만
`Initialized`이 참이 되는 조건을 가져야 한다.
`Initialized` 가 참이 되는 조건을 가져야 한다.
만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는
반드시 다시 실행된다.
@@ -264,15 +264,16 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다.
초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너
코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는
코드는 멱등성(idempotent)을 유지해야 한다. 특히, `EmptyDirs` 에 있는 파일에 쓰기를 수행하는 코드는
출력 파일이 이미 존재할 가능성에 대비해야 한다.
초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는
`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을
구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다.
초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다.
초기화 컨테이너들이 실패를
영원히 지속하는 상황을 방지하기 위해서
파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다.
파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다.
@@ -310,7 +311,7 @@ myapp-pod 1/1 Running 0 9m
이미지의 변경은 앱 컨테이너만 재시작시킨다.
* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는,
* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
때문에 유실되었다.
@@ -320,7 +321,5 @@ myapp-pod 1/1 Running 0 9m
## {{% heading "whatsnext" %}}
* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+7 -5
View File
@@ -114,9 +114,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
지원하지 않는다면, 기본 상태는 `Success`이다.
* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는
활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업
컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업
프로브가 없는 경우, 기본 상태는 `Success`이다.
### 언제 활성 프로브를 사용해야 하는가?
@@ -193,8 +193,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
...
```
* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다.
컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
```yaml
...
@@ -212,7 +211,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_
와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기
위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다.
위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다.
준비성 게이트는 파드에 대한 `status.condition` 필드의 현재
상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는
@@ -261,6 +260,9 @@ status:
* 파드 내의 모든 컨테이너들이 준비 상태이다.
* `ReadinessGates`에 지정된 모든 조건들이 `True` 이다.
파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면,
Kubelet은 파드의 상태를 `ContainerReady`로 설정한다.
## 재시작 정책
PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다.
content/ko/docs/concepts/workloads/pods/pod-overview.md
+7 -3
View File
@@ -26,6 +26,7 @@ card:
* **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
* **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다.
복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다.
쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다.
@@ -48,7 +49,7 @@ card:
#### 저장소
파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)를 참고하길 바란다.
파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다.
## 파드 작업
@@ -64,13 +65,16 @@ card:
워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다.
다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다.
* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}
* {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}
## 파드 템플릿
워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고
{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고
사용자를 대신해서 이러한 파드를 관리한다.
파드템플릿은 파드를 생성하기 위한 명세이며
@@ -87,6 +91,7 @@ apiVersion: batch/v1
kind: Job
metadata:
name: hello
spec:
template:
# 이것이 파드 템플릿이다.
spec:
@@ -113,4 +118,3 @@ metadata:
* 파드의 동작에 대해 더 알아보자.
* [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
* [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+11 -11
View File
@@ -18,10 +18,10 @@ weight: 50
### 기능 게이트 활성화
를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에
대해 `EvenPodsSpread`
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다.
를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와**
{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해
`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
활성화되어야 한다.
### 노드 레이블
@@ -160,6 +160,7 @@ spec:
- 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다.
- `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다.
1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다.
2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다.
@@ -191,13 +192,13 @@ spec:
토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.
- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우.
- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서
`PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
레플리카 셋 또는 스테이트풀 셋에서 계산한다.
레플리카 셋 또는 스테이트풀셋에서 계산한다.
예시 구성은 다음과 같다.
@@ -226,17 +227,16 @@ profiles:
## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교
쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다.
더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다.
- `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에
원하는 수의 파드를 얼마든지 채울 수 있다.
- `PodAntiAffinity` 로는, 단일 토폴로지 도메인에
단 하나의 파드만 스케줄 될 수 있다.
"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와
레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다.
"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서
고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다.
더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다.
## 알려진 제한사항
content/ko/docs/concepts/workloads/pods/pod.md
+43 -43
View File
@@ -5,15 +5,21 @@ weight: 20
---
<!-- overview -->
_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다.
_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는
배포 가능한 최소 컴퓨팅 단위이다.
<!-- body -->
## 파드는 무엇인가?
_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다.
이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은)
{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다.
이 그룹은 스토리지/네트워크를 공유하고,
해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다.
파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다.
이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다.
@@ -47,9 +53,10 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
파드가 만들어지고 고유한 ID(UID)가 할당되고,
재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다.
대신, 동일한 파드로,
원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
@@ -59,6 +66,7 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다.
{{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}}
*파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는
웹 서버를 포함하는 멀티 컨테이너 파드.*
@@ -70,7 +78,8 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써
애플리케이션 배포 및 관리를 단순화한다.
파드는 전개 단위, 수평 확장 및 복제를 한다.
공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는
공동 스케줄링,
공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는
파드의 컨테이너에 대해 자동으로 처리된다.
### 리소스 공유 및 통신
@@ -80,10 +89,12 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로
서로를 찾고 통신하는데 `localhost`를 사용할 수 있다.
이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다.
각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
각 파드에는 다른 물리적 컴퓨터 및 파드들과
네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다.
더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다.
더 자세한 내용은
[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다.
파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다.
볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고,
@@ -104,14 +115,17 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것
일반적으로 하나의 파드는
동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다.
더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다.
더 자세한 설명을 보려면
[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을
참조한다.
## 고려된 대안
_싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_
1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면,
인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다.
인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을
제공할 수 있다.
이 기능들은 사용자에게 편의를 제공한다.
1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리,
재빌드, 재배포될 수 있다.
@@ -129,19 +143,18 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
## 파드의 내구성 (또는 결핍)
파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패,
노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
일반적으로 사용자는 파드를 직접 만들 필요가 없다.
싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
컨트롤러는 클러스터 범위에서
복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은
컨트롤러는 상태를 저장하는 파드에도
위와 같은 기능 제공을 할 수 있다.
사용자 지향적으로 선정된 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)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
* 스케줄러 및 컨트롤러 연결 가능
@@ -149,58 +162,45 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
* 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리
* 컨트롤러와 서비스의 분리 &mdash; 파드를 감시하는 엔드 포인트 컨트롤러
* 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 &mdash; Kubelet은 효과적인 "파드 컨트롤러" 이다.
* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고,
삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
## 파드의 종료
파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다.
사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다.
사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다.
유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다.
파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다.
흐름 예시:
1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초)
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.
1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다.
1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다.
1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다.
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다.
기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다.
기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=<seconds>` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제).
kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다.
### 파드 강제 삭제
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다.
API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다.
노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다.
스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다.
파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다.
## 파드 컨테이너의 특권(Privileged) 모드
Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다.
사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다.
`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'`
마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다.
`The Pod "FooPodName" is invalid.
spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'`
{{< note >}}
이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다.
{{< /note >}}
## API 오브젝트
파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
파드는 쿠버네티스 REST API에서 최상위 리소스이다.
API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
content/ko/docs/concepts/workloads/pods/podpreset.md
+3
View File
@@ -1,4 +1,6 @@
---
title: 파드 프리셋
content_type: concept
weight: 50
@@ -25,6 +27,7 @@ weight: 50
제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset}
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.