Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

백업 및 복원

OpenShift Container Platform 4.8

OpenShift Container Platform 클러스터 백업 및 복원

Red Hat OpenShift Documentation Team

초록

이 문서는 클러스터 데이터를 백업하고 다양한 재해 시나리오에서 복구하는 방법에 대해 설명합니다.

1장. 백업 및 복원
링크 복사

1.1. OpenShift Container Platform의 백업 및 복원 작업 개요
링크 복사

클러스터 관리자는 잠시 동안 OpenShift Container Platform 클러스터를 중지하고 나중에 다시 시작해야 할 수 있습니다. 클러스터를 다시 시작해야 하는 몇 가지 이유는 클러스터에서 유지 관리를 수행하거나 리소스 비용을 줄여야 하기 때문입니다. OpenShift Container Platform에서는 나중에 클러스터를 쉽게 다시 시작할 수 있도록 클러스터의 정상 종료를 수행할 수 있습니다.

클러스터를 종료하기 전에 etcd 데이터를 백업 해야 합니다. etcd는 OpenShift Container Platform의 키-값 저장소로, 모든 리소스 오브젝트의 상태를 유지합니다. etcd 백업은 재해 복구에 중요한 역할을 합니다. OpenShift Container Platform에서는 비정상적인 etcd 멤버를 교체할 수도 있습니다.

클러스터를 다시 실행하려면 클러스터를 정상적으로 다시 시작합니다.

참고

클러스터의 인증서는 설치 날짜로부터 1년 후에 만료됩니다. 인증서가 유효한 동안 클러스터를 종료하고 정상적으로 다시 시작할 수 있습니다. 클러스터에서 만료된 컨트롤 플레인 인증서를 자동으로 검색하더라도 CSR(인증서 서명 요청)을 계속 승인해야 합니다.

다음과 같이 OpenShift Container Platform이 예상대로 작동하지 않는 여러 상황을 초래할 수 있습니다.

  • 노드 오류 또는 네트워크 연결 문제와 같이 예기치 않은 상태로 인해 재시작 후 작동하지 않는 클러스터가 있습니다.
  • 클러스터에서 중요한 것을 실수로 삭제했습니다.
  • 대부분의 컨트롤 플레인 호스트가 손실되어 etcd 쿼럼이 손실됩니다.

저장된 etcd 스냅샷을 사용하여 클러스터를 이전 상태로 복원하여 재해 상황에서 항상 복구할 수 있습니다.

1.2. 애플리케이션 백업 및 복원 작업
링크 복사

클러스터 관리자는 OADP(데이터 보호)용 OpenShift API를 사용하여 OpenShift Container Platform에서 실행되는 애플리케이션을 백업하고 복원할 수 있습니다.

OADP는 Velero 1.7 을 사용하여 네임스페이스 단위로 Kubernetes 리소스 및 내부 이미지를 백업하고 복원합니다. OADP는 스냅샷 또는 Restic을 사용하여 PV(영구 볼륨)를 백업하고 복원합니다. 자세한 내용은 OADP 기능을 참조하십시오.

1.2.1. OADP 요구 사항
링크 복사

OADP에는 다음과 같은 요구 사항이 있습니다.

  • cluster-admin 역할의 사용자로 로그인해야 합니다.

  • 다음 스토리지 유형 중 하나와 같은 백업을 저장하기 위한 오브젝트 스토리지가 있어야 합니다.

    • OpenShift Data Foundation
    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud Platform
    • S3 호환 오브젝트 스토리지
중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

  • 스냅샷으로 PV를 백업하려면 기본 스냅샷 API가 있는 클라우드 스토리지가 있거나 다음 공급자와 같은 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.

    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud Platform
    • CSI 스냅샷 지원 클라우드 스토리지(예: Ceph RBD 또는 Ceph FS)
참고

스냅샷을 사용하여 PV를 백업하지 않으려면 OADP Operator가 기본적으로 설치하는 Restic 을 사용할 수 있습니다.

1.2.2. 애플리케이션 백업 및 복원
링크 복사

Backup CR(사용자 정의 리소스)을 생성하여 애플리케이션을 백업합니다. 다음 백업 옵션을 구성할 수 있습니다.

Restore CR을 생성하여 애플리케이션을 복원합니다. 복원 후크는 복원 작업 중에 init 컨테이너 또는 애플리케이션 컨테이너에서 명령을 실행하도록 구성할 수 있습니다.

2장. 클러스터를 안전하게 종료
링크 복사

이 문서에서는 클러스터를 안전하게 종료하는 프로세스를 설명합니다. 유지 관리를 위해 또는 리소스 비용을 절약하기 위해 일시적으로 클러스터를 종료해야 할 수 있습니다.

2.1. 전제 조건
링크 복사

  • 클러스터를 종료하기 전에 etcd 백업을 만듭니다.

2.2. 클러스터 종료
링크 복사

나중에 클러스터를 다시 시작하기 위해 안전한 방법으로 클러스터를 종료할 수 있습니다.

참고

설치 날짜부터 1년까지 클러스터를 종료하고 정상적으로 다시 시작할 수 있습니다. 설치 날짜로부터 1년 후에는 클러스터 인증서가 만료됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    클러스터를 다시 시작할 때 문제가 발생할 경우 클러스터를 복원 할 수 있도록 이 단계를 수행하기 전에 etcd 백업을 해 두는 것이 중요합니다.

절차

  1. 연장된 기간 동안 클러스터를 종료하는 경우 인증서가 만료되는 날짜를 확인합니다. 

    $ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}'
    Copy to Clipboard Toggle word wrap

    출력 예

    2022-08-05T14:37:50Zuser@user:~ $
    1
    Copy to Clipboard Toggle word wrap

    1
    클러스터를 정상적으로 다시 시작할 수 있도록 지정된 날짜 또는 그 이전에 클러스터를 다시 시작하도록 계획합니다. 클러스터가 재시작되면 프로세스에서 kubelet 인증서를 복구하기 위해 보류 중인 인증서 서명 요청(CSR)을 수동으로 승인해야 할 수 있습니다.

  2. 클러스터의 모든 노드를 종료합니다. 클라우드 공급자의 웹 콘솔에서 이 작업을 수행하거나 다음 반복문을 실행할 수 있습니다. 

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done
    1
    Copy to Clipboard Toggle word wrap
    1
    -H 1 은 컨트롤 플레인 노드가 종료되기 전에 이 프로세스가 얼마나 오래 지속되는지를 나타냅니다. 노드가 10개 이상인 대규모 클러스터의 경우 모든 컴퓨팅 노드를 먼저 종료할 시간이 있는지 확인하려면 10분 이상으로 설정합니다.

    출력 예

    Starting pod/ip-10-0-130-169us-east-2computeinternal-debug ...
To use host binaries, run `chroot /host`
Shutdown scheduled for Mon 2021-09-13 09:36:17 UTC, use 'shutdown -c' to cancel.

Removing debug pod ...
Starting pod/ip-10-0-150-116us-east-2computeinternal-debug ...
To use host binaries, run `chroot /host`
Shutdown scheduled for Mon 2021-09-13 09:36:29 UTC, use 'shutdown -c' to cancel.
    Copy to Clipboard Toggle word wrap

    이러한 방법 중 하나를 사용하여 노드를 종료하면 pod가 정상적으로 종료되어 데이터 손상 가능성을 줄일 수 있습니다.

    참고

    대규모 클러스터의 경우 종료 시간을 더 길게 조정합니다. 

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 10; done
    Copy to Clipboard Toggle word wrap
    참고

    종료하기 전에 OpenShift Container Platform과 함께 제공되는 표준 pod의 컨트롤 플레인 노드 (마스터 노드라고도 함)를 드레인할 필요가 없습니다.

    클러스터 관리자는 클러스터를 다시 시작한 후 워크로드를 완전히 다시 시작해야 합니다. 사용자 지정 워크로드로 인해 종료하기 전에 컨트롤 플레인 노드를 드레 이한 경우 다시 시작한 후 클러스터가 다시 작동하기 전에 컨트롤 플레인 노드를 스케줄 대상으로 표시해야합니다.

  3. 외부 스토리지 또는 LDAP 서버와 같이 더 이상 필요하지 않은 클러스터 종속성을 중지합니다. 이 작업을 수행하기 전에 공급 업체의 설명서를 확인하십시오.

3장. 클러스터를 정상적으로 다시 시작
링크 복사

이 문서에서는 정상 종료 후 클러스터를 다시 시작하는 프로세스에 대해 설명합니다.

다시 시작한 후 클러스터가 정상적으로 작동할 것으로 예상되지만 예상치 못한 상황으로 인해 클러스터가 복구되지 않을 수 있습니다. 예를 들면 다음과 같습니다.

  • 종료 중 etcd 데이터 손상
  • 하드웨어로 인한 노드 오류
  • 네트워크 연결 문제

클러스터를 복구할 수 없는 경우 다음 단계에 따라이전 클러스터 상태로 복원합니다.

3.1. 전제 조건
링크 복사

3.2. 클러스터를 다시 시작
링크 복사

클러스터가 정상적으로 종료된 후 클러스터를 다시 시작할 수 있습니다.

전제 조건

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 이 프로세스에서는 클러스터를 정상적으로 종료하고 있는 것을 전제로 하고 있습니다.

프로세스

  1. 외부 스토리지 또는 LDAP 서버와 같은 클러스터의 종속 장치를 시작합니다.

  2. 모든 클러스터 시스템을 시작합니다.

    클라우드 제공 업체의 웹 콘솔에서 시스템을 시작하는 것과 같이 클라우드 환경에 적합한 방법을 사용하여 시스템을 시작합니다.

    약 10 분 정도 기다린 후 컨트롤 플레인 노드 (마스터 노드라고도 함)의 상태를 확인합니다.

  3. 모든 컨트롤 플레인 노드가 준비되었는지 확인합니다. 

    $ oc get nodes -l node-role.kubernetes.io/master
    Copy to Clipboard Toggle word wrap

    다음 출력에 표시된 대로 노드의 상태가 Ready인 경우 컨트롤 플레인 노드는 준비된 것입니다. 

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   75m   v1.21.0
ip-10-0-170-223.ec2.internal   Ready    master   75m   v1.21.0
ip-10-0-211-16.ec2.internal    Ready    master   75m   v1.21.0
    Copy to Clipboard Toggle word wrap

  4. 컨트롤 플레인 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

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

      $ oc get csr
      Copy to Clipboard Toggle word wrap

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

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  5. 컨트롤 플레인 노드가 준비되면 모든 작업자 노드가 준비되었는지 확인합니다. 

    $ oc get nodes -l node-role.kubernetes.io/worker
    Copy to Clipboard Toggle word wrap

    다음 출력에 표시된 대로 작업자 노드의 상태가 Ready인 경우 작업자 노드는 준비된 것입니다. 

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.21.0
ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.21.0
ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.21.0
    Copy to Clipboard Toggle word wrap

  6. 작업자 노드가 준비되지 않은 경우 승인해야하는 보류중인 인증서 서명 요청(CSR)이 있는지 확인합니다.

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

      $ oc get csr
      Copy to Clipboard Toggle word wrap

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

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

  7. 클러스터가 제대로 시작되었는지 확인합니다.

    1. 성능이 저하된 클러스터 Operator가 없는지 확인합니다. 

      $ oc get clusteroperators
      Copy to Clipboard Toggle word wrap

      DEGRADED 조건이 True로 설정된 클러스터 Operator가 없는지 확인합니다. 

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.8.0     True        False         False      59m
cloud-credential                           4.8.0     True        False         False      85m
cluster-autoscaler                         4.8.0     True        False         False      73m
config-operator                            4.8.0     True        False         False      73m
console                                    4.8.0     True        False         False      62m
csi-snapshot-controller                    4.8.0     True        False         False      66m
dns                                        4.8.0     True        False         False      76m
etcd                                       4.8.0     True        False         False      76m
...
      Copy to Clipboard Toggle word wrap

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

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      모든 노드의 상태가 Ready 상태인지 확인합니다. 

      NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.21.0
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.21.0
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.21.0
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.21.0
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.21.0
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.21.0
      Copy to Clipboard Toggle word wrap

클러스터가 제대로 시작되지 않은 경우 etcd 백업을 사용하여 클러스터를 복원해야 할 수 있습니다.

4장. 애플리케이션 백업 및 복원
링크 복사

4.1. OADP 기능 및 플러그인
링크 복사

OADP(데이터 보호) 기능을 위한 OpenShift API는 애플리케이션을 백업 및 복원하는 옵션을 제공합니다.

기본 플러그인을 사용하면 Velero가 특정 클라우드 공급자와 통합하고 OpenShift Container Platform 리소스를 백업 및 복원할 수 있습니다.

4.1.1. OADP 기능
링크 복사

OADP(데이터 보호)용 OpenShift API는 다음과 같은 기능을 지원합니다.

Backup

클러스터의 모든 리소스를 백업하거나 유형, 네임스페이스 또는 레이블로 리소스를 필터링할 수 있습니다.

OADP는 오브젝트 스토리지에 아카이브 파일로 저장하여 Kubernetes 오브젝트 및 내부 이미지를 백업합니다. OADP는 기본 클라우드 스냅샷 API 또는 CSI(Container Storage Interface)를 사용하여 스냅샷을 생성하여 PV(영구 볼륨)를 백업합니다. 스냅샷을 지원하지 않는 클라우드 공급자의 경우 OADP는 Restic을 사용하여 리소스 및 PV 데이터를 백업합니다.

Restore
백업에서 리소스와 PV를 복원할 수 있습니다. 백업의 모든 오브젝트를 복원하거나 네임스페이스, PV 또는 레이블별로 복원된 오브젝트를 필터링할 수 있습니다.
일정
지정된 간격으로 백업을 예약할 수 있습니다.
후크
후크를 사용하여 Pod의 컨테이너에서 명령을 실행할 수 있습니다(예: fsfreeze ) 파일 시스템을 정지할 수 있습니다. 백업 또는 복원 전이나 후에 실행할 후크를 구성할 수 있습니다. 복원 후크는 init 컨테이너 또는 애플리케이션 컨테이너에서 실행될 수 있습니다.

4.1.2. OADP 플러그인
링크 복사

OADP(OpenShift API for Data Protection)는 백업 및 스냅샷 작업을 지원하기 위해 스토리지 공급자와 통합된 기본 Velero 플러그인을 제공합니다. Velero 플러그인을 기반으로 사용자 정의 플러그인을 생성할 수 있습니다.

OADP는 OpenShift Container Platform 리소스 백업 및 CSI(Container Storage Interface) 스냅샷에 대한 플러그인도 제공합니다.

Expand
표 4.1. OADP 플러그인
OADP 플러그인함수스토리지 위치

AWS

오브젝트 저장소를 사용하여 Kubernetes 오브젝트를 백업 및 복원합니다.

AWS S3

스냅샷을 사용하여 볼륨을 백업하고 복원합니다.

AWS EBS

azure

오브젝트 저장소를 사용하여 Kubernetes 오브젝트를 백업 및 복원합니다.

Microsoft Azure Blob 스토리지

스냅샷을 사용하여 볼륨을 백업하고 복원합니다.

Microsoft Azure 관리 디스크

gcp

오브젝트 저장소를 사용하여 Kubernetes 오브젝트를 백업 및 복원합니다.

Google Cloud Storage

스냅샷을 사용하여 볼륨을 백업하고 복원합니다.

Google Compute Engine 디스크

openshift

오브젝트 저장소를 사용하여 OpenShift Container Platform 리소스를 백업 및 복원합니다. [1]

오브젝트 저장소

csi

CSI 스냅샷을 사용하여 볼륨을 백업 및 복원합니다. [2]

CSI 스냅샷을 지원하는 클라우드 스토리지

  1. 필수 항목입니다.
  2. csi 플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다.

4.1.3. OADP Velero 플러그인 정보
링크 복사

Velero를 설치할 때 다음 두 가지 유형의 플러그인을 구성할 수 있습니다.

  • 기본 클라우드 공급자 플러그인
  • 사용자 정의 플러그인

두 가지 유형의 플러그인은 모두 선택 사항이지만 대부분의 사용자는 하나 이상의 클라우드 공급자 플러그인을 구성합니다.

4.1.3.1. 기본 Velero 클라우드 공급자 플러그인
링크 복사

배포 중에 oadp_v1alpha1_dpa.yaml 파일을 구성할 때 다음과 같은 기본 Velero 클라우드 공급자 플러그인을 설치할 수 있습니다.

  • AWS (Amazon Web Services)
  • GCP (Google Cloud Platform)
  • azure (Microsoft Azure)
  • OpenShift (OpenShift Velero 플러그인)
  • CSI (컨테이너 스토리지 인터페이스)
  • Kube Virt(KubeVirt)

배포 중에 oadp_v1alpha1_dpa.yaml 파일에 원하는 기본 플러그인을 지정합니다.

예제 파일

다음 .yaml 파일은 openshift,aws,azure, gcp 플러그인을 설치합니다. 

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp
Copy to Clipboard Toggle word wrap
4.1.3.2. 사용자 정의 Velero 플러그인
링크 복사

배포 중에 oadp_v1alpha1_dpa.yaml 파일을 구성할 때 플러그인 이미지 및 이름을 지정하여 사용자 정의 Velero 플러그인을 설치할 수 있습니다.

배포 중에 oadp_v1alpha1_dpa.yaml 파일에 원하는 사용자 지정 플러그인을 지정합니다.

예제 파일

다음 .yaml 파일은 기본 openshift,azure, gcp 플러그인 및 이름이 custom-plugin-example 이고 quay.io/example-repo/custom-velero-plugin 이미지가 있는 사용자 정의 플러그인을 설치합니다. 

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin
Copy to Clipboard Toggle word wrap

4.2. OADP 설치 및 구성
링크 복사

4.2.1. OADP 설치 정보
링크 복사

클러스터 관리자는 OADP Operator를 설치하여 OADP(데이터 보호)용 OpenShift API를 설치합니다. OADP Operator는 Velero 1.7 을 설치합니다.

Kubernetes 리소스 및 내부 이미지를 백업하려면 다음 스토리지 유형 중 하나와 같은 백업 위치로 오브젝트 스토리지가 있어야 합니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

스냅샷 또는 Restic을 사용하여 PV(영구 볼륨)를 백업할 수 있습니다.

스냅샷으로 PV를 백업하려면 다음 클라우드 공급자 중 하나와 같은 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원하는 클라우드 공급자가 있어야 합니다.

클라우드 공급자가 스냅샷을 지원하지 않거나 스토리지가 NFS인 경우 Restic.

스토리지 공급자 인증 정보에 대한 Secret 오브젝트를 생성한 다음 데이터 보호 애플리케이션을 설치합니다.

추가 리소스
  • Velero 문서 의 백업 위치 및 스냅샷 위치에 대한 개요입니다.

OADP Operator를 설치하고 Velero에 AWS를 구성한 다음 데이터 보호 애플리케이션을 설치하여 AWS(Amazon Web Services)를 사용하여 OADP(Data Protection)용 OpenShift API를 설치합니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.2.2.1. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.8에 OADP(Data Protection) Operator의 OpenShift API를 설치합니다.

OADP Operator는 Velero 1.7 을 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
  5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.
4.2.2.2. Amazon Web Services S3 구성
링크 복사

MTC(Migration Toolkit for Containers)의 복제 리포지토리로 AWS(Amazon Web Services) S3 스토리지 버킷을 구성할 수 있습니다.

사전 요구 사항

  • 소스 및 대상 클러스터에서 AWS S3 스토리지 버킷에 액세스할 수 있어야 합니다.
  • AWS CLI가 설치되어 있어야 합니다.

  • 스냅샷 복사 방법을 사용하는 경우:

    • EC2 EBS(Elastic Block Storage)에 액세스할 수 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

프로세스

  1. AWS S3 버킷을 생성합니다. 

    $ aws s3api create-bucket \
    --bucket <bucket> \
    1 
    
    --region <bucket_region>
    2
    Copy to Clipboard Toggle word wrap
    1
    S3 버킷 이름을 지정합니다.
    2
    S3 버킷 영역을 지정합니다(예: us-east-1).

  2. IAM 사용자 velero를 생성합니다. 

    $ aws iam create-user --user-name velero
    Copy to Clipboard Toggle word wrap

  3. EC2 EBS 스냅샷 정책을 생성합니다. 

    $ cat > velero-ec2-snapshot-policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:CreateSnapshot",
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        }
    ]
}
EOF
    Copy to Clipboard Toggle word wrap

  4. 하나 또는 모든 S3 버킷에 대한 AWS S3 액세스 정책을 생성합니다. 

    $ cat > velero-s3-policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket>/*"
    1 
    
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": [
                "arn:aws:s3:::<bucket>"
    2 
    
            ]
        }
    ]
}
EOF
    Copy to Clipboard Toggle word wrap
    1 2
    단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

    출력 예

    "Resource": [
    "arn:aws:s3:::*"
    Copy to Clipboard Toggle word wrap

  5. EC2 EBS 정책을 velero에 연결합니다. 

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-ebs \
  --policy-document file://velero-ec2-snapshot-policy.json
    Copy to Clipboard Toggle word wrap

  6. AWS S3 정책을 velero에 연결합니다. 

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-s3 \
  --policy-document file://velero-s3-policy.json
    Copy to Clipboard Toggle word wrap

  7. velero에 대한 액세스 키를 생성합니다. 

    $ aws iam create-access-key --user-name velero
{
  "AccessKey": {
        "UserName": "velero",
        "Status": "Active",
        "CreateDate": "2017-07-31T22:24:41.576Z",
        "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
    1 
    
        "AccessKeyId": <AWS_ACCESS_KEY_ID>
    2 
    
    }
}
    Copy to Clipboard Toggle word wrap

  8. credentials-velero 파일을 생성합니다. 

    $ cat << EOF > ./credentials-velero
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
EOF
    Copy to Clipboard Toggle word wrap

    Data Protection 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 AWS의 Secret 오브젝트를 생성합니다.

4.2.2.3. 백업 및 스냅샷 위치에 대한 보안 생성
링크 복사

동일한 인증 정보를 사용하는 경우 백업 및 스냅샷 위치에 대한 Secret 오브젝트를 생성합니다.

보안의 기본 이름은 cloud-credentials 입니다.

전제 조건

  • 오브젝트 스토리지 및 클라우드 스토리지에서 동일한 인증 정보를 사용해야 합니다.
  • Velero의 오브젝트 스토리지를 구성해야 합니다.

  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

    참고

    DataProtectionApplication CR(사용자 정의 리소스)에는 보안을 설치해야 합니다. spec.backupLocations.credential.name 값이 지정되지 않은 경우 기본 이름이 사용됩니다.

    백업 위치 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 보안을 생성해야 합니다.

프로세스

  • 기본 이름으로 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

Secret 은 Data Protection 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조됩니다.

4.2.2.3.1. 다른 백업 및 스냅샷 위치 인증 정보에 대한 보안 구성
링크 복사

백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 credentials-velero 파일에서 별도의 프로필을 생성합니다.

그런 다음 Secret 오브젝트를 생성하고 DataProtectionApplication CR(사용자 정의 리소스)에서 프로필을 지정합니다.

프로세스

  1. 다음 예와 같이 백업 및 스냅샷 위치에 대한 개별 프로필을 사용하여 credentials-velero 파일을 생성합니다. 

    [backupStorage]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

[volumeSnapshot]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
    Copy to Clipboard Toggle word wrap

  2. credentials-velero 파일을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    1
    Copy to Clipboard Toggle word wrap

  3. 다음 예와 같이 DataProtectionApplication CR에 프로필을 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
        config:
          region: us-east-1
          profile: "backupStorage"
        credential:
          key: cloud
          name: cloud-credentials
  snapshotLocations:
    - name: default
      velero:
        provider: aws
        config:
          region: us-west-2
          profile: "volumeSnapshot"
    Copy to Clipboard Toggle word wrap
4.2.2.4. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 구성하고 자체 서명된 CA 인증서를 활성화할 수 있습니다.

4.2.2.4.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

전제 조건

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

프로세스

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    Copy to Clipboard Toggle word wrap
    1 2 1 1
    밀리코어icpus 또는 CPU 단위로 값을 지정합니다. 기본값은 500m 또는 하나의 CPU 단위입니다.
    2
    기본값은 512Mi 입니다.
    3
    기본값은 500m 또는 하나의 CPU 단위입니다.
    4
    기본값은 256Mi 입니다.
4.2.2.4.2. 자체 서명된 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

전제 조건

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

프로세스

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.veleLocation.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base46-encoded CA 인증서 문자열을 지정합니다.
    2
    SSL/TLS 보안을 비활성화하려면 false 여야 합니다.
4.2.2.5. 데이터 보호 애플리케이션 설치
링크 복사

DataProtectionApplication API의 인스턴스를 생성하여 DPA(Data Protection Application)를 설치합니다.

전제 조건

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 인증 정보를 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 보안을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 백업 및 스냅샷 위치 자격 증명에 대한 별도의 프로필이 포함된 기본 이름 cloud-credentials 인 Secret 을 생성해야 합니다.

    참고

    설치하는 동안 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 Secret 이 없는 경우 설치에 실패합니다.

프로세스

  1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - openshift
    1 
    
        - aws
    restic:
      enable: true
    2 
    
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket_name>
    3 
    
          prefix: <prefix>
    4 
    
        config:
          region: <region>
          profile: "default"
        credential:
          key: cloud
          name: cloud-credentials
    5 
    
  snapshotLocations:
    6 
    
    - name: default
      velero:
        provider: aws
        config:
          region: <region>
    7 
    
          profile: "default"
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 클러스터에서 네임스페이스를 백업하고 복원하려면 openshift 플러그인이 필요합니다.
    2
    Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포하므로 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.
    3
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    4
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    5
    생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.
    6
    PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
    7
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard Toggle word wrap

4.2.2.5.1. DataProtectionApplication CR에서 CSI 활성화
링크 복사

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

프로세스

  • 다음 예와 같이 DataProtectionApplication CR을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

4.2.3. Microsoft Azure로 데이터 보호용 OpenShift API 설치 및 구성
링크 복사

OADP Operator를 설치하고 Velero용으로 Azure를 구성한 다음 Data Protection Application을 설치하여 Microsoft Azure와 함께 OADP(데이터 보호)용 OpenShift API를 설치합니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.2.3.1. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.8에 OADP(Data Protection) Operator의 OpenShift API를 설치합니다.

OADP Operator는 Velero 1.7 을 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
  5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.
4.2.3.2. Microsoft Azure Blob 구성
링크 복사

Microsoft Azure Blob 스토리지 컨테이너를 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

  • Azure 스토리지 계정이 있어야 합니다.
  • Azure CLI가 설치되어 있어야 합니다.
  • Azure Blob 스토리지 컨테이너는 소스 및 대상 클러스터에 액세스할 수 있어야 합니다.

  • 스냅샷 복사 방법을 사용하는 경우:

    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

프로세스

  1. AZURE_RESOURCE_GROUP 변수를 설정합니다. 

    $ AZURE_RESOURCE_GROUP=Velero_Backups
    Copy to Clipboard Toggle word wrap

  2. Azure 리소스 그룹을 생성합니다. 

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS>
    1
    Copy to Clipboard Toggle word wrap
    1
    위치를 지정합니다.

  3. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다. 

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
    Copy to Clipboard Toggle word wrap

  4. Azure 스토리지 계정을 생성합니다. 

    $ az storage account create \
  --name $AZURE_STORAGE_ACCOUNT_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --sku Standard_GRS \
  --encryption-services blob \
  --https-only true \
  --kind BlobStorage \
  --access-tier Hot
    Copy to Clipboard Toggle word wrap

  5. BLOB_CONTAINER 변수를 설정합니다. 

    $ BLOB_CONTAINER=velero
    Copy to Clipboard Toggle word wrap

  6. Azure Blob 스토리지 컨테이너를 생성합니다. 

    $ az storage container create \
  -n $BLOB_CONTAINER \
  --public-access off \
  --account-name $AZURE_STORAGE_ACCOUNT_ID
    Copy to Clipboard Toggle word wrap

  7. 스토리지 계정 액세스 키를 가져옵니다. 

    $ AZURE_STORAGE_ACCOUNT_ACCESS_KEY=`az storage account keys list \
  --account-name $AZURE_STORAGE_ACCOUNT_ID \
  --query "[?keyName == 'key1'].value" -o tsv`
    Copy to Clipboard Toggle word wrap

  8. credentials-velero 파일을 생성합니다. 

    $ cat << EOF > ./credentials-velero
AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
AZURE_TENANT_ID=${AZURE_TENANT_ID}
AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
AZURE_STORAGE_ACCOUNT_ACCESS_KEY=${AZURE_STORAGE_ACCOUNT_ACCESS_KEY}
    1 
    
AZURE_CLOUD_NAME=AzurePublicCloud
EOF
    Copy to Clipboard Toggle word wrap
    1
    필수 항목입니다. credentials-velero 파일에 서비스 주체 자격 증명만 포함된 경우 내부 이미지를 백업할 수 없습니다.

    데이터 보호 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 Azure용 Secret 오브젝트를 생성합니다.

4.2.3.3. 백업 및 스냅샷 위치에 대한 보안 생성
링크 복사

동일한 인증 정보를 사용하는 경우 백업 및 스냅샷 위치에 대한 Secret 오브젝트를 생성합니다.

보안의 기본 이름은 cloud -credentials-azure 입니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지에서 동일한 인증 정보를 사용해야 합니다.
  • Velero의 오브젝트 스토리지를 구성해야 합니다.

  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

    참고

    DataProtectionApplication CR(사용자 정의 리소스)에는 보안을 설치해야 합니다. spec.backupLocations.credential.name 값이 지정되지 않은 경우 기본 이름이 사용됩니다.

    백업 위치 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 이름으로 보안을 생성해야 합니다.

프로세스

  • 기본 이름으로 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

Secret 은 Data Protection 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조됩니다.

4.2.3.3.1. 다른 백업 및 스냅샷 위치 인증 정보에 대한 보안 구성
링크 복사

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성합니다.

  • 사용자 지정 이름을 사용하여 백업 위치 시크릿. 사용자 지정 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials-azure 가 있는 스냅샷 위치 시크릿. 이 보안 은 DataProtectionApplication CR에 지정되어 있지 않습니다.

프로세스

  1. 클라우드 공급자에 대한 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 만듭니다.

  2. 기본 이름을 사용하여 스냅샷 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

  4. 사용자 정의 이름을 사용하여 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예 와 같이 사용자 지정 이름으로 보안을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          storageAccount: <azure_storage_account_id>
          subscriptionId: <azure_subscription_id>
          storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        provider: azure
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
  snapshotLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          subscriptionId: <azure_subscription_id>
          incremental: "true"
        name: default
        provider: azure
    Copy to Clipboard Toggle word wrap
    1
    사용자 이름이 있는 백업 위치 시크릿.
4.2.3.4. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 구성하고 자체 서명된 CA 인증서를 활성화할 수 있습니다.

4.2.3.4.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

프로세스

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    Copy to Clipboard Toggle word wrap
    1
    밀리코어icpus 또는 CPU 단위로 값을 지정합니다. 기본값은 500m 또는 하나의 CPU 단위입니다.
    2
    기본값은 512Mi 입니다.
    3
    기본값은 500m 또는 하나의 CPU 단위입니다.
    4
    기본값은 256Mi 입니다.
4.2.3.4.2. 자체 서명된 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

프로세스

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.veleLocation.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base46-encoded CA 인증서 문자열을 지정합니다.
    2
    SSL/TLS 보안을 비활성화하려면 false 여야 합니다.
4.2.3.5. 데이터 보호 애플리케이션 설치
링크 복사

DataProtectionApplication API의 인스턴스를 생성하여 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 인증 정보를 사용하는 경우 기본 이름 cloud-credentials-azure 를 사용하여 보안을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 두 개의 보안 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 시크릿 을 DataProtection Application CR 에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials-azure 인 secret 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치하는 동안 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 Secret 이 없는 경우 설치에 실패합니다.

프로세스

  1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - azure
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        config:
          resourceGroup: <azure_resource_group>
    3 
    
          storageAccount: <azure_storage_account_id>
    4 
    
          subscriptionId: <azure_subscription_id>
    5 
    
          storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
        credential:
          key: cloud
          name: cloud-credentials-azure
    6 
    
        provider: azure
        default: true
        objectStorage:
          bucket: <bucket_name>
    7 
    
          prefix: <prefix>
    8 
    
  snapshotLocations:
    9 
    
    - velero:
        config:
          resourceGroup: <azure_resource_group>
          subscriptionId: <azure_subscription_id>
          incremental: "true"
        name: default
        provider: azure
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 클러스터에서 네임스페이스를 백업하고 복원하려면 openshift 플러그인이 필요합니다.
    2
    Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포하므로 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.
    3
    Azure 리소스 그룹을 지정합니다.
    4
    Azure 스토리지 계정 ID를 지정합니다.
    5
    Azure 서브스크립션 ID를 지정합니다.
    6
    이 값을 지정하지 않으면 기본 이름 cloud-credentials-azure 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.
    7
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    8
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    9
    PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard Toggle word wrap

4.2.3.5.1. DataProtectionApplication CR에서 CSI 활성화
링크 복사

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

4.2.4. Google Cloud Platform으로 데이터 보호용 OpenShift API 설치 및 구성
링크 복사

OADP Operator를 설치하고 Velero용 GCP를 구성한 다음 데이터 보호 애플리케이션을 설치하여 GCP(Google Cloud Platform)를 사용하여 OADP(데이터 보호)용 OpenShift API를 설치합니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.2.4.1. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.8에 OADP(Data Protection) Operator의 OpenShift API를 설치합니다.

OADP Operator는 Velero 1.7 을 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
  5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.
4.2.4.2. GCP(Google Cloud Platform) 구성
링크 복사

GCP(Google Cloud Platform) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

사전 요구 사항

  • 소스 및 대상 클러스터에서 GCP 스토리지 버킷에 액세스할 수 있어야 합니다.
  • gsutil이 설치되어 있어야 합니다.

  • 스냅샷 복사 방법을 사용하는 경우:

    • 소스 및 대상 클러스터는 동일한 지역에 있어야 합니다.
    • 소스 및 대상 클러스터는 동일한 스토리지 클래스를 보유해야 합니다.
    • 스토리지 클래스는 스냅샷과 호환 가능해야 합니다.

절차

  1. gsutil에 로그인합니다. 

    $ gsutil init
    Copy to Clipboard Toggle word wrap

    출력 예

    Welcome! This command will take you through the configuration of gcloud.

Your current configuration has been set to: [default]

To continue, you must login. Would you like to login (Y/n)?
    Copy to Clipboard Toggle word wrap

  2. BUCKET 변수를 설정합니다. 

    $ BUCKET=<bucket>
    1
    Copy to Clipboard Toggle word wrap
    1
    버킷 이름을 지정합니다.

  3. 스토리지 버킷을 생성합니다. 

    $ gsutil mb gs://$BUCKET/
    Copy to Clipboard Toggle word wrap

  4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다. 

    $ PROJECT_ID=`gcloud config get-value project`
    Copy to Clipboard Toggle word wrap

  5. Velero IAM 서비스 계정을 생성합니다. 

    $ gcloud iam service-accounts create velero \
    --display-name "Velero Storage"
    Copy to Clipboard Toggle word wrap

  6. SERVICE_ACCOUNT_EMAIL 변수를 생성합니다. 

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
  --filter="displayName:Velero Storage" \
  --format 'value(email)'`
    Copy to Clipboard Toggle word wrap

  7. ROLE_PERMISSIONS 변수를 생성합니다. 

    $ ROLE_PERMISSIONS=(
    compute.disks.get
    compute.disks.create
    compute.disks.createSnapshot
    compute.snapshots.get
    compute.snapshots.create
    compute.snapshots.useReadOnly
    compute.snapshots.delete
    compute.zones.get
)
    Copy to Clipboard Toggle word wrap

  8. velero.server 사용자 정의 역할을 생성합니다. 

    $ gcloud iam roles create velero.server \
    --project $PROJECT_ID \
    --title "Velero Server" \
    --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
    Copy to Clipboard Toggle word wrap

  9. 프로젝트에 IAM 정책 바인딩을 추가합니다. 

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
    --role projects/$PROJECT_ID/roles/velero.server
    Copy to Clipboard Toggle word wrap

  10. IAM 서비스 계정을 업데이트합니다. 

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
    Copy to Clipboard Toggle word wrap

  11. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다. 

    $ gcloud iam service-accounts keys create credentials-velero \
  --iam-account $SERVICE_ACCOUNT_EMAIL
    Copy to Clipboard Toggle word wrap

    Data Protection 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 GCP용 Secret 오브젝트를 생성합니다.

4.2.4.3. 백업 및 스냅샷 위치에 대한 보안 생성
링크 복사

동일한 인증 정보를 사용하는 경우 백업 및 스냅샷 위치에 대한 Secret 오브젝트를 생성합니다.

Secret 의 기본 이름은 cloud-credentials-gcp 입니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지에서 동일한 인증 정보를 사용해야 합니다.
  • Velero의 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

Secret 은 Data Protection 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조됩니다.

4.2.4.3.1. 다른 백업 및 스냅샷 위치 인증 정보에 대한 보안 구성
링크 복사

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성합니다.

  • 사용자 지정 이름을 사용하여 백업 위치 시크릿. 사용자 지정 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials-gcp 가 있는 스냅샷 위치 보안. 이 보안 은 DataProtectionApplication CR에 지정되어 있지 않습니다.

절차

  1. 클라우드 공급자에 대한 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 만듭니다.

  2. 기본 이름을 사용하여 스냅샷 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

  4. 사용자 정의 이름을 사용하여 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예 와 같이 사용자 지정 이름으로 보안을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
...
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
  snapshotLocations:
    - velero:
        provider: gcp
        default: true
        config:
          project: <project>
          snapshotLocation: us-west1
    Copy to Clipboard Toggle word wrap
    1
    사용자 이름이 있는 백업 위치 시크릿.
4.2.4.4. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 구성하고 자체 서명된 CA 인증서를 활성화할 수 있습니다.

4.2.4.4.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    Copy to Clipboard Toggle word wrap
    1
    밀리코어icpus 또는 CPU 단위로 값을 지정합니다. 기본값은 500m 또는 하나의 CPU 단위입니다.
    2
    기본값은 512Mi 입니다.
    3
    기본값은 500m 또는 하나의 CPU 단위입니다.
    4
    기본값은 256Mi 입니다.
4.2.4.4.2. 자체 서명된 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.veleLocation.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base46-encoded CA 인증서 문자열을 지정합니다.
    2
    SSL/TLS 보안을 비활성화하려면 false 여야 합니다.
4.2.4.5. 데이터 보호 애플리케이션 설치
링크 복사

DataProtectionApplication API의 인스턴스를 생성하여 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 인증 정보를 사용하는 경우 기본 이름 cloud-credentials-gcp 를 사용하여 보안을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 두 개의 보안 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 시크릿 을 DataProtection Application CR 에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials-gcp 가 있는 시크릿 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치하는 동안 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 Secret 이 없는 경우 설치에 실패합니다.

절차

  1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - gcp
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: cloud-credentials-gcp
    3 
    
        objectStorage:
          bucket: <bucket_name>
    4 
    
          prefix: <prefix>
    5 
    
  snapshotLocations:
    6 
    
    - velero:
        provider: gcp
        default: true
        config:
          project: <project>
          snapshotLocation: us-west1
    7
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 클러스터에서 네임스페이스를 백업하고 복원하려면 openshift 플러그인이 필요합니다.
    2
    Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포하므로 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.
    3
    이 값을 지정하지 않으면 기본 이름 cloud-credentials-gcp 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.
    4
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    5
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
    6
    PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.
    7
    스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard Toggle word wrap

4.2.4.5.1. DataProtectionApplication CR에서 CSI 활성화
링크 복사

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

4.2.5. Multicloud Object Gateway로 데이터 보호용 OpenShift API 설치 및 구성
링크 복사

OADP Operator를 설치하고 Secret 오브젝트를 생성한 다음 데이터 보호 애플리케이션을 설치하여 MCG(Multicloud Object Gateway)를 사용하여 OADP(Data Protection)용 OpenShift API를 설치합니다.

MCG는 OpenShift Container Storage (OCS)의 구성 요소입니다. MCG를 DataProtectionApplication CR(사용자 정의 리소스)에서 백업 위치로 구성합니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

클라우드 공급자에 기본 스냅샷 API가 있는 경우 스냅샷 위치를 구성합니다. 클라우드 공급자가 스냅샷을 지원하지 않거나 스토리지가 NFS인 경우 Restic을 사용하여 백업을 생성할 수 있습니다.

Restic 또는 CSI(Container Storage Interface) 스냅샷에 대한 DataProtectionApplication CR에서 스냅샷 위치를 지정할 필요가 없습니다.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.2.5.1. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.8에 OADP(Data Protection) Operator의 OpenShift API를 설치합니다.

OADP Operator는 Velero 1.7 을 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
  5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.
4.2.5.2. MCG(Multi-Cloud Object Gateway) 구성
링크 복사

OpenShift Container Storage Operator를 설치하고 MCG(Multi-Cloud Object Gateway) 스토리지 버킷을 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다.

4.2.5.2.1. OpenShift Container Storage Operator 설치
링크 복사

OperatorHub에서 OpenShift Container Storage Operator를 설치할 수 있습니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
  3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
  4. 업데이트 채널, 설치 모드 및 승인 전략을 선택합니다.

  5. 설치를 클릭합니다.

    설치된 운영자 페이지에서 OpenShift Container Storage Operator가 openshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

4.2.5.2.2. Multi-Cloud Object Gateway 스토리지 버킷 작성
링크 복사

MCG(Multi-Cloud Object Gateway) 스토리지 버킷의 사용자 정의 리소스(CR)를 생성할 수 있습니다.

절차

  1. OpenShift Container Platform 클러스터에 로그인합니다. 

    $ oc login -u <username>
    Copy to Clipboard Toggle word wrap

  2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다. 

    apiVersion: noobaa.io/v1alpha1
kind: NooBaa
metadata:
  name: <noobaa>
  namespace: openshift-storage
spec:
 dbResources:
   requests:
     cpu: 0.5
    1 
    
     memory: 1Gi
 coreResources:
   requests:
     cpu: 0.5
    2 
    
     memory: 1Gi
    Copy to Clipboard Toggle word wrap
    1 2
    매우 작은 클러스터의 경우 값을 0.1로 변경할 수 있습니다.

  3. NooBaa 오브젝트를 생성합니다. 

    $ oc create -f noobaa.yml
    Copy to Clipboard Toggle word wrap

  4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다. 

    apiVersion: noobaa.io/v1alpha1
kind: BackingStore
metadata:
  finalizers:
  - noobaa.io/finalizer
  labels:
    app: noobaa
  name: <mcg_backing_store>
  namespace: openshift-storage
spec:
  pvPool:
    numVolumes: 3
    1 
    
    resources:
      requests:
        storage: <volume_size>
    2 
    
    storageClass: <storage_class>
    3 
    
  type: pv-pool
    Copy to Clipboard Toggle word wrap
    1
    영구 볼륨 풀에서 볼륨 수를 지정합니다.
    2
    볼륨의 크기를 지정합니다. (예: 50Gi)
    3
    스토리지 클래스를 지정합니다. (예: gp2)

  5. BackingStore 오브젝트를 생성합니다. 

    $ oc create -f bs.yml
    Copy to Clipboard Toggle word wrap

  6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다. 

    apiVersion: noobaa.io/v1alpha1
kind: BucketClass
metadata:
  labels:
    app: noobaa
  name: <mcg_bucket_class>
  namespace: openshift-storage
spec:
  placementPolicy:
    tiers:
    - backingStores:
      - <mcg_backing_store>
      placement: Spread
    Copy to Clipboard Toggle word wrap

  7. BucketClass 오브젝트를 생성합니다. 

    $ oc create -f bc.yml
    Copy to Clipboard Toggle word wrap

  8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다. 

    apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: <bucket>
  namespace: openshift-storage
spec:
  bucketName: <bucket>
    1 
    
  storageClassName: <storage_class>
  additionalConfig:
    bucketclass: <mcg_bucket_class>
    Copy to Clipboard Toggle word wrap
    1
    MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.

  9. ObjectBucketClaim 오브젝트를 생성합니다. 

    $ oc create -f obc.yml
    Copy to Clipboard Toggle word wrap

  10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다. 

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'
    Copy to Clipboard Toggle word wrap

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

  11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점: 

      $ oc get route -n openshift-storage s3
      Copy to Clipboard Toggle word wrap

    • S3 공급자 액세스 키: 

      $ oc get secret -n openshift-storage migstorage \
  -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
      Copy to Clipboard Toggle word wrap

    • S3 공급자 보안 액세스 키: 

      $ oc get secret -n openshift-storage migstorage \
  -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode
      Copy to Clipboard Toggle word wrap
4.2.5.3. 백업 및 스냅샷 위치에 대한 보안 생성
링크 복사

동일한 인증 정보를 사용하는 경우 백업 및 스냅샷 위치에 대한 Secret 오브젝트를 생성합니다.

보안의 기본 이름은 cloud-credentials 입니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지에서 동일한 인증 정보를 사용해야 합니다.
  • Velero의 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

Secret 은 Data Protection 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조됩니다.

4.2.5.3.1. 다른 백업 및 스냅샷 위치 인증 정보에 대한 보안 구성
링크 복사

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성합니다.

  • 사용자 지정 이름을 사용하여 백업 위치 시크릿. 사용자 지정 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials 가 있는 스냅샷 위치 시크릿. 이 보안 은 DataProtectionApplication CR에 지정되어 있지 않습니다.

절차

  1. 클라우드 공급자에 대한 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 만듭니다.

  2. 기본 이름을 사용하여 스냅샷 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

  4. 사용자 정의 이름을 사용하여 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예 와 같이 사용자 지정 이름으로 보안을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    restic:
      enable: true
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name:  <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    Copy to Clipboard Toggle word wrap
    1
    사용자 이름이 있는 백업 위치 시크릿.
4.2.5.4. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 구성하고 자체 서명된 CA 인증서를 활성화할 수 있습니다.

4.2.5.4.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    Copy to Clipboard Toggle word wrap
    1
    밀리코어icpus 또는 CPU 단위로 값을 지정합니다. 기본값은 500m 또는 하나의 CPU 단위입니다.
    2
    기본값은 512Mi 입니다.
    3
    기본값은 500m 또는 하나의 CPU 단위입니다.
    4
    기본값은 256Mi 입니다.
4.2.5.4.2. 자체 서명된 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.veleLocation.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base46-encoded CA 인증서 문자열을 지정합니다.
    2
    SSL/TLS 보안을 비활성화하려면 false 여야 합니다.
4.2.5.5. 데이터 보호 애플리케이션 설치
링크 복사

DataProtectionApplication API의 인스턴스를 생성하여 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 인증 정보를 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 보안을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 두 개의 보안 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 시크릿 을 DataProtection Application CR 에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials 인 secret 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치하는 동안 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 Secret 이 없는 경우 설치에 실패합니다.

절차

  1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - aws
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: <url>
    3 
    
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name: cloud-credentials
    4 
    
        objectStorage:
          bucket: <bucket_name>
    5 
    
          prefix: <prefix>
    6
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Container Platform 클러스터에서 네임스페이스를 백업하고 복원하려면 openshift 플러그인이 필요합니다.
    2
    Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포하므로 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.
    3
    S3 끝점의 URL을 지정합니다.
    4
    이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.
    5
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    6
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard Toggle word wrap

4.2.5.5.1. DataProtectionApplication CR에서 CSI 활성화
링크 복사

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

OADP Operator를 설치하고 백업 위치와 스냅샷 위치를 구성하여 OCS(OpenShift Container Storage)를 사용하여 OADP(Data Protection)용 OpenShift API를 설치합니다. 그런 다음 Data Protection 애플리케이션을 설치합니다.

Multicloud Object Gateway 또는 모든 S3 호환 오브젝트 스토리지를 DataProtectionApplication CR(사용자 정의 리소스)의 백업 위치로 구성할 수 있습니다.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

클라우드 공급자에 기본 스냅샷 API가 있는 경우 DataProtectionApplication CR의 스냅샷 위치로 클라우드 스토리지를 구성할 수 있습니다. Restic 또는 CSI(Container Storage Interface) 스냅샷의 스냅샷 위치를 지정할 필요가 없습니다.

제한된 네트워크 환경에 OADP Operator를 설치하려면 먼저 기본 OperatorHub 소스를 비활성화하고 Operator 카탈로그를 미러링해야 합니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

4.2.6.1. OADP Operator 설치
링크 복사

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift Container Platform 4.8에 OADP(Data Protection) Operator의 OpenShift API를 설치합니다.

OADP Operator는 Velero 1.7 을 설치합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인해야 합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
  3. OADP Operator 를 선택하고 설치를 클릭합니다.
  4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
  5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.
참고

OADP Operator를 설치한 후 클라우드 공급자가 네이티브 스냅샷 API를 지원하는 경우 오브젝트 스토리지를 백업 위치 및 클라우드 스토리지로 구성합니다.

클라우드 공급자가 스냅샷을 지원하지 않거나 스토리지가 NFS인 경우 Restic. Restic에는 스냅샷 위치가 필요하지 않습니다.

4.2.6.2. 백업 및 스냅샷 위치에 대한 보안 생성
링크 복사

동일한 인증 정보를 사용하는 경우 백업 및 스냅샷 위치에 대한 Secret 오브젝트를 생성합니다.

백업 스토리지 공급자의 기본 플러그인을 지정하지 않는 한 Secret 의 기본 이름은 cloud-credentials 입니다.

사전 요구 사항

  • 오브젝트 스토리지 및 클라우드 스토리지에서 동일한 인증 정보를 사용해야 합니다.
  • Velero의 오브젝트 스토리지를 구성해야 합니다.
  • 적절한 형식으로 오브젝트 스토리지에 대한 credentials-velero 파일을 생성해야 합니다.

절차

  • 기본 이름으로 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

Secret 은 Data Protection 애플리케이션을 설치할 때 DataProtectionApplication CR의 spec.backupLocations.credential 블록에서 참조됩니다.

4.2.6.2.1. 다른 백업 및 스냅샷 위치 인증 정보에 대한 보안 구성
링크 복사

백업 및 스냅샷 위치가 다른 인증 정보를 사용하는 경우 두 개의 Secret 오브젝트를 생성합니다.

  • 사용자 지정 이름을 사용하여 백업 위치 시크릿. 사용자 지정 이름은 DataProtectionApplication CR(사용자 정의 리소스)의 spec.backupLocations 블록에 지정됩니다.
  • 기본 이름 cloud-credentials 가 있는 스냅샷 위치 시크릿. 이 보안 은 DataProtectionApplication CR에 지정되어 있지 않습니다.

절차

  1. 클라우드 공급자에 대한 적절한 형식으로 스냅샷 위치에 대한 credentials-velero 파일을 만듭니다.

  2. 기본 이름을 사용하여 스냅샷 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

  4. 사용자 정의 이름을 사용하여 백업 위치에 대한 보안을 생성합니다. 

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
    Copy to Clipboard Toggle word wrap

  5. 다음 예 와 같이 사용자 지정 이름으로 보안을 DataProtectionApplication CR에 추가합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - csi
        - openshift
    featureFlags:
    - EnableCSI
    restic:
      enable: true
  backupLocations:
    - velero:
        provider: gcp
        default: true
        credential:
          key: cloud
          name: <custom_secret>
    1 
    
        objectStorage:
          bucket: <bucket_name>
          prefix: <prefix>
    Copy to Clipboard Toggle word wrap
    1
    사용자 이름이 있는 백업 위치 시크릿.
4.2.6.3. 데이터 보호 애플리케이션 구성
링크 복사

Velero 리소스 할당을 구성하고 자체 서명된 CA 인증서를 활성화할 수 있습니다.

4.2.6.3.1. Velero CPU 및 메모리 리소스 할당 설정
링크 복사

DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 Velero Pod의 CPU 및 메모리 리소스 할당을 설정합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR 매니페스트의 spec.configuration.velero.podConfig.ResourceAllocations 블록의 값을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  configuration:
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "1"
    1 
    
            memory: 512Mi
    2 
    
          requests:
            cpu: 500m
    3 
    
            memory: 256Mi
    4
    Copy to Clipboard Toggle word wrap
    1
    밀리코어icpus 또는 CPU 단위로 값을 지정합니다. 기본값은 500m 또는 하나의 CPU 단위입니다.
    2
    기본값은 512Mi 입니다.
    3
    기본값은 500m 또는 하나의 CPU 단위입니다.
    4
    기본값은 256Mi 입니다.
4.2.6.3.2. 자체 서명된 CA 인증서 활성화
링크 복사

알 수 없는 기관 오류로 서명된 인증서를 방지하려면 DataProtectionApplication CR(사용자 정의 리소스) 매니페스트를 편집하여 오브젝트 스토리지에 대해 자체 서명된 CA 인증서를 활성화해야 합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API가 설치되어 있어야 합니다.

절차

  • DataProtectionApplication CR 매니페스트의 spec.backupLocations.veleLocation.caCert 매개변수 및 spec.backupLocations.velero.config 매개변수를 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
spec:
...
  backupLocations:
    - name: default
      velero:
        provider: aws
        default: true
        objectStorage:
          bucket: <bucket>
          prefix: <prefix>
          caCert: <base64_encoded_cert_string>
    1 
    
        config:
          insecureSkipTLSVerify: "false"
    2 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Base46-encoded CA 인증서 문자열을 지정합니다.
    2
    SSL/TLS 보안을 비활성화하려면 false 여야 합니다.
4.2.6.4. 데이터 보호 애플리케이션 설치
링크 복사

DataProtectionApplication API의 인스턴스를 생성하여 DPA(Data Protection Application)를 설치합니다.

사전 요구 사항

  • OADP Operator를 설치해야 합니다.
  • 오브젝트 스토리지를 백업 위치로 구성해야 합니다.
  • 스냅샷을 사용하여 PV를 백업하는 경우 클라우드 공급자는 기본 스냅샷 API 또는 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
  • 백업 및 스냅샷 위치가 동일한 인증 정보를 사용하는 경우 기본 이름 cloud-credentials 를 사용하여 보안을 생성해야 합니다.

  • 백업 및 스냅샷 위치가 다른 자격 증명을 사용하는 경우 두 개의 보안 시크릿 을 생성해야 합니다.

    • 백업 위치에 대한 사용자 지정 이름이 있는 시크릿 입니다. 이 시크릿 을 DataProtection Application CR 에 추가합니다.

    • 스냅샷 위치에 대한 기본 이름 cloud-credentials 인 secret 입니다. 이 보안 은 DataProtectionApplication CR에서 참조되지 않습니다.

      참고

      설치하는 동안 백업 또는 스냅샷 위치를 지정하지 않으려면 빈 credentials-velero 파일을 사용하여 기본 보안을 생성할 수 있습니다. 기본 Secret 이 없는 경우 설치에 실패합니다.

절차

  1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
  2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

  3. YAML 보기를 클릭하고 DataProtectionApplication 매니페스트의 매개변수를 업데이트합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: <dpa_sample>
  namespace: openshift-adp
spec:
  configuration:
    velero:
      defaultPlugins:
        - gcp <.>
        - csi <.>
        - openshift
    1 
    
    restic:
      enable: true
    2 
    
  backupLocations:
    - velero:
        provider: gcp
    3 
    
        default: true
        credential:
          key: cloud
          name: <default_secret>
    4 
    
        objectStorage:
          bucket: <bucket_name>
    5 
    
          prefix: <prefix>
    6
    Copy to Clipboard Toggle word wrap
    1
    필요한 경우 백업 공급자의 기본 플러그인을 지정합니다(예: gcp ).
    2
    CSI 스냅샷을 사용하여 PV를 백업하는 경우 csi 기본 플러그인을 지정합니다. csi 플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다.
    3
    OpenShift Container Platform 클러스터에서 네임스페이스를 백업하고 복원하려면 openshift 플러그인이 필요합니다.
    4
    Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포하므로 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.
    5
    백업 공급자를 지정합니다.
    6
    백업 공급자에 기본 플러그인을 사용하는 경우 Secret 에 대해 올바른 기본 이름을 지정해야 합니다(예: cloud-credentials-gcp ). 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다. Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
  4. 생성을 클릭합니다.

  5. OADP 리소스를 확인하여 설치를 확인합니다. 

    $ oc get all -n openshift-adp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                     READY   STATUS    RESTARTS   AGE
pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
pod/restic-9cq4q                                         1/1     Running   0          94s
pod/restic-m4lts                                         1/1     Running   0          94s
pod/restic-pv4kr                                         1/1     Running   0          95s
pod/velero-588db7f655-n842v                              1/1     Running   0          95s

NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   3         3         3       3            3           <none>          96s

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
deployment.apps/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
deployment.apps/velero                              1/1     1            1           96s

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
replicaset.apps/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
replicaset.apps/velero-588db7f655                              1         1         1       96s
    Copy to Clipboard Toggle word wrap

4.2.6.4.1. DataProtectionApplication CR에서 CSI 활성화
링크 복사

CSI 스냅샷을 사용하여 영구 볼륨을 백업하기 위해 DataProtectionApplication CR(사용자 정의 리소스)에서 CSI(Container Storage Interface)를 활성화합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.

절차

  • 다음 예와 같이 DataProtectionApplication CR을 편집합니다. 

    apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  configuration:
    velero:
      defaultPlugins:
      - openshift
      - csi
    1 
    
    featureFlags:
    - EnableCSI
    2
    Copy to Clipboard Toggle word wrap
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

4.2.7. 데이터 보호를 위한 OpenShift API 설치 제거
링크 복사

OADP Operator를 삭제하여 OADP(Data Protection)용 OpenShift API를 설치 제거합니다. 자세한 내용은 클러스터에서 Operator 삭제를 참조하십시오.

4.3. 백업 및 복원
링크 복사

4.3.1. 애플리케이션 백업
링크 복사

Backup CR(사용자 정의 리소스)을 생성하여 애플리케이션을 백업합니다.

백업 CR은 S3 오브젝트 스토리지에서 Kubernetes 리소스 및 내부 이미지의 백업 파일을 생성하고, 클라우드 공급자가 기본 스냅샷 API 또는 CSI( Container Storage Interface)를 사용하여 OpenShift Container Storage 4와 같은 스냅샷을 생성하는 경우 S3 오브젝트 스토리지 및 PV(영구 볼륨) 의 스냅샷을 생성합니다. 자세한 내용은 CSI 볼륨 스냅샷을 참조하십시오.

중요

S3 스토리지의 CloudStorage API는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

클라우드 공급자에 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원하는 경우 Backup CR은 스냅샷을 생성하여 영구 볼륨을 백업합니다. 자세한 내용은 OpenShift Container Platform 설명서 의 CSI 볼륨 스냅샷 개요 를 참조하십시오.

클라우드 공급자가 스냅샷을 지원하지 않거나 애플리케이션이 NFS 데이터 볼륨에 있는 경우 Restic 을 사용하여 백업을 생성할 수 있습니다.

백업 작업 전후에 명령을 실행하도록 백업 후크 를 생성할 수 있습니다.

Backup CR 대신 Schedule CR 을 생성하여 백업을 예약할 수 있습니다.

4.3.1.1. 백업 CR 생성
링크 복사

Backup CR(사용자 정의 리소스)을 생성하여 Kubernetes 이미지, 내부 이미지 및 PV(영구 볼륨)를 백업합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.

  • 백업 위치 사전 요구 사항:

    • Velero에 대해 S3 오브젝트 스토리지가 구성되어 있어야 합니다.
    • DataProtectionApplication CR에 구성된 백업 위치가 있어야 합니다.

  • 스냅샷 위치 사전 요구 사항:

    • 클라우드 공급자에 기본 스냅샷 API가 있거나 CSI(Container Storage Interface) 스냅샷을 지원해야 합니다.
    • CSI 스냅샷의 경우 CSI 드라이버를 등록하려면 VolumeSnapshotClass CR을 생성해야 합니다.
    • DataProtectionApplication CR에 볼륨 위치가 구성되어 있어야 합니다.

절차

  1. backupStorageLocations CR을 검색합니다. 

    $ oc get backupStorageLocations
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m
    Copy to Clipboard Toggle word wrap

  2. 다음 예와 같이 Backup CR을 생성합니다. 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  hooks: {}
  includedNamespaces:
  - <namespace>
    1 
    
  storageLocation: <velero-sample-1>
    2 
    
  ttl: 720h0m0s
    Copy to Clipboard Toggle word wrap
    1
    백업할 네임스페이스 배열을 지정합니다.
    2
    backupStorageLocations CR의 이름을 지정합니다.

  3. Backup CR의 상태가 Completed 인지 확인합니다. 

    $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap
4.3.1.2. CSI 스냅샷을 사용하여 영구 볼륨 백업
링크 복사

Backup CR을 생성하기 전에 CSI 드라이버를 등록할 VolumeSnapshotClass CR(사용자 정의 리소스)을 생성하여 CSI(Container Storage Interface) 스냅샷을 사용하여 영구 볼륨을 백업합니다.

사전 요구 사항

  • 클라우드 공급자는 CSI 스냅샷을 지원해야 합니다.
  • DataProtectionApplication CR에서 CSI를 활성화해야 합니다.

절차

  • 다음 예와 같이 VolumeSnapshotClass CR을 생성합니다.

    Ceph RBD

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
deletionPolicy: Retain
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
    snapshotter: openshift-storage.rbd.csi.ceph.com
driver: openshift-storage.rbd.csi.ceph.com
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
    Copy to Clipboard Toggle word wrap

    Ceph FS

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: openshift-storage.cephfs.csi.ceph.com
deletionPolicy: Retain
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
    Copy to Clipboard Toggle word wrap

    기타 클라우드 공급자

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: <volume_snapshot_class_name>
  labels:
    velero.io/csi-volumesnapshot-class: "true"
driver: <csi_driver>
deletionPolicy: Retain
    Copy to Clipboard Toggle word wrap

이제 Backup CR을 생성할 수 있습니다.

4.3.1.3. Restic으로 애플리케이션 백업
링크 복사

Backup CR(사용자 정의 리소스)을 편집하여 Restic을 사용하여 Kubernetes 리소스, 내부 이미지 및 영구 볼륨을 백업합니다.

DataProtectionApplication CR에서 스냅샷 위치를 지정할 필요가 없습니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR에서 spec.configuration.restic.enable 을 false 로 설정하여 기본 Restic 설치를 비활성화해서는 안 됩니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.

절차

  • 다음 예와 같이 Backup CR을 편집합니다. 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  defaultVolumesToRestic: true
    1 
    
...
    Copy to Clipboard Toggle word wrap
    1
    defaultVolumesToRestic: true 를 spec 블록에 추가합니다.
4.3.1.4. 백업 후크 생성
링크 복사

Backup CR(사용자 정의 리소스)을 편집하여 Pod의 컨테이너에서 명령을 실행하는 백업 후크를 생성합니다.

Pod를 백업하기 전에 사전 후크가 실행됩니다. 사후 후크는 백업 후에 실행됩니다.

절차

  • 다음 예와 같이 Backup CR의 spec.hooks 블록에 후크를 추가합니다. 

    apiVersion: velero.io/v1
kind: Backup
metadata:
  name: <backup>
  namespace: openshift-adp
spec:
  hooks:
    resources:
      - name: <hook_name>
        includedNamespaces:
        - <namespace>
    1 
    
        excludedNamespaces:
        - <namespace>
        includedResources:
        - pods
    2 
    
        excludedResources: []
        labelSelector:
    3 
    
          matchLabels:
            app: velero
            component: server
        pre:
    4 
    
          - exec:
              container: <container>
    5 
    
              command:
              - /bin/uname
    6 
    
              - -a
              onError: Fail
    7 
    
              timeout: 30s
    8 
    
        post:
    9 
    
...
    Copy to Clipboard Toggle word wrap
    1
    후크가 적용되는 네임스페이스의 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    현재 Pod는 지원되는 유일한 리소스입니다.
    3
    선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
    4
    백업 전에 실행할 후크 배열입니다.
    5
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    6
    후크가 실행하는 명령의 배열입니다.
    7
    오류 처리에 허용되는 값은 Fail 및 Continue 입니다. 기본값은 Fail 입니다.
    8
    선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    9
    이 블록은 사전 백업 후크와 동일한 매개 변수를 사용하여 백업 후에 실행할 후크 배열을 정의합니다.
4.3.1.5. 백업 예약
링크 복사

Backup CR 대신 Schedule CR(사용자 정의 리소스)을 생성하여 백업을 예약합니다.

주의

다른 백업이 생성되기 전에 백업이 완료될 수 있도록 백업 일정에 충분한 시간을 남겨 둡니다.

예를 들어 네임스페이스의 백업이 일반적으로 10분 정도 걸리는 경우 15분마다 백업을 더 자주 예약하지 마십시오.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.

절차

  1. backupStorageLocations CR을 검색합니다. 

    $ oc get backupStorageLocations
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m
    Copy to Clipboard Toggle word wrap

  2. 다음 예와 같이 Schedule CR을 생성합니다. 

    $ cat << EOF | oc apply -f -
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: <schedule>
  namespace: openshift-adp
spec:
  schedule: 0 7 * * *
    1 
    
  template:
    hooks: {}
    includedNamespaces:
    - <namespace>
    2 
    
    storageLocation: <velero-sample-1>
    3 
    
    defaultVolumesToRestic: true
    4 
    
    ttl: 720h0m0s
EOF
    Copy to Clipboard Toggle word wrap
    1
    백업을 예약하는 Cron 표현식(예: 0 7 * * ) 매일 7:00에 백업을 수행합니다.
    2
    백업할 네임스페이스의 배열입니다.
    3
    backupStorageLocations CR의 이름입니다.
    4
    선택 사항: Restic을 사용하여 볼륨을 백업하는 경우 defaultVolumesToRestic: true 키-값 쌍을 추가합니다.

  3. 예약된 백업이 실행된 후 Schedule CR의 상태가 Completed 인지 확인합니다. 

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

4.3.2. 애플리케이션 복원
링크 복사

Restore CR(사용자 정의 리소스) 을 생성하여 애플리케이션 백업을 복원합니다.

애플리케이션 컨테이너가 시작되기 전에 또는 애플리케이션 컨테이너 자체에서 init 컨테이너에서 명령을 실행하는 복원 후크 를 생성할 수 있습니다.

4.3.2.1. Restore CR 생성
링크 복사

Restore CR을 생성하여 Backup CR(사용자 정의 리소스)을 복원합니다.

사전 요구 사항

  • OADP(Data Protection) Operator를 위한 OpenShift API를 설치해야 합니다.
  • DataProtectionApplication CR은 Ready 상태여야 합니다.
  • Velero Backup CR이 있어야 합니다.
  • 영구 볼륨(PV) 용량이 백업 시 요청된 크기와 일치하도록 요청된 크기를 조정합니다.

절차

  1. 다음 예와 같이 Restore CR을 생성합니다. 

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore>
  namespace: openshift-adp
spec:
  backupName: <backup>
    1 
    
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  restorePVs: true
    Copy to Clipboard Toggle word wrap
    1
    Backup CR의 이름입니다.

  2. Restore CR의 상태가 Completed 인지 확인합니다. 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

  3. 백업 리소스가 복원되었는지 확인합니다. 

    $ oc get all -n <namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    백업한 네임스페이스입니다.
4.3.2.2. 복원 후크 생성
링크 복사

Restore CR(사용자 정의 리소스)을 편집하여 애플리케이션을 복원하는 동안 Pod의 컨테이너에서 명령을 실행하는 복원 후크를 생성합니다.

두 가지 유형의 복원 후크를 생성할 수 있습니다.

  • init 후크는 애플리케이션 컨테이너가 시작되기 전에 설정 작업을 수행하기 위해 Pod에 init 컨테이너를 추가합니다.

    Restic 백업을 복원하는 경우 복원 후크 init 컨테이너 전에 restic-wait init 컨테이너가 추가됩니다.

  • exec 후크는 복원된 Pod의 컨테이너에서 명령 또는 스크립트를 실행합니다.

절차

  • 다음 예와 같이 Restore CR의 spec.hooks 블록에 후크를 추가합니다. 

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore>
  namespace: openshift-adp
spec:
  hooks:
    resources:
      - name: <hook_name>
        includedNamespaces:
        - <namespace>
    1 
    
        excludedNamespaces:
        - <namespace>
        includedResources:
        - pods
    2 
    
        excludedResources: []
        labelSelector:
    3 
    
          matchLabels:
            app: velero
            component: server
        postHooks:
        - init:
            initContainers:
            - name: restore-hook-init
              image: alpine:latest
              volumeMounts:
              - mountPath: /restores/pvc1-vm
                name: pvc1-vm
              command:
              - /bin/ash
              - -c
        - exec:
            container: <container>
    4 
    
            command:
            - /bin/bash
    5 
    
            - -c
            - "psql < /backup/backup.sql"
            waitTimeout: 5m
    6 
    
            execTimeout: 1m
    7 
    
            onError: Continue
    8
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: 후크가 적용되는 네임스페이스의 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
    2
    현재 Pod는 지원되는 유일한 리소스입니다.
    3
    선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
    4
    선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
    5
    후크가 실행하는 명령의 배열입니다.
    6
    선택 사항: waitTimeout 을 지정하지 않으면 복원은 무기한 대기합니다. 컨테이너가 시작될 때까지 그리고 컨테이너의 이전 후크가 완료될 때까지 대기하는 시간을 지정할 수 있습니다. 대기 시간 제한은 컨테이너가 복원될 때 시작되며 컨테이너가 이미지를 가져와서 볼륨을 마운트하는 데 시간이 필요할 수 있습니다.
    7
    선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은 30s 입니다.
    8
    오류 처리에 허용되는 값은 Fail 및 Continue 입니다.
    • 계속하십시오. 명령 오류만 기록됩니다.
    • 실패: 더 이상 Pod의 컨테이너에서 실행되는 복원 후크가 없습니다. Restore CR의 상태는 PartiallyFailed 가 됩니다.

4.4. 문제 해결
링크 복사

OpenShift CLI 툴 또는 Velero CLI 툴을 사용하여 Velero CR(사용자 정의 리소스)을 디버깅할 수 있습니다. Velero CLI 툴은 보다 자세한 로그 및 정보를 제공합니다.

설치 문제,백업 및 복원 CR 문제 및 Restic 문제를 확인할 수 있습니다.

must-gather 툴을 사용하여 로그, CR 정보 및 Prometheus 지표 데이터를 수집할 수 있습니다.

다음과 같이 Velero CLI 툴을 가져올 수 있습니다.

  • Velero CLI 툴 다운로드
  • 클러스터의 Velero 배포에서 Velero 바이너리에 액세스

4.4.1. Velero CLI 툴 다운로드
링크 복사

Velero 문서 페이지에 있는 지침에 따라 Velero CLI 툴을 다운로드하고 설치할 수 있습니다.

페이지에는 다음에 대한 지침이 포함되어 있습니다.

  • macOS Homebrew 사용
  • GitHub
  • Chocolatey를 사용하는 Windows

사전 요구 사항

  • DNS 및 컨테이너 네트워킹이 활성화된 Kubernetes 클러스터 v1.16 이상에 액세스할 수 있습니다.
  • kubectl 을 로컬로 설치했습니다.

절차

  1. 브라우저를 열고 Verleo 웹 사이트에서 " CLI 설치 "로 이동합니다.
  2. macOS, GitHub 또는 Windows에 적절한 절차를 따르십시오.

  3. 다음 표에 따라 OADP 버전에 적합한 Velero 버전을 다운로드합니다.

    Expand
    표 4.2. OADP-Velero 버전 관계
    OADP 버전Velero 버전

    0.2.6

    1.6.0

    0.5.5

    1.7.1

    1.0.0

    1.7.1

    1.0.1

    1.7.1

    1.0.2

    1.7.1

    1.0.3

    1.7.1

4.4.2. 클러스터의 Velero 배포에서 Velero 바이너리에 액세스
링크 복사

쉘 명령을 사용하여 클러스터의 Velero 배포의 Velero 바이너리에 액세스할 수 있습니다.

사전 요구 사항

  • DataProtectionApplication 사용자 정의 리소스에는 Reconcile 완료 의 상태가 있습니다.

절차

  • 다음 명령을 입력하여 필요한 별칭을 설정합니다. 

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    Copy to Clipboard Toggle word wrap

4.4.3. OpenShift CLI 툴을 사용하여 Velero 리소스 디버깅
링크 복사

Velero 사용자 정의 리소스(CR) 및 OpenShift CLI 툴을 사용하여 Velero Pod 로그를 확인하여 실패한 백업 또는 복원을 디버깅할 수 있습니다.

Velero CR

oc describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다. 

$ oc describe <velero_cr> <cr_name>
Copy to Clipboard Toggle word wrap
Velero 포드 로그

oc logs 명령을 사용하여 Velero pod 로그를 검색합니다. 

$ oc logs pod/<velero>
Copy to Clipboard Toggle word wrap
Velero Pod 디버그 로그

다음 예와 같이 DataProtectionApplication 리소스에서 Velero 로그 수준을 지정할 수 있습니다.

참고

이 옵션은 OADP 1.0.3부터 사용할 수 있습니다. 

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
spec:
  configuration:
    velero:
      logLevel: warning
Copy to Clipboard Toggle word wrap

다음 logLevel 값을 사용할 수 있습니다.

  • trace
  • debug
  • info
  • 경고
  • error
  • fatal
  • panic

대부분의 로그에 debug 를 사용하는 것이 좋습니다.

4.4.4. Velero CLI 툴을 사용하여 Velero 리소스 디버깅
링크 복사

Backup 및 Restore CR(사용자 정의 리소스)을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다.

Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.

구문

oc exec 명령을 사용하여 Velero CLI 명령을 실행합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> <command> <cr_name>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
Copy to Clipboard Toggle word wrap

도움말 옵션

velero --help 옵션을 사용하여 모든 Velero CLI 명령을 나열합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  --help
Copy to Clipboard Toggle word wrap
Describe 명령

velero describe 명령을 사용하여 Backup 또는 Restore CR과 관련된 경고 및 오류 요약을 검색합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
Copy to Clipboard Toggle word wrap

Logs 명령

velero logs 명령을 사용하여 Backup 또는 Restore CR의 로그를 검색합니다. 

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>
Copy to Clipboard Toggle word wrap

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
Copy to Clipboard Toggle word wrap

4.4.5. 설치 문제
링크 복사

Data Protection 애플리케이션을 설치할 때 잘못된 디렉토리 또는 잘못된 인증 정보를 사용하여 발생한 문제가 발생할 수 있습니다.

4.4.5.1. 백업 스토리지에 잘못된 디렉터리가 포함되어 있습니다.
링크 복사

Velero pod 로그에 오류 메시지가 표시되고 Backup storage에는 잘못된 최상위 디렉터리가 포함되어 있습니다.

원인

오브젝트 스토리지에는 Velero 디렉터리가 아닌 최상위 디렉터리가 포함되어 있습니다.

해결책

오브젝트 스토리지가 Velero에 전용되지 않은 경우 DataProtectionApplication 매니페스트에서 spec.backupLocations.velero.objectStorage.prefix 매개변수를 설정하여 버킷의 접두사를 지정해야 합니다.

4.4.5.2. 잘못된 AWS 인증 정보
링크 복사

oadp-aws-registry Pod 로그에 오류 메시지 InvalidAccessKeyId가 표시됩니다. 제공한 AWS Access Key는 저희 기록에 존재하지 않습니다.

Velero pod 로그에 오류 메시지 NoCredentialProviders: no valid providers in chain 가 표시됩니다.

원인

Secret 오브젝트를 생성하는 데 사용되는 credentials-velero 파일이 잘못 포맷되어 있습니다.

해결책

다음 예와 같이 credentials-velero 파일의 형식이 올바르게 지정되었는지 확인합니다.

credentials-velero 파일의 예

[default]
1 

aws_access_key_id=AKIAIOSFODNN7EXAMPLE
2 

aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Copy to Clipboard Toggle word wrap

1
AWS 기본 프로필.
2
따옴표(", ')로 값을 묶지 마십시오.

4.4.6. CR 문제 백업 및 복원
링크 복사

백업 및 복원 사용자 정의 리소스 (CR)에서 이러한 일반적인 문제가 발생할 수 있습니다.

4.4.6.1. 백업 CR은 볼륨을 검색할 수 없습니다.
링크 복사

Backup CR에 오류 메시지 InvalidVolume.NotFound가 표시됩니다. 'vol-xxxx' 볼륨이 존재하지 않습니다.

원인

PV(영구 볼륨) 및 스냅샷 위치는 다른 지역에 있습니다.

해결책

  1. 스냅샷 위치가 PV와 동일한 지역에 있도록 DataProtectionApplication 매니페스트의 spec.snapshotLocations.velero.config.region 키 값을 편집합니다.
  2. 새 Backup CR을 생성합니다.
4.4.6.2. 백업 CR 상태는 진행 중인 상태로 유지됩니다.
링크 복사

Backup CR의 상태는 InProgress 단계에 남아 있으며 완료되지 않습니다.

원인

백업이 중단되면 다시 시작할 수 없습니다.

해결책

  1. Backup CR의 세부 정보를 검색합니다. 

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
  backup describe <backup>
    Copy to Clipboard Toggle word wrap

  2. Backup CR을 삭제합니다. 

    $ oc delete backup <backup> -n openshift-adp
    Copy to Clipboard Toggle word wrap

    진행 중인 Backup CR에서 오브젝트 스토리지에 파일을 업로드하지 않았기 때문에 백업 위치를 정리할 필요가 없습니다.

  3. 새 Backup CR을 생성합니다.

4.4.7. Restic 문제
링크 복사

Restic을 사용하여 애플리케이션을 백업할 때 이러한 문제가 발생할 수 있습니다.

4.4.7.1. root_squash가 활성화된 NFS 데이터 볼륨에 대한 Restic 권한 오류
링크 복사

Restic Pod 로그에 오류 메시지 controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied" 가 표시됩니다.

원인

NFS 데이터 볼륨에 root_squash 가 활성화된 경우 Restic 은 nfsnobody 에 매핑되고 백업을 생성할 수 있는 권한이 없습니다.

해결책

Restic 에 대한 추가 그룹을 생성하고 DataProtectionApplication 매니페스트에 그룹 ID를 추가하여 이 문제를 해결할 수 있습니다.

  1. NFS 데이터 볼륨에서 Restic 에 대한 추가 그룹을 생성합니다.
  2. 그룹 소유권이 상속되도록 NFS 디렉터리에 setgid 비트를 설정합니다.

  3. 다음 예와 같이 spec.configuration.restic.supplementalGroups 매개변수 및 그룹 ID를 DataProtectionApplication 매니페스트에 추가합니다. 

    spec:
  configuration:
    restic:
      enable: true
      supplementalGroups:
      - <group_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.

Restic 백업의 Restore CR은 PartiallyFailed 또는 Failed 상태로 완료되거나 InProgress 로 남아 있으며 완료되지 않습니다.

상태가 PartiallyFailed 또는 Failed 인 경우 Velero pod 로그에 오류 메시지 level=error msg="unable to successfully complete restic restores of pod's volumes" 가 표시됩니다.

상태가 InProgress 이면 Restore CR 로그를 사용할 수 없으며 Restic Pod 로그에 오류가 표시되지 않습니다.

원인

DeploymentConfig 오브젝트에서 Restore Pod를 재배포하여 Restore CR이 실패합니다.

해결책

  1. ReplicationController,DeploymentConfig, TemplateInstances 리소스를 제외하는 Restore CR을 생성합니다. 

    $ velero restore create --from-backup=<backup> -n openshift-adp \
    1 
    
  --include-namespaces <namespace> \
    2 
    
  --exclude-resources replicationcontroller,deploymentconfig,templateinstances.template.openshift.io \
  --restore-volumes=true
    Copy to Clipboard Toggle word wrap
    1
    Backup CR의 이름을 지정합니다.
    2
    Backup CR에 include-namespaces 를 지정합니다.

  2. Restore CR의 상태가 Completed 인지 확인합니다. 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

  3. ReplicationController 및 DeploymentConfig 리소스가 포함된 Restore CR 을 생성합니다. 

    $ velero restore create --from-backup=<backup> -n openshift-adp \
  --include-namespaces <namespace> \
  --include-resources replicationcontroller,deploymentconfig \
  --restore-volumes=true
    Copy to Clipboard Toggle word wrap

  4. Restore CR의 상태가 Completed 인지 확인합니다. 

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

  5. 백업 리소스가 복원되었는지 확인합니다. 

    $ oc get all -n <namespace>
    Copy to Clipboard Toggle word wrap
4.4.7.3. Restic Backup CR은 버킷이 선점된 후 다시 생성할 수 없습니다.
링크 복사

네임스페이스에 대한 Restic Backup CR을 생성하고 S3 버킷을 비우고 동일한 네임스페이스에 Backup CR을 다시 생성하면 다시 생성되는 Backup CR이 실패합니다.

velero Pod 로그에 오류 메시지 msg="Error checking repository for stale locks" 가 표시됩니다.

원인

Velero는 오브젝트 스토리지에서 Restic 디렉터리가 삭제되면 ResticRepository 매니페스트에서 Restic 리포지토리를 생성하지 않습니다. 자세한 내용은 (Velero 문제 4421)를 참조하십시오.

4.4.8. must-gather 툴 사용
링크 복사

must-gather 툴을 사용하여 OADP 사용자 정의 리소스에 대한 로그, 메트릭 및 정보를 수집할 수 있습니다.

must-gather 데이터는 모든 고객 사례에 첨부되어야 합니다.

다음 데이터 수집 옵션을 사용하여 must-gather 툴을 실행할 수 있습니다.

  • full must-gather 데이터 수집은 OADP Operator가 설치된 모든 네임스페이스에 대한 Prometheus 지표, Pod 로그 및 Velero CR 정보를 수집합니다.
  • 필수 must-gather 데이터 수집은 특정 기간(예: 1시간 또는 24시간) 동안 Pod 로그 및 Velero CR 정보를 수집합니다. Prometheus 지표 및 중복 로그는 포함되지 않습니다.
  • 시간 초과가 포함된 must-gather 데이터 수집 데이터 수집은 많은 백업 CR이 실패한 경우 오랜 시간이 걸릴 수 있습니다. 시간 제한 값을 설정하여 성능을 향상시킬 수 있습니다.
  • Prometheus 지표 데이터 덤프는 Prometheus에서 수집한 지표 데이터가 포함된 아카이브 파일을 다운로드합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인해야 합니다.
  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

절차

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

  2. 다음 데이터 수집 옵션 중 하나에 대해 oc adm must-gather 명령을 실행합니다.

    • Prometheus 지표를 포함한 전체 must-gather 데이터 수집 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0
      Copy to Clipboard Toggle word wrap

      데이터는 must-gather/must-gather.tar.gz 로 저장됩니다. Red Hat 고객 포털에서 해당 지원 사례에 이 파일을 업로드할 수 있습니다.

    • 특정 기간 동안 Prometheus 지표 없이 필수 must-gather 데이터 수집 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_<time>_essential
      1
      Copy to Clipboard Toggle word wrap
      1
      시간을 시간 단위로 지정합니다. 허용되는 값은 1h,6h,24h,72h, 또는 모두 (예: gather_1h_essential 또는 gather_all_essential )입니다.

    • 시간 초과가 포함된 must-gather 데이터 수집 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_with_timeout <timeout>
      1
      Copy to Clipboard Toggle word wrap
      1
      시간 초과 값을 초 단위로 지정합니다.

    • Prometheus 지표 데이터 덤프: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_metrics_dump
      Copy to Clipboard Toggle word wrap

      이 작업에는 오랜 시간이 걸릴 수 있습니다. 데이터는 must-gather/metrics/prom_data.tar.gz 로 저장됩니다.

Prometheus 콘솔을 사용하여 메트릭 데이터 보기

Prometheus 콘솔을 사용하여 지표 데이터를 볼 수 있습니다.

절차

  1. prom_data.tar.gz 파일의 압축을 풉니다. 

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz
    Copy to Clipboard Toggle word wrap

  2. 로컬 Prometheus 인스턴스를 생성합니다. 

    $ make prometheus-run
    Copy to Clipboard Toggle word wrap

    이 명령은 Prometheus URL을 출력합니다.

    출력 결과

    Started Prometheus on http://localhost:9090
    Copy to Clipboard Toggle word wrap

  3. 웹 브라우저를 시작하고 URL로 이동하여 Prometheus 웹 콘솔을 사용하여 데이터를 확인합니다.

  4. 데이터를 보고 나면 Prometheus 인스턴스 및 데이터를 삭제합니다. 

    $ make prometheus-cleanup
    Copy to Clipboard Toggle word wrap

5장. 컨트롤 플레인 백업 및 복원
링크 복사

5.1. etcd 백업
링크 복사

etcd는 모든 리소스 개체의 상태를 저장하는 OpenShift Container Platform의 키-값 형식의 저장소입니다.

클러스터의 etcd 데이터를 정기적으로 백업하고 OpenShift Container Platform 환경 외부의 안전한 위치에 백업 데이터를 저장하십시오. 설치 후 24 시간 내에 발생하는 첫 번째 인증서 교체가 완료되기 전까지 etcd 백업을 수행하지 마십시오. 인증서 교체가 완료되기 전에 실행하면 백업에 만료된 인증서가 포함됩니다. etcd 스냅샷에 I/O 비용이 높기 때문에 사용량이 많은 시간 동안 etcd 백업을 수행하는 것도 좋습니다.

클러스터를 업그레이드한 후 etcd 백업을 수행해야 합니다. 이는 클러스터를 복원할 때 동일한 z-stream 릴리스에서 가져온 etcd 백업을 사용해야 하므로 중요합니다. 예를 들어 OpenShift Container Platform 4.y.z 클러스터는 4.y.z에서 가져온 etcd 백업을 사용해야 합니다.

중요

컨트롤 플레인 호스트(마스터 호스트라고도 함)에서 백업 스크립트를 실행하여 클러스터의 etcd 데이터를 백업합니다. 클러스터의 각 컨트롤 플레인 호스트마다 백업을 수행하지 마십시오.

etcd 백업 후 이전 클러스터 상태로 복원할 수 있습니다.

5.1.1. etcd 데이터 백업
링크 복사

다음 단계에 따라 etcd 스냅샷을 작성하고 정적 pod의 리소스를 백업하여 etcd 데이터를 백업합니다. 이 백업을 저장하여 etcd를 복원해야하는 경우 나중에 사용할 수 있습니다.

중요

단일 컨트롤 플레인 호스트(마스터 호스트라고도 함)의 백업만 저장합니다. 클러스터의 각 컨트롤 플레인 호스트에서 백업을 수행하지 마십시오.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • 클러스터 전체의 프록시가 활성화되어 있는지 확인해야 합니다.

    작은 정보

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

절차

  1. 컨트롤 플레인 노드의 디버그 세션을 시작합니다. 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. 루트 디렉토리를 /host 로 변경합니다. 

    sh-4.2# chroot /host
    Copy to Clipboard Toggle word wrap
  3. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

  4. cluster-backup.sh 스크립트를 실행하고 백업을 저장할 위치를 입력합니다.

    작은 정보

    cluster-backup.sh 스크립트는 etcd Cluster Operator의 구성 요소로 유지 관리되며 etcdctl snapshot save 명령 관련 래퍼입니다. 

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

    • snapshot_<datetimestamp>.db: 이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.

    • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 포드 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

      참고

      etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

      etcd 암호화는 키가 아닌 값만 암호화합니다. 이는 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

5.2. 비정상적인 etcd 멤버 교체
링크 복사

이 문서는 비정상적인 단일 etcd 멤버를 교체하는 프로세스를 설명합니다.

이 프로세스는 시스템이 실행 중이 아니거나 노드가 준비되지 않았거나 etcd pod가 크래시 루프 상태에있는 등 etcd 멤버의 비정상적인 상태에 따라 다릅니다.

참고

대부분의 컨트롤 플레인 호스트 (마스터 호스트라고도 함)가 손실되고 etcd 쿼럼 (정족수)의 손실이 발생한 경우 재해 복구 프로세스에 따라 이전 클러스터 상태로 복원해야 합니다.

교체된 멤버에서 컨트롤 플레인 인증서가 유효하지 않은 경우 이 프로세스 대신 만료된 컨트롤 플레인 인증서 복구절차를 따라야합니다.

컨트롤 플레인 노드가 유실되고 새 노드가 생성되는 경우 etcd 클러스터 Operator는 새 TLS 인증서 생성 및 노드를 etcd 멤버로 추가하는 프로세스를 진행합니다.

5.2.1. 사전 요구 사항
링크 복사

  • 비정상적인 etcd 멤버를 교체하기 전에 etcd 백업을 수행하십시오.

5.2.2. 비정상 etcd 멤버 식별
링크 복사

클러스터에 비정상적인 etcd 멤버가 있는지 여부를 확인할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 명령을 사용하여 EtcdMembersAvailable 상태의 상태 조건을 확인하십시오. 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

  2. 출력을 확인합니다. 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
    Copy to Clipboard Toggle word wrap

    이 출력 예는 ip-10-0-131-183.ec2.internal etcd 멤버가 비정상임을 보여줍니다.

5.2.3. 비정상적인 etcd 멤버의 상태 확인
링크 복사

비정상적인 etcd 멤버를 교체하는 프로세스는 etcd가 다음의 어떤 상태에 있는지에 따라 달라집니다.

  • 컴퓨터가 실행 중이 아니거나 노드가 준비되지 않았습니다.
  • etcd pod가 크래시 루프 상태에 있습니다.

다음 프로세스에서는 etcd 멤버가 어떤 상태에 있는지를 확인합니다. 이를 통해 비정상 etcd 멤버를 대체하기 위해 수행해야하는 단계를 확인할 수 있습니다.

참고

시스템이 실행되고 있지 않거나 노드가 준비되지 않았지만 곧 정상 상태로 돌아올 것으로 예상되는 경우 etcd 멤버를 교체하기 위한 절차를 수행할 필요가 없습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 비정상적인 etcd 멤버를 식별하고 있습니다.

프로세스

  1. 시스템이 실행되고 있지 않은지를 확인합니다. 

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
    Copy to Clipboard Toggle word wrap

    출력 예

    ip-10-0-131-183.ec2.internal  stopped
    1
    Copy to Clipboard Toggle word wrap

    1
    이 출력은 노드와 노드 시스템의 상태를 나열합니다. 상태가 running이 아닌 경우 시스템은 실행되지 않습니다.

    시스템이 실행되고 있지 않은 경우, 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  2. 노드가 준비되지 않았는지 확인합니다.

    다음 조건 중 하나에 해당하면 노드가 준비되지 않은 것입니다.

    • 시스템이 실행중인 경우 노드에 액세스할 수 있는지 확인하십시오. 

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable
      1
      Copy to Clipboard Toggle word wrap

      1
      unreachable 상태의 노드가 나열되면 노드가 준비되지 않은 것 입니다.

    • 노드에 여전히 액세스할 수 있는 경우 노드가 NotReady로 나열되어 있는지 확인하십시오. 

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
      Copy to Clipboard Toggle word wrap

      출력 예

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.21.0
      1
      Copy to Clipboard Toggle word wrap

      1
      노드가 NotReady로 표시되면 노드가 준비되지 않은 것입니다.

    노드가 준비되지 않은 경우 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

  3. etcd pod가 크래시 루프 상태인지 확인합니다.

    시스템이 실행되고 있고 노드가 준비된 경우 etcd pod가 크래시 루프 상태인지 확인하십시오.

    1. 컨트롤 플레인 노드(마스터 노드라고도 함)가 다음과 같이 Ready로 나열되는지 확인합니다. 

      $ oc get nodes -l node-role.kubernetes.io/master
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.21.0
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.21.0
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.21.0
      Copy to Clipboard Toggle word wrap

    2. etcd pod의 상태가 Error 또는 CrashloopBackoff인지 확인하십시오. 

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      1 
      
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

      1
      이 pod의 상태는 Error이므로 etcd pod는 크래시 루프 상태입니다.

    etcd pod가 크래시 루프 상태인 경우etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체 프로세스를 수행하십시오.

5.2.4. 비정상적인 etcd 멤버 교체
링크 복사

비정상적인 etcd 멤버의 상태에 따라 다음 절차 중 하나를 사용합니다.

다음에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 경우의 비정상적인 etcd 멤버를 교체하는 프로세스에 대해 자세히 설명합니다.

사전 요구 사항

  • 비정상적인 etcd 멤버를 식별했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

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

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 잠시 동안 클러스터에 연결할 수 없습니다.

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

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

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

  3. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  4. 컨트롤 플레인 시스템(마스터 시스템이라고도 함)을 삭제하고 다시 생성합니다. 이 시스템을 다시 만든 후에는 새 버전이 강제 실행되고 etcd는 자동으로 확장됩니다.

    설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 마스터를 만들 때 사용한 방법과 동일한 방법을 사용하여 새 마스터를 작성해야합니다.

    1. 비정상 멤버의 컴퓨터를 가져옵니다.

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

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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-154-204.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-164-97.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
      Copy to Clipboard Toggle word wrap

      1
      이는 비정상 노드의 컨트롤 플레인 시스템 ip-10-0-131-183.ec2.internal입니다.

    2. 시스템 설정을 파일 시스템의 파일에 저장합니다. 

      $ oc get machine clustername-8qw5l-master-0 \
      1 
      
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
      Copy to Clipboard Toggle word wrap
      1
      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

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

      1. 전체 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
        Copy to Clipboard Toggle word wrap

      2. metadata.name 필드를 새 이름으로 변경합니다.

        이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 clustername-8qw5l-master-0은 clustername-8qw5l-master-3으로 변경되어 있습니다.

        예를 들면 다음과 같습니다. 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
        Copy to Clipboard Toggle word wrap

      3. spec.providerID 필드를 삭제합니다. 

          providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
        Copy to Clipboard Toggle word wrap

    4. 비정상 멤버의 시스템을 삭제합니다. 

      $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
      1
      Copy to Clipboard Toggle word wrap
      1
      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

    5. 시스템이 삭제되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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-154-204.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-164-97.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
      Copy to Clipboard Toggle word wrap

    6. new-master-machine.yaml 파일을 사용하여 새 시스템을 만듭니다. 

      $ oc apply -f new-master-machine.yaml
      Copy to Clipboard Toggle word wrap

    7. 새 시스템이 생성되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      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-154-204.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-164-97.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-133-53.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
      Copy to Clipboard Toggle word wrap

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

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

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

    $ oc patch etcd/cluster --type=merge -p '\{"spec": {"unsupportedConfigOverrides": null}}
    Copy to Clipboard Toggle word wrap

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

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

  2. 정확히 세 개의 etcd 멤버가 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

5.2.4.2. etcd pod가 크래시 루프 상태인 비정상적인 etcd 멤버 교체
링크 복사

이 단계에서는 etcd pod가 크래시 루프 상태에 있는 경우 비정상 etcd 멤버를 교체하는 방법을 설명합니다.

전제 조건

  • 비정상적인 etcd 멤버를 식별했습니다.
  • etcd pod가 크래시 루프 상태에 있는것으로 확인되었습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 프로세스를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 크래시 루프 상태에 있는 etcd pod를 중지합니다.

    1. 크래시 루프 상태의 노드를 디버깅합니다.

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

      $ oc debug node/ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이를 비정상 노드의 이름으로 변경합니다.

    2. 루트 디렉토리를 /host 로 변경합니다. 

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

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

      sh-4.2# mkdir /var/lib/etcd-backup
      Copy to Clipboard Toggle word wrap 
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
      Copy to Clipboard Toggle word wrap

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

      sh-4.2# mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

  2. 비정상적인 멤버를 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

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

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 62bcf33650a7170a
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

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

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

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

  4. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

      출력 예

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

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

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드 (마스터 노드라고도함)에서 etcd pod가 작동하는지 확인합니다.

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

    $ oc patch etcd/cluster --type=merge -p '\{"spec": {"unsupportedConfigOverrides": null}}
    Copy to Clipboard Toggle word wrap

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

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

검증

  • 새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 다시 연결합니다.

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. 모든 멤버가 정상인지 확인합니다. 

      sh-4.2# etcdctl endpoint health
      Copy to Clipboard Toggle word wrap

      출력 예

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms
      Copy to Clipboard Toggle word wrap

이 프로세스에서는 시스템이 실행되고 있지 않거나 노드가 준비되지 않았기 때문에 비정상 상태의 베어 메탈 etcd 멤버를 교체하는 단계를 자세히 설명합니다.

설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.

사전 요구 사항

  • 비정상적인 베어 메탈 etcd 멤버를 식별했습니다.
  • 시스템이 실행되고 있지 않거나 노드가 준비되지 않았음을 확인했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

  • etcd 백업이 수행되었습니다.

    중요

    문제가 발생할 경우 클러스터를 복원할 수 있도록 이 단계를 수행하기 전에 etcd 백업을 수행해야합니다.

프로세스

  1. 비정상 멤버를 확인하고 제거합니다.

    1. 영향을 받는 노드에 없는 pod를 선택합니다.

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

      $ oc get pods -n openshift-etcd -o wide | grep etcd | grep -v guard
      Copy to Clipboard Toggle word wrap

      출력 예

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

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

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
      Copy to Clipboard Toggle word wrap

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      Copy to Clipboard Toggle word wrap

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다. 

      sh-4.2# etcdctl member remove 7a8197040a5126c8
      Copy to Clipboard Toggle word wrap

      출력 예

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
      Copy to Clipboard Toggle word wrap

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      출력 예

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      Copy to Clipboard Toggle word wrap

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 잠시 동안 클러스터에 연결할 수 없습니다.

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

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

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

  3. 다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
      Copy to Clipboard Toggle word wrap

      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다. 

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
      Copy to Clipboard Toggle word wrap

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

  4. 컨트롤 플레인 시스템을 삭제합니다.

    설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.

    1. 비정상 멤버의 컴퓨터를 가져옵니다.

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

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
      1 
      
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
      Copy to Clipboard Toggle word wrap

      1
      비정상 노드의 컨트롤 플레인 시스템 예cluster-control-plane-2.

    2. 시스템 설정을 파일 시스템의 파일에 저장합니다. 

      $ oc get machine examplecluster-control-plane-2 \
      1 
      
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
      Copy to Clipboard Toggle word wrap
      1
      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

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

      1. 전체 status 섹션을 삭제합니다. 

        status:
  addresses:
  - address: ""
    type: InternalIP
  - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.373
    type: InternalDNS
  - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.371
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Machine
    name: fe80::4adf:37ff:feb0:8aa1%ens1f1.372
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: machine.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: Machine
        Copy to Clipboard Toggle word wrap

  5. metadata.name 필드를 새 이름으로 변경합니다.

    이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 examplecluster-control-plane-2 는 examplecluster-control-plane-3 으로 변경되었습니다.

    예를 들면 다음과 같습니다. 

    apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: examplecluster-control-plane-3
  ...
    Copy to Clipboard Toggle word wrap

    1. spec.providerID 필드를 삭제합니다. 

        providerID: baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135
      Copy to Clipboard Toggle word wrap

    2. metadata.annotations 및 metadata.generation 필드를 제거합니다. 

        annotations:
    machine.openshift.io/instance-state: externally provisioned
  ...
  generation: 2
      Copy to Clipboard Toggle word wrap

    3. spec.conditions,spec.lastUpdated,spec.nodeRef 및 spec.phase 필드를 제거합니다. 

        lastTransitionTime: "2022-08-03T08:40:36Z"
message: 'Drain operation currently blocked by: [{Name:EtcdQuorumOperator Owner:clusteroperator/etcd}]'
reason: HookPresent
severity: Warning
status: "False"

type: Drainable
lastTransitionTime: "2022-08-03T08:39:55Z"
status: "True"
type: InstanceExists

lastTransitionTime: "2022-08-03T08:36:37Z"
status: "True"
type: Terminable
lastUpdated: "2022-08-03T08:40:36Z"
nodeRef:
kind: Node
name: openshift-control-plane-2
uid: 788df282-6507-4ea2-9a43-24f237ccbc3c
phase: Running
      Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다. 

    $ oc get clusteroperator baremetal
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.11.3    True        False         False      3d15h
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 사용하여 비정상 멤버의 시스템을 삭제합니다. 

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
    Copy to Clipboard Toggle word wrap

    어떤 이유로든 머신 삭제가 지연되거나 명령이 차단되고 지연되면 machine object finalizer 필드를 제거하여 강제로 삭제할 수 있습니다.

    중요

    Ctrl+c 를 눌러 머신 삭제를 중단하지 마십시오. 명령이 완료될 수 있도록 허용해야 합니다. 새 터미널 창을 열어 편집하여 종료자 필드를 삭제합니다. 

    $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
    Copy to Clipboard Toggle word wrap

    1. 필드를 찾아서 삭제합니다. 

      finalizers:
- machine.machine.openshift.io
      Copy to Clipboard Toggle word wrap

      변경 사항을 저장합니다. 

      machine.machine.openshift.io/examplecluster-control-plane-2 edited
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 시스템이 삭제되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
      Copy to Clipboard Toggle word wrap

  8. 다음 명령을 사용하여 이전 BareMetalHost 오브젝트를 제거합니다. 

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    출력 예

    baremetalhost.metal3.io "openshift-control-plane-2" deleted
    Copy to Clipboard Toggle word wrap

    BareMetalHost 및 Machine 오브젝트를 제거한 후 머신 컨트롤러에서 Node 오브젝트를 자동으로 삭제합니다.

    BareMetalHost 오브젝트를 삭제한 후 머신 노드를 삭제하는 데 과도한 시간이 필요한 경우 다음을 사용하여 머신 노드를 삭제할 수 있습니다. 

    $ oc delete node openshift-control-plane-2

node "openshift-control-plane-2" deleted
    Copy to Clipboard Toggle word wrap

    노드가 삭제되었는지 확인합니다. 

    $ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.24.0+9546431
openshift-control-plane-1 Ready master 3h24m v1.24.0+9546431
openshift-compute-0       Ready worker 176m v1.24.0+9546431
openshift-compute-1       Ready worker 176m v1.24.0+9546431
    Copy to Clipboard Toggle word wrap

  9. 새 BareMetalHost 오브젝트와 시크릿을 생성하여 BMC 자격 증명을 저장합니다. 

    $ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: openshift-control-plane-2-bmc-secret
  namespace: openshift-machine-api
data:
  password: <password>
  username: <username>
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    credentialsName: openshift-control-plane-2-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:b0:8a:a0
  bootMode: UEFI
  externallyProvisioned: false
  online: true
  rootDeviceHints:
    deviceName: /dev/sda
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api
EOF
    Copy to Clipboard Toggle word wrap
    참고

    사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 찾을 수 있습니다. bmc:address 에 사용할 프로토콜은 다른 bmh 개체에서 가져올 수 있습니다.

    중요

    기존 컨트롤 플레인 호스트에서 BareMetalHost 오브젝트 정의를 재사용하는 경우 external Provisioned 필드를 true 로 설정하지 마십시오.

    기존 컨트롤 플레인 BareMetalHost 오브젝트는 OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 외부Provisioned 플래그를 true 로 설정할 수 있습니다.

    검사가 완료되면 BareMetalHost 오브젝트가 생성되고 프로비저닝할 수 있습니다.

  10. 사용 가능한 BareMetalHost 오브젝트를 사용하여 생성 프로세스를 확인합니다. 

    $ oc get bmh -n openshift-machine-api

NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
    Copy to Clipboard Toggle word wrap

    1. new-master-machine.yaml 파일을 사용하여 새 컨트롤 플레인 시스템을 생성합니다. 

      $ oc apply -f new-master-machine.yaml
      Copy to Clipboard Toggle word wrap

    2. 새 시스템이 생성되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
      1 
      
examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
      Copy to Clipboard Toggle word wrap

      1
      새 시스템 clustername-8qw5l-master-3 이 생성되며 단계가 Provisioning( 프로비저닝)에서 Running (실행 중)으로 변경된 후 준비됩니다.

      새 시스템을 생성하는 데 몇 분이 걸릴 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

    3. 베어 메탈 호스트가 프로비저닝되고 다음 명령을 실행하여 오류가 보고되지 않았는지 확인합니다. 

      $ oc get bmh -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      출력 예

      $ oc get bmh -n openshift-machine-api
NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
      Copy to Clipboard Toggle word wrap

    4. 다음 명령을 실행하여 새 노드가 추가되고 준비 상태에 있는지 확인합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      출력 예

      $ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.24.0+9546431
openshift-control-plane-1 Ready master 4h26m v1.24.0+9546431
openshift-control-plane-2 Ready master 12m   v1.24.0+9546431
openshift-compute-0       Ready worker 3h58m v1.24.0+9546431
openshift-compute-1       Ready worker 3h58m v1.24.0+9546431
      Copy to Clipboard Toggle word wrap

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

    $ oc patch etcd/cluster --type=merge -p '\{"spec": {"unsupportedConfigOverrides": null}}
    Copy to Clipboard Toggle word wrap

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

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

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

    $ oc get pods -n openshift-etcd -o wide | grep etcd | grep -v guard
    Copy to Clipboard Toggle word wrap

    출력 예

    etcd-openshift-control-plane-0      5/5     Running     0     105m
etcd-openshift-control-plane-1      5/5     Running     0     107m
etcd-openshift-control-plane-2      5/5     Running     0     103m
    Copy to Clipboard Toggle word wrap

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    Copy to Clipboard Toggle word wrap

  2. 멤버 목록을 확인합니다. 

    sh-4.2# etcdctl member list -w table
    Copy to Clipboard Toggle word wrap

    출력 예

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    Copy to Clipboard Toggle word wrap

    참고

    이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

  3. 다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다. 

    # etcdctl endpoint health --cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다. 

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap 
    AllNodesAtLatestRevision
    Copy to Clipboard Toggle word wrap

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 백업을 사용하여 이전 클러스터 상태를 복원하거나 컨트롤 플레인 호스트 (마스터 호스트라고도 함)가 손실된 클러스터를 복원할 수 있습니다.

중요

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

사전 요구 사항

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

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

프로세스

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

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

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

    중요

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

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

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

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

    참고

    복구 호스트에서 pod를 수동으로 중지할 필요는 없습니다. 복구 스크립트는 복구 호스트에서 pod를 중지합니다.

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

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

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

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

      $ sudo crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
      Copy to Clipboard Toggle word wrap

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

      $ sudo crictl ps | grep kube-apiserver | grep -v operator
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap
    7. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
  5. 복구 컨트롤 플레인 호스트에 액세스합니다.

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

    작은 정보

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

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

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup
    Copy to Clipboard Toggle word wrap

    스크립트 출력 예

    ...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
    Copy to Clipboard Toggle word wrap

    참고

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

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

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

      $ oc get nodes -w
      Copy to Clipboard Toggle word wrap

      샘플 출력

      NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf
      Copy to Clipboard Toggle word wrap

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

    2. NotReady 상태에 있는 노드가 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH로 액세스하거나 웹 콘솔의 터미널 창을 사용할 수 있습니다. 

      $  ssh -i <ssh-key-path> core@<master-hostname>
      Copy to Clipboard Toggle word wrap

      샘플 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
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo systemctl restart kubelet.service
      Copy to Clipboard Toggle word wrap
    2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

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

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

      $ oc get csr
      Copy to Clipboard Toggle word wrap

      출력 예

      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 
      
...
      Copy to Clipboard Toggle word wrap

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

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

      $ oc describe csr <csr_name>
      1
      Copy to Clipboard Toggle word wrap
      1
      <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

      $ oc adm certificate approve <csr_name>
      Copy to Clipboard Toggle word wrap

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

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

      $ sudo crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      출력 예

      3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
      Copy to Clipboard Toggle word wrap

    2. 복구 호스트에서 etcd pod가 실행 중인지 확인합니다. 

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      Copy to Clipboard Toggle word wrap
      참고

      이 명령을 실행하기 전에 oc login을 실행하여 다음 오류가 발생하면 인증 컨트롤러가 시작될 때까지 잠시 기다렸다가 다시 시도하십시오. 

      Unable to connect to the server: EOF
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
      Copy to Clipboard Toggle word wrap

      Pending 상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

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

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

    설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.

    주의

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

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

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

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예: 

      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
      Copy to Clipboard Toggle word wrap
      1
      이는 손실된 컨트롤 플레인 호스트 ip-10-0-131-183.ec2.internal의 컨트롤 플레인 시스템입니다.

    2. 시스템 설정을 파일 시스템의 파일에 저장합니다. 

      $ oc get machine clustername-8qw5l-master-0 \
      1 
      
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
      Copy to Clipboard Toggle word wrap
      1
      손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

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

      1. 전체 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
        Copy to Clipboard Toggle word wrap

      2. metadata.name 필드를 새 이름으로 변경합니다.

        이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서는 clustername-8qw5l-master-0 이 clustername-8qw5l-master-3 으로 변경되었습니다. 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
        Copy to Clipboard Toggle word wrap

      3. spec.providerID 필드를 삭제합니다. 

        providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
        Copy to Clipboard Toggle word wrap

      4. metadata.annotations 및 metadata.generation 필드를 제거합니다. 

        annotations:
  machine.openshift.io/instance-state: running
...
generation: 2
        Copy to Clipboard Toggle word wrap

      5. metadata.resourceVersion 및 metadata.uid 필드를 제거합니다. 

        resourceVersion: "13291"
uid: a282eb70-40a2-4e89-8009-d05dd420d31a
        Copy to Clipboard Toggle word wrap

    4. 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다. 

      $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
      1
      Copy to Clipboard Toggle word wrap
      1
      손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

    5. 시스템이 삭제되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예: 

      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
      Copy to Clipboard Toggle word wrap

    6. new-master-machine.yaml 파일을 사용하여 새 시스템을 만듭니다. 

      $ oc apply -f new-master-machine.yaml
      Copy to Clipboard Toggle word wrap

    7. 새 시스템이 생성되었는지 확인합니다. 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      출력 예: 

      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
      Copy to Clipboard Toggle word wrap
      1
      새 시스템 clustername-8qw5l-master-3 이 생성되며 단계가 Provisioning( 프로비저닝)에서 Running (실행 중)으로 변경된 후 준비됩니다.

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

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

  13. 별도의 터미널 창에서 다음 명령을 사용하여 cluster-admin 역할의 사용자로 클러스터에 로그인합니다. 

    $ oc login -u <cluster_admin>
    1
    Copy to Clipboard Toggle word wrap
    1
    <cluster_admin>은 cluster-admin 역할을 사용하여 사용자 이름을 지정합니다.

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

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

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

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

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

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap

    etcd의 NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

    AllNodesAtLatestRevision
3 nodes are at revision 7
    1
    Copy to Clipboard Toggle word wrap
    1
    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

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

      $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
      Copy to Clipboard Toggle word wrap

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

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap

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

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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

이 프로세스를 완료한 후 모든 서비스를 복구하는데 몇 분 정도 걸릴 수 있습니다. 예를 들어, OAuth 서버 pod가 다시 시작될 때까지 oc login을 사용한 인증이 즉시 작동하지 않을 수 있습니다.

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

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을 승인하려면 다음 단계를 수행합니다.

절차

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

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    출력 예

    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 
    
...
    Copy to Clipboard Toggle word wrap

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

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

    $ oc describe csr <csr_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

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

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

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

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat