- etcd 스냅샷을 기반으로 Kubernetes 클러스터 복원
- Disaster Recovery에 대한 구성
Disaster Recovery에 대한 구성
이 솔루션 플레이북과 함께 제공된 절차 및 스크립트를 사용하여 기본 Kubernetes 클러스터에 etcd 스냅샷을 생성하고 다른(보조) Kubernetes 클러스터 또는 소스 클러스터 자체에서 복원할 수 있습니다. 스냅샷을 구성하려면 및 스크립트를 사용하기 전에 구성을 계획하고 요구 사항을 이해하는 것이 중요합니다.
참고:
이 솔루션은 제어 플레인 및 작업자 노드를 비롯한 Kubernetes 클러스터가 모두 존재한다고 가정합니다.구성 계획
기본 시스템을 기반으로 보조 시스템에서 리소스 및 구성을 계획합니다.
참고:
이 솔루션은 제어 플레인 및 작업자 노드를 비롯한 Kubernetes 클러스터가 모두 존재한다고 가정합니다. 이 플레이북에 제공된 권장 사항 및 유틸리티는 리소스, 제어 플레인 또는 작업자 노드 용량 및 구성을 확인하지 않습니다.여기에 설명된 대로 복구를 기본 클러스터(동일한 수의 제어 플레인 노드, 동일한 수의 워커 노드)에 적용할 수 있습니다. 이 절차에서는 kubeadm로 생성된 기본 Kubernetes 클러스터가 있다고 가정합니다. 보조 시스템의 호스트 이름은 다음 단락에 설명된 대로 기본 시스템을 모방하도록 구성됩니다. 그런 다음 kubeadm를 사용하여 보조 클러스터도 만들어집니다. 필요한 호스트 이름 분석이 처리된 후에만 생성됩니다.
구성을 계획할 때 Restore에 대해 다음 요구 사항을 완료하십시오.
- 기본 노드의 필수 워커 노드 및 리소스를 보조로 사용할 수 있는지 확인합니다. 여기에는 공유 스토리지 마운트, 로드 밸런서 및 복원할 네임스페이스에 사용되는 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그런 다음 기본에서와 동일한
$LBR_HN:$LBR_PORT및 CIDR 값을 보조에 사용합니다. 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보조 클러스터
보조에서 다음 명령을 실행하여 제어 플레인 및 워커 노드 상태, 역할, 수명, 버전, 내부 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작업의 경우)를 통해 다른 노드에 연결해야 합니다.
구성
Disaster Recovery를 구성합니다.
복원 단계는 다음과 같습니다.
- 기본 위치에
etcd백업을 수행합니다. - 보조 위치로 백업을 옮깁니다.
- 보조 클러스터에서
etcd백업을 복원합니다.
다음 단계를 수행하십시오.
- 기본 Kubernetes 클러스터에
etcd백업을 생성합니다.- 이 문서의 "Download Code" 섹션에서
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포드에서 사용됩니다. 드문 경우지만 각 노드에서 다른init및advertise포트를 사용하도록etcd를 사용자 정의한 경우 이를 고려하도록 스크립트를 사용자 정의해야 합니다. 다른 네트워크 플러그인이 사용되거나 기타 관련 포드 또는 배치가 특정 경우 복원 후 다시 시작되어야 하는 경우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.
- 이 문서의 "Download Code" 섹션에서
- 전체 디렉토리(
/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 - 보조 위치에서 백업을 사용할 수 있게 되면 다음 단계에 따라 백업을 복원합니다.
- "Download Code" 섹션에서 복원을 실행할 보조 영역 노드로
etcd스냅샷 DR에 대한 모든 스크립트를 다운로드합니다.이 노드에는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(프록시, 스케줄러, 컨트롤러) 및 배치(일관된 상태로 만들기)를 재활용합니다.
복원이 끝나면 보고서에 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 ~]$
- "Download Code" 섹션에서 복원을 실행할 보조 영역 노드로
확인
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에 대해 특별히 생성됩니다. - (선택 사항) 되돌립니다.
복원 로그 외에도
/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/current_etc_kubernetes디렉토리 아래의 제어 플레인 노드 각각에 대해 이전/etc/kubernetes구성의 백업이 생성됩니다. 마찬가지로 복원을/backup_dir/etcd_snapshot_backup-date/restore_attempted_restore-date/node_name로 복사하기 전에 각 노드의etcd데이터베이스도 복사됩니다. 이 옵션을 사용하여 복원이 실행되기 전에 있던 클러스터 구성으로 되돌릴 수 있습니다.