백업 및 복원

OpenShift Container Platform 4.6

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

초록

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

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 역할의 사용자로 로그인해야 합니다.

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

    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud Platform
    • Multicloud Object Gateway
    • S3 호환 오브젝트 스토리지(예: Noobaa 또는 Minio)
중요

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}'

    출력 예

    2022-08-05T14:37:50Zuser@user:~ $ 1

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

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

    참고

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

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

    종료하기 전에 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

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

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   75m   v1.19.0
ip-10-0-170-223.ec2.internal   Ready    master   75m   v1.19.0
ip-10-0-211-16.ec2.internal    Ready    master   75m   v1.19.0

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

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

      $ oc get csr

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

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

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

      $ oc adm certificate approve <csr_name>

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

    $ oc get nodes -l node-role.kubernetes.io/worker

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

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.19.0
ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.19.0
ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.19.0

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

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

      $ oc get csr

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

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

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

      $ oc adm certificate approve <csr_name>

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

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

      $ oc get clusteroperators

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

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.6.0     True        False         False      59m
cloud-credential                           4.6.0     True        False         False      85m
cluster-autoscaler                         4.6.0     True        False         False      73m
config-operator                            4.6.0     True        False         False      73m
console                                    4.6.0     True        False         False      62m
csi-snapshot-controller                    4.6.0     True        False         False      66m
dns                                        4.6.0     True        False         False      76m
etcd                                       4.6.0     True        False         False      76m
...

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

      $ oc get nodes

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

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

클러스터가 제대로 시작되지 않은 경우 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(Data Protection)용 OpenShift API는 스토리지 공급자와 통합되어 백업 및 스냅샷 작업을 지원하는 기본 Velero 플러그인을 제공합니다. Velero 플러그인을 기반으로 사용자 정의 플러그인을 생성할 수 있습니다.

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

표 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

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

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 문서 의 백업 위치 및 스냅샷 위치에 대한 개요입니다.

4.2.2. Amazon Web Services를 사용하여 데이터 보호용 OpenShift API 설치 및 구성

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.6에 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
    1
    S3 버킷 이름을 지정합니다.
    2
    S3 버킷 영역을 지정합니다(예: us-east-1).

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

    $ aws iam create-user --user-name velero

  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

  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
    1 2
    단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

    출력 예

    "Resource": [
    "arn:aws:s3:::*"

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

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-ebs \
  --policy-document file://velero-ec2-snapshot-policy.json

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

    $ aws iam put-user-policy \
  --user-name velero \
  --policy-name velero-s3 \
  --policy-document file://velero-s3-policy.json

  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
    }
}

  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

    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

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>

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

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero 1

  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"

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

    출력 예

    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

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
    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.6에 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

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

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    위치를 지정합니다.

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

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups

  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

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

    $ BLOB_CONTAINER=velero

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

    $ az storage container create \
  -n $BLOB_CONTAINER \
  --public-access off \
  --account-name $AZURE_STORAGE_ACCOUNT_ID

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

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

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

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
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

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

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

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

    출력 예

    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

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
    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.6에 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

    출력 예

    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)?

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

    $ BUCKET=<bucket> 1
    1
    버킷 이름을 지정합니다.

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

    $ gsutil mb gs://$BUCKET/

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

    $ PROJECT_ID=`gcloud config get-value project`

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

    $ gcloud iam service-accounts create velero \
    --display-name "Velero Storage"

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

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
  --filter="displayName:Velero Storage" \
  --format 'value(email)'`

  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
)

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

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

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

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
    --role projects/$PROJECT_ID/roles/velero.server

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

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

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

    $ gcloud iam service-accounts keys create credentials-velero \
  --iam-account $SERVICE_ACCOUNT_EMAIL

    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

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
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

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

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

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

    출력 예

    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

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
    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.6에 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. Multicloud Object Gateway 구성

MCG(Multicloud Object Gateway)를 MTC(Migration Toolkit for Containers)의 복제 리포지토리로 구성할 수 있습니다. MCG는 OpenShift Container Storage의 구성 요소입니다.

절차

  1. 적절한 OpenShift Container Storage 배포 가이드를 사용하여 OpenShift Container Storage를 배포합니다.

  2. NooBaa 사용자 지정 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY를 가져옵니다.

    MCG를 MTC 웹 콘솔에 복제 리포지토리로 추가하려면 이러한 값이 필요합니다.

4.2.5.3. 백업 및 스냅샷 위치에 대한 보안 생성

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

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

사전 요구 사항

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

절차

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

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

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
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

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

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

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

    출력 예

    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

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
    1
    csi 기본 플러그인을 추가합니다.
    2
    EnableCSI 기능 플래그를 추가합니다.

4.2.6. OpenShift Container Storage를 사용하여 데이터 보호용 OpenShift API 설치 및 구성

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.6에 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

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
  3. 오브젝트 스토리지에 적절한 형식으로 백업 위치에 대한 credentials-velero 파일을 생성합니다.

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

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero

  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>
    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
    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
...
    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 1
        - csi 2
        - openshift 3
    restic:
      enable: true 4
  backupLocations:
    - velero:
        provider: gcp 5
        default: true
        credential:
          key: cloud
          name: <default_secret> 6
        objectStorage:
          bucket: <bucket_name> 7
          prefix: <prefix> 8
    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
    백업 공급자에 기본 플러그인을 사용하는 경우 보안에 올바른 기본 이름(예: cloud-credentials-gcp )을 지정해야 합니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다. Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.
    7
    버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.
    8
    여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.
  4. 생성을 클릭합니다.

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

    $ oc get all -n openshift-adp

    출력 예

    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

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

    출력 예

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m

  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
    1
    백업할 네임스페이스 배열을 지정합니다.
    2
    backupStorageLocations CR의 이름을 지정합니다.

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

    $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'

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

    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

    기타 클라우드 공급자

    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

이제 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
...
    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
...
    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

    출력 예

    NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
velero-sample-1   Available   11s              31m

  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
    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}'

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
    1
    Backup CR의 이름입니다.

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

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

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

    $ oc get all -n <namespace> 1
    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
    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 버전을 다운로드합니다.

    표 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'

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>
Velero 포드 로그

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

$ oc logs pod/<velero>
Velero Pod 디버그 로그

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

참고

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

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
spec:
  configuration:
    velero:
      logLevel: warning

다음 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>

예제

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

도움말 옵션

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

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  --help
Describe 명령

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

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>

예제

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

Logs 명령

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

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>

예제

$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

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

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>

  2. Backup CR을 삭제합니다. 

    $ oc delete backup <backup> -n openshift-adp

    진행 중인 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
    1
    보조 그룹 ID를 지정합니다.
  4. 변경 사항을 적용할 수 있도록 Restic Pod가 다시 시작될 때까지 기다립니다.

4.4.7.2. Restic 백업의 복원 CR은 "PartiallyFailed", "Failed" 또는 remains "InProgress"입니다.

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
    1
    Backup CR의 이름을 지정합니다.
    2
    Backup CR에 include-namespaces 를 지정합니다.

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

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

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

    $ velero restore create --from-backup=<backup> -n openshift-adp \
  --include-namespaces <namespace> \
  --include-resources replicationcontroller,deploymentconfig \
  --restore-volumes=true

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

    $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

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

    $ oc get all -n <namespace>

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가 설치되어 있어야 합니다.

절차

  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

      데이터는 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
      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
      1
      시간 초과 값을 초 단위로 지정합니다.

    • Prometheus 지표 데이터 덤프: 

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.0 \
  -- /usr/bin/gather_metrics_dump

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

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

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

절차

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

    $ tar -xvzf must-gather/metrics/prom_data.tar.gz

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

    $ make prometheus-run

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

    출력 결과

    Started Prometheus on http://localhost:9090

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

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

    $ make prometheus-cleanup

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.6.2 클러스터는 4.6.2에서 가져온 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>

  2. 루트 디렉터리를 호스트로 변경하십시오. 

    sh-4.2# chroot /host
  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

    스크립트 출력 예

    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

    이 예제에서는 컨트롤 플레인 호스트의 /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"}'

  2. 출력을 확인합니다. 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy

    이 출력 예는 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

    출력 예

    ip-10-0-131-183.ec2.internal  stopped 1

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

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

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

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

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

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

      출력 예

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 1

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

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

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"

      출력 예

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.19.0 1

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

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

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

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

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

      $ oc get nodes -l node-role.kubernetes.io/master

      출력 예

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.19.0
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.19.0
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.19.0

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

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

      출력 예

      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

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

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

5.2.4. 비정상적인 etcd 멤버 교체

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

5.2.4.1. 시스템이 실행되고 있지 않거나 노드가 준비되지 않은 비정상적인 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

      출력 예

      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

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

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      출력 예

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 잠시 동안 클러스터에 연결할 수 없습니다.

  2. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      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

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

  3. 컨트롤 플레인 시스템(마스터 시스템이라고도 함)을 삭제하고 다시 생성합니다. 이 시스템을 다시 만든 후에는 새 버전이 강제 실행되고 etcd는 자동으로 확장됩니다.

    설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 마스터를 만들 때 사용한 방법과 동일한 방법을 사용하여 새 마스터를 작성해야합니다.

    1. 비정상 멤버의 컴퓨터를 가져옵니다.

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

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

      출력 예

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-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

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

      2. metadata.name 필드를 새 이름으로 변경합니다.

        이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 clustername-8qw5l-master-0은 clustername-8qw5l-master-3으로 변경되어 있습니다.

        예를 들면 다음과 같습니다. 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...

      3. 이전 단계의 새 시스템 이름을 사용하도록 metadata.selfLink 필드를 업데이트합니다. 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  selfLink: /apis/machine.openshift.io/v1beta1/namespaces/openshift-machine-api/machines/clustername-8qw5l-master-3
  ...

      4. spec.providerID 필드를 삭제합니다. 

          providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

      5. metadata.annotations 및 metadata.generation 필드를 제거합니다. 

          annotations:
    machine.openshift.io/instance-state: running
  ...
  generation: 2

      6. metadata.resourceVersion 및 metadata.uid 필드를 제거합니다. 

          resourceVersion: "13291"
  uid: a282eb70-40a2-4e89-8009-d05dd420d31a

    4. 비정상 멤버의 시스템을 삭제합니다. 

      $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
      1
      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

    5. 시스템이 삭제되었는지 확인합니다. 

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

      출력 예

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-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

    6. new-master-machine.yaml 파일을 사용하여 새 시스템을 만듭니다. 

      $ oc apply -f new-master-machine.yaml

    7. 새 시스템이 생성되었는지 확인합니다. 

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

      출력 예

      NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-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

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

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

검증

  1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    출력 예

    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

    이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다. 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

  2. 정확히 세 개의 etcd 멤버가 있는지 확인합니다.

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

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    2. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      이전 명령의 출력에 세 개 이상의 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
      1
      이를 비정상 노드의 이름으로 변경합니다.

    2. 루트 디렉토리를 호스트로 변경하십시오. 

      sh-4.2# chroot /host

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

      sh-4.2# mkdir /var/lib/etcd-backup
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/

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

      sh-4.2# mv /var/lib/etcd/ /tmp

      이제 노드 쉘을 종료할 수 있습니다.

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

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

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

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

      출력 예

      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

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

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    3. 멤버 목록을 확인합니다. 

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

    4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다. 

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      출력 예

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

    5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다. 

      sh-4.2# etcdctl member list -w table

      출력 예

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        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 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      이제 노드 쉘을 종료할 수 있습니다.

  3. 삭제된 비정상 etcd 멤버의 이전 암호를 제거합니다.

    1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      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

    2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. 서빙 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. 메트릭 시크릿을 삭제합니다. 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

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

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 수행하면 모든 컨트롤 플레인 노드 (마스터 노드라고도함)에서 etcd pod가 작동하는지 확인합니다.

검증

  • 새 멤버가 사용 가능하고 정상적인 상태에 있는지 확인합니다.

    1. 실행중인 etcd 컨테이너에 다시 연결합니다.

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

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    2. 모든 멤버가 정상인지 확인합니다. 

      sh-4.2# etcdctl endpoint health --cluster

      출력 예

      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

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.6.2 클러스터는 4.6.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

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

      $ sudo crictl ps | grep etcd | grep -v operator

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

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

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

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

      $ sudo crictl ps | grep kube-apiserver | grep -v operator

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

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

      $ sudo mv /var/lib/etcd/ /tmp
    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

    스크립트 출력 예

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

    참고

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

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

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

      $ oc get nodes -w

      샘플 출력

      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

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

    2. NotReady 상태에 있는 노드가 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 제거합니다. 노드에 SSH로 액세스하거나 웹 콘솔의 터미널 창을 사용할 수 있습니다. 

      $  ssh -i <ssh-key-path> core@<master-hostname>

      샘플 pki 디렉터리

      sh-4.4# pwd
/var/lib/kubelet/pki
sh-4.4# ls
kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
kubelet-client-current.pem              kubelet-server-current.pem

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

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

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

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

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

      $ oc get csr

      출력 예

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

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

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

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

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

      $ oc adm certificate approve <csr_name>

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

      $ oc adm certificate approve <csr_name>

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

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

      $ sudo crictl ps | grep etcd | grep -v operator

      출력 예

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

    2. 복구 호스트에서 etcd pod가 실행 중인지 확인합니다. 

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd
      참고

      이 명령을 실행하기 전에 oc login을 실행하여 다음 오류가 발생하면 인증 컨트롤러가 시작될 때까지 잠시 기다렸다가 다시 시도하십시오. 

      Unable to connect to the server: EOF

      출력 예

      NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

      Pending 상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

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

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1
    1
    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

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

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

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

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    etcd의 NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

    AllNodesAtLatestRevision
3 nodes are at revision 7 1
    1
    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

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

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

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

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. Kubernetes 컨트롤러 관리자에 대해 새 롤아웃을 강제 적용합니다. 

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

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

      $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

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

      $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다. 

      AllNodesAtLatestRevision
3 nodes are at revision 7 1
      1
      이 예에서 최신 버전 번호는 7입니다.

      출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    출력 예

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

복구 절차 후 모든 워크로드가 정상 작업으로 돌아가도록 하려면 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 리소스 삭제참조).

추가 리소스

  • SSH 를 사용하여 OpenShift Container Platform 인스턴스 및 컨트롤 플레인 노드에 액세스하기 위해 bastion 호스트를 생성하는 방법은 호스트에 액세스를 참조하십시오.

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

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

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

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

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

절차

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

    $ oc get csr

    출력 예

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

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

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

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

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

    $ oc adm certificate approve <csr_name>

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

    $ oc adm certificate approve <csr_name>