AKS 클러스터의 파란색-녹색 배포

AKS(Azure Kubernetes Service)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

이 문서에서는 현재 버전을 계속 실행하면서 AKS(Azure Kubernetes Service) 클러스터의 새 버전을 테스트하는 청록색 배포 전략을 구현하는 방법에 대한 지침을 제공합니다. 새 버전의 유효성이 검사되면 라우팅 변경이 사용자 트래픽을 새 버전으로 전환합니다. 이러한 방식으로 배포하면 업그레이드를 포함하여 AKS 클러스터를 변경할 때 가용성이 높아집니다. 이 문서에서는 Azure 관리되는 서비스 및 네이티브 Kubernetes 기능을 사용하는 AKS의 파란색-녹색 배포 디자인 및 구현에 대해 설명합니다.

아키텍처

이 섹션에서는 AKS 클러스터의 파란색-녹색 배포를 위한 아키텍처에 대해 설명합니다. 다음 두 가지 경우가 있습니다.

애플리케이션과 API가 공용 연결입니다.
애플리케이션과 API가 프라이빗 연결입니다.

여기에서 논의되지 않은 하이브리드 사례도 있는데, 여기에는 클러스터에 공용 연결 및 프라이빗 연결 애플리케이션과 API가 혼합되어 있습니다.

다음 다이어그램은 공용 연결 사례의 아키텍처를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

Azure Front Door 및 Azure DNS는 파란색 클러스터와 녹색 클러스터 간에 트래픽을 전환하는 라우팅 메커니즘을 제공합니다. 자세한 내용은 Azure Front Door를 사용한 파란색-녹색 배포를 참조하세요. Azure Front Door를 사용하면 전체 스위치 또는 가중치를 기반으로 하는 보다 제어된 스위치를 구현할 수 있습니다. 이 기술은 Azure 환경에서 가장 안정적이고 효율적입니다. 자체 DNS 및 부하 분산 장치를 사용하려면 안전하고 신뢰할 수 있는 스위치를 제공하도록 구성되어 있는지 확인해야 합니다.

Azure Application Gateway는 공용 엔드포인트 전용 프런트 엔드를 제공합니다.

이 다이어그램은 프라이빗 연결 사례용입니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

이 경우 단일 Azure DNS 인스턴스는 파란색 클러스터와 녹색 클러스터 간의 트래픽 전환을 구현합니다. 이는 A 및 CNAME 레코드를 사용하여 수행됩니다. 자세한 내용은 T3: 트래픽을 녹색 클러스터로 전환 섹션을 참조하세요.

Application Gateway는 프라이빗 엔드포인트 전용 프런트 엔드를 제공합니다.

워크플로

파란색-녹색 배포에는 클러스터의 현재 버전을 새 버전으로 업데이트하는 5단계가 있습니다. 설명에서 파란색 클러스터는 현재 버전이고 녹색 클러스터는 새 버전입니다.

단계는 다음과 같습니다.

T0: 파란색 클러스터가 켜져 있습니다.
T1: 녹색 클러스터를 배포합니다.
T2: 파란색 클러스터와 녹색 클러스터 간에 Kubernetes 상태를 동기화합니다.
T3: 트래픽을 녹색 클러스터로 전환합니다.
T4: 파란색 클러스터를 제거합니다.

새 버전이 출시되면 다음에 오는 모든 변경 내용 또는 업데이트에 대한 파란색 클러스터가 됩니다.

파란색 및 녹색 클러스터는 동시에 실행되지만 제한된 시간 동안만 실행되므로 비용과 운영 활동이 최적화됩니다.

전환 트리거

단계에서 단계로 전환하는 트리거를 자동화할 수 있습니다. 이 작업이 달성될 때까지 일부 또는 전부는 수동입니다. 트리거는 다음과 관련이 있습니다.

특정 워크로드 메트릭, SLO(서비스 수준 목표) 및 SLA(서비스 수준 계약): 트래픽을 전환하기 전에 AKS 클러스터의 전체 상태의 유효성을 검사하기 위해 T3 단계에서 주로 사용됩니다.
Azure 플랫폼 메트릭: 워크로드 및 AKS 클러스터의 상태를 평가하는 데 사용됩니다. 모든 전환에 사용됩니다.

클러스터의 네트워크 검색 가능성

다음과 같은 방법으로 클러스터에 대한 네트워크 검색 기능을 제공할 수 있습니다.

클러스터를 가리키는 DNS 레코드가 있습니다. 예시:
- aks-blue.contoso.com 는 파란색 클러스터의 개인 또는 공용 IP를 가리킵니다.
- aks-green.contoso.com 는 녹색 클러스터의 개인 또는 공용 IP를 가리킵니다.
그런 다음 이러한 호스트 이름을 직접 사용하거나 각 클러스터 앞에 있는 애플리케이션 게이트웨이의 백 엔드 풀 구성에서 사용할 수 있습니다.
애플리케이션 게이트웨이를 가리키는 DNS 레코드가 있습니다. 예시:
- aks-blue.contoso.com 는 청색 클러스터의 프라이빗 또는 공용 IP를 백 엔드 풀로 포함하는 애플리케이션 게이트웨이의 개인 또는 공용 IP를 가리킵니다.
- aks-green.contoso.com 는 녹색 클러스터의 프라이빗 또는 공용 IP를 백 엔드 풀로 사용하는 애플리케이션 게이트웨이의 개인 또는 공용 IP를 가리킵니다.

T0: 파란색 클러스터가 켜져 있습니다.

초기 단계인 T0은 파란색 클러스터가 활성 상태인 것입니다. 이 단계에서는 배포를 위해 클러스터의 새 버전을 준비합니다.

T1 단계의 트리거 조건은 클러스터의 새 버전인 녹색 클러스터의 릴리스입니다.

T1: 녹색 클러스터 배포

이 단계에서는 새 친환경 클러스터의 배포를 시작합니다. 파란색 클러스터는 계속 켜져 있고 라이브 트래픽은 여전히 이 클러스터로 라우팅됩니다.

T2 단계로 이동하는 트리거는 플랫폼 수준에서 녹색 AKS 클러스터의 유효성 검사입니다. 유효성 검사는 Azure Monitor 메트릭 및 CLI 명령을 사용하여 배포 상태의 유효성을 검사합니다. 자세한 내용은 Monitor로 AKS(Azure Kubernetes Service) 모니터링 및 AKS 데이터 참조 모니터링을 참조하세요.

AKS 모니터링은 다음 다이어그램과 같이 여러 수준으로 나눌 수 있습니다.

클러스터의 상태는 수준 1 및 2와 일부 수준 3에서 평가됩니다. 수준 1의 경우 Monitor의 네이티브 다중 클러스터 보기를 사용하여 다음과 같이 상태의 유효성을 검사할 수 있습니다.

수준 2에서 Kubernetes API 서버와 Kubelet이 제대로 작동하는지 확인합니다. Monitor에서 Kubelet 통합 문서, 특히 노드의 주요 운영 통계를 표시하는 통합 문서의 두 그리드를 사용할 수 있습니다.

노드당 개요 그리드는 각 노드에 대한 백분율 및 추세별로 총 작업, 총 오류 및 성공한 작업을 요약해서 보여 줍니다.
작업 유형별 개요 그리드는 각 작업 유형에 대해 작업, 오류 및 성공한 작업의 수를 백분율 및 추세로 제공합니다.

수준 3은 omsagent, kube-proxy 등과 같이 AKS에 기본적으로 배포되는 Kubernetes 개체 및 애플리케이션 전용입니다. 이 확인을 위해 Monitor의 인사이트 보기를 사용하여 AKS 배포의 상태를 확인할 수 있습니다.

또는 Container Insights를 사용하여 배포 및 HPA 메트릭에 설명된 전용 통합 문서를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

유효성 검사가 성공하면 T2 단계로 전환할 수 있습니다.

T2: 파란색 클러스터와 녹색 클러스터 간에 Kubernetes 상태 동기화

이 단계에서 애플리케이션, 운영자 및 Kubernetes 리소스는 아직 녹색 클러스터에 배포되지 않았거나 AKS 클러스터가 프로비전될 때 해당 리소스를 적용하고 배포할 수 있는 것은 아닙니다. 이 단계의 궁극적인 목표는 동기화가 끝날 때 녹색 클러스터가 파란색 클러스터의 이전 버전과 호환되는 것입니다. 그렇다면 트래픽을 녹색 클러스터로 전환하기 전에 새 클러스터의 상태의 유효성을 검사할 수 있습니다.

클러스터 간에 Kubernetes 상태를 동기화하는 다양한 방법이 있습니다.

CI/CD(연속 통합 및 지속적인 업데이트)를 통한 재배치. 일반적으로 앱의 일반 배포에 사용되는 것과 동일한 CI/CD 파이프라인을 사용하면 충분합니다. 이를 위한 일반적인 도구는 GitHub Actions, Azure DevOps 및 Jenkins입니다.
Flux 및 ArgoCD와 같이 CNCF(Cloud Native Computing Foundation) 웹 사이트에서 승격되는 솔루션을 갖춘 GitOps.
Kubernetes 구성 및 리소스를 데이터 저장소에 저장하는 사용자 지정 솔루션. 일반적으로 이러한 솔루션은 메타데이터 정의에서 시작한 다음 생성된 Kubernetes 매니페스트를 Azure Cosmos DB와 같은 데이터 저장소에 저장하는 Kubernetes 매니페스트 생성기를 기반으로 합니다. 이들은 일반적으로 사용 중인 애플리케이션 설명 프레임워크를 기반으로 하는 사용자 지정 솔루션입니다.

다음 다이어그램은 Kubernetes 상태를 동기화하는 프로세스를 보여 줍니다.

일반적으로 동기화 중에는 새 버전의 애플리케이션 배포가 라이브 클러스터에서 허용되지 않습니다. 이 기간은 동기화와 함께 시작하여 녹색 클러스터로의 전환이 완료되면 완료됩니다. Kubernetes에서 배포를 사용하지 않도록 설정하는 방법은 다를 수 있습니다. 두 가지 가능한 솔루션은 다음과 같습니다.

배포 파이프라인을 사용하지 않도록 설정합니다.
배포를 실행하는 Kubernetes 서비스 계정을 사용하지 않도록 설정합니다.

OPA(Open Policy Agent)를 사용하여 서비스 계정 사용하지 않도록 설정을 자동화할 수 있습니다. AKS 네이티브 기능은 아직 미리 보기 상태이므로 아직 사용할 수 없습니다.

여러 클러스터에서 Kubernetes 상태를 관리하는 고급 메커니즘을 사용하여 동기화 기간을 피할 수 있습니다.

동기화가 완료되면 클러스터 및 애플리케이션의 유효성 검사가 필요합니다. 다음 내용이 포함됩니다.

클러스터의 상태의 유효성을 검사하기 위한 모니터링 및 로깅 플랫폼 유효성 검사. T1: 녹색 클러스터 배포 단계에서 수행하는 작업을 고려할 수 있습니다.
현재 사용 중인 도구 체인을 기반으로 하는 애플리케이션의 기능 테스트.

녹색 클러스터 애플리케이션의 성능을 성능 기준과 비교하기 위해 부하 테스트 세션도 실행하는 것이 좋습니다. 원하는 도구 또는 Azure Load Testing을 사용할 수 있습니다.

일반적으로 녹색 클러스터는 외부 사용자에게 표시되지 않는 내부 URL을 사용하여 애플리케이션 게이트웨이 또는 외부 부하 분산 장치에 노출됩니다.

새 클러스터의 유효성이 검사되면 다음 단계로 진행하여 트래픽을 새 클러스터로 전환할 수 있습니다.

T3: 녹색 클러스터로 트래픽 전환

동기화가 완료되고 녹색 클러스터가 플랫폼 및 애플리케이션 수준에서 유효성 검사되면 기본 클러스터로 승격되고 라이브 트래픽 수신을 시작할 준비가 된 것입니다. 전환은 네트워킹 수준에서 수행됩니다. 종종 워크로드는 상태 비저장입니다. 그러나 워크로드가 상태 저장인 경우 전환 중에 상태 및 캐싱을 유지하기 위해 추가 솔루션을 구현해야 합니다.

다음은 스위치가 적용된 후 대상 상태를 보여 주는 다이어그램입니다.

이 문서에서 설명하는 기술은 전체 스위치를 구현합니다. 트래픽의 100%가 새 클러스터로 라우팅됩니다. 이는 라우팅이 녹색 클러스터를 가리키도록 업데이트된 A 또는 CNAME 레코드 할당을 사용하여 DNS 수준에서 적용되고 각 클러스터에 대한 애플리케이션 게이트웨이가 있기 때문입니다.

다음은 프라이빗 연결 엔드포인트를 전환하기 위한 구성의 예입니다. 제안된 솔루션은 A 레코드를 사용하여 전환합니다. DNS 및 IP 매핑 관점에서 전환 전 상황은 다음과 같습니다.

A 레코드 aks.priv.contoso.com 는 파란색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.
A 레코드 aks-blue.priv.contoso.com 는 파란색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.
A 레코드 aks-green.priv.contoso.com 는 녹색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.

스위치는 다음과 같이 다시 구성됩니다.

A 레코드 aks.priv.contoso.com 는 녹색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.
A 레코드 aks-blue.priv.contoso.com 는 파란색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.
A 레코드 aks-green.priv.contoso.com 는 녹색 애플리케이션 게이트웨이의 개인 IP를 가리킵니다.

클러스터 사용자는 레코드의 TTL(Time To Live) 및 DNS 전파 후에 스위치를 보게 됩니다.

공용 연결 엔드포인트의 경우 권장되는 방식은 Azure Front Door 및 Azure DNS를 사용합니다. 스위치 이전의 구성은 다음과 같습니다.

CNAME 레코드 official-aks.contoso.com 는 자동 생성된 Azure Front Door 도메인의 레코드를 가리킵니다. 자세한 내용은 자습서: Front Door에 사용자 지정 도메인 추가를 참조하세요.
A 레코드 aks.contoso.com 는 파란색 애플리케이션 게이트웨이의 공용 IP를 가리킵니다.
Azure Front Door 원본 구성은 호스트 이름을 가리킵니다 aks.contoso.com . 백 엔드 풀 구성에 대한 자세한 내용은 Azure Front Door의 원본 및 원본 그룹을 참조하세요.
- A 레코드 aks-blue.contoso.com 는 파란색 애플리케이션 게이트웨이의 공용 IP를 가리킵니다.
- A 레코드 aks-green.contoso.com 는 녹색 애플리케이션 게이트웨이의 공용 IP를 가리킵니다.

스위치는 다음과 같이 다시 구성됩니다.

CNAME 레코드 official-aks.contoso.com 는 자동 생성된 Azure Front Door 도메인의 레코드를 가리킵니다.
A 녹색 애플리케이션 게이트웨이의 공용 IP를 가리키는 레코드 aks.contoso.com 입니다.
Azure Front Door 원본 구성은 호스트 이름을 가리킵니다 aks.contoso.com .
- A 레코드 aks-blue.contoso.com 는 파란색 애플리케이션 게이트웨이의 공용 IP를 가리킵니다.
- A 녹색 애플리케이션 게이트웨이의 공용 IP를 가리키는 레코드 aks-green.contoso.com 입니다.

Canary 릴리스의 부분 스위치와 같은 대체 전환 기술은 Azure Front Door 또는 Traffic Manager와 같은 추가 Azure 서비스를 사용하여 가능합니다. Azure Front Door 수준에서 파란색-녹색 트래픽 스위치를 구현하려면 Azure Front Door를 사용한 파란색-녹색 배포를 참조하세요.

예에 설명된 대로 네트워킹 관점에서 이 기술은 네 가지 호스트 이름의 정의를 기반으로 합니다.

공식 공용 호스트 이름: 최종 사용자와 소비자가 사용하는 공식 공용 호스트 이름입니다.
클러스터 호스트 이름: 클러스터에서 호스트되는 워크로드 소비자가 사용하는 공식 호스트 이름입니다.
파란색 클러스터 호스트 이름: 파란색 클러스터의 전용 호스트 이름입니다.
녹색 클러스터 호스트 이름: 녹색 클러스터의 전용 호스트 이름입니다.

클러스터 호스트 이름은 수신 트래픽을 관리하기 위해 애플리케이션 게이트웨이 수준에서 구성된 이름입니다. 호스트 이름은 또한 TLS(전송 계층 보안)를 적절하게 관리하기 위한 AKS 수신 구성의 일부입니다. 이 호스트는 라이브 트랜잭션 및 요청에만 사용됩니다.

Azure Front Door도 배포의 일부인 경우 공식 클러스터 호스트 이름만 관리하기 때문에 스위치의 영향을 받지 않습니다. 애플리케이션 사용자에게 적절한 추상화를 제공합니다. DNS CNAME 레코드는 항상 Azure Front Door를 가리키기 때문에 스위치의 영향을 받지 않습니다.

파란색 및 녹색 클러스터 호스트 이름은 주로 클러스터를 테스트하고 유효성 검사하는 데 사용됩니다. 이러한 목적을 위해 호스트 이름은 전용 엔드포인트가 있는 애플리케이션 게이트웨이 수준에서 노출되고 TLS를 적절하게 관리하기 위해 AKS 수신 컨트롤러 수준에서도 노출됩니다.

이 단계에서 유효성 검사는 인프라 및 앱 모니터링 메트릭과 공식 SLO 및 SLA(사용 가능한 경우)를 기반으로 합니다. 유효성 검사에 성공하면 마지막 단계로 전환하여 파란색 클러스터를 제거합니다.

T4: 파란색 클러스터 제거

트래픽을 성공적으로 전환하면 녹색 클러스터가 라이브 트래픽에서 예상대로 작동하는지 유효성을 검사하기 위해 여전히 유효성 검사 및 모니터링이 발생하는 마지막 단계로 이동합니다. 유효성 검사 및 모니터링은 플랫폼 및 애플리케이션 수준을 모두 다룹니다.

이 유효성 검사가 완료되면 파란색 클러스터를 제거할 수 있습니다. 폐기는 비용을 줄이고 Azure가 제공하는 탄력성, 특히 AKS를 적절하게 사용하기 위해 강력히 권장되는 단계입니다.

파란색 클러스터가 제거된 후의 상황은 다음과 같습니다.

구성 요소

Application Gateway 는 웹 애플리케이션에 대한 트래픽을 관리할 수 있는 웹 트래픽(OSI 계층 7) 부하 분산 장치입니다. 이 솔루션에서는 HTTP 트래픽이 AKS 클러스터에 액세스하기 위한 게이트웨이로 사용됩니다.
AKS(Azure Kubernetes Service) 는 컨테이너화된 애플리케이션을 배포하고 관리하는 데 사용할 수 있는 관리되는 Kubernetes 서비스입니다. 이 애플리케이션 플랫폼은 이 패턴의 주요 구성 요소입니다.
Azure Container Registry 는 컨테이너 이미지 및 관련 아티팩트를 저장하고 관리하는 데 사용되는 관리되는 서비스입니다. 이 솔루션에서는 AKS 클러스터에서 Helm 차트와 같은 컨테이너 이미지 및 아티팩트 저장 및 배포에 사용됩니다.
Azure Monitor 는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집, 분석 및 응답하기 위한 모니터링 솔루션입니다. 파란색 녹색 배포를 실행하는 데 필요한 핵심 모니터링 기능을 제공합니다. 이 아키텍처는 AKS와의 통합 및 스테이지 전환을 관리하는 데 사용할 수 있는 로깅, 모니터링 및 경고 기능을 제공하는 기능 때문에 사용됩니다.
Azure Key Vault 는 비밀 관리, 키 관리 및 인증서 관리 문제를 해결하는 데 도움이 되며, 이 솔루션에 대한 platfomr 및 애플리케이션 수준에서 필요한 비밀 및 인증서를 저장하고 관리하는 데 사용됩니다.
Azure Front Door 는 전역 부하 분산 장치 및 애플리케이션 엔드포인트 관리 시스템입니다. 이 솔루션은 AKS에서 호스트되는 HTTP 애플리케이션에 대한 퍼블릭 엔드포인트로 사용됩니다. 이 솔루션에서는 파란색과 녹색 애플리케이션 게이트웨이 간의 트래픽 스위치를 관리하는 중요한 책임이 있습니다.
Azure DNS 는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. 파란색 및 녹색 클러스터에 대한 솔루션에서 사용되는 호스트 이름을 관리하며, 특히 프라이빗 엔드포인트의 경우 트래픽 스위치에서 중요한 역할을 합니다.

대안

더 많은 제어를 제공할 수 있는 트래픽 스위치를 구현하기 위한 대체 기술이 있습니다. 예를 들어 다음 중 하나 이상을 기반으로 하는 트래픽 규칙을 사용하여 부분 전환을 수행할 수 있습니다.
- 수신 트래픽 비율
- HTTP 헤더
- 쿠키
변경으로 인해 발생하는 문제로부터 더 큰 보호를 제공하는 또 다른 대안은 링 기반 배포를 사용하는 것입니다. 파란색과 녹색 클러스터 대신 링이라고 하는 더 많은 클러스터를 가질 수 있습니다. 각 링은 새 버전의 AKS에 액세스할 수 있는 사용자 수에 맞게 충분히 큽니다. 여기에 설명된 파란색-녹색 배포의 경우 적절한 비용 최적화 및 제어를 위해 링을 제거할 수 있습니다.
Application Gateway에 대한 가능한 대안은 NGINX 및 HAProxy입니다.
Container Registry의 가능한 대안은 Harbor입니다.
경우에 따라 Azure Front Door 및 Azure DNS 대신 다른 부하 분산 및 DNS 서비스를 사용하여 트래픽 스위치를 수행할 수 있습니다.
이 솔루션은 표준 수신 컨트롤러 Kubernetes API를 기반으로 합니다. 게이트웨이 API 대신 솔루션이 도움이 된다면 컨테이너용 Application Gateway를 사용합니다. Application Gateway와 Pod 간의 부하 분산을 관리하고 수신 트래픽 관리를 처리하는 데 도움이 될 수 있습니다. 컨테이너용 Application Gateway는 애플리케이션 게이트웨이의 설정을 제어합니다.

시나리오 정보

솔루션의 주요 이점은 다음과 같습니다.

배포 중 가동 중지 시간을 최소화했습니다.
계획된 롤백 전략이 있습니다.
AKS 변경 내용 및 업그레이드를 릴리스하고 배포하는 동안 제어 및 작업이 개선되었습니다.
DR(재해 복구) 절차를 실행해야 하는지 테스트합니다.

파란색-녹색 배포의 주요 원칙과 기본 측면은 다음 문서에서 설명합니다.

자동화와 CI/CD의 관점에서 솔루션은 다양한 방식으로 구현될 수 있습니다. 다음을 권장합니다.

IaC용 Bicep 또는 Terraform.
CI/CD용 Azure Pipelines 또는 GitHub Actions.

잠재적인 사용 사례

파란색-녹색 배포를 사용하면 실행 중인 애플리케이션 및 워크로드에 영향을 주지 않고 클러스터를 변경할 수 있습니다. 변경 내용의 예는 다음과 같습니다.

운영상의 변화
새 AKS 기능 활성화
클러스터의 공유 리소스에 대한 변경 내용
Kubernetes 버전 업데이트
수신 게이트웨이, 서비스 메시, 운영자, 네트워크 정책 등과 같은 Kubernetes 리소스 및 개체 수정
클러스터에서 실행 중인 워크로드에 영향을 주지 않고 아직 배포된 AKS 클러스터의 이전 버전으로 롤백

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

파란색-녹색 배포는 제로 터치 배포와 같이 완전히 자동화될 수 있습니다. 일반적으로 초기 구현에는 단계를 활성화하는 수동 트리거가 있습니다. 그 과정에서 적절한 성숙도 및 모니터링 기능을 사용하여 트리거를 자동화할 수 있습니다. 이는 트리거를 자동화하기 위한 자동화된 테스트 및 특정 메트릭, SLA 및 SLO가 있음을 의미합니다.
파란색 및 녹색 클러스터에 전용 호스트 이름을 지정하고 클러스터 앞에 있는 게이트웨이 및 부하 분산 장치에 전용 엔드포인트 구성을 지정하는 것이 중요합니다. 이는 새 클러스터 배포의 안정성과 유효성을 개선하는 데 중요합니다. 이러한 방식으로 배포 유효성 검사는 표준 프로덕션 클러스터의 동일한 아키텍처 및 구성에서 발생합니다.
AKS 클러스터가 서로 다른 사업부에서 관리하는 여러 애플리케이션에 대한 공유 리소스인 상황을 고려합니다. 이러한 경우 AKS 플랫폼 자체는 클러스터의 전체 운영 및 수명 주기를 담당하는 전담 팀에서 관리하고 관리 및 운영 목적으로 클러스터에 엔드포인트가 있는 것이 일반적입니다. 문제를 적절하게 분리하고 안정성을 위해 이러한 엔드포인트에 AKS 클러스터에 전용 수신 컨트롤러가 있는 것이 좋습니다.
파란색-녹색 배포는 AKS 및 관련 워크로드에 대한 BC/DR(비즈니스 연속성 및 재해 복구) 솔루션을 구현하고 테스트하는 데 유용합니다. 특히 클러스터가 여러 지역에 분산되어 있는 경우를 포함하여 여러 클러스터를 관리하기 위한 기본 구조를 제공합니다.
파란색-녹색 배포의 성공은 자동화, 모니터링 및 유효성 검사와 같은 구현의 모든 측면을 AKS 플랫폼뿐만 아니라 플랫폼에 배포된 워크로드 및 앱에 적용하는 데 달려 있습니다. 이렇게 하면 파란색-녹색 배포의 이점을 최대한 활용할 수 있습니다.
제안된 솔루션에는 각 시나리오 퍼블릭 및 프라이빗당 2개의 Application Gateway가 있으므로 총 4개입니다. 이 결정은 게이트웨이의 잘못된 구성으로 인한 가동 중지 시간을 방지하기 위해 Azure 애플리케이션 게이트웨이 수준에서 파란색 녹색 배포를 적용하는 것입니다. 이 결정의 주요 단점은 4개의 Application Gateway 인스턴스가 있기 때문에 비용입니다. WAF 정책 또는 크기 조정 구성과 같은 Application Gateway 구성에 관련된 변경 내용이 있는 기간에만 병렬로 실행됩니다. 추가 비용 최적화를 위해 각 시나리오당 단일 Application Gateway를 선택할 수 있습니다. 즉, 총 두 개의 Application Gateway를 의미합니다. 이렇게 하려면 Azure Front Door 대신 파란색/녹색 논리를 애플리케이션 게이트웨이로 이동해야 합니다. 따라서 Azure Front Door가 명령적으로 제어되는 대신 Application Gateway가 있습니다.

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

파란색-녹색 배포는 AKS 플랫폼 및 워크로드의 가용성에 직접적이고 긍정적인 영향을 미칩니다. 특히 AKS 플랫폼 변경 내용을 배포하는 동안 가용성을 높입니다. 사용자 세션이 잘 관리되면 가동 중지 시간이 거의 없습니다.
파란색-녹색 배포는 기본적으로 새 클러스터 버전에서 문제가 발생하는 경우 AKS 클러스터의 이전 버전으로 롤백할 수 있는 옵션이 있기 때문에 배포 중에 안정성을 보장합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

파란색-녹색 배포는 클라우드에서 제공하는 네이티브 탄력성으로 인해 Azure에서 널리 채택됩니다. 이를 통해 운영 및 리소스 사용량 측면에서 비용을 최적화할 수 있습니다. 대부분의 절감 효과는 클러스터의 새 버전을 성공적으로 배포한 후 더 이상 필요하지 않은 클러스터를 제거함으로써 발생합니다.
새 버전이 배포되면 동일한 비용 기준을 유지하기 위해 동일한 서브넷에서 파란색 및 녹색 클러스터를 모두 호스트하는 것이 일반적입니다. 모든 네트워크 연결과 리소스 및 서비스에 대한 액세스는 두 클러스터에서 동일하며 모든 Azure 서비스 및 리소스는 동일하게 유지됩니다.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

적절하게 구현된 파란색-녹색 배포는 자동화, 지속적인 업데이트 및 탄력적인 배포를 제공합니다.
지속적인 업데이트의 주요 측면 중 하나는 플랫폼 및 워크로드 변경의 증가분을 반복적으로 배달한다는 것입니다. AKS의 파란색-녹색 배포를 사용하면 제어되고 안전한 방식으로 플랫폼 수준에서 지속적인 업데이트를 달성할 수 있습니다.
복원력은 이전 클러스터로 롤백하는 옵션이 포함되어 있기 때문에 파란색-녹색 배포의 기본입니다.
파란색-녹색 배포는 비즈니스 연속성 전략과 관련된 활동을 줄이기 위해 적절한 수준의 자동화를 제공합니다.
성공적인 구현을 위해서는 플랫폼과 앱을 모니터링하는 것이 중요합니다. 플랫폼의 경우 네이티브 Azure 모니터링 기능을 사용할 수 있습니다. 앱의 경우 모니터링을 설계하고 구현해야 합니다.

시나리오 배포

이 가이드에 설명된 파란색-녹색 배포의 구현된 예제는 AKS 랜딩 존 가속기를 참조 하세요.

이 참조 구현은 Application Gateway 및 AGIC(Application Gateway 수신 컨트롤러)를 기반으로 합니다. 각 클러스터에는 자체 애플리케이션 게이트웨이가 있으며 트래픽 전환은 특히 CNAME 구성을 통해 DNS를 통해 수행됩니다.

Important

중요 업무용 워크로드의 경우 이 가이드에 설명된 대로 파란색/녹색 배포를 배포 자동화 및 지속적인 유효성 검사와 결합하여 가동 중지 시간을 0으로 설정하는 것이 중요합니다. 자세한 정보 및 지침은 중요 업무용 디자인 방법론에서 확인할 수 있습니다.

지역 고려 사항

파란색 및 녹색 클러스터를 별도의 지역 또는 동일한 지역에 배포할 수 있습니다. 디자인 및 운영 원칙은 이 선택에 의해 영향을 받지 않습니다. 그러나 다음과 같은 특정 형식의 추가 네트워킹 구성이 영향을 받을 수 있습니다.

AKS 및 애플리케이션 게이트웨이에 대한 전용 가상 네트워크 및 서브넷.
Monitor, Container Registry 및 Key Vault와 같은 지원 서비스와의 연결.
애플리케이션 게이트웨이의 Azure Front Door 표시 유형.

동일한 지역에 배포하기 위한 필수 조건이 있습니다.

가상 네트워크 및 서브넷은 두 개의 클러스터를 호스트하도록 크기를 조정해야 합니다.
Azure 구독은 두 클러스터에 충분한 용량을 제공해야 합니다.

수신 컨트롤러 및 외부 부하 분산 장치 배포

수신 컨트롤러 및 외부 부하 분산 장치의 배포에는 여러 가지 방식이 있습니다.

이 가이드에 설명된 아키텍처의 참조 구현과 같이 전용 외부 부하 분산 장치가 있는 단일 수신 컨트롤러를 가질 수 있습니다. AGIC 는 Application Gateway L7 부하 분산 장치를 사용하여 클라우드 소프트웨어를 인터넷에 노출할 수 있도록 하는 Kubernetes 애플리케이션입니다. 특정 시나리오에서는 애플리케이션 엔드포인트 외에 AKS 클러스터에 관리 엔드포인트가 있습니다. 관리 엔드포인트는 애플리케이션에서 운영 작업을 수행하거나 구성 맵, 비밀, 네트워크 정책 및 매니페스트 업데이트와 같은 구성 작업을 위한 것입니다.
동일한 클러스터 또는 여러 클러스터에 배포된 여러 수신 컨트롤러를 제공하는 단일 외부 부하 분산 장치가 있을 수 있습니다. 이 방식은 참조 구현에서 다루지 않습니다. 이 시나리오에서는 공용 엔드포인트와 프라이빗 엔드포인트에 대해 별도의 애플리케이션 게이트웨이를 사용하는 것이 좋습니다.
이 가이드에 제안되고 설명된 결과 아키텍처는 NGINX 및 Envoy 기반과 같은 AKS 클러스터의 일부로 배포된 표준 수신 컨트롤러를 기반으로 합니다. 참조 구현에서는 AGIC를 사용합니다. 즉, 애플리케이션 게이트웨이와 AKS Pod 간에 직접 연결이 있지만 전체 파란색-녹색 아키텍처에는 영향을 미치지 않습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

Vincenzo Morra | SAO 인큐베이션 설계자

기타 기여자:

Oscar Pla Alvarez | 도메인 솔루션 설계자

비공용 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음을 통해 공유

AKS 클러스터의 파란색-녹색 배포

아키텍처