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

2021-07-12 16:08:07 +09:00
parent 2ebbdd6a1e
commit 30c6cec1ba
6 changed files with 40 additions and 27 deletions
@@ -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

@@ -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 주소를 사용하여 컨트롤 플레인과 통신한다.