아티팩트 스냅샷을 사용하여 Kubernetes 클러스터를 재해로부터 보호

재해 발생 시 비즈니스 연속성을 보장하기 위해서는 데이터 보호를 제공하고 데이터 손실 및 생산성을 최소화하면서 대기 시스템으로 신속하게 전환할 수 있는 Kubernetes Cluster에서 실행되는 애플리케이션에 DR(재해 복구) 전략을 구현해야 합니다. Kubernetes 도입이 IT 시스템의 아키텍처에 의미하는 엄청난 변화에도 불구하고 Kubernetes 시스템은 유사한 DR 패러다임을 기존 애플리케이션(Oracle Java SE, Oracle Java EE 등)으로 제공합니다. 재해로 인해 기본 영역에서 작동 중지 시간이 발생할 경우 작업 로드를 재개할 수 있는 보조 위치에서 기본 시스템의 가능한 한 일관적이고 최신 복사본을 유지해야 합니다.

Oracle Maximum Availability Architecture(MAA)는 위치에 영향을 미치는 재해 시나리오에서 복구하고 복제본 사이트로 작업 로드를 강제로 재지정할 수 있는 권장 사항 및 유틸리티를 제공합니다. 이 설명서의 초점은 애플리케이션을 위한 Kubernetes 구성 복제입니다. Kubernetes 클러스터에서 실행되는 애플리케이션은 제어 플레인 노드, 작업자 노드, 로드 밸런서 및 스토리지를 포함하여 작동할 여러 구성요소에 따라 달라집니다. 동시에 Kubernetes에서 실행되는 애플리케이션에서 생성된 런타임 데이터는 기존 애플리케이션과 동일한 과제를 제시합니다. 런타임 애플리케이션은 지속 데이터를 생성, 읽기 및 업데이트할 수 있습니다. 이 솔루션 플레이북은 Kubernetes에서 실행되는 애플리케이션의 구성을 복제하기 위한 권장 사항을 제공합니다. 런타임 데이터의 재해 보호는 이 문서의 범위를 벗어나며 다음을 포함하여 애플리케이션 서버에서 실행되는 기존 애플리케이션과 동일한 방식으로 처리되어야 합니다.

• 다중 언어 지속성을 피합니다. BAC(Backup Availability Consistency) 이론에 따라 런타임 데이터에 대해 서로 다른 유형의 영구 저장소를 사용하면 문제를 해결할 수 없습니다.
• 가능한 한 종속성이 있는 모든 다양한 데이터 유형, 마이크로서비스 및 애플리케이션에 대해 단일 저장소를 사용합니다.
• 런타임 데이터에 대한 재해 보호는 Oracle Database에 대한 Oracle MAA 모범 사례를 참조하십시오.

또한 Kubernetes 클러스터 제어 영역을 보호해야 합니다. 적절한 etcd 스냅샷을 사용하여 손상, 오류를 방지하고 작동 중인 클러스터에 플래시백을 제공합니다. Oracle Maximum Availability는 재해로부터 제어 평면 보호를 위한 최적의 방법을 제공하지만 이 영역에서는 필요한 기술을 설명하기 위해 본 문서의 범위를 벗어납니다.

시작하기 전에

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

자세한 내용은 다음을 검토하십시오.

• Oracle WebLogic Server for Oracle Cloud Infrastructure 재해 복구
• Oracle Cloud Infrastructure Marketplace 재해 복구 기반의 SOA Suite

구조

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

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

참고:

런타임 데이터베이스에 대한 Oracle Autonomous Data Guard 설정은 이 문서의 범위를 벗어납니다.

그림 kubernetes-multiregion-dr.png에 대한 설명

kubernetes-multiregion-dr-oracle.zip

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

• 지역

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

• 로드 밸런서

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

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

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

• Data Guard

  {\f2732 Oracle Data Guard}는 하나 이상의{\f2732 standby database}를 생성{\f2732 , }유지{\f2732 , }관리 및 모니터하여 운용 중인{\f2732 Oracle }데이터베이스를 중단 없이 계속 사용할 수 있도록 하는 종합적인 서비스 집합을 제공합니다{\f2732 .} 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 클러스터 내에서 컨테이너화된 애플리케이션을 실행하는 작업자 시스템입니다. 모든 클러스터에는 하나 이상의 작업자 노드가 있습니다.

• Kubernetes 제어 플레인
  Kubernetes 제어 평면은 Kubernetes 클러스터 내의 작업자 노드 및 POD에 대한 리소스를 관리합니다. 제어 평면 구성요소는 이벤트를 감지 및 응답하고, 일정 잡기를 수행하고, 클러스터 리소스를 이동합니다. 제어 평면 구성요소는 다음과 같습니다.

  • kube-apiserver: Kubernetes API 서버를 실행합니다.
  • etcd: 모든 클러스터 데이터에 대한 분산 키-값 저장소입니다.
  • kube-scheduler: 지정되지 않은 새 POD를 실행할 노드를 결정합니다.
  • kube-controller-manager: 컨트롤러 프로세스를 실행합니다.
  • cloud-controller-manager: 클라우드별 API로 클러스터를 연결합니다.
• 수신 컨트롤러

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

• KUBE-Endpoint 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 구성만큼 자주 변경되지 않으며 모든 Kubernetes 클러스터 복제로 이미지를 업데이트할 필요가 없습니다. 기본 시스템에서 사용하는 이미지는 보조 시스템에 사용된 이미지와 동일해야 합니다. 그렇지 않으면 불일치가 발생할 수 있습니다. 그러나 이미지 복제는 이 플레이북의 범위를 벗어납니다. 다음을 포함하여 두 위치 간에 일관된 이미지 사용을 유지하는 데 사용할 수 있는 여러 전략이 있습니다.
  • 이미지를 기본 노드에 저장하고 보조 워커 노드에 로드합니다. 이 접근 방식은 구현하기 매우 쉽지만 관리 오버헤드가 발생합니다. 컨테이너 레지스트리를 사용하면 상당한 이점이 있으며 로컬에서 이미지를 저장하면 버전 및 업데이트를 관리하기가 더 어렵습니다.
  • 이미지는 기본 및 대기에서 사용하는 것과 다른 지역 또는 데이터 센터의 완전히 외부 컨테이너 레지스트리에 상주할 수 있습니다. 외부 제품 및 라이브러리는 제3자에 의해 유지 관리되며 해당 가용성은 일반적으로 릴리스에서 암시적입니다.
  • 이미지는 기본 및 대기에 있는 컨테이너 레지스트리에 상주할 수 있습니다. 각 영역은 새 버전의 이미지가 릴리스될 때 병렬로 업데이트됩니다. 따라서 사용되는 소프트웨어를 보다 효과적으로 제어할 수 있지만 관리 오버헤드가 높아집니다. 이미지를 복제하고 자격 증명을 관리하여 서로 다른 두 레지스트리에 액세스해야 합니다. CI/CD 도구는 일반적으로 이 접근 방식에 사용됩니다.

이 플레이북은 Oracle Cloud Infrastructure를 사용하는 예를 제공하지만, 권장 사항은 온프레미스 시스템에 설치된 커스텀 Kubernetes 클러스터에 일반적입니다. OKE(Oracle Cloud Infrastructure Container Engine for Kubernetes)에서 실행되는 기본 Kubernetes 클러스터와 온프레미스 또는 커스텀 Kubernetes 클러스터에서 실행되는 보조 클러스터 간에 제공되는 단계 및 스크립트를 사용할 수 있습니다. 또한 OKE에서 실행되는 기본 Kubernetes 클러스터와 OKE에서도 실행되는 보조 클러스터 또는 두 개의 온프레미스 또는 사용자정의 Kubernetes 클러스터 간에 단계와 스크립트를 사용할 수 있습니다.

필수 제품 및 역할 정보

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

• Kubernetes 클러스터
• kubernetes 시스템을 관리할 수 있는 배스천 노드
• Oracle Cloud Infrastructure(OCI)

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

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

서비스 이름: 역할	다음에 필요...
Oracle Cloud Infrastructure(OCI): admin	하나 이상의 OCI 리전을 사용하는 경우 리소스와 서비스를 프로비저닝하고 설정합니다.
Kubernetes 클러스터(기본): administrator	모든 스크립트를 실행합니다.
Kubernetes(기본) 노드: 실행 권한이 있는 OS 사용자 및 보조에 대한 SSH 권한	다음 스크립트 실행: maak8-get-all-artifacts.sh maak8DR-apply.sh
Kubernetes 클러스터(보조): administrator	모든 스크립트를 실행합니다.
Kubernetes(보조) 노드: 실행 권한이 있는 OS 사용자	다음 스크립트 실행: removeyamlblock.sh apply-artifacts.sh maak8-push-all-artifacts.sh

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

로그 변경

이 로그에는 중요한 변경 사항이 나열됩니다.

2023년 7월 12일

구조 다이어그램이 개정되었습니다. 콘텐츠가 향상되었습니다.