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

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 노드
 content_type: concept
 weight: 10
@@ -8,7 +11,8 @@ weight: 10
 
 쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 워크로드를 구동한다.
 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는
-{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 
+의해 관리되며
 {{< glossary_tooltip text="파드" term_id="pod" >}}를
 실행하는 데 필요한 서비스를 포함한다.
 
@@ -272,17 +276,18 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 #### 안정성
 
  대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
-축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
+축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여
 파드 축출을 하지 않는다는 의미가 된다.
 
 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
 체크한다(NodeReady 컨디션은 ConditionUnknown 또는
-ConditionFalse 다.).
-- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold`
-  (기본값 0.55)가 되면 축출 비율은 감소한다.
+ConditionFalse 다).
+- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold`
+  (기본값 0.55)가 되면 축출 속도가 감소한다.
 - 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
-  노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
+  노드 이하면 - 기본값 50) 축출이 중지된다.
+- 이외의 경우, 축출 속도는 초당
   `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
 
 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
@@ -293,7 +298,7 @@ ConditionFalse 다.).
 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
-`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이
+`--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이
 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
@@ -347,7 +352,8 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다.
 
 그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 `GracefulNodeShutdown`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 제어된다.
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 
+제어된다.
 
 기본적으로, 아래 설명된 두 구성 옵션,
 `ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
@@ -371,6 +377,20 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 유예 종료에 할당되고, 마지막 10초는
 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
 
+{{< note >}}
+그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.
+`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다.
+그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다.
+
+```
+Status:         Failed
+Reason:         Shutdown
+Message:        Node is shutting, evicting pods
+```
+
+실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다.
+이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 볼륨
 content_type: concept
 weight: 10
@@ -13,7 +18,6 @@ weight: 10
 파일을 공유할 때 발생한다.
 쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 추상화는
 이러한 문제를 모두 해결한다.
-
 [파드](/ko/docs/concepts/workloads/pods/)에 대해 익숙해지는 것을 추천한다.
 
 <!-- body -->
@@ -40,7 +44,6 @@ weight: 10
 
 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고
 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
-
 컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
 뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는
 파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
@@ -117,6 +120,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 베타 기능을 활성화해야 한다.
 
 #### AWS EBS CSI 마이그레이션 완료
+
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}
 
 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
@@ -257,6 +261,9 @@ spec:
 `path` 에서 파생된다.
 
 {{< note >}}
+* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하기 위해서는
+  먼저 컨피그맵을 생성해야 한다.
+
 * 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
 업데이트를 수신하지 않는다.
 
@@ -522,6 +529,15 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 ### hostPath {#hostpath}
 
+{{< warning >}}
+HostPath 볼륨에는 많은 보안 위험이 있으며, 가능하면 HostPath를 사용하지 않는 
+것이 좋다. HostPath 볼륨을 사용해야 하는 경우, 필요한 파일 또는 디렉터리로만 
+범위를 지정하고 ReadOnly로 마운트해야 한다.
+
+AdmissionPolicy를 사용하여 특정 디렉터리로의 HostPath 액세스를 제한하는 경우,
+`readOnly` 마운트를 사용하는 정책이 유효하려면 `volumeMounts` 가 반드시 지정되어야 한다.
+{{< /warning >}}
+
 `hostPath` 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를
 파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부
 애플리케이션에 강력한 탈출구를 제공한다.
@@ -538,7 +554,6 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 필드가 `type` 에 지원되는 값은 다음과 같다.
 
-
 | 값 | 행동 |
 |:------|:---------|
 | | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. |
@@ -552,6 +567,9 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다.
 
+* HostPath는 권한있는 시스템 자격 증명 (예 : Kubelet 용) 또는 권한있는 API 
+  (예 : 컨테이너 런타임 소켓)를 노출 할 수 있으며, 이는 컨테이너 이스케이프 또는 
+  클러스터의 다른 부분을 공격하는 데 사용될 수 있다.
 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을
   가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다.
 * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
@@ -909,7 +927,8 @@ API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정
 상대 경로를 지정한다.
 
 {{< note >}}
-projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다.
+projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 
+해당 볼륨 소스의 업데이트를 수신하지 않는다.
 {{< /note >}}
 
 ### quobyte
@@ -1103,7 +1122,6 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
 
 {{< /tabs >}}
 
-
 #### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration}
 
 ```yaml
@@ -1133,8 +1151,7 @@ spec:
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 `vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서
-`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다.
-이 기능을 사용하려면,
+`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면,
 [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.

content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -82,12 +82,11 @@ spec:
 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
 
 - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
-  이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는
-  파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야
-  한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
+  이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
   - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
-    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에
-    허용되는 최대 차이이다.
+    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
+    (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0) 
+    사이에 허용되는 최대 차이이다.
   - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
     왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
 - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
@@ -96,6 +95,8 @@ spec:
   - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
 - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
 
+파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
+
 사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다.
 
 ### 예시: 단수 토폴로지 분배 제약 조건
@@ -387,7 +388,8 @@ profiles:
 
 ## 알려진 제한사항
 
-- 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
+- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다. 예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다.
+[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다.
 - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
 
 ## {{% heading "whatsnext" %}}