Merge pull request #32789 from kubernetes/dev-1.23-ko.2
[ko] 2nd Korean localization work for v1.23pull/32797/head
Kubernetes Prow Robot
GitHub
commit
c38941a3b1
|
|
@ -15,7 +15,7 @@ weight: 50
|
|||
{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을
|
||||
구동할 수 있다.
|
||||
|
||||
{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
|
||||
{{< glossary_definition prepend="컨테이너 런타임 인터페이스(CRI)는" term_id="container-runtime-interface" length="all" >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,172 @@
|
|||
---
|
||||
title: 가비지(Garbage) 수집
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}}
|
||||
다음과 같은 리소스를 정리한다:
|
||||
|
||||
* [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [소유자 참조가 없는 오브젝트](#owners-dependents)
|
||||
* [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images)
|
||||
* [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) <!-- en 글에서부터 링크가 깨져있어 /docs를 따로 추가-->
|
||||
* {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다:
|
||||
* 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드
|
||||
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스
|
||||
* [노드 리스(Lease) 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)
|
||||
|
||||
## 소유자(Owners)와 종속(dependents) {#owners-dependents}
|
||||
|
||||
쿠버네티스의 많은 오브젝트는 [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/)를 통해 서로 연결되어 있다.
|
||||
|
||||
소유자 참조(Owner references)는 컨트롤 플레인에게 어떤 오브젝트가 서로 종속적인지를 알려준다.
|
||||
쿠버네티스는 소유자 참조를 사용하여 컨트롤 플레인과 다른 API 클라이언트에게 오브젝트를 삭제하기 전 관련 리소스를 정리하는 기회를 제공한다. 대부분의 경우, 쿠버네티스는 소유자 참조를 자동으로 관리한다.
|
||||
|
||||
소유권(Ownership)은 일부 리소스가 사용하는 [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)
|
||||
메커니즘과는 다르다. 예를 들어,
|
||||
`EndpointSlice` 오브젝트를 생성하는 {{<glossary_tooltip text="서비스" term_id="service">}}를
|
||||
생각해보자. 서비스는 *레이블*을 사용해 컨트롤 플레인이
|
||||
어떤 `EndpointSlice` 오브젝트가 해당 서비스에 의해 사용되는지 판단하는 데 도움을 준다. 레이블과 더불어,
|
||||
서비스를 대신해 관리되는 각 `EndpointSlice` 오브젝트는
|
||||
소유자 참조를 가진다. 소유자 참조는 쿠버네티스의 다른 부분이 제어하지 않는
|
||||
오브젝트를 방해하는 것을 방지하는 데 도움을 준다.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
|
||||
네임스페이스 종속 오브젝트는 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
|
||||
네임스페이스 소유자는 **반드시** 종속 오브젝트와 동일한 네임스페이스에 존재해야 한다.
|
||||
그렇지 않다면, 소유자 참조는 없는 것으로 간주되어, 종속 오브젝트는
|
||||
모든 소유자가 없는 것으로 확인되면 삭제될 수 있다.
|
||||
|
||||
클러스터 범위의 종속 오브젝트는 클러스터 범위의 소유자만 지정할 수 있다.
|
||||
v1.20 이상에서, 클러스터 범위의 종속 오브젝트가 네임스페이스 종류를 소유자로 지정하면,
|
||||
확인할 수 없는 소유자 참조가 있는 것으로 간주되어 가비지 수집이 될 수 없다.
|
||||
|
||||
v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
|
||||
또는 네임스페이스 종류를 참조하는 `ownerReference`가 있는 클러스터 범위의 종속 항목을 감지하면,
|
||||
`OwnerRefInvalidNamespace`가 원인인 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject`가 보고된다.
|
||||
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`
|
||||
를 실행하여 이러한 종류의 이벤트를 확인할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 캐스케이딩(Cascading) 삭제 {#cascading-deletion}
|
||||
|
||||
쿠버네티스는 오브젝트를 삭제할 때 더 이상 소유자 참조가 없는지,
|
||||
예를 들어 레플리카셋을 삭제할 때, 남겨진 파드가 없는지 확인하고 삭제한다.
|
||||
오브젝트를 삭제할 때 쿠버네티스가 오브젝트의 종속 오브젝트들을 자동으로 삭제할 지 여부를 제어할 수 있다.
|
||||
이 과정을 `캐스케이딩 삭제`라고 한다.
|
||||
캐스케이딩 삭제에는 다음과 같은 두 가지 종류가 있다.
|
||||
|
||||
* 포그라운드 캐스케이딩 삭제(Foreground cascading deletion)
|
||||
* 백그라운드 캐스케이딩 삭제(Background cascading deletion)
|
||||
|
||||
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
|
||||
|
||||
### 포그라운드 캐스케이딩 삭제 {#foreground-deletion}
|
||||
|
||||
포그라운드 캐스케이딩 삭제에서는 삭제하려는 소유자 오브젝트가 먼저
|
||||
*삭제 중* 상태가 된다. 이 상태에서는 소유자 오브젝트에게 다음과 같은 일이
|
||||
일어난다:
|
||||
|
||||
* 쿠버네티스 API 서버가 오브젝트의 `metadata.deletionTimestamp` 필드를
|
||||
오브젝트가 삭제 표시된 시간으로 설정한다.
|
||||
* 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로
|
||||
설정한다.
|
||||
* 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다.
|
||||
|
||||
소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다.
|
||||
모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다.
|
||||
이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다.
|
||||
|
||||
포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
|
||||
종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다.
|
||||
더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
|
||||
참고한다.
|
||||
|
||||
### 백그라운드 캐스케이딩 삭제 {#background-deletion}
|
||||
|
||||
백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고
|
||||
백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다.
|
||||
쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
|
||||
|
||||
더 자세한 내용은 [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를
|
||||
참고한다.
|
||||
|
||||
### 분리된 종속 (Orphaned dependents)
|
||||
|
||||
쿠버네티스가 소유자 오브젝트를 삭제할 때, 남은 종속 오브젝트는 *분리된* 오브젝트라고 부른다.
|
||||
기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다.
|
||||
이 행동을 오버라이드하는 방법을 보려면,
|
||||
다음 [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다.
|
||||
|
||||
## 사용되지 않는 컨테이너와 이미지 가비지 수집 {#containers-images}
|
||||
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet">}}은
|
||||
사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다
|
||||
수행한다. 외부 가비지 수집 도구는 Kubelet 의 행동을 중단시키고
|
||||
존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다.
|
||||
|
||||
사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면,
|
||||
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 Kubelet 을 수정하거나
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 리소스 타입의
|
||||
가비지 수집과 관련된 파라미터를 수정한다.
|
||||
|
||||
### 컨테이너 이미지 라이프사이클
|
||||
|
||||
쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
|
||||
모든 이미지의 라이프사이클을 관리한다.
|
||||
Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다.
|
||||
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
|
||||
`HighThresholdPercent` 값을 초과한 디스크 사용량은
|
||||
마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는
|
||||
가비지 수집을 트리거한다. Kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
|
||||
이미지를 삭제한다.
|
||||
|
||||
### 컨테이너 이미지 가비지 수집 {#container-image-garbage-collection}
|
||||
|
||||
Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다:
|
||||
|
||||
* `MinAge`: Kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다.
|
||||
* `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수.
|
||||
`0`으로 세팅하여 비활성화할 수 있다.
|
||||
* `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수
|
||||
`0`으로 세팅하여 비활성화할 수 있다.
|
||||
|
||||
위 변수와 더불어, Kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다.
|
||||
|
||||
`MaxPerPodContainer`와 `MaxContainer`는
|
||||
파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이
|
||||
전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때,
|
||||
서로 충돌이 발생할 수 있다.
|
||||
이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
|
||||
최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고
|
||||
가장 오래된 컨테이너들을 축출한다.
|
||||
또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다.
|
||||
|
||||
{{<note>}}
|
||||
Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
|
||||
{{</note>}}
|
||||
|
||||
## 가비지 수집 구성하기 {#configuring-gc}
|
||||
|
||||
자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다.
|
||||
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다:
|
||||
|
||||
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [완료된 잡 자동 정리하기](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [쿠버네티스 오브젝트의 소유권](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자.
|
||||
* 쿠버네티스 [finalizers](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
|
||||
* 완료된 잡을 정리하는 [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자.
|
||||
|
|
@ -33,7 +33,7 @@ weight: 10
|
|||
1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
|
||||
2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가
|
||||
|
||||
노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
|
||||
노드 {{< glossary_tooltip text="오브젝트" term_id="object" >}} 또는 노드의 kubelet으로 자체 등록한 후
|
||||
컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
|
||||
예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,109 +0,0 @@
|
|||
---
|
||||
title: kubelet 가비지(Garbage) 수집 설정하기
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
{{< note >}}
|
||||
이 한글 문서는 더 이상 관리되지 않습니다.
|
||||
|
||||
이 문서의 기반이 된 영어 원문은 삭제되었으며,
|
||||
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
|
||||
|
||||
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
|
||||
이 문서는 삭제될 수 있습니다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
가비지 수집은 사용되지 않는
|
||||
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
|
||||
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
|
||||
1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다.
|
||||
|
||||
별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써
|
||||
kubelet을 중단시킬 수도 있으므로 권장하지 않는다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 이미지 수집
|
||||
|
||||
쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
|
||||
라이프사이클을 관리한다.
|
||||
|
||||
이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다.
|
||||
`HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는
|
||||
디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한
|
||||
이미지들을 삭제한다.
|
||||
|
||||
## 컨테이너 수집
|
||||
|
||||
컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다.
|
||||
`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다.
|
||||
`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름)
|
||||
쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다.
|
||||
`MaxContainers` 는 죽은 컨테이너의 최대 수량이다.
|
||||
이러한 변수는 `MinAge` 를 0으로 설정하고,
|
||||
`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다.
|
||||
|
||||
Kubelet은 미확인, 삭제 또는 앞에서 언급한
|
||||
플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다.
|
||||
일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는
|
||||
파드 당 최대
|
||||
컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의
|
||||
전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다.
|
||||
다음의 상황에서 `MaxPerPodContainer` 가 조정된다.
|
||||
최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고
|
||||
가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는
|
||||
`MinAge` 보다 오래되면 제거된다.
|
||||
|
||||
kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다.
|
||||
|
||||
## 사용자 설정
|
||||
|
||||
여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
|
||||
|
||||
1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
|
||||
기본값은 85% 이다.
|
||||
2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
|
||||
기본값은 80% 이다.
|
||||
|
||||
다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
|
||||
|
||||
1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
|
||||
되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
|
||||
2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
|
||||
인스턴스의 최대 수. 기본 값은 1 이다.
|
||||
3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
|
||||
기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
|
||||
|
||||
컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
|
||||
문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
|
||||
1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
|
||||
값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
|
||||
의 값도 상대적으로 더 큰 값을 권장한다.
|
||||
자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
|
||||
|
||||
|
||||
## 사용 중단(Deprecation)
|
||||
|
||||
문서에 있는 몇 가지 kubelet의 가비지 수집 특징은 향후에 kubelet 축출(eviction) 기능으로 대체될 예정이다.
|
||||
|
||||
포함:
|
||||
|
||||
| 기존 Flag | 신규 Flag | 근거 |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | 기존의 축출 신호로 인하여 이미지 가비지 수집이 트리거 될 수 있음 |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | 축출 리클레임 기능이 동일한 행동을 수행 |
|
||||
| `--maximum-dead-containers` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
|
||||
| `--maximum-dead-containers-per-container` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
|
||||
| `--minimum-container-ttl-duration` | | 컨테이너의 외부 영역에 오래된 로그가 저장되어 사용중단(deprecated)됨 |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 |
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를
|
||||
본다.
|
||||
|
|
@ -160,7 +160,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
|
|||
각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다.
|
||||
|
||||
이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을
|
||||
분리할 수 있고, 이 중 일부는 `stdout` 또는 `stderr` 에
|
||||
분리할 수 있고, 이 중 일부는 `stdout` 또는 `stderr` 에
|
||||
작성하기 위한 지원이 부족할 수 있다. 로그를 리디렉션하는 로직은
|
||||
최소화되어 있기 때문에, 심각한 오버헤드가 아니다. 또한,
|
||||
`stdout` 및 `stderr` 가 kubelet에서 처리되므로, `kubectl logs` 와 같은
|
||||
|
|
|
|||
|
|
@ -397,7 +397,7 @@ deployment.apps/my-nginx configured
|
|||
rm /tmp/nginx.yaml
|
||||
```
|
||||
|
||||
이를 통해 보다 중요한 변경을 더 쉽게 수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
|
||||
이를 통해 보다 중요한 변경을 더 쉽게 수행할 수 있다. 참고로 `EDITOR` 또는 `KUBE_EDITOR` 환경 변수를 사용하여 편집기를 지정할 수 있다.
|
||||
|
||||
더 자세한 내용은, [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit) 문서를 참고하길 바란다.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,46 +30,7 @@ weight: 50
|
|||
찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신
|
||||
다른 접근법을 취한다.
|
||||
|
||||
## 쿠버네티스 네트워크 모델
|
||||
|
||||
모든 `Pod` 에는 고유의 IP 주소가 있다. 즉, `Pod` 간에 링크를 명시적으로
|
||||
생성할 필요가 없으며 컨테이너 포트를 호스트 포트에 매핑할
|
||||
필요가 거의 없다. 이렇게 하면 포트 할당, 이름 지정, 서비스 검색, 로드 밸런싱,
|
||||
애플리케이션 구성 및 마이그레이션 관점에서 `Pod` 를 VM 또는
|
||||
물리적 호스트처럼 취급할 수 있는 깔끔하고, 하위 호환성
|
||||
있는 모델이 생성된다.
|
||||
|
||||
쿠버네티스는 모든 네트워크 구현에 다음과 같은
|
||||
기본 요구 사항을 적용한다(의도적 네트워크 세분화 정책 제외).
|
||||
|
||||
* 노드의 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다.
|
||||
* 노드의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든
|
||||
파드와 통신할 수 있다.
|
||||
|
||||
참고: 호스트 네트워크에서 실행되는 `Pod` 를 지원하는 리눅스와 같은 플랫폼의 경우, 다음의 요구 사항을
|
||||
적용한다.
|
||||
|
||||
* 노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드에 있는 모든
|
||||
파드와 통신할 수 있다.
|
||||
|
||||
이 모델은 전체적으로 덜 복잡할 뿐만 아니라, 쿠버네티스를 위해 VM에서
|
||||
컨테이너로 애플리케이션을 포팅할 때 충돌이 적게 구현하려는 요구와
|
||||
주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
|
||||
프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
|
||||
|
||||
쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
|
||||
컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
|
||||
`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
|
||||
`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
|
||||
VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고
|
||||
한다.
|
||||
|
||||
이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다.
|
||||
|
||||
`Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를
|
||||
요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은
|
||||
컨테이너 런타임의 세부 사항이기도 하다. `Pod` 자체는
|
||||
호스트 포트의 존재 여부에 대해 인식하지 못한다.
|
||||
쿠버네티스 네트워킹 모델에 대한 상세 정보는 [여기](/ko/docs/concepts/services-networking/)를 참고한다.
|
||||
|
||||
## 쿠버네티스 네트워크 모델의 구현 방법
|
||||
|
||||
|
|
@ -106,7 +67,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
|
|||
|
||||
### 캘리코
|
||||
|
||||
[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
|
||||
[캘리코](https://projectcalico.docs.tigera.io/about/about-calico/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다.
|
||||
|
||||
### 실리움(Cilium)
|
||||
|
||||
|
|
@ -118,9 +79,9 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
|
|||
|
||||
### 화웨이의 CNI-Genie
|
||||
|
||||
[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
|
||||
[CNI-Genie](https://github.com/cni-genie/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/flannel-io/flannel#flannel), [캘리코](https://projectcalico.docs.tigera.io/about/about-calico/), [위브넷(Weave-net)](https://www.weave.works/oss/net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
|
||||
|
||||
CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
|
||||
CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
|
||||
|
||||
### cni-ipvlan-vpc-k8s
|
||||
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)는
|
||||
|
|
@ -143,9 +104,10 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
|
|||
[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
|
||||
Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
|
||||
|
||||
### 콘티브(Contiv)
|
||||
### 콘티브-VPP(Contiv-VPP)
|
||||
|
||||
[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
|
||||
[Contiv-VPP](https://contivpp.io/)는 유저 스페이스에서 동작하고 성능을 중시하는 쿠버네티스 네트워크 플러그인이며,
|
||||
데이터 플레인으로 [fd.io](https://fd.io/)를 사용한다.
|
||||
|
||||
### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
|
||||
|
||||
|
|
@ -165,10 +127,14 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
|
|||
|
||||
### 플라넬
|
||||
|
||||
[플라넬](https://github.com/coreos/flannel#flannel)은 쿠버네티스 요구 사항을
|
||||
[플라넬](https://github.com/flannel-io/flannel#flannel)은 쿠버네티스 요구 사항을
|
||||
충족하는 매우 간단한 오버레이 네트워크이다. 많은
|
||||
경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다.
|
||||
|
||||
### Hybridnet
|
||||
|
||||
[Hybridnet](https://github.com/alibaba/hybridnet)은 하이브리드 클라우드를 위해 디자인된 오픈소스 CNI 플러그인이며 하나 또는 다수의 클러스터에 있는 컨테이너를 위한 오버레이 및 언더레이 네트워킹을 제공한다. 오버레이 및 언더레이 컨테이너는 동일한 노드에서 실행될 수 있으며 클러스터 범위의 양방향 네트워크 연결성을 가진다.
|
||||
|
||||
### 재규어(Jaguar)
|
||||
|
||||
[재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다.
|
||||
|
|
@ -227,7 +193,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
|
|||
|
||||
### Weaveworks의 위브넷
|
||||
|
||||
[위브넷](https://www.weave.works/products/weave-net/)은
|
||||
[위브넷](https://www.weave.works/oss/net/)은
|
||||
쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다.
|
||||
위브넷은 [CNI 플러그인](https://www.weave.works/docs/net/latest/cni-plugin/) 또는
|
||||
독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며,
|
||||
|
|
|
|||
|
|
@ -17,23 +17,70 @@ weight: 60
|
|||
|
||||
## Klog
|
||||
|
||||
klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)
|
||||
는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
|
||||
klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog)는
|
||||
쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다.
|
||||
|
||||
klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
|
||||
|
||||
쿠버네티스는 각 컴포넌트의 로깅을 간소화하는 중에 있다.
|
||||
다음 klog 명령줄 플래그는 쿠버네티스 1.23에서
|
||||
[사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)되었으며
|
||||
이후 릴리스에서 제거될 것이다.
|
||||
|
||||
- `--add-dir-header`
|
||||
- `--alsologtostderr`
|
||||
- `--log-backtrace-at`
|
||||
- `--log-dir`
|
||||
- `--log-file`
|
||||
- `--log-file-max-size`
|
||||
- `--logtostderr`
|
||||
- `--one-output`
|
||||
- `--skip-headers`
|
||||
- `--skip-log-headers`
|
||||
- `--stderrthreshold`
|
||||
|
||||
출력은 출력 형식에 관계없이 항상 표준 에러(stderr)에 기록될 것이다.
|
||||
출력 리다이렉션은 쿠버네티스 컴포넌트를 호출하는 컴포넌트가 담당할 것으로 기대된다.
|
||||
이는 POSIX 셸 또는 systemd와 같은 도구일 수
|
||||
있다.
|
||||
|
||||
배포판과 무관한(distroless) 컨테이너 또는 윈도우 시스템 서비스와 같은 몇몇 경우에서,
|
||||
위의 옵션은 사용할 수 없다.
|
||||
그런 경우 출력을 리다이렉트하기 위해
|
||||
[`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
|
||||
바이너리를 쿠버네티스 컴포넌트의 래퍼(wrapper)로 사용할 수 있다.
|
||||
미리 빌드된 바이너리가 몇몇 쿠버네티스 베이스 이미지에 기본 이름 `/go-runner` 와
|
||||
서버 및 노드 릴리스 아카이브에는 `kube-log-runner`라는 이름으로 포함되어 있다.
|
||||
|
||||
다음 표는 각 `kube-log-runner` 실행법이 어떤 셸 리다이렉션에 해당되는지 보여준다.
|
||||
|
||||
| 사용법 | POSIX 셸 (예:) bash) | `kube-log-runner <options> <cmd>` |
|
||||
| -----------------------------------------|----------------------------|-------------------------------------------------------------|
|
||||
| stderr와 stdout을 합치고, stdout으로 출력 | `2>&1` | `kube-log-runner` (기본 동작)) |
|
||||
| stderr와 stdout을 로그 파일에 기록 | `1>>/tmp/log 2>&1` | `kube-log-runner -log-file=/tmp/log` |
|
||||
| 로그 파일에 기록하면서 stdout으로 출력 | `2>&1 \| tee -a /tmp/log` | `kube-log-runner -log-file=/tmp/log -also-stdout` |
|
||||
| stdout만 로그 파일에 기록 | `>/tmp/log` | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
|
||||
|
||||
### Klog 출력
|
||||
|
||||
klog 네이티브 형식 예 :
|
||||
```
|
||||
I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
|
||||
```
|
||||
|
||||
메시지 문자열은 줄바꿈을 포함하고 있을 수도 있다.
|
||||
```
|
||||
I1025 00:15:15.525108 1 example.go:79] This is a message
|
||||
which has a line break.
|
||||
```
|
||||
|
||||
|
||||
### 구조화된 로깅
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
{{<warning>}}
|
||||
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을
|
||||
파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
|
||||
{{< warning >}}
|
||||
구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다.
|
||||
|
||||
로그 형식 및 값 직렬화는 변경될 수 있다.
|
||||
{{< /warning>}}
|
||||
|
|
@ -42,7 +89,8 @@ I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/
|
|||
로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다.
|
||||
새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다.
|
||||
|
||||
구조화된 로그 형식:
|
||||
구조화된 로그 메시지의 기본 형식은 텍스트이며,
|
||||
기존 klog와 하위 호환되는 형식이다.
|
||||
|
||||
```ini
|
||||
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
|
||||
|
|
@ -54,24 +102,28 @@ I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/
|
|||
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
|
||||
```
|
||||
|
||||
문자열은 따옴표로 감싸진다. 다른 값들은
|
||||
[`%+v`](https://pkg.go.dev/fmt#hdr-Printing)로 포맷팅되며, 이로 인해
|
||||
[데이터에 따라](https://github.com/kubernetes/kubernetes/issues/106428) 로그 메시지가 다음 줄로 이어질 수 있다.
|
||||
```
|
||||
I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
|
||||
second line.}
|
||||
```
|
||||
|
||||
### JSON 로그 형식
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
|
||||
|
||||
{{<warning >}}
|
||||
|
||||
JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다.
|
||||
|
||||
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우
|
||||
JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
|
||||
모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다.
|
||||
|
||||
필드 이름과 JSON 직렬화는 변경될 수 있다.
|
||||
{{< /warning >}}
|
||||
|
||||
`--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다.
|
||||
JSON 로그 형식 예시(보기좋게 출력된 형태):
|
||||
|
||||
JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
|
||||
```json
|
||||
{
|
||||
"ts": 1580306777.04728,
|
||||
|
|
@ -106,9 +158,8 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
|
|||
로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다.
|
||||
{{< /warning >}}
|
||||
|
||||
`--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화 한다.
|
||||
활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고
|
||||
이러한 필드의 로깅이 방지된다.
|
||||
`--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화한다.
|
||||
활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 이러한 필드의 로깅이 방지된다.
|
||||
|
||||
현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록:
|
||||
* kube-controller-manager
|
||||
|
|
@ -122,16 +173,17 @@ JSON 로그 형식 예시(보기좋게 출력된 형태):
|
|||
|
||||
### 로그 상세 레벨(verbosity)
|
||||
|
||||
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면
|
||||
기록된 이벤트 수가 줄어든다.
|
||||
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다.
|
||||
로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다.
|
||||
|
||||
### 로그 위치
|
||||
|
||||
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 예를 들면 다음과 같다.
|
||||
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
|
||||
* kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다.
|
||||
* kubelet과 {{<glossary_tooltip term_id="container-runtime" text="컨테이너 런타임">}}은
|
||||
컨테이너에서 실행되지 않는다.
|
||||
|
||||
systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 jounald에 기록한다.
|
||||
그 외 시스템에서는, `/var/log` 디렉터리의 `.log` 파일에 기록한다.
|
||||
|
|
@ -145,4 +197,5 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
|
|||
|
||||
* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
|
||||
* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
|
||||
* [klog 플래그 사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) 알아보기
|
||||
* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기
|
||||
|
|
|
|||
|
|
@ -239,6 +239,10 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
|
|||
|
||||
환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
컨피그맵을 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 받지 못할 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
|
||||
|
|
|
|||
|
|
@ -1,11 +1,12 @@
|
|||
---
|
||||
title: 컨테이너 리소스 관리
|
||||
title: 파드 및 컨테이너 리소스 관리
|
||||
content_type: concept
|
||||
weight: 40
|
||||
feature:
|
||||
title: 자동 빈 패킹(bin packing)
|
||||
description: >
|
||||
리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다. 활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다.
|
||||
리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다.
|
||||
활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -14,7 +15,8 @@ feature:
|
|||
{{< glossary_tooltip text="컨테이너" term_id="container" >}}에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다.
|
||||
지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다.
|
||||
|
||||
파드에서 컨테이너에 대한 리소스 _요청(request)_ 을 지정하면, 스케줄러는 이 정보를
|
||||
파드에서 컨테이너에 대한 리소스 _요청(request)_ 을 지정하면,
|
||||
{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}는 이 정보를
|
||||
사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 _제한(limit)_ 을
|
||||
지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를
|
||||
사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은
|
||||
|
|
@ -56,7 +58,7 @@ feature:
|
|||
*CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다.
|
||||
CPU는 컴퓨팅 처리를 나타내며 [쿠버네티스 CPU](#cpu의-의미) 단위로 지정된다.
|
||||
메모리는 바이트 단위로 지정된다.
|
||||
쿠버네티스 v1.14 이상을 사용하는 경우, _huge page_ 리소스를 지정할 수 있다.
|
||||
리눅스 워크로드에 대해서는, _huge page_ 리소스를 지정할 수 있다.
|
||||
Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리
|
||||
블록을 할당하는 리눅스 관련 기능이다.
|
||||
|
||||
|
|
@ -78,7 +80,8 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
|
|||
|
||||
## 파드와 컨테이너의 리소스 요청 및 제한
|
||||
|
||||
파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다.
|
||||
각 컨테이너에 대해, 다음과 같은
|
||||
리소스 제한(limit) 및 요청(request)을 지정할 수 있다.
|
||||
|
||||
* `spec.containers[].resources.limits.cpu`
|
||||
* `spec.containers[].resources.limits.memory`
|
||||
|
|
@ -87,35 +90,43 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고
|
|||
* `spec.containers[].resources.requests.memory`
|
||||
* `spec.containers[].resources.requests.hugepages-<size>`
|
||||
|
||||
요청과 제한은 개별 컨테이너에서만 지정할 수 있지만,
|
||||
파드 리소스 요청 및 제한에 대해 이야기하는 것이 편리하다.
|
||||
특정 리소스 타입에 대한 *파드 리소스 요청/제한* 은 파드의 각 컨테이너에 대한
|
||||
요청 및 제한은 개별 컨테이너에 대해서만 지정할 수 있지만,
|
||||
한 파드의 총 리소스 요청 및 제한에 대해 생각해 보는 것도
|
||||
유용할 수 있다.
|
||||
특정 리소스 종류에 대해, *파드 리소스 요청/제한* 은 파드의 각 컨테이너에 대한
|
||||
해당 타입의 리소스 요청/제한의 합이다.
|
||||
|
||||
## 쿠버네티스의 리소스 단위
|
||||
|
||||
### CPU의 의미
|
||||
### CPU 리소스 단위 {#meaning-of-cpu}
|
||||
|
||||
CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다.
|
||||
쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다.
|
||||
쿠버네티스에서, 1 CPU 단위는 노드가 물리 호스트인지
|
||||
아니면 물리 호스트 내에서 실행되는 가상 머신인지에 따라
|
||||
**1 물리 CPU 코어** 또는 **1 가상 코어** 에 해당한다.
|
||||
|
||||
요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의
|
||||
`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은,
|
||||
`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다.
|
||||
CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은
|
||||
CPU 자원의 단위와 관련하여, `0.1` 이라는 [수량](/docs/reference/kubernetes-api/common-definitions/quantity/) 표현은
|
||||
"백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은
|
||||
"백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다.
|
||||
`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며,
|
||||
`1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로,
|
||||
`100m` 과 같은 형식이 선호될 수 있다.
|
||||
|
||||
CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
|
||||
0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다.
|
||||
CPU 리소스는 항상 리소스의 절대량으로 표시되며, 상대량으로 표시되지 않는다.
|
||||
예를 들어, 컨테이너가 싱글 코어, 듀얼 코어, 또는 48 코어 머신 중 어디에서 실행되는지와 상관없이
|
||||
`500m` CPU는 거의 같은 양의 컴퓨팅 파워를 가리킨다.
|
||||
|
||||
### 메모리의 의미
|
||||
{{< note >}}
|
||||
쿠버네티스에서 CPU 리소스를 `1m`보다 더 정밀한 단위로 표기할 수 없다.
|
||||
이 때문에, CPU 단위를 `1.0` 또는 `1000m`보다 작은 밀리CPU 형태로 표기하는 것이 유용하다.
|
||||
예를 들어, `0.005` 보다는 `5m`으로 표기하는 것이 좋다.
|
||||
{{< /note >}}
|
||||
|
||||
### 메모리 리소스 단위 {#meaning-of-memory}
|
||||
|
||||
`memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
|
||||
E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를
|
||||
E, P, T, G, M, k 와 같은
|
||||
[수량](/docs/reference/kubernetes-api/common-definitions/quantity/) 접미사 중 하나를 사용하여 메모리를
|
||||
일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
|
||||
같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
|
||||
|
||||
|
|
@ -123,13 +134,20 @@ E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메
|
|||
128974848, 129e6, 129M, 128974848000m, 123Mi
|
||||
```
|
||||
|
||||
다음은 예제이다.
|
||||
다음 파드에는 두 개의 컨테이너가 있다. 각 컨테이너에는 0.25 cpu와
|
||||
64MiB(2<sup>26</sup> 바이트)의 메모리 요청이 있다. 각 컨테이너는 0.5
|
||||
cpu와 128MiB 메모리로 제한된다. 파드에 0.5 cpu와 128 MiB
|
||||
메모리, 1 cpu와 256MiB 메모리 제한이 있다고 말할 수 있다.
|
||||
접미사의 대소문자에 유의한다.
|
||||
`400m`의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다.
|
||||
이 사람은 아마도 400 메비바이트(mebibytes) (`400Mi`) 또는 400 메가바이트 (`400M`) 를 요청하고 싶었을 것이다.
|
||||
|
||||
## 컨테이너 리소스 예제 {#example-1}
|
||||
|
||||
다음 파드는 두 컨테이너로 구성된다.
|
||||
각 컨테이너는 0.25 CPU와 64 MiB(2<sup>26</sup> 바이트) 메모리 요청을 갖도록 정의되어 있다.
|
||||
또한 각 컨테이너는 0.5 CPU와 128 MiB 메모리 제한을 갖는다.
|
||||
이 경우 파드는 0.5 CPU와 128 MiB 메모리 요청을 가지며,
|
||||
1 CPU와 256 MiB 메모리 제한을 갖는다.
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
@ -162,55 +180,54 @@ spec:
|
|||
선택한다. 각 노드는 파드에 제공할 수 있는 CPU와 메모리 양과 같은 각 리소스 타입에 대해
|
||||
최대 용량을 갖는다. 스케줄러는 각 리소스 타입마다
|
||||
스케줄된 컨테이너의 리소스 요청 합계가
|
||||
노드 용량보다 작도록 한다. 참고로 노드의 실제 메모리나
|
||||
노드 용량보다 작도록 한다.
|
||||
참고로 노드의 실제 메모리나
|
||||
CPU 리소스 사용량은 매우 적지만, 용량 확인에 실패한 경우
|
||||
스케줄러는 여전히 노드에 파드를 배치하지 않는다. 이는 리소스 사용량이
|
||||
나중에 증가할 때, 예를 들어, 일일 요청 비율이
|
||||
최대일 때 노드의 리소스 부족을 방지한다.
|
||||
|
||||
## 리소스 제한이 있는 파드가 실행되는 방법
|
||||
## 쿠버네티스가 리소스 요청 및 제한을 적용하는 방법 {#how-pods-with-resource-limits-are-run}
|
||||
|
||||
kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을
|
||||
컨테이너 런타임으로 전달한다.
|
||||
kubelet이 파드의 컨테이너를 시작할 때,
|
||||
kubelet은 해당 컨테이너의 메모리/CPU 요청 및 제한을 컨테이너 런타임에 전달한다.
|
||||
|
||||
도커를 사용하는 경우에는 다음과 같다.
|
||||
리눅스에서, 일반적으로 컨테이너 런타임은
|
||||
적용될 커널 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 설정하고,
|
||||
명시한 제한을 적용한다.
|
||||
|
||||
- `spec.containers[].resources.requests.cpu` 는 잠재적인 분수이며,
|
||||
1024를 곱한 값인 코어 값으로 변환된다. 이 숫자 또는 2보다
|
||||
큰 값은 `docker run` 명령에서
|
||||
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)
|
||||
플래그의 값으로 사용된다.
|
||||
- CPU 제한은 해당 컨테이너가 사용할 수 있는 CPU 시간에 대한 강한 상한(hard ceiling)을 정의한다.
|
||||
각 스케줄링 간격(시간 조각)마다, 리눅스 커널은 이 제한이 초과되었는지를 확인하고,
|
||||
만약 초과되었다면 cgroup의 실행 재개를 허가하지 않고 기다린다.
|
||||
- CPU 요청은 일반적으로 가중치 설정(weighting)을 정의한다.
|
||||
현재 부하율이 높은 시스템에서 여러 개의 컨테이너(cgroup)가 실행되어야 하는 경우,
|
||||
큰 CPU 요청값을 갖는 워크로드가 작은 CPU 요청값을 갖는 워크로드보다 더 많은 CPU 시간을 할당받는다.
|
||||
- 메모리 요청은 주로 (쿠버네티스) 파드 스케줄링 과정에서 사용된다.
|
||||
cgroup v2를 사용하는 노드에서, 컨테이너 런타임은 메모리 요청을 힌트로 사용하여
|
||||
`memory.min` 및 `memory.low`을 설정할 수 있다.
|
||||
- 메모리 제한은 해당 cgroup에 대한 메모리 사용량 상한을 정의한다.
|
||||
컨테이너가 제한보다 더 많은 메모리를 할당받으려고 시도하면,
|
||||
리눅스 커널의 메모리 부족(out-of-memory) 서브시스템이 활성화되고
|
||||
(일반적으로) 개입하여 메모리를 할당받으려고 했던 컨테이너의 프로세스 중 하나를 종료한다.
|
||||
해당 프로세스의 PID가 1이고, 컨테이너가 재시작 가능(restartable)으로 표시되어 있으면, 쿠버네티스가 해당 컨테이너를 재시작한다.
|
||||
- 파드 또는 컨테이너의 메모리 제한은 메모리 기반 볼륨(예: `emptyDir`)의 페이지에도 적용될 수 있다.
|
||||
kubelet은 `tmpfs` emptyDir 볼륨을 로컬 임시(ephemeral) 스토리지가 아닌
|
||||
컨테이너 메모리 사용으로 간주하여 추적한다.
|
||||
|
||||
- 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고
|
||||
100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 마이크로초 단위의
|
||||
총 CPU 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다.
|
||||
한 컨테이너가 메모리 요청을 초과하고
|
||||
해당 노드의 메모리가 부족하지면,
|
||||
해당 컨테이너가 속한 파드가 {{< glossary_tooltip text="축출" term_id="eviction" >}}될 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다.
|
||||
{{</ note >}}
|
||||
컨테이너가 비교적 긴 시간 동안 CPU 제한을 초과하는 것이 허용될 수도, 허용되지 않을 수도 있다.
|
||||
그러나, 컨테이너 런타임은 과도한 CPU 사용률을 이유로 파드 또는 컨테이너를 종료시키지는 않는다.
|
||||
|
||||
- `spec.containers[].resources.limits.memory` 는 정수로 변환되어,
|
||||
`docker run` 명령에서
|
||||
[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)
|
||||
플래그의 값으로 사용된다.
|
||||
|
||||
컨테이너가 메모리 제한을 초과하면, 컨테이너는 종료될 수 있다. 다시
|
||||
시작할 수 있으면, 다른 타입의 런타임 오류와 마찬가지로, kubelet이 다시
|
||||
시작한다.
|
||||
|
||||
컨테이너가 메모리 요청을 초과하면, 노드에 메모리가
|
||||
부족할 때마다 파드가 축출될 수 있다.
|
||||
|
||||
컨테이너가 오랫동안 CPU 제한을 초과하는 것은 허용되거나 허용되지
|
||||
않을 수 있다. 그러나, 과도한 CPU 사용으로 인해 종료되지는 않는다.
|
||||
|
||||
리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는
|
||||
종료 중인지 확인하려면,
|
||||
리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는 종료 중인지 확인하려면,
|
||||
[문제 해결](#문제-해결) 섹션을 참조한다.
|
||||
|
||||
### 컴퓨트 및 메모리 리소스 사용량 모니터링
|
||||
|
||||
파드의 리소스 사용량은 파드 상태의 일부로 보고된다.
|
||||
kubelet은 파드의 리소스 사용량을 파드
|
||||
[`status`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)에 포함하여 보고한다.
|
||||
|
||||
클러스터에서 선택적인 모니터링 도구를
|
||||
사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-api)에서
|
||||
|
|
@ -308,21 +325,26 @@ kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으
|
|||
|
||||
### 로컬 임시 스토리지에 대한 요청 및 제한 설정
|
||||
|
||||
_임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수 있다. 파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다.
|
||||
`ephemeral-storage`를 명시하여 로컬 임시 저장소를 관리할 수 있다.
|
||||
파드의 각 컨테이너는 다음 중 하나 또는 모두를 명시할 수 있다.
|
||||
|
||||
* `spec.containers[].resources.limits.ephemeral-storage`
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와
|
||||
같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
|
||||
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
|
||||
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
|
||||
Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
|
||||
예를 들어, 다음은 대략 동일한 값을 나타낸다.
|
||||
예를 들어, 다음은 거의 동일한 값을 나타낸다.
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
- `128974848`
|
||||
- `129e6`
|
||||
- `129M`
|
||||
- `123Mi`
|
||||
|
||||
다음 예에서, 파드에 두 개의 컨테이너가 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
|
||||
다음 예에서, 파드에 두 개의 컨테이너가 있다.
|
||||
각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다.
|
||||
각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다.
|
||||
따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 로컬 임시 스토리지 제한을 가진다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -356,10 +378,12 @@ spec:
|
|||
emptyDir: {}
|
||||
```
|
||||
|
||||
### 임시-스토리지 요청이 있는 파드의 스케줄링 방법
|
||||
### `ephemeral-storage` 요청이 있는 파드의 스케줄링 방법
|
||||
|
||||
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를
|
||||
선택한다. 각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다. 자세한 정보는, [노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다.
|
||||
파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를 선택한다.
|
||||
각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다.
|
||||
자세한 정보는,
|
||||
[노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다.
|
||||
|
||||
스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드 용량보다 작도록 한다.
|
||||
|
||||
|
|
@ -492,15 +516,19 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기
|
|||
[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 참조한다.
|
||||
|
||||
##### 기타 리소스
|
||||
|
||||
새로운 노드-레벨의 확장된 리소스를 알리기 위해, 클러스터 운영자는
|
||||
API 서버에 `PATCH` HTTP 요청을 제출하여 클러스터의
|
||||
노드에 대해 `status.capacity` 에서 사용할 수 있는 수량을 지정할 수 있다. 이 작업
|
||||
후에는, 노드의 `status.capacity` 에 새로운 리소스가 포함된다. 이
|
||||
`status.allocatable` 필드는 kubelet에 의해 비동기적으로 새로운
|
||||
리소스로 자동 업데이트된다. 참고로 스케줄러가 파드 적합성을 평가할 때 노드
|
||||
`status.allocatable` 값을 사용하므로, 노드 용량을
|
||||
새 리소스로 패치하는 것과 해당 노드에서 리소스를 스케줄하도록 요청하는 첫 번째 파드
|
||||
사이에 약간의 지연이 있을 수 있다.
|
||||
리소스로 자동 업데이트된다.
|
||||
|
||||
스케줄러가 파드 적합성을 평가할 때 노드의 `status.allocatable` 값을 사용하므로,
|
||||
스케줄러는 해당 비동기 업데이트 이후의 새로운 값만을 고려한다.
|
||||
따라서 노드 용량을 새 리소스로 패치하는 시점과
|
||||
해당 자원을 요청하는 첫 파드가 해당 노드에 스케줄될 수 있는 시점 사이에
|
||||
약간의 지연이 있을 수 있다.
|
||||
|
||||
**예제:**
|
||||
|
||||
|
|
@ -527,7 +555,7 @@ JSON-Pointer로 해석된다. 더 자세한 내용은,
|
|||
클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로
|
||||
리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다.
|
||||
|
||||
[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서
|
||||
[스케줄러 구성](/docs/reference/config-api/kube-scheduler-config.v1beta3/)에서
|
||||
스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다.
|
||||
|
||||
**예제:**
|
||||
|
|
@ -610,26 +638,31 @@ spec:
|
|||
|
||||
## PID 제한
|
||||
|
||||
프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
|
||||
프로세스 ID(PID) 제한은 kubelet의 구성에 대해
|
||||
주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다.
|
||||
자세한 내용은 [PID 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
|
||||
|
||||
## 문제 해결
|
||||
|
||||
### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다
|
||||
### 내 파드가 `FailedScheduling` 이벤트 메시지로 보류 중이다
|
||||
|
||||
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를
|
||||
찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이
|
||||
파드의 위치를 찾지 못하면 이벤트가 생성된다.
|
||||
파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면,
|
||||
노드를 찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다.
|
||||
파드가 할당될 곳을 스케줄러가 찾지 못하면
|
||||
[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)가 생성된다.
|
||||
다음과 같이 `kubectl`을 사용하여 파드의 이벤트를 볼 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl describe pod frontend | grep -A 3 Events
|
||||
kubectl describe pod frontend | grep -A 9999999999 Events
|
||||
```
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From Subobject PathReason Message
|
||||
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu
|
||||
```
|
||||
|
||||
위의 예에서, 노드의 CPU 리소스가 충분하지 않아 이름이
|
||||
위의 예에서, 모든 노드의 CPU 리소스가 충분하지 않아 이름이
|
||||
"frontend"인 파드를 스케줄하지 못했다. 비슷한 메시지로
|
||||
메모리 부족(PodExceedsFreeMemory)으로 인한 장애도 알릴 수 있다. 일반적으로, 파드가
|
||||
이 타입의 메시지로 보류 중인 경우, 몇 가지 시도해 볼 것들이 있다.
|
||||
|
|
@ -639,6 +672,9 @@ Events:
|
|||
- 파드가 모든 노드보다 크지 않은지 확인한다. 예를 들어, 모든
|
||||
노드의 용량이 `cpu: 1` 인 경우, `cpu: 1.1` 요청이 있는 파드는
|
||||
절대 스케줄되지 않는다.
|
||||
- 노드 테인트를 확인한다.
|
||||
대부분의 노드에 테인트가 걸려 있고, 신규 파드가 해당 테인트에 배척된다면,
|
||||
스케줄러는 해당 테인트가 걸려 있지 않은 나머지 노드에만 배치를 고려할 것이다.
|
||||
|
||||
`kubectl describe nodes` 명령으로 노드 용량과 할당된 양을
|
||||
확인할 수 있다. 예를 들면, 다음과 같다.
|
||||
|
|
@ -673,21 +709,34 @@ Allocated resources:
|
|||
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
|
||||
```
|
||||
|
||||
위의 출력에서, 파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를
|
||||
요청하는 것은 노드에 맞지 않음을 알 수 있다.
|
||||
위의 출력에서, 1.120 이상의 CPU 또는 6.23 Gi 이상의 메모리를 요청하는 파드는
|
||||
노드에 할당될 수 없음을 확인할 수 있다.
|
||||
|
||||
`Pods` 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을
|
||||
"Pods" 섹션을 살펴보면, 어떤 파드가 노드에서 공간을 차지하고 있는지를
|
||||
볼 수 있다.
|
||||
|
||||
시스템 데몬이 사용 가능한 리소스의 일부를 사용하기 때문에, 파드에
|
||||
사용 가능한 리소스의 양이 노드 용량보다 적다. `allocatable` 필드
|
||||
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)는
|
||||
파드가 사용할 수 있는 리소스의 양을 제공한다. 자세한 정보는
|
||||
[노드 할당 가능 리소스](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md)를 참조한다.
|
||||
사용 가능한 리소스의 일부를 시스템 데몬이 사용하기 때문에,
|
||||
파드에 사용 가능한 리소스의 양은 노드 총 용량보다 적다.
|
||||
쿠버네티스 API에서, 각 노드는 `.status.allocatable` 필드(상세 사항은
|
||||
[NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) 참조)를
|
||||
갖는다.
|
||||
|
||||
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/) 기능은
|
||||
소비될 수 있는 리소스의 총량을 제한하도록 구성할 수 있다. 네임스페이스와
|
||||
함께 사용하면, 한 팀이 모든 리소스를 사용하는 경우를 방지할 수 있다.
|
||||
`.status.allocatable` 필드는 해당 노드에서 파드가 사용할 수 있는
|
||||
리소스의 양을 표시한다(예: 15 vCPUs 및 7538 MiB 메모리).
|
||||
쿠버네티스의 노드 할당 가능 리소스에 대한 상세 사항은
|
||||
[시스템 데몬을 위한 컴퓨트 자원 예약하기](/docs/tasks/administer-cluster/reserve-compute-resources/)를 참고한다.
|
||||
|
||||
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하여,
|
||||
한 네임스페이스가 사용할 수 있는 리소스 총량을 제한할 수 있다.
|
||||
특정 네임스페이스 내에 ResourceQuota가 설정되어 있으면
|
||||
쿠버네티스는 오브젝트에 대해 해당 쿼터를 적용한다.
|
||||
예를 들어, 각 팀에 네임스페이스를 할당한다면, 각 네임스페이스에 ResourceQuota를 설정할 수 있다.
|
||||
리소스 쿼터를 설정함으로써 한 팀이 지나치게 많은 리소스를 사용하여
|
||||
다른 팀에 영향을 주는 것을 막을 수 있다.
|
||||
|
||||
해당 네임스페이스에 어떤 접근을 허용할지도 고려해야 한다.
|
||||
네임스페이스에 대한 **완전한** 쓰기 권한을 가진 사람은
|
||||
어떠한 리소스(네임스페이스에 설정된 ResourceQuota 포함)라도 삭제할 수 있다.
|
||||
|
||||
### 내 컨테이너가 종료되었다
|
||||
|
||||
|
|
@ -698,6 +747,8 @@ Allocated resources:
|
|||
```shell
|
||||
kubectl describe pod simmemleak-hra99
|
||||
```
|
||||
|
||||
출력은 다음과 같다.
|
||||
```
|
||||
Name: simmemleak-hra99
|
||||
Namespace: default
|
||||
|
|
@ -708,56 +759,47 @@ Status: Running
|
|||
Reason:
|
||||
Message:
|
||||
IP: 10.244.2.75
|
||||
Replication Controllers: simmemleak (1/1 replicas created)
|
||||
Containers:
|
||||
simmemleak:
|
||||
Image: saadali/simmemleak
|
||||
Image: saadali/simmemleak:latest
|
||||
Limits:
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
State: Running
|
||||
Started: Tue, 07 Jul 2015 12:54:41 -0700
|
||||
Last Termination State: Terminated
|
||||
Exit Code: 1
|
||||
Started: Fri, 07 Jul 2015 12:54:30 -0700
|
||||
Finished: Fri, 07 Jul 2015 12:54:33 -0700
|
||||
Ready: False
|
||||
Restart Count: 5
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
State: Running
|
||||
Started: Tue, 07 Jul 2019 12:54:41 -0700
|
||||
Last State: Terminated
|
||||
Reason: OOMKilled
|
||||
Exit Code: 137
|
||||
Started: Fri, 07 Jul 2019 12:54:30 -0700
|
||||
Finished: Fri, 07 Jul 2019 12:54:33 -0700
|
||||
Ready: False
|
||||
Restart Count: 5
|
||||
Conditions:
|
||||
Type Status
|
||||
Ready False
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine
|
||||
Normal Created 41s kubelet Created container simmemleak
|
||||
Normal Started 40s kubelet Started container simmemleak
|
||||
Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod
|
||||
```
|
||||
|
||||
앞의 예제에서, `Restart Count: 5` 표시는 파드의 `simmemleak`
|
||||
컨테이너가 종료되고 5번 다시 시작되었음을 나타낸다.
|
||||
컨테이너가 종료되고 (지금까지) 5번 다시 시작되었음을 나타낸다.
|
||||
`Reason: OOMKilled`를 통해 컨테이너가 제한보다 많은 양의 메모리를 사용하려고 했다는 것을 확인할 수 있다.
|
||||
|
||||
이전에 종료된 컨테이너의 상태를 가져오기 위해 `-o go-template=...` 옵션을 사용해서
|
||||
`kubectl get pod` 를 호출할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Container Name: simmemleak
|
||||
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
|
||||
```
|
||||
|
||||
컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다.
|
||||
다음 단계로 메모리 누수가 있는지 애플리케이션 코드를 확인해 볼 수 있다.
|
||||
애플리케이션이 예상한 대로 동작하는 것을 확인했다면,
|
||||
해당 컨테이너의 메모리 제한(및 요청)을 더 높게 설정해 본다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자.
|
||||
* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
|
||||
* 요청과 제한의 차이점에 대한 자세한 내용은,
|
||||
[리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다.
|
||||
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기
|
||||
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
|
||||
* API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와
|
||||
[컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다.
|
||||
* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
|
||||
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기
|
||||
* [kube-scheduler 정책 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)에 대해 더 읽어보기
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ no_list: true
|
|||
의미한다.
|
||||
|
||||
컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다.
|
||||
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
|
||||
따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 배포할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ weight: 20
|
|||
파드 이름과 네임스페이스는
|
||||
[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
|
||||
|
||||
Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
||||
컨테이너 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
||||
파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
|
||||
|
||||
### 클러스터 정보
|
||||
|
|
@ -42,7 +42,6 @@ Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
|
|||
컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수
|
||||
있다.
|
||||
이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다.
|
||||
이러한 환경 변수는 Docker 링크 구문과 일치한다.
|
||||
|
||||
*bar* 라는 이름의 컨테이너에 매핑되는 *foo* 라는 이름의 서비스에 대해서는,
|
||||
다음의 형태로 변수가 정의된다.
|
||||
|
|
|
|||
|
|
@ -436,7 +436,7 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
|
|||
- 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
|
||||
- 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
|
||||
- 쿠버네티스 구성은 필요 없다.
|
||||
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
|
||||
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
|
||||
- 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
|
||||
- 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
|
||||
1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
|
||||
|
|
@ -456,5 +456,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
|
||||
* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
|
||||
* [컨테이너 이미지 가비지 수집(garbage collection)](/ko/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
|
||||
* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry)
|
||||
|
|
|
|||
|
|
@ -109,6 +109,11 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
|
|||
|
||||
#### dockershim
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
|
||||
|
||||
dockershim은 쿠버네티스 v1.20에서 사용 중단되었으며, v1.24에서 제거될 것이다. 상세 사항은
|
||||
[dockershim 사용 중단](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)을 참고한다.
|
||||
|
||||
dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
|
||||
dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
|
||||
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
|
|||
|
||||
### 인가
|
||||
|
||||
[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
|
||||
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
|
||||
|
||||
|
||||
### 동적 어드미션 컨트롤
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ CRD 오브젝트의 이름은 유효한
|
|||
|
||||
## API 서버 애그리게이션
|
||||
|
||||
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
|
||||
일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 있다.
|
||||
|
||||
[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
|
||||
작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
|
||||
|
|
@ -180,7 +180,7 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다.
|
|||
| ------- | ----------- | ---- | -------------- |
|
||||
| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. |
|
||||
| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 |
|
||||
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
|
||||
| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 |
|
||||
| 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 |
|
||||
| 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 |
|
||||
| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 |
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
|
||||
title: 장치 플러그인
|
||||
description: GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다.
|
||||
description: 장치 플러그인을 사용하여 GPU, NIC, FPGA, 또는 비휘발성 주 메모리와 같이 공급 업체별 설정이 필요한 장치 또는 리소스를 클러스터에서 지원하도록 설정할 수 있다.
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
|
@ -48,13 +47,15 @@ service Registration {
|
|||
노드에 두 개의 정상 장치를 보고하고 나면, 노드 상태가 업데이트되어
|
||||
노드에 2개의 "Foo" 장치가 설치되어 사용 가능함을 알릴 수 있다.
|
||||
|
||||
그러고 나면, 사용자가
|
||||
[컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 명세에 있는 장치를 요청할 수 있다.
|
||||
다만, 다른 종류의 리소스를 요청하는 것이므로 다음과 같은 제한이 있다.
|
||||
|
||||
그러고 나면, 사용자가 장치를 파드 스펙의 일부로 요청할 수
|
||||
있다([`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 참조).
|
||||
확장 리소스를 요청하는 것은 다른 자원의 요청 및 제한을 관리하는 것과 비슷하지만,
|
||||
다음과 같은 차이점이 존재한다.
|
||||
* 확장된 리소스는 정수(integer) 형태만 지원되며 오버커밋(overcommit) 될 수 없다.
|
||||
* 컨테이너간에 장치를 공유할 수 없다.
|
||||
|
||||
### 예제 {#example-pod}
|
||||
|
||||
쿠버네티스 클러스터가 특정 노드에서 `hardware-vendor.example/foo` 리소스를 알리는 장치 플러그인을 실행한다고
|
||||
가정해 보자. 다음은 데모 워크로드를 실행하기 위해 이 리소스를 요청하는 파드의 예이다.
|
||||
|
||||
|
|
@ -287,7 +288,7 @@ message AllocatableResourcesResponse {
|
|||
|
||||
```
|
||||
쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다.
|
||||
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
끄면 된다.
|
||||
|
||||
쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다.
|
||||
|
|
@ -302,7 +303,7 @@ NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값
|
|||
gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
|
||||
장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
|
||||
표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링
|
||||
에이전트는 특권을 가진 보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
|
||||
에이전트는 특권을 가진 보안 컨텍스트에서 실행해야 한다. 장치 모니터링 에이전트가
|
||||
데몬셋으로 실행 중인 경우, 해당 장치 모니터링 에이전트의 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
|
||||
`/var/lib/kubelet/pod-resources` 를
|
||||
{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
|
||||
|
|
@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
|
|||
|
||||
## 장치 플러그인 예시 {#examples}
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
다음은 장치 플러그인 구현의 예이다.
|
||||
|
||||
* [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
|
||||
|
|
@ -357,5 +360,5 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
|
|||
|
||||
* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
|
||||
* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
|
||||
* 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
|
||||
* [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
|
||||
* 쿠버네티스에서 [TLS 인그레스에 하드웨어 가속](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
|
||||
|
|
|
|||
|
|
@ -42,9 +42,10 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
|
|||
| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 |
|
||||
| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 |
|
||||
|
||||
위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.
|
||||
위 레이블의 실제 예시는 다음 {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} 오브젝트를 고려한다.
|
||||
|
||||
```yaml
|
||||
# 아래는 전체 명세의 일부분이다
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -95,7 +95,26 @@ kubectl config view --minify | grep namespace:
|
|||
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
|
||||
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
|
||||
개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
|
||||
네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
|
||||
네임스페이스를 넘어서 접근하기 위해서는,
|
||||
전체 주소 도메인 이름(FQDN)을 사용해야 한다.
|
||||
|
||||
그렇기 때문에, 모든 네임스페이스 이름은 유효한
|
||||
[RFC 1123 DNS 레이블](/ko/docs/concepts/overview/working-with-objects/names/#dns-label-names)이어야 한다.
|
||||
|
||||
{{< warning >}}
|
||||
네임스페이스의 이름을 [공개 최상위 도메인](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 중 하나와 동일하게 만들면,
|
||||
해당 네임스페이스 내의 서비스의 짧은 DNS 이름이 공개 DNS 레코드와 겹칠 수 있다.
|
||||
어떠한 네임스페이스 내의 워크로드가
|
||||
[접미점(trailing dot)](https://datatracker.ietf.org/doc/html/rfc1034#page-8) 없이 DNS 룩업을 수행하면
|
||||
공개 DNS 레코드보다 우선하여 해당 서비스로 리다이렉트될 것이다.
|
||||
|
||||
이를 방지하기 위해, 신뢰하는 사용자만 네임스페이스를
|
||||
생성할 수 있도록 권한을 제한한다.
|
||||
필요한 경우, 추가적으로 써드파티 보안 컨트롤을 구성할 수 있으며,
|
||||
예를 들어 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 이용하여
|
||||
[공개 TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)와
|
||||
동일한 이름의 네임스페이스 생성을 금지시킬 수 있다.
|
||||
{{< /warning >}}
|
||||
|
||||
## 모든 오브젝트가 네임스페이스에 속하지는 않음
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,9 @@ weight: 30
|
|||
|
||||
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
|
||||
|
||||
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은
|
||||
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
|
||||
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, v1.25에서 제거될 예정이다.
|
||||
파드시큐리티폴리시는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)으로 대체되었다.
|
||||
사용 중단에 대한 상세 사항은 [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
|
||||
|
||||
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
|
||||
부여할 수 있다.
|
||||
|
|
@ -21,7 +22,7 @@ weight: 30
|
|||
|
||||
## 파드 시큐리티 폴리시란?
|
||||
|
||||
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
|
||||
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
|
||||
리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
|
||||
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
|
||||
조건 셋을 정의한다. 관리자는
|
||||
|
|
@ -195,7 +196,7 @@ API 서버 접근 제어에 대한 자세한 내용은
|
|||
## 정책 순서
|
||||
|
||||
파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여
|
||||
제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
|
||||
제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
|
||||
사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는
|
||||
다음 기준에 따라 정책을 선택한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다.
|
|||
|
||||
지정된 네임스페이스에서 요청할 수 있는 총 [스토리지 리소스](/ko/docs/concepts/storage/persistent-volumes/) 합을 제한할 수 있다.
|
||||
|
||||
또한 연관된 스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
|
||||
또한 연관된 스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다.
|
||||
|
||||
| 리소스 이름 | 설명 |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Kubelet은 다른 구성은 지원하지 않는다.
|
|||
|
||||
{{<note>}}
|
||||
일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다.
|
||||
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/cluster-administration/kubelet-garbage-collection/#사용-중단-deprecation)을 참조한다.
|
||||
사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/architecture/garbage-collection/#containers-images)을 참조한다.
|
||||
{{</note>}}
|
||||
|
||||
### 축출 임계값
|
||||
|
|
@ -235,7 +235,7 @@ QoS는 EphemeralStorage 요청에 적용되지 않으므로,
|
|||
`Guaranteed` 파드는 모든 컨테이너에 대해 자원 요청량과 제한이 명시되고
|
||||
그 둘이 동일할 때에만 보장(guaranteed)된다. 다른 파드의 자원 사용으로 인해
|
||||
`Guaranteed` 파드가 축출되는 일은 발생하지 않는다. 만약 시스템 데몬(예:
|
||||
`kubelet`, `docker`, `journald`)이 `system-reserved` 또는 `kube-reserved`
|
||||
`kubelet`, `journald`)이 `system-reserved` 또는 `kube-reserved`
|
||||
할당을 통해 예약된 것보다 더 많은 자원을 소비하고, 노드에는 요청량보다 적은 양의
|
||||
자원을 사용하고 있는 `Guaranteed` / `Burstable` 파드만 존재한다면,
|
||||
kubelet은 노드 안정성을 유지하고 자원 고갈이 다른 파드에 미칠 영향을 통제하기 위해
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
|
|||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
`PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
|
||||
`preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
|
||||
앞쪽에 배치되지만,
|
||||
그 파드는 다른 파드를 축출할 수 없다.
|
||||
스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고
|
||||
|
|
@ -122,17 +122,17 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
|
|||
비-선점 파드는 다른 우선순위가 높은 파드에 의해
|
||||
축출될 수 있다.
|
||||
|
||||
`PreemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
|
||||
`preemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어,
|
||||
해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수
|
||||
있다(기존의 기본 동작과 동일).
|
||||
`PreemptionPolicy` 가 `Never` 로 설정된 경우,
|
||||
`preemptionPolicy` 가 `Never` 로 설정된 경우,
|
||||
해당 프라이어리티클래스의 파드는 비-선점될 것이다.
|
||||
|
||||
예제 유스케이스는 데이터 과학 관련 워크로드이다.
|
||||
사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만,
|
||||
실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다.
|
||||
클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면,
|
||||
`PreemptionPolicy: Never` 의 우선순위가 높은 잡이
|
||||
`preemptionPolicy: Never` 의 우선순위가 높은 잡이
|
||||
다른 대기 중인 파드보다 먼저 스케줄링된다.
|
||||
|
||||
### 비-선점 프라이어리티클래스 예제
|
||||
|
|
|
|||
|
|
@ -5,8 +5,50 @@ description: >
|
|||
쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
|
||||
---
|
||||
|
||||
## 쿠버네티스 네트워크 모델
|
||||
|
||||
모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다.
|
||||
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며
|
||||
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
|
||||
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
|
||||
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing),
|
||||
애플리케이션 구성, 마이그레이션 관점에서 `파드`를
|
||||
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
|
||||
|
||||
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
|
||||
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
|
||||
|
||||
* [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
* 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
|
||||
파드와 통신할 수 있다
|
||||
|
||||
참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
|
||||
다음의 요구사항도 존재한다.
|
||||
|
||||
* 한 노드의 호스트 네트워크에 있는 파드는
|
||||
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
|
||||
|
||||
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
|
||||
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
|
||||
작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다.
|
||||
이는 동일한 기본 모델이다.
|
||||
|
||||
쿠버네티스 IP 주소는 `파드` 범주에 존재하며,
|
||||
`파드` 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다.
|
||||
이는 곧 `파드` 내의 컨테이너들이 각자의 포트에 `localhost`로 접근할 수 있음을 의미한다.
|
||||
또한 `파드` 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데,
|
||||
이는 VM 내 프로세스 간에도 마찬가지이다.
|
||||
이러한 모델은 "파드 별 IP" 모델로 불린다.
|
||||
|
||||
이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.
|
||||
|
||||
`노드` 자체의 포트를 `파드`로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림),
|
||||
이는 매우 비주류적인(niche) 동작이다.
|
||||
포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다.
|
||||
`파드` 자체는 호스트 포트 존재 유무를 인지할 수 없다.
|
||||
|
||||
쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
|
||||
- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다.
|
||||
- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
|
||||
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
|
||||
- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다.
|
||||
- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다.
|
||||
- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
|
||||
- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.
|
||||
|
|
|
|||
|
|
@ -13,11 +13,9 @@ weight: 30
|
|||
|
||||
## 컨테이너 연결을 위한 쿠버네티스 모델
|
||||
|
||||
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
|
||||
지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다.
|
||||
|
||||
기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
|
||||
|
||||
컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
|
||||
쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
|
||||
|
||||
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
|
||||
|
||||
|
|
@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
|||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
|
||||
이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
|
||||
|
||||
만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -106,10 +106,9 @@ SRV 레코드는 노멀 서비스 또는
|
|||
|
||||
`172-17-0-3.default.pod.cluster.local`.
|
||||
|
||||
서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된
|
||||
모든 파드는 다음과 같은 DNS 주소를 갖는다.
|
||||
서비스에 의해 노출된 모든 파드는 다음과 같은 DNS 주소를 갖는다.
|
||||
|
||||
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
|
||||
`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
|
||||
|
||||
### 파드의 hostname 및 subdomain 필드
|
||||
|
||||
|
|
|
|||
|
|
@ -57,6 +57,14 @@ IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워
|
|||
* `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
|
||||
* kube-proxy:
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* kubelet:
|
||||
* `--cloud-provider`가 명시되지 않았다면
|
||||
관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해
|
||||
쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다.
|
||||
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
|
||||
파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다.
|
||||
노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된
|
||||
IP 패밀리 선호사항을 만족한다.
|
||||
|
||||
{{< note >}}
|
||||
IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도)
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ weight: 40
|
|||
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
|
||||
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
|
||||
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md)는 인그레스 컨트롤러로서 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
|
||||
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
|
||||
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
|
||||
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 40
|
|||
## 인그레스란?
|
||||
|
||||
[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부
|
||||
{{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
|
||||
{{< link text="서비스" url="/ko/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다.
|
||||
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
|
||||
|
||||
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
|
||||
|
|
@ -80,7 +80,7 @@ graph LR;
|
|||
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
|
||||
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
|
||||
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
|
||||
다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
|
||||
서로 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 서로 다른 어노테이션을 지원한다.
|
||||
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
|
||||
|
||||
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
|
||||
|
|
@ -88,6 +88,15 @@ graph LR;
|
|||
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
|
||||
지시하는 규칙만 지원한다.
|
||||
|
||||
`ingressClassName`을 생략하려면, [기본 인그레스 클래스](#default-ingress-class)가
|
||||
정의되어 있어야 한다.
|
||||
|
||||
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
|
||||
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
|
||||
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
|
||||
하지만 [아래](#default-ingress-class)에 나와 있는 것과 같이 기본 `IngressClass`를 명시하는 것을
|
||||
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
|
||||
|
||||
### 인그레스 규칙
|
||||
|
||||
각 HTTP 규칙에는 다음의 정보가 포함된다.
|
||||
|
|
@ -339,6 +348,14 @@ spec:
|
|||
기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
몇몇 인그레스 컨트롤러는 기본 `IngressClass`가 정의되어 있지 않아도 동작한다.
|
||||
예를 들어, Ingress-NGINX 컨트롤러는 `--watch-ingress-without-class`
|
||||
[플래그](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)를 이용하여 구성될 수 있다.
|
||||
하지만 다음과 같이 기본 `IngressClass`를 명시하는 것을
|
||||
[권장](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do)한다.
|
||||
|
||||
{{< codenew file="service/networking/default-ingressclass.yaml" >}}
|
||||
|
||||
## 인그레스 유형들
|
||||
|
||||
### 단일 서비스로 지원되는 인그레스 {#single-service-ingress}
|
||||
|
|
@ -468,9 +485,7 @@ graph LR;
|
|||
트래픽을 일치 시킬 수 있다.
|
||||
|
||||
예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
|
||||
`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
|
||||
않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
|
||||
트래픽은 `service3`로 라우팅 한다.
|
||||
`service1`로, `second.bar.com`는 `service2`로, 그리고 요청 헤더가 `first.bar.com` 또는 `second.bar.com`에 해당되지 않는 모든 트래픽을 `service3`로 라우팅한다.
|
||||
|
||||
{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ weight: 50
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다.
|
||||
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 {{< glossary_tooltip text="파드" term_id="pod" >}}가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. 네트워크폴리시는 한쪽 또는 양쪽 종단이 파드인 연결에만 적용되며, 다른 연결에는 관여하지 않는다.
|
||||
|
||||
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
|
||||
|
||||
|
|
@ -27,15 +27,17 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
|
|||
|
||||
네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
|
||||
|
||||
## 격리 및 격리되지 않은 파드
|
||||
## 파드 격리의 두 가지 종류
|
||||
|
||||
기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
|
||||
파드 격리에는 이그레스에 대한 격리와 인그레스에 대한 격리의 두 가지 종류가 있다. 이들은 어떤 연결이 성립될지에 대해 관여한다. 여기서 "격리"는 절대적인 것이 아니라, "일부 제한이 적용됨"을 의미한다. 반대말인 "이그레스/인그레스에 대한 비격리"는 각 방향에 대해 제한이 적용되지 않음을 의미한다. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 두 종류 모두 파드 간 연결과 연관된다.
|
||||
|
||||
파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
|
||||
기본적으로, 파드는 이그레스에 대해 비격리되어 있다. 즉, 모든 아웃바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Egress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 이그레스에 대해 격리된다. 이러한 정책은 파드의 이그레스에 적용된다고 말한다. 파드가 이그레스에 대해 격리되면, 파드에서 나가는 연결 중에서 파드의 이그레스에 적용된 NetworkPolicy의 `egress` 리스트에 허용된 연결만이 허용된다. `egress` 리스트 각 항목의 효과는 합산되어 적용된다.
|
||||
|
||||
네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
|
||||
기본적으로, 파드는 인그레스에 대해 비격리되어 있다. 즉, 모든 인바운드 연결이 허용된다. 해당 파드에 적용되면서 `policyTypes`에 "Ingress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 인그레스에 대해 격리된다. 이러한 정책은 파드의 인그레스에 적용된다고 말한다. 파드가 인그레스에 대해 격리되면, 파드로 들어오는 연결 중에서 파드의 인그레스에 적용된 NetworkPolicy의 `ingress` 리스트에 허용된 연결만이 허용된다. `ingress` 리스트 각 항목의 효과는 합산되어 적용된다.
|
||||
|
||||
두 파드간 네트워크 흐름을 허용하기 위해서는, 소스 파드의 이그레스 정책과 목적지 파드의 인그레스 정책 모두가 해당 트래픽을 허용해야 한다. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하게 되어 있다면, 해당 트래픽은 거절될 것이다.
|
||||
네트워크 폴리시가 충돌하는 경우는 없다. 네트워크 폴리시는 합산되어 적용된다. 특정 파드의 특정 방향에 대해 하나 또는 여러 개의 폴리시가 적용되면, 해당 파드의 해당 방향에 대해 허용된 연결은 모든 폴리시가 허용하는 연결의 합집합이다. 따라서, 판별 순서는 폴리시 결과에 영향을 미치지 않는다.
|
||||
|
||||
송신 파드에서 수신 파드로의 연결이 허용되기 위해서는, 송신 파드의 이그레스 폴리시와 수신 파드의 인그레스 폴리시가 해당 연결을 허용해야 한다. 만약 어느 한 쪽이라도 해당 연결을 허용하지 않으면, 연결이 되지 않을 것이다.
|
||||
|
||||
## 네트워크폴리시 리소스 {#networkpolicy-resource}
|
||||
|
||||
|
|
@ -176,18 +178,20 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
|||
|
||||
### 기본적으로 모든 인그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
|
||||
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 인그레스 격리 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스에 대해 여전히 격리된다. 이 정책은 다른 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 인그레스 트래픽 허용
|
||||
### 모든 인그레스 트래픽 허용
|
||||
|
||||
만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
|
||||
한 네임스페이스의 모든 파드로의 인입(incoming) 연결을 허용하려면, 이를 명시적으로 허용하는 정책을 만들 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
|
||||
|
||||
이 정책이 존재하면, 해당 파드로의 인입 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로부터의 이그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 거부
|
||||
|
||||
모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
|
||||
|
|
@ -195,14 +199,16 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
|
|||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
|
||||
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은
|
||||
기본 인그레스 격리 정책을 변경하지 않는다.
|
||||
모든 파드의 인그레스 격리 정책을 변경하지 않는다.
|
||||
|
||||
### 기본적으로 모든 이그레스 트래픽 허용
|
||||
### 모든 이그레스 트래픽 허용
|
||||
|
||||
만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
|
||||
한 네임스페이스의 모든 파드로부터의 모든 연결을 허용하려면, 해당 네임스페이스의 파드로부터 나가는(outgoing) 모든 연결을 명시적으로 허용하는 정책을 생성할 수 있다.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
|
||||
|
||||
이 정책이 존재하면, 해당 파드에서 나가는 연결을 막는 다른 정책은 효력이 없다. 이 정책은 모든 파드로의 인그레스 격리에는 영향을 미치지 않는다.
|
||||
|
||||
### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
|
||||
|
||||
해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 45
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된
|
||||
노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다.
|
||||
|
|
@ -20,9 +20,9 @@ _서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이
|
|||
|
||||
## 서비스 내부 트래픽 정책 사용
|
||||
|
||||
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서
|
||||
`ServiceInternalTrafficPolicy`를 활성화한 후에
|
||||
`ServiceInternalTrafficPolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는
|
||||
베타 기능이며 기본적으로 활성화되어 있다.
|
||||
이 기능이 활성화되어 있으면,
|
||||
{{< glossary_tooltip text="서비스" term_id="service" >}}의
|
||||
`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
|
||||
이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ _서비스_ 로 들어가보자.
|
|||
|
||||
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
|
||||
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
|
||||
질의할 수 있다.
|
||||
질의할 수 있다.
|
||||
|
||||
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
|
||||
밸런서를 배치할 수 있는 방법을 제공한다.
|
||||
|
|
@ -449,11 +449,8 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
|
|||
|
||||
### 환경 변수
|
||||
|
||||
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
|
||||
환경 변수 세트를 추가한다. [도커 링크
|
||||
호환](https://docs.docker.com/userguide/dockerlinks/) 변수 ([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)와
|
||||
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
|
||||
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
|
||||
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다.
|
||||
`{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 환경 변수가 추가되는데, 이 때 서비스 이름은 대문자로, 하이픈(`-`)은 언더스코어(`_`)로 변환하여 사용한다. 또한 도커 엔진의 "_[레거시 컨테이너 연결](https://docs.docker.com/network/links/)_" 기능과 호환되는 변수([makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) 참조)도 지원한다.
|
||||
|
||||
예를 들어, TCP 포트 6379를 개방하고
|
||||
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
|
||||
|
|
@ -687,21 +684,28 @@ kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화
|
|||
|
||||
#### 로드밸런서 NodePort 할당 비활성화
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하여 서비스 Type=LoadBalancer에
|
||||
대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
|
||||
노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
|
||||
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
|
||||
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
|
||||
`type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며,
|
||||
이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다.
|
||||
노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
|
||||
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
|
||||
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우
|
||||
해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
|
||||
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
|
||||
이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
|
||||
이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
|
||||
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로,
|
||||
`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다.
|
||||
다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
|
||||
|
||||
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
|
||||
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
|
||||
이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
|
||||
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
|
||||
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
|
||||
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
|
||||
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,158 @@
|
|||
---
|
||||
|
||||
|
||||
title: 토폴로지 인지 힌트
|
||||
content_type: concept
|
||||
weight: 45
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
_토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써
|
||||
토폴로지 인지 라우팅을 가능하게 한다.
|
||||
이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며,
|
||||
이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다.
|
||||
|
||||
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
|
||||
인접성을 고려하여 트래픽을 라우트할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 동기(motivation)
|
||||
|
||||
쿠버네티스 클러스터가 멀티-존(multi-zone) 환경에 배포되는 일이 점점 많아지고 있다.
|
||||
_토폴로지 인지 힌트_ 는 트래픽이 발생한 존 내에서 트래픽을 유지하도록 처리하는 메커니즘을 제공한다.
|
||||
이러한 개념은 보통 "토폴로지 인지 라우팅"이라고 부른다.
|
||||
{{< glossary_tooltip text="서비스" term_id="Service" >}}의 엔드포인트를 계산할 때,
|
||||
엔드포인트슬라이스 컨트롤러는 각 엔드포인트의 토폴로지(지역(region) 및 존)를 고려하여,
|
||||
엔드포인트가 특정 존에 할당되도록 힌트 필드를 채운다.
|
||||
그러면 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}와 같은
|
||||
클러스터 구성 요소는 해당 힌트를 인식하고,
|
||||
(토폴로지 상 가까운 엔드포인트를 사용하도록) 트래픽 라우팅 구성에 활용한다.
|
||||
|
||||
## 토폴로지 인지 힌트 사용하기
|
||||
|
||||
`service.kubernetes.io/topology-aware-hints` 어노테이션을 `auto`로 설정하여
|
||||
서비스에 대한 토폴로지 인지 힌트를 활성화할 수 있다.
|
||||
이는 엔드포인트슬라이스 컨트롤러가 안전하다고 판단되는 경우 토폴로지 힌트를 설정하도록 지시하는 것이다.
|
||||
명심할 점은, 이를 수행한다고 해서 힌트가 항상 설정되는 것은 아니라는 것이다.
|
||||
|
||||
## 동작 방법 {#implementation}
|
||||
|
||||
이 기능을 동작시키는 요소는
|
||||
엔드포인트슬라이스 컨트롤러와 kube-proxy 두 구성요소로 나눠져 있다.
|
||||
이 섹션에서는 각 구성요소가 어떻게 이 기능을 동작시키는지에 대한 고차원 개요를 제공한다.
|
||||
|
||||
### 엔드포인트슬라이스 컨트롤러 {#implementation-control-plane}
|
||||
|
||||
엔드포인트슬라이스 컨트롤러는 이 기능이 활성화되어 있을 때
|
||||
엔드포인트슬라이스에 힌트를 설정하는 일을 담당한다.
|
||||
컨트롤러는 각 존에 일정 비율의 엔드포인트를 할당한다.
|
||||
이 비율은 해당 존에 있는 노드의
|
||||
[할당 가능한(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) CPU 코어에 의해 결정된다.
|
||||
예를 들어, 한 존에 2 CPU 코어가 있고 다른 존에 1 CPU 코어만 있는 경우,
|
||||
컨트롤러는 2 CPU 코어가 있는 존에 엔드포인트를 2배 할당할 것이다.
|
||||
|
||||
다음 예시는 엔드포인트슬라이스에 힌트가 채워졌을 때에 대한
|
||||
예시이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1
|
||||
kind: EndpointSlice
|
||||
metadata:
|
||||
name: example-hints
|
||||
labels:
|
||||
kubernetes.io/service-name: example-svc
|
||||
addressType: IPv4
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
endpoints:
|
||||
- addresses:
|
||||
- "10.1.2.3"
|
||||
conditions:
|
||||
ready: true
|
||||
hostname: pod-1
|
||||
zone: zone-a
|
||||
hints:
|
||||
forZones:
|
||||
- name: "zone-a"
|
||||
```
|
||||
|
||||
### kube-proxy {#implementation-kube-proxy}
|
||||
|
||||
kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 힌트를 기반으로
|
||||
자신이 라우팅하는 엔드포인트를 필터링한다.
|
||||
대부분의 경우, 이는 kube-proxy가 동일 존 내에서 트래픽을 엔드포인트로 라우팅할 수 있음을 뜻한다.
|
||||
때때로 컨트롤러는 존 사이에 보다 균등한 엔드포인트 분배를 위해 다른 존으로부터 엔드포인트를 할당하기도 한다.
|
||||
이러한 경우 일부 트래픽은 다른 존으로 라우팅될 것이다.
|
||||
|
||||
## 보호 규칙
|
||||
|
||||
쿠버네티스 컨트롤 플레인과 각 노드의 kube-proxy는
|
||||
토폴로지 인지 힌트를 사용하기 전에 몇 가지 보호 규칙을 적용한다.
|
||||
이들이 만족되지 않으면, kube-proxy는 존에 상관없이
|
||||
클러스터의 모든 곳으로부터 엔드포인트를 선택한다.
|
||||
|
||||
1. **엔드포인트 수가 충분하지 않음:** 존의 숫자보다 엔드포인트의 숫자가 적으면,
|
||||
컨트롤러는 어떤 힌트도 할당하지 않을 것이다.
|
||||
|
||||
2. **균형잡힌 할당이 불가능함:** 일부 경우에, 존 간 균형잡힌 엔드포인트 할당이 불가능할 수 있다.
|
||||
예를 들어, zone-a가 zone-b보다 2배 큰 상황에서,
|
||||
엔드포인트가 2개 뿐이라면,
|
||||
zone-a에 할당된 엔드포인트는 zone-b에 할당된 엔드포인트보다 2배의 트래픽을 수신할 것이다.
|
||||
컨트롤러는 이 "예상 과부하" 값을 각 존에 대해
|
||||
허용 가능한 임계값보다 작게 낮출 수 없는 경우에는 힌트를 할당하지 않는다.
|
||||
명심할 점은, 이것이 실시간 피드백 기반이 아니라는 것이다.
|
||||
개별 엔드포인트가 과부하 상태로 바뀔 가능성도 여전히 있다.
|
||||
|
||||
3. **하나 이상의 노드에 대한 정보가 불충분함:** `topology.kubernetes.io/zone` 레이블이 없는 노드가 있거나
|
||||
할당 가능한 CPU 값을 보고하지 않는 노드가 있으면,
|
||||
컨트롤 플레인은 토폴로지 인지 엔드포인트를 설정하지 않으며
|
||||
이로 인해 kube-proxy는 존 별로 엔드포인트를 필터링하지 않는다.
|
||||
|
||||
4. **하나 이상의 엔드포인트에 존 힌트가 없음:** 이러한 상황이 발생하면,
|
||||
kube-proxy는 토폴로지 인지 힌트로부터의 또는 토폴로지 인지 힌트로의 전환이 진행 중이라고 가정한다.
|
||||
이 상태에서 서비스의 엔드포인트를 필터링하는 것은 위험할 수 있으므로
|
||||
kube-proxy는 모든 엔드포인트를 사용하는 모드로 전환된다.
|
||||
|
||||
5. **힌트에 존이 기재되지 않음:** kube-proxy가 실행되고 있는 존을 향하는 힌트를 갖는 엔드포인트를
|
||||
하나도 찾지 못했다면,
|
||||
모든 존에서 오는 엔드포인트를 사용하는 모드로 전환된다.
|
||||
이러한 경우는 기존에 있던 클러스터에 새로운 존을 추가하는 경우에 발생할 가능성이 가장 높다.
|
||||
|
||||
## 제약사항
|
||||
|
||||
* 토폴로지 인지 힌트는 서비스의 `externalTrafficPolicy` 또는
|
||||
`internalTrafficPolicy`가 `Local`로 설정된 경우에는 사용되지 않는다.
|
||||
동일 클러스터의 서로 다른 서비스들에 대해 두 기능 중 하나를 사용하는 것은 가능하며,
|
||||
하나의 서비스에 두 기능 모두를 사용하는 것은 불가능하다.
|
||||
|
||||
* 이러한 접근 방법은 존의 일부분에서
|
||||
많은 트래픽이 발생하는 서비스에는 잘 작동하지 않을 것이다.
|
||||
대신, 들어오는 트래픽이
|
||||
각 존 내 노드 용량에 대략 비례한다고 가정한다.
|
||||
|
||||
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
|
||||
준비되지 않은(unready) 노드는 무시한다.
|
||||
이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다.
|
||||
|
||||
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
|
||||
{{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}은 고려하지 않는다.
|
||||
서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우,
|
||||
이러한 상황은 고려되지 않을 것이다.
|
||||
|
||||
* 오토스케일링 기능과는 잘 동작하지 않을 수 있다.
|
||||
예를 들어, 하나의 존에서 많은 트래픽이 발생하는 경우,
|
||||
해당 존에 할당된 엔드포인트만 트래픽을 처리하고 있을 것이다.
|
||||
이로 인해 {{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}가
|
||||
이 이벤트를 감지하지 못하거나,
|
||||
또는 새롭게 추가되는 파드가 다른 존에 추가될 수 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어본다.
|
||||
|
|
@ -0,0 +1,272 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 임시 볼륨
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 문서는 쿠버네티스의 _임시(ephemeral) 볼륨_ 에 대해 설명한다.
|
||||
쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/),
|
||||
특히 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 및 퍼시스턴트볼륨(PersistentVolume)에 대해 잘 알고 있는 것이 좋다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
일부 애플리케이션은 추가적인 저장소를 필요로 하면서도
|
||||
재시작 시 데이터의 영구적 보존 여부는 신경쓰지 않을 수도 있다.
|
||||
예를 들어, 캐싱 서비스는 종종 메모리 사이즈에 제약을 받으며
|
||||
이에 따라 전반적인 성능에 적은 영향을 미치면서도
|
||||
사용 데이터를 메모리보다는 느린 저장소에 간헐적으로 옮길 수도 있다.
|
||||
|
||||
또 다른 애플리케이션은 읽기 전용 입력 데이터를 파일에서 읽도록 되어 있으며,
|
||||
이러한 데이터의 예시로는 구성 데이터 또는 비밀 키 등이 있다.
|
||||
|
||||
_임시 볼륨_ 은 이러한 사용 사례를 위해 설계되었다.
|
||||
임시 볼륨은 파드의 수명을 따르며 파드와 함께 생성 및 삭제되기 때문에,
|
||||
일부 퍼시스턴트 볼륨이 어디에서 사용 가능한지에 제약되는 일 없이
|
||||
파드가 중지 및 재시작될 수 있다.
|
||||
|
||||
임시 볼륨은 파드 명세에 _인라인_ 으로 명시되며,
|
||||
이로 인해 애플리케이션 배포 및 관리가 간편해진다.
|
||||
|
||||
### 임시 볼륨의 종류
|
||||
|
||||
쿠버네티스는 각 목적에 맞는
|
||||
몇 가지의 임시 볼륨을 지원한다.
|
||||
- [emptyDir](/ko/docs/concepts/storage/volumes/#emptydir):
|
||||
파드가 시작될 때 빈 상태로 시작되며,
|
||||
저장소는 로컬의 kubelet 베이스 디렉터리(보통 루트 디스크) 또는 램에서 제공된다
|
||||
- [configMap](/ko/docs/concepts/storage/volumes/#configmap),
|
||||
[downwardAPI](/ko/docs/concepts/storage/volumes/#downwardapi),
|
||||
[secret](/ko/docs/concepts/storage/volumes/#secret):
|
||||
각 종류의 쿠버네티스 데이터를 파드에 주입한다
|
||||
- [CSI 임시 볼륨](#csi-ephemeral-volumes):
|
||||
앞의 볼륨 종류와 비슷하지만,
|
||||
특히 [이 기능을 지원](https://kubernetes-csi.github.io/docs/drivers.html)하는 특수한
|
||||
[CSI 드라이버](https://github.com/container-storage-interface/spec/blob/master/spec.md)에 의해 제공된다
|
||||
- [일반(generic) 임시 볼륨](#generic-ephemeral-volumes):
|
||||
퍼시스턴트 볼륨도 지원하는 모든 스토리지 드라이버에 의해 제공될 수 있다
|
||||
|
||||
`emptyDir`, `configMap`, `downwardAPI`, `secret`은
|
||||
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)로서
|
||||
제공된다.
|
||||
이들은 각 노드의 kubelet에 의해 관리된다.
|
||||
|
||||
CSI 임시 볼륨은
|
||||
써드파티 CSI 스토리지 드라이버에 의해 제공 *되어야 한다*.
|
||||
|
||||
일반 임시 볼륨은 써드파티 CSI 스토리지 드라이버에 의해 제공 *될 수 있지만*,
|
||||
동적 프로비저닝을 지원하는 다른 스토리지 드라이버에 의해서도 제공될 수 있다.
|
||||
일부 CSI 드라이버는 특히 CSI 임시 볼륨을 위해 만들어져서
|
||||
동적 프로비저닝을 지원하지 않는데,
|
||||
이러한 경우에는 일반 임시 볼륨 용으로는 사용할 수 없다.
|
||||
|
||||
써드파티 드라이버 사용의 장점은
|
||||
쿠버네티스 자체적으로는 지원하지 않는 기능(예:
|
||||
kubelet에서 관리하는 디스크와 성능 특성이 다른 스토리지, 또는 다른 데이터 주입)을
|
||||
제공할 수 있다는 것이다.
|
||||
|
||||
### CSI 임시 볼륨 {#csi-ephemeral-volumes}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
이 기능을 사용하려면 `CSIInlineVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
쿠버네티스 1.16부터는 기본적으로 활성화되어 있다.
|
||||
|
||||
{{< note >}}
|
||||
CSI 드라이버 중 일부만 CSI 임시 볼륨을 지원한다.
|
||||
쿠버네티스 CSI [드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html)에서
|
||||
어떤 드라이버가 임시 볼륨을 지원하는지 보여 준다.
|
||||
{{< /note >}}
|
||||
|
||||
개념적으로, CSI 임시 볼륨은 `configMap`, `downwardAPI`, `secret` 볼륨 유형과 비슷하다.
|
||||
즉, 스토리지는 각 노드에서 로컬하게 관리되며,
|
||||
파드가 노드에 스케줄링된 이후에 다른 로컬 리소스와 함께 생성된다.
|
||||
쿠버네티스에는 지금 단계에서는 파드를 재스케줄링하는 개념이 없다.
|
||||
볼륨 생성은 실패하는 일이 거의 없어야 하며,
|
||||
만약 실패할 경우 파드 시작 과정이 중단될 것이다.
|
||||
특히, [스토리지 용량 인지 파드 스케줄링](/ko/docs/concepts/storage/storage-capacity/)은
|
||||
이러한 볼륨에 대해서는 지원되지 *않는다*.
|
||||
또한 이러한 볼륨은 파드의 스토리지 자원 사용 상한에 제한받지 않는데,
|
||||
이는 kubelet 자신이 관리하는 스토리지에만 강제할 수 있는 것이기 때문이다.
|
||||
|
||||
|
||||
다음은 CSI 임시 스토리지를 사용하는 파드에 대한 예시 매니페스트이다.
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: my-csi-app
|
||||
spec:
|
||||
containers:
|
||||
- name: my-frontend
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- mountPath: "/data"
|
||||
name: my-csi-inline-vol
|
||||
command: [ "sleep", "1000000" ]
|
||||
volumes:
|
||||
- name: my-csi-inline-vol
|
||||
csi:
|
||||
driver: inline.storage.kubernetes.io
|
||||
volumeAttributes:
|
||||
foo: bar
|
||||
```
|
||||
|
||||
`volumeAttributes`은 드라이버에 의해 어떤 볼륨이 준비되는지를 결정한다.
|
||||
이러한 속성은 각 드라이버별로 다르며 표준화되지 않았다.
|
||||
더 자세한 사항은 각 CSI 드라이버 문서를
|
||||
참고한다.
|
||||
|
||||
클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며,
|
||||
[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다.
|
||||
|
||||
### 일반 임시 볼륨 {#generic-ephemeral-volumes}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
일반 임시 볼륨은
|
||||
프로비저닝 후 일반적으로 비어 있는 스크래치 데이터에 대해 파드 별 디렉터리를 제공한다는 점에서
|
||||
`emptyDir` 볼륨과 유사하다.
|
||||
하지만 다음과 같은 추가 기능도 제공한다.
|
||||
|
||||
- 스토리지는 로컬이거나 네트워크 연결형(network-attached)일 수 있다.
|
||||
- 볼륨의 크기를 고정할 수 있으며 파드는 이 크기를 초과할 수 없다.
|
||||
- 드라이버와 파라미터에 따라
|
||||
볼륨이 초기 데이터를 가질 수도 있다.
|
||||
- 볼륨에 대한 일반적인 작업은 드라이버가 지원하는 범위 내에서 지원된다.
|
||||
이와 같은 작업은 다음을 포함한다.
|
||||
[스냅샷](/ko/docs/concepts/storage/volume-snapshots/),
|
||||
[복제](/ko/docs/concepts/storage/volume-pvc-datasource/),
|
||||
[크기 조정](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장),
|
||||
및 [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/).
|
||||
|
||||
다음은 예시이다.
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
containers:
|
||||
- name: my-frontend
|
||||
image: busybox
|
||||
volumeMounts:
|
||||
- mountPath: "/scratch"
|
||||
name: scratch-volume
|
||||
command: [ "sleep", "1000000" ]
|
||||
volumes:
|
||||
- name: scratch-volume
|
||||
ephemeral:
|
||||
volumeClaimTemplate:
|
||||
metadata:
|
||||
labels:
|
||||
type: my-frontend-volume
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "scratch-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
### 라이프사이클 및 퍼시스턴트볼륨클레임
|
||||
|
||||
핵심 설계 아이디어는
|
||||
[볼륨 클레임을 위한 파라미터](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)는
|
||||
파드의 볼륨 소스 내부에서 허용된다는 점이다.
|
||||
레이블, 어노테이션 및 퍼시스턴트볼륨클레임을 위한 모든 필드가 지원된다.
|
||||
이러한 파드가 생성되면, 임시 볼륨 컨트롤러는 파드가 속한 동일한 네임스페이스에
|
||||
퍼시스턴트볼륨클레임 오브젝트를 생성하고
|
||||
파드가 삭제될 때에는 퍼시스턴트볼륨클레임도 삭제되도록 만든다.
|
||||
|
||||
이는 볼륨 바인딩 및/또는 프로비저닝을 유발하는데,
|
||||
{{< glossary_tooltip text="스토리지클래스" term_id="storage-class" >}}가
|
||||
즉각적인(immediate) 볼륨 바인딩을 사용하는 경우에는 즉시,
|
||||
또는 파드가 노드에 잠정적으로 스케줄링되었을 때 발생한다(`WaitForFirstConsumer` 볼륨 바인딩 모드).
|
||||
일반 임시 볼륨에는 후자가 추천되는데, 이 경우 스케줄러가 파드를 할당하기에 적합한 노드를 선택하기가 쉬워지기 때문이다.
|
||||
즉각적인 바인딩을 사용하는 경우,
|
||||
스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다.
|
||||
|
||||
[리소스 소유권](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 관점에서,
|
||||
일반 임시 스토리지를 갖는 파드는
|
||||
해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다.
|
||||
파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데,
|
||||
스토리지 클래스의 기본 회수 정책이 볼륨을 삭제하는 것이기 때문에 PVC의 삭제는 보통 볼륨의 삭제를 유발한다.
|
||||
회수 정책을 `retain`으로 설정한 스토리지클래스를 사용하여 준 임시(quasi-ephemeral) 로컬 스토리지를 생성할 수도 있는데,
|
||||
이렇게 하면 스토리지의 수명이 파드의 수명보다 길어지며,
|
||||
이러한 경우 볼륨 정리를 별도로 수행해야 함을 명심해야 한다.
|
||||
|
||||
이러한 PVC가 존재하는 동안은, 다른 PVC와 동일하게 사용될 수 있다.
|
||||
특히, 볼륨 복제 또는 스냅샷 시에 데이터 소스로 참조될 수 있다.
|
||||
또한 해당 PVC 오브젝트는 해당 볼륨의 현재 상태도
|
||||
가지고 있다.
|
||||
|
||||
### 퍼시스턴트볼륨클레임 이름 정하기
|
||||
|
||||
자동으로 생성된 PVC의 이름은 규칙에 따라 정해진다.
|
||||
PVC의 이름은 파드 이름과 볼륨 이름의 사이를 하이픈(`-`)으로 결합한 형태이다.
|
||||
위의 예시에서, PVC 이름은 `my-app-scratch-volume`가 된다.
|
||||
이렇게 규칙에 의해 정해진 이름은 PVC와의 상호작용을 더 쉽게 만드는데,
|
||||
이는 파드 이름과 볼륨 이름을 알면
|
||||
PVC 이름을 별도로 검색할 필요가 없기 때문이다.
|
||||
|
||||
PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할 수
|
||||
있으며("pod-a" 파드 + "scratch" 볼륨 vs. "pod" 파드 + "a-scratch" 볼륨 -
|
||||
두 경우 모두 PVC 이름은 "pod-a-scratch")
|
||||
또한 파드와 수동으로 생성한 PVC 간에도 이름 충돌이 발생할 수 있다.
|
||||
|
||||
이러한 충돌은 감지될 수 있는데, 이는 PVC가 파드를 위해 생성된 경우에만 임시 볼륨으로 사용되기 때문이다.
|
||||
이러한 체크는 소유권 관계를 기반으로 한다.
|
||||
기존에 존재하던 PVC는 덮어써지거나 수정되지 않는다.
|
||||
대신에 충돌을 해결해주지는 않는데,
|
||||
이는 적합한 PVC가 없이는 파드가 시작될 수 없기 때문이다.
|
||||
|
||||
{{< caution >}}
|
||||
이러한 충돌이 발생하지 않도록
|
||||
동일한 네임스페이스 내에서는 파드와 볼륨의 이름을 정할 때 주의해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 보안
|
||||
|
||||
GenericEphemeralVolume 기능을 활성화하면
|
||||
사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며,
|
||||
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다.
|
||||
클러스터 관리자는 이를 명심해야 한다.
|
||||
이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다.
|
||||
- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우,
|
||||
[파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를
|
||||
사용한다(쿠버네티스
|
||||
1.21에서 사용 중단됨).
|
||||
- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는
|
||||
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을
|
||||
사용한다.
|
||||
|
||||
일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로,
|
||||
사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도,
|
||||
다른 정책을 우회하는 데에는 사용할 수 없다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
### kubelet이 관리하는 임시 볼륨
|
||||
|
||||
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/#로컬-임시-ephemeral-스토리지)를 참고한다.
|
||||
|
||||
### CSI 임시 볼륨
|
||||
|
||||
- 설계에 대한 더 자세한 정보는
|
||||
[임시 인라인 CSI 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)를 참고한다.
|
||||
- 이 기능의 추가 개발에 대한 자세한 정보는 [enhancement 저장소의 이슈 #596](https://github.com/kubernetes/enhancements/issues/596)을 참고한다.
|
||||
|
||||
### 일반 임시 볼륨
|
||||
|
||||
- 설계에 대한 더 자세한 정보는
|
||||
[일반 임시 인라인 볼륨 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)를 참고한다.
|
||||
|
|
@ -73,8 +73,8 @@ API 서버 커맨드라인 플래그에 대한 자세한 정보는
|
|||
|
||||
일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 `volumes` 블록에 `persistentVolumeClaim`을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 [볼륨으로 클레임하기](#볼륨으로-클레임하기)를 참고하길 바란다.
|
||||
|
||||
### 사용 중인 스토리지 오브젝트 보호
|
||||
사용 중인 스토리지 오브젝트 보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
|
||||
### 사용 중인 스토리지 오브젝트 보호
|
||||
사용 중인 스토리지 오브젝트 보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다.
|
||||
|
||||
{{< note >}}
|
||||
PVC를 사용하는 파드 오브젝트가 존재하면 파드가 PVC를 사용하고 있는 상태이다.
|
||||
|
|
@ -254,6 +254,16 @@ PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여
|
|||
지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해
|
||||
새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다.
|
||||
|
||||
{{< warning >}}
|
||||
퍼시스턴트볼륨의 크기를 직접 변경하면 자동 볼륨 리사이즈 기능을 이용할 수 없게 된다.
|
||||
퍼시스턴트볼륨의 크기를 변경하고,
|
||||
퍼시스턴트볼륨에 해당되는 퍼시스턴트볼륨클레임의 `.spec`에 적혀 있는 크기를 동일하게 변경하면,
|
||||
스토리지 리사이즈가 발생하지 않는다.
|
||||
쿠버네티스 컨트롤 플레인은
|
||||
두 리소스의 목표 상태(desired state)가 일치하는 것을 확인하고,
|
||||
배후(backing) 볼륨 크기가 수동으로 증가되어 리사이즈가 필요하지 않다고 판단할 것이다.
|
||||
{{< /warning >}}
|
||||
|
||||
#### CSI 볼륨 확장
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
|
@ -412,7 +422,7 @@ spec:
|
|||
|
||||
### 용량
|
||||
|
||||
일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 쿠버네티스 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)을 참고한다.
|
||||
일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 용어집에 있는 [수량](/ko/docs/reference/glossary/?all=true#term-quantity) 항목을 참고한다.
|
||||
|
||||
현재 스토리지 용량 크기는 설정하거나 요청할 수 있는 유일한 리소스이다. 향후 속성에 IOPS, 처리량 등이 포함될 수 있다.
|
||||
|
||||
|
|
@ -525,19 +535,19 @@ PV는 `storageClassName` 속성을
|
|||
|
||||
다음 볼륨 유형은 마운트 옵션을 지원한다.
|
||||
|
||||
* AWSElasticBlockStore
|
||||
* AzureDisk
|
||||
* AzureFile
|
||||
* CephFS
|
||||
* Cinder (OpenStack 블록 스토리지)
|
||||
* GCEPersistentDisk
|
||||
* Glusterfs
|
||||
* NFS
|
||||
* Quobyte Volumes
|
||||
* RBD (Ceph Block Device)
|
||||
* StorageOS
|
||||
* VsphereVolume
|
||||
* iSCSI
|
||||
* `awsElasticBlockStore`
|
||||
* `azureDisk`
|
||||
* `azureFile`
|
||||
* `cephfs`
|
||||
* `cinder` (v1.18에서 **사용 중단됨**)
|
||||
* `gcePersistentDisk`
|
||||
* `glusterfs`
|
||||
* `iscsi`
|
||||
* `nfs`
|
||||
* `quobyte` (v1.22에서 **사용 중단됨**)
|
||||
* `rbd`
|
||||
* `storageos` (v1.22에서 **사용 중단됨**)
|
||||
* `vsphereVolume`
|
||||
|
||||
마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
|
|||
parameters:
|
||||
server: nfs-server.example.com
|
||||
path: /share
|
||||
readOnly: false
|
||||
readOnly: "false"
|
||||
```
|
||||
|
||||
* `server`: NFS 서버의 호스트네임 또는 IP 주소.
|
||||
|
|
@ -797,7 +797,7 @@ parameters:
|
|||
storagePool: sp1
|
||||
storageMode: ThinProvisioned
|
||||
secretRef: sio-secret
|
||||
readOnly: false
|
||||
readOnly: "false"
|
||||
fsType: xfs
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -39,6 +39,10 @@ weight: 41 # just after volume snapshots
|
|||
처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가
|
||||
생성된 이후에는 업데이트할 수 없다.
|
||||
|
||||
{{< note >}}
|
||||
CRD의 설치는 쿠버네티스 배포판의 책임이다. 필요한 CRD가 존재하지 않는다면, 볼륨스냅샷클래스 생성이 실패할 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotClass
|
||||
|
|
|
|||
|
|
@ -273,7 +273,7 @@ spec:
|
|||
* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하기 위해서는
|
||||
먼저 컨피그맵을 생성해야 한다.
|
||||
|
||||
* 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
|
||||
* 컨피그맵을 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
|
||||
업데이트를 수신하지 않는다.
|
||||
|
||||
* 텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩의 경우, `binaryData` 를 사용한다.
|
||||
|
|
@ -285,7 +285,7 @@ spec:
|
|||
이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다.
|
||||
|
||||
{{< note >}}
|
||||
다운워드 API를 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API
|
||||
다운워드 API를 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API
|
||||
업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -859,7 +859,7 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
|
|||
드라이버로 리다이렉트한다.
|
||||
이 기능을 사용하려면, 클러스터에
|
||||
[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고
|
||||
`CSIMigration`, `CSIMigrationRBD`
|
||||
`CSIMigration`, `csiMigrationRBD`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -894,7 +894,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
|
|||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
시크릿을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿
|
||||
시크릿을 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 시크릿
|
||||
업데이트를 수신하지 못한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -1133,6 +1133,7 @@ spec:
|
|||
volumeMounts:
|
||||
- name: workdir1
|
||||
mountPath: /logs
|
||||
# 변수 확장에는 괄호를 사용한다(중괄호 아님).
|
||||
subPathExpr: $(POD_NAME)
|
||||
restartPolicy: Never
|
||||
volumes:
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
|
|||
|
||||
다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
|
||||
두 가지 개념이다.
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
* [가비지(Garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)은 _소유하는 리소스_ 가
|
||||
제거된 후 클러스터에서 오브젝트를 정리한다.
|
||||
* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
|
||||
잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
|
||||
|
|
|
|||
|
|
@ -842,6 +842,13 @@ nginx-deployment-618515232 11 11 11 7m
|
|||
* 디플로이먼트로 기존 레플리카셋을 스케일 다운.
|
||||
* 새 파드가 준비되거나 이용할 수 있음(최소 [준비 시간(초)](#최소-대기-시간-초) 동안 준비됨).
|
||||
|
||||
롤아웃이 "진행 중" 상태가 되면,
|
||||
디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
|
||||
|
||||
* `type: Progressing`
|
||||
* `status: "True"`
|
||||
* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated`
|
||||
|
||||
`kubectl rollout status` 를 사용해서 디플로이먼트의 진행사황을 모니터할 수 있다.
|
||||
|
||||
### 디플로이먼트 완료
|
||||
|
|
@ -853,6 +860,17 @@ nginx-deployment-618515232 11 11 11 7m
|
|||
* 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때.
|
||||
* 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때.
|
||||
|
||||
롤아웃이 "완료" 상태가 되면,
|
||||
디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions`에 다음 속성을 포함하는 컨디션을 추가한다.
|
||||
|
||||
* `type: Progressing`
|
||||
* `status: "True"`
|
||||
* `reason: NewReplicaSetAvailable`
|
||||
|
||||
이 `Progressing` 컨디션은 새로운 롤아웃이 시작되기 전까지는 `"True"` 상태값을 유지할 것이다.
|
||||
레플리카의 가용성이 변경되는 경우에도(이 경우 `Available` 컨디션에 영향을 미침)
|
||||
컨디션은 유지된다.
|
||||
|
||||
`kubectl rollout status` 를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있다.
|
||||
만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.
|
||||
|
||||
|
|
@ -890,7 +908,7 @@ echo $?
|
|||
대기하는 시간(초)를 나타낸다.
|
||||
|
||||
다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가
|
||||
10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
|
||||
10분 후 디플로이먼트 롤아웃에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
|
||||
|
||||
```shell
|
||||
kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
|
||||
|
|
@ -902,14 +920,17 @@ deployment.apps/nginx-deployment patched
|
|||
만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의
|
||||
디플로이먼트 컨디션(DeploymentCondition)을 추가한다.
|
||||
|
||||
* Type=Progressing
|
||||
* Status=False
|
||||
* Reason=ProgressDeadlineExceeded
|
||||
* `type: Progressing`
|
||||
* `status: "False"`
|
||||
* `reason: ProgressDeadlineExceeded`
|
||||
|
||||
이 컨디션은 일찍 실패할 수도 있으며 이러한 경우 `ReplicaSetCreateError`를 이유로 상태값을 `"False"`로 설정한다.
|
||||
또한, 디플로이먼트 롤아웃이 완료되면 데드라인은 더 이상 고려되지 않는다.
|
||||
|
||||
컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다.
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을
|
||||
쿠버네티스는 `reason: ProgressDeadlineExceeded` 과 같은 상태 조건을
|
||||
보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며,
|
||||
예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다.
|
||||
{{< /note >}}
|
||||
|
|
@ -984,7 +1005,7 @@ Conditions:
|
|||
디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나,
|
||||
네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다.
|
||||
만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면
|
||||
성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`).
|
||||
성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`status: "True"` 와 `reason: NewReplicaSetAvailable`).
|
||||
|
||||
```
|
||||
Conditions:
|
||||
|
|
@ -994,11 +1015,11 @@ Conditions:
|
|||
Progressing True NewReplicaSetAvailable
|
||||
```
|
||||
|
||||
`Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
|
||||
최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가
|
||||
`type: Available` 과 `status: "True"` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다.
|
||||
최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `type: Progressing` 과 `status: "True"` 는 디플로이먼트가
|
||||
롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다.
|
||||
(자세한 내용은 특정 조건의 이유를 참조한다.
|
||||
이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)
|
||||
이 경우 `reason: NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.)
|
||||
|
||||
`kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다.
|
||||
`kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
|
||||
|
|
@ -1153,8 +1174,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
|
|||
|
||||
### 진행 기한 시간(초)
|
||||
|
||||
`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의
|
||||
상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
|
||||
`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `type: Progressing`, `status: "False"`의
|
||||
상태 그리고 리소스가 `reason: ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에
|
||||
디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다.
|
||||
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다.
|
||||
미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고,
|
||||
|
|
|
|||
|
|
@ -1,196 +0,0 @@
|
|||
---
|
||||
title: 가비지(Garbage) 수집
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
{{< note >}}
|
||||
이 한글 문서는 더 이상 관리되지 않습니다.
|
||||
|
||||
이 문서의 기반이 된 영어 원문은 삭제되었으며,
|
||||
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
|
||||
|
||||
[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
|
||||
이 문서는 삭제될 수 있습니다.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
|
||||
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 소유자(owner)와 종속(dependent)
|
||||
|
||||
일부 쿠버네티스 오브젝트는 다른 오브젝트의 소유자이다. 예를 들어 레플리카셋은
|
||||
파드 집합의 소유자이다. 소유자 오브젝트에게 소유된 오브젝트를 *종속*
|
||||
이라고 한다. 모든 종속 오브젝트는 소유하는 오브젝트를 가르키는 `metadata.ownerReferences`
|
||||
필드를 가지고 있다.
|
||||
|
||||
때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다.
|
||||
예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의
|
||||
`ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가
|
||||
레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡
|
||||
그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을
|
||||
자동으로 설정한다.
|
||||
|
||||
또한 `ownerReference` 필드를 수동으로 설정해서 소유자와 종속 항목 간의
|
||||
관계를 지정할 수도 있다.
|
||||
|
||||
여기에 파드 3개가 있는 레플리카셋의 구성 파일이 있다.
|
||||
|
||||
{{< codenew file="controllers/replicaset.yaml" >}}
|
||||
|
||||
레플리카셋을 생성하고 파드의 메타데이터를 본다면,
|
||||
OwnerReferences 필드를 찾을 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
|
||||
kubectl get pods --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 소유자가 `my-repset` 이라는 이름의 레플리카셋인 것을 보여준다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
controller: true
|
||||
blockOwnerDeletion: true
|
||||
kind: ReplicaSet
|
||||
name: my-repset
|
||||
uid: d9607e19-f88f-11e6-a518-42010a800195
|
||||
...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
|
||||
|
||||
네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
|
||||
네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
|
||||
그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
|
||||
종속 항목이 삭제될 수 있다.
|
||||
|
||||
클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
|
||||
v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
|
||||
확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
|
||||
|
||||
v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
|
||||
또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
|
||||
`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
|
||||
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
|
||||
이러한 종류의 이벤트를 확인할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 가비지 수집기의 종속 항목 삭제 방식 제어
|
||||
|
||||
오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의
|
||||
여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading)
|
||||
삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다.
|
||||
|
||||
만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면,
|
||||
종속 항목은 *분리됨(orphaned)* 이라고 한다.
|
||||
|
||||
### 포어그라운드 캐스케이딩 삭제
|
||||
|
||||
*포어그라운드 캐스케이딩 삭제* 에서는 루트 오브젝트가 먼저
|
||||
"삭제 중(deletion in progress)" 상태가 된다. "삭제 중" 상태에서는
|
||||
다음 사항이 적용된다.
|
||||
|
||||
* 오브젝트는 REST API를 통해 여전히 볼 수 있음
|
||||
* 오브젝트에 `deletionTimestamp` 가 설정됨
|
||||
* 오브젝트의 "foregroundDeletion"에 `metadata.finalizers` 값이 포함됨.
|
||||
|
||||
"삭제 중" 상태가 설정되면, 가비지
|
||||
수집기는 오브젝트의 종속 항목을 삭제한다. 가비지 수집기는 모든
|
||||
"차단" 종속 항목(`ownerReference.blockOwnerDeletion=true` 가 있는 오브젝트)의 삭제가 완료되면,
|
||||
소유자 오브젝트를 삭제한다.
|
||||
|
||||
"foregroundDeletion" 에서는 ownerReference.blockOwnerDeletion=true 로
|
||||
설정된 종속 항목만 소유자 오브젝트의 삭제를 차단한다는 것을 참고한다.
|
||||
쿠버네티스 버전 1.7에서는 소유자 오브젝트에 대한 삭제 권한에 따라 `blockOwnerDeletion` 를 true로 설정하기 위해 사용자 접근을 제어하는
|
||||
[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)가
|
||||
추가되었기에 권한이 없는 종속 항목은 소유자 오브젝트의 삭제를 지연시킬 수 없다.
|
||||
|
||||
만약 오브젝트의 `ownerReferences` 필드가 컨트롤러(디플로이먼트 또는 레플리카셋과 같은)에
|
||||
의해 설정된 경우 blockOwnerDeletion이 자동으로 설정되므로 이 필드를 수동으로 수정할 필요가 없다.
|
||||
|
||||
### 백그라운드 캐스케이딩 삭제
|
||||
|
||||
*백그라운드 캐스케이딩 삭제* 에서 쿠버네티스는 소유자 오브젝트를
|
||||
즉시 삭제하고, 가비지 수집기는 백그라운드에서 종속 항목을
|
||||
삭제한다.
|
||||
|
||||
### 캐스케이딩 삭제 정책 설정하기
|
||||
|
||||
캐스케이딩 삭제 정책을 제어하려면, 오브젝트를 삭제할 때 `deleteOptions`
|
||||
인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
|
||||
"Foreground" 또는 "Background" 이다.
|
||||
|
||||
여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
여기에 포어그라운드에서 종속 항목을 삭제하는 예시가 있다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
여기에 종속 항목을 분리됨으로 하는 예시가 있다.
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
kubectl도 캐스케이딩 삭제를 지원한다.
|
||||
|
||||
kubectl을 사용해서 포어그라운드의 종속 항목을 삭제하려면 `--cascade=foreground` 를 설정한다. 종속 항목을
|
||||
분리하기 위해서는 `--cascade=orphan` 를 설정한다.
|
||||
|
||||
기본 동작은 백그라운드의 종속 항목을 삭제하는 것이며,
|
||||
이는 `--cascade` 를 생략하거나 명시적으로 `background` 를 설정한 경우의 동작에 해당한다.
|
||||
|
||||
여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete replicaset my-repset --cascade=false
|
||||
```
|
||||
|
||||
### 디플로이먼트에 대한 추가 참고
|
||||
|
||||
1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
|
||||
를 사용해서 생성된 레플리카셋뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
|
||||
유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
|
||||
더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
|
||||
|
||||
## 알려진 이슈들
|
||||
|
||||
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
|
@ -416,10 +416,10 @@ spec:
|
|||
| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any |
|
||||
| [잡 템플릿 확장] | 1 | 1이어야 함 |
|
||||
|
||||
[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/
|
||||
[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/
|
||||
[작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/
|
||||
[가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
|
||||
[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
|
||||
[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/
|
||||
[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
|
||||
|
||||
## 고급 사용법
|
||||
|
||||
|
|
@ -615,8 +615,8 @@ spec:
|
|||
```
|
||||
|
||||
새 잡 자체는 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 와 다른 uid 를 가지게 될 것이다.
|
||||
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
|
||||
불일치를 허용한다.
|
||||
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있으며
|
||||
이런 불일치를 허용한다고 알릴 수 있다.
|
||||
|
||||
### 종료자(finalizers)를 이용한 잡 추적
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 20
|
|||
레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
|
||||
사용한다.
|
||||
|
||||
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
|
||||
레플리카셋은 파드의 [metadata.ownerReferences](/ko/docs/concepts/architecture/garbage-collection/#소유자-owner-와-종속-dependent)
|
||||
필드를 통해 파드에 연결되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
|
||||
레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
|
||||
이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
|
||||
|
|
@ -269,7 +269,7 @@ matchLabels:
|
|||
|
||||
### 레플리카셋과 해당 파드 삭제
|
||||
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
|
||||
레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/architecture/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
|
||||
|
||||
REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
|
||||
설정해야 한다.
|
||||
|
|
|
|||
|
|
@ -405,7 +405,7 @@ spec:
|
|||
* [스테이트풀셋 확장하기](/ko/docs/tasks/run-application/scale-stateful-set/)에 대해 배운다.
|
||||
* [스테이트풀셋을 삭제하면](/ko/docs/tasks/run-application/delete-stateful-set/) 어떤 일이 수반되는지를 배운다.
|
||||
* [스토리지의 볼륨을 사용하는 파드 구성](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)을 하는 방법을 배운다.
|
||||
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
|
||||
* [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
|
||||
* `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
|
||||
스테이트풀셋 API에 대해 이해하기 위해
|
||||
{{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
|
|||
일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
|
||||
|
||||
파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는
|
||||
두 가지 종류의 공유 리소스를 제공한다.
|
||||
두 가지 종류의 공유 리소스를 제공한다.
|
||||
|
||||
## 파드 작업
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ graph TB
|
|||
class zoneA,zoneB cluster;
|
||||
{{< /mermaid >}}
|
||||
|
||||
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
|
||||
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘 알려진 레이블](/ko/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
|
||||
|
||||
## 파드의 분배 제약 조건
|
||||
|
||||
|
|
|
|||
|
|
@ -110,15 +110,13 @@ SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/
|
|||
|
||||
## SIG 공동 의장으로 봉사
|
||||
|
||||
SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는
|
||||
SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는
|
||||
SIG Docs의 공동 의장 역할을 할 수 있다.
|
||||
|
||||
### 전제 조건
|
||||
|
||||
승인자는 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.
|
||||
쿠버네티스 멤버가 공동 의장이 되려면 다음의 요구 사항을 충족해야 한다.
|
||||
|
||||
- 6개월 이상 SIG Docs 승인자로 활동한다.
|
||||
- [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다.
|
||||
- SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트).
|
||||
- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
|
||||
[k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs),
|
||||
|
|
@ -126,6 +124,8 @@ SIG Docs의 공동 의장 역할을 할 수 있다.
|
|||
[SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의
|
||||
역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는
|
||||
영향을 이해한다.
|
||||
추가로, [쿠버네티스 문서 릴리스 프로세스](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정)가 어떻게 동작하는지 이해한다.
|
||||
- SIG Docs 커뮤니티에 이해 직접적으로 또는 lazy consensus(특정 기간 내에 아무런 의견이 없으면 통과)를 통해 승인된다.
|
||||
- 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다.
|
||||
|
||||
### 책임
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ repos:
|
|||
`generate-command` 필드의 내용은 수정하지 말아야 한다.
|
||||
대부분의 경우 `reference.yml` 을 직접 수정해야 할 필요는 없다.
|
||||
때때로, 업스트림 소스코드 업데이트 때문에 이 환경설정 파일을 수정해야 할 수도 있다.
|
||||
(예: Golang 버전 의존성, 서드파티 라이브러리 변경 등)
|
||||
(예: Golang 버전 의존성, 써드파티 라이브러리 변경 등)
|
||||
만약 스크립트 사용 시 빌드 문제가 있다면,
|
||||
[쿠버네티스 슬랙의 #sig-docs 채널](https://kubernetes.slack.com/archives/C1J0BPD2M)에서 SIG-Docs 팀에 문의하면 된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
|
|||
- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.
|
||||
|
||||
{{< note >}}
|
||||
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, "LGTM" 코멘트를 남기는 것도 좋다!
|
||||
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면,
|
||||
"LGTM" 코멘트를 남기는 것도 좋다!
|
||||
{{< /note >}}
|
||||
|
||||
- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
|
||||
|
|
@ -89,7 +90,8 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
|
|||
쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다.
|
||||
축하한다!
|
||||
|
||||
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
|
||||
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다.
|
||||
피드백의 내용을 해결한 후, 다시 지원하자.
|
||||
|
||||
1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.
|
||||
|
||||
|
|
@ -138,7 +140,8 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
|
|||
### 리뷰어 되기
|
||||
|
||||
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
|
||||
충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
|
||||
충족하면, SIG Docs 리뷰어가 될 수 있다.
|
||||
다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
|
||||
반드시 별도로 지원해야 한다.
|
||||
|
||||
지원하려면, 다음을 수행한다.
|
||||
|
|
|
|||
|
|
@ -72,14 +72,14 @@ PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR
|
|||
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는
|
||||
풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는
|
||||
챗봇 스타일 명령으로 쿠버네티스
|
||||
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
|
||||
조직 전체에서 [레이블 추가와 제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
|
||||
|
||||
리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다.
|
||||
|
||||
{{< table caption="리뷰를 위한 Prow 명령" >}}
|
||||
Prow 명령 | 역할 제한 | 설명
|
||||
:------------|:------------------|:-----------
|
||||
`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
|
||||
`/lgtm` | 조직 멤버 | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
|
||||
`/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다.
|
||||
`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다.
|
||||
`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다.
|
||||
|
|
|
|||
|
|
@ -85,7 +85,11 @@ class third,fourth white
|
|||
- PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
|
||||
- 다른 리뷰어의 의견 읽기
|
||||
- **Files changed** 탭을 클릭하여 변경된 파일과 행 보기
|
||||
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인
|
||||
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 Netlify 미리보기 빌드의 변경 사항을 확인.
|
||||
다음은 스크린샷이다(GitHub 데스크탑 사이트이며,
|
||||
태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다).
|
||||
{{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="Netlify 미리보기 링크를 포함하는 GitHub PR 상세 사항" >}}
|
||||
미리보기를 열려면, 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다.
|
||||
|
||||
4. **Files changed** 탭으로 이동하여 리뷰를 시작한다.
|
||||
1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ weight: 20
|
|||
타입 | 설명
|
||||
:--- | :----------
|
||||
개념 | 개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 <a href="/ko/docs/concepts/architecture/nodes/">노드</a>를 참조하자.
|
||||
태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
|
||||
태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/ko/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
|
||||
튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
|
||||
{{< /table >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ no_list: true
|
|||
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
|
||||
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
|
||||
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/)
|
||||
* [잘 알려진 레이블, 어노테이션과 테인트](/ko/docs/reference/labels-annotations-taints/)
|
||||
|
||||
## 공식적으로 지원되는 클라이언트 라이브러리
|
||||
|
||||
|
|
@ -73,14 +73,16 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
|
|||
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
|
||||
제공하지 않는다.
|
||||
|
||||
* [kube-apiserver 환경설정 (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/)
|
||||
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
|
||||
* [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
|
||||
|
||||
* [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
|
||||
* [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
|
||||
[kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
|
||||
[kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
|
||||
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
|
||||
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및
|
||||
[클라이언트 인증 API (v1)](/docs/reference/config-api/client-authentication.v1/)
|
||||
* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
|
||||
|
||||
## kubeadm을 위한 API 설정
|
||||
|
|
|
|||
|
|
@ -25,7 +25,8 @@ card:
|
|||
각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을
|
||||
활성화 또는 비활성화할 수 있다.
|
||||
모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다.
|
||||
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
|
||||
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
||||
기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
|
||||
|
||||
```shell
|
||||
--feature-gates="...,GracefulNodeShutdown=true"
|
||||
|
|
@ -53,7 +54,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
|---------|---------|-------|-------|-------|
|
||||
| `APIListChunking` | `false` | 알파 | 1.8 | 1.8 |
|
||||
| `APIListChunking` | `true` | 베타 | 1.9 | |
|
||||
| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 |
|
||||
| `APIPriorityAndFairness` | `false` | 알파 | 1.18 | 1.19 |
|
||||
| `APIPriorityAndFairness` | `true` | 베타 | 1.20 | |
|
||||
| `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
|
||||
| `APIResponseCompression` | `true` | 베타 | 1.16 | |
|
||||
|
|
@ -65,7 +66,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
|
||||
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
|
||||
| `CPUManager` | `true` | 베타 | 1.10 | |
|
||||
| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | |
|
||||
| `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | |
|
||||
| `CPUManagerPolicyBetaOptions` | `true` | 베타 | 1.23 | |
|
||||
| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | 1.22 |
|
||||
| `CPUManagerPolicyOptions` | `true` | 베타 | 1.23 | |
|
||||
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
|
||||
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
|
||||
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
|
||||
|
|
@ -85,13 +89,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
|
||||
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
|
||||
| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | |
|
||||
| `CSIMigrationRBD` | `false` | 알파 | 1.23 | |
|
||||
| `csiMigrationRBD` | `false` | 알파 | 1.23 | |
|
||||
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
|
||||
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
|
||||
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
|
||||
| `CSRDuration` | `true` | 베타 | 1.22 | |
|
||||
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
|
||||
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
|
||||
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
|
||||
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
|
||||
|
|
@ -100,12 +102,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
|
||||
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
|
||||
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
|
||||
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | |
|
||||
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 |
|
||||
| `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | |
|
||||
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
|
||||
| `DevicePlugins` | `true` | 베타 | 1.10 | |
|
||||
| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
|
||||
| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
|
||||
| `DisableCloudProviders` | `false` | 알파 | 1.22 | |
|
||||
| `DisableKubeletCloudCredentialProviders` | `false` | 알파 | 1.23 | |
|
||||
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
|
||||
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
|
||||
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
|
||||
|
|
@ -124,7 +128,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
|
||||
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
|
||||
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
|
||||
| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | |
|
||||
| `GRPCContainerProbe` | `false` | 알파 | 1.23 | |
|
||||
| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | |
|
||||
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
|
||||
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
|
||||
| `IdentifyPodOS` | `false` | 알파 | 1.23 | |
|
||||
|
|
@ -135,6 +141,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
|
||||
| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | |
|
||||
| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | |
|
||||
| `InTreePluginPortworxUnregister` | `false` | 알파 | 1.23 | |
|
||||
| `InTreePluginRBDUnregister` | `false` | 알파 | 1.23 | |
|
||||
| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
|
||||
| `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | |
|
||||
| `JobReadyPods` | `false` | 알파 | 1.23 | |
|
||||
|
|
@ -142,7 +150,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | |
|
||||
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
|
||||
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
|
||||
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
|
||||
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
|
||||
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
|
||||
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 |
|
||||
| `KubeletPodResourcesGetAllocatable` | `false` | 베타 | 1.23 | |
|
||||
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
|
||||
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
|
||||
|
|
@ -157,10 +168,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `NodeSwap` | `false` | 알파 | 1.22 | |
|
||||
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
|
||||
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
|
||||
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
|
||||
| `OpenAPIEnums` | `false` | 알파 | 1.23 | |
|
||||
| `OpenAPIV3` | `false` | 알파 | 1.23 | |
|
||||
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
|
||||
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
|
||||
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
|
||||
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
|
||||
| `PodOverhead` | `true` | 베타 | 1.18 | |
|
||||
| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 |
|
||||
|
|
@ -189,6 +203,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
|
||||
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
|
||||
| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
|
||||
| `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | |
|
||||
| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 |
|
||||
| `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | |
|
||||
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
|
||||
|
|
@ -197,13 +212,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `SuspendJob` | `true` | 베타 | 1.22 | |
|
||||
| `TopologyAwareHints` | `false` | 알파 | 1.21 | 1.22 |
|
||||
| `TopologyAwareHints` | `true` | 베타 | 1.23 | |
|
||||
| `TopologyAwareHints` | `false` | 베타 | 1.23 | |
|
||||
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
|
||||
| `TopologyManager` | `true` | 베타 | 1.18 | |
|
||||
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
|
||||
| `WinDSR` | `false` | 알파 | 1.14 | |
|
||||
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
|
||||
| `WinOverlay` | `true` | 베타 | 1.20 | |
|
||||
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 |
|
||||
| `WindowsHostProcessContainers` | `false` | 베타 | 1.23 | |
|
||||
{{< /table >}}
|
||||
|
||||
|
|
@ -233,6 +249,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
|
||||
| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 |
|
||||
| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
|
||||
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
|
||||
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 |
|
||||
| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | |
|
||||
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
|
||||
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
|
||||
|
|
@ -312,12 +330,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
|
||||
| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 |
|
||||
| `EndpointSliceProxying` | `true` | GA | 1.22 | - |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
|
||||
| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
|
||||
| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
|
||||
| `EvenPodsSpread` | `true` | GA | 1.19 | - |
|
||||
| `ExecProbeTimeout` | `true` | GA | 1.20 | - |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
|
||||
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
|
||||
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
|
||||
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
|
||||
|
|
@ -330,9 +348,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `HugePages` | `false` | 알파 | 1.8 | 1.9 |
|
||||
| `HugePages` | `true` | 베타| 1.10 | 1.13 |
|
||||
| `HugePages` | `true` | GA | 1.14 | - |
|
||||
| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
|
||||
| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
|
||||
| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
|
||||
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
|
||||
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
|
||||
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
|
||||
|
|
@ -351,9 +366,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
|
||||
| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 |
|
||||
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
|
||||
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
|
||||
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
|
||||
| `KubeletPodResources` | `true` | GA | 1.20 | |
|
||||
| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
|
||||
| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
|
||||
| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
|
||||
|
|
@ -375,7 +387,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
|
||||
| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
|
||||
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
|
||||
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
|
||||
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
|
||||
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 |
|
||||
| `PodDisruptionBudget` | `true` | GA | 1.21 | - |
|
||||
|
|
@ -497,7 +508,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 |
|
||||
| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 |
|
||||
| `WindowsGMSA` | `true` | GA | 1.18 | - |
|
||||
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 |
|
||||
| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 |
|
||||
| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 |
|
||||
| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
|
||||
|
|
@ -553,7 +563,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
|
||||
- `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
|
||||
- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다.
|
||||
- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
|
||||
- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는
|
||||
플러그인의 초기 형태를 제공하였으며, 사용 중단되었다.
|
||||
대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
|
||||
확인한다.
|
||||
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
|
||||
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
|
||||
설정을 활성화한다.
|
||||
|
|
@ -562,8 +575,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
TLS 확인을 건너뛸 수 있도록 한다.
|
||||
- `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의
|
||||
`DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다.
|
||||
- `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
|
||||
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
|
||||
- `AppArmor`: 리눅스 노드에서 실행되는 파드에 대한 AppArmor 필수 접근 제어의 사용을 활성화한다.
|
||||
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다.
|
||||
- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
|
||||
대한 제한을 보고하도록 한다.
|
||||
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
|
||||
|
|
@ -586,6 +599,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
리더 마이그레이션(Leader Migration)을 활성화한다.
|
||||
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
|
||||
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
|
||||
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다.
|
||||
이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다.
|
||||
이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다.
|
||||
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다.
|
||||
이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다.
|
||||
이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다.
|
||||
- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
|
||||
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
|
||||
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
|
||||
|
|
@ -638,9 +657,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
|
||||
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
|
||||
지원한다. CSIMigration 기능 플래그가 필요하다.
|
||||
- `CSIMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
클러스터에 CSIMigration 및 CSIMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
|
||||
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
|
||||
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
|
||||
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는
|
||||
`InTreePluginRBDUnregister` 기능 플래그에 의해
|
||||
|
|
@ -716,6 +735,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
|
||||
- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
|
||||
데몬셋 워크로드를 사용하도록 설정한다.
|
||||
[데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다.
|
||||
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
|
||||
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
|
||||
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
|
||||
|
|
@ -728,6 +748,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
|
||||
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
|
||||
모든 기능을 비활성화한다.
|
||||
- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해
|
||||
클라우드 프로바이더 컨테이너 레지스트리에 인증을 수행하는 kubelet 내부(in-tree) 기능을 비활성화한다.
|
||||
- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
|
||||
hugepages 사용을 활성화한다.
|
||||
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
|
||||
|
|
@ -768,6 +790,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
|
||||
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
|
||||
kubelet과 kube-apiserver를 사용하도록 설정한다.
|
||||
이 기능을 사용하려면 컨테이너 런타임이 지원해야 한다(Containerd: v1.5.6 이상, CRI-O: v1.22 이상).
|
||||
[확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
|
||||
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
|
||||
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
|
||||
|
|
@ -792,7 +815,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
|
||||
[Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을
|
||||
참조한다.
|
||||
- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때
|
||||
kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다.
|
||||
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
|
||||
- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
|
||||
- `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
|
||||
개별 컨테이너 메트릭을 기반으로 확장한다.
|
||||
- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
|
||||
|
|
@ -818,6 +844,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
|
||||
|
|
@ -889,6 +919,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
|
||||
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
|
||||
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
|
||||
- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의
|
||||
"enum" 필드 채우기를 활성화한다.
|
||||
- `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다.
|
||||
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
|
||||
삭제되지 않도록 한다.
|
||||
- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 애그리게이션 레이어(Aggregation Layer)
|
||||
id: aggregation-layer
|
||||
date: 2018-10-08
|
||||
full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
|
||||
full_link: /ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
|
||||
short_description: >
|
||||
애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 컨피그맵(ConfigMap)
|
||||
id: configmap
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/configuration/configmap/
|
||||
full_link: /ko/docs/concepts/configuration/configmap/
|
||||
short_description: >
|
||||
키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 컨테이너 런타임
|
||||
id: container-runtime
|
||||
date: 2019-06-05
|
||||
full_link: /docs/setup/production-environment/container-runtimes
|
||||
full_link: /ko/docs/setup/production-environment/container-runtimes/
|
||||
short_description: >
|
||||
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스는 여러 컨테이너 런타임을 지원한다. {{< glossary_tooltip term_id="docker">}},
|
||||
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}
|
||||
그리고 [Kubernetes CRI (컨테이너 런타임
|
||||
인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어.
|
||||
쿠버네티스는 {{< glossary_tooltip term_id="containerd" >}},
|
||||
{{< glossary_tooltip term_id="cri-o" >}}와 같은 컨테이너 런타임 및
|
||||
모든 [Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
|
||||
구현체를 지원한다.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 장치 플러그인(Device Plugin)
|
||||
id: device-plugin
|
||||
date: 2019-02-02
|
||||
full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
|
||||
full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
|
||||
short_description: >
|
||||
파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장
|
||||
aka:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: 가비지(Garbage) 수집
|
||||
id: garbage-collection
|
||||
date: 2022-01-14
|
||||
full_link: /ko/docs/concepts/architecture/garbage-collection/
|
||||
short_description: >
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
[실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고
|
||||
만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: 잡(Job)
|
||||
id: job
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/job
|
||||
full_link: /ko/docs/concepts/workloads/controllers/job/
|
||||
short_description: >
|
||||
완료를 목표로 실행되는 유한 또는 배치 작업.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: kube-proxy
|
||||
id: kube-proxy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
|
||||
full_link: /ko/docs/reference/command-line-tools-reference/kube-proxy/
|
||||
short_description: >
|
||||
`kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 범위 제한(LimitRange)
|
||||
id: limitrange
|
||||
date: 2019-04-15
|
||||
full_link: /docs/concepts/policy/limit-range/
|
||||
full_link: /ko/docs/concepts/policy/limit-range/
|
||||
short_description: >
|
||||
네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 로깅(Logging)
|
||||
id: logging
|
||||
date: 2019-04-04
|
||||
full_link: /docs/concepts/cluster-administration/logging/
|
||||
full_link: /ko/docs/concepts/cluster-administration/logging/
|
||||
short_description: >
|
||||
로그는 클러스터나 애플리케이션에 의해 로깅된 이벤트의 목록이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 네트워크 폴리시(Network Policy)
|
||||
id: network-policy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/services-networking/network-policies/
|
||||
full_link: /ko/docs/concepts/services-networking/network-policies/
|
||||
short_description: >
|
||||
파드 그룹들이 서로에 대한 그리고 다른 네트워크 엔드포인트에 대한 통신이 어떻게 허용되는지에 대한 명세이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 파드 시큐리티 폴리시(Pod Security Policy)
|
||||
id: pod-security-policy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/policy/pod-security-policy/
|
||||
full_link: /ko/docs/concepts/policy/pod-security-policy/
|
||||
short_description: >
|
||||
파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 리소스 쿼터(Resource Quotas)
|
||||
id: resource-quota
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/policy/resource-quotas/
|
||||
full_link: /ko/docs/concepts/policy/resource-quotas/
|
||||
short_description: >
|
||||
네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 서비스(Service)
|
||||
id: service
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
full_link: /ko/docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 스태틱 파드(Static Pod)
|
||||
id: static-pod
|
||||
date: 2019-02-12
|
||||
full_link: /docs/tasks/configure-pod-container/static-pod/
|
||||
full_link: /ko/docs/tasks/configure-pod-container/static-pod/
|
||||
short_description: >
|
||||
특정 노드의 Kubelet 데몬이 직접 관리하는 파드
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 테인트(Taint)
|
||||
id: taint
|
||||
date: 2019-01-11
|
||||
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
|
||||
short_description: >
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 톨러레이션(Toleration)
|
||||
id: toleration
|
||||
date: 2019-01-11
|
||||
full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/
|
||||
full_link: /ko/docs/concepts/scheduling-eviction/taint-and-toleration/
|
||||
short_description: >
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,29 +31,6 @@ content_type: concept
|
|||
|
||||
`--dry-run` 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
모든 `kubectl run`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 생성기
|
||||
`kubectl create --dry-run -o yaml`라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.
|
||||
|
||||
* `clusterrole`: 클러스터롤(ClusterRole)를 생성한다.
|
||||
* `clusterrolebinding`: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
|
||||
* `configmap`: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
|
||||
* `cronjob`: 지정된 이름으로 크론잡(CronJob)을 생성한다.
|
||||
* `deployment`: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
|
||||
* `job`: 지정된 이름으로 잡(Job)을 생성한다.
|
||||
* `namespace`: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
|
||||
* `poddisruptionbudget`: 지정된 이름으로 PodDisruptionBudget을 생성한다.
|
||||
* `priorityclass`: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
|
||||
* `quota`: 지정된 이름으로 쿼터(Quota)를 생성한다.
|
||||
* `role`: 단일 규칙으로 롤(Role)을 생성한다.
|
||||
* `rolebinding`: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
|
||||
* `secret`: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
|
||||
* `service`: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
|
||||
* `serviceaccount`: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
|
||||
|
||||
### `kubectl apply`
|
||||
|
||||
* `kubectl apply`를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 [Kubectl 책](https://kubectl.docs.kubernetes.io)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -159,6 +159,20 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클
|
|||
`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다.
|
||||
`PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다.
|
||||
|
||||
## volume.beta.kubernetes.io/storage-provisioner (사용 중단됨)
|
||||
|
||||
예시: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath`
|
||||
|
||||
적용 대상: PersistentVolumeClaim
|
||||
|
||||
이 어노테이션은 사용 중단되었다.
|
||||
|
||||
## volume.kubernetes.io/storage-provisioner
|
||||
|
||||
적용 대상: PersistentVolumeClaim
|
||||
|
||||
이 어노테이션은 동적 프로비저닝이 요구되는 PVC에 추가될 예정이다.
|
||||
|
||||
## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build}
|
||||
|
||||
예시: `node.kubernetes.io/windows-build=10.0.17763`
|
||||
|
|
|
|||
|
|
@ -17,4 +17,3 @@ sitemap:
|
|||
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
|
||||
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
|
||||
* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기
|
||||
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기
|
||||
|
|
|
|||
|
|
@ -12,16 +12,17 @@ no_list: true
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## Minikube
|
||||
## crictl
|
||||
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로
|
||||
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
|
||||
실행하는 도구이다.
|
||||
[`crictl`](https://github.com/kubernetes-sigs/cri-tools)은
|
||||
{{<glossary_tooltip term_id="cri" text="CRI">}}-호환 컨테이너 런타임의 조사 및 디버깅을 위한
|
||||
명령줄 인터페이스이다.
|
||||
|
||||
## 대시보드
|
||||
|
||||
[`대시보드`](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/), 는 쿠버네티스의 웹기반 유저 인터페이스이며 컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고
|
||||
클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.
|
||||
[`대시보드`](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)는
|
||||
쿠버네티스의 웹기반 유저 인터페이스이며
|
||||
컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고 클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해 준다.
|
||||
|
||||
## Helm
|
||||
{{% thirdparty-content single="true" %}}
|
||||
|
|
@ -65,3 +66,9 @@ Kui를 사용하면 다음의 작업이 가능하다.
|
|||
* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여
|
||||
실행 형상을 워터폴 그림으로 확인한다.
|
||||
* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다.
|
||||
|
||||
## Minikube
|
||||
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로
|
||||
단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서
|
||||
실행하는 도구이다.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
|
|||
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
|
||||
| PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
|
||||
| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
|
||||
| Python | [github.com/gtsystem/lightkube](https://github.com/gtsystem/lightkube) |
|
||||
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
|
||||
| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
|
||||
| Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: PKI 인증서 및 요구 사항
|
||||
|
||||
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
|
@ -75,7 +77,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
|
|||
|
||||
| 기본 CN | 부모 CA | O (주체에서) | 종류 | 호스트 (SAN) |
|
||||
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
|
||||
| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` |
|
||||
| kube-etcd | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-healthcheck-client | etcd-ca | | client | |
|
||||
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
|
||||
|
|
|
|||
|
|
@ -15,12 +15,19 @@ weight: 20
|
|||
|
||||
<!-- body -->
|
||||
|
||||
쿠버네티스 {{< skew currentVersion >}}에서는
|
||||
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
|
||||
런타임을 사용해야 한다.
|
||||
|
||||
더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다.
|
||||
|
||||
이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한
|
||||
세부 정보가 있다.
|
||||
|
||||
- [containerd](#containerd)
|
||||
- [CRI-O](#cri-o)
|
||||
- [도커](#도커)
|
||||
- [도커 엔진](#docker)
|
||||
- [미란티스 컨테이너 런타임](#mcr)
|
||||
|
||||
{{< note >}}
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
|
|
@ -76,13 +83,17 @@ systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명
|
|||
추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
|
||||
|
||||
```shell
|
||||
# dnf install -y grubby && \
|
||||
# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다.
|
||||
# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해
|
||||
# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다.
|
||||
sudo dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
--update-kernel=ALL \
|
||||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
|
||||
구성을 적용하려면 노드를 재부팅해야 한다.
|
||||
커널이 사용하는 커맨드 라인을 업데이트하려면,
|
||||
변경 사항을 적용하기 위해 노드를 재시작해야 한다.
|
||||
|
||||
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
|
||||
cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
|
||||
|
|
@ -94,13 +105,24 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야
|
|||
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
|
||||
[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
|
||||
|
||||
## CRI 버전 지원 {#cri-versions}
|
||||
|
||||
사용할 컨테이너 런타임이 적어도 CRI의 v1alpha2 이상을 지원해야 한다.
|
||||
|
||||
쿠버네티스 {{< skew currentVersion >}} 버전에서는 기본적으로 CRI API 중 v1을 사용한다.
|
||||
컨테이너 런타임이 v1 API를 지원하지 않으면,
|
||||
kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된다.
|
||||
|
||||
## 컨테이너 런타임
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
|
||||
### containerd
|
||||
|
||||
이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
|
||||
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
|
||||
|
||||
다음 명령을 사용하여 시스템에 containerd를 설치한다.
|
||||
|
||||
필수 구성 요소를 설치 및 구성한다.
|
||||
|
||||
|
|
@ -151,13 +173,12 @@ containerd를 설치한다.
|
|||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
|
||||
설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다.
|
||||
설정(예: `$Version:"1.4.3"`)한 후 다음 명령을 실행한다.
|
||||
|
||||
1. containerd 다운로드
|
||||
|
||||
```powershell
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.
|
||||
gz
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
|
|
@ -393,44 +414,28 @@ cgroup_manager = "cgroupfs"
|
|||
CRI-O의 cgroup 드라이버 구성을 동기화 상태로
|
||||
유지해야 한다.
|
||||
|
||||
### 도커
|
||||
### 도커 엔진 {#docker}
|
||||
|
||||
1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라
|
||||
리눅스 배포판용 도커를 설치한다.
|
||||
이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서
|
||||
검증된 최신 버전의 도커를 찾을 수 있다.
|
||||
도커 엔진은 모든 것을 시작한 컨테이너 런타임이다.
|
||||
이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다.
|
||||
[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서
|
||||
이 런타임 설치의 옵션들을 확인할 수 있다.
|
||||
|
||||
2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.
|
||||
도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다.
|
||||
더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다.
|
||||
|
||||
```shell
|
||||
sudo mkdir /etc/docker
|
||||
cat <<EOF | sudo tee /etc/docker/daemon.json
|
||||
{
|
||||
"exec-opts": ["native.cgroupdriver=systemd"],
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "100m"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
EOF
|
||||
```
|
||||
지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 통해
|
||||
쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는
|
||||
써드파티 어댑터를 찾아볼 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
`overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL
|
||||
또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.
|
||||
{{< /note >}}
|
||||
다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다.
|
||||
|
||||
3. 도커 재시작과 부팅시 실행되게 설정
|
||||
- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
|
||||
|
||||
```shell
|
||||
sudo systemctl enable docker
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
### 미란티스 컨테이너 런타임 {#mcr}
|
||||
|
||||
{{< note >}}
|
||||
더 자세한 내용은
|
||||
- [도커 데몬 설정](https://docs.docker.com/config/daemon/)
|
||||
- [systemd로 도커 제어](https://docs.docker.com/config/daemon/systemd/)
|
||||
{{< /note >}}
|
||||
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
|
||||
이전에는 도커 엔터프라이즈 에디션으로 알려져 있었다.
|
||||
|
||||
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
|
||||
이 컴포넌트는 MCR에 포함되어 있다.
|
||||
|
|
|
|||
|
|
@ -144,7 +144,6 @@ Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에
|
|||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: InitConfiguration
|
||||
nodeRegistration:
|
||||
patches:
|
||||
directory: /home/user/somedir
|
||||
```
|
||||
|
|
@ -159,7 +158,6 @@ nodeRegistration:
|
|||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta3
|
||||
kind: JoinConfiguration
|
||||
nodeRegistration:
|
||||
patches:
|
||||
directory: /home/user/somedir
|
||||
```
|
||||
|
|
|
|||
|
|
@ -702,7 +702,7 @@ kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을
|
|||
* 시크릿에 대한 하위 경로 볼륨 마운트
|
||||
* 호스트 마운트 프로젝션
|
||||
* DefaultMode(UID/GID 종속성에 기인함)
|
||||
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 읽기 전용을 지원한다.
|
||||
* 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 읽기 전용을 지원한다.
|
||||
* 블록 디바이스 매핑
|
||||
* 저장 매체로서의 메모리
|
||||
* uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
|
||||
|
|
@ -763,7 +763,7 @@ DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /
|
|||
파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로
|
||||
소스로 다시 라우팅되지 않는다.
|
||||
|
||||
* TCP/UDP 패킷은 여전히 치환될 수 있기 때문에
|
||||
* TCP/UDP 패킷은 여전히 치환될 수 있기 때문에
|
||||
`ping <destination>`을 `curl <destination>`으로 대체하여
|
||||
외부와의 연결을 디버깅할 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -309,4 +309,4 @@ spec:
|
|||
|
||||
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
[RuntimeClass]: https://kubernetes.io/ko/docs/concepts/containers/runtime-class/
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
|
|||
|
||||
## 클러스터에서 실행되는 서비스로 접근
|
||||
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다.
|
||||
이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 서비스에 접근](/ko/docs/tasks/administer-cluster/access-cluster-services/) 페이지를 참조한다.
|
||||
|
||||
## redirect 요청하기
|
||||
|
||||
|
|
|
|||
|
|
@ -218,8 +218,8 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
|||
#### 워크로드
|
||||
|
||||
선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다.
|
||||
애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여주고
|
||||
각각의 워크로드 종류는 따로 보여진다.
|
||||
해당 뷰는 애플리케이션의 워크로드 종류(예시: 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet))를 보여준다.
|
||||
각각의 워크로드 종류는 분리하여 볼 수 있다.
|
||||
리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은
|
||||
워크로드에 대한 실용적인 정보를 요약한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -282,8 +282,8 @@ CSR 서명자를 가지고 있는지 문의하는 것을 추천한다.
|
|||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
제 3 자 커스텀 컨트롤러도 사용될 수 있다.
|
||||
- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp)
|
||||
써드파티 커스텀 컨트롤러도 사용될 수 있다.
|
||||
- [kubelet-csr-approver](https://github.com/postfinance/kubelet-csr-approver)
|
||||
|
||||
이러한 컨트롤러는 CSR의 CommonName과 요청된 IPs 및 도메인 네임을
|
||||
모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ weight: 20
|
|||
이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
|
||||
이 페이지 대신 다음의 페이지들을 참고한다.
|
||||
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
|
||||
추상적인 업그레이드 작업 절차는 다음과 같다.
|
||||
|
||||
|
|
@ -37,8 +37,11 @@ weight: 20
|
|||
|
||||
### 추가 정보
|
||||
|
||||
- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이
|
||||
필요하다. 컨트롤 플레인 노드의 경우 CoreDNS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
|
||||
- 아래의 지침은 업그레이드 과정 중 언제 각 노드를 드레인해야 하는지를 제시한다.
|
||||
kubelet에 대해 **마이너** 버전 업그레이드를 하는 경우,
|
||||
먼저 업그레이드할 노드(들)을 드레인**해야 한다**.
|
||||
컨트롤 플레인 노드의 경우, CoreDNS 파드 또는 다른 중요한 워크로드를 실행 중일 수 있다.
|
||||
더 많은 정보는 [노드 드레인하기](/docs/tasks/administer-cluster/safely-drain-node/)를 참조한다.
|
||||
- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
|
||||
|
||||
<!-- steps -->
|
||||
|
|
|
|||
|
|
@ -2,16 +2,20 @@
|
|||
title: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성
|
||||
content_type: task
|
||||
weight: 40
|
||||
description: >-
|
||||
한 네임스페이스 내에서 CPU 리소스 제한의 유효한 범위를 정의하며,
|
||||
이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는
|
||||
방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
|
||||
오브젝트에 CPU의 최솟값과 최댓값을
|
||||
지정한다. 리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면, 네임스페이스에서
|
||||
생성될 수 없다.
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서
|
||||
컨테이너와 파드가 사용하는 CPU 리소스의 최솟값과 최댓값을 설정하는 방법을 보여준다.
|
||||
[리밋레인지(LimitRange)](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) 오브젝트에
|
||||
CPU의 최솟값과 최댓값을 지정한다.
|
||||
리밋레인지에 의해 부과된 제약 조건을 파드가 충족하지 않으면,
|
||||
해당 네임스페이스에 생성될 수 없다.
|
||||
|
||||
|
||||
|
||||
|
|
@ -19,11 +23,13 @@ weight: 40
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
태스크 예제를 실행하려면 클러스터에 적어도 1 CPU 이상이 사용 가능해야 한다.
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
태스크 예제를 실행하려면 클러스터에 적어도 1.0 CPU 이상이 사용 가능해야 한다.
|
||||
쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면
|
||||
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
|
@ -39,7 +45,7 @@ kubectl create namespace constraints-cpu-example
|
|||
|
||||
## 리밋레인지와 파드 생성
|
||||
|
||||
다음은 리밋레인지에 대한 구성 파일이다.
|
||||
다음은 리밋레인지에 대한 예시 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints.yaml" >}}
|
||||
|
||||
|
|
@ -72,15 +78,15 @@ limits:
|
|||
type: Container
|
||||
```
|
||||
|
||||
이제 constraints-cpu-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
|
||||
다음 단계를 수행한다.
|
||||
이제 `constraints-cpu-example` 네임스페이스에 파드를 생성할 때마다(또는
|
||||
다른 쿠버네티스 API 클라이언트가 동일한 파드를 생성할 때마다), 쿠버네티스는 다음 단계를 수행한다.
|
||||
|
||||
* 컨테이너가 자체 CPU 요청량(request)과 상한(limit)을 지정하지 않으면, 컨테이너에
|
||||
CPU 요청량과 상한의 기본값(default)을 지정한다.
|
||||
* 해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
컨트롤 플레인이 해당 컨테이너에 CPU 요청량과 상한의 기본값(default)을 지정한다.
|
||||
|
||||
* 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너가 200 millicpu 이상의 CPU 요청량을 지정하는지 확인한다.
|
||||
|
||||
* 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너가 800 millicpu 이하의 CPU 상한을 지정하는지 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
`LimitRange` 오브젝트를 생성할 때, huge-pages
|
||||
|
|
@ -88,8 +94,8 @@ CPU 요청량과 상한의 기본값(default)을 지정한다.
|
|||
모두 지정되어 있으면, 두 값은 같아야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
|
||||
500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정한다. 이는 리밋레인지에
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너 매니페스트는
|
||||
500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 리밋레인지에
|
||||
의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
|
||||
|
|
@ -100,7 +106,7 @@ CPU 요청량과 상한의 기본값(default)을 지정한다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
파드가 실행 중이고 컨테이너의 상태가 정상인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
|
||||
|
|
@ -112,7 +118,7 @@ kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
|
|||
kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을
|
||||
출력 결과는 파드 내 유일한 컨테이너의 CPU 요청량이 500 millicpu이고, CPU 상한이 800 millicpu임을
|
||||
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 만족시킨다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -131,8 +137,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
|
|||
|
||||
## CPU 최대 제약 조건을 초과하는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
|
||||
500 millicpu의 CPU 요청량과 1.5 cpu의 CPU 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -142,8 +148,8 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 큰 CPU 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
|
||||
표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다.
|
||||
해당 컨테이너가 수용 불가능한 이유는 너무 큰 CPU 상한을 지정하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml":
|
||||
|
|
@ -152,8 +158,8 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
|
|||
|
||||
## 최소 CPU 요청량을 충족하지 않는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
|
||||
100 millicpu의 CPU 요청량과 800 millicpu의 CPU 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -163,8 +169,9 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 작은 CPU 요청량을 지정하므로, 출력 결과에 파드가 생성되지
|
||||
않은 것으로 표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며, 이는 해당 파드가 수용 불가능한 컨테이너를 정의하고 있기 때문이다.
|
||||
해당 컨테이너가 수용 불가능한 이유는
|
||||
지정된 최저 CPU 상한보다도 낮은 CPU 상한을 지정하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml":
|
||||
|
|
@ -173,8 +180,8 @@ pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 2
|
|||
|
||||
## CPU 요청량 또는 상한을 지정하지 않은 파드 생성
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량을 지정하지 않으며, CPU 상한을 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너는
|
||||
CPU 요청량을 지정하지 않았으며, CPU 상한도 지정하지 않았다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}}
|
||||
|
||||
|
|
@ -190,8 +197,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.ya
|
|||
kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 대한 CPU 요청량이 800 millicpu이고, CPU 상한이 800 millicpu임을 나타낸다.
|
||||
컨테이너는 어떻게 이런 값을 얻었을까?
|
||||
출력을 보면 파드의 유일한 컨테이너에 대한 CPU 요청량이 800 millicpu이고,
|
||||
CPU 상한이 800 millicpu이다.
|
||||
이 컨테이너는 어떻게 이런 값을 얻었을까?
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
|
|
@ -201,11 +209,12 @@ resources:
|
|||
cpu: 800m
|
||||
```
|
||||
|
||||
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로, 리밋레인지로부터
|
||||
[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)이
|
||||
주어졌다.
|
||||
컨테이너가 자체 CPU 요청량과 상한을 지정하지 않았으므로,
|
||||
컨테이너가 이 네임스페이스에 대해 리밋레인지로부터
|
||||
[CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을
|
||||
적용했다.
|
||||
|
||||
이 시점에서, 컨테이너는 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
|
||||
이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
|
||||
|
||||
파드를 삭제한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,23 +2,36 @@
|
|||
title: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성
|
||||
content_type: task
|
||||
weight: 20
|
||||
description: >-
|
||||
한 네임스페이스에 CPU 리소스 상한의 기본값을 정의하며,
|
||||
이를 통해 미리 설정한 CPU 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
|
||||
쿠버네티스 클러스터는 네임스페이스로 나눌 수 있다. 기본 CPU 상한이 있는 네임스페이스에서
|
||||
컨테이너가 생성되고, 컨테이너가 자체 CPU 상한을 지정하지 않으면,
|
||||
컨테이너에 기본 CPU 상한이 할당된다. 쿠버네티스는 이 문서의 뒷부분에서
|
||||
설명하는 특정 조건에서 기본 CPU 요청량을 할당한다.
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 대한
|
||||
기본 CPU 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
|
||||
|
||||
쿠버네티스 클러스터를 여러 네임스페이스로 나눌 수 있다.
|
||||
기본 CPU [상한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)이
|
||||
설정되어 있는 네임스페이스에 파드를 생성했는데,
|
||||
해당 파드의 모든 컨테이너에 CPU 상한이 명시되어 있지 않다면,
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
|
||||
해당 컨테이너에 기본 CPU 상한을 할당한다.
|
||||
|
||||
쿠버네티스는 기본 CPU
|
||||
[사용량](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 할당하는데,
|
||||
이는 이 페이지의 이후 부분에서 설명될 특정 조건 하에서만 수행된다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
쿠버네티스에서 “1.0 CPU”가 무엇을 의미하는지 익숙하지 않다면,
|
||||
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -33,8 +46,8 @@ kubectl create namespace default-cpu-example
|
|||
|
||||
## 리밋레인지(LimitRange)와 파드 생성
|
||||
|
||||
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
|
||||
기본 CPU 요청량 및 기본 CPU 상한을 지정한다.
|
||||
다음은 예시 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}}에 대한 매니페스트이다.
|
||||
이 매니페스트는 기본 CPU 요청량 및 기본 CPU 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults.yaml" >}}
|
||||
|
||||
|
|
@ -44,13 +57,13 @@ default-cpu-example 네임스페이스에 리밋레인지를 생성한다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
이제 컨테이너가 default-cpu-example 네임스페이스에 생성되고,
|
||||
컨테이너가 CPU 요청량 및 CPU 상한에 대해 고유한 값을 지정하지 않으면,
|
||||
컨테이너에 CPU 요청량의 기본값 0.5와 CPU 상한
|
||||
기본값 1이 부여된다.
|
||||
이제 파드를 `default-cpu-example` 네임스페이스에 생성하고,
|
||||
해당 파드의 어떤 컨테이너도 자체 CPU 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
컨트롤 플레인이 해당 컨테이너에 CPU 요청량의 기본값(0.5)과
|
||||
상한의 기본값(1)을 지정한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량과 상한을 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 CPU 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}}
|
||||
|
||||
|
|
@ -66,8 +79,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --
|
|||
kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 500 milicpu의 CPU 요청량과
|
||||
1 cpu의 CPU 상한이 있음을 나타낸다. 이것은 리밋레인지에 의해 지정된 기본값이다.
|
||||
출력을 보면 파드 내 유일한 컨테이너의 CPU 요청량이 500m `cpu`("500 밀리cpu"로 읽을 수 있음)이고,
|
||||
CPU 상한이 1 `cpu`임을 알 수 있다.
|
||||
이것은 리밋레인지에 의해 지정된 기본값이다.
|
||||
|
||||
```shell
|
||||
containers:
|
||||
|
|
@ -83,8 +97,8 @@ containers:
|
|||
|
||||
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 상한을 지정하지만, 요청량은 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 CPU 상한은 지정하지만, 요청량은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -95,14 +109,15 @@ CPU 상한을 지정하지만, 요청량은 지정하지 않는다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
파드 사양을 확인한다.
|
||||
생성한 파드의
|
||||
[명세](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)를 확인한다.
|
||||
|
||||
```
|
||||
kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 CPU 요청량이 CPU 상한과 일치하도록 설정되었음을 보여준다.
|
||||
참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 cpu가 할당되지 않았다.
|
||||
참고로 컨테이너에는 CPU 요청량의 기본값인 0.5 `cpu`가 할당되지 않았다.
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -114,8 +129,8 @@ resources:
|
|||
|
||||
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
CPU 요청량을 지정하지만, 상한은 지정하지 않았다.
|
||||
다음은 컨테이너가 하나인 파드의 예시 매니페스트이다.
|
||||
해당 컨테이너는 CPU 요청량은 지정하지만, 상한은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -125,15 +140,16 @@ CPU 요청량을 지정하지만, 상한은 지정하지 않았다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
파드 사양을 확인한다.
|
||||
생성한 파드의 명세를 확인한다.
|
||||
|
||||
```
|
||||
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 CPU 요청량이 컨테이너의 구성 파일에 지정된 값으로
|
||||
설정되었음을 보여준다. 컨테이너의 CPU 상한은 1 cpu로 설정되며, 이는
|
||||
네임스페이스의 CPU 상한 기본값이다.
|
||||
출력을 보면 파드 생성 시 명시한 값대로
|
||||
컨테이너의 CPU 요청량이 설정된 것을 알 수 있다(다시 말해, 매니페스트와 일치한다).
|
||||
그러나, 해당 컨테이너의 CPU 상한은 1 `cpu`로 설정되며,
|
||||
이는 네임스페이스의 CPU 상한 기본값이다.
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -145,15 +161,22 @@ resources:
|
|||
|
||||
## CPU 상한 및 요청량의 기본값에 대한 동기
|
||||
|
||||
네임스페이스에 [리소스 쿼터](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)가 있는 경우,
|
||||
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가
|
||||
설정되어 있는 경우,
|
||||
CPU 상한에 대해 기본값을 설정하는 것이 좋다.
|
||||
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
다음은 CPU 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
|
||||
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 CPU 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 컨테이너가 사용하는 총 CPU 양은 지정된 상한을 초과하지 않아야 한다.
|
||||
* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 CPU 상한이 있어야 한다.
|
||||
* CPU 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다.
|
||||
해당 네임스페이스의 모든 파드에 대해 예약된 CPU 총량이
|
||||
지정된 상한을 초과하지 않아야 한다.
|
||||
|
||||
리밋레인지를 추가할 때에는 다음을 고려해야 한다.
|
||||
|
||||
컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 CPU 상한을 지정하지 않았다면,
|
||||
컨트롤 플레인이 해당 컨테이너에 CPU 상한 기본값을 적용하며,
|
||||
해당 파드는 CPU 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다.
|
||||
|
||||
컨테이너가 자체 CPU 상한을 지정하지 않으면, 상한 기본값이 부여되고, 쿼터에
|
||||
의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
title: 네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성
|
||||
content_type: task
|
||||
weight: 30
|
||||
description: >-
|
||||
한 네임스페이스 내에서 메모리 리소스 제한의 유효한 범위를 정의하며,
|
||||
이를 통해 해당 네임스페이스의 새로운 파드가 미리 설정한 범위 안에 들어오도록 한다.
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -15,16 +18,14 @@ weight: 30
|
|||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 파드가 사용할 수 있는 메모리가 최소 1GiB 이상 있어야 한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -39,7 +40,7 @@ kubectl create namespace constraints-mem-example
|
|||
|
||||
## 리밋레인지와 파드 생성
|
||||
|
||||
다음은 리밋레인지의 구성 파일이다.
|
||||
다음은 리밋레인지의 예시 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
|
||||
|
||||
|
|
@ -72,19 +73,20 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example -
|
|||
type: Container
|
||||
```
|
||||
|
||||
이제 constraints-mem-example 네임스페이스에 컨테이너가 생성될 때마다, 쿠버네티스는
|
||||
다음 단계를 수행한다.
|
||||
이제 `constraints-mem-example` 네임스페이스에 파드를 생성할 때마다,
|
||||
쿠버네티스는 다음 단계를 수행한다.
|
||||
|
||||
* 컨테이너가 자체 메모리 요청량(request)과 상한(limit)을 지정하지 않으면, 기본 메모리 요청량과
|
||||
상한을 컨테이너에 지정한다.
|
||||
* 해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다.
|
||||
|
||||
* 컨테이너에 500MiB 이상의 메모리 요청량이 있는지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너의 메모리 요청량이 최소 500 MiB 이상인지 확인한다.
|
||||
|
||||
* 컨테이너의 메모리 상한이 1GiB 이하인지 확인한다.
|
||||
* 해당 파드의 모든 컨테이너의 메모리 요청량이 1024 MiB(1 GiB)를 넘지 않는지
|
||||
확인한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너 매니페스트는
|
||||
600MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다. 이들은
|
||||
리밋레인지에 의해 부과된 메모리의 최소 및 최대 제약 조건을 충족한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
파드 명세 내에, 파드의 유일한 컨테이너는 600 MiB의 메모리 요청량 및 800 MiB의 메모리 상한을 지정하고 있다.
|
||||
이는 리밋레인지에 의해 부과된 최소 및 최대 메모리 제약 조건을 충족시킨다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
|
||||
|
||||
|
|
@ -94,7 +96,7 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example -
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
파드가 실행 중이고 컨테이너의 상태가 정상인지 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
||||
|
|
@ -106,8 +108,9 @@ kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 600MiB이고 메모리 상한이 800MiB임을
|
||||
나타낸다. 이는 리밋레인지에 의해 부과된 제약 조건을 충족한다.
|
||||
출력을 보면 파드의 컨테이너의 메모리 요청량이 600 MiB이고 메모리 상한이 800 MiB임을 알 수 있다.
|
||||
이는 리밋레인지에 의해 해당 네임스페이스에 부과된 제약 조건을
|
||||
만족시킨다.
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
|
|
@ -125,8 +128,8 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
|
||||
## 최대 메모리 제약 조건을 초과하는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
800MiB의 메모리 요청량과 1.5GiB의 메모리 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
컨테이너는 800MiB의 메모리 요청량과 1.5GiB의 메모리 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -136,8 +139,8 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 큰 메모리 상한을 지정하므로, 출력 결과에 파드가 생성되지 않은 것으로
|
||||
표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며,
|
||||
이는 해당 파드가 정의하고 있는 컨테이너가 허용된 것보다 더 많은 메모리를 요청하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml":
|
||||
|
|
@ -146,8 +149,8 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
|
|||
|
||||
## 최소 메모리 요청량을 충족하지 않는 파드 생성 시도
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정한다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
컨테이너는 100MiB의 메모리 요청량과 800MiB의 메모리 상한을 지정하고 있다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -157,8 +160,8 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
컨테이너가 너무 작은 메모리 요청량을 지정하므로, 출력 결과에 파드가 생성되지
|
||||
않은 것으로 표시된다.
|
||||
결과를 보면 파드가 생성되지 않은 것을 확인할 수 있으며,
|
||||
이는 해당 파드가 정의하고 있는 컨테이너가 지정된 최저 메모리 요청량보다도 낮은 메모리 요청량을 지정하고 있기 때문이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml":
|
||||
|
|
@ -167,10 +170,8 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
|
|||
|
||||
## 메모리 요청량 또는 상한을 지정하지 않은 파드 생성
|
||||
|
||||
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지 않으며, 메모리 상한을 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}}
|
||||
|
||||
|
|
@ -182,12 +183,12 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4
|
|||
|
||||
파드에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 파드의 컨테이너에 1GiB의 메모리 요청량과 1GiB의 메모리 상한이 있음을 보여준다.
|
||||
컨테이너는 이러한 값을 어떻게 얻었을까?
|
||||
출력을 보면 파드의 유일한 컨테이너에 대한 메모리 요청량이 1 GiB이고 메모리 상한도 1 GiB이다.
|
||||
이 컨테이너는 어떻게 이런 값을 얻었을까?
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -197,11 +198,20 @@ resources:
|
|||
memory: 1Gi
|
||||
```
|
||||
|
||||
컨테이너가 자체 메모리 요청량과 상한을 지정하지 않았으므로,
|
||||
리밋레인지의 [메모리의 요청량과 상한 기본값](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)이
|
||||
제공되었다.
|
||||
파드가 해당 컨테이너에 대해 메모리 요청량과 상한을 지정하지 않았으므로,
|
||||
클러스터가 리밋레인지로부터
|
||||
[메모리의 요청량과 상한 기본값](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을
|
||||
적용하였다.
|
||||
|
||||
이 시점에서, 컨테이너가 실행 중이거나 실행 중이 아닐 수 있다. 이 태스크의 전제 조건은
|
||||
이는 곧 파드 정의에서 이 값들을 볼 수 있음을 의미한다.
|
||||
`kubectl describe` 명령을 사용하여 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
# 출력에서 "Requests:" 섹션을 확인한다
|
||||
kubectl describe pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은
|
||||
노드에 최소 1GiB의 메모리가 있어야 한다는 것이다. 각 노드에
|
||||
1GiB의 메모리만 있는 경우, 노드에 할당할 수 있는 메모리가 1GiB의 메모리 요청량을 수용하기에 충분하지
|
||||
않을 수 있다. 메모리가 2GiB인 노드를 사용하는 경우에는, 메모리가
|
||||
|
|
@ -209,7 +219,7 @@ resources:
|
|||
|
||||
파드를 삭제한다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
||||
```
|
||||
|
||||
|
|
@ -224,12 +234,12 @@ kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example
|
|||
클러스터 관리자는 파드가 사용할 수 있는 메모리 양에 제한을 둘 수 있다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
* 클러스터의 각 노드에는 2GB의 메모리가 있다. 클러스터의 어떤 노드도 2GB 이상의 요청량을
|
||||
지원할 수 없으므로, 2GB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
|
||||
* 클러스터의 각 노드에는 2GiB의 메모리가 있다. 클러스터의 어떤 노드도 2GiB 이상의 요청량을
|
||||
지원할 수 없으므로, 2GiB 이상의 메모리를 요청하는 파드를 수락하지 않으려고 한다.
|
||||
|
||||
* 클러스터는 운영 부서와 개발 부서에서 공유한다.
|
||||
프로덕션 워크로드가 최대 8GB의 메모리를 소비하도록 하려면,
|
||||
개발 워크로드를 512MB로 제한해야 한다. 프로덕션 및 개발을 위해
|
||||
프로덕션 워크로드가 최대 8GiB의 메모리를 소비하도록 하려면,
|
||||
개발 워크로드를 512MiB로 제한해야 한다. 프로덕션 및 개발을 위해
|
||||
별도의 네임스페이스를 만들고, 각 네임스페이스에 메모리 제약 조건을 적용한다.
|
||||
|
||||
## 정리
|
||||
|
|
|
|||
|
|
@ -2,21 +2,35 @@
|
|||
title: 네임스페이스에 대한 기본 메모리 요청량과 상한 구성
|
||||
content_type: task
|
||||
weight: 10
|
||||
description: >-
|
||||
한 네임스페이스에 메모리 리소스 상한의 기본값을 정의하며,
|
||||
이를 통해 미리 설정한 메모리 리소스 상한이 해당 네임스페이스의 새로운 파드에 설정되도록 한다.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에 대한 기본 메모리 요청량(request)과 상한(limit)을 구성하는 방법을 보여준다.
|
||||
기본 메모리 상한이 있는 네임스페이스에서 컨테이너가 생성되고, 컨테이너가
|
||||
자체 메모리 상한을 지정하지 않으면, 컨테이너에 기본 메모리 상한이 할당된다.
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 대한
|
||||
기본 메모리 요청량(request) 및 상한(limit)을 구성하는 방법을 보여준다.
|
||||
|
||||
쿠버네티스 클러스터를 여러 네임스페이스로 나눌 수 있다.
|
||||
기본 메모리 [상한](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)이
|
||||
설정되어 있는 네임스페이스에 파드를 생성했는데,
|
||||
해당 파드의 모든 컨테이너에 메모리 상한이 명시되어 있지 않다면,
|
||||
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이
|
||||
해당 컨테이너에
|
||||
기본 메모리 상한을 할당한다.
|
||||
|
||||
쿠버네티스는 이 문서의 뒷부분에서 설명하는 특정 조건에서 기본 메모리 요청량을 할당한다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 최소 2GiB의 메모리가 있어야 한다.
|
||||
|
||||
|
|
@ -35,8 +49,9 @@ kubectl create namespace default-mem-example
|
|||
|
||||
## 리밋레인지(LimitRange)와 파드 생성
|
||||
|
||||
다음은 리밋레인지 오브젝트의 구성 파일이다. 구성은
|
||||
메모리 요청량 기본값(default)과 메모리 상한 기본값을 지정한다.
|
||||
다음은 예시 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}}에 대한 매니페스트이다.
|
||||
이 매니페스트는 기본 메모리 요청량 및
|
||||
기본 메모리 상한을 지정한다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults.yaml" >}}
|
||||
|
||||
|
|
@ -46,13 +61,14 @@ default-mem-example 네임스페이스에 리밋레인지를 생성한다.
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
이제 컨테이너가 default-mem-example 네임스페이스에 생성되고,
|
||||
컨테이너가 메모리 요청량 및 메모리 상한에 대해 고유한 값을 지정하지 않으면,
|
||||
컨테이너에 메모리 요청량 기본값 256MiB와 메모리 상한 기본값
|
||||
512MiB가 지정된다.
|
||||
이제 파드를 `default-mem-example` 네임스페이스에 생성하고,
|
||||
해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면,
|
||||
컨트롤 플레인이 해당 컨테이너에 메모리 요청량의 기본값(256 MiB)과
|
||||
상한의 기본값(512 MiB)을 지정한다.
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량 및 상한을 지정하지 않는다.
|
||||
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량과 상한을 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
|
||||
|
||||
|
|
@ -91,8 +107,8 @@ kubectl delete pod default-mem-demo --namespace=default-mem-example
|
|||
|
||||
## 컨테이너 상한은 지정하고, 요청량을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 상한을 지정하지만, 요청량은 지정하지 않는다.
|
||||
다음은 컨테이너가 하나인 파드의 매니페스트이다.
|
||||
해당 컨테이너는 메모리 상한은 지정하지만, 요청량은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}}
|
||||
|
||||
|
|
@ -122,8 +138,8 @@ resources:
|
|||
|
||||
## 컨테이너의 요청량은 지정하고, 상한을 지정하지 않으면 어떻게 되나?
|
||||
|
||||
컨테이너가 하나인 파드의 구성 파일은 다음과 같다. 컨테이너는
|
||||
메모리 요청량을 지정하지만, 상한은 지정하지 않았다.
|
||||
다음은 컨테이너가 하나인 파드의 예시 매니페스트이다.
|
||||
해당 컨테이너는 메모리 요청량은 지정하지만, 상한은 지정하지 않는다.
|
||||
|
||||
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
|
||||
|
||||
|
|
@ -139,9 +155,9 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.ya
|
|||
kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example
|
||||
```
|
||||
|
||||
출력 결과는 컨테이너의 메모리 요청량이 컨테이너의 구성 파일에 지정된 값으로
|
||||
설정되었음을 보여준다. 컨테이너의 메모리 상한은 네임스페이스의
|
||||
기본 메모리 상한인 512Mi로 설정되어 있다.
|
||||
출력을 보면 컨테이너의 매니페스트에 명시한 값대로 컨테이너의 메모리 요청량이 설정된 것을 알 수 있다.
|
||||
해당 컨테이너의 메모리 상한은 512 MiB로 설정되며,
|
||||
이는 네임스페이스의 메모리 상한 기본값과 일치한다.
|
||||
|
||||
```
|
||||
resources:
|
||||
|
|
@ -153,15 +169,23 @@ resources:
|
|||
|
||||
## 기본 메모리 상한 및 요청량에 대한 동기
|
||||
|
||||
네임스페이스에 리소스 쿼터가 있는 경우,
|
||||
네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가
|
||||
설정되어 있는 경우,
|
||||
메모리 상한에 기본값을 설정하는 것이 좋다.
|
||||
다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
|
||||
|
||||
* 네임스페이스에서 실행되는 모든 컨테이너에는 자체 메모리 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 컨테이너가 사용하는 총 메모리 양은 지정된 상한을 초과하지 않아야 한다.
|
||||
* 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 메모리 상한이 있어야 한다.
|
||||
(파드의 모든 컨테이너에 대해 메모리 상한을 지정하면,
|
||||
쿠버네티스가 파드 내의 컨테이너의 상한을 합산하여 파드-수준 메모리 상한을 추론할 수 있다.)
|
||||
* 메모리 상한은 해당 파드가 스케줄링될 노드에 리소스 예약을 적용한다.
|
||||
해당 네임스페이스의 모든 파드에 대해 예약된 메모리 총량이 지정된 상한을 초과하지 않아야 한다.
|
||||
* 해당 네임스페이스의 모든 파드가 실제로 사용하고 있는 메모리의 총량 또한 지정된 상한을 초과하지 않아야 한다.
|
||||
|
||||
컨테이너가 자체 메모리 상한을 지정하지 않으면, 기본 상한이 부여되고,
|
||||
쿼터에 의해 제한되는 네임스페이스에서 실행될 수 있다.
|
||||
리밋레인지를 추가할 때에는 다음을 고려해야 한다.
|
||||
|
||||
컨테이너를 갖고 있는 해당 네임스페이스의 파드가 자체 메모리 상한을 지정하지 않았다면,
|
||||
컨트롤 플레인이 해당 컨테이너에 메모리 상한 기본값을 적용하며,
|
||||
해당 파드는 메모리 리소스쿼터가 적용된 네임스페이스에서 실행되도록 허용될 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
|
|
@ -2,29 +2,31 @@
|
|||
title: 네임스페이스에 대한 메모리 및 CPU 쿼터 구성
|
||||
content_type: task
|
||||
weight: 50
|
||||
description: >-
|
||||
한 네임스페이스에 대한 총 메모리 및 CPU 자원 상한을 정의한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 실행 중인 모든 컨테이너가 사용할 수 있는
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서
|
||||
실행 중인 모든 파드가 사용할 수 있는
|
||||
총 메모리 및 CPU 양에 대한 쿼터를 설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) 오브젝트에
|
||||
쿼터를 지정할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
클러스터의 각 노드에는 최소 1GiB의 메모리가 있어야 한다.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 네임스페이스 생성
|
||||
|
|
@ -38,7 +40,7 @@ kubectl create namespace quota-mem-cpu-example
|
|||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
다음은 예시 리소스쿼터 오브젝트에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu.yaml" >}}
|
||||
|
||||
|
|
@ -56,15 +58,18 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu
|
|||
|
||||
리소스쿼터는 이러한 요구 사항을 quota-mem-cpu-example 네임스페이스에 배치한다.
|
||||
|
||||
* 모든 컨테이너에는 메모리 요청량(request), 메모리 상한(limit), CPU 요청량 및 CPU 상한이 있어야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 요청량은 1GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 메모리 상한은 2GiB를 초과하지 않아야 한다.
|
||||
* 모든 컨테이너에 대한 총 CPU 요청량은 1 cpu를 초과해서는 안된다.
|
||||
* 모든 컨테이너에 대한 총 CPU 상한은 2 cpu를 초과해서는 안된다.
|
||||
* 네임스페이스의 모든 파드에 대해, 각 컨테이너에는 메모리 요청량(request), 메모리 상한(limit), CPU 요청량 및 CPU 상한이 있어야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 메모리 요청량은 1GiB를 초과하지 않아야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 메모리 상한은 2GiB를 초과하지 않아야 한다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 CPU 요청량은 1 cpu를 초과해서는 안된다.
|
||||
* 네임스페이스의 모든 파드에 대한 총 CPU 상한은 2 cpu를 초과해서는 안된다.
|
||||
|
||||
쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면
|
||||
[CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
|
||||
|
||||
## 파드 생성
|
||||
|
||||
파드의 구성 파일은 다음과 같다.
|
||||
다음은 예시 파드에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}}
|
||||
|
||||
|
|
@ -75,15 +80,15 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu
|
|||
kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
파드의 컨테이너가 실행 중인지 확인한다.
|
||||
파드가 실행 중이고 파드의 (유일한) 컨테이너의 상태가 정상인지 확인한다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
|
||||
```
|
||||
|
||||
다시 한 번, 리소스쿼터에 대한 자세한 정보를 본다.
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml
|
||||
```
|
||||
|
||||
|
|
@ -105,15 +110,22 @@ status:
|
|||
requests.memory: 600Mi
|
||||
```
|
||||
|
||||
`jq` 도구가 설치되어 있으면, ([JSONPath](/ko/docs/reference/kubectl/jsonpath/)를 사용하여) `used` 값만을 질의 **하고**,
|
||||
정돈된 상태로 출력할 수 있다. 예시는 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example -o jsonpath='{ .status.used }' | jq .
|
||||
```
|
||||
|
||||
## 두 번째 파드 생성 시도
|
||||
|
||||
다음은 두 번째 파드의 구성 파일이다.
|
||||
다음은 두 번째 파드에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-mem-cpu-pod-2.yaml" >}}
|
||||
|
||||
구성 파일에서, 파드의 메모리 요청량이 700MiB임을 알 수 있다.
|
||||
매니페스트에서, 파드의 메모리 요청량이 700MiB임을 알 수 있다.
|
||||
사용된 메모리 요청량과 이 새 메모리 요청량의 합계가
|
||||
메모리 요청량 쿼터를 초과한다. 600MiB + 700MiB > 1GiB
|
||||
메모리 요청량 쿼터를 초과함에 유의한다(600 MiB + 700 MiB > 1 GiB).
|
||||
|
||||
파드 생성을 시도한다.
|
||||
|
||||
|
|
@ -133,11 +145,12 @@ requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.
|
|||
## 토론
|
||||
|
||||
이 연습에서 보았듯이, 리소스쿼터를 사용하여
|
||||
네임스페이스에서 실행 중인 모든 컨테이너에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
|
||||
네임스페이스에서 실행 중인 모든 파드에 대한 메모리 요청량의 총 합계를 제한할 수 있다.
|
||||
메모리 상한, CPU 요청량 및 CPU 상한의 총 합계를 제한할 수도 있다.
|
||||
|
||||
모든 컨테이너에 대한 합계 대신 개별 컨테이너를 제한하려면,
|
||||
[리밋레인지(LimitRange)](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)를 사용한다.
|
||||
네임스페이스 내의 총 자원을 관리하는 것 대신,
|
||||
개별 파드 또는 파드 내의 컨테이너별로 제한하고 싶을 수도 있다.
|
||||
이러한 종류의 제한을 걸려면, [리밋레인지(LimitRange)](/ko/docs/concepts/policy/limit-range/)를 사용한다.
|
||||
|
||||
## 정리
|
||||
|
||||
|
|
|
|||
|
|
@ -2,15 +2,17 @@
|
|||
title: 네임스페이스에 대한 파드 쿼터 구성
|
||||
content_type: task
|
||||
weight: 60
|
||||
description: >-
|
||||
한 네임스페이스 내에 만들 수 있는 파드의 수를 제한한다.
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
이 페이지는 네임스페이스에서 실행할 수 있는 총 파드 수에 대한 쿼터를
|
||||
이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서 실행할 수 있는 총 파드 수에 대한 쿼터를
|
||||
설정하는 방법을 보여준다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
|
||||
오브젝트에 쿼터를 지정한다.
|
||||
[리소스쿼터(ResourceQuota)](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) 오브젝트에
|
||||
쿼터를 지정할 수 있다.
|
||||
|
||||
|
||||
|
||||
|
|
@ -18,10 +20,9 @@ weight: 60
|
|||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -36,7 +37,7 @@ kubectl create namespace quota-pod-example
|
|||
|
||||
## 리소스쿼터 생성
|
||||
|
||||
다음은 리소스쿼터 오브젝트의 구성 파일이다.
|
||||
다음은 예시 리소스쿼터 오브젝트에 대한 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod.yaml" >}}
|
||||
|
||||
|
|
@ -66,11 +67,12 @@ status:
|
|||
pods: "0"
|
||||
```
|
||||
|
||||
다음은 디플로이먼트(Deployment) 구성 파일이다.
|
||||
다음은 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}에 대한 예시 매니페스트이다.
|
||||
|
||||
{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}}
|
||||
|
||||
구성 파일에서, `replicas: 3` 은 쿠버네티스가 모두 동일한 애플리케이션을 실행하는 세 개의 파드를 만들도록 지시한다.
|
||||
매니페스트에서, `replicas: 3` 은 쿠버네티스가 모두 동일한 애플리케이션을 실행하는
|
||||
세 개의 새로운 파드를 만들도록 지시한다.
|
||||
|
||||
디플로이먼트를 생성한다.
|
||||
|
||||
|
|
@ -84,8 +86,8 @@ kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yam
|
|||
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
출력 결과는 디플로이먼트에서 3개의 레플리카를 지정하더라도, 쿼터로
|
||||
인해 2개의 파드만 생성되었음을 보여준다.
|
||||
출력을 보면 디플로이먼트가 3개의 레플리카를 정의하고 있음에도,
|
||||
앞서 설정한 쿼터로 인해 2개의 파드만 생성되었음을 보여준다.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
|
|
@ -95,11 +97,18 @@ spec:
|
|||
status:
|
||||
availableReplicas: 2
|
||||
...
|
||||
lastUpdateTime: 2017-07-07T20:57:05Z
|
||||
lastUpdateTime: 2021-04-02T20:57:05Z
|
||||
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
|
||||
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
|
||||
```
|
||||
|
||||
### 리소스 선택
|
||||
|
||||
이 예제에서는 총 파드 수를 제한하는 리소스쿼터를 정의하였다.
|
||||
하지만, 다른 종류의 오브젝트의 총 수를 제한할 수도 있다.
|
||||
예를 들어, 한 네임스페이스에 존재할 수 있는
|
||||
{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}의 총 수를 제한할 수 있다.
|
||||
|
||||
## 정리
|
||||
|
||||
네임스페이스를 삭제한다.
|
||||
|
|
|
|||
|
|
@ -174,7 +174,7 @@ kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
|
|||
```shell
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
exitCode: 137
|
||||
finishedAt: 2017-06-20T20:52:19Z
|
||||
reason: OOMKilled
|
||||
|
|
|
|||
|
|
@ -10,20 +10,19 @@ weight: 20
|
|||
|
||||
이 페이지는 윈도우 노드에서 실행되는 파드와 컨테이너용으로 [그룹 관리 서비스 어카운트(Group Managed Service Accounts,](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) GMSA)를 구성하는 방법을 소개한다. 그룹 관리 서비스 어카운트는 자동 암호 관리, 단순화된 서비스 사용자 이름(service principal name, SPN) 관리, 여러 서버에 걸쳐 다른 관리자에게 관리를 위임하는 기능을 제공하는 특정한 유형의 액티브 디렉터리(Active Directory) 계정이다.
|
||||
|
||||
쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다. v1.16부터 도커 런타임은 윈도우 워크로드용 GMSA를 지원한다.
|
||||
|
||||
|
||||
쿠버네티스에서 GMSA 자격 증명 사양은 쿠버네티스 클러스터 전체 범위에서 사용자 정의 리소스(Custom Resources)로 구성된다. 윈도우 파드 및 파드 내의 개별 컨테이너들은 다른 윈도우 서비스와 상호 작용할 때 도메인 기반 기능(예: Kerberos 인증)에 GMSA를 사용하도록 구성할 수 있다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 `kubectl` 커맨드라인 툴을 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 한다. 이 섹션에서는 각 클러스터에 대해 한 번씩 필요한 일련의 초기 단계를 다룬다.
|
||||
|
||||
|
||||
### GMSACredentialSpec CRD 설치
|
||||
|
||||
GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(CustomResourceDefinition,](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) CRD)을 클러스터에서 구성하여 사용자 정의 리소스 유형 `GMSACredentialSpec`을 정의해야 한다. GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)을 다운로드하고 gmsa-crd.yaml로 저장한다.
|
||||
다음, `kubectl apply -f gmsa-crd.yaml` 로 CRD를 설치한다.
|
||||
|
||||
### GMSA 사용자를 검증하기 위해 웹훅 설치
|
||||
|
||||
쿠버네티스 클러스터에서 두 개의 웹훅을 구성하여 파드 또는 컨테이너 수준에서 GMSA 자격 증명 사양 참조를 채우고 검증한다.
|
||||
|
||||
1. 변형(mutating) 웹훅은 (파드 사양의 이름별로) GMSA에 대한 참조를 파드 사양 내 JSON 형식의 전체 자격 증명 사양으로 확장한다.
|
||||
|
|
@ -44,14 +43,14 @@ GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(Cu
|
|||
|
||||
스크립트에서 사용하는 [YAML 템플릿](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl)을 사용하여 웹훅 및 (파라미터를 적절히 대체하여) 관련 오브젝트를 수동으로 배포할 수도 있다.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## 액티브 디렉터리에서 GMSA 및 윈도우 노드 구성
|
||||
|
||||
쿠버네티스의 파드가 GMSA를 사용하도록 구성되기 전에 [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)에 설명된 대로 액티브 디렉터리에서 원하는 GMSA를 프로비저닝해야 한다. [윈도우 GMSA 문서](https://docs.microsoft.com/ko-kr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)에 설명된 대로 원하는 GMSA와 연결된 시크릿 자격 증명에 접근하려면 (쿠버네티스 클러스터의 일부인) 윈도우 워커 노드를 액티브 디렉터리에서 구성해야 한다.
|
||||
|
||||
## GMSA 자격 증명 사양 리소스 생성
|
||||
|
||||
(앞에서 설명한 대로) GMSACredentialSpec CRD를 설치하면 GMSA 자격 증명 사양이 포함된 사용자 정의 리소스를 구성할 수 있다. GMSA 자격 증명 사양에는 시크릿 또는 민감한 데이터가 포함되어 있지 않다. 이것은 컨테이너 런타임이 원하는 윈도우 컨테이너 GMSA를 설명하는 데 사용할 수 있는 정보이다. GMSA 자격 증명 사양은 [PowerShell 스크립트](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 유틸리티를 사용하여 YAML 형식으로 생성할 수 있다.
|
||||
|
||||
다음은 JSON 형식으로 GMSA 자격 증명 사양 YAML을 수동으로 생성한 다음 변환하는 단계이다.
|
||||
|
|
@ -67,7 +66,7 @@ GMSA 자격 증명 사양 리소스에 대한 [커스텀리소스데피니션(Cu
|
|||
다음 YAML 구성은 `gmsa-WebApp1`이라는 GMSA 자격 증명 사양을 설명한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: windows.k8s.io/v1alpha1
|
||||
apiVersion: windows.k8s.io/v1
|
||||
kind: GMSACredentialSpec
|
||||
metadata:
|
||||
name: gmsa-WebApp1 #임의의 이름이지만 참조로 사용된다.
|
||||
|
|
@ -92,6 +91,7 @@ credspec:
|
|||
위의 자격 증명 사양 리소스는 `gmsa-Webapp1-credspec.yaml`로 저장되고 `kubectl apply -f gmsa-Webapp1-credspec.yml`을 사용하여 클러스터에 적용될 수 있다.
|
||||
|
||||
## 특정 GMSA 자격 증명 사양에서 RBAC를 활성화하도록 cluster role 구성
|
||||
|
||||
각 GMSA 자격 증명 사양 리소스에 대해 cluster role을 정의해야 한다. 이것은 일반적으로 서비스 어카운트인 주체에 의해 특정 GMSA 리소스에 대한 `use` 동사를 승인한다. 다음 예는 위에서 `gmsa-WebApp1` 자격 증명 사양의 사용을 승인하는 클러스터 롤(cluster role)을 보여준다. 파일을 gmsa-webapp1-role.yaml로 저장하고 `kubectl apply -f gmsa-webapp1-role.yaml`을 사용하여 적용한다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -108,6 +108,7 @@ rules:
|
|||
```
|
||||
|
||||
## 특정 GMSA credspecs를 사용하도록 서비스 어카운트에 롤 할당
|
||||
|
||||
(파드가 사용하게 되는) 서비스 어카운트는 위에서 생성한 클러스터 롤에 바인딩되어야 한다. 이렇게 하면 서비스 어카운트가 원하는 GMSA 자격 증명 사양 리소스를 사용할 수 있다. 다음은 위에서 생성한 `gmsa-WebApp1` 자격 증명 사양 리소스를 사용하기 위해 `webapp1-role` 클러스터 롤에 바인딩되는 기본(default) 서비스 어카운트이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -127,6 +128,7 @@ roleRef:
|
|||
```
|
||||
|
||||
## 파드 사양에서 GMSA 자격 증명 사양 참조 구성
|
||||
|
||||
파드 사양 필드 `securityContext.windowsOptions.gmsaCredentialSpecName`은 파드 사양에서 원하는 GMSA 자격 증명 사양 사용자 정의 리소스에 대한 참조를 지정하는 데 사용된다. 이렇게 하면 지정된 GMSA를 사용하도록 파드 사양의 모든 컨테이너가 구성된다. 다음은 `gmsa-WebApp1`을 참조하도록 채워진 어노테이션이 있는 샘플 파드 사양이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -197,55 +199,17 @@ spec:
|
|||
|
||||
1. 컨테이너 런타임은 컨테이너가 액티브 디렉터리에서 GMSA의 ID를 가정하고 해당 ID를 사용하여 도메인의 서비스에 접근할 수 있도록 지정된 GMSA 자격 증명 사양으로 각 윈도우 컨테이너를 구성한다.
|
||||
|
||||
## Containerd
|
||||
## 호스트네임 또는 FQDN을 사용하는 경우에 네트워크 공유에 인증하기
|
||||
|
||||
윈도우 서버 2019에서 containerd와 함께 GMSA를 사용하려면 패치 [KB5000822](https://support.microsoft.com/ko-kr/topic/2021년-3월-9일-kb5000822-os-빌드-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564)된 OS Build 17763.1817 (또는 이후 버전)을 실행해야 한다.
|
||||
파드에서 호스트네임 또는 FQDN을 사용하여 SMB 공유에 연결할 때 문제를 겪고 있으나, IPv4 주소로는 해당 공유에 접속이 가능한 상황이라면, 윈도우 노드에 다음 레지스트리 키를 등록했는지 확인한다.
|
||||
|
||||
또한 파드에서 SMB 공유에 연결하려고 할 때 발생하는 containerd와 관련된 알려진 문제가 있다. GMSA를 구성하면 파드가 hostname 또는 FQDN을 사용하여 공유에 연결할 수 없지만, IP 주소를 사용하여 공유에 연결하면 예상대로 작동한다.
|
||||
|
||||
```PowerShell
|
||||
ping adserver.ad.local
|
||||
```
|
||||
hostname을 IPv4 주소로 올바르게 변환한다. 출력은 다음과 유사하다.
|
||||
|
||||
```
|
||||
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
|
||||
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
|
||||
```cmd
|
||||
reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1
|
||||
```
|
||||
|
||||
그러나 hostname을 사용하여 디렉터리를 탐색하려고 할 때
|
||||
|
||||
```PowerShell
|
||||
cd \\adserver.ad.local\test
|
||||
```
|
||||
|
||||
대상 공유가 존재하지 않음을 암시하는 오류가 표시된다.
|
||||
|
||||
```
|
||||
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
|
||||
At line:1 char:1
|
||||
+ cd \\adserver.ad.local\test
|
||||
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
|
||||
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
|
||||
```
|
||||
|
||||
그러나 IPv4 주소를 대신 사용하여 공유를 탐색하면 오류가 사라진다. 다음은 예시이다.
|
||||
|
||||
```PowerShell
|
||||
cd \\192.168.111.18\test
|
||||
```
|
||||
|
||||
공유 내의 디렉터리로 변경하면 다음과 유사한 프롬프트가 표시된다.
|
||||
|
||||
```
|
||||
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
|
||||
```
|
||||
|
||||
동작을 수정하려면 노드에서 `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1`을 실행하여 필요한 레지스트리 키를 추가해야 한다. 이 노드 변경 사항은 새로 생성된 파드에만 적용되는데, SMB 공유에 액세스해야 하는 실행 중인 파드를 다시 생성해야 하는 것을 의미한다.
|
||||
그런 다음 동작 변경 사항을 적용하려면 실행 중인 파드를 다시 생성해야 한다.
|
||||
이 레지스트리 키가 어떻게 사용되는지에 대한 자세한 정보는
|
||||
[여기](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)에서 볼 수 있다.
|
||||
|
||||
## 문제 해결
|
||||
|
||||
|
|
@ -258,7 +222,9 @@ GMSA가 사용자 환경에서 작동하도록 하는 데 어려움이 있는
|
|||
```PowerShell
|
||||
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
|
||||
```
|
||||
|
||||
`nltest.exe /parentdomain` 는 다음과 같은 오류를 발생시킨다.
|
||||
|
||||
```
|
||||
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
||||
```
|
||||
|
|
|
|||
|
|
@ -7,8 +7,10 @@ weight: 100
|
|||
<!-- overview -->
|
||||
|
||||
이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해
|
||||
{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을
|
||||
사용하는 파드를 생성하는 방법을 보여준다.
|
||||
{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는
|
||||
파드를 생성하는 방법을 보여준다.
|
||||
현재 많은 곳에서 프라이빗 레지스트리가 사용되고 있다.
|
||||
여기서는 예시 레지스트리로 [Docker Hub](https://www.docker.com/products/docker-hub)을 사용한다.
|
||||
|
||||
{{% thirdparty-content single="true" %}}
|
||||
|
||||
|
|
@ -17,7 +19,9 @@ weight: 100
|
|||
* {{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
* 이 실습을 수행하기 위해, `docker` 명령줄 도구와
|
||||
[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.
|
||||
[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다.
|
||||
* 다른 프라이빗 컨테이너 레지스트리를 사용하는 경우,
|
||||
해당 레지스트리를 위한 명령줄 도구 및 레지스트리 로그인 정보가 필요하다.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -59,12 +63,13 @@ cat ~/.docker/config.json
|
|||
도커 자격 증명 저장소를 사용하는 경우, `auth` 항목이 아닌, 저장소의 이름을 값으로 사용하는 `credsStore` 항목을 확인할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 기존의 도커 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials}
|
||||
## 기존의 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials}
|
||||
|
||||
쿠버네티스 클러스터는 프라이빗 이미지를 받아올 때, 컨테이너 레지스트리에 인증하기 위하여
|
||||
`kubernetes.io/dockerconfigjson` 타입의 시크릿을 사용한다.
|
||||
|
||||
만약 이미 `docker login` 을 수행하였다면, 이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
|
||||
만약 이미 `docker login` 을 수행하였다면,
|
||||
이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic regcred \
|
||||
|
|
@ -77,7 +82,7 @@ kubectl create secret generic regcred \
|
|||
다음을 확인하자.
|
||||
|
||||
- 데이터 항목의 이름을 `.dockerconfigjson` 으로 설정한다
|
||||
- 도커 파일을 base64로 인코딩하고 그 문자열을 `data[".dockerconfigjson"]`
|
||||
- 도커 구성 파일을 base64로 인코딩하고 그 문자열을 `data[".dockerconfigjson"]`
|
||||
필드에 자르지 않고 한 줄로 이어서 붙여넣는다
|
||||
- `type` 을 `kubernetes.io/dockerconfigjson` 으로 설정한다
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ API 서버에서 제어될 수는 없다.
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
|
||||
이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="cri-o" >}}를 사용하며,
|
||||
노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
|
||||
다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.
|
||||
|
||||
|
|
@ -156,15 +156,20 @@ Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시
|
|||
(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다.
|
||||
```shell
|
||||
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
|
||||
결과는 다음과 유사하다.
|
||||
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`crictl`은 이미지 URI와 SHA-256 체크섬을 출력한다. `NAME`은 다음과 같을 것이다.
|
||||
`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`
|
||||
{{< /note >}}
|
||||
|
||||
API 서버에서 미러 파드를 볼 수 있다.
|
||||
|
||||
|
|
@ -172,8 +177,8 @@ API 서버에서 미러 파드를 볼 수 있다.
|
|||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -181,7 +186,6 @@ Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있
|
|||
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은
|
||||
미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을
|
||||
통하여 이러한 레이블을 사용할 수 있다.
|
||||
|
|
@ -190,34 +194,33 @@ Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있
|
|||
kubelet 은 스태틱 파드를 지우지 _않는다._
|
||||
|
||||
```shell
|
||||
kubectl delete pod static-web-my-node1
|
||||
kubectl delete pod static-web
|
||||
```
|
||||
```
|
||||
pod "static-web-my-node1" deleted
|
||||
pod "static-web" deleted
|
||||
```
|
||||
파드가 여전히 구동 중인 것을 볼 수 있다.
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web 1/1 Running 0 4s
|
||||
```
|
||||
|
||||
kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
|
||||
중지할 수 있다.
|
||||
kubelet 이 구동 중인 노드로 돌아가서 컨테이너를 수동으로 중지할 수 있다.
|
||||
일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
|
||||
것을 볼 수 있다.
|
||||
|
||||
```shell
|
||||
# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
|
||||
docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
|
||||
crictl stop 129fd7d382018 # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다.
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
|
||||
```
|
||||
|
||||
## 스태틱 파드의 동적 추가 및 제거
|
||||
|
|
@ -230,13 +233,13 @@ CONTAINER ID IMAGE COMMAND CREATED ...
|
|||
#
|
||||
mv /etc/kubelet.d/static-web.yaml /tmp
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
|
||||
mv /tmp/static-web.yaml /etc/kubelet.d/
|
||||
sleep 20
|
||||
docker ps
|
||||
crictl ps
|
||||
```
|
||||
```
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```console
|
||||
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
|
||||
f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
|
||||
```
|
||||
|
|
|
|||
|
|
@ -154,5 +154,4 @@ kubectl exec -i -t my-pod --container main-app -- /bin/bash
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [kubectl
|
||||
* exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를참고한다.
|
||||
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 참고한다.
|
||||
|
|
@ -68,7 +68,7 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
|||
|
||||
### 요약(Summary) API 소스
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며,
|
||||
소비자(consumer)가 읽을 수 있도록 이를
|
||||
소비자(consumer)가 읽을 수 있도록 이 통계를
|
||||
[요약 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)에 기록한다.
|
||||
|
||||
1.23 이전에는 이러한 자원들은 기본적으로 [cAdvisor](https://github.com/google/cadvisor)에 의해 수집되었다.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,6 @@ weight: 10
|
|||
|
||||
{{< note >}}
|
||||
`command` 필드는 일부 컨테이너 런타임에서 `entrypoint`에 해당된다.
|
||||
아래의 [참고사항](#참고사항)을 확인하자.
|
||||
{{< /note >}}
|
||||
|
||||
이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
|
||||
|
|
@ -111,43 +110,6 @@ command: ["/bin/sh"]
|
|||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
```
|
||||
|
||||
## 참고사항
|
||||
|
||||
이 테이블은 도커와 쿠버네티스에서 사용되는 필드 이름들을 정리한 것이다.
|
||||
|
||||
| 설명 | 도커 필드 이름 | 쿠버네티스 필드 이름 |
|
||||
|----------------------------------------|------------------------|-----------------------|
|
||||
| 컨테이너에서 실행되는 커맨드 | Entrypoint | command |
|
||||
| 커맨드에 전달되는 인자들 | Cmd | arg |
|
||||
|
||||
기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에
|
||||
제공되는 기본 값들이 사용된다.
|
||||
|
||||
* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면,
|
||||
제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본
|
||||
Cmd 값은 덮어쓰여진다.
|
||||
|
||||
* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint
|
||||
값이 정의한 `args` 값들과 함께 실행된다.
|
||||
|
||||
* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본
|
||||
EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께
|
||||
실행된다.
|
||||
|
||||
여기 몇 가지 예시들이 있다.
|
||||
|
||||
| 이미지 Entrypoint | 이미지 Cmd | 컨테이너 command | 컨테이너 args | 실행되는 커맨드 |
|
||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | <설정되지 않음> | `[ep-1 foo bar]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <설정되지 않음> | `[ep-2]` |
|
||||
| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | `[zoo boo]` | `[ep-1 zoo boo]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ kubectl delete cronjob hello
|
|||
```
|
||||
|
||||
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
|
||||
[가비지(garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
|
||||
[가비지(garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
|
||||
|
||||
## 크론 잡 명세 작성
|
||||
|
||||
|
|
|
|||
|
|
@ -38,8 +38,8 @@ weight: 10
|
|||
(기본값은 1),
|
||||
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
|
||||
(기본값은 0),
|
||||
[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge)
|
||||
(베타 기능, 기본값은 25%)를
|
||||
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
|
||||
(베타 기능, 기본값은 0)를
|
||||
설정할 수도 있다.
|
||||
|
||||
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
|
||||
|
|
|
|||
|
|
@ -86,12 +86,20 @@ metadata:
|
|||
name: example-configmap-1-8mbdf7882g
|
||||
```
|
||||
|
||||
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
|
||||
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
|
||||
|
||||
```shell
|
||||
# .env 파일 생성
|
||||
# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다
|
||||
cat <<EOF >.env
|
||||
FOO=Bar
|
||||
BAZ
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
|
|
@ -105,7 +113,7 @@ EOF
|
|||
생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl kustomize ./
|
||||
BAZ=Qux kubectl kustomize ./
|
||||
```
|
||||
|
||||
생성된 컨피그맵은 다음과 같다.
|
||||
|
|
@ -113,10 +121,11 @@ kubectl kustomize ./
|
|||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
FOO=Bar
|
||||
BAZ: Qux
|
||||
FOO: Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: example-configmap-1-8mbdf7882g
|
||||
name: example-configmap-1-892ghb99c8
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -748,8 +757,8 @@ spec:
|
|||
커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다.
|
||||
|
||||
```shell
|
||||
# deployment.yaml 파일 생성
|
||||
cat <<EOF > deployment.yaml
|
||||
# deployment.yaml 파일 생성(문서 구분 기호를 따옴표로 감쌈)
|
||||
cat <<'EOF' > deployment.yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue