diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index b364410cb5..bf51fe3196 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -8,10 +8,9 @@ content_type: concept weight: 20 --- - -특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 +특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 {{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 @@ -28,10 +27,10 @@ weight: 20 쿠버네티스가 특정 파드를 어느 노드에 스케줄링할지 고르는 다음의 방법 중 하나를 골라 사용할 수 있다. - * [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드 - * [어피니티 / 안티 어피니티](#affinity-and-anti-affinity) - * [nodeName](#nodename) 필드 - * [파드 토폴로지 분배 제약 조건](#pod-topology-spread-constraints) +- [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드 +- [어피니티 / 안티 어피니티](#affinity-and-anti-affinity) +- [nodeName](#nodename) 필드 +- [파드 토폴로지 분배 제약 조건](#pod-topology-spread-constraints) ## 노드 레이블 {#built-in-node-labels} @@ -84,20 +83,20 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다. -* 어피니티/안티-어피니티 언어가 더 표현적이다. +- 어피니티/안티-어피니티 언어가 더 표현적이다. `nodeSelector`로는 명시한 레이블이 있는 노드만 선택할 수 있다. 어피니티/안티-어피니티는 선택 로직에 대한 좀 더 많은 제어권을 제공한다. -* 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, +- 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, 이 덕분에 스케줄러는 매치되는 노드를 찾지 못한 경우에도 파드를 스케줄링할 수 있다. -* 다른 노드 (또는 다른 토폴로지 도메인)에서 실행 중인 +- 다른 노드 (또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 사용하여 파드를 제한할 수 있으며, 이를 통해 어떤 파드들이 노드에 함께 위치할 수 있는지에 대한 규칙을 정의할 수 있다. 어피니티 기능은 다음의 두 가지 종류로 구성된다. -* *노드 어피니티* 기능은 `nodeSelector` 필드와 비슷하지만 +- *노드 어피니티* 기능은 `nodeSelector` 필드와 비슷하지만 더 표현적이고 소프트(soft) 규칙을 지정할 수 있게 해 준다. -* *파드 간 어피니티/안티-어피니티* 는 다른 파드의 레이블을 이용하여 +- *파드 간 어피니티/안티-어피니티* 는 다른 파드의 레이블을 이용하여 해당 파드를 제한할 수 있게 해 준다. ### 노드 어피니티 {#node-affinity} @@ -106,10 +105,10 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다. 노드 어피니티에는 다음의 두 종류가 있다. - * `requiredDuringSchedulingIgnoredDuringExecution`: +- `requiredDuringSchedulingIgnoredDuringExecution`: 규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. 이 기능은 `nodeSelector`와 유사하지만, 좀 더 표현적인 문법을 제공한다. - * `preferredDuringSchedulingIgnoredDuringExecution`: +- `preferredDuringSchedulingIgnoredDuringExecution`: 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. 해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다. @@ -127,17 +126,20 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 이 예시에서는 다음의 규칙이 적용된다. - * 노드는 키가 `topology.kubernetes.io/zone`인 레이블을 갖고 *있어야 하며*, +- 노드는 키가 `topology.kubernetes.io/zone`인 레이블을 갖고 *있어야 하며*, 레이블의 값이 `antarctica-east1` 혹은 `antarctica-west1`*여야 한다*. - * 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을 +- 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을 갖고 있는 노드를 *선호한다* . `operator` 필드를 사용하여 쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` 및 `Lt` 연산자를 사용할 수 있다. +이것이 어떻게 작동하는지에 대해 더 자세히 배우고 싶으면 +[오퍼레이터](#operator)를 보자. + `NotIn` 및 `DoesNotExist` 연산자를 사용하여 노드 안티-어피니티 규칙을 정의할 수 있다. -또는, 특정 노드에서 파드를 쫓아내는 +또는, 특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. {{}} @@ -217,12 +219,12 @@ PodSpec에 지정된 NodeAffinity도 적용된다. 즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다. -`addedAffinity`는 엔드 유저에게 표시되지 않으므로, +`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 스케줄러 프로파일 이름과 명확한 상관 관계가 있는 노드 레이블을 사용한다. {{< note >}} -[데몬셋 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 +[데몬셋 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#데몬-파드가-스케줄-되는-방법)하는 데몬셋 컨트롤러는 스케줄링 프로파일을 지원하지 않는다. 데몬셋 컨트롤러가 파드를 생성할 때, 기본 쿠버네티스 스케줄러는 해당 파드를 배치하고 데몬셋 컨트롤러의 모든 `nodeAffinity` 규칙을 준수한다. @@ -268,8 +270,8 @@ Y는 쿠버네티스가 충족할 규칙이다. 노드 어피니티와 마찬가지로 파드 어피니티 및 안티-어피니티에는 다음의 2 종류가 있다. - * `requiredDuringSchedulingIgnoredDuringExecution` - * `preferredDuringSchedulingIgnoredDuringExecution` +- `requiredDuringSchedulingIgnoredDuringExecution` +- `preferredDuringSchedulingIgnoredDuringExecution` 예를 들어, `requiredDuringSchedulingIgnoredDuringExecution` 어피니티를 사용하여 서로 통신을 많이 하는 두 서비스의 파드를 @@ -293,7 +295,7 @@ Y는 쿠버네티스가 충족할 규칙이다. 파드 어피니티 규칙은 "하드" `requiredDuringSchedulingIgnoredDuringExecution`을, 안티-어피니티 규칙은 "소프트" `preferredDuringSchedulingIgnoredDuringExecution`을 사용한다. -위의 어피니티 규칙은 `security=S1` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에만 +위의 어피니티 규칙은 `security=S1` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에만 파드를 스케줄링하도록 스케줄러에 지시한다. 더 정확히 말하면, 만약 `security=S1` 파드 레이블이 있는 하나 이상의 기존 파드를 실행하고 있는 노드가 `zone=V`에 하나 이상 존재한다면, @@ -311,12 +313,15 @@ Y는 쿠버네티스가 충족할 규칙이다. 파드 어피니티와 안티-어피니티의 `operator` 필드에 `In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다. +이것이 어떻게 작동하는지에 대해 더 자세히 배우고 싶으면 +[오퍼레이터](#operator)를 보자. + 원칙적으로, `topologyKey` 에는 성능과 보안상의 이유로 다음의 예외를 제외하면 어느 레이블 키도 사용할 수 있다. -* 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는 +- 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는 `requiredDuringSchedulingIgnoredDuringExecution` 및 `preferredDuringSchedulingIgnoredDuringExecution` 내에 허용되지 않는다. -* `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해, +- `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해, `LimitPodHardAntiAffinityTopology` 어드미션 컨트롤러는 `topologyKey`를 `kubernetes.io/hostname`으로 제한한다. 커스텀 토폴로지를 허용하고 싶다면 어드미션 컨트롤러를 수정하거나 비활성화할 수 있다. @@ -332,7 +337,7 @@ Y는 쿠버네티스가 충족할 규칙이다. 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. `namespaceSelector` 또는 `namespaces` 필드에 의해 선택된 네임스페이스 모두에 적용된다. -빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, +빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이 적용된 파드의 네임스페이스에 매치된다. #### 더 실제적인 유스케이스 {#more-practical-use-cases} @@ -430,10 +435,10 @@ spec: 위의 두 디플로이먼트를 생성하면 다음과 같은 클러스터 형상이 나타나는데, 세 노드에 각 웹 서버가 캐시와 함께 있는 형상이다. -| node-1 | node-2 | node-3 | -|:--------------------:|:-------------------:|:------------------:| -| *webserver-1* | *webserver-2* | *webserver-3* | -| *cache-1* | *cache-2* | *cache-3* | +| node-1 | node-2 | node-3 | +| :-----------: | :-----------: | :-----------: | +| *webserver-1* | *webserver-2* | *webserver-3* | +| *cache-1* | *cache-2* | *cache-3* | 전체적인 효과는 각 캐시 인스턴스를 동일한 노드에서 실행 중인 단일 클라이언트가 액세스하게 될 것 같다는 것이다. 이 접근 방식은 차이(불균형 로드)와 대기 ​​시간을 모두 최소화하는 것을 목표로 한다. @@ -453,13 +458,18 @@ spec: `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다. -- 만약 명명된 노드가 없으면, 파드가 실행되지 않고 - 따라서 자동으로 삭제될 수 있다. -- 만약 명명된 노드에 파드를 수용할 수 있는 - 리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다. - 예: OutOfmemory 또는 OutOfcpu. -- 클라우드 환경의 노드 이름은 항상 예측 가능하거나 - 안정적인 것은 아니다. +- 만약 명명된 노드가 없으면, 파드가 실행되지 않고 + 따라서 자동으로 삭제될 수 있다. +- 만약 명명된 노드에 파드를 수용할 수 있는 + 리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다. + 예: OutOfmemory 또는 OutOfcpu. +- 클라우드 환경의 노드 이름은 항상 예측 가능하거나안정적인 것은 아니다. + +{{< note >}} +`nodeName`은 커스텀 스케줄러 또는 기존에 설정된 스케줄러를 우회해야 하는 케이스를 위해 존재한다. +스케줄러를 우회하는 행위는 노드가 과도하게 구독되어 파드가 실패하는 원인이 될 수 있다. +스케줄러 우회 없이 특정 노드에 파드를 배정하기 위해서는 [노드 어피니티](#node-affinity) 또는 [노드 셀렉터](#nodeselector)를 사용할 수 있다. +{{}} 다음은 `nodeName` 필드를 사용하는 파드 스펙 예시이다. @@ -484,6 +494,31 @@ _토폴로지 분배 제약 조건_을 사용하여 지역(regions), 영역(zone [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에서 작동 방식에 대해 더 자세히 알아볼 수 있다. +## 오퍼레이터 {#operator} + +위의 `nodeAffinity`와 `podAffinity`의 `operator` 필드에 사용할 수 있는 논리적 오퍼레이터는 다음과 같다. + +| 오퍼레이터 | 행동 | +| :------------: | :-------------: | +| `In` | 배정받은 문자열의 집합 내에 레이블이 존재한다. | +| `NotIn` | 배정받은 문자열의 집합 내에 레이블이 존재하지 않는다. | +| `Exists` | 오브젝트 내에 해당 레이블이 키로 존재한다. | +| `DoesNotExist` | 오브젝트 내에 해당 레이블이 키로 존재하지 않는다. | + +`nodeAffinity`에서만 사용할 수 있는 오퍼레이터는 다음과 같다. + +| 오퍼레이터 | 행동 | +| :------------: | :-------------: | +| `Gt` | 해당 셀렉터가 지은 레이블의 파싱된 정수값이 배정받은 값이 파싱된 정수값보다 크거나 같다. | +| `Lt` | 해당 셀렉터가 지은 레이블의 파싱된 정수값이 배정받은 값이 파싱된 정수값보다 작거나 같다. | + + +{{}} +`Gt`와 `Lt` 오퍼레이터는 정수가 아닌 값에는 작동하지 않는다. +받은 값이 정수로 파싱이 되지 않으면 파드는 스케줄링을 실패하게 된다. +또한, `Gt`와 `Lt`는 `podAffinity`에서는 사용할 수 없다. +{{}} + ## {{% heading "whatsnext" %}} * [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다. @@ -493,5 +528,3 @@ _토폴로지 분배 제약 조건_을 사용하여 지역(regions), 영역(zone 노드 수준 리소스 할당 결정에 어떻게 관여하는지 알아본다. * [노드셀렉터(nodeSelector)](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 어떻게 사용하는지 알아본다. * [어피니티/안티-어피니티](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)를 어떻게 사용하는지 알아본다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 85556c6ca2..c2110ee934 100644 --- a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -8,11 +8,11 @@ weight: 100 {{}}은 클러스터 노드의 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다. -이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, -kubelet은 하나 이상의 파드를 능동적으로 중단시켜 +이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, +kubelet은 하나 이상의 파드를 능동적으로 중단시켜 자원을 회수하고 고갈 상황을 방지할 수 있다. -노드-압박 축출 과정에서, kubelet은 축출할 파드의 `PodPhase`를 +노드-압박 축출 과정에서, kubelet은 축출할 파드의 `PodPhase`를 `Failed`로 설정함으로써 파드가 종료된다. 노드-압박 축출은 @@ -23,7 +23,7 @@ kubelet은 이전에 설정된 `PodDisruptionBudget` 값이나 파드의 `termin kubelet은 이전에 설정된 `eviction-max-pod-grace-period` 값을 따른다. [하드 축출 임계값](#hard-eviction-thresholds)을 사용하는 경우, 파드 종료 시 `0s` 만큼 기다린 후 종료한다(즉, 기다리지 않고 바로 종료한다). -실패한 파드를 새로운 파드로 교체하는 +실패한 파드를 새로운 파드로 교체하는 {{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스(예: {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})가 파드를 관리하는 경우, @@ -37,9 +37,9 @@ kubelet은 최종 사용자 파드를 종료하기 전에 kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라미터를 사용한다. - * 축출 신호 - * 축출 임계값 - * 모니터링 간격 +- 축출 신호 +- 축출 임계값 +- 모니터링 간격 ### 축출 신호 {#eviction-signals} @@ -59,13 +59,13 @@ kubelet은 다음과 같은 축출 신호를 사용한다. | `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` | | `pid.available` | `pid.available` := `node.stats.rlimit.maxpid` - `node.stats.rlimit.curproc` | -이 표에서, `설명` 열은 kubelet이 축출 신호 값을 계산하는 방법을 나타낸다. -각 축출 신호는 백분율 또는 숫자값을 지원한다. -kubelet은 총 용량 대비 축출 신호의 백분율 값을 +이 표에서, `설명` 열은 kubelet이 축출 신호 값을 계산하는 방법을 나타낸다. +각 축출 신호는 백분율 또는 숫자값을 지원한다. +kubelet은 총 용량 대비 축출 신호의 백분율 값을 계산한다. -`memory.available` 값은 `free -m`과 같은 도구가 아니라 cgroupfs로부터 도출된다. -이는 `free -m`이 컨테이너 안에서는 동작하지 않고, 또한 사용자가 +`memory.available` 값은 `free -m`과 같은 도구가 아니라 cgroupfs로부터 도출된다. +이는 `free -m`이 컨테이너 안에서는 동작하지 않고, 또한 사용자가 [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 기능을 사용하는 경우 자원 부족에 대한 결정은 루트 노드뿐만 아니라 cgroup 계층 구조의 최종 사용자 파드 부분에서도 지역적으로 이루어지기 때문에 중요하다. @@ -102,10 +102,10 @@ kubelet이 축출 결정을 내릴 때 사용하는 축출 임계값을 축출 임계값은 `[eviction-signal][operator][quantity]` 형태를 갖는다. -* `eviction-signal`에는 사용할 [축출 신호](#eviction-signals)를 적는다. -* `operator`에는 [관계연산자](https://ko.wikipedia.org/wiki/관계연산자#표준_관계연산자)를 +- `eviction-signal`에는 사용할 [축출 신호](#eviction-signals)를 적는다. +- `operator`에는 [관계연산자](https://ko.wikipedia.org/wiki/관계연산자#표준_관계연산자)를 적는다(예: `<` - 미만) -* `quantity`에는 `1Gi`와 같이 축출 임계값 수치를 적는다. +- `quantity`에는 `1Gi`와 같이 축출 임계값 수치를 적는다. `quantity`에 들어가는 값은 쿠버네티스가 사용하는 수치 표현 방식과 맞아야 한다. 숫자값 또는 백분율(`%`)을 사용할 수 있다. @@ -131,11 +131,11 @@ kubelet은 축출된 파드를 유예 시간 없이 즉시 종료한다. 소프트 축출 임계값을 설정할 때 다음과 같은 플래그를 사용할 수 있다. -* `eviction-soft`: 축출 임계값(예: `memory.available<1.5Gi`)의 집합이며, +- `eviction-soft`: 축출 임계값(예: `memory.available<1.5Gi`)의 집합이며, 지정된 유예 시간동안 이 축출 임계값 조건이 충족되면 파드 축출이 트리거된다. -* `eviction-soft-grace-period`: 축출 유예 시간의 집합이며, +- `eviction-soft-grace-period`: 축출 유예 시간의 집합이며, 소프트 축출 임계값 조건이 이 유예 시간동안 충족되면 파드 축출이 트리거된다. -* `eviction-max-pod-grace-period`: '최대 허용 파드 종료 유예 시간(단위: 초)'이며, +- `eviction-max-pod-grace-period`: '최대 허용 파드 종료 유예 시간(단위: 초)'이며, 소프트 축출 임계값 조건이 충족되어 파드를 종료할 때 사용한다. #### 하드 축출 임계값 {#hard-eviction-thresholds} @@ -144,17 +144,17 @@ kubelet은 축출된 파드를 유예 시간 없이 즉시 종료한다. kubelet은 고갈된 자원을 회수하기 위해 파드를 유예 시간 없이 즉시 종료한다. -`eviction-hard` 플래그를 사용하여 하드 축출 +`eviction-hard` 플래그를 사용하여 하드 축출 임계값(예: `memory.available<1Gi`)을 설정할 수 있다. kubelet은 다음과 같은 하드 축출 임계값을 기본적으로 설정하고 있다. -* `memory.available<100Mi` -* `nodefs.available<10%` -* `imagefs.available<15%` -* `nodefs.inodesFree<5%` (리눅스 노드) +- `memory.available<100Mi` +- `nodefs.available<10%` +- `imagefs.available<15%` +- `nodefs.inodesFree<5%` (리눅스 노드) -이러한 하드 축출 임계값의 기본값은 +이러한 하드 축출 임계값의 기본값은 매개변수가 변경되지 않은 경우에만 설정된다. 어떤 매개변수의 값을 변경한 경우, 다른 매개변수의 값은 기본값으로 상속되지 않고 0으로 설정된다. 사용자 지정 값을 제공하려면, @@ -167,8 +167,8 @@ kubelet은 `housekeeping-interval`에 설정된 시간 간격(기본값: `10s`) ### 노드 컨디션 {#node-conditions} -kubelet은 하드/소프트 축출 임계값 조건이 충족되어 -노드 압박이 발생했다는 것을 알리기 위해, +kubelet은 하드/소프트 축출 임계값 조건이 충족되어 +노드 압박이 발생했다는 것을 알리기 위해, 설정된 유예 시간과는 관계없이 노드 컨디션을 보고한다. kubelet은 다음과 같이 노드 컨디션과 축출 신호를 매핑한다. @@ -179,7 +179,7 @@ kubelet은 다음과 같이 노드 컨디션과 축출 신호를 매핑한다. | `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, 또는 `imagefs.inodesFree` | 노드의 루트 파일시스템 또는 이미지 파일시스템의 가용 디스크 공간 또는 inode의 수가 축출 임계값에 도달함 | | `PIDPressure` | `pid.available` | (리눅스) 노드의 가용 프로세스 ID(PID)가 축출 임계값 이하로 내려옴 | -kubelet은 `--node-status-update-frequency`에 설정된 +kubelet은 `--node-status-update-frequency`에 설정된 시간 간격(기본값: `10s`)마다 노드 컨디션을 업데이트한다. #### 노드 컨디션 진동(oscillation) @@ -204,10 +204,10 @@ kubelet은 노드의 파일시스템을 기반으로 노드-수준 자원을 회 컨테이너 런타임이 사용할 전용 `imagefs` 파일시스템이 노드에 있으면, kubelet은 다음 작업을 수행한다. - * `nodefs` 파일시스템이 축출 임계값 조건을 충족하면, - kubelet은 종료된 파드와 컨테이너에 대해 가비지 수집을 수행한다. - * `imagefs` 파일시스템이 축출 임계값 조건을 충족하면, - kubelet은 모든 사용중이지 않은 이미지를 삭제한다. +- `nodefs` 파일시스템이 축출 임계값 조건을 충족하면, + kubelet은 종료된 파드와 컨테이너에 대해 가비지 수집을 수행한다. +- `imagefs` 파일시스템이 축출 임계값 조건을 충족하면, + kubelet은 모든 사용중이지 않은 이미지를 삭제한다. #### `imagefs`가 없는 경우 @@ -351,9 +351,9 @@ kubelet에 축출 정책을 설정할 때, 만약 어떤 파드 배치가 즉시 다음 시나리오를 가정한다. -* 노드 메모리 용량: `10Gi` -* 운영자는 시스템 데몬(커널, `kubelet` 등)을 위해 메모리 용량의 10%를 확보해 놓고 싶어 한다. -* 운영자는 시스템 OOM 발생을 줄이기 위해 메모리 사용률이 95%인 상황에서 파드를 축출하고 싶어한다. +- 노드 메모리 용량: `10Gi` +- 운영자는 시스템 데몬(커널, `kubelet` 등)을 위해 메모리 용량의 10%를 확보해 놓고 싶어 한다. +- 운영자는 시스템 OOM 발생을 줄이기 위해 메모리 사용률이 95%인 상황에서 파드를 축출하고 싶어한다. 이것이 실현되도록, kubelet이 다음과 같이 실행된다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 92d7611d03..a76f907d08 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -63,7 +63,8 @@ weight: 90 `system-` 접두사를 붙일 수 없다. 프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질 -수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가 +수 있다. 이는 프라이어리티클래스 오브젝트는 -2147483648에서 1000000000의 값을 가질 수 있다는 뜻이다. +중요한 시스템 파드를 대표하는 내장 프라이어리티클래스에는 더 큰 숫자가 예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를 하나씩 생성해야 한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md b/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md index e1239c32e1..af910ffecf 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md @@ -26,21 +26,7 @@ weight: 40 파드가 생성될 때만 초기화할 수 있다(클라이언트에 의해 생성되거나, 어드미션 중에 변경될 때). 생성 후 각 스케줄링게이트는 임의의 순서로 제거될 수 있지만, 새로운 스케줄링게이트의 추가는 허용되지 않는다. -{{}} -stateDiagram-v2 - s1: 파드 생성 - s2: 파드 스케줄링 게이트됨 - s3: 파드 스케줄링 준비됨 - s4: 파드 실행 - if: 스케줄링 게이트가 비어 있는가? - [*] --> s1 - s1 --> if - s2 --> if: 스케줄링 게이트 제거됨 - if --> s2: 아니오 - if --> s3: 네 - s3 --> s4 - s4 --> [*] -{{< /mermaid >}} +{{< figure src="/ko/docs/images/podSchedulingGates.svg" alt="pod-scheduling-gates-diagram" caption="그림. 파드 스케줄링게이트" class="diagram-large" link="https://mermaid.live/edit#pako:eNp1Uk9v0zAc_SqWd5vSdU2yrDMSXMaREzcIBy-2G6tJHMXOYKoqFZHD6HqYBEwcNsQh0nbc0A4g8Yka9zvg_OmqScwn_97v-fk9-zeBgSAUIigVVvSQ41GG496x7Sd-AsySAwRWi0X15RLoT1e6uOtgewPPS_13psuiuv4Ilr8W-up-Nf9dnd90TOf_TF3Oqj_FhuZuaGfl6uJzC3OGnrhgeTsDRkBf3AP947SafzXAi_bQ2-13oNd7bryvMzQlZ2vvXfmUNNA_L5d3tw_eOGvlTGb9rajOTvX38nHHZKyKch24xdx1sKY0nuonDSIs5SFlYDyUgPEoQluO7QV0z5IqE2OKthhj3b73nhMVIjf9YAUiElnTe9ZpmFCWtC3pWNK1eKPnJ9CCMc1izIn50El9vw9VSGPqQ2S2BGdjH_rJ1PBwrsTrkySASGU5tWCeks3_PwZfEq5EBhHDkTRgJDChppxAdZLWkzPiUhnFQCSMj2o8zyIDh0qlEvX7dXtnxFWYH-0EIu5LTkKcqfD4wOt7tjfEtkO9fQfvOQ4JjgYHQ2a7A0b2dwc2htOpBVOcvBEifjBAGz-v2rFtpnf6DwGYFtw" >}} ## 사용 예시 @@ -70,7 +56,7 @@ kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}' 출력은 다음과 같다. ```none -[{"name":"foo"},{"name":"bar"}] +[{"name":"example.com/foo"},{"name":"example.com/bar"}] ``` 스케줄러에게 이 파드가 스케줄링 될 준비가 되었음을 알리기 위해, 수정된 매니페스트를 다시 적용하여 @@ -104,6 +90,28 @@ test-pod 1/1 Running 0 15s 10.0.0.4 node-2 구분하기 위해 `scheduler_pending_pods` 메트릭은 `”gated"`라는 새로운 레이블과 함께 제공된다. `scheduler_pending_pods{queue="gated"}`를 사용하여 메트릭 결과를 확인할 수 있다. +## 파드 스케줄링 지시(Pod Scheduling Directives) 변경하기 + +{{< feature-state for_k8s_version="v1.27" state="beta" >}} + +일정한 제약 조건이 있는 스케줄링 게이트가 있는 동안 포드의 스케줄링 지시를 변경할 수 있다. 고수준의 관점에서는 +파드의 스케줄링 지시를 줄이는 것만 가능하다. 즉, 업데이트된 지시는 파드를 이전에 일치했던 노드의 하위 집합으로만 +스케줄링할 수 있다. 파드의 스케줄링 지시을 업데이트하는 규칙은 다음과 같다. + +1. `.spec.nodeSelector`의 경우, 조건의 추가만 허용된다. 비어있는 경우, 새로 설정할 수 있다. + +2. `spec.affinity.nodeAffinity`가 nil이면, 어떤 값으로든 설정이 가능하다. + +3. `NodeSelectorTerms`가 비어있다면, 설정이 가능하다. 비어있지 않다면, `matchExpressions` 또는 + `fieldExpressions`에 `NodeSelectorRequirements`만 추가할 수 있으며, + 이미 존재하는 `matchExpressions`과 `fieldExpressions`을 변경하지 않아도 된다. 이는 + `.requiredDuringSchedulingIgnoredDuringExecution.NodeSelectorTerms`은 OR로 적용되는 것에 반해 + `nodeSelectorTerms[].matchExpressions`과 `nodeSelectorTerms[].fieldExpressions`의 + 표현식에는 AND로 적용되기 때문이다. + +4. `.preferredDuringSchedulingIgnoredDuringExecution`의 경우, 모든 업데이트가 허용된다. 이는 + 선호한다는 조건이 강제되지 않고, 이로 인해 정책 컨트롤러들은 해당 항목들을 검증하지 않기 때문이다. + ## {{% heading "whatsnext" %}} * 자세한 내용은 [PodSchedulingReadiness KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness)를 참고한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index fcabf42c3a..07b1d9ad9a 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -100,10 +100,10 @@ kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여 ```yaml shape: - - utilization: 0 - score: 0 - - utilization: 100 - score: 10 + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 ``` 위의 인수는 `utilization` 이 0%인 경우 `score` 는 0, `utilization` 이 @@ -120,7 +120,7 @@ shape: `resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다. -``` yaml +```yaml resources: - name: cpu weight: 1 @@ -251,4 +251,3 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) - [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다. - [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다. - diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index cf97d54f34..b04eebdc33 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -224,6 +224,10 @@ tolerations: 테인트를 추가한다. 장애 상태가 정상으로 돌아오면 kubelet 또는 노드 컨트롤러가 관련 테인트를 제거할 수 있다. +노드에 접근이 불가능한 경우, API 서버는 노드의 kubelet과의 통신에 실패한다. 파드 삭제 결정은 +API 서버와의 통신이 재개될 때까지 kubelet에 전달될 수 없다. 그동안 삭제가 스케쥴링된 파드들이 분리된 노드에서 +지속적으로 작동할 수도 있다. + {{< note >}} 콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다. 이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로) diff --git a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md index bcc37bb1a1..c251a7e5bf 100644 --- a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -64,7 +64,7 @@ spec: topologyKey: whenUnsatisfiable: labelSelector: - matchLabelKeys: # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. + matchLabelKeys: # 선택 사항이며, v1.27에서 베타 기능으로 도입되었다. nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다. nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다. ### 파드의 다른 필드가 이 아래에 오게 된다. @@ -97,8 +97,8 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다. {{< note >}} - `minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우 - `MinDomainsInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다. + `minDomains` 필드는 1.25에서 기본적으로 비활성화되어 있는 베타 필드이다. 사용을 원할 경우 + `MinDomainsInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. {{< /note >}} - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다. @@ -129,24 +129,29 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. - **matchLabelKeys** 는 분배도(spreading)가 계산될 파드를 선택하기 위한 파드 레이블 - 키 목록이다. 키는 파드 레이블에서 값을 조회하는 데 사용되며, 이러한 키-값 레이블은 `labelSelector`와 AND 처리되어 들어오는 파드(incoming pod)에 대해 분배도가 계산될 기존 파드 그룹의 선택에 사용된다. 파드 레이블에 없는 키는 무시된다. null 또는 비어 있는 목록은 `labelSelector`와만 일치함을 의미한다. + 키 목록이다. 키는 파드 레이블에서 값을 조회하는 데 사용되며, 이러한 키-값 레이블은 `labelSelector`와 AND 처리되어 + 들어오는 파드(incoming pod)에 대해 분배도가 계산될 기존 파드 그룹의 선택에 사용된다. + `matchLabelKeys`와 `labelSelector`에 동일한 키는 금지된다. 또한 `labelSelector`가 설정되어 있지 않으면 + `matchLabelKeys`는 설정할 수 없다. 파드 레이블에 없는 키는 무시된다. null 또는 비어 있는 목록은 `labelSelector`와만 일치함을 의미한다. - `matchLabelKeys`를 사용하면, 사용자는 다른 리비전 간에 `pod.spec`을 업데이트할 필요가 없다. 컨트롤러/오퍼레이터는 다른 리비전에 대해 동일한 `label`키에 다른 값을 설정하기만 하면 된다. 스케줄러는 `matchLabelKeys`를 기준으로 값을 자동으로 가정할 것이다. 예를 들어 사용자가 디플로이먼트를 사용하는 경우, 디플로이먼트 컨트롤러에 의해 자동으로 추가되는 `pod-template-hash`로 키가 지정된 레이블을 사용함으로써 단일 디플로이먼트에서 서로 다른 리비전을 구별할 수 있다. + `matchLabelKeys`를 사용하면, 사용자는 다른 리비전 간에 `pod.spec`을 업데이트할 필요가 없다. 컨트롤러/오퍼레이터는 다른 리비전에 대해 동일한 `label`키에 다른 값을 설정하기만 하면 된다. 스케줄러는 `matchLabelKeys`를 기준으로 값을 자동으로 가정할 것이다. 예를 들어 당신이 디플로이먼트를 사용하는 경우, 디플로이먼트 컨트롤러에 의해 자동으로 추가되는 [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label)로 키가 지정된 레이블을 사용함으로써 단일 디플로이먼트에서 서로 다른 리비전을 구별할 수 있다. ```yaml topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + app: foo matchLabelKeys: - - app - pod-template-hash ``` {{< note >}} - `matchLabelKeys` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `matchLabelKeys` 필드는 1.27에서 기본값으로 활성화되어 있는 베타 필드이다. 이 필드를 비활성화하려면 `MatchLabelKeysInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) - 를 활성화시켜야 한다. + 를 비활성화시켜야 한다. {{< /note >}} - **nodeAffinityPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 @@ -243,7 +248,7 @@ graph TB 동일한 토폴로지 도메인(예: 클라우드 공급자 리전)에 있는 모든 노드가 일관적으로 레이블되도록 하는 메카니즘이 필요하다. 각 노드를 수동으로 레이블하는 것을 피하기 위해, -대부분의 클러스터는 `topology.kubernetes.io/hostname`와 같은 잘 알려진 레이블을 자동으로 붙인다. +대부분의 클러스터는 `kubernetes.io/hostname`와 같은 잘 알려진 레이블을 자동으로 붙인다. 이용하려는 클러스터가 이를 지원하는지 확인해 본다. ## 토폴로지 분배 제약 조건 예시 diff --git a/content/ko/docs/images/podSchedulingGates.svg b/content/ko/docs/images/podSchedulingGates.svg new file mode 100644 index 0000000000..92f11aa8c6 --- /dev/null +++ b/content/ko/docs/images/podSchedulingGates.svg @@ -0,0 +1 @@ +
스케줄링 게이트 제거됨
아니오
네
파드 생성
파드 스케줄링 게이트됨
파드 스케줄링 준비됨
파드 실행
스케줄링 게이트가 비어 있는가?
 \ No newline at end of file