Merge pull request #28906 from seokho-son/fix-outd-1.21-ko.6

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

content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md

@@ -20,6 +20,13 @@ card:
 반드시 존재해야 한다는 것을 의미하는 것은 아니다.
 {{< /note >}}
 
+
+{{< warning >}}
+신뢰할 수 있는 소스의 kubeconfig 파일만 사용해야 한다. 특수 제작된 kubeconfig 파일은 악성코드를 실행하거나 파일을 노출시킬 수 있다.
+신뢰할 수 없는 kubeconfig 파일을 꼭 사용해야 한다면, 셸 스크립트를 사용하는 경우처럼 신중한 검사가 선행되어야 한다.
+{{< /warning>}}
+
+
 ## {{% heading "prerequisites" %}}
 
 {{< include "task-tutorial-prereqs.md" >}}

content/ko/docs/tasks/administer-cluster/certificates.md

@@ -116,7 +116,10 @@ weight: 20
         openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
         -CAcreateserial -out server.crt -days 10000 \
         -extensions v3_ext -extfile csr.conf
-1.  인증서를 본다.
+1.  인증서 서명 요청을 확인한다.
+
+        openssl req  -noout -text -in ./server.csr
+1.  인증서를 확인한다.
 
         openssl x509  -noout -text -in ./server.crt
 

content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md

@@ -1,7 +1,9 @@
 ---
-reviewers:
+
+
 title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
 content_type: task
+
 ---
 
 <!-- overview -->
@@ -62,7 +64,7 @@ HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드
 HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
 설정할 필요는 없다.
 
-다음 샘플 커맨드는 기존 HA 호환 클러스터에서 
+다음 샘플 커맨드는 기존 HA 호환 클러스터에서
 컨트롤 플레인 노드를 복제한다.
 
 ```shell
@@ -89,39 +91,41 @@ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ## 동작에 실패한 컨트롤 플레인 노드 처리
 
 HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면,
-클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인 노드를 추가하는 것이 가장 좋다.
+클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인
+노드를 추가하는 것이 가장 좋다.
 다음 샘플 커맨드로 이 과정을 시연한다.
 
 1. 손상된 복제본을 제거한다.
 
-    ```shell
-    KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
-    ```
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
 
-1. 기존 복제본 대신 새 노드를 추가한다.
+<ol start="2"><li>기존 복제본을 대신할 새 노드를 추가한다.</li></ol>
 
-    ```shell
-    KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-    ```
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
 
 ## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례
 
-* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안, 
+* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안,
 해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다.
 영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다
 (더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
 
-* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된 
+* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된
 컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다.
-결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도 
+결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도
 클러스터의 심각한 장애 상태를 초래한다.
-따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은 
+따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은
 단일 노드로 구성된 컨트롤 플레인보다도 못하다.
 
 * 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
 클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
 이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로
-Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다).
+Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다.
+(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다)
 
 
 
@@ -152,14 +156,14 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있
 해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
 로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
 
-### 마스터 서비스와 Kubelet
+### 컨트롤 플레인 서비스와 Kubelet
 
 쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
 시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
 
 * 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다.
 
-* 고가용성 컨트롤 플레인의 경우, IP 주소는 마스터 앞의 로드밸런서를 가리킨다.
+* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다.
 
 마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다.
 

content/ko/docs/tasks/tls/certificate-rotation.md

@@ -27,10 +27,10 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
 기본적으로 이러한 인증서는 1년 만기로 발급되므로
 너무 자주 갱신할 필요는 없다.
 
-쿠버네티스 1.8은 [kubelet 인증서
+쿠버네티스는 [kubelet 인증서
 갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며,
 이 기능은 현재 인증서의 만료 시한이 임박한 경우,
-새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다.
+새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 기능이다.
 새로운 인증서를 사용할 수 있게 되면
 쿠버네티스 API에 대한 연결을 인증하는데 사용된다.
 

content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md

@@ -55,7 +55,7 @@ EOF
 
 ```shell
 kubectl apply -f example-redis-config.yaml
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
 ```
 
 Redis 파드 매니페스트의 내용을 검토하고 다음의 사항을 염두에 둔다.
@@ -206,7 +206,7 @@ kubectl exec -it redis -- redis-cli
 
 ```shell
 kubectl delete pod redis
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
 ```
 
 이제 마지막으로 설정값을 다시 확인해 본다.

content/ko/examples/policy/restricted-psp.yaml

@@ -5,14 +5,11 @@ metadata:
   annotations:
     seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
     apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
-    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'runtime/default'
     apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
 spec:
   privileged: false
-  # 루트로의 에스컬레이션을 방지하는데 필요하다.
+  # 루트로의 에스컬레이션을 방지하는 데 필요하다.
   allowPrivilegeEscalation: false
-  # 이것은 루트가 아닌 사용자 + 권한 에스컬레이션을 허용하지 않는 것으로 중복이지만,
-  # 심층 방어를 위해 이를 제공한다.
   requiredDropCapabilities:
     - ALL
   # 기본 볼륨 유형을 허용한다.
@@ -22,8 +19,10 @@ spec:
     - 'projected'
     - 'secret'
     - 'downwardAPI'
-    # 클러스터 관리자가 설정한 퍼시스턴트볼륨을 사용하는 것이 안전하다고 가정한다.
+    # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)의 사용은 안전하다고 가정한다.
+    - 'csi'
     - 'persistentVolumeClaim'
+    - 'ephemeral'
   hostNetwork: false
   hostIPC: false
   hostPID: false