5.3. 재해 복구

5.3.1. 재해 복구 정보

재해 복구 문서에서는 관리자에게 OpenShift Container Platform 클러스터에서 발생할 수있는 여러 재해 상황을 복구하는 방법에 대한 정보를 제공합니다. 관리자는 클러스터를 작동 상태로 복원하려면 다음 절차 중 하나 이상을 수행해야합니다.

중요

재해 복구를 수행하려면 하나 이상의 정상 컨트롤 플레인 호스트가 있어야 합니다.

이전 클러스터 상태로 복원

클러스터를 이전 상태로 복원하려는 경우 (예: 관리자가 일부 주요 정보를 삭제한 경우) 이 솔루션을 사용할 수 있습니다. 이에는 대부분의 컨트롤 플레인 호스트가 손실되고 etcd 쿼럼이 손실되고 클러스터가 오프라인인 상태에서도 사용할 수 있습니다. etcd 백업을 수행한 경우 이 절차에 따라 클러스터를 이전 상태로 복원할 수 있습니다.

해당하는 경우 만료된 컨트롤 플레인 인증서를 복구해야 할 수도 있습니다.

주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이 절차는 마지막 수단으로만 사용해야 합니다.

복원을 수행하기 전에 클러스터에 미치는 영향에 대한 자세한 내용은 클러스터 상태 복원 을 참조하십시오.

참고

대부분의 마스터를 계속 사용할 수 있고 etcd 쿼럼이 있는 경우 절차에 따라 비정상적인 단일 etcd 멤버 교체를 수행합니다.

만료된 컨트롤 플레인 인증서 복구

컨트롤 플레인 인증서가 만료된 경우 이 솔루션을 사용할 수 있습니다. 예를 들어, 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체 전에 클러스터를 종료하면 인증서가 교체되지 않고 만료됩니다. 다음 단계에 따라 만료된 컨트롤 플레인 인증서를 복구할 수 있습니다.

5.3.2. 이전 클러스터 상태로 복원

클러스터를 이전 상태로 복원하려면 스냅샷을 작성하여 etcd 데이터를 백업 해야 합니다. 이 스냅샷을 사용하여 클러스터 상태를 복구합니다.

5.3.2.1. 클러스터 상태 복원 정보

etcd 백업을 사용하여 클러스터를 이전 상태로 복원할 수 있습니다. 이를 사용하여 다음과 같은 상황에서 복구할 수 있습니다.

클러스터에서 대부분의 컨트롤 플레인 호스트가 손실되었습니다(쿼럼 손실).
관리자가 중요한 것을 삭제했으며 클러스터를 복구하려면 복원해야 합니다.

주의

이전 클러스터 상태로 복원하는 것은 실행 중인 클러스터에서 수행하기에 위험하고 불안정한 작업입니다. 이는 마지막 수단으로만 사용해야 합니다.

Kubernetes API 서버를 사용하여 데이터를 검색할 수 있는 경우 etcd를 사용할 수 있으며 etcd 백업을 사용하여 복원할 수 없습니다.

etcd를 복원하려면 클러스터를 효율적으로 복원하는 데 시간이 걸리며 모든 클라이언트가 충돌하는 병렬 기록이 발생합니다. 이는 kubelets, Kubernetes 컨트롤러 관리자, SDN 컨트롤러 및 영구 볼륨 컨트롤러와 같은 구성 요소 모니터링 동작에 영향을 줄 수 있습니다.

이로 인해 etcd의 콘텐츠가 디스크의 실제 콘텐츠와 일치하지 않을 때 Operator가 문제가 발생하여 디스크의 파일이 etcd의 콘텐츠와 충돌할 때 Kubernetes API 서버, Kubernetes 컨트롤러 관리자, Kubernetes 스케줄러 및 etcd의 Operator가 중단될 수 있습니다. 여기에는 문제를 해결하기 위해 수동 작업이 필요할 수 있습니다.

극단적인 경우 클러스터에서 영구 볼륨 추적을 손실하고, 더 이상 존재하지 않는 중요한 워크로드를 삭제하고, 시스템을 다시 이미지화하고, 만료된 인증서로 CA 번들을 다시 작성할 수 있습니다.

5.3.2.2. 이전 클러스터 상태로 복원

저장된 etcd 백업을 사용하여 이전 클러스터 상태를 복원하거나 대부분의 컨트롤 플레인 호스트가 손실된 클러스터를 복원할 수 있습니다.

참고

클러스터에서 컨트롤 플레인 머신 세트를 사용하는 경우 보다 간단한 etcd 복구 절차는 "컨트롤 플레인 머신 세트 문제 해결"을 참조하십시오.

중요

클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 합니다. 예를 들어 OpenShift Container Platform 4.7.2 클러스터는 4.7.2에서 가져온 etcd 백업을 사용해야 합니다.

사전 요구 사항

설치 중에 사용된 인증서 기반 kubeconfig 파일을 통해 cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
복구 호스트로 사용할 정상적인 컨트롤 플레인 호스트가 있어야 합니다.
컨트롤 플레인 호스트에 대한 SSH 액세스.
동일한 백업에서 가져온 etcd 스냅샷과 정적 pod 리소스가 모두 포함된 백업 디렉터리입니다. 디렉토리의 파일 이름은 snapshot_<datetimestamp>.db 및 static_kuberesources_<datetimestamp>.tar.gz 형식이어야합니다.

중요

복구되지 않은 컨트롤 플레인 노드의 경우 SSH 연결을 설정하거나 정적 pod를 중지할 필요가 없습니다. 복구되지 않은 다른 컨트롤 플레인 시스템을 삭제하고 다시 생성할 수 있습니다.

절차

복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.
복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.
복원 프로세스가 시작된 후 kube-apiserver 에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.
중요
이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.
etcd 백업 디렉터리를 복구 컨트롤 플레인 호스트에 복사합니다.
이 절차에서는 etcd 스냅샷과 정적 pod의 리소스가 포함된 백업 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로 합니다.
다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.
참고
복구 호스트에서 정적 Pod를 중지할 필요가 없습니다.
1. 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.
2. 다음을 실행하여 kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.
```
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
```
3. 다음을 사용하여 etcd pod가 중지되었는지 확인합니다.
```
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
```
  이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.
4. 다음을 실행하여 kubelet 매니페스트 디렉토리에서 기존 kube-apiserver 파일을 이동합니다.
```
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
```
5. 다음을 실행하여 kube-apiserver 컨테이너가 중지되었는지 확인합니다.
```
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
```
  이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.
6. 다음을 사용하여 kubelet 매니페스트 디렉토리에서 기존 kube-controller-manager 파일을 이동합니다.
```
$ sudo mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp
```
7. 다음을 실행하여 kube-controller-manager 컨테이너가 중지되었는지 확인합니다.
```
$ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"
```
  이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.
8. 다음을 사용하여 kubelet 매니페스트 디렉토리에서 기존 kube-scheduler 파일을 이동합니다.
```
$ sudo mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /tmp
```
9. 다음을 사용하여 kube-scheduler 컨테이너가 중지되었는지 확인합니다.
```
$ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"
```
  이 명령의 출력이 비어 있지 않으면 몇 분 기다렸다가 다시 확인하십시오.
10. 다음 예와 함께 etcd 데이터 디렉터리를 다른 위치로 이동합니다.
```
$ sudo mv /var/lib/etcd/ /tmp
```
11. /etc/kubernetes/manifests/keepalived.yaml 파일이 있는 경우 다음 단계를 따르십시오.
  1. kubelet 매니페스트 디렉토리에서 /etc/kubernetes/manifests/keepalived.yaml 파일을 이동합니다.
    $ sudo mv /etc/kubernetes/manifests/keepalived.yaml /tmp
  2. keepalived 데몬에서 관리하는 컨테이너가 중지되었는지 확인합니다.
    $ sudo crictl ps --name keepalived
    이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.
  3. 컨트롤 플레인에 VIP가 할당되어 있는지 확인합니다.
    $ ip -o address | egrep '<api_vip>|<ingress_vip>'
  4. 보고된 각 VIP에 대해 다음 명령을 실행하여 제거합니다.
    $ sudo ip address del <reported_vip> dev <reported_vip_device>
12. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
복구 컨트롤 플레인 호스트에 액세스합니다.
keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다.
```
$ ip -o address | grep <api_vip>
```
VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.
클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.
작은 정보
oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.

$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

스크립트 출력 예

...stopping kube-scheduler-pod.yaml
...stopping kube-controller-manager-pod.yaml
...stopping etcd-pod.yaml
...stopping kube-apiserver-pod.yaml
Waiting for container etcd to stop
.complete
Waiting for container etcdctl to stop
.............................complete
Waiting for container etcd-metrics to stop
complete
Waiting for container kube-controller-manager to stop
complete
Waiting for container kube-apiserver to stop
..........................................................................................complete
Waiting for container kube-scheduler to stop
complete
Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
starting restore-etcd static pod
starting kube-apiserver-pod.yaml
static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
starting kube-controller-manager-pod.yaml
static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
starting kube-scheduler-pod.yaml
static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

cluster-restore.sh 스크립트는 etcd,kube-apiserver,kube-controller-manager 및 kube-scheduler Pod가 중지되고 복원 프로세스가 끝날 때 시작되었음을 표시해야합니다.

참고

마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스에서 노드가 NotReady 상태가 될 수 있습니다.

노드를 확인하여 Ready 상태인지 확인합니다.

다음 명령을 실행합니다.

$ oc get nodes -w

샘플 출력

NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.24.0
host-172-25-75-38   Ready   infra,worker   3d20h   v1.24.0
host-172-25-75-40   Ready   master         3d20h   v1.24.0
host-172-25-75-65   Ready   master         3d20h   v1.24.0
host-172-25-75-74   Ready   infra,worker   3d20h   v1.24.0
host-172-25-75-79   Ready   worker         3d20h   v1.24.0
host-172-25-75-86   Ready   worker         3d20h   v1.24.0
host-172-25-75-98   Ready   infra,worker   3d20h   v1.24.0

모든 노드가 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.

NotReady 상태에 있는 노드가 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH로 액세스하거나 웹 콘솔의 터미널 창을 사용할 수 있습니다.
```
$  ssh -i <ssh-key-path> core@<master-hostname>
```
샘플 pki 디렉터리
```
sh-4.4# pwd
/var/lib/kubelet/pki
sh-4.4# ls
kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
kubelet-client-current.pem              kubelet-server-current.pem
```

모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.
1. 복구 호스트에서 다음을 실행합니다.
```
$ sudo systemctl restart kubelet.service
```
2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

보류 중인 인증서 서명 요청(CSR)을 승인합니다.

참고

3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같은 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이 단계에서 나열된 모든 명령을 건너뛸 수 있습니다.

다음을 실행하여 현재 CSR 목록을 가져옵니다.

$ oc get csr

출력 예

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
...

1 2: 보류 중인 kubelet 서비스

CSR (사용자 프로비저닝 설치용). <2> 보류 중인 node-bootstrapper CSR

CSR의 세부 정보를 검토하여 다음을 실행하여 유효한지 확인합니다.
```
$ oc describe csr <csr_name> 1
```
1
<csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
다음을 실행하여 각 유효한 node-bootstrapper CSR을 승인합니다.
```
$ oc adm certificate approve <csr_name>
```
사용자 프로비저닝 설치의 경우 다음을 실행하여 각 유효한 kubelet 서비스 CSR을 승인합니다.
```
$ oc adm certificate approve <csr_name>
```
1. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

복구 호스트에서 다음을 사용하여 etcd 컨테이너가 실행 중인지 확인합니다.

$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

출력 예

3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

복구 호스트에서 다음을 사용하여 etcd pod가 실행 중인지 확인합니다.
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
출력 예
```
NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
```
상태가 Pending 또는 출력에 두 개 이상의 etcd pod가 나열된 경우 몇 분 기다렸다가 다시 확인하십시오.
1. OVNKubernetes 네트워크 플러그인을 사용하는 경우 ovnkube-controlplane Pod를 다시 시작해야 합니다.

다음을 실행하여 모든 ovnkube-controlplane Pod를 삭제합니다.

$ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane

다음을 사용하여 모든 ovnkube-controlplane Pod가 재배포되었는지 확인합니다.
```
$ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane
```
1. CNO(Cluster Network Operator)가 OVN-Kubernetes 컨트롤 플레인을 재배포하고 더 이상 복구되지 않은 컨트롤러 IP 주소를 참조하지 않는지 확인합니다. 이 결과를 확인하려면 다음 명령의 출력을 정기적으로 확인하십시오. 다음 단계의 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작하기 전에 빈 결과를 반환할 때까지 기다립니다.
```
$ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<non-recovery_controller_ip_1>|<non-recovery_controller_ip_2>'
```
  참고
  OVN-Kubernetes 컨트롤 플레인을 재배포하고 이전 명령을 사용하여 빈 출력을 반환하는 데 최소 5-10 분이 걸릴 수 있습니다.
2. 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 재시작합니다.
  참고
  승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다. failurePolicy 를 Fail 로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.
  또는 클러스터 상태를 복원하는 동안 failurePolicy 를 Ignore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후 failurePolicy 를 Fail 로 설정할 수 있습니다.
northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트 및 나머지 컨트롤 플레인 노드에 액세스하고 다음을 실행합니다.
```
$ sudo rm -f /var/lib/ovn/etc/*.db
```
다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.
```
$ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
```

다음 명령을 실행하여 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되고 Running 상태에 있는지 확인합니다.

$ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes

출력 예

NAME                   READY   STATUS    RESTARTS   AGE
ovnkube-master-nb24h   4/4     Running   0          48s

다음을 사용하여 ovnkube-node Pod가 다시 실행 중인지 확인합니다.

$ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done

모든 ovnkube-node Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.
```
$ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node
```
1. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd 가 자동으로 확장됩니다.
  - 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.
    주의
    복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.
  - 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.
    주의
    복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.
    설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

손실된 컨트롤 플레인 호스트 중 하나에 대한 시스템을 가져옵니다.

cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.

$ oc get machines -n openshift-machine-api -o wide

출력 예:

NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

1: 이는 손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템인 ip-10-0-131-183.ec2.internal 입니다.

다음을 실행하여 머신 구성을 파일 시스템의 파일에 저장합니다.
```
$ oc get machine clustername-8qw5l-master-0 \ 1
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
```
1
손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

이전 단계에서 만든 new-master-machine.yaml 파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.

다음을 실행하여 전체 status 섹션을 제거합니다.

status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus

다음을 실행하여 metadata.name 필드를 새 이름으로 변경합니다.
이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 clustername-8qw5l-master-0 이 clustername-8qw5l-master-3 로 변경됩니다.
```
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
```
다음을 실행하여 spec.providerID 필드를 제거합니다.
```
providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
```
다음을 실행하여 metadata.annotations 및 metadata.generation 필드를 제거합니다.
```
annotations:
  machine.openshift.io/instance-state: running
...
generation: 2
```
다음을 실행하여 metadata.resourceVersion 및 metadata.uid 필드를 제거합니다.
```
resourceVersion: "13291"
uid: a282eb70-40a2-4e89-8009-d05dd420d31a
```

다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.
```
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
```
1
손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

다음을 실행하여 머신이 삭제되었는지 확인합니다.

$ oc get machines -n openshift-machine-api -o wide

출력 예:

NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal   aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

다음을 실행하여 new-master-machine.yaml 파일을 사용하여 머신을 생성합니다.
```
$ oc apply -f new-master-machine.yaml
```

다음을 실행하여 새 시스템이 생성되었는지 확인합니다.

$ oc get machines -n openshift-machine-api -o wide

출력 예:

NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

1: 새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경되면 시스템이 준비 상태가 됩니다.

새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아올 때 자동으로 동기화됩니다.

복구 호스트가 아닌 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.
1. 다음을 입력하여 쿼럼 가드를 끕니다.
```
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
```
  이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.
2. 복구 호스트 내의 별도의 터미널 창에서 다음을 실행하여 복구 kubeconfig 파일을 내보냅니다.
```
$ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
```
3. etcd 를 강제로 재배포합니다.
  복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음을 실행합니다.
```
$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
```
  1
  forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.
  etcd 클러스터 Operator가 재배포를 수행하면 기존 노드가 초기 부트스트랩 확장과 유사한 새 Pod로 시작됩니다.
4. 다음을 입력하여 쿼럼 가드를 다시 켭니다.
```
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
```
5. 다음을 실행하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.
```
$ oc get etcd/cluster -oyaml
```
6. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
  cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음을 실행합니다.
```
$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
  etcd 의 NodeInstallerProgressing 상태 조건을 검토하여 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
  1
  이 예에서 최신 버전 번호는 7입니다.
  출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
7. etcd 를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 적용합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있기 때문에 kube-apiserver 는 다른 노드에 다시 설치됩니다.
  cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음을 실행합니다.
kube-apiserver 에 대해 새 롤아웃을 강제 적용합니다.
```
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
1
이 예에서 최신 버전 번호는 7입니다.
출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
다음 명령을 실행하여 Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다.
```
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
다음을 실행하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
```
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
1
이 예에서 최신 버전 번호는 7입니다.
출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
다음을 실행하여 kube-scheduler 에 새 롤아웃을 강제 적용합니다.
```
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
다음을 사용하여 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.
```
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
1
이 예에서 최신 버전 번호는 7입니다.
출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.
1. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.
  클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
  출력 예
```
etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h
```

복구 절차에 따라 모든 워크로드가 정상 작업으로 돌아가도록 하려면 kube-apiserver 정보를 저장하는 각 Pod를 다시 시작합니다. 여기에는 라우터, Operator, 타사 구성 요소와 같은 OpenShift Container Platform 구성 요소가 포함됩니다.

참고

이전 절차 단계를 완료하면 모든 서비스가 복원된 상태로 돌아올 때까지 몇 분 정도 기다려야 할 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login을 사용한 인증이 즉시 작동하지 않을 수 있습니다.

즉각적인 인증을 위해 system:admin kubeconfig 파일을 사용하는 것이 좋습니다. 이 방법은 OAuth 토큰에 대해 SSL/TLS 클라이언트 인증서에 대한 인증을 기반으로 합니다. 다음 명령을 실행하여 이 파일로 인증할 수 있습니다.

$ export KUBECONFIG=<installation_directory>/auth/kubeconfig

다음 명령을 실행하여 인증된 사용자 이름을 표시합니다.

$ oc whoami

5.3.2.3. 추가 리소스

5.3.2.4. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법

OpenShift Container Platform 클러스터에서 모든 형식의 영구저장장치를 사용하는 경우 일반적으로 클러스터의 상태가 etcd 외부에 저장됩니다. StatefulSet 오브젝트에서 실행 중인 Pod 또는 데이터베이스에서 실행 중인 Elasticsearch 클러스터일 수 있습니다. etcd 백업에서 복원하면 OpenShift Container Platform의 워크로드 상태도 복원됩니다. 그러나 etcd 스냅샷이 오래된 경우 상태가 유효하지 않거나 오래되었을 수 있습니다.

중요

PV(영구 볼륨)의 내용은 etcd 스냅샷의 일부가 아닙니다. etcd 스냅샷에서 OpenShift Container Platform 클러스터를 복원할 때 중요하지 않은 워크로드가 중요한 데이터에 액세스할 수 있으며 그 반대의 경우로도 할 수 있습니다.

다음은 사용되지 않는 상태를 생성하는 몇 가지 예제 시나리오입니다.

MySQL 데이터베이스는 PV 오브젝트에서 지원하는 pod에서 실행됩니다. etcd 스냅샷에서 OpenShift Container Platform을 복원해도 스토리지 공급자의 볼륨을 다시 가져오지 않으며 pod를 반복적으로 시작하려고 하지만 실행 중인 MySQL pod는 생성되지 않습니다. 스토리지 공급자에서 볼륨을 복원한 다음 새 볼륨을 가리키도록 PV를 편집하여 이 Pod를 수동으로 복원해야 합니다.
Pod P1에서는 노드 X에 연결된 볼륨 A를 사용합니다. 다른 pod가 노드 Y에서 동일한 볼륨을 사용하는 동안 etcd 스냅샷을 가져오는 경우 etcd 복원이 수행되면 해당 볼륨이 여전히 Y 노드에 연결되어 있으므로 Pod P1이 제대로 시작되지 않을 수 있습니다. OpenShift Container Platform은 연결을 인식하지 못하고 자동으로 연결을 분리하지 않습니다. 이 경우 볼륨이 노드 X에 연결된 다음 Pod P1이 시작될 수 있도록 노드 Y에서 볼륨을 수동으로 분리해야 합니다.
etcd 스냅샷을 만든 후 클라우드 공급자 또는 스토리지 공급자 인증 정보가 업데이트되었습니다. 이로 인해 해당 인증 정보를 사용하는 CSI 드라이버 또는 Operator가 작동하지 않습니다. 해당 드라이버 또는 Operator에 필요한 인증 정보를 수동으로 업데이트해야 할 수 있습니다.
etcd 스냅샷을 만든 후 OpenShift Container Platform 노드에서 장치가 제거되거나 이름이 변경됩니다. Local Storage Operator는 /dev/disk/by-id 또는 /dev 디렉터리에서 관리하는 각 PV에 대한 심볼릭 링크를 생성합니다. 이 경우 로컬 PV가 더 이상 존재하지 않는 장치를 참조할 수 있습니다.
이 문제를 해결하려면 관리자가 다음을 수행해야 합니다.
1. 잘못된 장치가 있는 PV를 수동으로 제거합니다.
2. 각 노드에서 심볼릭 링크를 제거합니다.
3. LocalVolume 또는 LocalVolumeSet 오브젝트를 삭제합니다 (스토리지 영구 스토리지 구성 로컬 볼륨을 사용하는 영구 스토리지 Local Storage Operator 리소스 삭제참조).

5.3.3. 만료된 컨트롤 플레인 인증서 복구

5.3.3.1. 만료된 컨트롤 플레인 인증서 복구

클러스터는 만료된 컨트롤 플레인 인증서에서 자동으로 복구될 수 있습니다.

그러나 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 사용자 프로비저닝 설치의 경우 보류 중인 kubelet 서비스 CSR을 승인해야 할 수도 있습니다.

보류중인 CSR을 승인하려면 다음 단계를 수행합니다.

절차

현재 CSR의 목록을 가져옵니다.

$ oc get csr

출력 예

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 2
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

1: 보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.
2: 보류 중인 node-bootstrapper CSR입니다.

CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.
```
$ oc describe csr <csr_name> 1
```
1
<csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
각각의 유효한 node-bootstrapper CSR을 승인합니다.
```
$ oc adm certificate approve <csr_name>
```
사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다.
```
$ oc adm certificate approve <csr_name>
```

5.3. 재해 복구

5.3.1. 재해 복구 정보

5.3.2. 이전 클러스터 상태로 복원

5.3.2.1. 클러스터 상태 복원 정보

5.3.2.2. 이전 클러스터 상태로 복원

5.3.2.3. 추가 리소스

5.3.2.4. 영구 스토리지 상태 복원을 위한 문제 및 해결 방법

5.3.3. 만료된 컨트롤 플레인 인증서 복구

5.3.3.1. 만료된 컨트롤 플레인 인증서 복구

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links