[ko] Update outdated in dev-1.21-ko.8 (M13-M40)

content/ko/docs/concepts/services-networking/service.md

@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
 마찬가지로, 서비스 정의를 API 서버에 `POST`하여
 새 인스턴스를 생성할 수 있다.
 서비스 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-레이블-이름)이어야 한다.
 
 예를 들어, 각각 TCP 포트 9376에서 수신하고
 `app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -188,7 +188,7 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
 
 ### 초과 용량 엔드포인트
-엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
+엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21
 클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
 이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
 

content/ko/docs/concepts/storage/storage-classes.md

@@ -76,7 +76,7 @@ volumeBindingMode: Immediate
 | Glusterfs            | ✓            | [Glusterfs](#glusterfs)              |
 | iSCSI                | -                   | -                                    |
 | Quobyte              | ✓            | [Quobyte](#quobyte)                  |
-| NFS                  | -                   | -                                    |
+| NFS                  | -                   | [NFS](#nfs)       |
 | RBD                  | ✓            | [Ceph RBD](#ceph-rbd)                |
 | VsphereVolume        | ✓            | [vSphere](#vsphere)                  |
 | PortworxVolume       | ✓            | [Portworx 볼륨](#portworx-볼륨)  |
@@ -423,6 +423,29 @@ parameters:
     헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
     삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
 
+### NFS
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: example-nfs
+provisioner: example.com/external-nfs
+parameters:
+  server: nfs-server.example.com
+  path: /share
+  readOnly: false
+```
+
+* `server`: NFS 서버의 호스트네임 또는 IP 주소.
+* `path`: NFS 서버가 익스포트(export)한 경로.
+* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
+
+쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
+예시는 다음과 같다.
+* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
+* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
+
 ### OpenStack Cinder
 
 ```yaml

content/ko/docs/concepts/workloads/controllers/job.md

@@ -255,7 +255,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 
 ## 잡의 종료와 정리
 
-잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다.  이를 유지하면
+잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다. 
+이를 유지하면
 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
 `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.

content/ko/docs/concepts/workloads/pods/_index.md

@@ -282,6 +282,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
 여기에서 제어할 수는 없다는 의미이다.
 
+## 컨테이너 프로브
+
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+
+- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
+- `TCPSocketAction` (kubelet에 의해 직접 검사)
+- `HTTPGetAction` (kubelet에 의해 직접 검사)
+
+[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
+파드 라이프사이클 문서를 참고한다.
+
 ## {{% heading "whatsnext" %}}
 
 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.

content/ko/docs/concepts/workloads/pods/disruptions.md

@@ -31,7 +31,7 @@ weight: 60
 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
 - 커널 패닉
 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
-- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
+- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
 
 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
 왜냐하면

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -290,8 +290,9 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
 다음의 규칙이 적용된다.
 
-* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
+* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 
-  높은 것은 *유효한 초기화 요청량/상한* 이다.
+  가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 
+  이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
 * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
   * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
   * 리소스에 대한 유효한 초기화 요청량/상한

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
    확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
    프로세스를 시작한다.
    1. 파드의 컨테이너 중 하나가 `preStop`
-      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
+      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/)을 정의한 경우, kubelet은
       컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
       계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
       요청한다.

content/ko/docs/contribute/generate-ref-docs/quickstart.md

@@ -6,7 +6,7 @@ weight: 40
 
 <!-- overview -->
 
-이 문서에서는 `update-imported-docs` 스크립트를 사용하여 
+이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여 
 쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다. 
 이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
 
@@ -39,7 +39,7 @@ git clone git@github.com:<your_github_username>/website.git
 
 ## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
 
-`update-imported-docs` 스크립트는 `<web-base>/update-imported-docs/` 
+`update-imported-docs.py` 스크립트는 `<web-base>/update-imported-docs/` 
 디렉터리에 존재한다.
 
 이 스크립트는 다음 레퍼런스를 생성한다.
@@ -48,7 +48,7 @@ git clone git@github.com:<your_github_username>/website.git
 * `kubectl` 명령어 레퍼런스
 * 쿠버네티스 API 레퍼런스
 
-`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 
+`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 
 생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를 
 생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와 
 `kubernetes-sigs/reference-docs` 저장소를 클론하며, 
@@ -69,7 +69,7 @@ git clone git@github.com:<your_github_username>/website.git
 `kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
 `K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
 
-`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
+`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
 
 1. 환경설정 파일에 있는 관련 저장소를 클론한다. 
    레퍼런스 문서 생성을 위해 
@@ -152,17 +152,17 @@ repos:
 
 ## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
 
-다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
+다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
 
 ```shell
 cd <web-base>/update-imported-docs
-./update-imported-docs <configuration-file.yml> <release-version>
+./update-imported-docs.py <configuration-file.yml> <release-version>
 ```
 
 예를 들면 다음과 같다.
 
 ```shell
-./update-imported-docs reference.yml 1.17
+./update-imported-docs.py reference.yml 1.17
 ```
 
 <!-- Revisit: is the release configuration used -->
@@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
 * [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
 * [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
 
-

content/ko/docs/reference/command-line-tools-reference/feature-gates.md

@@ -1,7 +1,10 @@
 ---
-weight: 10
 title: 기능 게이트
+weight: 10
 content_type: concept
+card:
+  name: reference
+  weight: 60
 ---
 
 <!-- overview -->

content/ko/docs/reference/glossary/api-eviction.md

@@ -2,7 +2,7 @@
 title: API를 이용한 축출(Eviction)
 id: api-eviction
 date: 2021-04-27
-full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
+full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/
 short_description: >
   API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
   축출 오브젝트를 만드는 프로세스이다

content/ko/docs/reference/kubectl/overview.md

@@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags]
 `cluster-info`    | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
 `completion`    | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
 `config`        | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
-`convert`    | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
+`convert`    | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
 `cordon`    | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
 `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
 `create`        | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.

content/ko/docs/reference/labels-annotations-taints.md

@@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
 
 kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
 
-## experimental.windows.kubernetes.io/isolation-type
+## experimental.windows.kubernetes.io/isolation-type (사용 중단됨) {#experimental-windows-kubernetes-io-isolation-type}
 
 예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
 
@@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려
 
 {{< note >}}
 이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
+v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다.
 {{< /note >}}
 
 ## ingressclass.kubernetes.io/is-default-class

content/ko/docs/reference/tools/_index.md

@@ -8,7 +8,7 @@ no_list: true
 ---
 
 <!-- overview -->
-쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
+쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
 
 
 <!-- body -->

content/ko/docs/reference/using-api/health-checks.md

@@ -1,5 +1,7 @@
 ---
 title: 쿠버네티스 API 헬스(health) 엔드포인트
+
+
 content_type: concept
 weight: 50
 ---
@@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
 
 {{< feature-state state="alpha" >}}
 
-각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
+각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
 개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
 `<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 대형 클러스터에 대한 고려 사항
 weight: 20
 ---
@@ -121,3 +124,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
 [클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
 여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
 노드 수를 실행할 수 있도록 도와준다.
+
+[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는 
+클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.

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

@@ -31,6 +31,7 @@ card:
 <!-- steps -->
 
 ## MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인 {#verify-mac-address}
+
 * 사용자는 `ip link` 또는 `ifconfig -a` 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
 * product_uuid는 `sudo cat /sys/class/dmi/id/product_uuid` 명령을 사용하여 확인할 수 있다.
 
@@ -239,8 +240,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
 
 ```bash
 CNI_VERSION="v0.8.2"
+ARCH="amd64"
 sudo mkdir -p /opt/cni/bin
-curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
+curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
 ```
 
 명령어 파일을 다운로드할 디렉터리 정의
@@ -259,15 +261,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에
 
 ```bash
 CRICTL_VERSION="v1.17.0"
-curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
+ARCH="amd64"
+curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
 ```
 
 `kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
 
 ```bash
 RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
+ARCH="amd64"
 cd $DOWNLOAD_DIR
-sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
+sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
 sudo chmod +x {kubeadm,kubelet,kubectl}
 
 RELEASE_VERSION="v0.4.0"

content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
 content_type: concept
 weight: 75
@@ -20,8 +25,8 @@ weight: 75
 
 ## 시작하기 전에
 
-* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
+* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
-포함한 쿠버네티스 클러스터를 생성한다.
+포함하는 쿠버네티스 클러스터를 생성한다.
 * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
 모두 비슷한 방식이라는 것이 중요하다.
 [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
@@ -100,15 +105,15 @@ spec:
 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
 
     * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
-    * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
+    * 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
-    * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
+    * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
       파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
     * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
       핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
-    * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
+    * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
       IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
     * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
-    * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
+    * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
     * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
 
 {{< note >}}
@@ -178,8 +183,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
 예를 들면,  `--register-with-taints='os=windows:NoSchedule'`
 
 모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
-윈도우 파드가 윈도우 노드에 스케줄링되려면,
+윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
-윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
+윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
 
 ```yaml
 nodeSelector:

content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md

@@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
 1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
 
     ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
+    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
     ```
 
     성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
@@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
 2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
 
     ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
+    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
     ```
 
     성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.

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

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 윈도우 노드 추가
 min-kubernetes-server-version: 1.17
 content_type: tutorial
@@ -158,7 +163,7 @@ Install-WindowsFeature -Name containers
 #### wins, kubelet 및 kubeadm 설치
 
 ```PowerShell
-   curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
 ```
 
@@ -201,7 +206,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
 #### wins, kubelet 및 kubeadm 설치
 
 ```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
 ```
 

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

@@ -128,6 +128,17 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
 
 이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다. 
 
+명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
+이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
+[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로 
+kubectl을 사용하여 삭제 및 재시작할 수 없다.
+스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고 
+20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/
+reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
+파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
+그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
+kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
+
 {{< warning >}}
 HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
 {{< /warning >}}

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

@@ -9,17 +9,17 @@ weight: 20
 <!-- overview -->
 
 이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
-{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로,
+{{< skew currentVersionAddMinor -1 >}}.x 버전에서 {{< skew currentVersion >}}.x 버전으로,
-{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.  업그레이드가 지원되지 않는 경우
+{{< skew currentVersion >}}.x 버전에서 {{< skew currentVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.  업그레이드가 지원되지 않는 경우
 마이너 버전을 건너뛴다.
 
 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
 이 페이지 대신 다음의 페이지들을 참고한다.
 
-- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -2 >}}에서 {{< skew currentVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
-- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -3 >}}에서 {{< skew currentVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
-- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -4 >}}에서 {{< skew currentVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
-- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew currentVersionAddMinor -5 >}}에서 {{< skew currentVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 
 추상적인 업그레이드 작업 절차는 다음과 같다.
 
@@ -45,19 +45,19 @@ weight: 20
 
 ## 업그레이드할 버전 결정
 
-OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다.
+OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew currentVersion >}})을 찾는다.
 
 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
     apt update
     apt-cache madison kubeadm
-    # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
+    # 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
-    # {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
+    # {{< skew currentVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
     yum list --showduplicates kubeadm --disableexcludes=kubernetes
-    # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
+    # 목록에서 최신 버전({{< skew currentVersion >}})을 찾는다
-    # {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
+    # {{< skew currentVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -74,18 +74,18 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
 
 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
+    # {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
     apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubeadm
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
+    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
-    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -120,13 +120,13 @@ OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVe
 
     ```shell
     # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
-    sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
+    sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
     ```
 
     명령이 완료되면 다음을 확인해야 한다.
 
     ```
-    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!
+    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!
 
     [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
     ```
@@ -171,20 +171,20 @@ sudo kubeadm upgrade apply
 {{< tabs name="k8s_install_kubelet" >}}
 {{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
     <pre>>
-    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
     </pre>
 {{< /tab >}}
 {{< tab name="CentOS, RHEL 또는 Fedora" >}}
     <pre>
-    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
     </pre>
 {{< /tab >}}
 {{< /tabs >}}
@@ -216,18 +216,18 @@ sudo systemctl restart kubelet
 
 {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubeadm
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 
@@ -254,18 +254,18 @@ sudo systemctl restart kubelet
 
 {{< tabs name="k8s_kubelet_and_kubectl" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}
 

content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 네트워크 폴리시로 실리움(Cilium) 사용하기
 content_type: task
 weight: 20
@@ -22,44 +25,59 @@ weight: 20
 
 실리움에 쉽게 친숙해지기 위해
 Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
-[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
+[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
 
-Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
+Minikube를 시작하려면 최소 버전으로 >= v1.5.2 가 필요하고,
 다음의 실행 파라미터로 실행한다.
 
 ```shell
 minikube version
 ```
 ```
-minikube version: v1.3.1
+minikube version: v1.5.2
 ```
 
 ```shell
-minikube start --network-plugin=cni --memory=4096
+minikube start --network-plugin=cni
 ```
 
-BPF 파일시스템을 마운트한다
+minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
+실리움은 클러스터 구성을 자동으로 감지하고 
+성공적인 설치를 위해 적절한 구성 요소를 설치한다.
 
 ```shell
-minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
+curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
+sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
+rm cilium-linux-amd64.tar.gz
+cilium install
 ```
 
-Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
-간단한 ``올인원`` YAML 파일로 배포할 수 있다.
-
-```shell
-kubectl create -f  https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
 ```
-```
+🔮 Auto-detected Kubernetes kind: minikube
-configmap/cilium-config created
+✨ Running "minikube" validation checks
-serviceaccount/cilium created
+✅ Detected minikube version "1.20.0"
-serviceaccount/cilium-operator created
+ℹ️  Cilium version not set, using default version "v1.10.0"
-clusterrole.rbac.authorization.k8s.io/cilium created
+🔮 Auto-detected cluster name: minikube
-clusterrole.rbac.authorization.k8s.io/cilium-operator created
+🔮 Auto-detected IPAM mode: cluster-pool
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
+🔮 Auto-detected datapath mode: tunnel
-clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
+🔑 Generating CA...
-daemonset.apps/cilium create
+2021/05/27 02:54:44 [INFO] generate received request
-deployment.apps/cilium-operator created
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
+🔑 Generating certificates for Hubble...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
+🚀 Creating Service accounts...
+🚀 Creating Cluster roles...
+🚀 Creating ConfigMap...
+🚀 Creating Agent DaemonSet...
+🚀 Creating Operator Deployment...
+⌛ Waiting for Cilium to be installed...
 ```
 
 시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
@@ -82,14 +100,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
 파드의 목록을 보려면 다음을 실행한다.
 
 ```shell
-kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system -l k8s-app=cilium
 ```
 
 다음과 유사한 파드의 목록을 볼 것이다.
 
 ```console
 NAME           READY   STATUS    RESTARTS   AGE
-cilium-6rxbd    1/1     Running   0          1m
+cilium-kkdhz   1/1     Running   0          3m23s
 ...
 ```
 

content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md

@@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
 다음 커맨드를 실행한다.
 
 ```shell
-kubectl create secret generic dev-db-secret \
+kubectl create secret generic db-user-pass \
   --from-literal=username=devuser \
   --from-literal=password='S!B\*d$zDsb='
 ```

content/ko/docs/tasks/manage-daemon/update-daemon-set.md

@@ -11,6 +11,8 @@ weight: 10
 
 ## {{% heading "prerequisites" %}}
 
+{{< include "task-tutorial-prereqs.md" >}}
+
 <!-- steps -->
 
 ## 데몬셋 업데이트 전략