1. etcd 스냅샷을 기반으로 Kubernetes 클러스터 복원
  2. etcd 스냅샷 기반 Kubernetes 클러스터 복원에 대해 알아보기

etcd 스냅샷 기반 Kubernetes 클러스터 복원에 대해 알아보기

재해 발생 시 비즈니스 연속성을 보장하기 위해 Kubernetes 클러스터에서 실행되는 애플리케이션에 대한 재해 복구 전략을 구현해야 합니다. 이러한 Oracle Maximum Availability Architecture(Oracle MAA) 권장 사항을 사용하여 데이터 보호를 제공하고 데이터 및 생산성 손실을 최소화하면서 대기 시스템으로 신속하게 전환할 수 있습니다.

Kubernetes 채택이 IT 시스템의 아키텍처에 대해 의미하는 엄청난 변화에도 불구하고 Kubernetes 시스템은 기존 애플리케이션(예: Oracle Java SE, Oracle Java EE 또는 JavaScript)과 유사한 DR(재해 복구) 패러다임을 제공합니다. 재해로 인해 기본 영역에서 작동 중지 시간이 발생할 경우 작업 로드를 재개할 수 있는 보조 위치에서 기본 시스템의 일관되고 "가능한 최신" 복사본을 유지해야 합니다.

이 솔루션 플레이북은 보조 Kubernetes 시스템을 생성하고 위치에 영향을 미치는 재해 시나리오에서 복구하고 워크로드를 복제 사이트로 강제로 재지정할 수 있는 Oracle MAA 권장사항 및 유틸리티를 제공합니다.

이 솔루션 플레이북은 다른 영역에서 Kubernetes 클러스터를 복원하는 데 중점을 두지만 동일한 스크립트 및 절차를 사용하여 이전 시점으로 클러스터를 복원할 수 있습니다. 이 작업은 다음과 같이 재해 복구 이외의 시나리오에서 유용할 수 있습니다.

  • 제어 평면이 잘못 구성된 경우
  • etcd 데이터베이스가 손실되거나 손상되거나 etcd가 제대로 작동하지 않을 경우
  • 잘못된 배치 또는 사용자 오류가 여러 응용 프로그램 또는 마이크로서비스에 영향을 미치므로 클러스터를 이전 버전 또는 구체화 버전으로 되돌려야 합니다. ETCD 스냅샷 복원은 모든 아티팩트를 스냅샷(백업)이 생성된 시점으로 복원합니다.

이 문서에서는 Kubernetes 등의 데이터를 보조 위치에 복제하는 방법을 중점적으로 다룹니다. Kubernetes 클러스터의 모든 정보는 클러스터 데이터용 Kubernetes의 보조 저장소로 사용되는 키 값 저장소인 etcd에 저장됩니다. 이 솔루션 플레이북은 etcd 복원을 기반으로 Kubernetes kubeadm 툴로 생성된 Kubernetes 클러스터(https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ 참조)를 복제하기 위한 권장 사항을 제공합니다. 제공된 설정 절차 및 스크립트는 다른 유형의 클러스터(kubeadm로 생성되지 않은 클러스터)에 대한 사용자정의가 필요할 수 있지만 일반적으로 Kubernetes의 제어 플레인에서 사용하는 etcd 끝점에 대한 액세스 권한이 있는 경우 적합합니다. 이 복제 솔루션은 보조 클러스터에 대한 특정 설정이 필요하며 etcd 복사본(etd 스냅샷이라고도 함)을 사용하여 기본 클러스터에 존재하는 것과 동일한 아티팩트를 표시합니다.

아티팩트 스냅샷 또는 타사 Kubernetes 백업 툴을 사용하여 Kubernetes 시스템 전체에서 특정 네임스페이스 및 애플리케이션을 복제할 수 있습니다. 그러나 제어 플레인 메타데이터의 파일 손상 및 잘못된 구성으로부터 클러스터를 보호하지는 않습니다. etcd 스냅샷을 재해 방지용으로 사용하는 것 외에도 로컬 복원에 사용하고 Kubernetes 클러스터를 이전 작업 시점으로 되돌릴 수 있습니다. etcd 저장소 및 etcd 클러스터 시스템이 비정상인 경우 애플리케이션은 계속 실행될 수 있지만 Pod 재배치, 구성 변경, 보안 액세스 및 제어 플레인 가용성이 필요한 기타 모든 작업이 제대로 작동하지 않습니다. 따라서 etcd 보존은 Kubernetes 클러스터 수명 주기 절차의 중요한 부분이어야 합니다.

Kubernetes 구성 데이터 외에도 Kubernetes에서 실행되는 애플리케이션 및 마이크로서비스는 런타임 시 데이터를 생성할 수 있습니다. 런타임 데이터 재해 보호는 이 문서의 범위를 벗어나므로 애플리케이션 서버에서 실행되는 기존 애플리케이션과 동일한 방식으로 처리해야 합니다.

  • 다중 언어 지속성 방지(런타임 데이터에 대해 서로 다른 유형의 영구 저장소를 사용하는 것은 BAC 정리당 문제를 해결할 수 있는 "거의" 불가능)
  • 다양한 데이터 유형, 마이크로서비스 및 애플리케이션에 대해 가능한 한 많은 종속성을 갖춘 단일 저장소 사용
  • 런타임에 대한 재해 방지는 Oracle MAA Best Practices for Oracle Database를 참조하십시오.

시작하기 전에

기존 미들웨어 시스템에 대한 DR(재해 복구) 시스템을 설정하는 방법을 설명하는 몇 가지 Oracle Maximum Availability Architecture(MAA) 기술 개요가 있습니다. 이 문서에서는 Kubernetes 애플리케이션이 사용하는 외부 인프라 구성요소(예: 스토리지, 로드 밸런서 및 데이터베이스)에 대한 재해 보호 요구사항을 자세히 설명합니다.

자세한 내용은 다음을 참조하십시오.

구조

이 아키텍처는 Kubernetes 클러스터에 대한 DR(재해 복구) 시스템의 토폴로지를 보여줍니다.

기본 데이터베이스에 상주하는 모든 런타임, 구성 및 메타데이터 정보는 Oracle Autonomous Data Guard를 통해 지역 1에서 지역 2로 복제됩니다. 필요한 Kubernetes 클러스터 구성은 제어 플레인 보호를 위해 etcd 스냅샷을 통해 복제됩니다. 애플리케이션별 구성 보호를 위해 etcd 복사본 또는 아티팩트 스냅샷을 사용할 수 있습니다. 자세한 내용은 아티팩트 스냅샷을 사용하여 Kubernetes 클러스터를 재해로부터 보호하십시오. 컨테이너에서 사용하는 이미지는 각 클러스터 또는 외부 저장소에 있는 레지스트리에서 호스트됩니다(이미지는 자체적으로 Kubernetes 클러스터 구성으로 간주되지 않음).

참고:

런타임 데이터베이스에 대한 Oracle Autonomous Data Guard 설정은 이 문서의 범위를 벗어납니다.
kubernetes-etcd-multiregion-dr.png에 대한 설명은 다음과 같습니다.
그림 kubernetes-etcd-multiregion-dr.png에 대한 설명

쿠버네티스-etcd-multiregion-dr-oracle.zip

이 구조는 다음 구성 요소를 지원합니다.

  • 지역

    Oracle Cloud Infrastructure 리전은 가용성 도메인이라는 하나 이상의 데이터 센터를 포함하는 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며 방대한 거리로 구분할 수 있습니다(국가 또는 대륙).

  • 로드 밸런서

    Oracle Cloud Infrastructure Load Balancing 서비스는 단일 시작점에서 백엔드의 다중 서버로 트래픽을 자동으로 배포합니다.

  • DRG(동적 경로 지정 게이트웨이)

    DRG는 동일한 지역의 VCN과 지역 외부의 네트워크(예: 다른 Oracle Cloud Infrastructure 지역의 VCN, 온프레미스 네트워크 또는 다른 클라우드 공급자의 네트워크) 간에 전용 네트워크 트래픽 경로를 제공하는 가상 라우터입니다.

  • Data Guard

    Oracle Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to remain available without interruption. Oracle Data Guard는 이러한 standby database를 운용 중인 데이터베이스의 복사본으로 유지 관리합니다. 그런 다음 계획된 운용중단이나 계획되지 않은 운용중단으로 인해 운용 중인 데이터베이스를 사용할 수 없게 되면 Oracle Data Guard는 모든 standby database를 운용 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다.

  • Oracle Real Application Clusters (Oracle RAC)

    Oracle RAC를 사용하면 여러 서버에서 단일 Oracle Database를 실행하여 공유 스토리지에 액세스하는 동안 가용성을 극대화하고 수평 확장성을 구현할 수 있습니다. Oracle RAC 인스턴스에 연결하는 유저 세션은 일반 유저 응용 프로그램을 변경하지 않고도 정전 시 변경 사항을 복구하고 안전하게 리플레이할 수 있습니다.

  • 컨테이너 레지스트리

    Oracle Cloud Infrastructure Registry는 개발-운영 워크플로우를 간소화할 수 있는 Oracle 관리 레지스트리입니다. 레지스트리를 사용하면 개발 아티팩트 및 이미지를 쉽게 저장, 공유 및 관리할 수 있습니다. Oracle Cloud Infrastructure의 고가용성 및 확장성 아키텍처를 통해 애플리케이션을 안정적으로 배포하고 관리할 수 있습니다.

  • Kubernetes용 컨테이너 엔진

    Oracle Cloud Infrastructure Container Engine for Kubernetes는 컨테이너화된 애플리케이션을 클라우드에 배포하는 데 사용할 수 있는 확장 가능한 고가용성 완전 관리형 서비스입니다. 애플리케이션에 필요한 컴퓨트 리소스를 지정하면 Container Engine for Kubernetes가 기존 테넌시의 Oracle Cloud Infrastructure에서 프로비저닝합니다. Container Engine for Kubernetes는 Kubernetes를 사용하여 호스트 클러스터 전반에서 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화합니다.

  • Kubernetes 클러스터

    Kubernetes 클러스터는 컨테이너화된 애플리케이션을 실행하는 머신 세트입니다. Kubernetes는 해당 노드에서 컨테이너화된 워크로드 및 서비스를 관리할 수 있는 이식 가능한 확장 가능한 오픈 소스 플랫폼을 제공합니다. Kubernetes 클러스터는 작업자 노드 및 제어 플레인 노드로 구성됩니다.

  • Kubernetes 제어 플레인
    Kubernetes 제어 플레인은 Kubernetes 클러스터 내의 작업자 노드 및 포드에 대한 리소스를 관리합니다. 제어 플레인 구성 요소는 이벤트를 감지 및 응답하고, 일정을 수행하고, 클러스터 리소스를 이동합니다. 다음은 제어 평면 구성요소입니다.
    • kube-apiserver: Kubernetes API 서버를 실행합니다.
    • etcd: 모든 클러스터 데이터에 대해 분산된 키-값 저장소
    • kube-scheduler: 지정되지 않은 새 POD를 실행할 노드를 결정합니다.
    • kube-controller-manager: 컨트롤러 프로세스를 실행합니다.
    • cloud-controller-manager: 클라우드별 API를 사용하여 클러스터를 연결합니다.
  • Kubernetes 작업자 노드

    Kubernetes 작업자 노드는 Kubernetes 클러스터 내에서 컨테이너화된 애플리케이션을 실행하는 작업자 시스템입니다. 모든 클러스터에는 하나 이상의 워커 노드가 있습니다.

  • 수신 컨트롤러

    수신 컨트롤러는 Kubernetes 클러스터에서 실행되며 수신 리소스를 관리하는 구성요소입니다. 외부 네트워크에서 트래픽을 수신하여 올바른 서비스로 라우팅하고 로드 밸런싱 및 SSL 종료를 수행합니다. 수신 컨트롤러는 일반적으로 클러스터에서 별도의 Pod로 실행되며 관리하는 서비스와 독립적으로 크기를 조정할 수 있습니다.

  • KUBE-엔드포인트 API

    KUBE-Endpoint API는 Kubernetes 제어 플레인의 kube-apiserver 구성요소입니다. Kubernetes API 서버를 실행합니다.

  • ETCD 백업

    ETCD 백업은 Kubernetes 제어 플레인의 etcd 구성 요소의 백업입니다. etcd에는 모든 클러스터 데이터에 대한 분산 키-값 저장소가 포함됩니다. 재해 복구를 위해 Kubernetes 클러스터를 복구하기 위해 ETCD 백업을 생성하는 것이 중요합니다.

  • YAML 스냅샷

    YAML 스냅샷은 Kubernetes 클러스터의 아티팩트 정의를 포함하는 (yaml) 파일의 적시 복사본입니다. 스냅샷은 동일하거나 다른 Kubernetes 클러스터에서 해당 아티팩트를 복원하는 데 사용할 수 있는 tar 파일입니다.

Kubernetes 재해 보호를 위한 고려 사항

Kubernetes에 대한 재해 보호를 구현하는 경우 다음 사항을 고려하십시오.

  • 대칭 재해 복구(DR): Oracle은 기본 및 보조에서 동일한 리소스 용량과 구성을 사용할 것을 권장합니다. 두 지역의 Kubernetes 클러스터에는 작업자 노드 수(및 해당 하드웨어 용량) 및 기타 인프라(공유 스토리지, 로드 밸런서, 데이터베이스 등)와 같은 유사한 리소스를 사용할 수 있어야 합니다. 보조 영역에서 Kubernetes 클러스터가 종속되는 리소스는 기본과 동일한 워크로드를 따라갈 수 있어야 합니다. 또한 두 시스템은 복원된 시스템이 의존하는 것과 동일한 서비스와 동일하게 작동해야 하며, 측면 자동차, 구성 맵(CM)을 두 위치에서 모두 사용해야 합니다.
  • 호스트 이름 별칭 및 가상화: 보조 사이트의 노드에서 사용하는 호스트 이름을 계획하는 것이 중요합니다. 기본 Kubernetes 클러스터에서 etcd 스냅샷을 복원하기 전에 제어 플레인 및 워커 노드의 호스트 이름 또는 별칭 호스트 이름은 보조 위치에서 "활성"이어야 합니다. 노드 이름은 Kubernetes 클러스터의 다른 아티팩트에 저장되어 작업자 노드를 식별하고, Pod 할당을 표시하며, 클러스터 자체를 설명하는 구성(구성) 맵과 여러 구성 파일 및 항목에 저장됩니다. 보조 위치는 기본 Kubernetes 클러스터에서 사용된 호스트 이름이 동일한 작업자, 제어 플레인 및 프론트 엔드 kube-api 주소를 식별해야 합니다(정규화된 이름은 도메인 이름에서 다를 수 있지만 호스트 이름은 동일해야 함). 호스트 이름 별칭을 지정하지 않으면 etcd 스냅샷 복원이 제대로 작동하지 않습니다. Kubelet, 스케줄러, 컨트롤러 및 일반적으로 제어 플레인 서비스는 복제된 구성에 사용되는 적합한 끝점 및 호스트에 연결할 수 없기 때문입니다. IP를 사용하여 Kubernetes에서 노드를 식별하지 마십시오. 항상 대신 호스트 이름을 사용하십시오.
  • 컨테이너 이미지가 바이너리와 유사한 패러다임을 제공합니다.: Kubernetes 구성만큼 이미지가 자주 변경되지 않을 수 있으며 모든 Kubernetes 클러스터 복제로 이미지를 업데이트할 필요가 없습니다. 기본 시스템에서 사용하는 이미지는 보조 시스템에 사용된 이미지와 동일해야 합니다. 그렇지 않으면 불일치 및 오류가 발생할 수 있습니다. 그러나 이미지 복제는 이 플레이북의 범위를 벗어납니다. 다음과 같은 여러 전략을 사용하여 두 위치 간에 이미지를 일관되게 사용할 수 있습니다.
    • 이미지를 기본 노드에 저장하고 보조 작업자 노드에 로드합니다. 이 접근 방식은 구현하기가 매우 쉽지만 관리 오버헤드가 발생합니다. 컨테이너 레지스트리를 사용하면 상당한 이점이 있으며 이미지를 로컬로 저장하면 버전 및 업데이트 관리가 더 어려워집니다.
    • 이미지는 기본 및 대기 데이터베이스에서 사용되는 것과 다른 지역 또는 데이터 센터에 완전히 외부 컨테이너 레지스트리에 상주할 수 있습니다. 외부 제품 및 라이브러리는 타사에서 유지 관리하며 일반적으로 릴리스에서 암시적으로 사용할 수 있습니다.
    • 이미지는 기본 및 대기에 있는 컨테이너 레지스트리에 상주할 수 있습니다. 각 영역은 새 버전의 이미지가 릴리스될 때 병렬로 업데이트됩니다. 이렇게 하면 사용되는 소프트웨어를 보다 효과적으로 제어할 수 있지만 관리 오버헤드가 증가합니다. 두 개의 서로 다른 레지스트리에 액세스하려면 이미지를 복제하고 인증서를 관리해야 합니다. CI/CD 도구는 일반적으로 이 접근 방식에 사용됩니다.

이 솔루션 플레이북은 kubeadm 툴을 사용하여 생성된 Kubernetes 클러스터를 사용하는 예를 보여줍니다. 권장사항은 온프레미스 시스템에 설치된 사용자정의 Kubernetes 클러스터에 일반적이지만 대부분의 스크립트는 kubeadm 툴로 생성되지 않는 클러스터를 수정해야 할 수 있습니다. 동일한 etcd 및 Kubernetes 버전을 실행하는 Kubernetes 클러스터 간에 제공되는 단계 및 스크립트를 사용해야 합니다. 서로 다른 Kubernetes 버전 간에 etcd 스냅샷을 복원하면 불일치가 발생하고 etcd 클러스터가 불안정해질 수 있습니다.

필수 제품 및 역할 정보

이 솔루션을 사용하려면 다음과 같은 제품과 역할이 필요합니다.

  • Kubernetes 클러스터
  • Kubernetes 시스템을 관리할 수 있는 배스천은 클러스터의 etcd 끝점에 액세스하고 ssh를 사용하여 다른 제어 플레인 노드에 액세스할 수 있습니다.
  • (선택 사항) Oracle Cloud Infrastructure(OCI)

    이 플레이북은 기본 및 보조 지역에 OCI 리전 및 리소스 사용을 기반으로 합니다. 그러나 이 솔루션은 온프레미스에 위치한 Kubernetes 클러스터에도 적용됩니다.

각 서비스에 필요한 역할입니다.

서비스 이름: 역할 다음에 필요...
Kubernetes 클러스터(기본): administrator 모든 스크립트를 실행합니다.
Kubernetes(기본) 노드: 루트에 대한 sudo 권한을 가진 사용자

다음 스크립트 실행:

  • maak8s-force-stop-cp.sh
  • maak8-etcd-backup.sh
  • maak8-etcd-restore.sh
Kubernetes 클러스터(보조): administrator 모든 스크립트를 실행합니다.
Kubernetes(보조) 노드: 루트에 대한 sudo 권한을 가진 사용자 다음 스크립트 실행:
  • maak8s-force-stop-cp.sh
  • maak8-etcd-backup.sh
  • maak8-etcd-restore.sh

필요한 것을 얻으려면 Oracle 제품, 솔루션 및 서비스를 참조하십시오.