From 615ff586b203d82701f3fac24c425fcba5e2b7e7 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 20 Dec 2021 15:28:55 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.23-ko.1 M55-61 --- content/ko/docs/reference/kubectl/overview.md | 1 + .../reference/labels-annotations-taints.md | 35 ++- .../ko/docs/reference/scheduling/config.md | 222 +++++++++++++++--- .../ko/docs/reference/scheduling/policies.md | 94 +------- content/ko/docs/reference/tools/_index.md | 16 ++ .../reference/using-api/client-libraries.md | 4 +- .../docs/reference/using-api/health-checks.md | 8 +- 7 files changed, 253 insertions(+), 127 deletions(-) diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index c00d0565b5..4b289d50d2 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -91,6 +91,7 @@ kubectl [command] [TYPE] [NAME] [flags] * `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고, * `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고, * kubectl 명령에 네임스페이스를 명시하지 않으면 + kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다. 이는 클러스터 외부에서 실행되었을 때와는 다른데, diff --git a/content/ko/docs/reference/labels-annotations-taints.md b/content/ko/docs/reference/labels-annotations-taints.md index 2577531042..dbc769179a 100644 --- a/content/ko/docs/reference/labels-annotations-taints.md +++ b/content/ko/docs/reference/labels-annotations-taints.md @@ -36,10 +36,9 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블 적용 대상: 네임스페이스 -`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있으면, -쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다. -레이블의 값은 네임스페이스의 이름으로 적용된다. +({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인) +쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다. +레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다. 레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 이 레이블이 유용할 수 있다. @@ -63,6 +62,16 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다. +## kubernetes.io/change-cause {#change-cause} + +예시: `kubernetes.io/change-cause=kubectl edit --record deployment foo` + +적용 대상: 모든 오브젝트 + +이 어노테이션은 어떤 오브젝트가 왜 변경되었는지 그 이유를 담는다. + +어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다. + ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} 예시: `controller.kubernetes.io/pod-deletion-cost=10` @@ -425,4 +434,20 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 객체를 만들거나 업데이트할 때에도 경고가 표시된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 -참고한다. \ No newline at end of file +참고한다. + +## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod} + +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다. +파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다. +[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면, +해당 설정이 파드 내의 모든 컨테이너에 적용된다. + +## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io} + +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/clusters/seccomp/) 튜토리얼에서 +seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. +튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, +이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다. diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index d31897054d..1c1db61d1b 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -18,8 +18,8 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)) +KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/) +또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) 구조에 맞게 파일을 작성하고, `kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. @@ -78,6 +78,8 @@ clientConnection: 플러그인은 적어도 하나 이상 필요하다. 1. `postBind`: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다. +1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해 + 플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다. 각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. @@ -101,7 +103,7 @@ profiles: 모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 사용할 수도 있다. -### 스케줄링 플러그인 +### 스케줄링 플러그인 {#scheduling-plugins} 기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 하나 이상을 구현한다. @@ -178,30 +180,6 @@ profiles: - `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/) 볼륨 제한이 충족될 수 있는지 확인한다. 익스텐션 포인트: `filter`. - -다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만 -사용할 수 있다. - -- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를 - 선호한다. - Extension points: `score`. -- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를 - 선호한다. - 익스텐션 포인트: `score`. -- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 - 선호한다. - 익스텐션 포인트: `score`. -- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라 - 노드를 필터링하거나 스코어링한다. - 익스텐션 포인트: `Filter`, `Score`. -- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에 - 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 - 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 - 분산하는 것을 선호한다. - 익스텐션 포인트: `preFilter`, `filter`, `score`. -- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 - 노드의 우선 순위를 지정한다. - 익스텐션 포인트: `score`. ### 여러 프로파일 @@ -251,6 +229,186 @@ profiles: 단 하나만 가질 수 있기 때문이다. {{< /note >}} +### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint} + +`kubescheduler.config.k8s.io/v1beta3` 부터, +다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나 +비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다. +이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다. + +`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자. +모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면, +다음과 같은 프로파일 환경 설정을 사용한다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: MyPlugin +``` + +위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과 +동일한 효과를 갖는다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + preScore: + enabled: + - name: MyPlugin + score: + enabled: + - name: MyPlugin + preFilter: + enabled: + - name: MyPlugin + filter: + enabled: + - name: MyPlugin +``` + +여기서 `multiPoint` 를 사용했을 때의 이점은, +추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때, +새로운 익스텐션에 대해서도 `multiPoint` 환경 설정이 자동으로 활성화될 것이라는 점이다. + +`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다. +기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나, +와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다. +다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'MyPlugin' + preScore: + disabled: + - name: '*' + score: + disabled: + - name: '*' +``` + +`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. +그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. +예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고 +각각의 가중치가 `1` 이라고 하자. +이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + score: + enabled: + - name: 'DefaultScore2' + weight: 5 +``` + +이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데, +이는 이 플러그인들이 기본 플러그인이기 때문이다. +그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다. +이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다. +결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다. + +`MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다. +1. 명시된 익스텐션 포인트가 먼저 실행되며, 여기에 명시된 환경 설정은 다른 모든 곳에 설정된 내용보다 우선한다. +2. `MultiPoint` 및 플러그인 설정을 통해 수동으로 구성된 플러그인 +3. 기본 플러그인 및 기본 플러그인의 기본 설정 + +위의 우선 순위를 설명하기 위해, 다음과 같은 예시를 가정한다. +| 플러그인 | 익스텐션 포인트 | +|---|---| +|`DefaultQueueSort`|`QueueSort`| +|`CustomQueueSort`|`QueueSort`| +|`DefaultPlugin1`|`Score`, `Filter`| +|`DefaultPlugin2`|`Score`| +|`CustomPlugin1`|`Score`, `Filter`| +|`CustomPlugin2`|`Score`, `Filter`| + +이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'CustomQueueSort' + - name: 'CustomPlugin1' + weight: 3 + - name: 'CustomPlugin2' + disabled: + - name: 'DefaultQueueSort' + filter: + disabled: + - name: 'DefaultPlugin1' + score: + enabled: + - name: 'DefaultPlugin2' +``` + +명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다. +명시한 익스텐션 포인트의 우선 순위가 더 높으므로, +이 재정의는 무시되고 로그에만 기록된다. + +대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다. +* 커스텀 `queueSort` 플러그인을 활성화하고 기존의 기본 플러그인을 비활성화한다 +* `CustomPlugin1` 과 `CustomPlugin2` 플러그인을 활성화하며, 이 플러그인에 연결된 모든 익스텐션 포인트를 위해 이 플러그인들이 먼저 실행된다 +* `filter` 에 대해서만 `DefaultPlugin1` 을 비활성화한다 +* `score` 에 대해, `DefaultPlugin2` 플러그인이 (심지어 커스텀 플러그인보다도) 가장 먼저 실행되도록 순서를 조정한다 + +`multiPoint` 필드가 없는 `v1beta3` 이전 버전의 환경 설정에서는, 위의 스니펫을 다음과 같이 표현할 수 있다. +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta2 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + + # 기본 QueueSort 플러그인을 비활성화한다 + queueSort: + enabled: + - name: 'CustomQueueSort' + disabled: + - name: 'DefaultQueueSort' + + # 커스텀 Filter 플러그인을 활성화한다 + filter: + enabled: + - name: 'CustomPlugin1' + - name: 'CustomPlugin2' + - name: 'DefaultPlugin2' + disabled: + - name: 'DefaultPlugin1' + + # 커스텀 score 플러그인을 활성화하고 순서를 조정한다 + score: + enabled: + - name: 'DefaultPlugin2' + weight: 1 + - name: 'DefaultPlugin1' + weight: 3 +``` + +다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과 +기존 방법과의 끊김없는 통합을 확인할 수 있다. + ## 스케줄러 설정 전환 {{< tabs name="tab_with_md" >}} @@ -284,8 +442,14 @@ profiles: * v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다. -* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다. +* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port` 가 잘못 설정되면 검증 실패를 유발한다. +{{% /tab %}} +{{% tab name="v1beta2 → v1beta3" %}} +* 세 플러그인의 가중치 기본값이 다음과 같이 증가한다. + * `InterPodAffinity`: 1 에서 2 로 + * `NodeAffinity`: 1 에서 2 로 + * `TaintToleration`: 1 에서 3 으로 {{% /tab %}} {{< /tabs >}} @@ -293,5 +457,5 @@ profiles: * [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 -* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 * [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기 +* [kube-scheduler 설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽어보기 diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 1146ba033a..462b044bff 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -1,102 +1,20 @@ --- title: 스케줄링 정책 content_type: concept -weight: 10 +sitemap: + priority: 0.2 # Scheduling priorities are deprecated --- -스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다. +쿠버네티스 v1.23 이전 버전에서는, *단정(predicates)* 및 *우선순위(priorities)* 프로세스를 지정하기 위해 스케줄링 정책을 사용할 수 있다. +예를 들어, `kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap ` 명령을 실행하여 스케줄링 정책을 설정할 수 있다. -`kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap `을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다. - - - -## 단정 {#predicates} - -다음의 *단정* 은 필터링을 구현한다. - -- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는 - 포트(네트워크 프로토콜 종류)가 있는지 확인한다. - -- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다. - -- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는 - 리소스(예: CPU 및 메모리)가 있는지 확인한다. - -- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 - 노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다. - -- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면 - 파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지 - 평가한다. - -- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해 - 파드가 노드에 적합한지 평가한다. - -- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와 - 구성된 제한을 초과하는지 여부를 결정한다. - -- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이 - 노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다. - -- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다. - 이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와 - 바인딩되지 않은 PVC 모두에 적용된다. - -## 우선순위 {#priorities} - -다음의 *우선순위* 는 스코어링을 구현한다. - -- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}}, - {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는 - {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는 - 파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다. - -- `InterPodAffinityPriority`: 선호된 - [파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다. - -- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉, - 노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가 - 많을수록 이 정책이 부여하는 순위가 낮아진다. - -- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다. - 이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된 - 파드를 맞춘다. - -- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다. - -- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다. - -- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 - 노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가 - 동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다. - -- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링 - 설정에 따라 노드의 우선순위를 지정한다. - 이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다. - -- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로, - 모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을 - 고려하여 노드의 순위를 조정한다. - -- `ImageLocalityPriority`: 해당 파드의 - {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된 - 노드를 선호한다. - -- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한 - 파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한 - 파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는 - 서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다. - -- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다. - -- `EvenPodsSpreadPriority`: 선호된 - [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다. +이러한 스케줄링 정책은 쿠버네티스 v1.23 버전부터 지원되지 않는다. 관련된 플래그인 `policy-config-file`, `policy-configmap`, `policy-configmap-namespace`, `use-legacy-policy-config` 플래그도 지원되지 않는다. 대신, 비슷한 효과를 얻기 위해 [스케줄러 구성](/ko/docs/reference/scheduling/config/)을 사용한다. ## {{% heading "whatsnext" %}} * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 -* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기 +* [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/) 읽어보기 diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index e618bcacc5..6cf9e76a3c 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -49,3 +49,19 @@ Kompose의 용도 * 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환 * 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전 * V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환 + +## Kui + +[`Kui`](https://github.com/kubernetes-sigs/kui)는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 +출력으로 그래픽적인 응답을 제공하는 GUI 도구이다. + +Kui는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 출력으로 그래픽적인 응답을 제공한다. +Kui는 ASCII 표 대신 정렬 가능한 표를 GUI로 제공한다. + +Kui를 사용하면 다음의 작업이 가능하다. + +* 자동으로 생성되어 길이가 긴 리소스 이름을 클릭하여 복사할 수 있다. +* `kubectl` 명령을 입력하면 실행되는 모습을 볼 수 있으며, `kubectl` 보다 더 빠른 경우도 있다. +* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여 + 실행 형상을 워터폴 그림으로 확인한다. +* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다. diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 11d2e793bc..aad89380f6 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -1,5 +1,7 @@ --- title: 클라이언트 라이브러리 + + content_type: concept weight: 30 --- @@ -35,7 +37,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) - ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리 {{% thirdparty-content %}} @@ -70,7 +71,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | diff --git a/content/ko/docs/reference/using-api/health-checks.md b/content/ko/docs/reference/using-api/health-checks.md index d9277c25f9..3e4b113e6d 100644 --- a/content/ko/docs/reference/using-api/health-checks.md +++ b/content/ko/docs/reference/using-api/health-checks.md @@ -1,5 +1,7 @@ --- title: 쿠버네티스 API 헬스(health) 엔드포인트 + + content_type: concept weight: 50 --- @@ -18,11 +20,11 @@ weight: 50 `/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. API 서버의 `healthz`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다. -아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다. +아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다. 다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다. -모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. +모든 엔드포인트에 대해, `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다. ```shell @@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' {{< feature-state state="alpha" >}} -각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다. +각 개별 헬스 체크는 HTTP 엔드포인트를 노출하며 개별적으로 체크할 수 있다. 개별 체크를 위한 스키마는 `/livez/` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. `` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.