Merge pull request #35372 from Seo-yul/220725-dev-1.24-ko.2-M44-M50

[ko] Update outdated files dev-1.24-ko.2 (M44-M50)

content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -18,7 +18,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
 {{< /note >}}
 
 {{< warning >}}
-신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. 
+신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다.
 신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다.
 {{< /warning>}}
 
@@ -150,16 +150,16 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
 
 ## 프록시
 
-다음과 같이 kubeconfig 파일에 `proxy-url`을 설정하여 `kubectl`이 프록시를 거치도록 설정할 수 있다.
+다음과 같이 kubeconfig 파일에서 `proxy-url`를 사용하여 `kubectl`이 각 클러스터마다 프록시를 거치도록 설정할 수 있다.
 
 ```yaml
 apiVersion: v1
 kind: Config
 
-proxy-url: https://proxy.host:3128
-
 clusters:
 - cluster:
+    proxy-url: http://proxy.example.org:3128
+    server: https://k8s.example.org/k8s/clusters/c-xxyyzz
   name: development
 
 users:
@@ -168,7 +168,6 @@ users:
 contexts:
 - context:
   name: development
-
 ```
 
 

content/ko/docs/concepts/configuration/secret.md

@@ -247,6 +247,8 @@ API 크리덴셜이 [TokenRequest](/docs/reference/kubernetes-api/authentication
 예를 들어, 영원히 만료되지 않는 토큰이 필요한 경우에 활용할 수 있다. 
 그러나, 이렇게 하기보다는 API 접근에 필요한 토큰을 얻기 위해 
 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 서브리소스를 사용하는 것을 권장한다.
+`TokenRequest` API로부터 토큰을 얻기 위해 
+[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
 {{< /note >}}
 
 #### 특정 경로에 대한 시크릿 키 투영하기
@@ -887,14 +889,29 @@ empty-secret   Opaque   0      2m6s
 
 `kubernetes.io/service-account-token` 시크릿 타입은 
 {{< glossary_tooltip text="서비스 어카운트" term_id="service-account" >}}를 확인하는 
-토큰을 저장하기 위해서 사용한다. 
+토큰 자격증명을 저장하기 위해서 사용한다.
+
+1.22 버전 이후로는 이러한 타입의 시크릿은 더 이상 파드에 자격증명을 마운트하는 데 사용되지 않으며, 
+서비스 어카운트 토큰 시크릿 오브젝트를 사용하는 대신 
+[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 통해 토큰을 얻는 것이 추천된다. 
+`TokenRequest` API에서 얻은 토큰은 제한된 수명을 가지며 다른 API 클라이언트에서 읽을 수 없기 때문에 
+시크릿 오브젝트에 저장된 토큰보다 더 안전하다.
+`TokenRequest` API에서 토큰을 얻기 위해서 
+[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
+
+토큰을 얻기 위한 `TokenRequest` API를 사용할 수 없는 경우에는
+서비스 어카운트 토큰 시크릿 오브젝트를 생성할 수 밖에 없으나,
+이는 만료되지 않는 토큰 자격증명을 읽기 가능한 API 오브젝트로
+지속되는 보안 노출 상황을 감수할 수 있는 경우에만 생성해야 한다.
+
 이 시크릿 타입을 사용할 때는, 
 `kubernetes.io/service-account.name` 어노테이션이 존재하는 
-서비스 어카운트 이름으로 설정되도록 해야 한다. 
+서비스 어카운트 이름으로 설정되도록 해야 한다. 만약 서비스 어카운트와 
-쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 
+시크릿 오브젝트를 모두 생성하는 경우, 서비스 어카운트를 먼저 생성해야만 한다.
+
+시크릿이 생성된 후, 쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 
 `kubernetes.io/service-account.uid` 어노테이션 및 
-`data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채우며, 
+인증 토큰을 보관하고 있는 `data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채운다.
-이들은 인증 토큰을 보관한다.
 
 다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다.
 
@@ -911,17 +928,11 @@ data:
   extra: YmFyCg==
 ```
 
-`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을
+시크릿을 만든 후, 쿠버네티스가 `data` 필드에 `token` 키를 채울 때까지 기다린다.
-생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스
-어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다.
-
-이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나
-기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만
-필요하다면, 이것이 권장되는 워크플로우이다.
 
 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
-또한 파드에서 서비스 어카운트를 참조하는 방법을
+또한 파드에서 서비스 어카운트 자격증명을 참조하는 방법에 대한 정보는 
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
 `automountServiceAccountToken` 필드와 `serviceAccountName`
 필드를 통해 확인할 수 있다.
@@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \
 ```
 
 이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. 
-다음 명령으로 이 새 시크릿에서 `.data.dockercfgjson` 필드를 덤프하고 
+다음 명령으로 이 새 시크릿에서 `.data.dockerconfigjson` 필드를 덤프하고 
 base64로 디코드하면,
 
 ```shell

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

@@ -17,14 +17,14 @@ no_list: true
 
 <!-- overview -->
 
-쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
+쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 쿠버네티스 프로젝트를 
-쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
+포크하거나 코드에 패치를 제출할 필요가 거의 없다.
-거의 없다.
 
 이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
 쿠버네티스 클러스터를 업무 환경의 요구에 맞게
 조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
-잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
+잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 
+쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
 어떤 익스텐션(extension) 포인트와 패턴이 있는지,
 그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다.
 
@@ -32,11 +32,14 @@ no_list: true
 
 ## 개요
 
-사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
+사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 
+포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 
+나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
 
 ## 구성
 
-*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
+*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 
+각 바이너리 별로 문서화되어 있다.
 
 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
@@ -44,9 +47,22 @@ no_list: true
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
 
-호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
+호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 
+플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 
+가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 
+쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 
+시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
 
-[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
+[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), 
+[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), 
+[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 
+역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 
+*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 
+일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 
+선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 
+구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 
+경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 
+사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
 
 ## 익스텐션
 
@@ -70,10 +86,9 @@ no_list: true
 컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
 오브젝트의 `.status`를 업데이트 한다.
 
-컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
+컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때 
-원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
+이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와 
-*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
+마찬가지로 웹훅은 장애 지점을 추가한다.
-추가한다.
 
 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
@@ -95,15 +110,35 @@ kubectl에서 사용한다.
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 ![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
 
-1.   사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
+1.   사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. 
-2.   apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
+   [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 
-3.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+   개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
-4.   쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
-5.   쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
-6.   kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
-7.   kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
 
-어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
+1.   apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 
+   콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 
+   [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
+
+1.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 
+   쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 
+   추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 
+   *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 
+   커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+
+1.   쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 
+   방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
+
+1.   쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 
+   구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
+
+1.   kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 
+   보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 
+   파드 네트워킹 구현이 가능하다.
+
+1.   kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 
+   [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
+
+어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 
+여러 유형의 익스텐션이 포함될 수 있다.
 
 <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
 ![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
@@ -112,60 +147,86 @@ kubectl에서 사용한다.
 
 ### 사용자 정의 유형
 
-새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
+새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 
+`kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 
+쿠버네티스에 커스텀 리소스를 추가하자.
 
 애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
 
-커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
+커스텀 리소스에 대한 자세한 내용은 
+[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
 
 
 ### 새로운 API와 자동화의 결합
 
-사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
+사용자 정의 리소스 API와 컨트롤 루프의 조합을 
+[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 
+특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 
+사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
 
 ### 빌트인 리소스 변경
 
-사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
+사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 
-API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
+새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
+API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 
+접근 익스텐션은 영향을 준다.
 
 
 ### API 접근 익스텐션
 
-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
+요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 
+다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 
+대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 
+참고하길 바란다.
 
 이러한 각 단계는 익스텐션 포인트를 제공한다.
 
-쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
+쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 
+있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 
+확인할 수 있다(웹훅). 이러한 방법은 모두 
+[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
 
 ### 인증
 
-[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
+[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 
-
+요청하는 클라이언트의 사용자 이름에 매핑한다.
-쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
 
+쿠버네티스는 몇 가지 빌트인 인증 방법과 
+필요에 맞지 않는 경우 
+[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
 
 ### 인가
 
-[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
+[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 
-
+사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 
+작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 
+인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 
+통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
 
 ### 동적 어드미션 컨트롤
 
-요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
+요청이 승인된 후, 쓰기 작업인 경우 
+[어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 
+빌트인 단계 외에도 몇 가지 익스텐션이 있다.
 
-*   [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
+* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 
-*   임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
+  컨테이너에서 실행할 수 있는 이미지를 제한한다.
+* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 
+  [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 
+  사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
 
 ## 인프라스트럭처 익스텐션
 
 ### 스토리지 플러그인
 
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
+[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 
-Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
+사용하면 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)에서 찾을 수 있다.
 
+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)에서 
+찾을 수 있다.
 
 ### 장치 플러그인
 
@@ -173,7 +234,6 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
 통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
 발견할 수 있게 해준다.
 
-
 ### 네트워크 플러그인
 
 노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@@ -192,7 +252,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
 
 스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
 파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
-[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
+[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을
 지원한다.
 
 ## {{% heading "whatsnext" %}}

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

@@ -9,7 +9,7 @@ weight: 20
 {{< feature-state for_k8s_version="v1.10" state="beta" >}}
 
 쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는
-[장치 플러그인 프레임워크](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)를
+[장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를
 제공한다.
 
 공급 업체는 쿠버네티스 자체의 코드를 커스터마이징하는 대신, 수동 또는

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

@@ -14,6 +14,8 @@ weight: 10
 쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다. 
 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
 
+CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
+
 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의 
 CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다. 
 쿠버네티스 플러그인은 
@@ -24,26 +26,37 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
 
 ## 설치
 
-CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
+네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
 
-* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
+{{< note >}}
-* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
+쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
+이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다.
+
+dockershim 제거 후 문제가 발생하는 경우 
+[CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자.
+{{< /note >}}
+
+컨테이너 런타임에서 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)
+
+CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다.
 
 ## 네트워크 플러그인 요구 사항
 
-파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
+쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
+iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다.
+예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
+플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
 
 kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
 
-### CNI
+### 루프백 CNI
 
-CNI 플러그인은 Kubelet에 `--network-plugin=cni` 커맨드라인 옵션을 전달하여 선택된다. Kubelet은 `--cni-conf-dir`(기본값은 `/etc/cni/net.d`)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 파드의 네트워크를 설정한다. CNI 구성 파일은 [CNI 명세](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)와 일치해야 하며, 구성에서 참조하는 필수 CNI 플러그인은 `--cni-bin-dir`(기본값은 `/opt/cni/bin`)에 있어야 한다.
+쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 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 구성 파일이 있는 경우, kubelet은 이름별 알파벳 순으로 구성 파일을 사용한다.
+### hostPort 지원
-
-구성 파일에 지정된 CNI 플러그인 외에도, 쿠버네티스는 최소 0.2.0 버전의 표준 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 플러그인이 필요하다.
-
-#### hostPort 지원
 
 CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
 플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다.
@@ -80,7 +93,7 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
 }
 ```
 
-#### 트래픽 셰이핑 지원
+### 트래픽 셰이핑(shaping) 지원
 
 **실험적인 기능입니다**
 
@@ -132,8 +145,4 @@ metadata:
 ...
 ```
 
-## 용법 요약
-
-* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
-
 ## {{% heading "whatsnext" %}}

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

@@ -111,7 +111,9 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 {{% thirdparty-content %}}
 
 * [Charmed Operator Framework](https://juju.is/)
+* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
 * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
+* [kube-rs](https://kube.rs/) (Rust)
 * [kubebuilder](https://book.kubebuilder.io/) 사용하기
 * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)

content/ko/docs/concepts/overview/kubernetes-api.md

@@ -76,7 +76,7 @@ card:
 
 쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
 Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
-자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
+자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) 디자인 제안과
 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
 IDL(인터페이스 정의 언어) 파일을 참고한다.
 

content/ko/docs/concepts/overview/working-with-objects/names.md

@@ -100,4 +100,4 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
 ## {{% heading "whatsnext" %}}
 
 * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
-* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
+* [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기.

content/ko/docs/contribute/_index.md

@@ -18,8 +18,15 @@ card:
 {{< note >}}
 일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은
 [기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다.
+
+또한, 쿠버네티스 기여에 대한 내용은
+{{< glossary_tooltip text="CNCF" term_id="cncf" >}}
+[문서](https://contribute.cncf.io/contributors/projects/#kubernetes)
+를 참고한다.
 {{< /note >}}
 
+---
+
 이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다.
 
 쿠버네티스 문서 기여자들은

content/ko/docs/contribute/advanced.md

@@ -136,7 +136,7 @@ SIG Docs의 공동 의장 역할을 할 수 있다.
 다음과 같은 책임을 가진다.
 
 - SIG Docs가 우수한 문서화를 통해 개발자의 행복을 극대화하는 데 집중한다.
-- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다.
+- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다.
 - 기여에 대한 새로운 지침을 확인하여 SIG에 대한 모범 사례를 배우고 설정한다.
 - SIG 회의를 예약하고 진행한다. 주간 상태 업데이트, 브랜치별 회고/기획 세션과 필요에 따라 그 외 세션을 진행한다.
 - KubeCon 이벤트 및 기타 컨퍼런스에서 문서 스프린트를 스케줄링하고 진행한다.

content/ko/docs/contribute/new-content/open-a-pr.md

@@ -15,13 +15,15 @@ card:
 [새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
 {{< /note >}}
 
-새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
+새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다.
-
+[시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의
-변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
+모든 요구 사항을 준수해야 한다.
-
-변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다.
 
+변경 사항이 적거나, git에 익숙하지 않은 경우,
+[GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
 
+변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고
+컴퓨터에서 로컬로 변경하는 방법을 배운다.
 
 <!-- body -->
 
@@ -61,7 +63,7 @@ class tasks,tasks2 white
 class id1 k8s
 {{</ mermaid >}}
 
-***그림 - GitHub 상에서 PR을 여는 단계***
+그림 - GitHub 상에서 PR을 여는 단계
 
 1.  이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
     페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
@@ -91,7 +93,8 @@ class id1 k8s
     - **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다.
 
     {{< note >}}
-    PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
+    PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다.
+    자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
     {{</ note >}}
 
 7.  **Create pull request** 를 선택한다.
@@ -120,7 +123,8 @@ GitHub 사용자 이름을 코멘트로 남긴다.
 git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
 로컬 포크로 작업한다.
 
-컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
+컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다.
+git UI 애플리케이션을 사용할 수도 있다.
 
 아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
 
@@ -151,7 +155,8 @@ class 1,2,3,3a,4,5,6 grey
 class S,T spacewhite
 class changes,changes2 white
 {{</ mermaid >}}
-***그림 - 로컬 포크에서 변경 사항 작업하기***
+
+그림 - 로컬 포크에서 변경 사항 작업하기
 
 ### kubernetes/website 리포지터리 포크하기
 
@@ -201,7 +206,10 @@ class changes,changes2 white
     이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
 
     {{< note >}}
-    이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
+    이 워크플로는
+    [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)
+    와 다르다.
+    포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
     {{< /note >}}
 
 ### 브랜치 만들기
@@ -211,14 +219,16 @@ class changes,changes2 white
   - 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
   - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
   - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
-  - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
+  - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다.
+     자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
   - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
     해당 작업을 위해 작성된 특정 기능 브랜치를
     사용한다.
 
     브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
 
-2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
+2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다.
+   이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
 
     ```bash
     git checkout -b <my_new_branch> upstream/main
@@ -268,7 +278,8 @@ class changes,changes2 white
     ```
 
     {{< note >}}
-    커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할
+    커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자.
+    나중에 풀 리퀘스트 설명에 추가할
     수 있다.
     {{< /note >}}
 
@@ -280,39 +291,34 @@ class changes,changes2 white
 
 ### 로컬에서 변경 사항 미리보기 {#preview-locally}
 
-변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
+변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다.
+미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
 
-website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
+website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다.
+도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로,
+디버깅에 유용할 수 있다.
 
 {{< tabs name="tab_with_hugo" >}}
 {{% tab name="Hugo 컨테이너" %}}
 
 {{< note >}}
-아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
+아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다.
+이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
 {{< /note >}}
 
 1.  로컬에서 이미지를 빌드한다.
+    _Hugo 도구 자체에 대한 변경을 테스트하는 경우에만 이 단계가 필요하다._
 
-      ```bash
+      ```shell
-      # docker 사용(기본값)
+      # 터미널에서 명령 실행 (필요에 따라)
-      make container-image
+      make container-serve
-
-      ### 또는 ###
-
-      # podman 사용
-      CONTAINER_ENGINE=podman make container-image
       ```
 
-2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
+2.  컨테이너에서 Hugo를 시작한다.
 
-      ```bash
+      ```shell
-      # docker 사용(기본값)
+      # 터미널에서 실행
       make container-serve
-
-      ### 또는 ###
-
-      # podman 사용
-      CONTAINER_ENGINE=podman make container-serve
       ```
 
 3.  웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는
@@ -326,18 +332,19 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 
 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
 
-1.  [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
+1.  [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된
+    [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
 
 2.  website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
-테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
+    테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
 
-    ```bash
+    ```shell
     git submodule update --init --recursive --depth 1
     ```
 
 3.  터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
 
-      ```bash
+      ```shell
       cd <path_to_your_repo>/website
       hugo server --buildFuture
       ```
@@ -354,6 +361,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 ### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
 
 아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
+
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 
@@ -379,7 +387,8 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b
 class 1,2,3,4,5,6,7,8 grey
 class first,second white
 {{</ mermaid >}}
-***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
+
+그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계
 
 1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
 2. **New Pull Request** 를 선택한다.
@@ -387,29 +396,36 @@ class first,second white
 4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다.
 5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다.
 6. **Create Pull Request** 를 선택한다.
-7. 풀 리퀘스트에 대한 설명을 추가한다.
+`. 풀 리퀘스트에 대한 설명을 추가한다.
+
     - **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다.
     - **Description**: 변경 사항을 자세히 설명한다.
-      - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
-      - 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
 
-8. **Create pull request** 버튼을 선택한다.
+      - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다.
+        이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다.
+        다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
+      - 구체적인 내용에 대한 조언이 필요한 경우,
+        원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
+
+7. **Create pull request** 버튼을 선택한다.
 
 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
 
-
+PR을 연 후, GitHub는 자동 테스트를 실행하고
-PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
+[Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
 
   - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다.
-  - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
+  - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기
+    직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
 
-또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
+또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다.
+자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
 
 ### 로컬에서 피드백 해결
 
 1. 변경한 후, 이전 커밋을 수정한다.
 
-    ```bash
+    ```shell
     git commit -a --amend
     ```
 
@@ -421,7 +437,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 3. `git push origin <my_new_branch>` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다.
 
     {{< note >}}
-      수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
+    수정하는 대신 `git commit -m` 을 사용하는 경우,
+    병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
     {{< /note >}}
 
 #### 리뷰어의 변경
@@ -430,35 +447,38 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 
 1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다.
 
-    ```bash
+    ```shell
     git fetch origin
     git rebase origin/<your-branch-name>
     ```
 
 2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다.
 
-    ```bash
+    ```shell
     git push --force-with-lease origin <your-branch-name>
     ```
 
 #### 충돌 병합 및 리베이스
 
 {{< note >}}
-자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
+자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts),
+[고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나,
+슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
 {{< /note >}}
 
-다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다.
+다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다.
+PR의 모든 병합 충돌을 해결해야 한다.
 
 1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다.
 
-    ```bash
+    ```shell
     git fetch origin
     git rebase origin/<your-branch-name>
     ```
 
     그런 다음 포크에 변경 사항을 강제로 푸시한다.
 
-    ```bash
+    ```shell
     git push --force-with-lease origin <your-branch-name>
     ```
 
@@ -477,7 +497,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 
   이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다.
 
-4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다.
+4. 충돌한 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다.
+   충돌을 해결하고 충돌 마커를 삭제한다.
 
     {{< note >}}
     자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다.
@@ -485,12 +506,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 
 5. 변경 세트에 파일을 추가한다.
 
-    ```bash
+    ```shell
     git add <filename>
     ```
+
 6.  리베이스를 계속한다.
 
-    ```bash
+    ```shell
     git rebase --continue
     ```
 
@@ -500,7 +522,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 
 8. 브랜치를 포크에 강제로 푸시한다.
 
-    ```bash
+    ```shell
     git push --force-with-lease origin <your-branch-name>
     ```
 
@@ -509,10 +531,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
 ### 커밋 스쿼시하기
 
 {{< note >}}
-자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
+자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나,
+슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
 {{< /note >}}
 
-PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다.
+PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다.
+PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여
+커밋 수를 확인할 수 있다.
 
 {{< note >}}
 여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다.
@@ -520,15 +545,16 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
 
 1. 대화식 리베이스를 시작한다.
 
-    ```bash
+    ```shell
     git rebase -i HEAD~<number_of_commits_in_branch>
     ```
 
-    커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
+    커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다.
+    `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
 
     출력은 다음과 비슷하다.
 
-    ```bash
+    ```none
     pick d875112ca Original commit
     pick 4fa167b80 Address feedback 1
     pick 7d54e15ee Address feedback 2
@@ -540,7 +566,9 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
     # 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다.
     ```
 
-    출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
+    출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다.
+    두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다.
+    `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
 
     리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다.
 
@@ -552,7 +580,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
 
     다음의 원본 텍스트를 변경한다.
 
-    ```bash
+    ```none
     pick d875112ca Original commit
     pick 4fa167b80 Address feedback 1
     pick 7d54e15ee Address feedback 2
@@ -560,13 +588,14 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
 
     아래와 같이 변경한다.
 
-    ```bash
+    ```none
     pick d875112ca Original commit
     squash 4fa167b80 Address feedback 1
     squash 7d54e15ee Address feedback 2
     ```
 
-    이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
+    이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다.
+    타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
 
 3. 파일을 저장하고 종료한다.
 
@@ -578,14 +607,15 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
 
 ## 다른 리포지터리에 기여하기
 
-[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다.
+[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다.
+이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스
+또는 코드 주석과 같은 문서가 포함되어 있다.
 
 개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다.
 이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다.
 
-각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를
+각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 제기하거나 PR을 제출하기 전에,
-제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고
+그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 `code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
-`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
 
 대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한
 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때

content/ko/docs/contribute/participate/_index.md

@@ -93,9 +93,8 @@ PR 소유자에게 조언하는데 활용된다.
 
 ## 병합 작업 방식
 
-풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
+풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다.
-브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의
+게시된 콘텐츠의 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
-품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
 작동 방식은 다음과 같다.
 
 - 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,

content/ko/docs/contribute/participate/roles-and-responsibilities.md

@@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 - [슬랙](https://slack.k8s.io/) 또는
   [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
 
-[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
+[CLA에 서명](https://github.com/kubernetes/community/blob/master/CLA.md) 후에 누구나 다음을 할 수 있다.
 
 - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
 - 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.

content/ko/docs/contribute/review/for-approvers.md

@@ -181,7 +181,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의
 
 ### 블로그 이슈
 
-[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라
+[쿠버네티스 블로그](/blog/) 항목은 시간이 지남에 따라
 구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다.
 1년이 지난 블로그 항목과 관련된 이슈일 경우,
 수정하지 않고 이슈를 닫는다.
@@ -221,3 +221,5 @@ https://github.com/kubernetes/kubernetes 에서
 
 문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
 ```
+
+

content/ko/docs/reference/access-authn-authz/authorization.md

@@ -96,7 +96,7 @@ DELETE    | delete(개별 리소스), deletecollection(리소스 모음)
 
 #### API 접근 확인
 
-`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
+`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 `auth can-i` 하위 명령어를 제공한다.
 이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며,
 사용되는 인가 모드에 관계없이 작동한다.
 

content/ko/docs/setup/_index.md

@@ -27,6 +27,13 @@ card:
 [쿠버네티스를 다운로드](/releases/download/)하여 
 로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.
 
+`kube-apiserver`나 `kube-proxy`와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은
+클러스터 내에서 [컨테이너 이미지](/releases/download/#container-images)를 통해 배포할 수 있다.
+
+쿠버네티스 컴포넌트들은 가급적 컨테이너 이미지로 실행하는 것을 **추천**하며,
+이를 통해 쿠버네티스가 해당 컴포넌트들을 관리하도록 한다.
+컨테이너를 구동하는 컴포넌트(특히 kubelet)는 여기에 속하지 않는다.
+
 쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 
 같은 매니지드 서비스를 선택할 수도 있다.
 광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 
@@ -60,4 +67,5 @@ card:
 쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 
 리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 
 다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
-- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.
+
+- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/concepts/windows/)를 살펴본다.

content/ko/docs/setup/best-practices/certificates.md

@@ -23,7 +23,7 @@ weight: 40
 
 * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
 * API 서버가 kubelet과 통신하기 위한 
-  kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
+  kubelet [서버 인증서](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)
 * API 서버 엔드포인트를 위한 서버 인증서
 * API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
 * API 서버에서 kubelet과 통신을 위한 클라이언트 인증서

content/ko/docs/setup/production-environment/_index.md

@@ -28,29 +28,29 @@ no_list: true
 다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다.
 
 - *가용성*: 단일 머신 쿠버네티스 [학습 환경](/ko/docs/setup/#학습-환경)은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다.
-고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다.
+  고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다.
   - 컨트롤 플레인과 워크 노드를 분리
   - 컨트롤 플레인 구성요소를 여러 노드에 복제
   - 클러스터의 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}로 가는 트래픽을 로드밸런싱
   - 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장
 
 - *스케일링*: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의 
-일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 
+  일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 
-마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 
+  마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 
-계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, 
+  계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, 
-컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 
+  컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 
-잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다.
+  잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다.
 
 - *보안 및 접근 관리*: 학습을 위한 쿠버네티스 클러스터에는 
-완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 
+  완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 
-두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 
+  두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 
-접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다.
+  접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다.
-역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 
+  역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 
-기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 
+  기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 
-액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. 
+  액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. 
-[정책](/ko/docs/concepts/policy/)과 
+  [정책](/ko/docs/concepts/policy/)과 
-[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 
+  [컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 
-관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.
+  관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.
 
 쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 
 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 
@@ -59,16 +59,16 @@ no_list: true
 다음과 같은 옵션이 있다.
 
 - *서버리스*: 클러스터를 전혀 관리하지 않고 
-타사 장비에서 워크로드를 실행하기만 하면 된다. 
+  타사 장비에서 워크로드를 실행하기만 하면 된다. 
-CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다.
+  CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다.
 - *관리형 컨트롤 플레인*: 쿠버네티스 서비스 공급자가 
-클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다.
+  클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다.
 - *관리형 워커 노드*: 필요에 맞는 노드 풀을 정의하면, 
-쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 
+  쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 
-필요 시 업그레이드 제공을 보장한다.
+  필요 시 업그레이드 제공을 보장한다.
 - *통합*: 쿠버네티스를 스토리지, 컨테이너 레지스트리, 
-인증 방법 및 개발 도구와 같이 
+  인증 방법 및 개발 도구와 같이 
-사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다.
+  사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다.
 
 프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든, 
 요구 사항이 *컨트롤 플레인*, *워커 노드*, 
@@ -99,52 +99,52 @@ CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금
 다음 사항들을 고려한다.
 
 - *배포 도구 선택*: kubeadm, kops, kubespray와 같은 도구를 이용해 
-컨트롤 플레인을 배포할 수 있다. 
+  컨트롤 플레인을 배포할 수 있다. 
-[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 
+  [배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 
-여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. 
+  여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. 
-배포 시, 다양한 
+  배포 시, 다양한 
-[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다.
+  [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다.
 - *인증서 관리*: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다. 
-인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. 
+  인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. 
-[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 
+  [PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 
-상세 사항을 확인한다.
+  상세 사항을 확인한다.
 - *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에 
-외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. 
+  외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. 
-[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 
+  [외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 
-상세 사항을 확인한다.
+  상세 사항을 확인한다.
 - *etcd 서비스 분리 및 백업*: etcd 서비스는 
-다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, 
+  다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, 
-또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. 
+  또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. 
-etcd는 클러스터 구성 데이터를 저장하므로 
+  etcd는 클러스터 구성 데이터를 저장하므로 
-필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다.
+  필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다.
-[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다.
+  [etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다.
-[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 
+  [쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 
-[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 
+  [kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 
-상세 사항을 확인한다.
+  상세 사항을 확인한다.
 - *다중 컨트롤 플레인 시스템 구성*: 고가용성을 위해, 
-컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. 
+  컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. 
-컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, 
+  컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, 
-각 서비스는 최소 3대의 머신에서 실행되어야 한다. 
+  각 서비스는 최소 3대의 머신에서 실행되어야 한다. 
-그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 
+  그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 
-각 서비스 복제본 요청이 보장된다. 
+  각 서비스 복제본 요청이 보장된다. 
-스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다.
+  스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다.
-일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 
+  일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 
-[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. 
+  [Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. 
-리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다.
+  리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다.
 - *다중 영역(zone)으로 확장*: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면 
-여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 
+  여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 
-클러스터를 만드는 것이 좋다. 
+  클러스터를 만드는 것이 좋다. 
-영역의 그룹을 지역(region)이라고 한다.
+  영역의 그룹을 지역(region)이라고 한다.
-동일한 지역의 여러 영역에 클러스터를 분산하면 
+  동일한 지역의 여러 영역에 클러스터를 분산하면 
-하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. 
+  하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다.
-[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다.
+  [여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다.
 - *구동 중인 기능 관리*: 클러스터를 계속 유지하려면, 
-상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. 
+  상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. 
-예를 들어 kubeadm으로 클러스터를 생성한 경우, 
+  예를 들어 kubeadm으로 클러스터를 생성한 경우, 
-[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 
+  [인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 
-[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다.
+  [kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다.
-[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 
+  [클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 
-더 많은 쿠버네티스 관리 작업을 볼 수 있다.
+  더 많은 쿠버네티스 관리 작업을 볼 수 있다.
 
 컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면, 
 [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
@@ -166,39 +166,36 @@ etcd 백업 계획을 세우려면
 워커 노드(간단히 *노드*라고도 함)를 어떤 방법으로 관리할지 고려해야 한다.
 
 - *노드 구성하기*: 노드는 물리적 또는 가상 머신일 수 있다. 
-직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 
+  직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 
-적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다.
+  적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다.
-다음을 고려해야 한다.
+  다음을 고려해야 한다.
   - 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성)
   - 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지
 - *노드 검증하기*: [노드 구성 검증하기](/ko/docs/setup/best-practices/node-conformance/)에서 
-노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 
+  노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 
-만족하는지 확인하는 방법을 알아본다.
+  만족하는지 확인하는 방법을 알아본다.
 - *클러스터에 노드 추가하기*: 클러스터를 자체적으로 관리하는 경우, 
-머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 
+  머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 
-또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. 
+  또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. 
-이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다.
+  이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다.
-- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를 
-실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. 
-[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다.
 - *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼 
-확장하는 것에 대한 계획이 있어야 한다. 
+  확장하는 것에 대한 계획이 있어야 한다. 
-실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 
+  실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 
-[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. 
+  [대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. 
-만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다.
+  만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다.
 - *노드 자동 스케일링*: 대부분의 클라우드 공급자는 
-비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 
+  비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 
-[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. 
+  [클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. 
-[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 
+  [자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 
-오토스케일러가 어떻게 동작하는지, 
+  오토스케일러가 어떻게 동작하는지, 
-[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 
+  [배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 
-각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. 
+  각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. 
-온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 
+  온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 
-스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
+  스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
 - *노드 헬스 체크 구성*: 중요한 워크로드의 경우, 
-해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. 
+  해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. 
-[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) 
+  [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) 
-데몬을 사용하면 노드가 정상인지 확인할 수 있다.
+  데몬을 사용하면 노드가 정상인지 확인할 수 있다.
 
 ## 프로덕션 사용자 관리
 
@@ -215,39 +212,51 @@ etcd 백업 계획을 세우려면
 다음과 같은 전략을 선택해야 한다.
 
 - *인증*: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는 
-HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다.
+  HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다.
-사용자는 인증 방법을 선택하여 사용할 수 있다.
+  사용자는 인증 방법을 선택하여 사용할 수 있다.
-apiserver는 또한 플러그인을 사용하여 
+  apiserver는 또한 플러그인을 사용하여 
-LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다.
+  LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다.
-쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 
+  쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 
-[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다.
+  [인증](/docs/reference/access-authn-authz/authentication/)을 참조한다.
-- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다.
+- *인가*: 일반 사용자 인가를 위해,
-  - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다.
+  RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서
-  - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
+  사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를
+  확인할 수 있다.
+  - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 
+    특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다.
+    특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다.
+    그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을
+    특정 사용자에게 연결할 수 있다.
+  - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의
+    리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다.
+    정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류),
+    그리고 '대상(사용자 또는 그룹)', '리소스 속성',
+    '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다.
+    자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다.
 
 프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다.
 
-- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, 
+- *인가 모드 설정*: 쿠버네티스 API 서버
-*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다.
+  ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, 
-예를 들어, (*`/etc/kubernetes/manifests`*에 있는) 
+  *`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다.
-*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. 
+  예를 들어, *`kube-adminserver.yaml`* 파일(*`/etc/kubernetes/manifests`*에 있는) 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. 
-이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
+  이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
 - *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우, 
-사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. 
+  사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. 
-그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다.
+  그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다.
-자세한 내용은 
+  자세한 내용은 
-[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다.
+  [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다.
 - *속성을 포함하는 정책 생성(ABAC을 사용하는 경우)*: ABAC 인증을 사용하는 경우, 
-속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 
+  속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 
-특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. 
+  특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. 
-[예시](/docs/reference/access-authn-authz/abac/#examples)에서 
+  [예시](/docs/reference/access-authn-authz/abac/#examples)에서
-더 많은 정보를 확인한다.
+  더 많은 정보를 확인한다.
 - *어드미션 컨트롤러 도입 고려*: 
-[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 
+  [웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 
-API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. 
+  API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. 
-웹훅 및 다른 인가 형식을 사용하려면 API 서버에 
+  웹훅 및 다른 인가 형식을 사용하려면 API 서버에 
-[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 
+  [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 
-추가해야 한다.
+  추가해야 한다.
 
 ## 워크로드에 자원 제한 걸기
 
@@ -256,38 +265,44 @@ API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추
 워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다.
 
 - *네임스페이스 제한 설정*: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다. 
-[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 
+  [메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 
-상세 사항을 확인한다. 
+  상세 사항을 확인한다. 
-[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 
+  [계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 
-제한을 상속할 수도 있다.
+  제한을 상속할 수도 있다.
 - *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면, 
-DNS 서비스도 확장할 준비가 되어 있어야 한다. 
+  DNS 서비스도 확장할 준비가 되어 있어야 한다. 
-[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다.
+  [클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다.
 - *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, 
-서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. 
+  서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. 
-기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다.
+  기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다.
-[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 
+  [서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 
-새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
+  새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
-  - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다.
+  - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다.
-  - 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다.
+    [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서
+    예시를 확인한다.
+  - 서비스 어카운트에 RBAC 권한을 할당한다.
+    [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서
+    상세 사항을 확인한다.
 
 ## {{% heading "whatsnext" %}}
 
 - 프로덕션 쿠버네티스를 직접 구축할지, 
-아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 
+  아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 
-[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다.
+  [쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다.
 - 클러스터를 직접 구축한다면, 
-[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, 
+  [인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, 
-[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 
+  [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 
-[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) 
+  [API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) 
-등의 기능에 대한 고가용성을 
+  등의 기능에 대한 고가용성을 
-어떻게 보장할지를 계획한다.
+  어떻게 보장할지를 계획한다.
-- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 
+- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/),
-하나를 선택한다.
+  [kops](/ko/docs/setup/production-environment/tools/kops/),
+  [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 
+  하나를 선택한다.
 - [인증](/docs/reference/access-authn-authz/authentication/) 및 
-[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 
+  [인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 
-사용자 관리 방법을 구성한다.
+  사용자 관리 방법을 구성한다.
 - [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/), 
-[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), 
+  [DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), 
-[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 
+  [서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 
-애플리케이션 워크로드의 실행에 대비한다.
+  애플리케이션 워크로드의 실행에 대비한다.

content/ko/docs/setup/production-environment/container-runtimes.md

@@ -36,7 +36,7 @@ _dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접
 더 이상 쿠버네티스에 포함되지 않는다(이 제거는 
 v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). 
 이 제거가 어떻게 영향을 미치는지 알아보려면 
-[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. 
+[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. 
 dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, 
 [dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
 
@@ -46,6 +46,41 @@ v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고
 
 
 <!-- body -->
+## 필수 요소들 설치 및 구성하기
+
+다음 단계에서는 리눅스의 쿠버네티스 노드를 위한 일반적인 설정들을 적용한다.
+
+만약 필요하지 않다고 생각한다면 몇몇 설정들은 넘어가도 무방하다.
+
+더 자세한 정보는, [네트워크 플러그인 요구사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)이나 각자 사용 중인 컨테이너 런타임에 해당하는 문서를 확인한다.
+
+### IPv4를 포워딩하여 iptables가 브리지된 트래픽을 보게 하기
+
+`lsmod | grep br_netfilter`를 실행하여 `br_netfilter` 모듈이 로드되었는지 확인한다.
+
+명시적으로 로드하려면, `sudo modprobe br_netfilter`를 실행한다.
+
+리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables`가 1로 설정되어 있는지 확인한다. 예를 들어,
+
+```bash
+cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
+overlay
+br_netfilter
+EOF
+
+sudo modprobe overlay
+sudo modprobe br_netfilter
+
+# 필요한 sysctl 파라미터를 설정하면, 재부팅 후에도 값이 유지된다.
+cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
+net.bridge.bridge-nf-call-iptables  = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+net.ipv4.ip_forward                 = 1
+EOF
+
+# 재부팅하지 않고 sysctl 파라미터 적용하기
+sudo sysctl --system
+```
 
 ## cgroup 드라이버
 
@@ -132,45 +167,22 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
 
 {{% thirdparty-content %}}
 
-
 ### containerd
 
 이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다.
 
 다음 명령을 사용하여 시스템에 containerd를 설치한다.
 
-1. 필수 구성 요소를 설치 및 구성한다.
+[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)의 지침에 따라, 유효한 환경 설정 파일(`config.toml`)을 생성한다.
 
-   (이 지침은 리눅스 노드에만 적용된다)
+{{< tabs name="Finding your config.toml file" >}}
-
+{{% tab name="Linux" %}}
-   ```shell
+`/etc/containerd/config.toml` 경로에서 파일을 찾을 수 있음.
-   cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
+{{% /tab %}}
-   overlay
+{{< tab name="Windows" >}}
-   br_netfilter
+`C:\Program Files\containerd\config.toml` 경로에서 파일을 찾을 수 있음.
-   EOF
+{{< /tab >}}
-
+{{< /tabs >}}
-   sudo modprobe overlay
-   sudo modprobe br_netfilter
-
-   # 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
-   cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
-   net.bridge.bridge-nf-call-iptables  = 1
-   net.ipv4.ip_forward                 = 1
-   net.bridge.bridge-nf-call-ip6tables = 1
-   EOF
-
-   # 재부팅하지 않고 sysctl 파라미터 적용
-   sudo sysctl --system
-   ```
-
-1. containerd를 설치한다.
-
-   [containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) 
-   문서를 확인하고, 
-   유효한 환경 설정 파일(`config.toml`)을 작성하는 부분까지의 
-   가이드를 따른다. 
-   리눅스에서, 이 파일은 `/etc/containerd/config.toml`에 존재한다. 
-   윈도우에서, 이 파일은 `C:\Program Files\containerd\config.toml`에 존재한다.
 
 리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다.
 윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다.
@@ -185,6 +197,14 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
     SystemdCgroup = true
 ```
+{{< note >}}
+만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면,
+CRI integration 플러그인은 기본적으로 비활성화되어 있다.
+
+쿠버네티스에서 containerd를 사용하기 위해서는 CRI support가 활성화되어 있어야 한다.
+`cri`가 `/etc/containerd/config.toml` 파일 안에 있는 `disabled_plugins` 목록에 포함되지 않도록 주의하자.
+만약 해당 파일을 변경하였다면, `containerd`를 다시 시작한다.
+{{< /note >}}
 
 이 변경 사항을 적용하려면, containerd를 재시작한다.
 
@@ -193,7 +213,19 @@ sudo systemctl restart containerd
 ```
 
 kubeadm을 사용하는 경우,
-[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다.
+[kubelet용 cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver)를 수동으로 구성한다.
+
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd}
+
+[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서
+아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
+
+```toml
+[plugins."io.containerd.grpc.v1.cri"]
+  sandbox_image = "k8s.gcr.io/pause:3.2"
+```
+
+설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다.
 
 ### CRI-O
 
@@ -221,6 +253,19 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
 
 CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-o}
+
+[CRI-O 설정](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md)에서
+아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
+
+```toml
+[crio.image]
+pause_image="registry.k8s.io/pause:3.6"
+```
+
+이 옵션은 `systemctl reload crio` 혹은 `crio` 프로세스에 `SIGHUP`을 보내 변경사항을 적용하기 위한
+live configuration reload 기능을 지원한다.
+
 ### 도커 엔진 {#docker}
 
 {{< note >}}
@@ -237,6 +282,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 
 `cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd}
+
+`cri-dockerd` 어댑터는, 
+파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
+해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
+
 ### 미란티스 컨테이너 런타임 {#mcr}
 
 [미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 
@@ -251,6 +302,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
 CRI 소켓의 경로를 찾으려면 
 `cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
 
+#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr}
+
+`cri-dockerd` 어댑터는, 
+파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
+해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
+
 ## {{% heading "whatsnext" %}}
 
 컨테이너 런타임과 더불어, 클러스터에는 

content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md

@@ -45,26 +45,6 @@ card:
 네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는
 경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다.
 
-## iptables가 브리지된 트래픽을 보게 하기
-
-`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다.
-
-리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다.
-
-```bash
-cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
-br_netfilter
-EOF
-
-cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
-net.bridge.bridge-nf-call-ip6tables = 1
-net.bridge.bridge-nf-call-iptables = 1
-EOF
-sudo sysctl --system
-```
-
-자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다.
-
 ## 필수 포트 확인 {#check-required-ports}
 [필수 포트들](/ko/docs/reference/ports-and-protocols/)은
 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
@@ -74,7 +54,7 @@ sudo sysctl --system
 nc 127.0.0.1 6443
 ```
 
-사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
+사용자가 사용하는 파드 네트워크 플러그인은 특정 포트를 열어야 할 수도
 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
 플러그인 문서를 참고한다.
 
@@ -202,7 +182,6 @@ name=Kubernetes
 baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
 enabled=1
 gpgcheck=1
-repo_gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
 exclude=kubelet kubeadm kubectl
 EOF

content/ko/docs/setup/production-environment/tools/kubespray.md

@@ -6,7 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
+이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
 
 Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
 
@@ -46,7 +46,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은
 * 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트:
   * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
   * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
-  * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet)
+  * [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal)
 
 ### (2/5) 인벤토리 파일 구성하기
 
@@ -93,7 +93,8 @@ Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _sca
 
 ### 클러스터 스케일링하기
 
-scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
+scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자.
+remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자.
 
 ### 클러스터 업그레이드 하기
 

content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md

@@ -27,7 +27,7 @@ CPU의 최솟값과 최댓값을 지정한다.
 
 클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다.
 
-태스크 예제를 실행하려면 클러스터에 적어도 1.0 CPU 이상이 사용 가능해야 한다.
+클러스터의 각 노드는 파드 실행을 위해 적어도 1.0 CPU 이상이 사용 가능해야 한다.
 쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면 
 [CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다.
 
@@ -45,7 +45,7 @@ kubectl create namespace constraints-cpu-example
 
 ## 리밋레인지와 파드 생성
 
-다음은 리밋레인지에 대한 예시 매니페스트이다.
+다음은 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}} 예제 매니페스트이다.
 
 {{< codenew file="admin/resource/cpu-constraints.yaml" >}}
 
@@ -95,7 +95,7 @@ limits:
 {{< /note >}}
 
 다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너 매니페스트는
-500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 리밋레인지에
+500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 이 네임스페이스의 리밋레인지에
 의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다.
 
 {{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
@@ -214,7 +214,10 @@ resources:
 [CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을 
 적용했다.
 
-이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
+이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 
+노드에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 
+노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 
+2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다.
 
 파드를 삭제한다.
 

content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md

@@ -140,7 +140,8 @@ resources:
 kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
 ```
 
-생성한 파드의 명세를 확인한다.
+생성한 파드의 
+[명세](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)를 확인한다.
 
 ```
 kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example

content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md

@@ -10,8 +10,9 @@ description: >-
 
 <!-- overview -->
 
-이 페이지는 네임스페이스에서 실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을
+이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서 
-설정하는 방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
+실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을 설정하는 방법을 보여준다.
+[리밋레인지(LimitRange)](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)
 오브젝트에 최소 및 최대 메모리 값을
 지정한다. 파드가 리밋레인지에 의해 부과된 제약 조건을 충족하지 않으면,
 네임스페이스에서 생성될 수 없다.
@@ -77,7 +78,7 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example -
 쿠버네티스는 다음 단계를 수행한다.
 
 * 해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면, 
-  해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다.
+컨트롤 플레인이 해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다.
 
 * 해당 파드의 모든 컨테이너의 메모리 요청량이 최소 500 MiB 이상인지 확인한다.
 

content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md

@@ -172,7 +172,7 @@ resources:
 네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가 
 설정되어 있는 경우,
 메모리 상한에 기본값을 설정하는 것이 좋다.
-다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다.
+다음은 리소스 쿼터가 네임스페이스에 적용하는 세 가지 제한 사항이다.
 
 * 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 메모리 상한이 있어야 한다.
   (파드의 모든 컨테이너에 대해 메모리 상한을 지정하면, 

content/ko/docs/tasks/administer-cluster/namespaces.md

@@ -0,0 +1,319 @@
+---
+
+
+
+title: 네임스페이스를 사용해 클러스터 공유하기
+content_type: task
+---
+
+<!-- overview -->
+이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}를 살펴보고, 작업하고, 삭제하는 방법에 대해 다룬다. 또한 쿠버네티스 네임스페이스를 사용해 클러스터를 세분화하는 방법에 대해서도 다룬다.
+
+
+## {{% heading "prerequisites" %}}
+
+* [기존 쿠버네티스 클러스터](/ko/docs/setup/)가 있다.
+* 쿠버네티스 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="서비스" >}}, 그리고 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 대해 이해하고 있다.
+
+
+<!-- steps -->
+
+## 네임스페이스 보기
+
+1. 아래 명령어를 사용해 클러스터의 현재 네임스페이스를 나열한다.
+
+```shell
+kubectl get namespaces
+```
+```
+NAME          STATUS    AGE
+default       Active    11d
+kube-system   Active    11d
+kube-public   Active    11d
+```
+
+쿠버네티스를 시작하면 세 개의 초기 네임스페이스가 있다.
+
+   * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
+   * `kube-system` 쿠버네티스 시스템에서 생성된 오브젝트의 네임스페이스
+   * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(미인증 사용자를 포함)가 읽을 수 있다. 이 네임스페이스는 일부 리소스를 공개적으로 보고 읽을 수 있어야 하는 경우에 대비하여 대부분이 클러스터 사용을 위해 예약돼 있다. 그러나 이 네임스페이스의 공개적인 성격은 관례일 뿐 요구 사항은 아니다.
+   
+아래 명령을 실행해 특정 네임스페이스에 대한 요약 정보를 볼 수 있다.
+
+```shell
+kubectl get namespaces <name>
+```
+
+자세한 정보를 보는 것도 가능하다.
+
+```shell
+kubectl describe namespaces <name>
+```
+```
+Name:           default
+Labels:         <none>
+Annotations:    <none>
+Status:         Active
+
+No resource quota.
+
+Resource Limits
+ Type       Resource    Min Max Default
+ ----               --------    --- --- ---
+ Container          cpu         -   -   100m
+```
+
+이러한 세부 정보에는 리소스 한도(limit) 범위 뿐만 아니라 리소스 쿼터(만약 있다면)까지 모두 표시된다.
+
+리소스 쿼터는 *네임스페이스* 내 리소스의 집계 사용량을 추적하며, 
+*네임스페이스*에서 사용할 수 있는 *하드(Hard)* 리소스 사용 제한을 클러스터 운영자가 정의할 수 있도록 해준다.
+
+제한 범위는 하나의 엔티티(entity)가 하나의 *네임스페이스*에서 사용할 수 있는 
+리소스 양에 대한 최대/최소 제약 조건을 정의한다.
+
+[어드미션 컨트롤: 리밋 레인지(Limit Range)](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조하자.
+
+네임스페이스는 다음 두 상태 중 하나에 있을 수 있다.
+
+   * `Active` 네임스페이스가 사용 중이다.
+   * `Terminating` 네임스페이스가 삭제 중이므로 새 오브젝트에 사용할 수 없다.
+
+자세한 내용은 API 레퍼런스의 [네임스페이스](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)를
+참조한다.
+
+## 새 네임스페이스 생성하기
+
+{{< note >}}
+    `kube-` 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다.
+{{< /note >}}
+
+1. `my-namespace.yaml`이라는 YAML 파일을 생성하고 아래 내용을 작성한다.
+
+    ```yaml
+    apiVersion: v1
+    kind: Namespace
+    metadata:
+      name: <insert-namespace-name-here>
+    ```
+    다음 명령을 실행한다.
+   
+    ```
+    kubectl create -f ./my-namespace.yaml
+    ```
+
+2. 아래 명령으로 네임스페이스를 생성할 수도 있다.
+
+    ```
+    kubectl create namespace <insert-namespace-name-here>
+    ``` 
+
+네임스페이스의 이름은 
+유효한 [DNS 레이블](/docs/concepts/overview/working-with-objects/names#dns-label-names)이어야 한다.
+
+옵션 필드인 `finalizer`는 네임스페이스가 삭제 될 때 관찰자가 리소스를 제거할 수 있도록 한다. 존재하지 않는 파이널라이저(finalizer)를 명시한 경우 네임스페이스는 생성되지만 사용자가 삭제하려 하면 `Terminating` 상태가 된다.
+
+파이널라이저에 대한 자세한 내용은 네임스페이스 [디자인 문서](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers)에서 확인할 수 있다.
+
+## 네임스페이스 삭제하기
+
+다음 명령을 실행해 네임스페이스를 삭제한다.
+
+```shell
+kubectl delete namespaces <insert-some-namespace-name>
+```
+
+{{< warning >}}
+이렇게 하면 네임스페이스의 _모든 것_ 이 삭제된다!
+{{< /warning >}}
+
+삭제는 비동기적이므로 삭제 후 한동안은 네임스페이스의 상태가 `Terminating`으로 보일 것이다.
+
+## 쿠버네티스 네임스페이스를 사용해 클러스터 세분화하기
+
+1. 기본 네임스페이스 이해하기
+
+    기본적으로 쿠버네티스 클러스터는 클러스터에서 사용할 기본 파드, 서비스, 그리고 디플로이먼트(Deployment) 집합을 가지도록 
+    클러스터를 프로비저닝 할 때 기본 네임스페이스를 인스턴스화한다.
+    
+    새 클러스터가 있다고 가정하고 아래 명령을 수행하면 사용 가능한 네임스페이스를 볼 수 있다.
+
+    ```shell
+    kubectl get namespaces
+    ```
+    ```
+    NAME      STATUS    AGE
+    default   Active    13m
+    ```
+
+2. 새 네임스페이스 생성하기
+
+    이 예제에서는 내용을 저장할 쿠버네티스 네임스페이스를 추가로 두 개 생성할 것이다.
+
+    개발과 프로덕션 유스케이스에서 공유 쿠버네티스 클러스터를 사용하는 조직이 있다고 가정하자.
+
+    개발 팀은 애플리케이션을 구축하고 실행하는데 사용하는 파드, 서비스, 디플로이먼트의 목록을 볼 수 있는 공간을 클러스터에 유지하려 한다.
+    이 공간에서는 쿠버네티스 리소스가 자유롭게 추가 및 제거되고, 
+    누가 리소스를 수정할 수 있는지 없는지에 대한 제약이 완화돼 빠른 개발이 가능해진다.
+
+    운영 팀은 운영 사이트를 실행하는 파드, 서비스, 디플로이먼트 집합을 조작할 수 있는 사람과 
+    그렇지 않은 사람들에 대해 엄격한 절차를 적용할 수 있는 공간을 클러스터에 유지하려 한다.
+
+    이 조직이 따를 수 있는 한 가지 패턴은 쿠버네티스 클러스터를 `development(개발)`와 `production(운영)`이라는 두 개의 네임스페이스로 분할하는 것이다.
+
+    우리의 작업을 보존하기 위해 새로운 네임스페이스 두 개를 만들자.
+
+    kubectl을 사용해 `development` 네임스페이스를 생성한다.
+
+    ```shell
+    kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
+    ```
+
+    그런 다음 kubectl을 사용해 `production` 네임스페이스를 생성한다.
+
+    ```shell
+    kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
+    ```
+
+    제대로 생성이 되었는지 확인하기 위해 클러스터 내의 모든 네임스페이스를 나열한다.
+
+    ```shell
+    kubectl get namespaces --show-labels
+    ```
+    ```
+    NAME          STATUS    AGE       LABELS
+    default       Active    32m       <none>
+    development   Active    29s       name=development
+    production    Active    23s       name=production
+    ```
+
+3. 네임스페이스마다 파드 생성
+
+    쿠버네티스 네임스페이스는 클러스터의 파드, 서비스 그리고 디플로이먼트의 범위를 제공한다.
+
+    하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다.
+
+    이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자.
+
+    ```shell
+    kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname  -n=development --replicas=2
+    ```
+    호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다.
+
+    ```shell
+    kubectl get deployment -n=development
+    ```
+    ```
+    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+    snowflake    2/2     2            2           2m
+    ```
+    ```shell
+    kubectl get pods -l app=snowflake -n=development
+    ```
+    ```
+    NAME                         READY     STATUS    RESTARTS   AGE
+    snowflake-3968820950-9dgr8   1/1       Running   0          2m
+    snowflake-3968820950-vgc4n   1/1       Running   0          2m
+    ```
+
+    개발자들은 `production` 네임스페이스의 내용에 영향을 끼칠 걱정 없이 하고 싶은 것을 할 수 있으니 대단하지 않은가.
+
+    이제 `production` 네임스페이스로 전환해 한 네임스페이스의 리소스가 다른 네임스페이스에서는 어떻게 숨겨지는지 보자.
+
+    `production` 네임스페이스는 비어있어야 하며 아래 명령은 아무 것도 반환하지 않아야 한다.
+
+    ```shell
+    kubectl get deployment -n=production
+    kubectl get pods -n=production
+    ```
+
+    프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다.
+
+    ```shell
+    kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
+    kubectl scale deployment cattle --replicas=5 -n=production
+
+    kubectl get deployment -n=production
+    ```
+    ```
+    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+    cattle       5/5     5            5           10s
+    ```
+
+    ```shell
+    kubectl get pods -l app=cattle -n=production
+    ```
+    ```
+    NAME                      READY     STATUS    RESTARTS   AGE
+    cattle-2263376956-41xy6   1/1       Running   0          34s
+    cattle-2263376956-kw466   1/1       Running   0          34s
+    cattle-2263376956-n4v97   1/1       Running   0          34s
+    cattle-2263376956-p5p3i   1/1       Running   0          34s
+    cattle-2263376956-sxpth   1/1       Running   0          34s
+    ```
+
+지금 쯤이면 사용자가 한 네임스페이스에 생성한 리소스는 다른 네임스페이스에서 숨겨져 있어야 한다는 것을 잘 알고 있을 것이다.
+
+쿠버네티스 정책 지원이 발전함에 따라, 이 시나리오를 확장해 각 네임스페이스에 
+서로 다른 인증 규칙을 제공하는 방법을 보이도록 하겠다.
+
+
+
+<!-- discussion -->
+
+## 네임스페이스의 사용 동기 이해하기
+
+단일 클러스터는 여러 사용자 및 사용자 그룹(이하 '사용자 커뮤니티')의 요구를 충족시킬 수 있어야 한다.
+
+쿠버네티스 _네임스페이스_ 는 여러 프로젝트, 팀 또는 고객이 쿠버네티스 클러스터를 공유할 수 있도록 지원한다.
+
+이를 위해 다음을 제공한다.
+
+1. [이름](/ko/docs/concepts/overview/working-with-objects/names/)에 대한 범위
+2. 인증과 정책을 클러스터의 하위 섹션에 연결하는 메커니즘
+
+여러 개의 네임스페이스를 사용하는 것은 선택 사항이다.
+
+각 사용자 커뮤니티는 다른 커뮤니티와 격리된 상태로 작업할 수 있기를 원한다.
+
+각 사용자 커뮤니티는 다음을 가진다.
+
+1. 리소스 (파드, 서비스, 레플리케이션 컨트롤러(replication controller) 등
+2. 정책 (커뮤니티에서 조치를 수행할 수 있거나 없는 사람)
+3. 제약 조건 (해당 커뮤니티에서는 어느 정도의 쿼터가 허용되는지 등)
+
+클러스터 운영자는 각 사용자 커뮤니티 마다 네임스페이스를 생성할 수 있다.
+
+네임스페이스는 다음을 위한 고유한 범위를 제공한다.
+
+1. (기본 명명 충돌을 방지하기 위해) 명명된 리소스
+2. 신뢰할 수 있는 사용자에게 관리 권한 위임
+3. 커뮤니티 리소스 소비를 제한하는 기능
+
+유스케이스는 다음을 포함한다.
+
+1.  클러스터 운영자로서 단일 클러스터에서 여러 사용자 커뮤니티를 지원하려 한다.
+2.  클러스터 운영자로서 클러스터 분할에 대한 권한을 
+    해당 커뮤니티의 신뢰할 수 있는 사용자에게 위임하려 한다.
+3.  클러스터 운영자로서 클러스터를 사용하는 다른 커뮤니티에 미치는 영향을 제한하기 위해 
+    각 커뮤니티가 사용할 수 있는 리소스의 양을 제한하고자 한다.
+4.  클러스터 사용자로서 다른 사용자 커뮤니티가 클러스터에서 수행하는 작업과는 별도로 
+    사용자 커뮤니티와 관련된 리소스와 상호 작용하고 싶다.
+
+## 네임스페이스와 DNS 이해하기
+
+[서비스](/ko/docs/concepts/services-networking/service/)를 생성하면 상응하는 [DNS 엔트리(entry)](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
+이 엔트리는 `<서비스-이름><네임스페이스=이름>.svc.cluster.local` 형식을 갖는데, 
+컨테이너가 `<서비스-이름>`만 갖는 경우에는 네임스페이스에 국한된 서비스로 연결된다.
+이 기능은 개발, 스테이징 및 프로덕션과 같이 
+여러 네임스페이스 내에서 동일한 설정을 사용할 때 유용하다. 
+네임스페이스를 넘어서 접근하려면 전체 주소 도메인 이름(FQDN)을 사용해야 한다.
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [네임스페이스 선호(preference)](/ko/docs/concepts/overview/working-with-objects/namespaces/#선호하는-네임스페이스-설정하기)에 대해 자세히 알아보기.
+* [요청(request)에 대한 네임스페이스 설정](/ko/docs/concepts/overview/working-with-objects/namespaces/#요청에-네임스페이스-설정하기)에 대해 자세히 알아보기.
+* [네임스페이스 설계](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md) 참조하기.
+
+

content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md

@@ -0,0 +1,219 @@
+---
+reviewers:
+
+
+title: 다중 스케줄러 설정
+content_type: task
+weight: 20
+---
+
+<!-- overview -->
+
+쿠버네티스는 [여기](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
+설명한 스케줄러를 기본 스케줄러로 사용한다.
+만일 기본 스케줄러가 사용자의 필요를 만족시키지 못한다면 직접 스케줄러를 구현하여 사용할 수 있다.
+이에 더해, 기본 스케줄러와 함께 여러 스케줄러를 동시에 사용하여
+쿠버네티스가 각 파드에 대해 어떤 스케줄러를 적용할지에 대한 설정도 할 수 있다.
+예제와 함께 쿠버네티스에서 다중 스케줄러를 사용하는 방법에 대해 배워보도록 하자.
+
+스케줄러를 구현하는 방법에 대한 자세한 설명은 해당 문서에서 다루지 않는다.
+kube-scheduler 구현을 다루는 공식 예시는 쿠버네티스 소스 디렉토리에 있는
+[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler)
+를 참고한다.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+## 스케줄러 패키징
+
+스케줄러 바이너리를 컨테이너 이미지로 패키징한다. 해당 예제를 통해
+기본 스케줄러 (kube-scheduler)를 두 번째 스케줄러로 사용할 수 있다.
+[GitHub 쿠버네티스 소스코드](https://github.com/kubernetes/kubernetes)를 
+클론하고 소스를 빌드하자.
+
+```shell
+git clone https://github.com/kubernetes/kubernetes.git
+cd kubernetes
+make
+```
+
+kube-scheduler 바이너리를 담은 컨테이너 이미지를 생성하자.
+이미지를 빌드 하기 위한 `Dockerfile`은 다음과 같다.
+
+```docker
+FROM busybox
+ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler
+```
+
+파일을 `Dockerfile`로 저장하고 이미지를 빌드한 후 레지스트리로 푸시하자. 해당 예제에서는 이미지를
+[Google Container Registry (GCR)](https://cloud.google.com/container-registry/)로
+푸시하고 있다.
+이에 대한 자세한 내용은 GCR
+[문서](https://cloud.google.com/container-registry/docs/)를 참고하자.
+
+```shell
+docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
+gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
+```
+
+## 스케줄러에서 사용할 쿠버네티스 디플로이먼트 정의하기
+
+이제 스케줄러 컨테이너 이미지가 있으니, 해당 이미지를 포함하는 파드 구성을 생성하고
+쿠버네티스 클러스터 내에서 실행해보자. 해당 예제에서는, 클러스터 내에 직접 파드를 생성하는 대신에
+[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용해도 된다.
+[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는
+[레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)을 관리하며,
+이는 또 파드를 관리하기 때문에 스케줄러에 대한 회복 탄력성을 제공한다.
+다음은 디플로이먼트에 대한 구성 파일이다. 이 파일을 `my-scheduler.yaml`으로 저장한다.
+
+{{< codenew file="admin/sched/my-scheduler.yaml" >}}
+
+해당 매니페스트에서는 [KubeSchedulerConfiguration](/ko/docs/reference/scheduling/config/)을 
+사용하여 구현할 스케줄러의 특성을 정의한다. 이러한 설정은 초기화 과정에서 `--config` 옵션을 통해 `kube-scheduler`에게 전달된다.
+해당 구성 파일은 `my-scheduler-config` 컨피그맵에 저장된다. `my-scheduler` 디플로이먼트의 파드에서는 `my-scheduler-config` 컨피그맵을 볼륨으로 마운트 시킨다.
+
+앞서 언급한 스케줄러 구성에서는, 구현한 스케줄러가
+[KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerProfile)의 형식으로 나타나게 된다.
+{{< note >}}
+스케줄러가 특정 파드에 대한 스케줄링을 수행하는지 판단하기 위해서는, PodTemplate 또는 파드 매니페스트의
+`spec.schedulerName` 필드가 `KubeSchedulerProfile`의 `schedulerName` 필드와 일치하는지 확인해야 한다.
+클러스터 내 실행되고 있는 모든 스케줄러는 고유한 이름을 가져야 한다.
+{{< /note >}}
+
+또한, `kube-scheduler`와 같은 권한을 부여받기 위해서는 전용 서비스 어카운트 `my-scheduler`를 생성하고
+해당 서비스 어카운트를 클러스터롤 `system:kube-scheduler`와 바인딩해야 한다.
+
+이외의 커맨드 라인 인자에 대한 자세한 설명은
+[kube-scheduler 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 참고하고
+이외의 사용자 정의 `kube-scheduler` 구성에 대한 자세한 설명은
+[스케줄러 구성 레퍼런스](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
+에서 참고한다.
+
+## 두 번째 스케줄러를 클러스터에서 실행하기
+
+쿠버네티스 클러스터에서 스케줄러를 실행하기 위해서,
+위의 구성 파일에서 명시한 디플로이먼트를 쿠버네티스 클러스터 내에 생성한다.
+
+```shell
+kubectl create -f my-scheduler.yaml
+```
+
+스케줄러 파드가 실행되고 있는지 확인한다.
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+
+```
+NAME                                           READY     STATUS    RESTARTS   AGE
+....
+my-scheduler-lnf4s-4744f                       1/1       Running   0          2m
+...
+```
+
+기본 kube-scheduler 파드와 더불어,
+my-scheduler 파드가 실행("Running")되고 있다는 것을 목록에서 볼 수 있을 것이다.
+
+### 리더 선출 활성화
+
+리더 선출이 활성화된 상태로 다중 스케줄러를 실행하기 위해서는 다음과 같은 작업을 수행해야 한다.
+
+`my-scheduler-config` 컨피그맵의 YAML 파일에서 KubeSchedulerConfiguration의 다음과 같은 필드들을 갱신한다.
+
+* `leaderElection.leaderElect` 를 `true` 로
+* `leaderElection.resourceNamespace` 를 `<lock-object-namespace>` 로
+* `leaderElection.resourceName` 을 `<lock-object-name>` 으로
+
+{{< note >}}
+컨트롤 플레인이 잠금 오브젝트를 생성해 주지만, 해당 네임스페이스가 존재하는 상태이어야 한다.
+`kube-system` 네임스페이스를 사용해도 된다.
+{{< /note >}}
+
+클러스터 내에 RBAC가 활성화되어 있는 상태라면, `system:kube-scheduler` 클러스터롤을 업데이트 해야 한다.
+다음 예시와 같이, 구현한 스케줄러의 이름을 `endpoints`와 `leases` 리소스에 적용되는 룰의 resourceNames에 추가하자.
+
+```shell
+kubectl edit clusterrole system:kube-scheduler
+```
+
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
+
+## 파드의 스케줄러를 지정하기
+
+이제 두 번째 스케줄러가 실행되고 있으니,
+파드를 몇 개 생성하여 기본 스케줄러 또는 새로 배치한 스케줄러에 의해 스케줄링이 되도록 설정해 보자.
+특정 스케줄러를 이용하여 파드를 스케줄링하기 위해서는
+해당 파드의 명세에 해당 스케줄러의 이름을 명시해야 한다. 세 가지 예시를 참고해 보자.
+
+- 스케줄러 이름을 명시하지 않은 파드 명세
+
+  {{< codenew file="admin/sched/pod1.yaml" >}}
+
+  스케줄러 이름을 제공받지 못했다면,
+  파드는 자동으로 기본 스케줄러에 의해 스케줄링이 수행된다.
+
+  해당 파일을 `pod1.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자.
+
+  ```shell
+  kubectl create -f pod1.yaml
+  ```
+
+- `default-scheduler`를 명시한 파드 명세
+
+  {{< codenew file="admin/sched/pod2.yaml" >}}
+
+  `spec.schedulerName`의 값으로 스케줄러 이름을 제공함으로써 스케줄러가 정해진다.
+  이와 같은 경우에서는, 기본 스케줄러의 이름인 `default-scheduler`를 명시하고 있다.
+
+  해당 파일을 `pod2.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자.
+
+  ```shell
+  kubectl create -f pod2.yaml
+  ```
+
+- `my-scheduler`를 명시한 파드 명세
+
+  {{< codenew file="admin/sched/pod3.yaml" >}}
+
+  이와 같은 경우에서는, 직접 배치한 스케줄러 - `my-scheduler`를 통해
+  해당 파드의 스케줄링이 수행되어야 한다는 것을 명시하고 있다.
+  `spec.schedulerName`의 값은 `KubeSchedulerProfile` 매핑의  `schedulerName` 필드와 일치해야 한다.
+
+  해당 파일을 `pod3.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자.
+
+  ```shell
+  kubectl create -f pod3.yaml
+  ```
+
+  세 개의 파드가 모두 실행되고 있는지 확인해 보자.
+
+  ```shell
+  kubectl get pods
+  ```
+
+<!-- discussion -->
+
+### 파드가 원하는 스케줄러에 의해 스케줄링 되었는지 확인해보기
+
+이번 예제들을 수월하게 진행하기 위해,
+파드가 실제로 원하는 스케줄러에 의해 스케줄링되고 있는지 확인해 보지 않았다.
+해당 사항은 파드와 디플로이먼트 구성 파일의 제출 순서를 바꿔보면 확인해 볼 수 있다.
+만일 스케줄러 디플로이먼트 구성 파일을 제출하기 전에 모든 파드의 구성 파일을 쿠버네티스 클러스터에 제출한다면,
+다른 두 개의 파드는 스케줄링 되는 와중에 `annotation-second-scheduler` 파드는
+무기한 "Pending" 상태에 머무르는 것을 관찰할 수 있다.
+스케줄러 디플로이먼트 구성 파일을 제출하여 새로운 스케줄러가 실행되기 시작하면,
+`annotation-second-scheduler` 파드도 스케줄링 된다.
+
+다른 방법으로는, 이벤트 로그에서 "Scheduled" 항목을 찾아
+파드가 원하는 스케줄러에 의해 스케줄링 되었는지 확인해 볼 수 있다.
+
+```shell
+kubectl get events
+```
+또한, 관련된 컨트롤 플레인 노드들의 스태틱 파드 매니페스트를 수정하면 클러스터의 메인 스케줄러로
+[사용자 정의 스케줄러 구성](/ko/docs/reference/scheduling/config/#multiple-profiles)
+또는 사용자 정의 컨테이너 이미지를 사용할 수도 있다.
+

content/ko/docs/tasks/tls/certificate-rotation.md

@@ -28,7 +28,7 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
 너무 자주 갱신할 필요는 없다.
 
 쿠버네티스는 [kubelet 인증서
-갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며,
+갱신](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함하며,
 이 기능은 현재 인증서의 만료 시한이 임박한 경우,
 새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 기능이다.
 새로운 인증서를 사용할 수 있게 되면

content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md

@@ -43,7 +43,7 @@ kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로
 
 ```bash
 echo 'alias k=kubectl' >>~/.bashrc
-echo 'complete -F __start_kubectl k' >>~/.bashrc
+echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
 ```
 
 {{< note >}}

content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md

@@ -77,7 +77,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
 
     ```bash
     echo 'alias k=kubectl' >>~/.bash_profile
-    echo 'complete -F __start_kubectl k' >>~/.bash_profile
+    echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
     ```
 
 - Homebrew로 kubectl을 설치한 경우([여기](/ko/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)의 설명을 참고), kubectl 자동 완성 스크립트가 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있을 것이다. 이 경우, 아무 것도 할 필요가 없다.

content/ko/docs/tasks/tools/install-kubectl-linux.md

@@ -138,10 +138,9 @@ card:
 cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
 name=Kubernetes
-baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
+baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
 enabled=1
 gpgcheck=1
-repo_gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
 EOF
 sudo yum install -y kubectl

content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md

@@ -8,7 +8,7 @@ content_type: tutorial
 
 <!-- overview -->
 
-이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다.
+이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 파드 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다.
 
 
 
@@ -27,7 +27,7 @@ content_type: tutorial
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 * 예시는 `kubectl` 1.14 이상 버전에서 동작한다.
-* [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
+* [컨피그맵을 사용해서 파드 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
 
 
 
@@ -78,7 +78,7 @@ kubectl get pod/redis configmap/example-redis-config
 
 다음의 결과를 볼 수 있다.
 
-```shell
+```
 NAME        READY   STATUS    RESTARTS   AGE
 pod/redis   1/1     Running   0          8s
 

content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html

@@ -11,7 +11,7 @@ weight: 20
 
 <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
 <link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
-<script src="https://katacoda.com/embed.js"></script>
+{{< katacoda-tutorial >}}
 
 <div class="layout" id="top">
 

content/ko/docs/tutorials/security/cluster-level-pss.md

@@ -19,6 +19,9 @@ weight: 10
 
 파드 시큐리티 스탠다드를 특정 네임스페이스에 적용하려면, [파드 시큐리티 스탠다드를 네임스페이스 수준에 적용하기](/ko/docs/tutorials/security/ns-level-pss/)를 참고한다.
 
+만약 쿠버네티스 버전이 v{{< skew currentVersion >}}이 아니라면,
+해당 버전의 문서를 확인하자.
+
 ## {{% heading "prerequisites" %}}
 
 워크스테이션에 다음을 설치한다.
@@ -38,12 +41,12 @@ weight: 10
 1. 파드 시큐리티 스탠다드가 적용되지 않은 클러스터를 생성한다.
 
     ```shell
-    kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0
+    kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0
     ```
    다음과 비슷하게 출력될 것이다.
     ```
     Creating cluster "psa-wo-cluster-pss" ...
-    ✓ Ensuring node image (kindest/node:v1.23.0) 🖼
+    ✓ Ensuring node image (kindest/node:v1.24.0) 🖼
     ✓ Preparing nodes 📦  
     ✓ Writing configuration 📜
     ✓ Starting control-plane 🕹️
@@ -245,12 +248,12 @@ weight: 10
    파드 시큐리티 어드미션을 사용하는 클러스터를 생성한다.
 
    ```shell
-    kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml
+    kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml
    ```
    다음과 비슷하게 출력될 것이다.
    ```
     Creating cluster "psa-with-cluster-pss" ...
-     ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 
+     ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 
      ✓ Preparing nodes 📦  
      ✓ Writing configuration 📜 
      ✓ Starting control-plane 🕹️ 

content/ko/docs/tutorials/services/source-ip.md

@@ -204,21 +204,9 @@ client_address=10.240.0.3
 * 파드의 응답은 node2로 다시 라우팅된다.
 * 파드의 응답은 클라이언트로 다시 전송된다.
 
-시각적으로
+이를 그림으로 표현하면 다음과 같다.
 
-{{< mermaid >}}
+{{< figure src="/docs/images/tutor-service-nodePort-fig01.svg" alt="source IP nodeport figure 01" class="diagram-large" caption="그림. Source IP Type=NodePort using SNAT" link="https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg" >}}
-graph LR;
-  client(client)-->node2[Node 2];
-  node2-->client;
-  node2-. SNAT .->node1[Node 1];
-  node1-. SNAT .->node2;
-  node1-->endpoint(Endpoint);
-
-  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-  class node1,node2,endpoint k8s;
-  class client plain;
-{{</ mermaid >}}
 
 이를 피하기 위해 쿠버네티스는
 [클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다.
@@ -260,20 +248,9 @@ client_address=104.132.1.79
 * 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다.
 * node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다.
 
-시각적으로
+이를 시각적으로 표현하면 다음과 같다.
 
-{{< mermaid >}}
+{{< figure src="/docs/images/tutor-service-nodePort-fig02.svg" alt="source IP nodeport figure 02" class="diagram-large" caption="그림. Source IP Type=NodePort preserves client source IP address" link="" >}}
-graph TD;
-  client --> node1[Node 1];
-  client(client) --x node2[Node 2];
-  node1 --> endpoint(endpoint);
-  endpoint --> node1;
-
-  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-  class node1,node2,endpoint k8s;
-  class client plain;
-{{</ mermaid >}}
 
 
 
@@ -324,7 +301,7 @@ client_address=10.240.0.5
 강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서
 자신을 스스로 제거한다.
 
-시각적으로:
+이를 그림으로 표현하면 다음과 같다.
 
 ![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg)
 

content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md

@@ -16,7 +16,7 @@ card:
 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/ko/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다.
 
 {{< warning >}}
-이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자.
+이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)로 배포하기를 고려해보자.
 {{< /warning >}}
 
 {{< note >}}

content/ko/docs/tutorials/stateful-application/zookeeper.md

@@ -122,7 +122,7 @@ zk-2      1/1       Running   0         40s
 ```
 
 스테이트풀셋 컨트롤러는 3개의 파드를 생성하고, 각 파드는
-[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
+[ZooKeeper](https://archive.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다.
 
 
 ### 리더 선출 촉진
@@ -305,7 +305,7 @@ numChildren = 0
 
 ### 내구성있는 저장소 제공
 
-[ZooKeeper 기본](#zookeeper-basics) 섹션에서 언급했듯이
+[ZooKeeper 기본](#zookeeper) 섹션에서 언급했듯이
 ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상태의 스냅샷을 저장 미디에에 주기적으로 저장한다.
 내구성을 제공하기 위해 WAL을 이용하는 것은
 복제된 상태 머신을 이루는 합의 프로토콜에서

content/ko/examples/admin/sched/clusterrole.yaml

@@ -0,0 +1,37 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  annotations:
+    rbac.authorization.kubernetes.io/autoupdate: "true"
+  labels:
+    kubernetes.io/bootstrapping: rbac-defaults
+  name: system:kube-scheduler
+rules:
+  - apiGroups:
+      - coordination.k8s.io
+    resources:
+      - leases
+    verbs:
+      - create
+  - apiGroups:
+      - coordination.k8s.io
+    resourceNames:
+      - kube-scheduler
+      - my-scheduler
+    resources:
+      - leases
+    verbs:
+      - get
+      - update
+  - apiGroups:
+      - ""
+    resourceNames:
+      - kube-scheduler
+      - my-scheduler
+    resources:
+      - endpoints
+    verbs:
+      - delete
+      - get
+      - patch
+      - update

content/ko/examples/admin/sched/my-scheduler.yaml

@@ -0,0 +1,99 @@
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: my-scheduler
+  namespace: kube-system
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: my-scheduler-as-kube-scheduler
+subjects:
+- kind: ServiceAccount
+  name: my-scheduler
+  namespace: kube-system
+roleRef:
+  kind: ClusterRole
+  name: system:kube-scheduler
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: my-scheduler-as-volume-scheduler
+subjects:
+- kind: ServiceAccount
+  name: my-scheduler
+  namespace: kube-system
+roleRef:
+  kind: ClusterRole
+  name: system:volume-scheduler
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: my-scheduler-config
+  namespace: kube-system
+data:
+  my-scheduler-config.yaml: |
+    apiVersion: kubescheduler.config.k8s.io/v1beta2
+    kind: KubeSchedulerConfiguration
+    profiles:
+      - schedulerName: my-scheduler
+    leaderElection:
+      leaderElect: false
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    component: scheduler
+    tier: control-plane
+  name: my-scheduler
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      component: scheduler
+      tier: control-plane
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        component: scheduler
+        tier: control-plane
+        version: second
+    spec:
+      serviceAccountName: my-scheduler
+      containers:
+      - command:
+        - /usr/local/bin/kube-scheduler
+        - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
+        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
+        livenessProbe:
+          httpGet:
+            path: /healthz
+            port: 10259
+            scheme: HTTPS
+          initialDelaySeconds: 15
+        name: kube-second-scheduler
+        readinessProbe:
+          httpGet:
+            path: /healthz
+            port: 10259
+            scheme: HTTPS
+        resources:
+          requests:
+            cpu: '0.1'
+        securityContext:
+          privileged: false
+        volumeMounts:
+          - name: config-volume
+            mountPath: /etc/kubernetes/my-scheduler
+      hostNetwork: false
+      hostPID: false
+      volumes:
+        - name: config-volume
+          configMap:
+            name: my-scheduler-config

content/ko/examples/admin/sched/pod1.yaml

@@ -0,0 +1,10 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: no-annotation
+  labels:
+    name: multischeduler-example
+spec:
+  containers:
+  - name: pod-with-no-annotation-container
+    image: k8s.gcr.io/pause:2.0

content/ko/examples/admin/sched/pod2.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotation-default-scheduler
+  labels:
+    name: multischeduler-example
+spec:
+  schedulerName: default-scheduler
+  containers:
+  - name: pod-with-default-annotation-container
+    image: k8s.gcr.io/pause:2.0

content/ko/examples/admin/sched/pod3.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotation-second-scheduler
+  labels:
+    name: multischeduler-example
+spec:
+  schedulerName: my-scheduler
+  containers:
+  - name: pod-with-second-annotation-container
+    image: k8s.gcr.io/pause:2.0

content/ko/examples/application/mysql/mysql-configmap.yaml

@@ -4,15 +4,14 @@ metadata:
   name: mysql
   labels:
     app: mysql
+    app.kubernetes.io/name: mysql
 data:
   primary.cnf: |
     # Primary에만 이 구성을 적용한다.
     [mysqld]
-    log-bin
+    log-bin    
-    datadir=/var/lib/mysql/mysql
   replica.cnf: |
     # 레플리카에만 이 구성을 적용한다.
     [mysqld]
-    super-read-only
+    super-read-only    
-    datadir=/var/lib/mysql/mysql
 

content/ko/examples/application/mysql/mysql-services.yaml

@@ -5,6 +5,7 @@ metadata:
   name: mysql
   labels:
     app: mysql
+    app.kubernetes.io/name: mysql
 spec:
   ports:
   - name: mysql
@@ -21,6 +22,8 @@ metadata:
   name: mysql-read
   labels:
     app: mysql
+    app.kubernetes.io/name: mysql
+    readonly: "true"
 spec:
   ports:
   - name: mysql

content/ko/examples/application/mysql/mysql-statefulset.yaml

@@ -6,12 +6,14 @@ spec:
   selector:
     matchLabels:
       app: mysql
+      app.kubernetes.io/name: mysql
   serviceName: mysql
   replicas: 3
   template:
     metadata:
       labels:
         app: mysql
+        app.kubernetes.io/name: mysql
     spec:
       initContainers:
       - name: init-mysql

content/ko/examples/controllers/job.yaml

@@ -7,7 +7,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
   backoffLimit: 4

content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml

@@ -30,4 +30,4 @@ spec:
             - key-2
   containers:
   - name: with-node-affinity
-    image: k8s.gcr.io/pause:2.0
+    image: k8s.gcr.io/pause:2.0 

content/ko/includes/task-tutorial-prereqs.md

@@ -2,7 +2,7 @@
 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고
 있지 않다면,
 [minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나
-다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
+다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
 
-* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes)
+* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) 
 * [Play with Kubernetes](https://labs.play-with-k8s.com/)

content/ko/releases/_index.md

@@ -12,7 +12,7 @@ type: docs
 쿠버네티스 버전은 **x.y.z** 의 형태로 표현되는데,
 **x** 는 메이저(major) 버전, **y** 는 마이너(minor), **z** 는 패치(patch) 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/)의 용어를 따른 것이다.
 
-저 자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다.
+자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다.
 
 <!-- body -->
 

content/ko/releases/version-skew-policy.md

@@ -21,12 +21,12 @@ description: >
 ## 지원되는 버전
 
 쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다.
-자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다.
+자세한 내용은 [쿠버네티스 릴리스 버전](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning)을 참조한다.
 
 쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
 
 보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다.
-패치 릴리스는 각 브랜치별로 [정기적인 주기](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.
+패치 릴리스는 각 브랜치별로 [정기적인 주기](/releases/patch-releases/#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.
 
 [릴리스 관리자](/releases/release-managers/) 그룹이 이러한 결정 권한을 가진다.