diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index 5c0aa0343b..53af8dbdec 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -14,9 +14,8 @@ hide_summary: true # 섹션의 목차에 별도로 기재
 나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해
 잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다.
 
-일반적으로 {{< glossary_tooltip text="파드" term_id="pod" >}}에서
-참조하기 전에 애플리케이션의 컨테이너 이미지를
-생성해서 레지스트리로 푸시한다.
+일반적으로 컨테이너 이미지는 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 사용되기 전에 
+사용자가 애플리케이션의 컨테이너 이미지를 생성하고 레지스트리로 푸시하는 과정을 거친다.
 
 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
 
@@ -97,7 +96,11 @@ hide_summary: true # 섹션의 목차에 별도로 기재
 `<image-name>:<tag>`를 `<image-name>@<digest>`로 교체한다.
 (예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
 
-이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 다이제스트로 명시하면 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해 준다.
+이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 
+기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 
+이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 
+쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 
+이미지를 다이제스트로 명시하면 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해 준다.
 
 파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 
 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
@@ -137,8 +140,8 @@ hide_summary: true # 섹션의 목차에 별도로 기재
   그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
 - `imagePullPolicy`와 사용할 이미지의 태그를 생략한다.
   그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다.
-- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다.
-
+- [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 
+  어드미션 컨트롤러를 활성화 한다.
 
 ### 이미지풀백오프(ImagePullBackOff)
 
@@ -154,6 +157,48 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
 쿠버네티스는 시간 간격을 늘려가면서 시도를 계속하며, 시간 간격의 상한은 쿠버네티스 코드에 
 300초(5분)로 정해져 있다.
 
+## 순차 및 병렬 이미지 풀
+
+기본적으로, kubelet은 이미지를 순차적으로 풀링한다. 
+다르게 말하면, kubelet은 이미지 서비스에 이미지 풀 요청을 한 번에 하나씩만 보낸다. 
+현재 처리 중인 요청이 완료될 때까지 다른 이미지 풀 요청은 기다려야 한다.
+
+각 노드는 이미지 풀 결정을 독립적으로 수행한다. 
+순차 이미지 풀링을 사용하더라도, 서로 다른 두 노드가 동일한 이미지를 병렬적으로 풀링할 수 있다.
+
+병렬 이미지 풀을 활성화하고 싶다면, [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의 
+`serializeImagePulls` 필드를 false로 설정할 수 있다. 
+`serializeImagePulls` 필드가 false로 설정되어 있으면, 
+이미지 풀 요청이 이미지 서비스로 즉시 전송되며, 여러 이미지가 동시에 풀링될 것이다.
+
+병렬 이미지 풀을 활성화할 때, 
+사용 중인 컨테이너 런타임의 이미지 서비스가 병렬 이미지 풀을 처리할 수 있는지 확인한다.
+
+kubelet은 단일 파드에 대해 여러 이미지를 병렬로 풀링하지는 않을 것이다. 
+예를 들어, 초기화 컨테이너와 애플리케이션 컨테이너로 이루어지는 파드가 있다면, 
+두 컨테이너에 대한 이미지 풀은 병렬로 진행되지 않을 것이다. 
+그러나, 서로 다른 이미지를 사용하는 두 파드가 있고, 병렬 이미지 풀이 활성화되어 있다면, 
+kubelet은 서로 다른 두 파드에 대해 이미지 풀을 병렬로 수행한다. 
+
+### 최대 병렬 이미지 풀
+
+{{< feature-state for_k8s_version="v1.27" state="alpha" >}}
+
+`serializeImagePulls`가 false로 설정되어 있으면, 
+kubelet은 기본적으로는 동시에 풀링할 수 있는 이미지의 수에 제한을 두지 않는다. 
+병렬 이미지 풀 수에 제한을 설정하고 싶으면, 
+kubelet 구성 내의 `maxParallelImagePulls` 필드를 설정할 수 있다. 
+`maxParallelImagePulls`를 _n_ 으로 설정하면, 동시에 _n_ 개의 이미지만 풀링할 수 있으며, 
+이를 초과하는 이미지 풀은 현재 진행 중인 이미지 풀이 완료되기를 기다려야 한다.
+
+병렬 이미지 풀이 활성화되어 있는 경우에, 병렬 이미지 풀의 수를 제한하여 
+이미지 풀 작업이 네트워크 대역폭이나 디스크 입출력을 지나치게 많이 차지하는 것을 방지할 수 있다.
+
+`maxParallelImagePulls`의 값은 1 이상의 양수로 설정할 수 있다. 
+`maxParallelImagePulls`를 2 이상의 값으로 지정했다면, 
+`serializeImagePulls`는 false로 설정해야 한다. 
+`maxParallelImagePulls`가 올바르게 설정되어 있지 않으면 kubelet은 시작에 실패할 것이다.
+
 ## 이미지 인덱스가 있는 다중 아키텍처 이미지
 
 바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 
@@ -163,35 +208,39 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 
 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
 
-쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 
-접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 
-또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다.
+쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 
+이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 
+이에 대한 아이디어는, 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 
+이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 
+`pause-amd64` 라고 하는 이미지를 생성하는 것이다.
 
 ## 프라이빗 레지스트리 사용
 
 프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다.
 자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다.
-  - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
-    - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
-    - 클러스터 관리자에 의한 노드 구성 필요
-  - Kubelet 자격증명 제공자(Credential Provider)를 통해 프라이빗 레지스트리로부터 동적으로 자격증명을 가져오기
-    - kubelet은 특정 프라이빗 레지스트리에 대해 자격증명 제공자 실행 
-      플러그인(credential provider exec plugin)을 사용하도록 설정될 수 있다.
-  - 미리 내려받은(pre-pulled) 이미지
-    - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
-    - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
-  - 파드에 ImagePullSecrets을 명시
-    - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능
-  - 공급 업체별 또는 로컬 확장
-    - 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드
-      제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을
-      구현할 수 있다.
+
+- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
+  - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
+  - 클러스터 관리자에 의한 노드 구성 필요
+- Kubelet 자격증명 제공자(Credential Provider)를 통해 프라이빗 레지스트리로부터 동적으로 자격증명을 가져오기
+  - kubelet은 특정 프라이빗 레지스트리에 대해 자격증명 제공자 실행 
+    플러그인(credential provider exec plugin)을 사용하도록 설정될 수 있다.
+- 미리 내려받은(pre-pulled) 이미지
+  - 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
+  - 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
+- 파드에 ImagePullSecrets을 명시
+  - 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능
+- 공급 업체별 또는 로컬 확장
+  - 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드
+    제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을
+    구현할 수 있다.
 
 이들 옵션은 아래에서 더 자세히 설명한다.
 
 ### 프라이빗 레지스트리에 인증하도록 노드 구성
 
-크리덴셜 설정에 대한 상세 지침은 사용하는 컨테이너 런타임 및 레지스트리에 따라 다르다. 가장 정확한 정보는 솔루션 설명서를 참조해야 한다.
+크리덴셜 설정에 대한 상세 지침은 사용하는 컨테이너 런타임 및 레지스트리에 따라 다르다. 
+가장 정확한 정보는 솔루션 설명서를 참조해야 한다.
 
 프라이빗 컨테이너 이미지 레지스트리 구성 예시를 보려면, 
 [프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다. 
@@ -276,7 +325,6 @@ kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미
 이미지를 풀 해야 한다고 명시하면,
 kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
 
-
 ### 미리 내려받은 이미지 {#pre-pulled-images}
 
 {{< note >}}
@@ -292,7 +340,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
 레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면,
 클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다.
 
-이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.
+이것은 특정 이미지를 속도를 위해 미리 로드하거나 
+프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.
 
 모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다.
 
@@ -314,13 +363,18 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
 
 ```shell
-kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+kubectl create secret docker-registry <name> \
+  --docker-server=DOCKER_REGISTRY_SERVER \
+  --docker-username=DOCKER_USER \
+  --docker-password=DOCKER_PASSWORD \
+  --docker-email=DOCKER_EMAIL
 ```
 
 만약 도커 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고,
 자격 증명 파일을 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}으로
 가져올 수 있다.
-[기존 도커 자격 증명으로 시크릿 생성](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다.
+[기존 도커 자격 증명으로 시크릿 생성](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 
+관련 방법을 설명하고 있다.
 
 `kubectl create secret docker-registry`는
 하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에,
@@ -333,8 +387,9 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER
 
 #### 파드의 imagePullSecrets 참조
 
-이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을
-참조하는 파드를 생성할 수 있다.
+이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 
+해당 시크릿을 참조하는 파드를 생성할 수 있다. `imagePullSecrets` 배열의 각 항목으로는 
+해당 파드와 동일한 네임스페이스에 있는 시크릿만 참조할 수 있다.
 
 예를 들면 다음과 같다.
 
@@ -364,7 +419,8 @@ EOF
 그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 리소스에
 imagePullSecrets을 셋팅하여 자동화할 수 있다.
 
-자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
+자세한 지침을 위해서는 
+[서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
 
 이것은 노드 당 `.docker/config.json`와 함께 사용할 수 있다. 자격 증명은
 병합될 것이다.
@@ -377,7 +433,8 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
 1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다.
    - 퍼블릭 레지스트리의 퍼블릭 이미지를 사용한다.
      - 설정이 필요 없다.
-     - 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다.
+     - 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 
+       가용성이 향상되고 이미지를 가져오는 시간이 줄어든다.
 1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를
    실행하는 클러스터의 경우.
    - 호스트된 프라이빗 레지스트리를 사용한다.
@@ -388,17 +445,33 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
      - 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
    - 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
 1. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
-   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
+   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 
+     그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
    - 민감한 데이터는 이미지 안에 포장하는 대신, "시크릿" 리소스로 이동한다.
 1. 멀티-테넌트 클러스터에서 각 테넌트가 자신의 프라이빗 레지스트리를 필요로 하는 경우.
-   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
+   - [AlwaysPullImages 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)가 활성화되어 있는지 확인한다. 
+     그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
    - 인가가 요구되도록 프라이빗 레지스트리를 실행한다.
-   - 각 테넌트에 대한 레지스트리 자격 증명을 생성하고, 시크릿에 넣고, 각 테넌트 네임스페이스에 시크릿을 채운다.
+   - 각 테넌트에 대한 레지스트리 자격 증명을 생성하고, 시크릿에 넣고, 
+     각 테넌트 네임스페이스에 시크릿을 채운다.
    - 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.
 
-
 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
 
+## 레거시 내장 kubelet 자격 증명 공급자
+
+이전 버전의 Kubernetes에서, kubelet은 클라우드 공급자 자격 증명과 직접 통합되어 있었다. 
+이로 인해 이미지 레지스트리용 자격 증명을 동적으로 가져올 수 있었다.
+
+이러한 kubelet 자격 증명 공급자 통합의 내장 구현은 
+ACR (Azure Container Registry), ECR (Elastic Container Registry), GCR (Google Container Registry) 의 3종이 있었다.
+
+레거시 메카니즘에 대한 더 많은 정보는 현재 사용 중인 쿠버네티스 버전의 문서를 참고한다. 
+쿠버네티스 v1.26부터 v{{< skew latestVersion >}}까지는 레거시 메카니즘를 포함하고 있지 않으므로, 
+다음 중 한 가지 방법을 사용해야 한다.
+- kubelet 이미지 자격 증명 공급자를 각 노드에 대해 구성한다
+- `imagePullSecrets` 및 하나 이상의 시크릿을 사용하여 이미지 풀 자격 증명을 지정한다
+
 ## {{% heading "whatsnext" %}}
 
 * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md
index bf5f306e91..79e0469e1c 100644
--- a/content/ko/docs/concepts/extend-kubernetes/_index.md
+++ b/content/ko/docs/concepts/extend-kubernetes/_index.md
@@ -1,6 +1,6 @@
 ---
 title: 쿠버네티스 확장
-weight: 110
+weight: 999 # 이 섹션이 맨 마지막에 와야 한다
 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
 # reviewers:
 # - erictune
@@ -283,6 +283,20 @@ FlexVolume 스토리지에 의존하는 파드를 실행하는 경우 kubelet은
 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해
 쿠버네티스는 다양한 네트워크 토폴로지 및 기술을 활용할 수 있게 된다.
 
+### kubelet 이미지 자격 증명 공급자 플러그인
+
+{{< feature-state for_k8s_version="v1.26" state="stable" >}}
+kubelet 이미지 자격 증명 공급자는 kubelet이 이미지 레지스트리 자격 증명을 동적으로 가져올 수 있게 하는 플러그인이다. 
+이후, 자격 증명은 구성과 일치하는 컨테이너 이미지 레지스트리에서 
+이미지를 풀링할 때 사용된다.
+
+이러한 플러그인은 외부 서비스와 통신하거나 로컬 파일을 사용하여 자격 증명을 가져올 수 있다. 
+이러한 방법으로, kubelet은 각 레지스트리에 대한 자격 증명을 정적으로 갖고 있지 않아도 되며, 
+다양한 인증 방법 및 프로토콜을 지원할 수 있다.
+
+플러그인의 구성에 대한 상세 사항은 
+[kubelet 이미지 자격 증명 공급자 구성하기](/ko/docs/tasks/administer-cluster/kubelet-credential-provider/)를 참고한다.
+
 ### 스케줄링 익스텐션
 
 스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index b1e4d2a0ae..9f912115a0 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -17,7 +17,7 @@ weight: 10
 ## 커스텀 리소스
 
 *리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의
-[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 
+{{< glossary_tooltip text="API 오브젝트" term_id="object" >}} 모음을 저장하는 엔드포인트이다. 
 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다.
 
 *커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 9cdec7d4de..00fc97a4df 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -28,7 +28,7 @@ kubelet은 `Registration` gRPC 서비스를 노출시킨다.
 
 ```gRPC
 service Registration {
-	rpc Register(RegisterRequest) returns (Empty) {}
+  rpc Register(RegisterRequest) returns (Empty) {}
 }
 ```
 
@@ -87,60 +87,65 @@ spec:
 
 장치 플러그인의 일반적인 워크플로우에는 다음 단계가 포함된다.
 
-* 초기화. 이 단계에서, 장치 플러그인은 공급 업체별 초기화 및 설정을 수행하여
-  장치가 준비 상태에 있는지 확인한다.
+1. 초기화. 이 단계에서, 장치 플러그인은 공급 업체별 초기화 및 설정을 수행하여
+   장치가 준비 상태에 있는지 확인한다.
 
-* 플러그인은 다음의 인터페이스를 구현하는 호스트 경로 `/var/lib/kubelet/device-plugins/`
-  아래에 유닉스 소켓과 함께 gRPC 서비스를 시작한다.
+1. 플러그인은 다음의 인터페이스를 구현하는 호스트 경로 `/var/lib/kubelet/device-plugins/`
+   아래에 유닉스 소켓과 함께 gRPC 서비스를 시작한다.
 
-  ```gRPC
-  service DevicePlugin {
-		    // GetDevicePluginOptions는 장치 관리자와 통신할 옵션을 반환한다.
-        rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
+   ```gRPC
+   service DevicePlugin {
+         // GetDevicePluginOptions는 장치 관리자와 통신할 옵션을 반환한다.
+         rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
 
-    		// ListAndWatch는 장치 목록 스트림을 반환한다.
-		    // 장치 상태가 변경되거나 장치가 사라질 때마다, ListAndWatch는
-		    // 새 목록을 반환한다.
-        rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
+         // ListAndWatch는 장치 목록 스트림을 반환한다.
+         // 장치 상태가 변경되거나 장치가 사라질 때마다, ListAndWatch는
+         // 새 목록을 반환한다.
+         rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
 
-				// 컨테이너를 생성하는 동안 Allocate가 호출되어 장치
-				// 플러그인이 장치별 작업을 실행하고 kubelet에 장치를
-				// 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다.
-        rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
+         // 컨테이너를 생성하는 동안 Allocate가 호출되어 장치
+         // 플러그인이 장치별 작업을 실행하고 kubelet에 장치를
+         // 컨테이너에서 사용할 수 있도록 하는 단계를 지시할 수 있다.
+         rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
 
-        // GetPreferredAllocation은 사용 가능한 장치 목록에서 할당할
-				// 기본 장치 집합을 반환한다. 그 결과로 반환된 선호하는 할당은
-				// devicemanager가 궁극적으로 수행하는 할당이 되는 것을 보장하지
-				// 않는다. 가능한 경우 devicemanager가 정보에 입각한 할당 결정을
-				// 내릴 수 있도록 설계되었다.
-        rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
+         // GetPreferredAllocation은 사용 가능한 장치 목록에서 할당할
+         // 기본 장치 집합을 반환한다. 그 결과로 반환된 선호하는 할당은
+         // devicemanager가 궁극적으로 수행하는 할당이 되는 것을 보장하지
+         // 않는다. 가능한 경우 devicemanager가 정보에 입각한 할당 결정을
+         // 내릴 수 있도록 설계되었다.
+         rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
 
-        // PreStartContainer는 등록 단계에서 장치 플러그인에 의해 표시되면 각 컨테이너가
-				// 시작되기 전에 호출된다. 장치 플러그인은 장치를 컨테이너에서 사용할 수 있도록 하기 전에
-				// 장치 재설정과 같은 장치별 작업을 실행할 수 있다.
-        rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
-  }
-  ```
+         // PreStartContainer는 등록 단계에서 장치 플러그인에 의해 표시되면 각 컨테이너가
+         // 시작되기 전에 호출된다. 장치 플러그인은 장치를 컨테이너에서 사용할 수 있도록 하기 전에
+         // 장치 재설정과 같은 장치별 작업을 실행할 수 있다.
+         rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
+   }
+   ```
 
-  {{< note >}}
-  `GetPreferredAllocation()` 또는 `PreStartContainer()` 에 대한 유용한 구현을
-  제공하기 위해 플러그인이 필요하지 않다. 이러한 호출(있는 경우) 중
-  사용할 수 있는 경우를 나타내는 플래그는 `GetDevicePluginOptions()`
-  호출에 의해 다시 전송된 `DevicePluginOptions` 메시지에 설정되어야 한다. `kubelet` 은
-  항상 `GetDevicePluginOptions()` 를 호출하여 사용할 수 있는
-  선택적 함수를 확인한 후 직접 호출한다.
-  {{< /note >}}
+   {{< note >}}
+   `GetPreferredAllocation()` 또는 `PreStartContainer()` 에 대한 유용한 구현을
+   제공하기 위해 플러그인이 필요하지 않다. 이러한 호출(있는 경우) 중
+   사용할 수 있는 경우를 나타내는 플래그는 `GetDevicePluginOptions()`
+   호출에 의해 다시 전송된 `DevicePluginOptions` 메시지에 설정되어야 한다. `kubelet` 은
+   항상 `GetDevicePluginOptions()` 를 호출하여 사용할 수 있는
+   선택적 함수를 확인한 후 직접 호출한다.
+   {{< /note >}}
 
-* 플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서
-  유닉스 소켓을 통해 kubelet에 직접 등록한다.
+1. 플러그인은 호스트 경로 `/var/lib/kubelet/device-plugins/kubelet.sock` 에서
+   유닉스 소켓을 통해 kubelet에 직접 등록한다.
 
-* 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를
-  모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다.
-  또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은
-  GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다.
-  작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된
-  `AllocateResponse` 를 반환한다. kubelet은 이 정보를
-  컨테이너 런타임에 전달한다.
+   {{< note >}}
+   워크플로우의 순서가 중요하다. 플러그인이 자신을 kubelet에 등록하기 전에 
+   gRPC 서비스를 서빙하고 있어야 등록이 문제 없이 성공한다.
+   {{< /note >}}
+
+1. 성공적으로 등록하고 나면, 장치 플러그인은 서빙(serving) 모드에서 실행되며, 그 동안 플러그인은 장치 상태를
+   모니터링하고 장치 상태 변경 시 kubelet에 다시 보고한다.
+   또한 gRPC 요청 `Allocate` 를 담당한다. `Allocate` 하는 동안, 장치 플러그인은
+   GPU 정리 또는 QRNG 초기화와 같은 장치별 준비를 수행할 수 있다.
+   작업이 성공하면, 장치 플러그인은 할당된 장치에 접근하기 위한 컨테이너 런타임 구성이 포함된
+   `AllocateResponse` 를 반환한다. kubelet은 이 정보를
+   컨테이너 런타임에 전달한다.
 
 ### kubelet 재시작 처리
 
@@ -158,8 +163,7 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 새 k
 장치 플러그인은 특권을 가진 보안 컨텍스트에서 실행해야 한다.
 장치 플러그인을 데몬셋으로 배포하는 경우, 플러그인의
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서
-`/var/lib/kubelet/device-plugins` 를
-{{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
+`/var/lib/kubelet/device-plugins` 를 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
 
 데몬셋 접근 방식을 선택하면 쿠버네티스를 사용하여 장치 플러그인의 파드를 노드에 배치하고,
 장애 후 데몬 파드를 다시 시작하고, 업그레이드를 자동화할 수 있다.
@@ -170,12 +174,14 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 새 k
 해당 기능이 v1.12의 베타 버전으로 올라오면서 이는 필수 요구사항이 아니게 되었다.
 해당 기능이 베타 버전이 된 이후로 API는 버전화되었고 그동안 변하지 않았다.
 그러므로 kubelet 업그레이드를 원활하게 진행할 수 있을 것이지만,
-안정화되기 전까지는 향후 API가 변할 수도 있으므로 업그레이드를 했을 때 절대로 문제가 없을 것이라고는 보장할 수는 없다.
+안정화되기 전까지는 향후 API가 변할 수도 있으므로 
+업그레이드를 했을 때 절대로 문제가 없을 것이라고는 보장할 수는 없다.
 
-{{< caution >}}
+{{< note >}}
 쿠버네티스의 장치 관리자 컴포넌트는 안정화된(GA) 기능이지만 _장치 플러그인 API_는 안정화되지 않았다.
-장치 플러그인 API와 버전 호환성에 대한 정보는 [장치 플러그인 API 버전](/docs/reference/node/device-plugin-api-versions/)를 참고하라.
-{{< /caution >}}
+장치 플러그인 API와 버전 호환성에 대한 정보는 
+[장치 플러그인 API 버전](/docs/reference/node/device-plugin-api-versions/)를 참고하라.
+{{< /note >}}
 
 프로젝트로서, 쿠버네티스는 장치 플러그인 개발자에게 다음 사항을 권장한다.
 
@@ -207,6 +213,7 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고,
 service PodResourcesLister {
     rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
     rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
+    rpc Get(GetPodResourcesRequest) returns (GetPodResourcesResponse) {}
 }
 ```
 
@@ -214,7 +221,16 @@ service PodResourcesLister {
 
 `List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
-이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
+이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 
+또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
+
+쿠버네티스 v1.27부터, `List` 엔드포인트는 `DynamicResourceAllocation` API에 의해 
+`ResourceClaims`에 할당된 실행 중인 파드에 대한 리소스 정보를 제공할 수 있다. 
+이 기능을 활성화하려면 `kubelet`을 실행할 때 다음 플래그를 사용해야 한다.
+
+```
+--feature-gates=DynamicResourceAllocation=true,KubeletPodResourcesDynamiceResources=true
+```
 
 ```gRPC
 // ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
@@ -235,6 +251,7 @@ message ContainerResources {
     repeated ContainerDevices devices = 2;
     repeated int64 cpu_ids = 3;
     repeated ContainerMemory memory = 4;
+    repeated DynamicResource dynamic_resources = 5;
 }
 
 // ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
@@ -260,6 +277,28 @@ message ContainerDevices {
     repeated string device_ids = 2;
     TopologyInfo topology = 3;
 }
+
+// DynamicResource는 동적 리소스 할당에 의해 컨테이너에 할당된 장치에 대한 정보를 포함한다.
+message DynamicResource {
+    string class_name = 1;
+    string claim_name = 2;
+    string claim_namespace = 3;
+    repeated ClaimResource claim_resources = 4;
+}
+
+// ClaimResource는 각 플러그인별 리소스 정보를 포함한다.
+message ClaimResource {
+    repeated CDIDevice cdi_devices = 1 [(gogoproto.customname) = "CDIDevices"];
+}
+
+// CDIDevice는 CDI 장치 정보를 나타낸다.
+message CDIDevice {
+    // Fully qualified CDI device name
+    // for example: vendor.com/gpu=gpudevice1
+    // see more details in the CDI specification:
+    // https://github.com/container-orchestrated-devices/container-device-interface/blob/main/SPEC.md
+    string name = 1;
+}
 ```
 {{< note >}}
 `List` 엔드포인트의 `ContainerResources` 내부에 있는 cpu_ids은 특정 컨테이너에 할당된
@@ -290,7 +329,6 @@ List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`
 충분하지 않으며, kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다.
 {{< /note >}}
 
-
 ```gRPC
 // AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다.
 message AllocatableResourcesResponse {
@@ -312,8 +350,8 @@ message AllocatableResourcesResponse {
 
 `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다.
 NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은
-[kubelet에 등록할 때](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자로-장치-플러그인-통합) 장치 플러그인이 보고하는 것과 일치한다.
-
+[kubelet에 등록할 때](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자로-장치-플러그인-통합) 
+장치 플러그인이 보고하는 것과 일치한다.
 
 gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다.
 장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다.
@@ -323,20 +361,51 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 
 `/var/lib/kubelet/pod-resources` 를
 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.
 
-`PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+`PodResourcesLister service` 를 지원하려면 `KubeletPodResources` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 
 이것은 쿠버네티스 1.15부터 기본으로 활성화되어 있으며, 쿠버네티스 1.20부터는 v1 상태이다.
 
+### `Get` gRPC 엔드포인트 {#grpc-endpoint-get}
+
+{{< feature-state state="alpha" for_k8s_version="v1.27" >}}
+
+`Get` 엔드포인트는 실행 중인 파드의 리소스 정보를 제공한다. 
+이 엔드포인트는 `List` 엔드포인트가 제공하는 것과 비슷한 정보를 노출한다. 
+`Get` 엔드포인트는 실행 중인 파드의 `PodName`과 `PodNamespace`를 필요로 한다.
+
+```gRPC
+// GetPodResourcesRequest는 파드에 대한 정보를 포함한다.
+message GetPodResourcesRequest {
+    string pod_name = 1;
+    string pod_namespace = 2;
+}
+```
+
+이 기능을 활성화하려면 kubelet 서비스를 실행할 때 다음 플래그를 사용해야 한다.
+
+```
+--feature-gates=KubeletPodResourcesGet=true
+```
+
+`Get` 엔드포인트는 동적 리소스 할당 API에 의해 할당된 
+동적 리소스와 관련된 파드 정보를 제공할 수 있다. 
+이 기능을 활성화하려면 kubelet 서비스를 실행할 때 다음 플래그를 사용해야 한다.
+
+```
+--feature-gates=KubeletPodResourcesGet=true,DynamicResourceAllocation=true,KubeletPodResourcesDynamiceResources=true
+```
+
 ## 토폴로지 관리자로 장치 플러그인 통합
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
 토폴로지 관리자는 kubelet 컴포넌트로, 리소스를 토폴로지 정렬 방식으로 조정할 수 있다. 
-이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 확장되었다.
-
+이를 위해, 장치 플러그인 API가 `TopologyInfo` 구조체를 포함하도록 
+확장되었다.
 
 ```gRPC
 message TopologyInfo {
-	repeated NUMANode nodes = 1;
+  repeated NUMANode nodes = 1;
 }
 
 message NUMANode {
@@ -344,8 +413,10 @@ message NUMANode {
 }
 ```
 
-토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다.
-그런 다음 장치 관리자는 이 정보를 사용하여 토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다.
+토폴로지 관리자를 활용하려는 장치 플러그인은 장치 ID 및 장치의 정상 상태와 함께 
+장치 등록의 일부로 채워진 TopologyInfo 구조체를 다시 보낼 수 있다. 
+그런 다음 장치 관리자는 이 정보를 사용하여 
+토폴로지 관리자와 상의하고 리소스 할당 결정을 내린다.
 
 `TopologyInfo` 는 `nodes` 필드에 `nil`(기본값) 또는 NUMA 노드 목록을 설정하는 것을 지원한다.
 이를 통해 복수의 NUMA 노드에 연관된 장치에 대해 장치 플러그인을 설정할 수 있다.
@@ -366,8 +437,10 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 다음은 장치 플러그인 구현의 예이다.
 
 * [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
-* 인텔 GPU, FPGA, QAT, VPU, SGX, DSA, DLB 및 IAA 장치용 [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
-* 하드웨어 지원 가상화를 위한 [KubeVirt 장치 플러그인](https://github.com/kubevirt/kubernetes-device-plugins)
+* 인텔 GPU, FPGA, QAT, VPU, SGX, DSA, DLB 및 IAA 장치용 
+  [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
+* 하드웨어 지원 가상화를 위한 
+  [KubeVirt 장치 플러그인](https://github.com/kubevirt/kubernetes-device-plugins)
 * [컨테이너에 최적화된 OS를 위한 NVIDIA GPU 장치 플러그인](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
 * [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin)
 * [SocketCAN 장치 플러그인](https://github.com/collabora/k8s-socketcan)
@@ -377,8 +450,10 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 
 ## {{% heading "whatsnext" %}}
 
-
-* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
-* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
+* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 
+  알아보기
+* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 
+  배우기
 * [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
-* 쿠버네티스에서 [TLS 인그레스에 하드웨어 가속](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
+* 쿠버네티스에서 [TLS 인그레스에 하드웨어 가속](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 
+  읽기
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index 93ad7a0cf0..7135013c31 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -16,7 +16,8 @@ weight: 10
 사용 중인 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다.
 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 (오픈소스와 클로즈드 소스로) 존재한다.
 
-CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
+CNI 플러그인은 
+[쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
 
 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의 
 CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다. 
@@ -29,17 +30,21 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
 ## 설치
 
 네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 
-특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
+특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 
+CNI 플러그인을 로드하도록 구성되어야 한다.
 
 {{< note >}}
-쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
-이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다.
+쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 
+kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
+이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, 
+CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다.
 
 도커심 제거 후 문제가 발생하는 경우 
 [CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자.
 {{< /note >}}
 
-컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자.
+컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 
+아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자.
 
   - [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
   - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
@@ -49,21 +54,28 @@ CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용
 
 ## 네트워크 플러그인 요구 사항
 
-쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
+쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 
+플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
 iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다.
-예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 
+예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 
+플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 
 `1`로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
-플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
+플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 
+컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
 
 kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며,
-`net/bridge/bridge-nf-call-iptables=1`을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
+`net/bridge/bridge-nf-call-iptables=1`을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 
+iptables 프록시에서 올바르게 작동하도록 한다.
 
 ### 루프백 CNI
 
-쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 
+쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 
+쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 
 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다.
-루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 
-재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91))
+루프백 인터페이스 구현은 
+[CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 
+재사용하거나 자체 코드를 개발하여 수행할 수 있다
+([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)).
 
 ### hostPort 지원
 
@@ -97,7 +109,8 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 
     },
     {
       "type": "portmap",
-      "capabilities": {"portMappings": true}
+      "capabilities": {"portMappings": true},
+      "externalSetMarkChain": "KUBE-MARK-MASQ"
     }
   ]
 }
@@ -112,7 +125,8 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
 플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.
 
 트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
-추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다.
+추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 
+확인한다.
 
 ```json
 {
diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md
index ac1b7e10d4..6c5aac83df 100644
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@@ -119,6 +119,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 * [kubebuilder](https://book.kubebuilder.io/) 사용하기
 * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
+* [Mast](https://docs.ansi.services/mast/user_guide/operator/)
 * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를
   사용하여 직접 구현하기
 * [오퍼레이터 프레임워크](https://operatorframework.io)
diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md
index 82c2048bf1..ed19e5dfd1 100644
--- a/content/ko/docs/concepts/overview/_index.md
+++ b/content/ko/docs/concepts/overview/_index.md
@@ -36,76 +36,105 @@ no_list: true
 ![배포 혁명](/images/docs/Container_Evolution.svg)
 
 **전통적인 배포 시대:**
-초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 
-리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 
-결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. 
+초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 
+한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 
+리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 
+리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 
+결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 
+이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. 
 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었다.
 
-**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 
-가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
+**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 
+이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 
+가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 
+다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.
 
-가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 
-하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 
-가상 머신으로 구성된 클러스터로 만들 수 있다.
+가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 
+쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 
+하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 
+가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.
 
-각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.
+각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 
+모든 구성 요소를 실행하는 하나의 완전한 머신이다.
 
-**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 
-그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다.
-기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
+**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 
+격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 
+그러므로 컨테이너는 가볍다고 여겨진다. 
+VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다.
+기본 인프라와의 종속성을 끊었기 때문에, 
+클라우드나 OS 배포본에 모두 이식할 수 있다.
 
 컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 유명해졌다.
 
-* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적이다.
-* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 
+* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 
+  컨테이너 이미지 생성이 보다 쉽고 효율적이다.
+* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드하여 배포할 수 있고, 
+  (이미지의 불변성 덕에) 빠르고 
   효율적으로 롤백할 수 있다.
-* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 
-  인프라스트럭처에서 분리된다.
-* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
-* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
-* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
+* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 
+  애플리케이션 컨테이너 이미지를 만들기 때문에, 
+  애플리케이션을 인프라스트럭처와 분리하여 개발할 수 있게 된다.
+* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 
+  애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
+* 개발, 테스팅 및 운영 환경에 걸친 일관성: 
+  클라우드에서 구동되는 것과 동일하게 랩탑에서도 구동된다.
+* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 
+  온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
 * 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 
   실행하는 수준으로 추상화 수준이 높아진다.
-* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 
-  보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
+* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 
+  애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 
+  더 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
   * 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
   * 리소스 사용량: 고효율 고집적.
 
 ## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
 
-컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 
-가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 
+컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 
+프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 
+예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 
 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
 
-그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 
-애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다.
+그것이 쿠버네티스가 필요한 이유이다! 
+쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 
+애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 
+예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다.
 
 쿠버네티스는 다음을 제공한다.
 
 * **서비스 디스커버리와 로드 밸런싱**
-  쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 
+  쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 
+  컨테이너에 대한 트래픽이 많으면, 
   쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
 * **스토리지 오케스트레이션**
-쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다
+  쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 
+  원하는 저장소 시스템을 자동으로 탑재할 수 있다
 * **자동화된 롤아웃과 롤백**
-  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 
-  예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
+  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 
+  현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 
+  예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 
+  기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
 * **자동화된 빈 패킹(bin packing)**
-  컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 
-  쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
+  컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 
+  각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 
+  쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
 * **자동화된 복구(self-healing)**
-  쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 
+  쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, 
+  '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 
   서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
 * **시크릿과 구성 관리**
   쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 
-  컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
+  컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 
+  시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
 
 ## 쿠버네티스가 아닌 것
 
 쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다.
-쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 
-로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 
-쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 
+쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, 
+PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 
+사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 
+하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 
+이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 
 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.
 
 쿠버네티스는:
@@ -113,20 +142,26 @@ no_list: true
 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 
   상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 
   애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
-* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 
+* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 
+  지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 
   취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
-* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 
+* 애플리케이션 레벨의 서비스를 제공하지 않는다. 
+  애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 
   데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 
   이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 
   [Open Service Broker](https://openservicebrokerapi.org/)와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
-* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
-* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
-* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
+* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 
+  개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
+* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 
+  선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
+* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 
+  제공하거나 채택하지 않는다.
 * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 
   오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다.
-  반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 
-  의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 
-  사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
+  반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 
+  이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. 
+  A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 
+  이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md
index 4e2319ac9b..f9f33b9aaa 100644
--- a/content/ko/docs/concepts/overview/components.md
+++ b/content/ko/docs/concepts/overview/components.md
@@ -122,10 +122,20 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 [클러스터-레벨 로깅](/ko/docs/concepts/cluster-administration/logging/) 메커니즘은
 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
 
+### 네트워크 플러그인
+
+[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 
+컨테이너 네트워크 인터페이스(Container Network Interface, CNI) 스펙을 구현한 소프트웨어 구성 요소이다. 
+네트워크 플러그인은 파드에 IP주소를 할당하고 클러스터 내의 다른 파드와 통신할 수 있도록 해 준다.
+
 
 ## {{% heading "whatsnext" %}}
 
-* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
-* [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
-* [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기
-* etcd의 공식 [문서](https://etcd.io/docs/) 읽기
+다음에 대해 더 살펴본다.
+   * [노드](/ko/docs/concepts/architecture/nodes/) 및 [노드와 컨트롤 플레인 간의 통신](/ko/docs/concepts/architecture/control-plane-node-communication/).
+   * 쿠버네티스 [컨트롤러](/ko/docs/concepts/architecture/controller/).
+   * 쿠버네티스 기본 스케줄러인 [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/).
+   * etcd의 공식 [문서](https://etcd.io/docs/).
+   * 쿠버네티스의 몇 가지 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/).
+   * [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/)를 사용하여 클라우드 공급자와 연동하기.
+   * [kubectl](/docs/reference/generated/kubectl/kubectl-commands) 명령.
diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md
index 14626f7121..8a76e80ce7 100644
--- a/content/ko/docs/concepts/overview/kubernetes-api.md
+++ b/content/ko/docs/concepts/overview/kubernetes-api.md
@@ -82,13 +82,9 @@ IDL(인터페이스 정의 언어) 파일을 참고한다.
 
 ### OpenAPI V3
 
-{{< feature-state state="beta"  for_k8s_version="v1.24" >}}
+{{< feature-state state="stable"  for_k8s_version="v1.27" >}}
 
-쿠버네티스 {{< param "version" >}} 버전은 OpenAPI v3 API 발행(publishing)에 대한 베타 지원을 제공한다. 
-이는 베타 기능이며 기본적으로 활성화되어 있다.
-kube-apiserver 구성 요소에 
-`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화하여 
-이 베타 기능을 비활성화할 수 있다.
+쿠버네티스는 쿠버네티스 API에 대한 설명을 OpenAPI v3로 발행(publishing)한다.
 
 `/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 
 그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
@@ -153,11 +149,37 @@ kube-apiserver 구성 요소에
   </tbody>
 </table>
 
+OpenAPI V3 가져오기의 Golang 구현은 `k8s.io/client-go/openapi3` 패키지를 확인한다.
+
 ## 지속성
 
 쿠버네티스는 오브젝트의 직렬화된 상태를
 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 저장한다.
 
+## API 디스커버리
+
+클러스터에서 지원하는 모든 그룹 버전의 목록이 
+`/api` 및 `/apis` 엔드포인트에 발행된다. 
+또한 각 그룹 버전은 지원하는 리소스 목록을 `/apis/<group>/<version>`(예: 
+`/apis/rbac.authorization.k8s.io/v1alpha1`)에 노출한다. 
+kubectl은 클러스터가 지원하는 리소스 목록을 가져오는 데에 
+이러한 엔드포인트를 사용한다.
+
+### 합산(aggregated) 디스커버리
+
+{{< feature-state state="beta"  for_k8s_version="v1.27" >}}
+
+쿠버네티스는 클러스터가 지원하는 리소스 정보를 각 그룹 버전별 API로 발행하는 것 대신 
+2개의 엔드포인트(`/api` 및 `/apis`)로 발행하는 
+합산 디스커버리를 베타 수준으로 지원한다. 
+이러한 엔드포인트를 사용하면 일반적인 쿠버네티스 클러스터에 대한 디스커버리 시 
+전송되는 요청의 수를 대폭 줄일 수 있다. 
+이러한 요청은 각 엔드포인트에 요청을 보낼 때 
+Accept 헤더에 다음과 같이 합산 디스커버리임을 나타내면 된다.
+`Accept: application/json;v=v2beta1;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList`.
+
+이 엔드포인트는 ETag 및 protobuf 인코딩도 지원한다.
+
 ## API 그룹과 버전 규칙
 
 필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해,