[ko] Update outdated files in dev-1.21-ko.5 (p4)

content/ko/docs/reference/using-api/client-libraries.md

@@ -65,7 +65,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
 | PHP                  | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
 | PHP                  | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) |
-| Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
 | Python               | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) |
 | Python               | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
 | Python               | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |

content/ko/docs/setup/_index.md

@@ -1,17 +1,21 @@
 ---
-no_issue: true
+
+
+
+
 title: 시작하기
 main_menu: true
 weight: 20
 content_type: concept
+no_list: true
 card:
   name: setup
   weight: 20
   anchors:
   - anchor: "#학습-환경"
     title: 학습 환경
-  - anchor: "#운영-환경"
-    title: 운영 환경
+  - anchor: "#프로덕션-환경"
+    title: 프로덕션 환경
 ---
 
 <!-- overview -->
@@ -20,16 +24,40 @@ card:
 쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고
 클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다.
 
-쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다.
+[쿠버네티스를 다운로드](/releases/download/)하여 
+로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.
+
+쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 
+같은 매니지드 서비스를 선택할 수도 있다.
+광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 
+표준화된/맞춤형 솔루션도 있다.
 
 <!-- body -->
 
 ## 학습 환경
 
-쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자.
+쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 
+로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용한다.
+[도구 설치](/ko/docs/tasks/tools/)를 살펴본다.
+
+## 프로덕션 환경
+
+[프로덕션 환경](/ko/docs/setup/production-environment/)을 위한 
+솔루션을 평가할 때에는, 쿠버네티스 클러스터(또는 _추상화된 객체_) 
+운영에 대한 어떤 측면을 스스로 관리하기를 원하는지, 
+또는 제공자에게 넘기기를 원하는지 고려한다.
+
+클러스터를 직접 관리하는 경우, 공식적으로 지원되는 쿠버네티스 구축 도구는 
+[kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/)이다.
 
-## 운영 환경
+## {{% heading "whatsnext" %}}
 
-운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자.
+- [쿠버네티스를 다운로드](/releases/download/)한다.
+- `kubectl`을 포함한 [도구를 설치](/ko/docs/tasks/tools/)한다.
+- 새로운 클러스터에 사용할 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 선택한다.
+- 클러스터 구성의 [모범 사례](/ko/docs/setup/best-practices/)를 확인한다.
 
-[쿠버네티스 파트너](/ko/partners/#conformance)에는 [공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자 목록이 포함되어 있다.
+쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 
+리눅스에서 실행되어야 한다. 클러스터 내에서는 리눅스 또는 
+다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
+- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.

content/ko/docs/setup/best-practices/cluster-large.md

@@ -6,13 +6,13 @@ weight: 20
 클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는
 쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리
 또는 가상 머신)의 집합이다.
-쿠버네티스 {{<param "version">}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는,
+쿠버네티스 {{<param "version">}}는 노드 5,000개까지의 클러스터를 지원한다. 보다 정확하게는,
 쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다.
 
-* 노드 당 파드 100 개 이하
-* 노드 5000개 이하
-* 전체 파드 150000개 이하
-* 전체 컨테이너 300000개 이하
+* 노드 당 파드 110 개 이하
+* 노드 5,000개 이하
+* 전체 파드 150,000개 이하
+* 전체 컨테이너 300,000개 이하
 
 노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은
 클러스터 배포 방법에 따라 다르다.

content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -7,7 +7,6 @@ card:
   weight: 40
 ---
 
-
 <!-- overview -->
 
 이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
@@ -21,20 +20,15 @@ card:
 반드시 존재해야 한다는 것을 의미하는 것은 아니다.
 {{< /note >}}
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 {{< include "task-tutorial-prereqs.md" >}}
 
 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면,
 `kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과
 [마이너 버전 하나 차이 이내](/ko/releases/version-skew-policy/#kubectl)여야
 한다.
 
-
-
 <!-- steps -->
 
 ## 클러스터, 사용자, 컨텍스트 정의
@@ -49,7 +43,7 @@ scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인
 `config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에
 다음 내용을 가진 `config-demo`라는 파일을 생성한다.
 
-```shell
+```yaml
 apiVersion: v1
 kind: Config
 preferences: {}
@@ -114,7 +108,7 @@ kubectl config --kubeconfig=config-demo view
 
 두 클러스터, 두 사용자, 세 컨텍스트들이 출력 결과로 나온다.
 
-```shell
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -186,7 +180,7 @@ kubectl config --kubeconfig=config-demo view --minify
 
 `dev-frontend` 컨텍스트에 관련된 구성 정보가 출력 결과로 표시될 것이다.
 
-```shell
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -238,7 +232,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage
 
 현재 컨텍스트인 `dev-storage`에 관련된 설정을 보자.
 
-
 ```shell
 kubectl config --kubeconfig=config-demo view --minify
 ```
@@ -247,7 +240,7 @@ kubectl config --kubeconfig=config-demo view --minify
 
 `config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.
 
-```shell
+```yaml
 apiVersion: v1
 kind: Config
 preferences: {}
@@ -269,13 +262,17 @@ contexts:
 예:
 
 ### 리눅스
+
 ```shell
-export  KUBECONFIG_SAVED=$KUBECONFIG
+export KUBECONFIG_SAVED=$KUBECONFIG
 ```
+
 ### 윈도우 PowerShell
-```shell
+
+```powershell
 $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 ```
+
 `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
 리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다.
 `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
@@ -284,11 +281,14 @@ $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.
 
 ### 리눅스
+
 ```shell
-export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
+export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
 ```
+
 ### 윈도우 PowerShell
-```shell
+
+```powershell
 $Env:KUBECONFIG=("config-demo;config-demo-2")
 ```
 
@@ -303,7 +303,7 @@ kubectl config view
 컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
 가지고 있다는 것에 주목하길 바란다.
 
-```shell
+```yaml
 contexts:
 - context:
     cluster: development
@@ -347,12 +347,15 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 예:
 
 ### 리눅스
+
 ```shell
 export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
+
 ### 윈도우 Powershell
-```shell
- $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
+
+```powershell
+$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
 ```
 
 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
@@ -367,19 +370,18 @@ kubectl config view
 `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>
 
 ### 리눅스
+
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```
 
 ### 윈도우 PowerShell
-```shell
- $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
-```
-
 
+```powershell
+$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
+```
 
 ## {{% heading "whatsnext" %}}
 
-
 * [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)

content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md

@@ -22,7 +22,7 @@ weight: 100
 ## 모든 네임스페이스의 모든 컨테이너 이미지 가져오기
 
 - `kubectl get pods --all-namespaces` 를 사용하여 모든 네임스페이스의 모든 파드 정보를 가져온다.
-- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={..image}` 를 사용한다.
+- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={.items[*].spec.containers[*].image}` 를 사용한다.
   이 명령어는 결과값으로 받은 json을 반복적으로 파싱하여,
   `image` 필드만을 출력한다.
   - jsonpath를 사용하는 방법에 대해 더 많은 정보를 얻고 싶다면
@@ -33,7 +33,7 @@ weight: 100
   - `uniq` 를 사용하여 이미지 개수를 합산한다.
 
 ```shell
-kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
 tr -s '[[:space:]]' '\n' |\
 sort |\
 uniq -c
@@ -80,7 +80,7 @@ sort
 명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다.
 
 ```shell
-kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
+kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx
 ```
 
 ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기
@@ -89,7 +89,7 @@ kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
 아래의 명령어 결과값은 `kube-system` 네임스페이스에 있는 파드만 출력한다.
 
 ```shell
-kubectl get pods --namespace kube-system -o jsonpath="{..image}"
+kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"
 ```
 
 ## jsonpath 대신 Go 템플릿을 사용하여 컨테이너 이미지 목록 보기

content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md

@@ -183,7 +183,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
 
 ```powershell
 # 예
-.\Install-Containerd.ps1 -ContainerDVersion v1.4.1
+.\Install-Containerd.ps1 -ContainerDVersion 1.4.1
 ```
 
 {{< /note >}}

content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -85,7 +85,11 @@ front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no
 {{< /warning >}}
 
 {{< note >}}
-kubeadm은 자동 인증서 갱신을 위해 kubelet을 구성하기 때문에 `kubelet.conf` 는 위 목록에 포함되어 있지 않다.
+`kubelet.conf` 는 위 목록에 포함되어 있지 않은데, 이는
+kubeadm이 [자동 인증서 갱신](/ko/docs/tasks/tls/certificate-rotation/)을 위해 
+`/var/lib/kubelet/pki`에 있는 갱신 가능한 인증서를 이용하여 kubelet을 구성하기 때문이다.
+만료된 kubelet 클라이언트 인증서를 갱신하려면 
+[kubelet 클라이언트 갱신 실패](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert) 섹션을 확인한다.
 {{< /note >}}
 
 {{< warning >}}

content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md

@@ -55,7 +55,7 @@ cat ~/.docker/config.json
 ## 기존의 도커 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials}
 
 쿠버네티스 클러스터는 프라이빗 이미지를 받아올 때, 컨테이너 레지스트리에 인증하기 위하여 
-`docker-registry` 타입의 시크릿을 사용한다.
+`kubernetes.io/dockerconfigjson` 타입의 시크릿을 사용한다.
 
 만약 이미 `docker login` 을 수행하였다면, 이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다.
 

content/ko/docs/tasks/configure-pod-container/quality-service-pod.md

@@ -45,10 +45,14 @@ kubectl create namespace qos-example
 
 파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다.
 
-* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
-* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
+* 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 한다.
+* 파드 내 모든 컨테이너의 메모리 상한이 메모리 요청량과 일치해야 한다.
+* 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 한다.
+* 파드 내 모든 컨테이너의 CPU 상한이 CPU 요청량과 일치해야 한다.
 
-이것은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과
+이러한 제약은 초기화 컨테이너와 앱 컨테이너 모두에 동일하게 적용된다.
+
+다음은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과
 메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다.
 
 {{< codenew file="pods/qos/qos-pod.yaml" >}}

content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md

@@ -41,7 +41,7 @@ content_type: task
 
         kubectl apply -f https://k8s.io/examples/debug/termination.yaml
 
-	   YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에
+	   YAML 파일에 있는 `command` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에
 	   "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
 	   것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를
 	   기록한 후에 종료된다.