Merge pull request #26647 from pjhwa/outdated2-26620

Update outdated files in dev-1.20-ko.5 (2)

Author: k8s-ci-robot

content/ko/docs/concepts/security/controlling-access.md

@@ -132,7 +132,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
 API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
 
-기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
+기본적으로, 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
 
   1. `로컬호스트 포트`:
 

content/ko/docs/concepts/security/overview.md

@@ -119,6 +119,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r
 컨테이너 취약점 스캔 및 OS에 종속적인 보안 | 이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다.
 이미지 서명 및 시행 | 컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다.
 권한있는 사용자의 비허용 | 컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다.
+더 강력한 격리로 컨테이너 런타임 사용 | 더 강력한 격리를 제공하는 [컨테이너 런타임 클래스](/ko/docs/concepts/containers/runtime-class/)를 선택한다.
 
 ## 코드
 
@@ -151,3 +152,4 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 
 * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/)
 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/)
 * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/)
+* [런타임 클래스](/ko/docs/concepts/containers/runtime-class)

content/ko/docs/concepts/services-networking/dual-stack.md

@@ -35,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
 
    * 쿠버네티스 1.20 이상
      이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
-     쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 
+     쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
      문서 참조
    * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
    * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
@@ -69,9 +69,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 
 
 클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
 
-서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성)
+서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성)
 
-서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 
+서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를
 다음 값 중 하나로 설정한다.
 
 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
@@ -158,7 +158,7 @@ status:
   loadBalancer: {}
 ```
 
-1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
+1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
 
 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
 

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

@@ -23,21 +23,22 @@ weight: 40
 
 {{% thirdparty-content %}}
 
-* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
   컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
 * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
   Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
+* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
   이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
   오픈소스 인그레스 컨트롤러다.
-* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
+* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](https://www.haproxy.org/#desc)의
   인그레스 컨트롤러다.
-* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
+* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](https://www.haproxy.org/#desc) 용
   인그레스 컨트롤러이기도 하다.
 * [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
   기반 인그레스 컨트롤러다.
@@ -48,8 +49,9 @@ weight: 40
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
   [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
+* [Tyk 오퍼레이터](https://github.com/TykTechnologies/tyk-operator)는 사용자 지정 리소스로 인그레스를 확장하여 API 관리 기능을 인그레스로 가져온다. Tyk 오퍼레이터는 오픈 소스 Tyk 게이트웨이 및 Tyk 클라우드 컨트롤 플레인과 함께 작동한다.
 * [Voyager](https://appscode.com/products/voyager)는
-  [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다.
+  [HAProxy](https://www.haproxy.org/#desc)의 인그레스 컨트롤러다.
 
 ## 여러 인그레스 컨트롤러 사용
 

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

@@ -430,8 +430,8 @@ CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위
 예를 들면, 쿠버네티스 네임스페이스 `my-ns`에 `my-service`라는
 서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
 `my-service.my-ns`에 대한 DNS 레코드를 만든다. `my-ns` 네임 스페이스의 파드들은
-간단히 `my-service`에 대한 이름 조회를 수행하여 찾을 수 있어야 한다
-(`my-service.my-ns` 역시 동작함).
+`my-service`(`my-service.my-ns` 역시 동작함)에 대한 이름 조회를
+수행하여 서비스를 찾을 수 있어야 한다.
 
 다른 네임스페이스의 파드들은 이름을 `my-service.my-ns`으로 사용해야 한다. 이 이름은
 서비스에 할당된 클러스터 IP로 변환된다.
@@ -463,7 +463,7 @@ DNS SRV 쿼리를 수행할 수 있다.
 
 셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
 API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하여
-`서비스` 를 지원하는 `파드` 를 직접 가리키는 레코드 (주소)를 반환한다.
+`서비스` 를 지원하는 `파드` 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.
 
 ### 셀렉터가 없는 경우
 
@@ -1164,7 +1164,7 @@ IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정
 
 이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
 의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
-간단히 연결할 수 있다.
+연결할 수 있다.
 
 #### iptables
 

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

@@ -487,7 +487,7 @@ PV는 `storageClassName` 속성을
 * VsphereVolume
 * iSCSI
 
-마운트 옵션의 유효성이 검사되지 않으므로 마운트 옵션이 유효하지 않으면 마운트가 실패한다.
+마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다.
 
 이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이
 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만,
@@ -629,6 +629,11 @@ spec:
 
 퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다.
 
+### `hostPath` 유형의 퍼시스턴트볼륨
+
+`hostPath` 퍼시스턴트볼륨은 노드의 파일이나 디렉터리를 사용하여 네트워크 연결 스토리지를 에뮬레이션한다.
+[`hostPath` 유형 볼륨의 예](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)를 참고한다.
+
 ## 원시 블록 볼륨 지원
 
 {{< feature-state for_k8s_version="v1.18" state="stable" >}}

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

@@ -143,8 +143,8 @@ CSI | 1.14 (alpha), 1.16 (beta)
 클래스의 `mountOptions` 필드에 지정된 마운트 옵션을 가진다.
 
 만약 볼륨 플러그인이 마운트 옵션을 지원하지 않는데, 마운트
-옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV 에서
-검증되지 않으므로 PV 마운트가 유효하지 않으면 마운트가 실패하게 된다.
+옵션을 지정하면 프로비저닝은 실패한다. 마운트 옵션은 클래스 또는 PV에서
+검증되지 않는다. PV 마운트가 유효하지 않으면, 마운트가 실패하게 된다.
 
 ### 볼륨 바인딩 모드
 

content/ko/docs/concepts/storage/volume-pvc-datasource.md

@@ -19,7 +19,7 @@ weight: 30
 
 복제는 표준 볼륨처럼 소비할 수 있는 쿠버네티스 볼륨의 복제본으로 정의된다.  유일한 차이점은 프로비저닝할 때 "새" 빈 볼륨을 생성하는 대신에 백엔드 장치가 지정된 볼륨의 정확한 복제본을 생성한다는 것이다.
 
-쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어있고, 사용가능해야 한다(사용 중이 아니어야함).
+쿠버네티스 API의 관점에서 복제를 구현하면 새로운 PVC 생성 중에 기존 PVC를 데이터 소스로 지정할 수 있는 기능이 추가된다. 소스 PVC는 바인딩되어 있고, 사용 가능해야 한다(사용 중이 아니어야 함).
 
 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.
 
@@ -64,5 +64,3 @@ spec:
 ## 사용
 
 새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다.  또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다.  원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다.  이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다.
-
-

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

@@ -103,6 +103,8 @@ spec:
       fsType: ext4
 ```
 
+EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition number>"` 를 제공하여 마운트할 파티션을 지정할 수 있다.
+
 #### AWS EBS CSI 마이그레이션
 
 {{< feature-state for_k8s_version="v1.17" state="beta" >}}
@@ -207,8 +209,8 @@ spec:
 Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI
-드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
-를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
+드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를
+설치하고 `CSIMigration` 과 `CSIMigrationOpenStack`
 베타 기능을 활성화해야 한다.
 
 ### 컨피그맵(configMap) {#configmap}

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -89,6 +89,11 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 `concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은
 실행될 것이다.
 
+{{< caution >}}
+`startingDeadlineSeconds` 가 10초 미만의 값으로 설정되면, 크론잡이 스케줄되지 않을 수 있다. 이는 크론잡 컨트롤러가 10초마다 항목을 확인하기 때문이다.
+{{< /caution >}}
+
+
 모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다.
 
 ````