Merge pull request #31031 from jihoon-seo/211220_Outdated_M55

[ko] Update outdated files in dev-1.23-ko.1 (M55-M61)

Author: k8s-ci-robot

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은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
 이는 클러스터 외부에서 실행되었을 때와는 다른데, 

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)을
-참고한다.
+참고한다.
+
+## 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` 를 설정함으로써 가능하다.

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 <filename>`을 실행하여
 스케줄링 프로파일을 지정할 수 있다.
@@ -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,14 +442,20 @@ 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 >}}
 
 ## {{% heading "whatsnext" %}}
 
 * [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/) 레퍼런스 읽어보기