kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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 2024-01-26 07:33:37 +01:00 committed by GitHub
parent 537ff99bba dfaf0839dc
commit ab8a48fa9b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
8 changed files with 154 additions and 103 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -8,10 +8,9 @@ content_type: concept
weight: 20
---
<!-- overview -->
특정한 {{< 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/)를 설정할 수 있다.
{{<note>}}
@ -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)를 사용할 수 있다.
{{</ 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/)를 어떻게 사용하는지 알아본다.

68
content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
View File

@ -8,11 +8,11 @@ weight: 100
{{<glossary_tooltip term_id="kubelet" text="kubelet">}}은
클러스터 노드의 메모리, 디스크 공간, 파일시스템 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이 다음과 같이 실행된다.

3
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -63,7 +63,8 @@ weight: 90
`system-` 접두사를 붙일 수 없다.
프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질
수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가
수 있다. 이는 프라이어리티클래스 오브젝트는 -2147483648에서 1000000000의 값을 가질 수 있다는 뜻이다.
중요한 시스템 파드를 대표하는 내장 프라이어리티클래스에는 더 큰 숫자가
예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를
하나씩 생성해야 한다.

40
content/ko/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md
View File

@ -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)를 참고한다.

11
content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
View File

@ -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/)에 대해 더 읽어본다.

4
content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -224,6 +224,10 @@ tolerations:
테인트를 추가한다. 장애 상태가 정상으로 돌아오면 kubelet 또는 노드 컨트롤러가
관련 테인트를 제거할 수 있다.
노드에 접근이 불가능한 경우, API 서버는 노드의 kubelet과의 통신에 실패한다. 파드 삭제 결정은
API 서버와의 통신이 재개될 때까지 kubelet에 전달될 수 없다. 그동안 삭제가 스케쥴링된 파드들이 분리된 노드에서
지속적으로 작동할 수도 있다.
{{< note >}}
콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다.
이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로)

23
content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md
View File

@ -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`와 같은 잘 알려진 레이블을 자동으로 붙인다.
이용하려는 클러스터가 이를 지원하는지 확인해 본다.
## 토폴로지 분배 제약 조건 예시

1
content/ko/docs/images/podSchedulingGates.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB