[ko] Update outdated files in dev-1.20-ko.6 (p2)

content/ko/docs/concepts/architecture/nodes.md

@@ -57,7 +57,7 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 정상적인지 확인한다.
 
 상태 확인을 중지하려면 사용자 또는 {{< glossary_tooltip term_id="controller" text="컨트롤러">}}에서
-노드 오브젝트를 명시적으로 삭제해야한다.
+노드 오브젝트를 명시적으로 삭제해야 한다.
 {{< /note >}}
 
 노드 오브젝트의 이름은 유효한

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -55,7 +55,7 @@ sitemap:
 
 ## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do}
 
-컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
+컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
 
 그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.
 

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -66,7 +66,7 @@ weight: 40
 다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
 
 {{< note >}}
-인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다.
+인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야 한다.
 {{< /note >}}
 
 

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

@@ -311,7 +311,7 @@ IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을
 
 {{< note >}}
 IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
-사용 가능하도록 해야한다.
+사용 가능하도록 해야 한다.
 
 kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을
 사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는
@@ -1120,7 +1120,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
 않아도 된다. 그것은 격리 실패이다.
 
 서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
-서비스가 충돌하지 않도록 해야한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
+서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
 할당하여 이를 수행한다.
 
 각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는

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

@@ -68,7 +68,7 @@ parameters:
 ### 드라이버
 
 볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을
-결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다.
+결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야 한다.
 
 ### 삭제정책(DeletionPolicy)
 

content/ko/docs/concepts/storage/volumes.md

@@ -1332,7 +1332,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
 * `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume`
   그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는
   민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는
-  선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
+  선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에
   둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다.
 * `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해
   CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿

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

@@ -341,7 +341,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다.
 {{< /note >}}
 
-* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다.
+* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트해야 한다.
 그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가
 이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며,
 새로운 레플리카셋을 생성하게 된다.
@@ -1060,7 +1060,7 @@ echo $?
 이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
 
 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
-레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
+레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
 
 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고,
 명시되지 않으면 기본값이 된다.

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

@@ -49,7 +49,7 @@ kubectl 명령에서 숏컷으로 사용된다.
 
 {{< codenew file="controllers/replication.yaml" >}}
 
-예제 파일을 다운로드 한 후 다음 명령을 실행하여 예제 작업을 실행하라.
+예제 파일을 다운로드한 후 다음 명령을 실행하여 예제 작업을 실행하라.
 
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/replication.yaml

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

@@ -107,7 +107,7 @@ spec:
 
 ## 파드 셀렉터
 
-스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
+스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
 
 ## 파드 신원
 
@@ -173,7 +173,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다.
-이것은 반드시 수동으로 해야한다.
+이것은 반드시 수동으로 해야 한다.
 
 ### 파드 이름 레이블
 

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

@@ -103,7 +103,7 @@ PDB는 자발적 중단으로
 일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
 
 클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
-[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
+[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)로
 불리는 PodDisruptionBudget을 준수하는 도구를 이용해야 한다.
 
 예를 들어, `kubectl drain` 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수

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

@@ -38,8 +38,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가
 타임아웃 기간 후에 [삭제되도록 스케줄된다](#pod-garbage-collection).
 
 파드는 자체적으로 자가 치유되지 않는다. 파드가
-{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 실패하거나,
-스케줄 작업 자체가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
+{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 해당 노드가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
 리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는
 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라
 부르는 하이-레벨 추상화를 사용하여

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

@@ -351,7 +351,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
-| `VolumeSubpath` | `true` | GA | 1.13 | - |
+| `VolumeSubpath` | `true` | GA | 1.10 | - |
 | `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 |
 | `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 |
 | `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |

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

@@ -293,12 +293,12 @@ kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{pr
 ## 실행 중인 파드와 상호 작용
 
 ```bash
-kubectl logs my-pod                                 # 파드 로그(stdout) 덤프
+kubectl logs my-pod                                 # 파드 로그 덤프 (stdout)
 kubectl logs -l name=myLabel                        # name이 myLabel인 파드 로그 덤프 (stdout)
-kubectl logs my-pod --previous                      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout) 덤프
-kubectl logs my-pod -c my-container                 # 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
+kubectl logs my-pod --previous                      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout)
+kubectl logs my-pod -c my-container                 # 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
 kubectl logs -l name=myLabel -c my-container        # name이 myLabel인 파드 로그 덤프 (stdout)
-kubectl logs my-pod -c my-container --previous      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout, 멀티-컨테이너 경우) 덤프
+kubectl logs my-pod -c my-container --previous      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
 kubectl logs -f my-pod                              # 실시간 스트림 파드 로그(stdout)
 kubectl logs -f my-pod -c my-container              # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
 kubectl logs -f -l name=myLabel --all-containers    # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
@@ -317,6 +317,18 @@ kubectl top pod POD_NAME --containers               # 특정 파드와 해당 
 kubectl top pod POD_NAME --sort-by=cpu              # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
 ```
 
+## 디플로이먼트, 서비스와 상호 작용
+```bash
+kubectl logs deploy/my-deployment                         # 디플로이먼트에 대한 파드 로그 덤프 (단일-컨테이너 경우)
+kubectl logs deploy/my-deployment -c my-container         # 디플로이먼트에 대한 파드 로그 덤프 (멀티-컨테이너 경우)
+
+kubectl port-forward svc/my-service 5000                  # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 동일한(5000번) 포트로 전달
+kubectl port-forward svc/my-service 5000:my-service-port  # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 <my-service-port> 라는 이름을 가진 포트로 전달
+
+kubectl port-forward deploy/my-deployment 5000:6000       # 로컬 머신의 5000번 포트를 리스닝하고, <my-deployment> 에 의해 생성된 파드의 6000번 포트로 전달
+kubectl exec deploy/my-deployment -- ls                   # <my-deployment> 에 의해 생성된 첫번째 파드의 첫번째 컨테이너에 명령어 실행 (단일- 또는 다중-컨테이너 경우)
+```
+
 ## 노드, 클러스터와 상호 작용
 
 ```bash

content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md

@@ -7,7 +7,7 @@ content_type: concept
 ---
 
 <!-- overview -->
-당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.
+당신은 쿠버네티스 커맨드 라인 도구인 `kubectl`을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 `kubectl`을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 `kubectl`과 같은 명령어를 설명한다.
 
 
 <!-- body -->

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

@@ -65,12 +65,13 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | 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) |
+| Python               | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
 | Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
 | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
 | Ruby                 | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
 | Rust                 | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
 | Rust                 | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
-| Scala                | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
+| Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) |
 | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
 | DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
 | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) |

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

@@ -155,5 +155,5 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 |-------------------------|-------------------------|-----------------------------------------------------------------------|
 | admin.conf              | kubectl                 | 클러스터 관리자를 설정한다.                                              |
 | kubelet.conf            | kubelet                 | 클러스터 각 노드를 위해 필요하다.                            |
-| controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. |
-| scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다.          |
+| controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야 한다. |
+| scheduler.conf          | kube-scheduler          | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야 한다.          |

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

@@ -219,11 +219,16 @@ sudo systemctl restart containerd
 ```
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
+
+<br />
+Powershell 세션을 띄우고, `$Version` 환경 변수를 원하는 버전으로 설정(예: `$Version=1.4.3`)한 뒤, 다음 명령어를 실행한다.
+<br />
+
 ```powershell
 # (containerd 설치)
 # containerd 다운로드
-cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz
-cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
+curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
+tar.exe xvf .\containerd-windows-amd64.tar.gz
 ```
 
 ```powershell
@@ -236,7 +241,9 @@ cd $Env:ProgramFiles\containerd\
 # - sandbox_image (쿠버네티스 pause 이미지)
 # - cni bin_dir 및 conf_dir locations
 Get-Content config.toml
-```
+
+# (선택 사항이지만, 강력히 권장됨) containerd를 Windows Defender 검사 예외에 추가
+Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe" ```
 
 ```powershell
 # containerd 시작

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

@@ -39,7 +39,7 @@ kops는 자동화된 프로비저닝 시스템인데,
 
 #### 설치
 
-[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드 한다(소스 코드로부터 빌드하는 것도 역시 편리하다).
+[releases page](https://github.com/kubernetes/kops/releases)에서 kops를 다운로드한다(소스 코드로부터 빌드하는 것도 역시 편리하다).
 
 {{< tabs name="kops_installation" >}}
 {{% tab name="macOS" %}}