5.4. 재해 복구

절차

1. 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.

2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.

   복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.

   중요

   이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

3. etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.

   이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된 backup 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로하고 있습니다.

4. 다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.

   참고

   복구 호스트에서 정적 Pod를 중지할 필요가 없습니다.

   1. 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.

   2. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. etcd pod가 중지되었는지 확인합니다.

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

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

   4. kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.

      $ sudo mv -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. Kubernetes API 서버 pod가 중지되었는지 확인합니다.

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

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

   6. etcd 데이터 디렉토리를 다른 위치로 이동합니다.

      $ sudo mv -v /var/lib/etcd/ /tmp

   7. /etc/kubernetes/manifests/keepalived.yaml 파일이 있고 노드가 삭제되면 다음 단계를 따르십시오.

      1. kubelet 매니페스트 디렉토리에서 /etc/kubernetes/manifests/keepalived.yaml 파일을 이동합니다.

         $ sudo mv -v /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>

   8. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
5. 복구 컨트롤 플레인 호스트에 액세스합니다.

6. keepalived 데몬이 사용 중인 경우 복구 컨트롤 플레인 노드가 VIP를 소유하고 있는지 확인합니다.

   $ ip -o address | grep <api_vip>

   VIP 주소가 있는 경우 출력에 강조 표시됩니다. VIP가 잘못 설정되거나 구성되지 않은 경우 이 명령은 빈 문자열을 반환합니다.

7. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

   작은 정보

   oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

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

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/assets/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

   참고

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

9. 노드가 Ready 상태에 있는지 확인합니다.

   1. 다음 명령을 실행합니다.

      $ oc get nodes -w

      샘플 출력

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

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

   2. 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

10. 모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.

    1. 복구 호스트에서 다음 명령을 실행합니다.

       $ sudo systemctl restart kubelet.service

    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

11. 보류 중인 CSR을 승인합니다.

    참고

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

    1. 현재 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(사용자 프로비저닝 설치용)입니다.

       3 4

       보류 중인 node-bootstrapper CSR입니다.

    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

       $ oc describe csr <csr_name> 1

       1

       <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

    3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

    4. 사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

12. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

    1. 복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다.

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

       출력 예

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

    2. 복구 호스트에서 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가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

13. OVNKubernetes 네트워크 플러그인을 사용하는 경우 복구 컨트롤 플레인 호스트가 아닌 컨트롤 플레인 호스트와 연결된 노드 오브젝트를 삭제합니다.

    $ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>

14. 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 분이 걸릴 수 있습니다.

15. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 다시 시작합니다.

    참고

    승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다. failurePolicy 를 Fail 로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.

    또는 클러스터 상태를 복원하는 동안 failurePolicy 를 Ignore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후 failurePolicy 를 Fail 로 설정할 수 있습니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트와 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다.

       $ sudo rm -f /var/lib/ovn/etc/*.db

    2. 다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.

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

    3. 다음 명령을 실행하여 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

    4. 다음 명령을 실행하여 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

    5. 모든 ovnkube-node Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.

       $ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node

16. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신이 다시 생성되면 새 버전이 강제 생성되고 etcd가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

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

         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 의 컨트롤 플레인 시스템입니다.

      2. 다음을 실행하여 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.

         $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

         손실된 컨트롤 플레인 호스트의 시스템을 삭제한 후 새 시스템이 자동으로 프로비저닝됩니다.

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

         $ 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는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

      4. 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

17. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

18. 복구 호스트 내의 별도의 터미널 창에서 다음 명령을 실행하여 복구 kubeconfig 파일을 내보냅니다.

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig

19. etcd를 강제로 재배포합니다.

    복구 kubeconfig 파일을 내보낸 동일한 터미널 창에서 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1

    1

    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.

20. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

21. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml

22. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

23. etcd를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 실행합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있으므로 Kubernetes API 서버는 다른 노드에 다시 설치됩니다.

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

    1. Kubernetes API 서버에 대해 새 롤아웃을 강제 적용합니다.

       $ 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    3. Kubernetes 스케줄러에 대해 새 롤아웃을 강제 적용합니다.

       $ 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

24. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 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

절차

1. 현재 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입니다.

2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

   $ oc describe csr <csr_name> 1

   1

   <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

   $ oc adm certificate approve <csr_name>

4. 사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다.

   $ oc adm certificate approve <csr_name>

1. 관리 클러스터 1에서 소스 관리 클러스터로 간주할 수 있으며 컨트롤 플레인 및 작업자는 외부 DNS API를 사용하여 상호 작용합니다. 외부 DNS API에 액세스할 수 있으며 로드 밸런서는 관리 클러스터 사이에 있습니다.

   

2. etcd, 컨트롤 플레인 및 작업자 노드가 포함된 호스팅 클러스터의 스냅샷을 생성합니다. 이 프로세스 중에 작업자 노드는 액세스할 수 없는 경우에도 외부 DNS API에 계속 액세스하려고 하며 워크로드가 실행되고 컨트롤 플레인은 로컬 매니페스트 파일에 저장되고 etcd는 S3 버킷으로 백업됩니다. 데이터 플레인이 활성화되고 컨트롤 플레인이 일시 중지되었습니다.

   

3. 대상 관리 클러스터 2의 경우 S3 버킷에서 etcd를 복원하고 로컬 매니페스트 파일에서 컨트롤 플레인을 복원합니다. 이 프로세스 중에 외부 DNS API가 중지되고 호스트된 클러스터 API에 액세스할 수 없게 되고 API를 사용하는 모든 작업자는 매니페스트 파일을 업데이트할 수 없지만 워크로드가 계속 실행되고 있습니다.

   

4. 외부 DNS API는 다시 액세스할 수 있으며 작업자 노드는 이를 사용하여 관리 클러스터 2로 이동합니다. 외부 DNS API는 컨트롤 플레인을 가리키는 로드 밸런서에 액세스할 수 있습니다.

   

5. 관리 클러스터 2에서 컨트롤 플레인 및 작업자 노드는 외부 DNS API를 사용하여 상호 작용합니다. 리소스는 etcd의 S3 백업을 제외하고 관리 클러스터 1에서 삭제됩니다. mangagement 클러스터 1에서 호스트 클러스터를 다시 설정하려고 하면 작동하지 않습니다.

   

절차

1. 다음 명령을 입력하여 소스 관리 클러스터를 선언할 configmap 파일을 생성합니다.

   $ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}

2. 다음 명령을 입력하여 호스팅 클러스터 및 노드 풀에서 조정을 종료합니다.

   PAUSED_UNTIL="true"
   oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator

   PAUSED_UNTIL="true"
   oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator

3. 다음 bash 스크립트를 실행하여 etcd를 백업하고 S3 버킷에 데이터를 업로드합니다.

   작은 정보

   이 스크립트를 함수로 래핑하고 main 함수에서 호출합니다.

   # ETCD Backup
   ETCD_PODS="etcd-0"
   if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
     ETCD_PODS="etcd-0 etcd-1 etcd-2"
   fi
   
   for POD in ${ETCD_PODS}; do
     # Create an etcd snapshot
     oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
     oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
   
     FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
     CONTENT_TYPE="application/x-compressed-tar"
     DATE_VALUE=`date -R`
     SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
   
     set +x
     ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
     SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
     SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64)
     set -x
   
     # FIXME: this is pushing to the OIDC bucket
     oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
       -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
       -H "Date: ${DATE_VALUE}" \
       -H "Content-Type: ${CONTENT_TYPE}" \
       -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
       https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db
   done

   etcd 백업에 대한 자세한 내용은 "호스트된 클러스터에서 etcd 백업 및 복원"을 참조하십시오.

4. 다음 명령을 입력하여 Kubernetes 및 OpenShift Container Platform 오브젝트를 백업합니다. 다음 오브젝트를 백업해야 합니다.

   • HostedCluster 네임스페이스의 HostedCluster 및 NodePool 오브젝트
   • HostedCluster 네임스페이스의 HostedCluster 시크릿
   • HostedControl Plane 네임스페이스의 HostedControlPlane
   • 호스팅 된 컨트롤 플레인 네임스페이스의 클러스터
   • AWSCluster,AWSMachineTemplate, AWSMachine Template 네임스페이스의 AWSMachineTemplate
   • MachineDeployments,MachineSets, Hosted Control Plane 네임스페이스의 머신

   • 호스팅된 컨트롤 플레인 네임스페이스의 controlPlane 시크릿

     mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
     chmod 700 ${BACKUP_DIR}/namespaces/
     
     # HostedCluster
     echo "Backing Up HostedCluster Objects:"
     oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
     echo "--> HostedCluster"
     sed -i '' -e '/^status:$/,$d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
     
     # NodePool
     oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
     echo "--> NodePool"
     sed -i '' -e '/^status:$/,$ d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
     
     # Secrets in the HC Namespace
     echo "--> HostedCluster Secrets:"
     for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do
         oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml
     done
     
     # Secrets in the HC Control Plane Namespace
     echo "--> HostedCluster ControlPlane Secrets:"
     for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do
         oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml
     done
     
     # Hosted Control Plane
     echo "--> HostedControlPlane:"
     oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml
     
     # Cluster
     echo "--> Cluster:"
     CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
     oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml
     
     # AWS Cluster
     echo "--> AWS Cluster:"
     oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml
     
     # AWS MachineTemplate
     echo "--> AWS Machine Template:"
     oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml
     
     # AWS Machines
     echo "--> AWS Machine:"
     CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
     for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml
     done
     
     # MachineDeployments
     echo "--> HostedCluster MachineDeployments:"
     for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         mdp_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml
     done
     
     # MachineSets
     echo "--> HostedCluster MachineSets:"
     for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         ms_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml
     done
     
     # Machines
     echo "--> HostedCluster Machine:"
     for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         m_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml
     done

5. 다음 명령을 입력하여 ControlPlane 경로를 정리합니다.

   $ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

   해당 명령을 입력하여 ExternalDNS Operator에서 Route53 항목을 삭제할 수 있습니다.

6. 이 스크립트를 실행하여 Route53 항목이 정리되었는지 확인합니다.

   function clean_routes() {
   
       if [[ -z "${1}" ]];then
           echo "Give me the NS where to clean the routes"
           exit 1
       fi
   
       # Constants
       if [[ -z "${2}" ]];then
           echo "Give me the Route53 zone ID"
           exit 1
       fi
   
       ZONE_ID=${2}
       ROUTES=10
       timeout=40
       count=0
   
       # This allows us to remove the ownership in the AWS for the API route
       oc delete route -n ${1} --all
   
       while [ ${ROUTES} -gt 2 ]
       do
           echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..."
           echo "Try: (${count}/${timeout})"
           sleep 10
           if [[ $count -eq timeout ]];then
               echo "Timeout waiting for cleaning the Route53 DNS records"
               exit 1
           fi
           count=$((count+1))
           ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN})
       done
   }
   
   # SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>"
   clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"

절차

1. 다음 명령을 입력하여 새 관리 클러스터에 복원 중인 클러스터의 네임스페이스가 포함되어 있지 않은지 확인합니다.

   # Just in case
   export KUBECONFIG=${MGMT2_KUBECONFIG}
   BACKUP_DIR=${HC_CLUSTER_DIR}/backup
   
   # Namespace deletion in the destination Management cluster
   $ oc delete ns ${HC_CLUSTER_NS} || true
   $ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true

2. 다음 명령을 입력하여 삭제된 네임스페이스를 다시 생성합니다.

   # Namespace creation
   $ oc new-project ${HC_CLUSTER_NS}
   $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}

3. 다음 명령을 입력하여 HC 네임스페이스에 보안을 복원합니다.

   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*

4. 다음 명령을 입력하여 HostedCluster 컨트롤 플레인 네임스페이스의 오브젝트를 복원합니다.

   # Secrets
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*
   
   # Cluster
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*

5. AWS 인스턴스를 재사용하기 위해 노드와 노드 풀을 복구하는 경우 다음 명령을 입력하여 HC 컨트롤 플레인 네임스페이스의 오브젝트를 복원합니다.

   # AWS
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*
   
   # Machines
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*

6. 이 bash 스크립트를 실행하여 etcd 데이터 및 호스팅 클러스터를 복원하십시오.

   ETCD_PODS="etcd-0"
   if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
     ETCD_PODS="etcd-0 etcd-1 etcd-2"
   fi
   
   HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml
   HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
   HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml
   cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE}
   cat > ${HC_RESTORE_FILE} <<EOF
       restoreSnapshotURL:
   EOF
   
   for POD in ${ETCD_PODS}; do
     # Create a pre-signed URL for the etcd snapshot
     ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
     ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT})
   
     # FIXME no CLI support for restoreSnapshotURL yet
     cat >> ${HC_RESTORE_FILE} <<EOF
       - "${ETCD_SNAPSHOT_URL}"
   EOF
   done
   
   cat ${HC_RESTORE_FILE}
   
   if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then
     sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE}
     sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE}
   fi
   
   HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true)
   if [[ ${HC} == "" ]];then
       echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace"
       oc apply -f ${HC_NEW_FILE}
   else
       echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step"
   fi

7. AWS 인스턴스를 재사용하기 위해 노드와 노드 풀을 복구하는 경우 다음 명령을 입력하여 노드 풀을 복원합니다.

   oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*

절차

1. 다음 명령을 입력하여 배포 및 상태 저장 세트 오브젝트를 확장합니다.

   # Just in case
   export KUBECONFIG=${MGMT_KUBECONFIG}
   
   # Scale down deployments
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
   oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
   sleep 15

2. 다음 명령을 입력하여 NodePool 오브젝트를 삭제합니다.

   NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}')
   if [[ ! -z "${NODEPOOLS}" ]];then
       oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
       oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS}
   fi

3. 다음 명령을 입력하여 machine 및 machineset 오브젝트를 삭제합니다.

   # Machines
   for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
       oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
       oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
   done
   
   oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true

4. 다음 명령을 입력하여 클러스터 오브젝트를 삭제합니다.

   # Cluster
   C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
   oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
   oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

5. 이러한 명령을 입력하여 AWS 머신(Kubernetes 오브젝트)을 삭제합니다. 실제 AWS 머신 삭제에 대해 우려하지 마십시오. 클라우드 인스턴스는 영향을 받지 않습니다.

   # AWS Machines
   for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
   do
       oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
       oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
   done

6. 다음 명령을 입력하여 Hosted ControlPlane 및 ControlPlane HC 네임스페이스 오브젝트를 삭제합니다.

   # Delete HCP and ControlPlane HC NS
   oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
   oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
   oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true

7. 다음 명령을 입력하여 HostedCluster 및 HC 네임스페이스 오브젝트를 삭제합니다.

   # Delete HC and HC Namespace
   oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true
   oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME}  || true
   oc delete ns ${HC_CLUSTER_NS} || true

1. 호스트 클러스터의 kubeconfig 경로를 사용하여 KUBECONFIG 환경 변수를 로드합니다.

2. 다음 명령을 입력합니다.

   $ oc delete pod -n openshift-ovn-kubernetes --all

절차

1. 다음 스크립트의 변수를 정보로 교체합니다.

   # Fill the Common variables to fit your environment, this is just a sample
   SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
   BASE_PATH=${HOME}/hypershift
   BASE_DOMAIN="aws.sample.com"
   PULL_SECRET_FILE="${HOME}/pull_secret.json"
   AWS_CREDS="${HOME}/.aws/credentials"
   CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
   HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
   HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
   HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
   NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}
   
   # MGMT Context
   MGMT_REGION=us-west-1
   MGMT_CLUSTER_NAME="${USER}-dev"
   MGMT_CLUSTER_NS=${USER}
   MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
   MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"
   
   # MGMT2 Context
   MGMT2_CLUSTER_NAME="${USER}-dest"
   MGMT2_CLUSTER_NS=${USER}
   MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
   MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"
   
   # Hosted Cluster Context
   HC_CLUSTER_NS=clusters
   HC_REGION=us-west-1
   HC_CLUSTER_NAME="${USER}-hosted"
   HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
   HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
   BACKUP_DIR=${HC_CLUSTER_DIR}/backup
   
   BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"
   
   # DNS
   AWS_ZONE_ID="Z026552815SS3YPH9H6MG"
   EXTERNAL_DNS_DOMAIN="guest.jpdv.aws.kerbeross.com"

2. 로컬 파일 시스템에 스크립트를 저장합니다.

3. 다음 명령을 입력하여 스크립트를 실행합니다.

   source <env_file>

   여기서: env_file 은 스크립트를 저장한 파일의 이름입니다.

   마이그레이션 스크립트는 다음 리포지토리에서 유지 관리됩니다. https://github.com/openshift/hypershift/blob/main/contrib/migration/migrate-hcp.sh.