Update outdated files in dev-1.23-ko.1 (M13-M16)

Author: seokho-son

content/ko/docs/concepts/extend-kubernetes/_index.md

@@ -77,7 +77,7 @@ no_list: true
 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
 바이너리 플러그인은 kubelet(예:
-[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
+[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
 kubectl에서 사용한다.
 
@@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 
 ### 인가
 
-[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
 
 
 ### 동적 어드미션 컨트롤
@@ -163,6 +163,8 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
 
+FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다.
+
 
 ### 장치 플러그인
 

content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

@@ -37,7 +37,8 @@ _선언적(declarative) API_ 를 제공하게 된다.
 
 쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는
 책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다.
-쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다.
+쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가
+선언한 의도한 상태에 동기화 되도록 한다.
 이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다.
 
 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고
@@ -146,9 +147,9 @@ CRD 오브젝트의 이름은 유효한
 
 일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다.
 
-[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를
+[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를
 작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다.
-기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여
+주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여
 모든 클라이언트가 사용할 수 있게 한다.
 
 ## 커스텀 리소스를 추가할 방법 선택

content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -197,6 +197,8 @@ service PodResourcesLister {
 }
 ```
 
+### `List` gRPC 엔드포인트 {#grpc-endpoint-list}
+
 `List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
 이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
@@ -246,10 +248,35 @@ message ContainerDevices {
     TopologyInfo topology = 3;
 }
 ```
+{{< note >}}
+`List` 엔드포인트의 `ContainerResources` 내부에 있는 cpu_ids은 특정 컨테이너에 할당된
+독점 CPU들에 해당한다. 만약 공유 풀(shared pool)에 있는 CPU들을 확인(evaluate)하는 것이 목적이라면, 해당 `List`
+엔드포인트는 다음에 설명된 것과 같이, `GetAllocatableResources` 엔드포인트와 함께 사용되어야
+한다.
+1. `GetAllocatableResources`를 호출하여 할당 가능한 모든 CPU 목록을 조회
+2. 시스템의 모든 `ContainerResources`에서 `GetCpuIds`를 호출
+3. `GetAllocateableResources` 호출에서 `GetCpuIds` 호출로 얻은 모든 CPU를 빼기
+{{< /note >}}
+
+### `GetAllocatableResources` gRPC 엔드포인트 {#grpc-endpoint-getallocatableresources}
+
+{{< feature-state state="beta" for_k8s_version="v1.23" >}}
 
 GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다.
 kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다.
 
+{{< note >}}
+`GetAllocatableResources`는 [할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스를 확인(evaluate)하기 위해서만 
+사용해야 한다. 만약 목적이 free/unallocated 리소스를 확인하기 위한 것이라면
+List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`로 얻은 결과는 kubelet에
+노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면
+(예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를
+호출할 것으로 가정한다.
+그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는
+충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다.
+{{< /note >}}
+
+
 ```gRPC
 // AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다.
 message AllocatableResourcesResponse {
@@ -259,6 +286,13 @@ message AllocatableResourcesResponse {
 }
 
 ```
+쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다.
+이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
+끄면 된다.
+
+쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다. 
+
+`--feature-gates=KubeletPodResourcesGetAllocatable=true`
 
 `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
 NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은

content/ko/docs/concepts/extend-kubernetes/operator.md

@@ -31,9 +31,7 @@ weight: 30
 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을
 자동화할 수 있다.
 
-쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}
-개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을
-확장할 수 있다.
+쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다.
 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의
 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.