Merge pull request #41825 from YanyChoi/dev-1.27-ko.1-m44-m50
[ko] Update outdated files in dev-1.27-ko.1 (M44-M50)pull/44922/head
Kubernetes Prow Robot
GitHub
commit
ab8a48fa9b
|
|
@ -8,7 +8,6 @@ content_type: concept
|
|||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만
|
||||
|
|
@ -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,15 +126,18 @@ 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/)를 설정할 수 있다.
|
||||
|
|
@ -222,7 +224,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
|
|||
스케줄러 프로파일 이름과 명확한 상관 관계가 있는 노드 레이블을 사용한다.
|
||||
|
||||
{{< 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` 어피니티를 사용하여
|
||||
서로 통신을 많이 하는 두 서비스의 파드를
|
||||
|
|
@ -311,12 +313,15 @@ Y는 쿠버네티스가 충족할 규칙이다.
|
|||
파드 어피니티와 안티-어피니티의 `operator` 필드에
|
||||
`In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다.
|
||||
|
||||
이것이 어떻게 작동하는지에 대해 더 자세히 배우고 싶으면
|
||||
[오퍼레이터](#operator)를 보자.
|
||||
|
||||
원칙적으로, `topologyKey` 에는 성능과 보안상의 이유로 다음의 예외를 제외하면
|
||||
어느 레이블 키도 사용할 수 있다.
|
||||
|
||||
* 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는
|
||||
- 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는
|
||||
`requiredDuringSchedulingIgnoredDuringExecution` 및 `preferredDuringSchedulingIgnoredDuringExecution` 내에 허용되지 않는다.
|
||||
* `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해,
|
||||
- `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해,
|
||||
`LimitPodHardAntiAffinityTopology` 어드미션 컨트롤러는
|
||||
`topologyKey`를 `kubernetes.io/hostname`으로 제한한다.
|
||||
커스텀 토폴로지를 허용하고 싶다면 어드미션 컨트롤러를 수정하거나 비활성화할 수 있다.
|
||||
|
|
@ -431,7 +436,7 @@ spec:
|
|||
세 노드에 각 웹 서버가 캐시와 함께 있는 형상이다.
|
||||
|
||||
| node-1 | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| :-----------: | :-----------: | :-----------: |
|
||||
| *webserver-1* | *webserver-2* | *webserver-3* |
|
||||
| *cache-1* | *cache-2* | *cache-3* |
|
||||
|
||||
|
|
@ -458,8 +463,13 @@ spec:
|
|||
- 만약 명명된 노드에 파드를 수용할 수 있는
|
||||
리소스가 없는 경우 파드가 실패하고, 그 이유는 다음과 같이 표시된다.
|
||||
예: OutOfmemory 또는 OutOfcpu.
|
||||
- 클라우드 환경의 노드 이름은 항상 예측 가능하거나
|
||||
안정적인 것은 아니다.
|
||||
- 클라우드 환경의 노드 이름은 항상 예측 가능하거나안정적인 것은 아니다.
|
||||
|
||||
{{< note >}}
|
||||
`nodeName`은 커스텀 스케줄러 또는 기존에 설정된 스케줄러를 우회해야 하는 케이스를 위해 존재한다.
|
||||
스케줄러를 우회하는 행위는 노드가 과도하게 구독되어 파드가 실패하는 원인이 될 수 있다.
|
||||
스케줄러 우회 없이 특정 노드에 파드를 배정하기 위해서는 [노드 어피니티](#node-affinity) 또는 [노드 셀렉터](#nodeselector)를 사용할 수 있다.
|
||||
{{</ note >}}
|
||||
|
||||
다음은 `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` | 해당 셀렉터가 지은 레이블의 파싱된 정수값이 배정받은 값이 파싱된 정수값보다 작거나 같다. |
|
||||
|
||||
|
||||
{{<note>}}
|
||||
`Gt`와 `Lt` 오퍼레이터는 정수가 아닌 값에는 작동하지 않는다.
|
||||
받은 값이 정수로 파싱이 되지 않으면 파드는 스케줄링을 실패하게 된다.
|
||||
또한, `Gt`와 `Lt`는 `podAffinity`에서는 사용할 수 없다.
|
||||
{{</note>}}
|
||||
|
||||
## {{% 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/)를 어떻게 사용하는지 알아본다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,9 +37,9 @@ kubelet은 최종 사용자 파드를 종료하기 전에
|
|||
|
||||
kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라미터를 사용한다.
|
||||
|
||||
* 축출 신호
|
||||
* 축출 임계값
|
||||
* 모니터링 간격
|
||||
- 축출 신호
|
||||
- 축출 임계값
|
||||
- 모니터링 간격
|
||||
|
||||
### 축출 신호 {#eviction-signals}
|
||||
|
||||
|
|
@ -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}
|
||||
|
|
@ -149,10 +149,10 @@ kubelet은 고갈된 자원을 회수하기 위해 파드를 유예 시간 없
|
|||
|
||||
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%` (리눅스 노드)
|
||||
|
||||
이러한 하드 축출 임계값의 기본값은
|
||||
매개변수가 변경되지 않은 경우에만 설정된다. 어떤 매개변수의 값을 변경한 경우,
|
||||
|
|
@ -204,9 +204,9 @@ kubelet은 노드의 파일시스템을 기반으로 노드-수준 자원을 회
|
|||
컨테이너 런타임이 사용할 전용 `imagefs` 파일시스템이 노드에 있으면,
|
||||
kubelet은 다음 작업을 수행한다.
|
||||
|
||||
* `nodefs` 파일시스템이 축출 임계값 조건을 충족하면,
|
||||
- `nodefs` 파일시스템이 축출 임계값 조건을 충족하면,
|
||||
kubelet은 종료된 파드와 컨테이너에 대해 가비지 수집을 수행한다.
|
||||
* `imagefs` 파일시스템이 축출 임계값 조건을 충족하면,
|
||||
- `imagefs` 파일시스템이 축출 임계값 조건을 충족하면,
|
||||
kubelet은 모든 사용중이지 않은 이미지를 삭제한다.
|
||||
|
||||
#### `imagefs`가 없는 경우
|
||||
|
|
@ -351,9 +351,9 @@ kubelet에 축출 정책을 설정할 때, 만약 어떤 파드 배치가 즉시
|
|||
|
||||
다음 시나리오를 가정한다.
|
||||
|
||||
* 노드 메모리 용량: `10Gi`
|
||||
* 운영자는 시스템 데몬(커널, `kubelet` 등)을 위해 메모리 용량의 10%를 확보해 놓고 싶어 한다.
|
||||
* 운영자는 시스템 OOM 발생을 줄이기 위해 메모리 사용률이 95%인 상황에서 파드를 축출하고 싶어한다.
|
||||
- 노드 메모리 용량: `10Gi`
|
||||
- 운영자는 시스템 데몬(커널, `kubelet` 등)을 위해 메모리 용량의 10%를 확보해 놓고 싶어 한다.
|
||||
- 운영자는 시스템 OOM 발생을 줄이기 위해 메모리 사용률이 95%인 상황에서 파드를 축출하고 싶어한다.
|
||||
|
||||
이것이 실현되도록, kubelet이 다음과 같이 실행된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,8 @@ weight: 90
|
|||
`system-` 접두사를 붙일 수 없다.
|
||||
|
||||
프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질
|
||||
수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가
|
||||
수 있다. 이는 프라이어리티클래스 오브젝트는 -2147483648에서 1000000000의 값을 가질 수 있다는 뜻이다.
|
||||
중요한 시스템 파드를 대표하는 내장 프라이어리티클래스에는 더 큰 숫자가
|
||||
예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를
|
||||
하나씩 생성해야 한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,21 +26,7 @@ weight: 40
|
|||
파드가 생성될 때만 초기화할 수 있다(클라이언트에 의해 생성되거나, 어드미션 중에 변경될 때).
|
||||
생성 후 각 스케줄링게이트는 임의의 순서로 제거될 수 있지만, 새로운 스케줄링게이트의 추가는 허용되지 않는다.
|
||||
|
||||
{{<mermaid>}}
|
||||
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)를 참고한다.
|
||||
|
|
|
|||
|
|
@ -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/)에 대해 더 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -224,6 +224,10 @@ tolerations:
|
|||
테인트를 추가한다. 장애 상태가 정상으로 돌아오면 kubelet 또는 노드 컨트롤러가
|
||||
관련 테인트를 제거할 수 있다.
|
||||
|
||||
노드에 접근이 불가능한 경우, API 서버는 노드의 kubelet과의 통신에 실패한다. 파드 삭제 결정은
|
||||
API 서버와의 통신이 재개될 때까지 kubelet에 전달될 수 없다. 그동안 삭제가 스케쥴링된 파드들이 분리된 노드에서
|
||||
지속적으로 작동할 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다.
|
||||
이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로)
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ spec:
|
|||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
matchLabelKeys: <list> # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
|
||||
matchLabelKeys: <list> # 선택 사항이며, 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`와 같은 잘 알려진 레이블을 자동으로 붙인다.
|
||||
이용하려는 클러스터가 이를 지원하는지 확인해 본다.
|
||||
|
||||
## 토폴로지 분배 제약 조건 예시
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 12 KiB |
Loading…
Reference in New Issue