- etcd 스냅샷을 기반으로 Kubernetes 클러스터 복원
- 재해 복구에 대한 구성
재해 복구에 대한 구성
이 솔루션 플레이북과 함께 제공되는 절차 및 스크립트를 사용하여 기본 Kubernetes 클러스터에
etcd 스냅샷을 생성하고 다른(보조) Kubernetes 클러스터 또는 소스 클러스터 자체에서 복원할 수 있습니다. 을 다운로드하고 스크립트를 사용하여 스냅샷을 구성하기 전에 구성을 계획하고 요구 사항을 이해하는 것이 중요합니다.
주:
이 솔루션은 제어 플레인 및 작업자 노드를 포함한 Kubernetes 클러스터가 이미 존재한다고 가정합니다.구성 계획
기본 시스템을 기반으로 보조 시스템에서 리소스 및 구성을 계획합니다.
주:
이 솔루션은 제어 플레인 및 작업자 노드를 포함한 Kubernetes 클러스터가 이미 존재한다고 가정합니다. 이 플레이북에 제공된 권장 사항 및 유틸리티는 리소스, 제어 플레인 또는 작업자 노드 용량 및 구성을 확인하지 않습니다.여기에 설명된 대로 복원은 기본 "미러링" 클러스터(동일한 제어 플레인 노드 수, 동일한 수의 워커 노드)에 적용할 수 있습니다. 이 절차에서는 kubeadm로 생성된 기본 Kubernetes 클러스터가 존재한다고 가정합니다. 보조 시스템의 호스트 이름은 다음 단락에 설명된 대로 기본 호스트를 모방하도록 구성됩니다. 그런 다음 kubeadm를 사용하여 보조 클러스터도 만들어집니다(필요한 호스트 이름 확인이 수행된 후에만 해당).
구성을 계획할 때 Restore에 대해 다음 요구 사항을 완료합니다.
- 1차의 필수 워커 노드 및 리소스가 2차에서 사용 가능한지 확인합니다. 여기에는 공유 스토리지 마운트, 로드 밸런서 및 복원할 네임스페이스에 사용되는 POD 및 시스템에서 사용되는 데이터베이스가 포함됩니다.
- 컨트롤 및 작업자 평면에서 사용되는 호스트 이름이 보조에서 유효하도록 호스트 이름 확인을 구성합니다.
예를 들어, 기본 사이트에서 다음과 유사한 클러스터를 분석하는 경우
[opc@olk8-m1 ~]$ kubectl get nodes -A NAME STATUS ROLES AGE VERSION olk8-m1 Ready control-plane 552d v1.25.12 olk8-m2 Ready control-plane 552d v1.25.12 olk8-m3 Ready control-plane 2y213d v1.25.12 olk8-w1 Ready <none> 2y213d v1.25.12 olk8-w2 Ready <none> 2y213d v1.25.12 olk8-w3 Ready <none> 2y213d v1.25.12 [opc@olk8-m1 ~]$ nslookup olk8-m1 Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: olk8-m1.k8dbfrasubnet.k8dbvcn.oraclevcn.com Address: 10.11.0.16그런 다음 보조 사이트에서 동일한 노드 이름을 사용해야 합니다. 제어 플레인에 있는 이전 예제 노드에서 영역 2의 호스트 이름은 다른 IP에 매핑된 것과 동일합니다.[opc@k8dramsnewbastion ~]$ nslookup olk8-m1 Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: olk8-m1.sub01261629121.k8drvcnams.oraclevcn.com Address: 10.5.176.144 [opc@k8dramsnewbastion ~]$kubeadm를 사용하여 클러스터를 만들고 작업자 노드를 추가한 후 보조 구성이 생성되면 내부 IP 및 기타 값이 지연되더라도 동일한 노드 이름이 사용됩니다.[opc@k8dramsnewbastion ~]$ kubectl get nodes -A NAME STATUS ROLES AGE VERSION olk8-m1 Ready control-plane 552d v1.25.11 olk8-m2 Ready control-plane 552d v1.25.11 olk8-m3 Ready control-plane 2y213d v1.25.11 olk8-w1 Ready <none> 2y213d v1.25.11 olk8-w2 Ready <none> 2y213d v1.25.11 olk8-w3 Ready <none> 2y213d v1.25.11 kube-api프론트 엔드 주소에 대해 유사한 "호스트 이름 별칭"을 사용합니다.주:
기본 Kubernetes 클러스터는 프론트엔드
kube-api에 IP 주소를 사용하지 않아야 합니다. 보조 시스템에서 이 프런트엔드를 별칭으로 지정할 수 있도록 호스트 이름을 사용해야 합니다. 기존 기본kube-api시스템에 호스트 이름 별칭을 추가하는 방법에 대한 예는 maak8s-kube-api-alias.sh 스크립트를 참조하십시오.예를 들어, 기본kube-api주소 확인이 다음과 같은 경우입니다.[opc@olk8-m1 ~]$ grep server .kube/config server: https://k8lbr.paasmaaoracle.com:6443 [opc@olk8-m1 ~]$ grep k8lbr.paasmaaoracle.com /etc/hosts 132.145.247.187 k8lbr.paasmaaoracle.com k8lbr그런 다음 보조의kube-api는 동일한 호스트 이름을 사용해야 합니다(다른 IP에 매핑할 수 있음).[opc@k8dramsnewbastion ~]$ grep server .kube/config server: https://k8lbr.paasmaaoracle.com:6443 [opc@k8dramsnewbastion ~]$ grep k8lbr.paasmaaoracle.com /etc/hosts 144.21.37.81 k8lbr.paasmaaoracle.com k8lbr각 위치에서 가상 호스트, 로컬/etc/hosts확인 또는 다른 DNS 서버를 사용하여 이 작업을 수행할 수 있습니다. 특정 호스트에서 사용되는 호스트 이름 분석 방법을 확인하려면 호스트의/etc/nsswitch.conf파일에서 hosts 매개변수 값을 검색합니다.-
호스트에서 로컬로 호스트 이름을 확인하려는 경우 파일 항목을
hosts매개변수의 첫번째 항목으로 만듭니다.files가 hosts 매개변수의 첫번째 항목인 경우 호스트/etc/hosts파일의 항목이 먼저 호스트 이름을 확인하는 데 사용됩니다./etc/nsswitch.conf파일에서 로컬 호스트 이름 분석 사용 지정:hosts: files dns nis -
호스트에서 DNS를 사용하여 호스트 이름을 분석하려면
dns항목을 hosts 매개변수에 대한 첫번째 항목으로 만듭니다.dns가hosts매개변수의 첫번째 항목인 경우 DNS 서버 항목이 먼저 호스트 이름을 확인하는 데 사용됩니다.DNS 호스트 이름 확인
/etc/nsswitch.conf파일 사용 지정:hosts: dns files nis
단순성과 일관성을 위해 Oracle은 사이트(운영 사이트 또는 대기 사이트) 내의 모든 호스트가 동일한 호스트 이름 분석 방법(로컬로 호스트 이름을 분석하거나 별도의 DNS 서버 또는 전역 DNS 서버를 사용하여 호스트 이름을 분석)을 사용할 것을 권장합니다.
"호스트 이름 별칭 지정" 기술은 수년간 미들웨어 시스템에 대한 재해 보호에서 사용되었습니다. Oracle Fusion Middleware Disaster Recovery Guide 및 Oracle Cloud Disaster Protection과 관련된 기타 문서(예: Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery 및 Oracle Cloud Infrastructure Marketplace Disaster Recovery의 SOA Suite)를 비롯한 자세한 내용과 예제는 Oracle 설명서에서 확인할 수 있습니다.
-
- 프론트 엔드
kube-api로드 밸런서에 대해 기본 클러스터와 동일한 호스트 이름을 사용하여 보조 클러스터를 생성합니다.호스트 이름 분석이 준비된 후에 이 단계를 수행합니다. Kuberneteskubeadm도구 설명서를 참조하십시오. 기본 버전과 동일한kubeadm및 Kubernetes 버전을 사용합니다. 컨테이너 런타임이 지연될 수 있지만 두 지역 모두에서 동일한 버전의 Kubernetes 인프라를 사용해야 합니다.예를 들어, 다음과 같이 기본 클러스터가 생성된 경우kubeadm init --control-plane-endpoint $LBR_HN:$LBR_PORT --pod-network-cidr=10.244.0.0/16 --node-name $mnode1 --upload-certs --v=9그런 다음 primary와 동일한
$LBR_HN:$LBR_PORT및 CIDR 값을 secondary에 사용하십시오. kOps 및 kubesparay와 같은 다른 클러스터 만들기 도구를 사용하는 경우에도 마찬가지입니다. - 제어 플레인 또는 작업자 노드를 추가할 때는 기본 및 보조 노드에 동일한 노드 이름을 사용해야 합니다.
kubeadm join $LBR_HN:$LBR_PORT --token $token --node-name $host --discovery-token-ca-cert-hash $token_ca --control-plane --certificate-key $cp_ca - 보조 클러스터가 구성되면 Kubernetes에서 노드 정보를 검색할 때 동일한 호스트 이름이 나타나야 합니다.
각 제어 플레인 및 워커 노드에 대해 보조에서 사용되는 $host 변수는 기본에서 사용되는 변수와 동일해야 합니다.
기본 클러스터
기본 데이터베이스에서 다음 명령을 실행하여 제어 플레인 및 작업자 노드 상태, 롤, 수명, 버전, 내부 IP, 외부 IP, OS 이미지, 커널 버전 및 컨테이너 런타임을 확인합니다.다음은 출력 예입니다.[opc@olk8-m1 ~]$ kubectl get nodes -o wide[opc@olk8-m1 ~]$ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME olk8-m1 Ready control-plane 578d v1.25.12 10.11.0.16 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1 olk8-m2 Ready control-plane 578d v1.25.12 10.11.210.212 <none> Oracle Linux Server 7.9 5.4.17-2136.301.1.3.el7uek.x86_64 cri-o://1.26.1 olk8-m3 Ready control-plane 2y238d v1.25.12 10.11.0.18 <none> Oracle Linux Server 7.9 4.14.35-2047.527.2.el7uek.x86_64 cri-o://1.26.1 olk8-w1 Ready <none> 2y238d v1.25.12 10.11.0.20 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1 olk8-w2 Ready <none> 2y238d v1.25.12 10.11.0.21 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1 olk8-w3 Ready <none> 2y238d v1.25.12 10.11.0.22 <none> Oracle Linux Server 7.9 4.14.35-1902.302.2.el7uek.x86_64 cri-o://1.26.1 [opc@olk8-m1 ~]$기본 데이터베이스에서 다음 명령을 실행하여 Kubernetes 제어 플레인 및 코어 DNS가 실행 중인 위치를 식별합니다.[opc@olk8-m1 ~]$ kubectl cluster-info보조 클러스터
2차 명령에서 다음 명령을 실행하여 제어 플레인 및 작업자 노드 상태, 롤, 수명, 버전, 내부 IP, 외부 IP, OS 이미지, 커널 버전 및 컨테이너 런타임을 확인합니다.[opc@k8dramsnewbastion ~]$ kubectl get node -o wide다음은 출력 예입니다.[opc@k8dramsnewbastion ~]$ kubectl get node -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME olk8-m1 Ready control-plane 579d v1.25.11 10.5.176.144 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.21 olk8-m2 Ready control-plane 579d v1.25.11 10.5.176.167 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.21 olk8-m3 Ready control-plane 2y239d v1.25.11 10.5.176.154 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.21 olk8-w1 Ready <none> 2y239d v1.25.11 10.5.176.205 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.22 olk8-w2 Ready <none> 2y239d v1.25.11 10.5.176.247 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.22 olk8-w3 Ready <none> 2y239d v1.25.11 10.5.176.132 <none> Oracle Linux Server 8.7 5.15.0-101.103.2.1.el8uek.x86_64 containerd://1.6.22 [opc@k8dramsnewbastion ~]$ kubectl cluster-info Kubernetes control plane is running at https://k8lbr.paasmaaoracle.com:6443 CoreDNS is running at https://k8lbr.paasmaaoracle.com:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. [opc@k8dramsnewbastion ~]$보조 명령에서 다음 명령을 실행하여 Kubernetes 제어 플레인 및 코어 DNS가 실행 중인 위치를 식별합니다.[opc@k8dramsnewbastion ~]$ kubectl cluster-infokubeadm클러스터 생성의 기본 설정으로etcd는 기본 및 보조의 동일한 포트를 사용합니다. 보조 클러스터에서 다른 포트를 사용해야 하는 경우 처리할 스크립트를 수정해야 합니다.etcds데이터베이스에 대해 기본 및 보조의 다른 저장 영역 위치를 사용할 수 있습니다. 스크립트는 보조 클러스터가etcd에 사용 중인 적절한 위치에서 복원을 처리합니다. - 기본 위치와 보조 위치(백업 및 복원 스크립트를 실행하는 노드)에
etcdctl를 모두 설치합니다.백업 및 복원 스크립트는etcdctl를 사용하여 클러스터에서 정보를 가져오고etcd스냅샷을 만들고 적용합니다.etcdctl를 설치하려면 https://github.com/etcd-io/etcd/releases 설명서를 참조하십시오. - 백업 및 복원 작업을 실행하는 노드가 이 유형의 액세스에 대해 사용으로 설정되도록 적절한 방화벽 및 보안 규칙이 제자리에 있는지 확인합니다.또한 스크립트는
kubectl를 사용하여 클러스터에 액세스하고 SSH 및 HTTP(셸 명령 및etcdctl작업의 경우)를 통해 다른 노드에 연결해야 합니다.
구성
재해 복구를 위해 구성합니다.
복원 단계는 다음과 같습니다.
- 기본 위치에서
etcd백업을 수행합니다. - 백업을 보조 위치로 배송합니다.
- 보조 클러스터에서 해당
etcd백업을 복원합니다.
다음 단계를 수행하십시오.
- 기본 Kubernetes 클러스터에
etcd백업을 생성합니다.- 이 문서의 "다운로드 코드" 섹션에서
etcd스냅샷 DR에 대한 스크립트를 모두 다운로드합니다.주:
기본 스크립트가 다른 보조 스크립트를 사용하기 때문에 모든 스크립트가 동일한 경로에 있어야 합니다. - 제어 플레인 노드
etcd구성에서 advert_port를 가져옵니다.[opc@olk8-m1 ~]$ sudo grep etcd.advertise-client-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}' 2379그리고init_port에도 마찬가지입니다.[opc@olk8-m1 ~]$ sudo grep initial-advertise-peer-urls /etc/kubernetes/manifests/etcd.yaml | awk -F ":" '{print $NF}' 2380이러한 포트는 기본 포트이며 모든 제어 플레인
etcd포드에서 사용됩니다. 드문 경우지만etcd가 각 노드에서 다른init및advertise포트를 사용하도록 사용자 정의된 경우 스크립트를 사용자 정의하여 고려해야 합니다. 다른 네트워크 플러그인이 사용되거나 특정 경우 복원 후 다른 관련 Pod 또는 배치를 재시작해야 하는 경우infra_pod_list에 대한 값을 사용자정의할 수도 있습니다. 그러나 일반적으로 파일에 제공된 값으로 기본 설정될 수 있습니다. maak8s.env스크립트를 편집하고 환경에 따라 변수를 갱신합니다.다음은maak8s.env파일의 예입니다.[opc@olk8-m1 ~]$ cat maak8s.env #sudo ready user to ssh into the control plane nodes export user=opc #ssh key for the ssh export ssh_key=/home/opc/KeyMAA.ppk #etcdctl executable's location export etcdctlhome=/scratch/etcdctl/ #etcd advertise port export advert_port=2379 #etcd init cluster port export init_port=2380 #infrastructure pods that will be restarted on restore export infra_pod_list="flannel proxy controller scheduler"maak8-etcd-backup.sh스크립트를 실행하고 인수로 다음 필드를 이 순서대로 제공합니다.- 백업이 저장될 디렉토리
- 백업을 설명하는 "LABEL/TEXT"
kubectl작업을 실행할 클러스터 구성의 위치
예:[opc@olk8-m1 ~]$ ./maak8-etcd-backup.sh /backup-volumes/ "ETCD Snapshot after first configuration " /home/opc/.kubenew/config
이 스크립트는 다음 작업을 수행합니다.
etcd마스터 노드에서etcd스냅샷을 생성합니다.- 클러스터에 대한 서명 키를 포함하여 각 제어 플레인 노드의 현재 구성 복사본(각 제어 플레인 노드에 대한 매니페스트 및 인증서)을 만듭니다.
- 노드, Pod, 서비스 및 클러스터 구성 목록을 기록합니다.
- 위의 모든 정보를 날짜 레이블이 지정된 디렉토리에 저장합니다. 명령행 인수에 지정된 디렉토리가
/backup-volume인 경우 백업은 백업의/backup-volume/etcd_snapshot_date아래에 저장됩니다. 예:/backup-volume/etcd_snapshot_2022-08-29_15-56-59.
- 이 문서의 "다운로드 코드" 섹션에서
- 보조 클러스터에 전체 디렉토리(
/backup-volume/etcd_snapshot_date)를 복사합니다.sftp도구를 사용하거나 디렉토리로 tar을 만들어 보조 위치로 보냅니다.- 보조 시스템(기본 시스템)에서 사용할 수 있도록 파일을 압축 해제하거나 압축을 풉니다.
- 백업의 날짜 레이블을 기록해 둡니다(위 예제에서는 2022-08-29_15-56-59).
예제[opc@olk8-m1 ~]$ scp -i KeyMAA.ppk -qr /backup-volume/etcd_snapshot_2022-08-29_15-56-59 154.21.39.171:/restore-volume [opc@olk8-m1 ~]$ ssh -i KeyMAA.ppk 154.21.39.171 "ls -lart /restore-volume" total 4 drwxrwxrwt. 6 root root 252 Aug 30 15:11 .. drwxrwxr-x. 3 opc opc 47 Aug 30 15:12 . drwxrwxr-x. 5 opc opc 4096 Aug 30 15:12 etcd_snapshot_2022-08-29_15-56-59 - 보조 위치에서 백업을 사용할 수 있게 되면 다음 단계에 따라 백업을 복원합니다.
etcd스냅샷 DR에 대한 모든 스크립트를 "Download Code" 섹션에서 복원을 실행할 보조 영역 노드로 다운로드합니다.이 노드에도etcdctl가 설치되어 있고 보조 클러스터에 대한kubectl액세스가 있어야 합니다.주:
기본 스크립트는 다른 보조 스크립트를 사용하기 때문에 다른 단계를 실행할 때 모든 스크립트가 동일한 경로에 있어야 합니다.maak8s.env스크립트를 편집하고 환경에 따라 변수를 갱신합니다.보조 노드에 따라 사용자, ssh 키 및etcdctl위치를 변경할 수 있지만advert및init포트는 기본 노드에서 사용되는 포트와 동일해야 합니다.다음은maak8s.env파일의 예입니다.[opc@olk8-m1 ~]$ cat maak8s.env #sudo ready user to ssh into the control plane nodes export user=opc #ssh key for the ssh export ssh_key=/home/opc/KeyMAA.ppk #etcdctl executable's location export etcdctlhome=/scratch/etcdctl/ #etcd advertise port export advert_port=2379 #etcd init cluster port export init_port=2380 #infrastructure pods that will be restarted on restore export infra_pod_list="flannel proxy controller scheduler"maak8-etcd-restore.sh스크립트를 사용하여 복원을 실행합니다. 백업이 기본에서 대기로 복사된 루트 디렉토리, 백업 시간기록 및 클러스터에 대한kubectl구성의 위치를 인수로 제공합니다.예제[opc@k8dramsnewbastion ~]$ ./maak8-etcd-restore.sh /restore-volume 2022-08-29_15-56-59 /home/opc/.kube/config이 스크립트는
/restore-volume디렉토리에서etcd_snapshot_date라는 하위 디렉토리를 찾습니다. 이 예에서는/restore-volume/etcd_snapshot_2022-08-29_15-56-59를 사용합니다.복원은 다음 작업을 수행합니다.- 제어 평면이 실행 중인 경우 강제로 보조에서 중지
- 모든 제어 플레인 노드에서
etcd스냅샷을 복원합니다. - 모든 제어 플레인 노드에서 클러스터 서명 키를 바꿉니다.
- 제어 플레인을 시작합니다.
- 클러스터의 모든 인프라 포드(프록시, 스케줄러, 컨트롤러) 및 배포를 재활용하여 일관된 상태로 전환
복원이 끝나면 보고서에는 Pod 및
etcd부속 시스템의 상태가 표시됩니다. 예제NAMESPACE NAME READY STATUS RESTARTS AGE default dnsutils 1/1 Running 0 27d default nginx-deployment-566ff9bd67-6rl7f 1/1 Running 0 19s default nginx-deployment-566ff9bd67-hnx69 1/1 Running 0 17s default nginx-deployment-566ff9bd67-hvrwq 1/1 Running 0 15s default test-pd 1/1 Running 0 26d kube-flannel kube-flannel-ds-4f2fz 1/1 Running 3 (22d ago) 35d kube-flannel kube-flannel-ds-cvqzh 1/1 Running 3 (22d ago) 35d kube-flannel kube-flannel-ds-dmbhp 1/1 Running 3 (22d ago) 35d kube-flannel kube-flannel-ds-skhz2 1/1 Running 3 (22d ago) 35d kube-flannel kube-flannel-ds-zgkkp 1/1 Running 4 (22d ago) 35d kube-flannel kube-flannel-ds-zpbn7 1/1 Running 3 (22d ago) 35d kube-system coredns-8f994fbf8-6ghs4 0/1 ContainerCreating 0 15s kube-system coredns-8f994fbf8-d79h8 1/1 Running 0 19s kube-system coredns-8f994fbf8-wcknd 1/1 Running 0 12s kube-system coredns-8f994fbf8-zh8w4 1/1 Running 0 19s kube-system etcd-olk8-m1 1/1 Running 22 (89s ago) 44s kube-system etcd-olk8-m2 1/1 Running 59 (88s ago) 44s kube-system etcd-olk8-m3 1/1 Running 18 (88s ago) 26s kube-system kube-apiserver-olk8-m1 1/1 Running 26 (89s ago) 44s kube-system kube-apiserver-olk8-m2 1/1 Running 60 (88s ago) 42s kube-system kube-apiserver-olk8-m3 1/1 Running 18 (88s ago) 27s kube-system kube-controller-manager-olk8-m1 1/1 Running 19 (89s ago) 10s kube-system kube-controller-manager-olk8-m2 1/1 Running 18 (88s ago) 10s kube-system kube-controller-manager-olk8-m3 1/1 Running 18 (88s ago) 10s kube-system kube-flannel-ds-62dcq 1/1 Running 0 19s kube-system kube-flannel-ds-bh5w7 1/1 Running 0 19s kube-system kube-flannel-ds-cc2rk 1/1 Running 0 19s kube-system kube-flannel-ds-p8kdk 1/1 Running 0 19s kube-system kube-flannel-ds-vj8r8 1/1 Running 0 18s kube-system kube-flannel-ds-wz2kv 1/1 Running 0 18s kube-system kube-proxy-28d98 1/1 Running 0 14s kube-system kube-proxy-2gb99 1/1 Running 0 15s kube-system kube-proxy-4dfjd 1/1 Running 0 14s kube-system kube-proxy-72l5q 1/1 Running 0 14s kube-system kube-proxy-s8zbs 1/1 Running 0 14s kube-system kube-proxy-tmqnm 1/1 Running 0 14s kube-system kube-scheduler-olk8-m1 0/1 Pending 0 5s kube-system kube-scheduler-olk8-m2 1/1 Running 18 (88s ago) 5s kube-system kube-scheduler-olk8-m3 1/1 Running 18 (88s ago) 5s newopns weblogic-operator-5d74f56886-mtjp6 0/1 Terminating 0 26d newopns weblogic-operator-webhook-768d9f6f79-tdt8b 0/1 Terminating 0 26d soans soaedgdomain-adminserver 0/1 Running 0 22d soans soaedgdomain-soa-server1 0/1 Running 0 22d soans soaedgdomain-soa-server2 0/1 Running 0 22d +--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS | +--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ | olk8-m1:2379 | 63c63522f0be24a6 | 3.5.6 | 146 MB | true | false | 2 | 1195 | 1195 | | | olk8-m2:2379 | 697d3746d6f10842 | 3.5.6 | 146 MB | false | false | 2 | 1195 | 1195 | | | olk8-m3:2379 | 7a23c67093a3029 | 3.5.6 | 146 MB | false | false | 2 | 1195 | 1195 | | +--------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+ +------------------+---------+---------+----------------------+---------------------------+------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+---------+----------------------+---------------------------+------------+ | 7a23c67093a3029 | started | olk8-m3 | https://olk8-m3:2380 | https://10.5.176.154:2379 | false | | 63c63522f0be24a6 | started | olk8-m1 | https://olk8-m1:2380 | https://10.5.176.144:2379 | false | | 697d3746d6f10842 | started | olk8-m2 | https://olk8-m2:2380 | https://10.5.176.167:2379 | false | +------------------+---------+---------+----------------------+---------------------------+------------+ Restore completed at 2023-08-30_15-18-22 [opc@k8dramsnewbastion ~]$
확인
maak8DR-apply.sh 스크립트를 실행한 후 기본 클러스터에 있는 모든 아티팩트가 보조 클러스터로 복제되었는지 확인합니다. 보조 클러스터를 살펴보고 보조 사이트의 POD가 오류 없이 실행 중인지 확인합니다.
- 필요한 포드가 기본의 상태와 일치할 때까지 보조 포드의 상태를 확인합니다. 기본적으로 Pod 및 배치는 보조 영역에서 시작됩니다. 복원이 끝나면 보조 클러스터의 상태가 표시됩니다. 일부 포드는 RUNNING 상태에 도달하는 데 추가 시간이 걸릴 수 있습니다.
- 가능한 오류는 보조에서
restore로그를 확인하십시오.로그 위치는 복원 시작 시 보고됩니다. 기본적으로 로그는 백업 자체가 있는 디렉토리(/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/restore.log) 아래에 생성됩니다. 다른 로그는 특히etcd스냅샷 복원 작업/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/etcd_op.log에 대해 생성됩니다. - (선택 사항) 되돌립니다.
복원 로그 외에도 이전
/etc/kubernetes구성의 백업은/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes디렉토리 아래의 각 제어 플레인 노드에 대해 생성됩니다. 마찬가지로 복원 전에 각 노드의etcd데이터베이스가/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name로 복사됩니다. 이러한 옵션을 사용하여 복원이 실행되기 전에 존재했던 클러스터 구성으로 되돌릴 수 있습니다.