[ko] Update outdated files in dev-1.23-ko.3 (M44-M77)

2022-06-20 22:34:23 +09:00 · 2022-06-20 22:34:23 +09:00 · 6d6a8be31b
parent 04e900f07b
commit 6d6a8be31b
30 changed files with 858 additions and 760 deletions
--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@ -87,7 +87,7 @@ volumeBindingMode: Immediate
 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이
 이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와
 함께 제공된다). 또한, 쿠버네티스에서 정의한
-[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을
+[사양](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)을
 따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다.
 외부 프로비저너의 작성자는 코드의 수명, 프로비저너의
 배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인
@ -241,8 +241,8 @@ allowedTopologies:
 - matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
-    - us-central1-a
-    - us-central1-b
+    - us-central-1a
+    - us-central-1b
 ```

 ## 파라미터
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@ -145,12 +145,19 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n

 {{< feature-state for_k8s_version="v1.19" state="beta" >}}

-`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
-`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
-드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI
-드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
-를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk`
-기능을 활성화해야 한다.
+`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 
+기존 인-트리 플러그인의 모든 플러그인 작업을 
+`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. 
+이 기능을 사용하려면, 클러스터에 
+[Azure Disk CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고 
+`CSIMigration` 및 `CSIMigrationAzureDisk` 기능을 활성화해야 한다.
+
+#### azureDisk CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면, 
+`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다.

 ### azureFile {#azurefile}

@ -163,15 +170,22 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n

 {{< feature-state for_k8s_version="v1.21" state="beta" >}}

-`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
-`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
-드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI
-드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver)
-를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 
+기존 인-트리 플러그인의 모든 플러그인 작업을 
+`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. 
+이 기능을 사용하려면, 클러스터에 
+[Azure File CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 
+`CSIMigration` 및 `CSIMigrationAzureFile` 기능을 활성화해야 한다.

 Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.

+#### azureFile CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면, 
+`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다.
+
 ### cephfs

 `cephfs` 볼륨은 기존 CephFS 볼륨을
@ -251,7 +265,7 @@ metadata:
 spec:
  containers:
    - name: test
-      image: busybox
+      image: busybox:1.28
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
@ -879,9 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에
 * 또한, 트리 내(in-tree) 스토리지클래스의 
  `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 
  `adminSecretName` 값이 `adminId` 파라미터 값의 
-  base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다.
-
-{{< /note >}}
+  base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}}

 ### secret

@ -1130,7 +1142,7 @@ spec:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
-    image: busybox
+    image: busybox:1.28
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 # │ │ │ ┌───────────── 월 (1 - 12)
 # │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
 # │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
-# │ │ │ │ │
+# │ │ │ │ │                                   또는 sun, mon, tue, wed, thu, fri, sat
 # │ │ │ │ │
 # * * * * *
 ```
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 `.spec.selector` 필드는 파드 셀렉터이다. 이것은
 [잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다.

-쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
-파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
-셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다.
-또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다.
-파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
+`.spec.template`의 레이블과 매치되는 
+파드 셀렉터를 명시해야 한다.
+또한, 한 번 데몬셋이 만들어지면 
+`.spec.selector` 는 바꿀 수 없다.
+파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.

 `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.

@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.

-만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 
-일치하지 않는 구성은 API에 의해 거부된다.
+`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다. 
+이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다.

 ### 오직 일부 노드에서만 파드 실행

@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 ### 기본 스케줄러로 스케줄

-{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
+{{< feature-state for_k8s_version="1.17" state="stable" >}}

 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
    기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).

-    예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
-    이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
-    충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
-    이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
+    예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음, 
+    이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다. 
+    충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. 
+    이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. 
+    디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다.

 * 디플로이먼트의 세부 정보 가져오기
  ```shell
@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
      Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
    ```
-    처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서
-    3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
-    디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로   스케일 업한 다음
-    이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다.
-    이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
+    처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고 
+    3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. 
+    디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다. 
+    그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다. 
+    이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 
    마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다.

+{{< note >}}
+쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며, 
+이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다. 
+그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며, 
+종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다.
+{{< /note >}}
+
 ### 롤오버(일명 인-플라이트 다중 업데이트)

 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@ -308,7 +308,7 @@ spec:

 ### 완료된 잡을 위한 TTL 메커니즘

-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}

 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@ -631,7 +631,8 @@ spec:

 이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 
 이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다. 
-사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+사용자가 느낄 수 있는 유일한 차이점은 
+컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
 {{< /note >}}

 이 기능이 활성화되지 않으면, 잡 
--- a/content/ko/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md
@ -223,8 +223,6 @@ pod2             1/1     Running   0          36s

 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
-쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
-API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.

 레플리카셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.

-REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
-레플리케이션 컨트롤러를 삭제).
+REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 
+명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제).

 ### 레플리케이션 컨트롤러만 삭제

@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적

 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.

-REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
+REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.

 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@ -115,7 +115,7 @@ spec:

 ### 파드 셀렉터

-스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
+스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.

 ### 볼륨 클레임 템플릿

@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 되기 전까지 종료되지 않는다.

 ### 파드 관리 정책
-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를
-통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
+스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 
+고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.

 #### OrderedReady 파드 관리

@ -242,6 +242,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
 받지 않는다.

+
 ## 업데이트 전략

 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
@ -255,8 +256,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.

 `RollingUpdate`(롤링 업데이트)
-: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
+`RollingUpdate` 업데이트 전략은 스테이트풀셋의 파드에 대한 자동화된 롤링 업데이트를 구현한다. 이는 기본 업데이트 전략이다.

 ## 롤링 업데이트

--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@ -180,7 +180,7 @@ spec:
    spec:
      containers:
      - name: hello
-        image: busybox
+        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 여기까지 파드 템플릿이다
@ -251,20 +251,19 @@ spec:

 ### 파드 네트워킹

-각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
-모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
-공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한
-컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
-*파드 외부의* 엔티티와 통신할 때,
-공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
-파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
-`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
-POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
-통신할 수도 있다. 다른 파드의 컨테이너는
-고유한 IP 주소를 가지며
-[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다.
-다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
-사용하여 통신할 수 있다.
+각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 
+파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며, 
+여기에는 IP 주소와 네트워크 포트가 포함된다. 
+파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는 
+`localhost` 를 사용하여 서로 통신할 수 있다. 
+파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, 
+공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. 
+파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, 
+`localhost` 를 통해 서로를 찾을 수 있다. 
+파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 
+표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. 
+다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다. 
+다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.

 파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
 종료 시간이 표시된다.

-컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
-실행된다.
+컨테이너에 구성된 `preStop` 훅이 있는 경우, 
+이 훅은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다.

 ## 컨테이너 재시작 정책 {#restart-policy}

--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -12,14 +12,6 @@ obsolete -->

 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.

-{{< note >}}
-v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
-[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
-[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
-`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다
-{{< /note >}}
-
 <!-- body -->

 ## 필수 구성 요소
@ -306,11 +298,12 @@ class zoneC cluster;
 예시 구성은 다음과 같다.

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
-  - pluginConfig:
+  - schedulerName: default-scheduler
+    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
@ -366,11 +359,12 @@ defaultConstraints:
 `defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
-  - pluginConfig:
+  - schedulerName: default-scheduler
+    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints: []
--- a/content/ko/docs/contribute/_index.md
+++ b/content/ko/docs/contribute/_index.md
@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
 class S,T,U spacewhite
 class first,second,third white
 {{</ mermaid >}}
-***그림 - 신규 기여자를 위한 시작 가이드***
+그림 1. 신규 기여자를 위한 시작 가이드.

-위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
+그림 1은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!

 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
 역할과 권한에 대한 자세한 내용은
@ -105,7 +105,7 @@ class first,second,third white

 ## 첫 번째 기여

-몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
+몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 그림 2는 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.

 <!-- 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 -->
@ -136,7 +136,7 @@ class A,B,D,E,F,G grey
 class S,T spacewhite
 class first,second white
 {{</ mermaid >}}
-***그림 - 첫 기여를 위한 준비***
+그림 2. 첫 기여를 위한 준비.

 - [기여 개요](/ko/docs/contribute/new-content/)를 읽고
  기여할 수 있는 다양한 방법에 대해 알아봅니다.
--- a/content/ko/docs/contribute/advanced.md
+++ b/content/ko/docs/contribute/advanced.md
@ -86,6 +86,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/
 - 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다.
 - 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다.
 - 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다.
+- 월간 미팅을 개최하여 새로운 기여자에게 도움을 주고 조언을 해 준다.

 현재 새로운 기여자 홍보대사는 각 SIG-Docs 회의와 [쿠버네티스 #sig-docs 채널](https://kubernetes.slack.com)에서 발표된다.

--- a/content/ko/docs/contribute/participate/pr-wranglers.md
+++ b/content/ko/docs/contribute/participate/pr-wranglers.md
@ -48,8 +48,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
  CLA에 서명한 후 PR을 열 수 있음을 알린다.
  **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
 - [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
-  멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
-  지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
+  멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
 - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
  병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
 - [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
@ -88,3 +87,17 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
 [`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.

 {{< /note >}}
+
+## PR 랭글러 섀도우 프로그램
+
+2021년 말에, SIG Docs는 PR 랭글러 섀도우 프로그램을 도입했다. 이 프로그램은 새로운 기여자가 PR 랭글링 과정을 이해하는 데 도움을 주기 위해 도입되었다.
+
+### 섀도우 되기
+
+- PR 랭글러 섀도우 활동에 관심이 있다면, [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)에서 올해의 PR 랭글링 스케줄을 확인하고 지원한다.
+
+- 쿠버네티스 org 멤버는 [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수정하여 기존 PR 랭글러를 1주일 간 섀도잉할 수 있다.
+
+- 쿠버네티스 org 비 멤버는 [#sig-docs 슬랙 채널](https://kubernetes.slack.com/messages/sig-docs)에서 특정 주간에 대해 기존 PR 랭글러에 대한 섀도잉을 요청할 수 있다. Brad Topol (`@bradtopol`) 또는 [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 중 한 명에게 연락하면 된다.
+
+- PR 랭글러 섀도워로 지원했다면, [쿠버네티스 슬랙](https://slack.k8s.io)에서 PR 랭글러에게 자신을 소개한다.
--- a/content/ko/docs/contribute/review/reviewing-prs.md
+++ b/content/ko/docs/contribute/review/reviewing-prs.md
@ -36,7 +36,7 @@ weight: 10

 ## 리뷰 과정

-일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
+일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.

 <!-- 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 -->
@ -67,7 +67,7 @@ class S,T spacewhite
 class third,fourth white
 {{</ mermaid >}}

-***그림 - 리뷰 과정 절차***
+그림 1. 리뷰 과정 절차.

 1.  [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
    이동한다.
--- a/content/ko/docs/home/_index.md
+++ b/content/ko/docs/home/_index.md
@ -60,7 +60,7 @@ cards:
  title: K8s 릴리스 노트
  description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
  button: "쿠버네티스 다운로드"
-  button_path: "/docs/setup/release/notes"
+  button_path: "/releases/download"
 - name: about
  title: 문서에 대하여
  description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다.
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@ -43,7 +43,7 @@ no_list: true

 ## CLI

-* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
+* [kubectl](/ko/docs/reference/kubectl/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
    * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
 * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.

@ -66,6 +66,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로

 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
  [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
+
 ## API 설정

 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
@ -73,10 +74,12 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
 제공하지 않는다.

-
+* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
 * [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
+* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
 * [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
  [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
+* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
 * [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
  [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@ -29,7 +29,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.

 ```shell
--feature-gates="...,GracefulNodeShutdown=true"
+--feature-gates=...,GracefulNodeShutdown=true
 ```

 다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를
@ -63,7 +63,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
 | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
 | `AppArmor` | `true` | 베타 | 1.4 | |
-| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
+| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
+| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
 | `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
 | `CPUManager` | `true` | 베타 | 1.10 | |
 | `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | |
@ -74,7 +75,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 | `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
 | `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
 | `CSIMigration` | `true` | 베타 | 1.17 | |
-| `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
+| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 |
 | `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 |
 | `CSIMigrationAWS` | `true` | 베타 | 1.23 | |
 | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
@ -129,6 +130,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
 | `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
 | `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | |
+| `GracefulNodeShutdownBasedOnPodPriority` | `true` | 베타 | 1.24 | |
 | `GRPCContainerProbe` | `false` | 알파 | 1.23 | |
 | `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | |
 | `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
@ -428,6 +430,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | 1.21 |
 | `ServerSideApply` | `true` | GA | 1.22 | - |
+| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | - |
 | `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
 | `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 |
 | `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
@ -579,48 +582,58 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다.
 - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
  대한 제한을 보고하도록 한다.
-  자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
+  자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 
+  참고한다.
 - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
  포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
  더 가까운 노드가 선호된다.
 - `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다.
  자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
  참고한다.
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
-  마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
-  확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
-  `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
-  자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
-  확인한다.
+- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 
+  서비스어카운트 볼륨을 마이그레이션한다. 
+  클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 
+  확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 
+  이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 
+  `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. 
+  자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다.
 - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가
  kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면,
  cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록
-  [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
+  [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 
+  [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
  리더 마이그레이션(Leader Migration)을 활성화한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
  [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다. 
+- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 
+  미세 조정을 허용한다. 
  이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다.
  이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다.
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다. 
+- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 
+  미세 조정을 허용한다. 
  이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다.
  이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다.
 - `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
-컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
-더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
+- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 
+  로그 파일 사이즈 기본값은 10MB이며, 
+  컨테이너 당 최대 로그 파일 수 기본값은 5이다. 
+  이 값은 kubelet 환경설정으로 변경할 수 있다. 
+  더 자세한 내용은 
+  [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
 - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
-  자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)
-  문서를 참고한다.
+  자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을
+  참고한다.
 - `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된
  모든 로직을 활성화한다.
 - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
 - `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서
  사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
-  AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에
-  EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로
-  폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
+- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 
+  AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 
+  이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
 - `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS
  인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
@ -630,21 +643,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  더 이상 사용되지 않는다. 
 - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
  Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
-  노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
-  AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
-  필요하다.
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리
-  플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을
-  Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
-  라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
-  플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
-  있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해
-  더 이상 사용되지 않는다.
+  이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
+  이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
+- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 
+  Azure-Disk 인-트리 플러그인 등록을 중지하고 
+  shim 및 변환 로직을 사용하여 
+  볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 
+  클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 
+  AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 
+  이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 
+  `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다.
 - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
  Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
-  노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
-  AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
-  필요하다.
+  이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
+  이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
 - `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을
  Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
@ -654,46 +672,57 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  `InTreePluginAzureFileUnregister` 기능 플래그로 인해
  더 이상 사용되지 않는다.
 - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
-  GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
-  PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
-  지원한다. CSIMigration 기능 플래그가 필요하다.
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 
-  Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. 
-  클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, 
-  Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. 
-  이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 
-  `InTreePluginRBDUnregister` 기능 플래그에 의해 
-  사용 중단되었다.
+  GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 
+  이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
+  이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
 - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD
  인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
  인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
  CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
-  플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
+  플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 
+  이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
  더 이상 사용되지 않는다.
 - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
-  Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
-  Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
-  Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 
+  이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
+  이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
 - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서
  Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
  플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
  클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
-  Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
+  Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 
+  이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 
  더 이상 사용되지 않는다.
+- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 
+  Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. 
+  클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, 
+  Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. 
+  이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해 
+  사용 중단되었다.
 - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
  라우팅하는 shim 및 변환 로직을 사용한다.
-  노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
-  인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 
+  인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다. 
+  프로비전 동작에 대해서는 폴백을 지원하지 않는데, 
+  프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
+  이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
 - `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
  vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
  CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
-  클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
+  클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 
+  이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
  더 이상 사용되지 않는다.
 - `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 
  Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. 
-  Portworx CSI 드라이버가 설치 및 설정되어 있어야 하며, kube-controller-manager와 kubelet 환경 설정 내에 `CSIMigrationPortworx=true` 기능 게이트가 활성화되어 있어야 한다.
- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
+  Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다.
+- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
 - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
  호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
  마운트할 수 있다.
@ -721,7 +750,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  동일한 컨트롤러의 버전 1이 선택된다.
 - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
  `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다.
+- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 
+  검증 규칙을 기반으로 커스텀 리소스를 검증하는 
+  표현 언어 검증(expression language validation)을 CRD에 활성화한다.
 - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
  자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
  확인한다.
@ -804,7 +835,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
  사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
  재 매핑이 활성화된 경우에만 활성화해야 한다.
- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다.
+- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 
+  버그를 수정한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
 - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
  볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원
@ -817,8 +849,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  참조한다.
 - `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때 
  kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다.
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
+- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. 
+  [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
+- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 
+  PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
 - `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
  개별 컨테이너 메트릭을 기반으로 확장한다.
 - `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
@ -830,10 +864,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 - `HyperVContainer`: 윈도우 컨테이너를 위한
  [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
  기능을 활성화한다.
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. 
-  쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
+- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 
+  이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. 
+  쿠버네티스 {{< skew currentVersion >}}에서, 
+  `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
 - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
  변경할 수 없는(immutable) 것으로 표시할 수 있다.
+- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 
+  완료 인덱스에 따라 관리할 수 있도록 허용한다.
+- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 
+  `IngressClass` 리소스를 참조할 수 있도록 허용한다. 
+  이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다.
+- `Initializers`: Initializers 어드미션 플러그인을 사용하여, 
+  오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다.
 - `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 
  플러그인의 등록을 중지한다.
 - `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 
@ -850,13 +893,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  플러그인의 등록을 중지한다.
 - `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 
  플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
-  완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
-  한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
-  `Scope` 와 `Namespace` 2개의 필드를 추가한다.
- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의
-  비동기 조정을 허용한다.
 - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
  기능을 활성화한다.
 - `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 
@ -874,16 +910,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  kubelet 구성을 로드할 수 있다.
  자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
  참고한다.
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서 kubelet 실행을 활성화한다.
+- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 
+  kubelet exec 자격 증명 공급자를 활성화한다.
+- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서 
+  kubelet 실행을 활성화한다.
  [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다.
 - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
  플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
 - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
  [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
  참고한다.
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다.
-  이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를
+- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 
+  `GetAllocatableResources` 기능을 활성화한다.
+  이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 
+  할당 가능 자원에 대한 정보를
  [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다.
 - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
  `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
@ -903,18 +943,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
 - `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 
  메모리 어피니티를 설정할 수 있다.
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
+- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 
+  파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
 - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
  사용을 활성화한다.
 - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
  자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
 - `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable)
-  {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가)
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy)	오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
+  {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. 
+  (네임스페이스의 이름도 변경 불가)
+- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy)	오브젝트에서 단일 포트를 지정하는 것 대신에 
+  포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
 - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
  사용을 활성화한다.
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
+- `NodeLease`: 새로운 리스(Lease) API가 
+  노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
 - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
  반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
  더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
@ -922,8 +966,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 - `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 
  "enum" 필드 채우기를 활성화한다.
 - `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
-  삭제되지 않도록 한다.
 - `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
   [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
 - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
@ -931,8 +973,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 - `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 
  CRI 컨테이너 런타임으로부터 수집하도록 설정한다.
 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과
-  [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
+- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 
+  기능과
+  [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 
+  쿼터 범위 기능을 활성화한다.
 - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
  기능을 활성화한다.
 - `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를
@ -948,12 +992,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  지정된 노드를 먼저 검사할지 여부를 
  스케줄러에 알려준다.
 - `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
-  `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
+  `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 
+  기능을 활성화한다.
  더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
 - `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
  컨테이너의 proc 타입의 마운트를 제어할 수 있다.
 - `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록 
  kube-proxy를 활성화한다.
+- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
+  삭제되지 않도록 한다.
 - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
  더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
  (현재 메모리만 해당).
@ -966,8 +1013,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 - `RemainingItemCount`: API 서버가
  [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
  응답에서 남은 항목 수를 표시하도록 허용한다.
- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고
-  제거한다.
+- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고 제거한다.
 - `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을
  관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다.
 - `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중
@ -982,7 +1028,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
  참조한다.
 - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
-  자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
+  자세한 내용은 
+  [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
 - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
  자세한 사항은
  [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
@ -994,12 +1041,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
  스케줄링할 수 있다.
 - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
  _SCTP_ `protocol` 값을 활성화한다.
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다.
+- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 
+  `RuntimeDefault`을 사용한다.
  seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다.
 - `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여
  목록 작업을 가속화할 수 있다.
 - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
  경로를 활성화한다.
+- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. 
+  이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라 
+  API 서버 사이드에서 수행됨을 의미한다.
 - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
  JWKS URL)를 활성화한다. 자세한 내용은
  [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을
@ -1007,7 +1058,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
 - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다.
 - `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다.
 - `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다.
- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은
+- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 
+  자세한 내용은
  [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
 - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를
--- a/content/ko/docs/reference/glossary/api-eviction.md
+++ b/content/ko/docs/reference/glossary/api-eviction.md
@ -10,7 +10,6 @@ aka:
 tags:
  - operation
 ---
-
 API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)를 사용하여
 생성된 `Eviction` 오브젝트로 파드를 정상 종료한다.

@ -20,4 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api
 축출 API를 직접 호출해 축출 요청을 할 수 있다.
 `Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다.

+API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 
+[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다.
+
 API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다.
+
+* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다.
--- a/content/ko/docs/reference/glossary/kubectl.md
+++ b/content/ko/docs/reference/glossary/kubectl.md
@ -2,18 +2,20 @@
 title: Kubectl
 id: kubectl
 date: 2018-04-12
-full_link: /docs/user-guide/kubectl-overview/
+full_link: /ko/docs/reference/kubectl/
 short_description: >
-  쿠버네티스 API 서버와 통신하기 위한 커맨드라인 툴.
+  쿠버네티스 클러스터와 통신하기 위한 커맨드라인 툴.

 aka:
+- kubectl
 tags:
 - tool
 - fundamental
 ---
- {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} 서버와 통신하기 위한 커맨드라인 툴.
+쿠버네티스 API를 사용하여 
+쿠버네티스 클러스터의 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}과 
+통신하기 위한 커맨드라인 툴

 <!--more-->

-사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다.
-
+사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 `kubectl`을 사용할 수 있다.
--- a/content/ko/docs/reference/glossary/namespace.md
+++ b/content/ko/docs/reference/glossary/namespace.md
@ -2,9 +2,9 @@
 title: 네임스페이스(Namespace)
 id: namespace
 date: 2018-04-12
-full_link: /ko/docs/concepts/overview/working-with-objects/namespaces
+full_link: /ko/docs/concepts/overview/working-with-objects/namespaces/
 short_description: >
-  쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.
+  쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화.

 aka: 
 tags:
--- a/content/ko/docs/reference/glossary/pod-security-policy.md
+++ b/content/ko/docs/reference/glossary/pod-security-policy.md
@ -2,7 +2,7 @@
 title: 파드 시큐리티 폴리시(Pod Security Policy)
 id: pod-security-policy
 date: 2018-04-12
-full_link: /ko/docs/concepts/policy/pod-security-policy/
+full_link: /ko/docs/concepts/security/pod-security-policy/
 short_description: >
  파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.

@ -17,3 +17,4 @@ tags:

 파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다.

+파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다.
--- a/content/ko/docs/reference/issues-security/security.md
+++ b/content/ko/docs/reference/issues-security/security.md
@ -19,8 +19,6 @@ weight: 20

 보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입한다.

-[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드도 구독할 수 있다.
-
 ## 취약점 보고

 우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다.
--- a/content/ko/docs/reference/kubectl/_index.md
+++ b/content/ko/docs/reference/kubectl/_index.md
@ -1,5 +1,556 @@
 ---
-title: "kubectl"
+title: 명령줄 도구 (kubectl)
+content_type: reference
 weight: 60
+no_list: true
+card:
+  name: reference
+  weight: 20
 ---

+<!-- overview -->
+{{< glossary_definition prepend="쿠버네티스는 다음을 제공한다: " term_id="kubectl" length="short" >}}
+
+이 툴의 이름은 `kubectl`이다.
+
+구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다.
+KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+파일을 지정할 수 있다.
+
+이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
+지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
+[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
+
+설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고하고, 
+빠른 가이드는 [치트 시트](/ko/docs/reference/kubectl/cheatsheet/)를 참고한다. `docker` 명령줄 도구에 익숙하다면, 
+[도커 사용자를 위한 `kubectl`](/ko/docs/reference/kubectl/docker-cli-to-kubectl/)에서 대응되는 쿠버네티스 명령어를 볼 수 있다.
+
+<!-- body -->
+
+## 구문
+
+터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다.
+
+```shell
+kubectl [command] [TYPE] [NAME] [flags]
+```
+
+다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
+
+* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
+예: `create`, `get`, `describe`, `delete`
+
+* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
+  단수형, 복수형 또는 약어 형식을 지정할 수 있다.
+  예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
+
+   ```shell
+   kubectl get pod pod1
+   kubectl get pods pod1
+   kubectl get po pod1
+   ```
+
+* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods`
+
+   여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
+
+   * 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
+
+      * 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`<br/>
+      예: `kubectl get pod example-pod1 example-pod2`
+
+      * 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
+      예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
+
+   * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
+
+      * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
+     예: `kubectl get -f ./pod.yaml`
+
+* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
+
+{{< caution >}}
+커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
+{{< /caution >}}
+
+도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
+
+## 클러스터 내 인증과 네임스페이스 오버라이드
+
+기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
+
+하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
+
+**`POD_NAMESPACE` 환경 변수**
+
+`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
+
+명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
+
+**kubectl이 서비스어카운트 토큰을 관리하는 방법**
+
+만약
+* 쿠버네티스 서비스 어카운트 토큰 파일이 
+  `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
+* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
+* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
+* kubectl 명령에 네임스페이스를 명시하지 않으면
+
+kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. 
+kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
+이는 클러스터 외부에서 실행되었을 때와는 다른데, 
+kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우 
+kubectl은 `default` 네임스페이스에 대해 동작한다.
+
+## 명령어
+
+다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
+
+명령어       | 구문    |       설명
+-------------------- | -------------------- | --------------------
+`alpha`    | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
+`annotate`    | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
+`api-resources`    | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다.
+`api-versions`    | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다.
+`apply`            | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
+`attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
+`auth`    | `kubectl auth [flags] [options]` | 승인을 검사한다.
+`autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
+`certificate`    | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다.
+`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 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
+`cordon`    | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
+`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
+`create`        | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
+`delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다.
+`describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 하나 이상의 리소스의 자세한 상태를 표시한다.
+`diff`        | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
+`drain`    | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다.
+`edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다.
+`exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다.
+`explain`    | `kubectl explain  [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
+`expose`        | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다.
+`get`        | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 하나 이상의 리소스를 나열한다.
+`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
+`label`        | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다.
+`logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다.
+`options`    | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
+`patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다.
+`plugin`    | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
+`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다.
+`proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다.
+`replace`        | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다.
+`rollout`    | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
+`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 클러스터에서 지정된 이미지를 실행한다.
+`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다.
+`set`    | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다.
+`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다.
+`top`    | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다.
+`uncordon`    | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다.
+`version`        | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
+`wait`    | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
+
+명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
+
+## 리소스 타입
+
+다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
+
+(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
+
+| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
+|---|---|---|---|---|
+| `bindings` | | | true | Binding |
+| `componentstatuses` | `cs` | | false | ComponentStatus |
+| `configmaps` | `cm` | | true | ConfigMap |
+| `endpoints` | `ep` | | true | Endpoints |
+| `events` | `ev` | | true | Event |
+| `limitranges` | `limits` | | true | LimitRange |
+| `namespaces` | `ns` | | false | Namespace |
+| `nodes` | `no` | | false | Node |
+| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
+| `persistentvolumes` | `pv` | | false | PersistentVolume |
+| `pods` | `po` | | true | Pod |
+| `podtemplates` | | | true | PodTemplate |
+| `replicationcontrollers` | `rc` | | true | ReplicationController |
+| `resourcequotas` | `quota` | | true | ResourceQuota |
+| `secrets` | | | true | Secret |
+| `serviceaccounts` | `sa` | | true | ServiceAccount |
+| `services` | `svc` | | true | Service |
+| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
+| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
+| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
+| `apiservices` | | apiregistration.k8s.io | false | APIService |
+| `controllerrevisions` | | apps | true | ControllerRevision |
+| `daemonsets` | `ds` | apps | true | DaemonSet |
+| `deployments` | `deploy` | apps | true | Deployment |
+| `replicasets` | `rs` | apps | true | ReplicaSet |
+| `statefulsets` | `sts` | apps | true | StatefulSet |
+| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
+| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
+| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
+| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
+| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
+| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
+| `cronjobs` | `cj` | batch | true | CronJob |
+| `jobs` | | batch | true | Job |
+| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
+| `leases` | | coordination.k8s.io | true | Lease |
+| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
+| `events` | `ev` | events.k8s.io | true | Event |
+| `ingresses` | `ing` | extensions | true | Ingress |
+| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
+| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
+| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
+| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
+| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
+| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
+| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
+| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
+| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
+| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
+| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
+| `roles` | | rbac.authorization.k8s.io | true | Role |
+| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
+| `csidrivers` | | storage.k8s.io | false | CSIDriver |
+| `csinodes` | | storage.k8s.io | false | CSINode |
+| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
+| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
+
+## 출력 옵션
+
+특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
+
+### 출력 서식화
+
+모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다.
+
+#### 구문
+
+```shell
+kubectl [command] [TYPE] [NAME] -o <output_format>
+```
+
+`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다.
+
+출력 형식 | 설명
+--------------| -----------
+`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
+`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
+`-o json`     | JSON 형식의 API 오브젝트를 출력한다.
+`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
+`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
+`-o name`     | 리소스 이름만 출력한다.
+`-o wide`     | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
+`-o yaml`     | YAML 형식의 API 오브젝트를 출력한다.
+
+##### 예제
+
+이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
+
+```shell
+kubectl get pod web-pod-13je7 -o yaml
+```
+
+기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
+[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
+
+#### 사용자 정의 열 {#custom-columns}
+
+사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
+사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
+
+##### 예제
+
+인라인:
+
+```shell
+kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
+```
+
+템플릿 파일:
+
+```shell
+kubectl get pods <pod-name> -o custom-columns-file=template.txt
+```
+
+`template.txt` 파일에 포함된 내용은 다음과 같다.
+
+```
+NAME          RSRC
+metadata.name metadata.resourceVersion
+```
+두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
+
+```
+NAME           RSRC
+submit-queue   610995
+```
+
+#### 서버측 열
+
+`kubectl` 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
+이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
+이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
+
+이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
+`kubectl get` 명령에 `--server-print=false` 플래그를 추가한다.
+
+##### 예제
+
+파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
+
+```shell
+kubectl get pods <pod-name> --server-print=false
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+NAME       AGE
+pod-name   1m
+```
+
+### 오브젝트 목록 정렬
+
+터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
+
+#### 구문
+
+```shell
+kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
+```
+
+##### 예제
+
+이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
+
+```shell
+kubectl get pods --sort-by=.metadata.name
+```
+
+## 예제: 일반적인 작업
+
+다음 예제 세트를 사용하여 일반적으로 사용되는 `kubectl` 조작 실행에 익숙해진다.
+
+`kubectl apply` - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
+
+```shell
+# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
+kubectl apply -f example-service.yaml
+
+# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
+kubectl apply -f example-controller.yaml
+
+# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
+kubectl apply -f <directory>
+```
+
+`kubectl get` - 하나 이상의 리소스를 나열한다.
+
+```shell
+# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
+kubectl get pods
+
+# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
+kubectl get pods -o wide
+
+# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
+kubectl get replicationcontroller <rc-name>
+
+# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
+kubectl get rc,services
+
+# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
+kubectl get ds
+
+# 노드 server01에서 실행 중인 모든 파드를 나열한다.
+kubectl get pods --field-selector=spec.nodeName=server01
+```
+
+`kubectl describe` - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
+
+```shell
+# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
+kubectl describe nodes <node-name>
+
+# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
+kubectl describe pods/<pod-name>
+
+# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
+# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
+kubectl describe pods <rc-name>
+
+# 모든 파드의 정보를 출력한다.
+kubectl describe pods
+```
+
+{{< note >}}
+`kubectl get` 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
+리소스를 검색하는 데 사용된다. 예를 들어, `-o` 또는 `--output` 플래그를
+사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
+`-w` 또는 `--watch` 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
+있다. `kubectl describe` 명령은 지정된 리소스의 여러 관련 측면을
+설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
+사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, `kubectl describe node`
+명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
+정보도 검색한다.
+{{< /note >}}
+
+`kubectl delete` - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
+
+```shell
+# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
+kubectl delete -f pod.yaml
+
+# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
+kubectl delete pods,services -l <label-key>=<label-value>
+
+# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
+kubectl delete pods --all
+```
+
+`kubectl exec` - 파드의 컨테이너에 대해 명령을 실행한다.
+
+```shell
+# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
+kubectl exec <pod-name> -- date
+
+# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
+kubectl exec <pod-name> -c <container-name> -- date
+
+# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
+kubectl exec -ti <pod-name> -- /bin/bash
+```
+
+`kubectl logs` - 파드의 컨테이너에 대한 로그를 출력한다.
+
+```shell
+# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
+kubectl logs <pod-name>
+
+# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
+kubectl logs -f <pod-name>
+```
+
+`kubectl diff` - 제안된 클러스터 업데이트의 차이점을 본다.
+
+```shell
+# "pod.json"에 포함된 리소스의 차이점을 출력한다.
+kubectl diff -f pod.json
+
+# 표준입력에서 파일을 읽어 차이점을 출력한다.
+cat service.yaml | kubectl diff -f -
+```
+
+## 예제: 플러그인 작성 및 사용
+
+`kubectl` 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
+
+```shell
+# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
+# 시작하도록 실행 파일의 이름을 지정한다.
+cat ./kubectl-hello
+```
+```shell
+#!/bin/sh
+
+# 이 플러그인은 "hello world"라는 단어를 출력한다
+echo "hello world"
+```
+작성한 플러그인을 실행 가능하게 한다
+```bash
+chmod a+x ./kubectl-hello
+
+# 그리고 PATH의 위치로 옮긴다
+sudo mv ./kubectl-hello /usr/local/bin
+sudo chown root:root /usr/local/bin
+
+# 이제 kubectl 플러그인을 만들고 "설치했다".
+# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
+kubectl hello
+```
+```
+hello world
+```
+
+```shell
+# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
+# 플러그인을 "제거"할 수 있다
+sudo rm /usr/local/bin/kubectl-hello
+```
+
+`kubectl` 에 사용할 수 있는 모든 플러그인을 보려면,
+`kubectl plugin list` 하위 명령을 사용한다.
+
+```shell
+kubectl plugin list
+```
+출력 결과는 다음과 비슷하다.
+```
+The following kubectl-compatible plugins are available:
+
+/usr/local/bin/kubectl-hello
+/usr/local/bin/kubectl-foo
+/usr/local/bin/kubectl-bar
+```
+
+`kubectl plugin list` 는 또한 실행 가능하지 않거나,
+다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
+```shell
+sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
+kubectl plugin list
+```
+```
+The following kubectl-compatible plugins are available:
+
+/usr/local/bin/kubectl-hello
+/usr/local/bin/kubectl-foo
+  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
+/usr/local/bin/kubectl-bar
+
+error: one plugin warning was found
+```
+
+플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
+구축하는 수단으로 생각할 수 있다.
+
+```shell
+cat ./kubectl-whoami
+```
+다음 몇 가지 예는 이미 `kubectl-whoami` 에
+다음 내용이 있다고 가정한다.
+```shell
+#!/bin/bash
+
+# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
+# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
+kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
+```
+
+위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한
+사용자가 포함된 출력이 제공된다.
+
+```shell
+# 파일을 실행 가능하게 한다
+sudo chmod +x ./kubectl-whoami
+
+# 그리고 PATH로 옮긴다
+sudo mv ./kubectl-whoami /usr/local/bin
+
+kubectl whoami
+Current user: plugins-user
+```
+
+## {{% heading "whatsnext" %}}
+
+* `kubectl` 레퍼런스 문서를 읽는다.
+  * kubectl [명령어 레퍼런스](/ko/docs/reference/kubectl/kubectl/)
+  * [명령줄 인자](/docs/reference/generated/kubectl/kubectl-commands/) 레퍼런스
+* [`kubectl` 사용 규칙](/docs/reference/kubectl/conventions/)에 대해 알아본다.
+* kubectl의 [JSONPath 지원](/docs/reference/kubectl/jsonpath/)에 대해 알아본다.
+* [플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아본다.
+  * 플러그인에 대해 좀 더 알아보려면, [예시 CLI 플러그인](https://github.com/kubernetes/sample-cli-plugin)을 살펴본다.
--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@ -5,6 +5,7 @@ title: kubectl 치트 시트


 content_type: concept
+weight: 10 # highlight it
 card:
  name: reference
  weight: 30
@ -38,6 +39,11 @@ complete -F __start_kubectl k
 source <(kubectl completion zsh)  # 현재 셸에 zsh의 자동 완성 설정
 echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
 ```
+### --all-namespaces 에 대한 노트
+
+`--all-namespaces`를 붙여야 하는 상황이 자주 발생하므로, `--all-namespaces`의 축약형을 알아 두는 것이 좋다.
+
+```kubectl -A```

 ## Kubectl 컨텍스트와 설정

@ -56,11 +62,11 @@ kubectl config view
 # e2e 사용자의 암호를 확인한다
 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

-kubectl config view -o jsonpath='{.users[].name}'    # 첫 번째 사용자 출력
+kubectl config view -o jsonpath='{.users[].name}'     # 첫 번째 사용자 출력
 kubectl config view -o jsonpath='{.users[*].name}'    # 사용자 리스트 조회
-kubectl config get-contexts                          # 컨텍스트 리스트 출력
-kubectl config current-context              # 현재 컨텍스트 출력
-kubectl config use-context my-cluster-name  # my-cluster-name를 기본 컨텍스트로 설정
+kubectl config get-contexts                           # 컨텍스트 리스트 출력
+kubectl config current-context                        # 현재 컨텍스트 출력
+kubectl config use-context my-cluster-name            # my-cluster-name를 기본 컨텍스트로 설정

 # 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
@ -73,6 +79,10 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

 kubectl config unset users.foo                       # foo 사용자 삭제
+
+# 컨텍스트/네임스페이스를 설정/조회하는 단축 명령 (bash 및 bash 호환 셸에서만 동작함, 네임스페이스 설정을 위해 kn 을 사용하기 전에 현재 컨텍스트가 설정되어야 함)
+alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
+alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'
 ```

 ## Kubectl apply
@ -92,10 +102,10 @@ kubectl apply -f https://git.io/vPieo          # url로부터 리소스(들) 생
 kubectl create deployment nginx --image=nginx  # nginx 단일 인스턴스를 시작

 # "Hello World"를 출력하는 잡(Job) 생성
-kubectl create job hello --image=busybox -- echo "Hello World"
+kubectl create job hello --image=busybox:1.28 -- echo "Hello World"

 # 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
-kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    
+kubectl create cronjob hello --image=busybox:1.28   --schedule="*/1 * * * *" -- echo "Hello World"

 kubectl explain pods                           # 파드 매니페스트 문서를 조회

@ -108,7 +118,7 @@ metadata:
 spec:
  containers:
  - name: busybox
-    image: busybox
+    image: busybox:1.28
    args:
    - sleep
    - "1000000"
@ -120,7 +130,7 @@ metadata:
 spec:
  containers:
  - name: busybox
-    image: busybox
+    image: busybox:1.28
    args:
    - sleep
    - "1000"
@ -172,9 +182,9 @@ kubectl get pods --selector=app=cassandra -o \
 kubectl get configmap myconfig \
  -o jsonpath='{.data.ca\.crt}'

-# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'
+# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/control-plane'
 # 으로 명명된 라벨의 결과를 제외)
-kubectl get node --selector='!node-role.kubernetes.io/master'
+kubectl get node --selector='!node-role.kubernetes.io/control-plane'

 # 네임스페이스의 모든 실행 중인 파드를 조회
 kubectl get pods --field-selector=status.phase=Running
@ -212,10 +222,10 @@ kubectl diff -f ./my-manifest.yaml

 # 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
 # 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
-kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+kubectl get nodes -o json | jq -c 'paths|join(".")'

 # 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
-kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+kubectl get pods -o json | jq -c 'paths|join(".")'

 # 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정).
 # `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다.
@ -224,7 +234,6 @@ for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo

 ## 리소스 업데이트

-
 ```bash
 kubectl set image deployment/frontend www=image:v2               # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
 kubectl rollout history deployment/frontend                      # 현 리비전을 포함한 디플로이먼트의 이력을 체크
@ -234,7 +243,7 @@ kubectl rollout status -w deployment/frontend                    # 완료될 때
 kubectl rollout restart deployment/frontend                      # "frontend" 디플로이먼트의 롤링 재시작


-cat pod.json | kubectl replace -f -                              # std로 전달된 JSON을 기반으로 파드 교체
+cat pod.json | kubectl replace -f -                              # stdin으로 전달된 JSON을 기반으로 파드 교체

 # 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴.
 kubectl replace --force -f ./pod.json
@ -253,7 +262,8 @@ kubectl autoscale deployment foo --min=2 --max=10                # 디플로이
 ## 리소스 패치

 ```bash
-kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트
+# 노드를 부분적으로 업데이트
+kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

 # 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요.
 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
@ -270,7 +280,7 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1",

 ## 리소스 편집

-편집기로 모든 API 리소스를 편집.
+선호하는 편집기로 모든 API 리소스를 편집할 수 있다.

 ```bash
 kubectl edit svc/docker-registry                      # docker-registry라는 서비스 편집
@ -310,7 +320,7 @@ kubectl logs my-pod -c my-container --previous      # 컨테이너의 이전 인
 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)
-kubectl run -i --tty busybox --image=busybox -- sh  # 대화형 셸로 파드를 실행
+kubectl run -i --tty busybox --image=busybox:1.28 -- sh  # 대화형 셸로 파드를 실행
 kubectl run nginx --image=nginx -n mynamespace      # mynamespace 네임스페이스에서 nginx 파드 1개 실행
 kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
 --dry-run=client -o yaml > pod.yaml
@ -419,7 +429,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
 kubectl get pods -A -o=custom-columns='DATA:metadata.*'
 ```

-더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/overview/#custom-columns)를 참고한다.
+더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/#custom-columns)를 참고한다.

 ### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅

@ -440,10 +450,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그

 ## {{% heading "whatsnext" %}}

-* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.
+* [kubectl 개요](/ko/docs/reference/kubectl/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.

 * [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다.

 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다.

-* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.
+* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.
--- a/content/ko/docs/reference/kubectl/jsonpath.md
+++ b/content/ko/docs/reference/kubectl/jsonpath.md
@ -1,7 +1,6 @@
 ---
 title: JSONPath 지원
 content_type: concept
-weight: 25
 ---

 <!-- overview -->
--- a/content/ko/docs/reference/kubectl/overview.md
+++ b/content/ko/docs/reference/kubectl/overview.md
@ -1,547 +0,0 @@
---
-
-
-title: kubectl 개요
-content_type: concept
-weight: 20
-card:
-  name: reference
-  weight: 20
---
-
-<!-- overview -->
-Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다.
-구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다.
-KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
-플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
-파일을 지정할 수 있다.
-
-이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
-지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
-[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
-설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고한다.
-
-<!-- body -->
-
-## 구문
-
-터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다.
-
-```shell
-kubectl [command] [TYPE] [NAME] [flags]
-```
-
-다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
-
-* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
-예: `create`, `get`, `describe`, `delete`
-
-* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
-  단수형, 복수형 또는 약어 형식을 지정할 수 있다.
-  예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
-
-   ```shell
-   kubectl get pod pod1
-   kubectl get pods pod1
-   kubectl get po pod1
-   ```
-
-* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods`
-
-   여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
-
-   * 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
-
-      * 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`<br/>
-      예: `kubectl get pod example-pod1 example-pod2`
-
-      * 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
-      예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
-
-   * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
-
-      * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
-     예: `kubectl get -f ./pod.yaml`
-
-* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
-
-{{< caution >}}
-커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
-{{< /caution >}}
-
-도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
-
-## 클러스터 내 인증과 네임스페이스 오버라이드
-
-기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
-
-하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
-
-**`POD_NAMESPACE` 환경 변수**
-
-`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
-
-명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
-
-**kubectl이 서비스어카운트 토큰을 관리하는 방법**
-
-만약
-* 쿠버네티스 서비스 어카운트 토큰 파일이 
-  `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
-* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
-* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
-* kubectl 명령에 네임스페이스를 명시하지 않으면
-
-kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. 
-kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
-이는 클러스터 외부에서 실행되었을 때와는 다른데, 
-kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우 
-kubectl은 `default` 네임스페이스에 대해 동작한다.
-
-## 명령어
-
-다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
-
-명령어       | 구문    |       설명
-------------------- | -------------------- | --------------------
-`alpha`    | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
-`annotate`    | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
-`api-resources`    | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다.
-`api-versions`    | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다.
-`apply`            | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
-`attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
-`auth`    | `kubectl auth [flags] [options]` | 승인을 검사한다.
-`autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
-`certificate`    | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다.
-`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 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
-`cordon`    | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
-`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
-`create`        | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
-`delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다.
-`describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 하나 이상의 리소스의 자세한 상태를 표시한다.
-`diff`        | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
-`drain`    | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다.
-`edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다.
-`exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다.
-`explain`    | `kubectl explain  [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
-`expose`        | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다.
-`get`        | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 하나 이상의 리소스를 나열한다.
-`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
-`label`        | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다.
-`logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다.
-`options`    | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
-`patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다.
-`plugin`    | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
-`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다.
-`proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다.
-`replace`        | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다.
-`rollout`    | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
-`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 클러스터에서 지정된 이미지를 실행한다.
-`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다.
-`set`    | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다.
-`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다.
-`top`    | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다.
-`uncordon`    | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다.
-`version`        | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
-`wait`    | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
-
-명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
-
-## 리소스 타입
-
-다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
-
-(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
-
-| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
-|---|---|---|---|---|
-| `bindings` | | | true | Binding |
-| `componentstatuses` | `cs` | | false | ComponentStatus |
-| `configmaps` | `cm` | | true | ConfigMap |
-| `endpoints` | `ep` | | true | Endpoints |
-| `events` | `ev` | | true | Event |
-| `limitranges` | `limits` | | true | LimitRange |
-| `namespaces` | `ns` | | false | Namespace |
-| `nodes` | `no` | | false | Node |
-| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
-| `persistentvolumes` | `pv` | | false | PersistentVolume |
-| `pods` | `po` | | true | Pod |
-| `podtemplates` | | | true | PodTemplate |
-| `replicationcontrollers` | `rc` | | true | ReplicationController |
-| `resourcequotas` | `quota` | | true | ResourceQuota |
-| `secrets` | | | true | Secret |
-| `serviceaccounts` | `sa` | | true | ServiceAccount |
-| `services` | `svc` | | true | Service |
-| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
-| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
-| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false |  CustomResourceDefinition |
-| `apiservices` | | apiregistration.k8s.io | false | APIService |
-| `controllerrevisions` | | apps | true | ControllerRevision |
-| `daemonsets` | `ds` | apps | true | DaemonSet |
-| `deployments` | `deploy` | apps | true | Deployment |
-| `replicasets` | `rs` | apps | true | ReplicaSet |
-| `statefulsets` | `sts` | apps | true | StatefulSet |
-| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
-| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
-| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
-| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
-| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
-| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
-| `cronjobs` | `cj` | batch | true | CronJob |
-| `jobs` | | batch | true | Job |
-| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
-| `leases` | | coordination.k8s.io | true | Lease |
-| `endpointslices` |  | discovery.k8s.io | true | EndpointSlice |
-| `events` | `ev` | events.k8s.io | true | Event |
-| `ingresses` | `ing` | extensions | true | Ingress |
-| `flowschemas` |  | flowcontrol.apiserver.k8s.io | false | FlowSchema |
-| `prioritylevelconfigurations` |  | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
-| `ingressclasses` |  | networking.k8s.io | false | IngressClass |
-| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
-| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
-| `runtimeclasses` |  | node.k8s.io | false | RuntimeClass |
-| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
-| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
-| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
-| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
-| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
-| `roles` | | rbac.authorization.k8s.io | true | Role |
-| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
-| `csidrivers` | | storage.k8s.io | false | CSIDriver |
-| `csinodes` | | storage.k8s.io | false | CSINode |
-| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
-| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
-
-## 출력 옵션
-
-특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
-
-### 출력 서식화
-
-모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다.
-
-#### 구문
-
-```shell
-kubectl [command] [TYPE] [NAME] -o <output_format>
-```
-
-`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다.
-
-출력 형식 | 설명
--------------| -----------
-`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
-`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
-`-o json`     | JSON 형식의 API 오브젝트를 출력한다.
-`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
-`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
-`-o name`     | 리소스 이름만 출력한다.
-`-o wide`     | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
-`-o yaml`     | YAML 형식의 API 오브젝트를 출력한다.
-
-##### 예제
-
-이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
-
-```shell
-kubectl get pod web-pod-13je7 -o yaml
-```
-
-기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
-[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
-
-#### 사용자 정의 열 {#custom-columns}
-
-사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
-사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
-
-##### 예제
-
-인라인:
-
-```shell
-kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
-```
-
-템플릿 파일:
-
-```shell
-kubectl get pods <pod-name> -o custom-columns-file=template.txt
-```
-
-`template.txt` 파일에 포함된 내용은 다음과 같다.
-
-```
-NAME          RSRC
-metadata.name metadata.resourceVersion
-```
-두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
-
-```
-NAME           RSRC
-submit-queue   610995
-```
-
-#### 서버측 열
-
-`kubectl` 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
-이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
-이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
-
-이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
-`kubectl get` 명령에 `--server-print=false` 플래그를 추가한다.
-
-##### 예제
-
-파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
-
-```shell
-kubectl get pods <pod-name> --server-print=false
-```
-
-출력 결과는 다음과 비슷하다.
-
-```
-NAME       AGE
-pod-name   1m
-```
-
-### 오브젝트 목록 정렬
-
-터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
-
-#### 구문
-
-```shell
-kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
-```
-
-##### 예제
-
-이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
-
-```shell
-kubectl get pods --sort-by=.metadata.name
-```
-
-## 예제: 일반적인 작업
-
-다음 예제 세트를 사용하여 일반적으로 사용되는 `kubectl` 조작 실행에 익숙해진다.
-
-`kubectl apply` - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
-
-```shell
-# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
-kubectl apply -f example-service.yaml
-
-# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
-kubectl apply -f example-controller.yaml
-
-# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
-kubectl apply -f <directory>
-```
-
-`kubectl get` - 하나 이상의 리소스를 나열한다.
-
-```shell
-# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
-kubectl get pods
-
-# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
-kubectl get pods -o wide
-
-# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
-kubectl get replicationcontroller <rc-name>
-
-# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
-kubectl get rc,services
-
-# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
-kubectl get ds
-
-# 노드 server01에서 실행 중인 모든 파드를 나열한다.
-kubectl get pods --field-selector=spec.nodeName=server01
-```
-
-`kubectl describe` - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
-
-```shell
-# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
-kubectl describe nodes <node-name>
-
-# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
-kubectl describe pods/<pod-name>
-
-# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
-# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
-kubectl describe pods <rc-name>
-
-# 모든 파드의 정보를 출력한다.
-kubectl describe pods
-```
-
-{{< note >}}
-`kubectl get` 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
-리소스를 검색하는 데 사용된다. 예를 들어, `-o` 또는 `--output` 플래그를
-사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
-`-w` 또는 `--watch` 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
-있다. `kubectl describe` 명령은 지정된 리소스의 여러 관련 측면을
-설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
-사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, `kubectl describe node`
-명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
-정보도 검색한다.
-{{< /note >}}
-
-`kubectl delete` - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
-
-```shell
-# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
-kubectl delete -f pod.yaml
-
-# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
-kubectl delete pods,services -l <label-key>=<label-value>
-
-# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
-kubectl delete pods --all
-```
-
-`kubectl exec` - 파드의 컨테이너에 대해 명령을 실행한다.
-
-```shell
-# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
-kubectl exec <pod-name> -- date
-
-# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
-kubectl exec <pod-name> -c <container-name> -- date
-
-# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
-kubectl exec -ti <pod-name> -- /bin/bash
-```
-
-`kubectl logs` - 파드의 컨테이너에 대한 로그를 출력한다.
-
-```shell
-# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
-kubectl logs <pod-name>
-
-# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
-kubectl logs -f <pod-name>
-```
-
-`kubectl diff` - 제안된 클러스터 업데이트의 차이점을 본다.
-
-```shell
-# "pod.json"에 포함된 리소스의 차이점을 출력한다.
-kubectl diff -f pod.json
-
-# 표준입력에서 파일을 읽어 차이점을 출력한다.
-cat service.yaml | kubectl diff -f -
-```
-
-## 예제: 플러그인 작성 및 사용
-
-`kubectl` 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
-
-```shell
-# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
-# 시작하도록 실행 파일의 이름을 지정한다.
-cat ./kubectl-hello
-```
-```shell
-#!/bin/sh
-
-# 이 플러그인은 "hello world"라는 단어를 출력한다
-echo "hello world"
-```
-작성한 플러그인을 실행 가능하게 한다
-```bash
-chmod a+x ./kubectl-hello
-
-# 그리고 PATH의 위치로 옮긴다
-sudo mv ./kubectl-hello /usr/local/bin
-sudo chown root:root /usr/local/bin
-
-# 이제 kubectl 플러그인을 만들고 "설치했다".
-# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
-kubectl hello
-```
-```
-hello world
-```
-
-```shell
-# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
-# 플러그인을 "제거"할 수 있다
-sudo rm /usr/local/bin/kubectl-hello
-```
-
-`kubectl` 에 사용할 수 있는 모든 플러그인을 보려면,
-`kubectl plugin list` 하위 명령을 사용한다.
-
-```shell
-kubectl plugin list
-```
-출력 결과는 다음과 비슷하다.
-```
-The following kubectl-compatible plugins are available:
-
-/usr/local/bin/kubectl-hello
-/usr/local/bin/kubectl-foo
-/usr/local/bin/kubectl-bar
-```
-
-`kubectl plugin list` 는 또한 실행 가능하지 않거나,
-다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
-```shell
-sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
-kubectl plugin list
-```
-```
-The following kubectl-compatible plugins are available:
-
-/usr/local/bin/kubectl-hello
-/usr/local/bin/kubectl-foo
-  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
-/usr/local/bin/kubectl-bar
-
-error: one plugin warning was found
-```
-
-플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
-구축하는 수단으로 생각할 수 있다.
-
-```shell
-cat ./kubectl-whoami
-```
-다음 몇 가지 예는 이미 `kubectl-whoami` 에
-다음 내용이 있다고 가정한다.
-```shell
-#!/bin/bash
-
-# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
-# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
-kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
-```
-
-위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한
-사용자가 포함된 출력이 제공된다.
-
-```shell
-# 파일을 실행 가능하게 한다
-sudo chmod +x ./kubectl-whoami
-
-# 그리고 PATH로 옮긴다
-sudo mv ./kubectl-whoami /usr/local/bin
-
-kubectl whoami
-Current user: plugins-user
-```
-
-## {{% heading "whatsnext" %}}
-
-* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.
-
-* 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다.
--- a/content/ko/docs/reference/tools/_index.md
+++ b/content/ko/docs/reference/tools/_index.md
@ -30,9 +30,6 @@ no_list: true
 [Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다.
 이 패키지는 _Helm charts_ 라고 알려져 있다.

-Helm은 미리 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 제 3자가
-관리하는 도구로, 쿠버네티스 차트(charts)라고도 알려져 있다.
-
 Helm의 용도

 * 쿠버네티스 차트로 배포된 인기있는 소프트웨어를 검색하고 사용
--- a/content/ko/docs/setup/best-practices/certificates.md
+++ b/content/ko/docs/setup/best-practices/certificates.md
@ -22,6 +22,8 @@ weight: 40
 쿠버네티스는 다음 작업에서 PKI를 필요로 한다.

 * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
+* API 서버가 kubelet과 통신하기 위한 
+  kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
 * API 서버 엔드포인트를 위한 서버 인증서
 * API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
 * API 서버에서 kubelet과 통신을 위한 클라이언트 인증서
@ -89,7 +91,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
 `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)

-`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.
+`kind`는 하나 이상의 [x509 키 사용](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.

 | 종류   | 키 사용                                                                         |
 |--------|---------------------------------------------------------------------------------|