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) 패러다임을 제공합니다. 운영 리전에서 재해로 인해 다운타임이 발생하는 경우 워크로드를 재개할 수 있는 보조 위치에 운영 시스템의 일관되고 "가능한 최신" 복사본을 유지 관리해야 합니다.

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

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

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

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

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

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

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

시작하기 전에

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

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

애플리케이션별 구성 보호를 위한 아티팩트 스냅샷 사용에 대한 자세한 내용은 아티팩트 스냅샷을 사용하여 OCI Kubernetes 엔진 클러스터를 재해로부터 보호를 참조하십시오.

구조

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

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

주:

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

쿠버네티스-etcd-멀티레기온-dr-oracle.zip

이 아키텍처는 다음 구성 요소를 지원합니다.

  • 지역

    Oracle Cloud Infrastructure 리전은 가용성 도메인이라고 하는 데이터 센터가 하나 이상 포함된 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 먼 거리가 그들을 분리 할 수 있습니다 (국가 또는 대륙에 걸쳐).

  • 로드 밸런서

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

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

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

  • Data Guard

    Oracle Data Guard and Oracle Active Data Guard provide a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases and that enable production Oracle databases to remain available without interruption. Oracle Data Guard는 인메모리 복제를 사용하여 이러한 대기 데이터베이스를 운영 데이터베이스의 복사본으로 유지 관리합니다. 계획되거나 계획되지 않은 운용중단으로 인해 운용 중인 데이터베이스를 사용할 수 없게 되면 Oracle Data Guard에서 대기 데이터베이스를 운용 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다. Oracle Active Data Guard는 읽기 대부분 작업 로드를 대기 데이터베이스로 오프로드하는 추가 기능을 제공하며 고급 데이터 보호 기능도 제공합니다.

  • Oracle RAC(Oracle Real Application Clusters)

    Oracle RAC를 사용하면 여러 서버에서 단일 Oracle Database를 실행하여 가용성을 극대화하고 수평 확장성을 지원하는 동시에 공유 스토리지에 액세스할 수 있습니다. Oracle RAC 인스턴스에 접속하는 사용자 세션은 일반 사용자 응용 프로그램을 변경하지 않고 장애 조치 중 변경 사항을 안전하게 복구하고 재생할 수 있습니다.

  • 레지스트리

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

  • Kubernetes Engine

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

  • Kubernetes 클러스터

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

  • Kubernetes 제어 플레인
    Kubernetes 제어 평면은 Kubernetes 클러스터 내 작업자 노드 및 POD에 대한 리소스를 관리합니다. 제어 플레인 구성 요소는 이벤트를 감지 및 응답하고, 일정을 잡고, 클러스터 리소스를 이동합니다. 제어 평면 구성요소는 다음과 같습니다.
    • 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 할당을 표시하기 위해 클러스터 자체를 설명하는 구성(config) 맵과 여러 구성 파일 및 항목에 저장됩니다. 보조 위치는 기본 Kubernetes 클러스터에서 사용된 호스트 이름이 동일한 작업자, 제어 플레인 및 프론트 엔드 kube-api 주소를 식별해야 합니다(전체 이름은 도메인 이름마다 다를 수 있지만 호스트 이름은 동일해야 함). 호스트 이름 별칭을 지정하지 않으면 kubelet, 스케줄러, 컨트롤러 및 일반적으로 제어 플레인 서비스가 복제된 구성에서 사용되는 적절한 끝점 및 호스트에 연결할 수 없으므로 etcd 스냅샷 복원이 제대로 작동하지 않습니다. Kubernetes에서 노드를 식별하기 위해 IP 주소를 사용하지 마십시오. 대신 호스트 이름을 항상 사용하십시오.
  • 이미지가 바이너리와 유사한 패러다임을 나타냄: 이미지는 Kubernetes 구성만큼 자주 변경되지 않을 수 있으며 모든 Kubernetes 클러스터 복제로 이미지를 업데이트할 필요가 없습니다. 기본 시스템에서 사용하는 이미지는 보조 시스템에서 사용되는 이미지와 동일해야 합니다. 그렇지 않으면 불일치 및 오류가 발생할 수 있습니다. 그러나 이미지 복제는 이 플레이북의 범위를 벗어납니다. 다음을 포함하여 두 위치 간에 이미지를 일관되게 사용하는 데 사용할 수 있는 여러 전략이 있습니다.
    • 이미지를 기본 노드에 저장하고 보조 워커 노드에 로드합니다. 이 접근 방식은 구현하기가 매우 쉽지만 관리 오버헤드가 발생합니다. 컨테이너 레지스트리를 사용하면 상당한 이점이 있으며 이미지를 로컬로 저장하면 버전 및 업데이트를 관리하기가 더 어려워집니다.
    • 이미지는 기본 및 대기에서 사용되는 영역 또는 데이터 센터의 다른 영역에 있는 완전히 외부 컨테이너 레지스트리에 상주할 수 있습니다. 외부 제품 및 라이브러리는 타사에서 유지 관리하며 일반적으로 릴리스에서 가용성이 암시적입니다.
    • 이미지는 기본 및 대기 위치에 있는 컨테이너 레지스트리에 상주할 수 있습니다. 각 영역은 새 버전의 이미지가 릴리스될 때 병렬로 업데이트됩니다. 따라서 사용되는 소프트웨어를 보다 효과적으로 제어할 수 있지만 관리 오버헤드가 높아집니다. 서로 다른 두 레지스트리에 액세스하려면 이미지를 복제하고 인증서를 관리해야 합니다. CI/CD 도구는 일반적으로 이러한 접근 방식에 사용됩니다.
  • 기본 클러스터와 보조 클러스터의 차이점: 기본 및 보조 클러스터는 사용된 버전 및 구성 측면에서 서로의 복제본이 될 것으로 예상됩니다(일반적으로 DR 시스템의 경우). 특히 관련된 사항은 다음과 같습니다.
    1. Kubernetes 버전
    2. 컨테이너 런타임 및 컨테이너 런타임 버전
    3. 네트워크 플러그인 및 네트워크 플러그인 버전
    4. podSubnet 및 servicesubnet
    5. etcd hostpath 디렉토리 및 etcd 이미지 버전
    6. 네트워크 플러그인 및 DNS 이미지 버전
    7. 제어 플레인 포드의 이미지 저장소

    Kubernetes 버전의 사이트 간에 사소한 차이가 있는 재해 보호 구성이 작동할 수 있지만, 기본 etcd 스냅샷에서 복원한 후 클러스터가 불일치 상태로 남을 수 있습니다. 컨테이너 런타임 소켓, Kubernetes 버전 등에 대한 정보는 Kubernetes 자체에 저장됩니다. 예를 들어, cri-socket 정보는 사용 중인 컨테이너 런타임을 기반으로 하는 각 노드에만 적용되며 내부 구성 맵에 저장됩니다. kubeadm의 업그레이드에 사용되는 많은 정보는 kube-system 네임스페이스의 구성 맵을 기반으로 합니다. 따라서 기본 및 보조 모두 이러한 구성 맵에서 동일한 정보를 사용하는 것이 중요합니다. 이 명령을 사용하여 중요한 구성 맵의 모든 관련 정보를 yaml 파일의 기본 및 대기 모두에 저장할 수 있습니다. 

    [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

    마찬가지로 다음 명령을 사용하여 각 사이트에서 노드 구성을 복사할 수 있습니다.

    [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

이 솔루션 플레이북에서는 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 제품, 솔루션 및 서비스를 참조하십시오.