First Korean l10n work for release-1.19

- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544)
- Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720)
- Translate reference/scheduling/policies.md in Korean (#23690)
- Update outdated files in the dev-1.19-ko.1 branch (#23702)
- Modify translation access by Korean glossary (#23627)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>

content/ko/docs/reference/_index.md

@@ -33,7 +33,7 @@ content_type: concept
 ## CLI 레퍼런스
 
 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
-    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
 * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
 
 ## 컴포넌트 레퍼런스
@@ -44,10 +44,10 @@ content_type: concept
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
   * [kube-scheduler 정책](/docs/reference/scheduling/policies)
-  * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles)
+  * [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
 
 ## 설계 문서
 
-쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
-
-
+쿠버네티스 기능에 대한 설계 문서의 아카이브.
+[쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와
+[쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.

content/ko/docs/reference/command-line-tools-reference/_index.md

@@ -1,5 +1,4 @@
 ---
 title: 커맨드 라인 도구 레퍼런스
 weight: 60
-toc-hide: true
 ---

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

@@ -67,7 +67,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
 | `CSIMigrationAWS` | `false` | 베타 | 1.17 | |
 | `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | |
-| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | |
+| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
+| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
 | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | |
 | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | |
@@ -76,15 +77,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | |
 | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
+| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
+| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
+| `CSIStorageCapacity` | `false` | 알파 | 1.19 | |
+| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
 | `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
+| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
+| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.20 |
 | `DryRun` | `false` | 알파 | 1.12 | 1.12 |
 | `DryRun` | `true` | 베타 | 1.13 | |
-| `DynamicAuditing` | `false` | 알파 | 1.13 | |
 | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
 | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
@@ -99,12 +105,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
-| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
-| `EvenPodsSpread` | `true` | 베타 | 1.18 | |
+| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | |
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
-| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | |
+| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
 | `HyperVContainer` | `false` | 알파 | 1.10 | |
-| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | |
+| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
+| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | |
 | `IPv6DualStack` | `false` | 알파 | 1.16 | |
 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | 베타 | 1.15 | |
@@ -113,34 +120,37 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
 | `MountContainers` | `false` | 알파 | 1.9 | |
-| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | |
-| `NonPreemptingPriority` | `false` | 알파 | 1.15 | |
+| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
+| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
+| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
+| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
 | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | 베타 | 1.5 | |
 | `PodOverhead` | `false` | 알파 | 1.16 | - |
 | `ProcMountType` | `false` | 알파 | 1.12 | |
 | `QOSReserved` | `false` | 알파 | 1.11 | |
 | `RemainingItemCount` | `false` | 알파 | 1.15 | |
-| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | |
-| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
 | `RunAsGroup` | `true` | 베타 | 1.14 | |
 | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | 베타 | 1.14 | |
-| `SCTPSupport` | `false` | 알파 | 1.12 | |
+| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | 베타 | 1.19 | |
+| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
 | `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
-| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | |
+| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
+| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
+| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | |
 | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
 | `StartupProbe` | `true` | 베타 | 1.18 | |
 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | 베타 | 1.15 | |
-| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
-| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | |
 | `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 |
 | `SupportNodePidsLimit` | `true` | 베타 | 1.15 | |
 | `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
@@ -156,6 +166,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
 | `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
 | `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - |
+| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
 | `WindowsGMSA` | `false` | 알파 | 1.14 | |
 | `WindowsGMSA` | `true` | 베타 | 1.16 | |
 | `WinDSR` | `false` | 알파 | 1.14 | |
@@ -210,6 +221,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
+| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
+| `DynamicAuditing` | - | 사용 중단 | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
@@ -218,6 +231,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
 | `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - |
+| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
+| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
+| `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | 알파 | 1.8 | 1.9 |
@@ -251,9 +267,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
 | `PVCProtection` | - | 사용 중단 | 1.10 | - |
 | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
+| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
+| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 |
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
+| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
+| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
 | `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
@@ -262,6 +282,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
 | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
+| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
+| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
+| `StreamingProxyRedirects` | - | 사용 중단| 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@@ -377,11 +400,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다.
 - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
 - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere 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)
   호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
   마운트할 수 있다.
   자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
+- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
+  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
+- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다.
 - `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다.
 - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
   자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
@@ -395,11 +423,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
   생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
   실행 중인 파드 문제를 해결한다.
+- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/docs/concepts/cluster-administration/monitoring.md).
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
   기반 리소스 프로비저닝을 활성화한다.
+- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
+  [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
   요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
 - `DynamicAuditing`: [동적 감사](/docs/tasks/debug-application-cluster/audit/#dynamic-backend) 기능을 활성화한다.
+- `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
 - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
 - `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다.
   이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다.
@@ -420,10 +452,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   재 매핑이 활성화된 경우에만 활성화해야 한다.
 - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
   엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
-- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, kube-proxy는
-  엔드포인트슬라이스를 엔드포인트 대신 기본 데이터 소스로 사용하여
-  확장성과 성능을 향상시킨다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+- `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, 리눅스에서 실행되는
+  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
+  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
+  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+- `WindowsEndpointSliceProxying`: 이 기능 게이트가 활성화되면, 윈도우에서 실행되는
+  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
+  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
+  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
+- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
 - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
 - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
 - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
@@ -435,9 +473,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
 - `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다.
    자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다.
-- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
+- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
 - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다.
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 대해 `LocalStorageCapacityIsolation`이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)에 대한 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 프로젝트 쿼터를 사용하여 파일시스템 사용보다는 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 `LocalStorageCapacityIsolation` 이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는 프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
 - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
   자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
@@ -460,7 +498,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   삭제되지 않도록 한다.  
 - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서
   요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당).
-- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중
+- `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중
   하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는
   스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
   노드 사이의 관계를 끊는 것이다.
@@ -472,7 +510,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다.
 - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다.
 - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
-- `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다.
+- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다.
 - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다.
 - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
 - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
@@ -480,6 +518,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다.
   "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다.
 - `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다.
+- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
 - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다.
 - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
   사용 중인 경우 삭제를 연기한다.

content/ko/docs/reference/glossary/kube-apiserver.md

@@ -2,21 +2,21 @@
 title: API 서버
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /ko/docs/concepts/overview/components/#kube-apiserver
 short_description: >
   쿠버네티스 API를 제공하는 컨트롤 플레인 컴포넌트.
 
-aka: 
+aka:
 - kube-apiserver
 tags:
 - architecture
 - fundamental
 ---
- API 서버는 쿠버네티스 API를 
+ API 서버는 쿠버네티스 API를
 노출하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다.
 API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.
 
-<!--more--> 
+<!--more-->
 
 쿠버네티스 API 서버의 주요 구현은 [kube-apiserver](/docs/reference/generated/kube-apiserver/) 이다.
 kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다.

content/ko/docs/reference/glossary/managed-service.md

@@ -2,17 +2,21 @@
 title: 매니지드 서비스
 id: managed-service
 date: 2018-04-12
-full_link: 
+full_link:
 short_description: >
   타사 공급자가 유지보수하는 소프트웨어.
 
-aka: 
+aka:
 
 tags:
 - extension
 ---
- 타사 공급자가 유지보수하는 소프트웨어. 
+ 타사 공급자가 유지보수하는 소프트웨어.
 
-<!--more--> 
+<!--more-->
 
-매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. [서비스 카탈로그](/docs/concepts/service-catalog/)는 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.
+매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고
+GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다.
+[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는
+{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는
+매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.

content/ko/docs/reference/issues-security/_index.md

@@ -1,5 +1,4 @@
 ---
 title: 쿠버네티스 이슈와 보안
 weight: 10
-toc-hide: true
 ---

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

@@ -8,16 +8,10 @@ card:
 
 <!-- overview -->
 
-참고 항목: [Kubectl 개요](/ko/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath).
-
-이 페이지는 `kubectl` 커맨드의 개요이다.
-
-
+이 페이지는 일반적으로 사용하는 `kubectl` 커맨드와 플래그에 대한 목록을 포함한다.
 
 <!-- body -->
 
-# kubectl - 치트 시트
-
 ## Kubectl 자동 완성
 
 ### BASH
@@ -77,7 +71,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
 kubectl config unset users.foo                       # foo 사용자 삭제
 ```
 
-## Apply
+## Kubectl apply
+
 `apply`는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. `kubectl apply`를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. [Kubectl Book](https://kubectl.docs.kubernetes.io)을 참고한다.
 
 ## 오브젝트 생성
@@ -200,6 +195,13 @@ kubectl get events --sort-by=.metadata.creationTimestamp
 
 # 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
 kubectl diff -f ./my-manifest.yaml
+
+# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
+# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
+kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
+kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 ```
 
 ## 리소스 업데이트
@@ -249,6 +251,7 @@ kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1",
 ```
 
 ## 리소스 편집
+
 편집기로 모든 API 리소스를 편집.
 
 ```bash
@@ -382,15 +385,12 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
 `--v=8` | HTTP 요청 내용을 표시.
 `--v=9` | 내용을 잘라 내지 않고 HTTP 요청 내용을 표시.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
-* [kubectl 개요](/ko/docs/reference/kubectl/overview/)에 대해 더 배워보자.
+* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자.
 
 * [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
 
 * 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다.
 
-* 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인
+* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.

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

@@ -8,10 +8,16 @@ card:
 ---
 
 <!-- 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/install-kubectl/)를 참고한다.
+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/install-kubectl/)를 참고한다.
 
 <!-- body -->
 
@@ -25,9 +31,12 @@ kubectl [command] [TYPE] [NAME] [flags]
 
 다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
 
-* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: `create`, `get`, `describe`, `delete`
+* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
+예: `create`, `get`, `describe`, `delete`
 
-* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
+* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
+  단수형, 복수형 또는 약어 형식을 지정할 수 있다.
+  예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
 
    ```shell
    kubectl get pod pod1
@@ -205,11 +214,13 @@ kubectl [command] [TYPE] [NAME] -o <output_format>
 kubectl get pod web-pod-13je7 -o yaml
 ```
 
-기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다.
+기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
+[kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
 
 #### 사용자 정의 열 {#custom-columns}
 
-사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다. 사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
+사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
+사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
 
 ##### 예제
 
@@ -493,8 +504,6 @@ kubectl whoami
 Current user: plugins-user
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
 * [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.

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

@@ -0,0 +1,5 @@
+---
+title: 스케줄링
+weight: 70
+toc-hide: true
+---

content/ko/docs/reference/scheduling/policies.md

@@ -0,0 +1,118 @@
+---
+title: 스케줄링 정책
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다.
+
+`kube-scheduler --policy-config-file <filename>` 또는 `kube-scheduler --policy-configmap <ConfigMap>`을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다.
+
+
+
+<!-- body -->
+
+## 단정 {#predicates}
+
+다음의 *단정* 은 필터링을 구현한다.
+
+- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는
+  포트(네트워크 프로토콜 종류)가 있는지 확인한다.
+
+- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다.
+
+- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는
+  리소스(예: CPU 및 메모리)가 있는지 확인한다.
+
+- `PodMatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가
+  노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다.
+
+- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면
+  파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지
+  평가한다.
+
+- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해
+  파드가 노드에 적합한지 평가한다.
+
+- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와
+  구성된 제한을 초과하는지 여부를 결정한다.
+
+- `CheckNodeMemoryPressure`: 노드가 메모리 압박을 보고하고 있고, 구성된
+  예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodePIDPressure`: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된
+  예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodeDiskPressure`: 노드가 스토리지 압박(파일시스템이 가득차거나
+  거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.
+
+- `CheckNodeCondition`: 노드는 파일시스템이 완전히 가득찼거나,
+  네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다.
+  노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가
+  해당 노드에 스케줄되지 않는다.
+
+- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이
+  노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다.
+
+- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다.
+  이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와
+  바인딩되지 않은 PVC 모두에 적용된다.
+
+## 우선순위 {#priorities}
+
+다음의 *우선순위* 는 스코어링을 구현한다.
+
+- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}},
+  {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는
+  {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는
+  파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다.
+
+- `InterPodAffinityPriority`: 선호된
+  [파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다.
+
+- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉,
+  노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가
+  많을수록 이 정책이 부여하는 순위가 낮아진다.
+
+- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다.
+  이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된
+  파드를 맞춘다.
+
+- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.
+
+- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다.
+
+- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
+  노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가
+  동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.
+
+- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링
+  설정에 따라 노드의 우선순위를 지정한다.
+  이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다.
+
+- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로,
+  모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을
+  고려하여 노드의 순위를 조정한다.
+
+- `ImageLocalityPriority`: 해당 파드의
+  {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된
+  노드를 선호한다.
+
+- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한
+  파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한
+  파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는
+  서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.
+
+- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다.
+
+- `EvenPodsSpreadPriority`: 선호된
+  [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다.
+
+
+
+## {{% heading "whatsnext" %}}
+
+* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
+* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기

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

@@ -1,6 +1,4 @@
 ---
 title: 설치 도구 레퍼런스
 weight: 50
-toc-hide: true
 ---
-

content/ko/docs/reference/setup-tools/kubeadm/_index.md

@@ -1,6 +1,30 @@
 ---
 title: "Kubeadm"
 weight: 10
-toc-hide: true
+no_list: true
+content_type: concept
+card:
+  name: reference
+  weight: 40
 ---
 
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다.
+
+kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다.
+
+대신, 우리는 더 높은 수준의 맞춤형 도구가 kubeadm 위에 구축될 것으로 기대하며, 이상적으로는, 모든 배포의 기반으로 kubeadm을 사용하면 규격을 따르는 클러스터를 더 쉽게 생성할 수 있다.
+
+## 설치 방법
+
+kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다.
+
+## {{% heading "whatsnext" %}}
+
+* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다.
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다.
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다.
+* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다.
+* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다.
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다.
+* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다.
+* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.

content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md

@@ -1,28 +0,0 @@
----
-title: kubeadm 개요
-weight: 10
-card:
-  name: reference
-  weight: 40
----
-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다.
-
-kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다.
-
-대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다.
-
-## 설치하는 방법
-
-kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다.
-
-## 다음 내용
-
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드
-* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용
-* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림
-* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공
-

content/ko/docs/reference/using-api/_index.md

@@ -1,5 +1,4 @@
 ---
 title: 쿠버네티스 API 사용하기
 weight: 10
-toc-hide: true
 ---

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

@@ -22,8 +22,8 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 
 ## 공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리
 
-다음의 클라이언트 라이브러리들은 [쿠버네티스 SIG API
-Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다.
+다음의 클라이언트 라이브러리들은
+[쿠버네티스 SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다.
 
 
 | 언어      | 클라이언트 라이브러리 | 예제 프로그램 |
@@ -73,6 +73,3 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
 | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
 | Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
-
-
-