이 문서에서는 멀티 클러스터 Google Kubernetes Engine(GKE) 환경에서 업그레이드를 설계, 계획, 구현하는 방법을 설명합니다. 이 문서에 업그레이드를 위해 멀티 클러스터 인그레스가 사용되지만, 외부 부하 분산기를 수동으로 구성하는 등, 다른 솔루션에도 이 개념이 적용될 수 있습니다. 이 문서에는 멀티 클러스터 인그레스로 멀티 클러스터 GKE 환경을 업그레이드하는 방법을 보여주는 동반된 튜토리얼이 있습니다. 이 문서는 GKE 클러스터 그룹을 유지보수해야 하는 Google Cloud 관리자를 대상으로 합니다.
멀티 클러스터 아키텍처에 대한 필요성
이 섹션에서는 멀티 클러스터 Kubernetes 아키텍처가 필요할 수 있는 다양한 이유를 살펴봅니다.
인프라로서의 Kubernetes
이 문서에서는 Kubernetes 클러스터를 인프라 구성요소로 간주합니다. 인프라는 처분 가능합니다. 구성요소가 어떤 목적을 제공하기 위해 존재하기 때문에 어떠한 인프라 구성요소도 특별하게 취급하지 않아야 합니다. Kubernetes의 목적은 개발자 및 운영자가 컨테이너 기반 애플리케이션과 서비스를 소비자에게 제공할 수 있도록 자동화 및 조정 기능을 제공하는 것입니다. 소비자는 내부 팀, 다른 서비스 또는 외부 고객일 수 있습니다.
일반적인 멀티 클러스터 시나리오
인프라로서의 Kubernetes 특성 외에도 멀티 클러스터 환경을 구성해야 할 많은 이유가 있습니다.
- 지리. 많은 서비스가 여러 리전에 배치되어야 합니다. 서비스를 단일 리전에서 제공하는 경우와 비교할 때 서비스를 소비자에게 더 가깝게(소비자의 리전에) 배치하면 지연 시간이 낮기 때문에 더 나은 환경을 제공할 수 있습니다. Kubernetes 클러스터는 단일 리전에서 실행됩니다. 멀티 리전 배포의 경우 여러 리전에 있는 여러 Kubernetes 클러스터가 필요합니다. 멀티 클라우드 또는 하이브리드 클라우드 환경에서도 각 환경에 여러 클러스터가 필요합니다. Kubernetes 클러스터는 또한 서비스의 스테이트풀(stateful) 데이터 소스와 함께 배치되는 경우가 많습니다. 관계형 데이터베이스 관리 시스템(RDBMS)와 같은 일부 애플리케이션은 해당 백엔드와 동일한 위치(리전 및 영역)에 있어야 할 수 있습니다.
- 테넌시 및 환경. Kubernetes 클러스터는 멀티테넌시용으로 설계되었습니다. 여러 팀이 각 서비스에 대해 단일 클러스터를 공유할 수 있습니다. Kubernetes는 네임스페이스, 역할 기반 액세스 제어(RBAC), 네트워크 정책, 인증과 같은 표준 리소스를 제공하여 멀티 테넌트 환경에서 액세스 제어를 적절하게 구성합니다. 경우에 따라 일부 서비스는 회사 정책, 개인정보 보호, 보안 또는 산업 규정으로 인해 한 클러스터에 다른 서비스와 함께 배치하지 못할 수 있습니다. 이럴 때 특정 테넌트를 고유 클러스터로 구분하기 위해서는 멀티 클러스터가 필요합니다. 또한 환경(개발, 스테이징, 프로덕션)도 개별 클러스터로 생성됩니다. 서로 다른 환경에 설치되는 액세스 범위 및 애플리케이션 유형이 매우 다르며 개별 클러스터로 유지되어야 합니다.
- 구성 및 함수. 일부 경우에는 특정 기능을 수행하기 위해 클러스터가 생성됩니다. 예를 들어 머신러닝 워크플로에는 GPU가 포함된 노드가 필요하거나 일괄 분석 워크로드 목적으로 Spot VM으로 구성된 인스턴스 클러스터에 대해 기타 하드웨어 요구사항을 갖고 있는 Kubeflow 또는 데이터 분석 작업이 사용될 수 있습니다. 이러한 하드웨어 요구사항은 다른 서비스에 적용되지 않을 수 있습니다. 이러한 워크플로가 비즈니스를 실행하는 데 중요하지 않을 수 있으며, 임시 클러스터(단기 클러스터)가 필요할 수 있습니다. 관측 가능성(로깅, 측정항목, trace) 및 CI/CD 도구와 같은 공유 서비스는 자체 플랫폼 관리자 클러스터에 더 적합합니다. 비즈니스와 관련해 중요도가 높지 않은 워크플로의 경우 개별적인 함수 특정 클러스터가 자주 보입니다.
- 복원력. 다중 클러스터는 환경의 복원력을 높이기 위해 자주 사용됩니다. 각 클러스터에는 영향 영역이 있습니다. 여기에서 영향 영역은 클러스터 오작동, 잘못된 구성, 계획된 또는 계획되지 않은 유지보수로 인한 클러스터 오프라인 전환으로 인해 부정적인 영향을 받는 서비스 수를 의미합니다. 크기가 작은 클러스터가 대량으로 있으면 크기가 작은 영향 영역이 대량으로 있는 것입니다. 서비스가 두 클러스터에 존재할 경우 클러스터가 로드를 동일하게 공유합니다. 한 클러스터가 오프라인으로 전환하면 트래픽의 50%가 영향을 받습니다. 동일 서비스가 단일 클러스터로 제공되는 경우, 해당 클러스터에 사고가 발생하면 서비스가 100% 중단될 것입니다. 따라서 멀티 클러스터는 재해 복구 목적으로도 자주 사용됩니다.
이 문서에서는 멀티 클러스터 배포의 복원력 특성에 대해 자세히 살펴봅니다.
멀티 클러스터 및 분산 서비스
분산 서비스는 여러 Kubernetes 클러스터에 배포되는 Kubernetes 서비스입니다. 분산 서비스는 스테이트리스(Stateless) 서비스이며 다중 클러스터 간에 동일하게 작동합니다. 즉, 분산 서비스의 Kubernetes 서비스 이름이 동일하며, 다중 클러스터 간에 동일한 네임스페이스로 구현됩니다. Kubernetes 서비스는 서비스가 실행되는 Kubernetes 클러스터에 연결됩니다. Kubernetes 클러스터가 오프라인으로 전환되면 Kubernetes 서비스도 오프라인으로 전환됩니다. 분산 서비스는 개별 Kubernetes 클러스터로부터 분리됩니다. 하나 이상의 Kubernetes 클러스터가 작동 중지되더라도 분산 서비스가 온라인 상태일 수 있고 서비스 수준 목표(SLO) 범위를 유지할 수 있습니다.
다음 그림에서 frontend는 동일한 서비스 이름 및 네임스페이스를 사용하여 멀티 클러스터에서 실행되는 분산 서비스입니다.
이 아키텍처에서 frontend 서비스는 단일 클러스터에 연결되지 않으며, 다이어그램에서는 Kubernetes 클러스터 인프라 레이어를 포함하는 레이어로 개념적으로 표현되었습니다. frontend 서비스를 실행하는 개별 클러스터가 작동 중지되더라도 frontend가 온라인 상태로 유지됩니다.
여기에는 단일 개별 클러스터에서 실행되는 추가 서비스인 accounts 서비스와 ledger 서비스가 있습니다. 업타임 및 가용성은 서비스가 있는 Kubernetes 클러스터의 업타임에 따라 달라집니다.
복원력은 멀티 클러스터 배포를 사용하는 이유 중 하나입니다. 분산 서비스는 멀티 클러스터 아키텍처에서 복원력이 높은 서비스를 만듭니다. 스테이트리스(Stateless) 서비스는 멀티 클러스터 환경에서 분산 서비스로 가장 많이 사용됩니다. 분산 서비스를 사용할 때는 다음과 같은 요구사항 및 고려사항이 적용됩니다.
멀티 클러스터 네트워킹. 멀티 클러스터 인그레스와 같은 멀티 클러스터 인그레스 기술을 사용하거나 고유 외부 부하 분산기 또는 프록시 솔루션을 사용하여 서비스를 실행하는 클러스터로 분산 서비스로 지정된 트래픽을 전송할 수 있습니다. 어떤 옵션을 사용하더라도 분산 서비스 대신 특정 인스턴스로 트래픽을 라우팅할 시기, 위치, 정도를 제어할 수 있어야 합니다. 다음 다이어그램은 2개의 GKE 클러스터에서 실행되는 분산 서비스
frontend로 트래픽을 전송하는 부하 분산기를 보여줍니다.
관측 가능성. 분산 서비스에 대해 총체적으로 SLO(일반적으로 가용성 및 지연 시간)를 측정하기 위해 도구를 사용합니다. 이러한 구성은 멀티 클러스터에서 각 서비스의 성능에 대한 전반적인 뷰를 제공합니다. 분산 서비스가 대부분의 관측 가능성 솔루션에서 잘 정의된 리소스는 아니지만, 개별 Kubernetes 서비스 측정항목을 수집하고 조합할 수 있습니다. Cloud Monitoring과 같은 솔루션 또는 Grafana와 같은 오픈소스 도구는 Kubernetes 서비스 측정항목을 제공합니다. Istio 및 Anthos Service Mesh와 같은 서비스 메시 솔루션도 계측 없이 서비스 측정항목을 제공합니다.
서비스 배치. Kubernetes 서비스는 단일 Kubernetes 클러스터 내에서 노드 수준의 내결함성을 제공합니다. 즉, 노드가 중단되어도 Kubernetes 서비스가 지속될 수 있습니다. 노드가 중단되면 Kubernetes 제어 영역 노드가 정상 노드를 사용하도록 Pod 사용 일정을 자동으로 재구성합니다. 분산 서비스는 클러스터 수준의 내결함성을 제공합니다. 즉, 클러스터가 중단되어도 분산 서비스가 지속될 수 있습니다. 분산 서비스를 계획할 때는 이러한 서비스 배치를 고려해야 합니다. 분산 서비스는 모든 클러스터에서 실행될 필요가 없습니다. 분산 서비스가 실행되는 클러스터는 다음 요구사항에 따라 달라집니다.
- 필요한 서비스의 위치 또는 리전이 무엇인가요?
- 분산 서비스에 필요한 SLO는 무엇인가요?
- 클러스터, 영역, 리전 등 분산 서비스에 필요한 내결함성 유형은 무엇인가요? 예를 들어 단일 영역에서 멀티 클러스터가 필요하거나 단일 리전 또는 여러 리전의 영역 간에 멀티 클러스터가 필요한가요?
최악의 경우 시나리오에서 분산 서비스가 견뎌야 하는 중단 수준은 무엇인가요? 클러스터 레이어에서 사용할 수 있는 옵션은 다음과 같습니다.
- N+1(여기서 N은 서비스 용량 요구를 충족시키기 위해 필요한 클러스터 수). 분산 서비스는 단일 클러스터 오류를 견딜 수 있습니다.
- N+2. 분산 서비스가 2개의 동시 오류를 견딜 수 있습니다. 예를 들어 계획된 중단 및 계획되지 않은 중단이 동시에 2개 클러스터에서 발생해도 서비스가 지속됩니다.
출시 및 롤백. 분산 서비스는 Kubernetes 서비스와 비슷하게 점진적 출시 및 롤백을 허용합니다. 하지만 분산 서비스에서는 Kubernetes 서비스와 달리 점진적 변경을 위해 클러스터가 추가 배포 단위로 사용될 수 있습니다. 출시 및 롤백도 서비스 요구사항에 따라 달라집니다. 버그 수정과 같이 일부 경우에는 모든 클러스터에서 동시에 서비스를 업그레이드해야 할 수 있습니다. 다른 경우에는 한 번에 하나씩 클러스터에 변경 사항을 천천히 출시(또는 지연 출시)해야 할 수 있습니다. 이러한 점진적 출시는 서비스에 변경사항을 점진적으로 도입함으로써 분산 서비스에 대한 위험을 낮춰줍니다. 하지만 이 방식은 클러스터 수에 따라 시간이 오래 걸릴 수 있습니다. 어떤 단일 업그레이드 전략도 완벽한 것은 없습니다. 오히려 분산 서비스 요구사항에 따라 여러 가지 출시 및 롤백 전략이 사용되는 경우가 많습니다. 여기서 중요한 것은 분산 서비스의 경우 해당 환경에서 점진적이고 제어된 방식의 변경이 허용되어야 한다는 것입니다.
비즈니스 연속성 및 재해 복구(BCDR) 이 두 용어는 함께 사용되는 경우가 많습니다. 비즈니스 연속성은 중요 이벤트(계획되었거나 계획되지 않은)가 발생했을 때 핵심 서비스의 지속성을 나타내며, 재해 복구는 이러한 이벤트 발생 후 비즈니스 운영을 정상 상태로 되돌리기 위해 필요하거나 수행되는 조치를 나타냅니다. 많은 BCDR 전략은 이 문서의 범위를 벗어납니다. BCDR을 위해서는 시스템 및 서비스에서 일정 수준의 중복성이 필요합니다. 분산 서비스의 핵심 조건은 서비스를 여러 위치(클러스터, 영역, 리전)에서 실행한다는 것입니다.
BCDR 전략은 종종 앞에서 설명한 출시 및 롤백 전략에 따라 달라집니다. 예를 들어 지연 출시 또는 제어된 방식으로 출시를 수행할 경우, 버그 또는 잘못된 구성 푸시로 인한 효과를 대규모 사용자에게 영향을 주지 않고 조기에 포착할 수 있습니다. 최신 CI/CD 방식에서와 같이 대규모 그리고 빠른 속도로 변경사항을 출시할 때는 사용자에 따라 동일한 버전의 분산 서비스가 제공되지 않는 경우가 일반적입니다. 분산 시스템 및 서비스에서의 BCDR 계획 및 전략은 기존의 모놀리식 아키텍처와 다릅니다. 기존 시스템에서는 변경이 한 번에 이뤄지기 때문에 대규모 사용자(또는 모든 사용자)에 영향을 주며, 따라서 출시 후 원치 않는 효과가 발생할 것을 대비하여 중복 또는 백업 시스템을 준비해야 합니다. 분산 시스템 및 서비스에서는 소규모 사용자에게만 영향을 줄 수 있도록 거의 모든 변경이 점진적인 방식으로 수행됩니다.
클러스터 수명 주기 관리. 제어 방식의 출시 및 롤백과 같이, 분산 서비스에서는 제어 방식의 클러스터 수명 주기 관리가 허용됩니다. 분산 서비스는 유지보수 목적으로 클러스터를 로테이션에서 빼낼 수 있도록 클러스터 수준의 복원력을 제공합니다. 클러스터 수명 주기 관리는 Kubernetes 서비스에 적용되지 않는 분산 서비스의 특성입니다.
이 문서의 나머지 부분에서는 분산 서비스의 클러스터 수명 주기 특성에 대해 자세히 살펴봅니다.
GKE 클러스터 수명 주기 관리
클러스터 수명 주기 관리는 서비스 SLO를 위반하지 않으면서 Kubernetes 클러스터 그룹을 정상 상태 및 업데이트된 상태로 유지하기 위해 필요한 전략 및 계획으로 정의될 수 있습니다. 적절한 전략 및 계획을 사용할 때 클러스터 수명 주기 관리는 일상적이어야 하고, 당연히 있어야 하며, 상시적이어야 합니다.
이 문서에서는 GKE 수명 주기 관리에 대해 자세히 살펴봅니다. 하지만 이 개념은 다른 Kubernetes 분배 방식에도 적용될 수 있습니다.
GKE 버전 관리 및 업그레이드
클러스터 수명 주기 관리에 대한 전략 및 계획을 살펴보기 전에 클러스터 업그레이드가 어떻게 구성되는지 이해하는 것이 중요합니다.
클러스터에는 제어 영역 노드와 워커 노드라는 두 구성요소가 있습니다. Kubernetes 클러스터를 업그레이드하려면 모든 노드를 동일한 버전으로 업그레이드해야 합니다. Kubernetes는 시맨틱 버전 관리 스키마를 따릅니다.
Kubernetes 버전은 X.Y.Z:로 표시됩니다. 여기서 X는 주 버전이고, Y는 부 버전, Z는 패치 버전입니다. 부 출시는 약 3개월(분기)마다 수행되고, Kubernetes 프로젝트는 최근 3회의 부 출시에 대해 출시 분기를 유지합니다. 즉, 9개월이 지난 Kubernetes 부 출시는 더 이상 유지되지 않으며, 최신 버전으로 업그레이드할 때 API 변경이 필요할 수 있습니다. 정기적으로 Kubernetes 업그레이드를 계획해야 합니다. 계획된 GKE 업그레이드는 1분기 또는 2분기 간격으로 수행하는 것이 좋습니다.
GKE 클러스터는 지원되는 모든 부 출시의 Kubernetes 버전 실행을 지원합니다. 언제든지 최소 2개 이상의 부 버전을 사용할 수 있습니다.
GKE의 클러스터 가용성 유형은 다음과 같습니다.
- 단일 영역 클러스터. 단일 제어 영역 노드 및 모든 노드 풀이 단일 리전의 단일 영역에 있습니다.
- 다중 영역 클러스터. 단일 제어 영역 노드가 한 영역에 있고 노드 풀은 단일 리전의 여러 영역에 있습니다.
- 리전 클러스터. 여러 제어 영역 노드 및 노드 풀이 단일 리전의 여러 영역에 있습니다.
GKE는 관리형 서비스이며 컨트롤 플레인 노드 및 워커 노드 모두에 대해 자동 업그레이드를 제공합니다.
GKE 자동 업그레이드
GKE 자동 업그레이드는 인기 있고 자주 사용되는 클러스터 수명 주기 전략입니다. GKE 자동 업그레이드는 GKE 클러스터가 지원되는 버전으로 업데이트된 상태로 유지하는 완전 관리형 방식을 제공합니다. GKE 자동 업그레이드는 제어 영역 노드와 워커 노드를 개별적으로 업그레이드합니다.
마스터 자동 업그레이드. 기본적으로 GKE 제어 영역 노드는 자동으로 업그레이드됩니다. 단일 영역 및 다중 영역 클러스터에는 단일 제어 영역(제어 영역 노드)이 있습니다. 제어 영역 노드 업그레이드 중에도 워크로드는 계속 실행됩니다. 하지만 업그레이드가 완료될 때까지는 새 워크로드를 배포하거나, 기존 워크로드를 수정하거나, 클러스터 구성을 변경하는 것이 불가능합니다.
리전 클러스터에는 제어 영역의 여러 복제본이 포함되며, 복제본이 한 번에 하나씩만 업그레이드됩니다. 업그레이드하는 동안 클러스터는 고가용성을 유지하며 각 제어 영역의 복제본은 업그레이드하는 동안에만 사용할 수 있습니다.
워커 노드 자동 업그레이드. 노드 풀은 한 번에 하나씩 업그레이드됩니다. 노드 풀 내에서 노드는 한 번에 하나씩 무작위 순서로 업그레이드됩니다. 한 번에 업그레이드되는 노드 수를 변경할 수 있지만 이 프로세스는 노드 수 및 워크로드 구성에 따라 몇 시간까지 걸릴 수 있습니다.
GKE 자동 업그레이드 수명 주기 전략
가능한 경우 GKE 자동 업그레이드를 사용하는 것이 좋습니다. GKE 자동 업그레이드는 제어보다 편의를 우선합니다. 하지만 GKE 자동 업그레이드는 특정 매개변수 내에서 클러스터가 업그레이드되는 시간과 방법에 영향을 줄 수 있는 여러 방법들을 제공합니다. 유지보수 기간 및 유지보수 제외에 영향을 줄 수 있습니다. 출시 채널은 버전 선택에 영향을 미치고 노드 업그레이드 전략은 노드 업그레이드 순서와 시기에 영향을 미칩니다. 이러한 제어 및 리전 클러스터(여러 Kubernetes 제어 영역)에도 불구하고 GKE 자동 업그레이드는 서비스 업타임을 보장하지 않습니다. 다음 중 하나 이상이 필요한 경우에는 GKE 자동 업그레이드 기능을 사용하지 않을 수 있습니다.
- 정확한 GKE 클러스터 버전 제어.
- GKE 업그레이드를 위한 정확한 시간 제어.
- GKE 그룹에 대한 업그레이드 전략 제어(다음 섹션 참조).
GKE 멀티 클러스터 수명 주기 관리
이 섹션에서는 여러 가지 GKE 멀티 클러스터 수명 주기 관리 전략과 이를 계획하는 방법을 설명합니다.
계획 및 설계 고려사항
GKE 멀티 클러스터 아키텍처는 클러스터 수명 주기 관리 전략을 선택할 때 일정 부분을 담당합니다. 이러한 전략을 살펴보려면 먼저 클러스터 수명 주기 관리 전략에 영향을 주거나 또는 영향을 받을 수 있는 특정 설계 결정 사항을 확인할 필요가 있습니다.
클러스터 유형
클러스터 수명 주기 관리 전략으로 GKE 자동 업그레이드를 사용하는 경우 클러스터 유형이 중요할 수 있습니다. 예를 들어 리전 클러스터에 한 번에 자동 업그레이드되는 제어 영역 노드가 있지만, 영역 클러스터에 단일 제어 영역 노드가 포함될 수 있습니다. GKE 자동 업그레이드를 사용하지 않고 모든 Kubernetes 클러스터를 일회용 인프라로 간주할 경우에는 클러스터 수명 주기 관리 전략을 결정할 때 선택할 클러스터 유형이 중요하지 않을 수 있습니다. 다음 섹션인 GKE 멀티 클러스터 수명 주기 관리에서 설명하는 전략을 클러스터 유형에 적용할 수 있습니다.
클러스터 배치 및 사용 공간
클러스터 배치 및 사용 공간을 결정할 때 다음 요소를 고려하세요.
- 클러스터를 배치할 영역 및 리전
- 필요한 클러스터 수와 크기
비즈니스 및 사용자에게 제공하는 리전에 따라 영역 및 리전이 결정되므로 첫 번째 요소는 일반적으로 쉽게 해결됩니다.
클러스터 수와 크기 확인은 다음과 같이 분류되며, 각각 장점과 단점이 있습니다.
- 소규모 대형 클러스터. 리전 클러스터에서 제공되는 중복성과 복원력을 사용하고 리전별로 한 개(또는 두 개)의 대형 리전 클러스터를 배치합니다. 이 방법의 장점은 여러 클러스터를 관리하는 데 따른 운영 오버헤드가 낮다는 것입니다. 하지만 영향 영역이 크기 때문에 많은 서비스에 영향을 줄 수 있는 단점이 있습니다.
- 대규모 소형 클러스터. 서비스가 여러 클러스터에 분할되기 때문에 많은 수의 소형 클러스터를 만들어서 클러스터 영향 영역을 줄일 수 있습니다. 이 방법은 단기 임시 클러스터(예: 일괄 워크로드를 실행하는 클러스터)의 경우에도 효과적입니다. 이 방법은 업그레이드할 클러스터 수가 많기 때문에 운영 오버헤드가 높은 단점이 있습니다. 또한 제어 영역 노드 수가 많기 때문에 추가 비용이 발생할 수 있습니다. 자동화, 예측 가능한 일정과 전략, 영향을 받는 팀과 서비스 간의 적절한 조정을 통해 이러한 비용과 높은 운영 오버헤드를 줄일 수 있습니다.
이 문서에서는 상황에 따라 다르므로 어떤 방법이 더 좋은지 추천하지 않습니다. 일부 경우에는 여러 서비스 범주에 따라 두 가지 설계 패턴을 모두 선택할 수 있습니다.
다음 전략은 어떤 설계를 선택하더라도 효과적입니다.
용량 계획
용량을 계획할 때는 선택한 클러스터 수명 주기 전략을 고려하는 것이 중요합니다. 용량 계획 시에는 다음 일반 서비스 로드와 유지보수 이벤트를 고려해야 합니다.
- 클러스터 업그레이드와 같은 계획된 이벤트
- 클러스터 중단과 같은 계획되지 않은 이벤트(예: 잘못된 구성 푸시 및 잘못된 출시)
용량을 계획할 때는 모든 종합적 또는 부분적 중단을 고려해야 합니다. 계획된 유지보수 이벤트만 설계할 때는 서비스 성능 저하 없이 업그레이드하기 위해 한 번에 하나씩 클러스터를 로테이션에서 빼낼 수 있도록 모든 분산 서비스에 필요한 것보다 하나 더 클러스터를 구성해야 합니다. 이 방식을 N+1 용량 계획이라고도 합니다. 계획된 유지보수 이벤트와 계획되지 않은 유지보수 이벤트를 설계할 때는 의도한 용량을 제공하는 데 필요한 것보다 2개(또는 그 이상)의 추가 클러스터를 모든 분산 서비스에 구성해야 합니다. 하나는 계획된 이벤트를 위한 것이고 다른 하나는 계획된 유지보수 기간 중에 발생하는 계획되지 않은 이벤트를 위한 것입니다. 이 방식을 N+2 용량 계획이라고도 합니다.
멀티 클러스터 아키텍처에서 드레이닝과 스필링은 자주 사용되는 용어입니다. 이러한 용어는 업그레이드 및 유지보수 이벤트 동안 클러스터에서 트래픽을 삭제하는 프로세스(드레이닝)와 다른 클러스터로 트래픽을 리디렉션하는 프로세스(스필링)를 의미합니다. 이 프로세스는 멀티 클러스터 인그레스와 같은 네트워킹 솔루션 또는 다른 부하 분산 방법을 사용하여 수행됩니다. 일부 클러스터 수명 주기 관리 전략에서는 드레이닝과 스필링을 주의해서 사용하는 것이 매우 중요합니다. 용량을 계획할 때는 드레이닝과 스필링을 모두 고려해야 합니다. 예를 들어 단일 클러스터를 드레이닝할 때는 추가적으로 스필링된 트래픽을 처리할 수 있도록 다른 클러스터의 용량이 충분한지 고려해야 합니다. 다른 고려사항으로는 영역 또는 리전의 충분한 용량이나 다른 리전으로 트래픽을 전송해야 하는지 여부(리전별로 단일 리전 클러스터를 사용하는 경우)가 있습니다. 다음 다이어그램은 한 클러스터에서 삭제(클러스터 드레이닝)되고 동일한 분산 서비스를 실행 중인 다른 클러스터로 전송되는 트래픽을 보여줍니다.
클러스터 및 분산 서비스
서비스 기반 클러스터 설계에서는 클러스터에서 실행해야 하는 서비스에 따라 클러스터 아키텍처(개수, 크기, 위치)를 결정하도록 합니다. 따라서 분산 서비스가 필요한 위치에 따라 클러스터 배치가 결정됩니다. 분산 서비스 배치를 결정할 때는 다음을 고려하세요.
- 위치 요구사항. 서비스를 제공해야 하는 리전은 무엇인가요?
- 중요도. 서비스 가용성이 비즈니스에 얼마나 중요한가요?
- SLO. 일반적으로 중요도를 기준으로 할 때 서비스의 서비스 수준 목표는 무엇인가요?
- 복원력. 서비스에 필요한 복원력은 어느 정도인가요? 클러스터, 영역 또는 심지어 리전 오류에도 내결함성이 필요한가요?
클러스터 업그레이드를 계획할 때는 드레이닝되었을 때 단일 클러스터가 영향을 주는 서비스 수를 고려해야 하며, 이러한 각 서비스를 다른 적절한 클러스터에 스필링할 것을 생각해야 합니다. 클러스터는 단일 테넌트 또는 멀티 테넌트일 수 있습니다. 단일 테넌트 클러스터는 단일 서비스 또는 서비스 집합으로 표현되는 하나의 제품만 제공합니다. 단일 테넌트 클러스터는 다른 서비스 또는 제품과 클러스터를 공유하지 않습니다. 멀티 테넌트 클러스터는 일반적으로 네임스페이스로 분할되는 여러 서비스 및 제품을 실행할 수 있습니다.
팀에 대한 영향
클러스터 이벤트는 서비스에 영향을 줄 뿐만 아니라 팀에도 영향을 줄 수 있습니다. 예를 들어 DevOps팀은 클러스터 업그레이드 중 CI/CD 파이프라인을 리디렉션하거나 중지해야 할 수 있습니다. 마찬가지로, 지원팀은 계획된 중단에 대한 알림을 받아야 합니다. 여러 팀에 대한 영향을 줄이기 위해 자동화 및 도구를 배치해야 합니다. 단일 클러스터 또는 클러스터 그룹에 대한 업그레이드는 모든 팀에 알림을 제공할 때 일상적이며 상시적인 것으로 간주됩니다.
시기, 일정, 조정
Kubernetes는 분기별로 새로운 부 버전을 출시하며, 최근 3개의 출시버전을 유지합니다. 클러스터 업그레이드의 시기 및 일정을 신중하게 계획해야 합니다. 이러한 업그레이드가 수행될 때는 서비스 소유자, 서비스 운영자, 플랫폼 관리자 간의 협의가 선행되어야 합니다. 업그레이드를 계획할 때는 다음 질문을 고려해보세요.
- 얼마나 자주 업그레이드하나요? 분기별로 또는 다른 시간 기준에 따라 업그레이드하나요?
- 언제 업그레이드하나요? 분기 시작 시에 비즈니스 활동이 느려질 때 또는 해당 업종별 발생하는 비즈니스 다운타임 중에 업그레이드하나요?
- 업그레이드하지 않아야 할 때는 언제인가요? 블랙 프라이데이, 사이버 먼데이와 같은 트래픽 급증 이벤트 또는 중요한 회의 및 기타 산업 관련 이벤트를 피하기 위해 업그레이드를 하지 않아야 할 시기에 대한 명확한 계획이 있나요?
운영팀과 지원팀은 물론 서비스 소유자에게 전략을 명확하게 전달하는 것이 중요합니다. 미리 모든 정보를 전달하여 모든 사람이 클러스터 업그레이드 시간과 방법을 잘 알고 있어야 합니다. 이를 위해서는 관련된 모든 팀들 간의 명확한 조정이 필요합니다. 단일 서비스에도 이를 사용하는 여러 팀이 포함됩니다. 일반적으로 이러한 팀은 다음과 같은 카테고리로 분류될 수 있습니다.
- 비즈니스 논리를 만들고 이를 서비스로 코딩할 책임이 있는 서비스 개발자
- 안전하고 신뢰할 수 있는 방식으로 서비스를 실행할 책임이 있는 서비스 운영자. 운영자는 정책 또는 보안 관리자, 네트워킹 관리자, 지원팀과 같은 여러 팀으로 구성될 수 있습니다.
이 기간 동안 적절한 조치를 취할 수 있도록 클러스터 업그레이드 중 모든 사람들에게 필요한 정보를 전달해야 합니다. 한 가지 방법은 서비스 중단 이슈를 계획할 때와 동일한 방법으로 업그레이드를 계획하는 것입니다. 영향을 받은 사용자가 없더라도, 이슈 책임자, 채팅방, 회고를 사용할 수 있습니다. 자세한 내용은 이슈 대응을 참조하세요.
GKE 클러스터 수명 주기 전략
이 섹션에서는 GKE 멀티 클러스터 아키텍처에서 자주 사용되는 기본 클러스터 수명 주기 관리 전략에 대해 설명합니다. 모든 시나리오에 효과적인 하나의 전략은 존재하지 않습니다. 그리고 다양한 서비스 카테고리 및 비즈니스 요구에 맞게 여러 전략을 선택해야 할 수 있습니다.
연속 업그레이드
다음 그림은 지속적 업그레이드 전략을 보여줍니다.
부하 분산기를 사용하여 하나의 GKE 클러스터에서 모든 트래픽이 드레이닝되고 클러스터가 업그레이드됩니다. 드레이닝된 트래픽 로드는 다른 GKE 클러스터로 스필링됩니다.
연속 업그레이드는 이 문서에 설명된 전략들 중 가장 간단하고 가장 비용 효과적인 전략입니다. old_ver(또는 최신 프로덕션) 버전을 실행하는 n개의 클러스터로 시작합니다. 그런 후 한 번에 m개의 클러스터를 드레이닝합니다. m은 n보다 작습니다. 그런 후 클러스터를 삭제하고 새 버전으로 새 클러스터를 다시 만들거나 드레이닝된 클러스터를 업그레이드합니다.
새 클러스터를 삭제하거나 업그레이드할지에 대한 판단은 클러스터 크기는 물론 클러스터가 변경할 수 없는 인프라인지 여부에 따라 달라집니다. 변경 불가능한 인프라의 경우 시간이 지날수록 원치 않는 결과가 발생할 수도 있는 지속적인 클러스터 업그레이드 대신, 새 클러스터를 만들고 예측할 수 없는 모든 구성 변경을 방지해야 합니다.
GKE를 사용하는 경우 단일 명령어 또는 API 호출로 GKE 클러스터를 만들 수 있습니다. 새 클러스터 전략에서는 전체 클러스터 구성(클러스터 매니페스트)를 클러스터 외부(일반적으로 Git)에 저장해야 합니다. 그런 후 새 클러스터에서 동일한 구성 템플릿을 사용할 수 있습니다. 새 클러스터의 경우 CI/CD 파이프라인이 올바른 클러스터를 가리키는지 확인합니다. 클러스터가 올바르게 구성되었으면 서비스 SLO를 모니터링하면서 트래픽을 클러스터로 천천히 푸시할 수 있습니다.
이 프로세스는 모든 클러스터에 대해 반복됩니다. 용량 계획에 따라 서비스 SLO를 위반하지 않고 한 번에 여러 클러스터를 업그레이드할 수 있습니다.
단순한 것이 좋고 복원력보다는 비용이 중요한 경우, 연속 업그레이드 전략을 사용하면 됩니다. 이 전략을 사용할 때는 모든 분산 서비스에 대해 GKE 그룹에 필요한 용량을 초과할 일이 없습니다.
다음 다이어그램은 멀티 클러스터 아키텍처에서 GKE 클러스터를 업그레이드하는 동안의 타임라인과 서비스 용량 요구사항을 비교해서 보여줍니다.
앞의 다이어그램은 GKE 업그레이드 프로세스 전체 기간 동안 서비스 지원 용량이 필요한 값 아래로 떨어지지 않는 것을 보여줍니다. 업그레이드할 GKE 클러스터를 로테이션에서 빼내면 이 로드를 지원하기 위해 다른 클러스터가 수직 확장됩니다.
블루/그린 업그레이드
다음 다이어그램은 블루/그린 업그레이드 전략을 보여줍니다.
앞의 다이어그램에서는 새 버전을 실행하는 새로운 GKE 클러스터가 추가되었습니다. 그런 다음 부하 분산기를 사용해서 트래픽이 전송되지 않을 때까지 이전 클러스터 중 하나를 천천히 드레이닝하면서 새 클러스터로 트래픽을 전송합니다. 완전히 드레이닝된 이전 클러스터는 삭제할 수 있습니다. 나머지 클러스터에 대해서도 동일한 프로세스를 따를 수 있습니다.
블루/그린 업그레이드 전략은 어느 정도 추가된 복원력을 제공합니다.
이 전략은 연속 업그레이드와 비슷하지만 비용이 조금 더 높습니다. 유일한 차이는 기존 클러스터를 먼저 드레이닝하는 대신 해당 버전으로 새 m 클러스터를 먼저 만듭니다. 여기서 m은 n보다 작거나 같습니다. 새 클러스터를 CI/CD 파이프라인에 추가한 후 서비스 SLO를 모니터링하면서 트래픽을 천천히 스필링합니다. 새 클러스터가 완전히 트래픽을 받게 되면 이전 버전의 클러스터를 드레이닝하고 삭제합니다.
블루/그린 클러스터 업그레이드 전략은 일반적으로 서비스에 사용되는 블루/그린 전략과 비슷합니다. 새 클러스터를 한 번에 여러 개 만들면 전체 비용이 늘어나지만 그룹 업그레이드 시간을 줄일 수 있는 이점이 있습니다. 추가 비용은 추가 클러스터가 사용될 때의 업그레이드 기간에 대해서만 발생합니다. 새 클러스터를 먼저 만들 때의 이점은 오류가 발생했을 때 롤백할 수 있다는 것입니다. 또한 프로덕션 트래픽을 전송하기 전 새 클러스터를 테스트할 수도 있습니다. 짧은 기간 동안만 이전 버전과 함께 클러스터가 공존하기 때문에 추가 비용도 최소한으로 유지됩니다.
단순한 것이 좋고 비용보다는 복원력이 중요한 경우 블루/그린 업그레이드 전략을 사용하면 됩니다. 추가 클러스터가 먼저 추가되고 업그레이드 기간 동안 GKE 그룹에 필요한 용량을 초과합니다.
이전 다이어그램에서 새 클러스터를 먼저 임시로 추가하면 그룹의 다른 클러스터가 그룹에서 드레이닝되고 삭제되면서 필요한 용량에 비해 사용 가능한 용량이 늘어납니다. 하지만 이전(완전히 드레이닝된) 클러스터 중 하나를 삭제한 후에는 용량이 다시 필요한 수준으로 돌아갑니다. 이 모델에서는 그룹에 있는 클러스터 수 및 크기에 따라 비용이 증가될 수 있기 때문에 이러한 용량 변화가 중요하게 표시되었습니다.
카나리아 클러스터 업그레이드
카나리아 클러스터 업그레이드는 이 문서에서 설명된 전략들 중에서 가장 복원력이 높고 복잡한 전략입니다. 이 전략은 서비스 수명 주기 관리에서 클러스터 수명 주기 관리를 완전히 분리하여, 서비스에 대해 가장 낮은 위험과 가장 높은 복원력을 제공합니다. 이전의 연속 및 블루/그린 업그레이드 전략에서는 전체 GKE 그룹을 단일 버전으로 유지합니다. 이 전략에서는 다른 버전을 실행하는 GKE 클러스터를 2개 또는 3개의 그룹으로 유지합니다. 클러스터를 업그레이드하는 대신 시간 경과에 따라 하나의 서비스 그룹의 서비스를 다른 그룹으로 마이그레이션합니다. 가장 오래된 GKE 그룹이 드레이닝되면(즉, 모든 서비스가 다음 버전의 GKE 그룹으로 마이그레이션되면), 이 그룹을 삭제합니다.
이 전략에서는 현재 프로덕션을 위한 그룹과 다음 프로덕션 후보 버전을 위한 그룹의 최소 두 가지 GKE 그룹을 유지보수해야 합니다. 또한 2개를 초과하여 GKE 그룹을 유지할 수도 있습니다. 그룹이 늘어날수록 유연성이 커지지만 비용과 운영 오버헤드도 같이 늘어납니다. 이러한 추가 그룹은 개발, 스테이징, 프로덕션 환경과 같이 서로 다른 환경에 클러스터를 배치하는 것과 같지 않습니다. 비프로덕션 환경은 비프로덕션 트래픽으로 Kubernetes 기능 및 서비스를 테스트하기에 적합합니다.
카나리아 클러스터 업그레이드를 사용하는 이 전략에서는 프로덕션 환경에서 여러 GKE 그룹 버전을 유지보수해야 합니다. 이것은 서비스에 자주 사용되는 카나리아 릴리스 전략과 비슷합니다. 카나리아 서비스 배포의 경우 서비스 소유자는 항상 서비스의 특정 버전으로 이슈를 정확하게 식별할 수 있습니다. 또한 카나리아 클러스터에서는 서비스 소유자가 서비스가 실행되는 GKE 그룹 버전을 고려해야 합니다. 단일 분산 서비스 버전은 잠재적으로 여러 GKE 그룹 버전으로 실행될 수 있습니다. 서비스 마이그레이션이 점진적으로 수행될 수 있기 때문에 새로운 버전 클러스터로 서비스 트래픽을 모두 전송하기 전에 새 그룹에서 서비스의 효과를 확인할 수 있습니다.
다음 다이어그램은 서로 다른 GKE 클러스터 그룹을 관리하여 서비스 수명 주기에서 클러스터 수명 주기를 완전히 분리할 수 있는 것을 보여줍니다.
이전 다이어그램은 시간 경과에 따라 이전 그룹이 완전히 드레이닝될 때까지 GKE 클러스터의 한 그룹에서 새 버전을 실행하는 다음 그룹으로 천천히 마이그레이션되는 frontend 분산 서비스를 보여줍니다. 그룹이 드레이닝된 다음에는 이를 삭제할 수 있고 새 그룹이 생성됩니다. 모든 서비스가 다음 그룹으로 마이그레이션되고 이전 그룹은 드레이닝되면서 삭제됩니다.
다른 무엇보다 복원력이 가장 중요한 경우에는 카나리아 클러스터 업그레이드 전략을 사용합니다.
업그레이드 전략 선택
다음 다이어그램은 서비스 및 비즈니스 요구를 기준으로 가장 적합한 전략을 결정하는 데 도움을 줄 수 있습니다.
이전 다이어그램은 자신에게 적합한 업그레이드 전략을 선택하는 데 도움이 되는 결정 트리입니다.
- 정확한 버전 및 업그레이드 시간을 완전히 제어할 필요가 없다면 GKE에서 제공되는 자동 업그레이드 기능을 선택할 수 있습니다.
- 낮은 비용이 가장 중요하면 연속 업그레이드 전략을 선택할 수 있습니다.
- 비용과 복원력의 균형이 중요하면 블루/그린 전략을 선택할 수 있습니다.
- 비용보다 복원력이 중요하면 카나리아 클러스터 업그레이드 전략을 선택할 수 있습니다.
GKE 클러스터 수명 주기 관리를 위한 멀티 클러스터 인그레스 사용
거의 모든 전략은 업그레이드 중 클러스터를 드레이닝하고 다른 클러스터로 트래픽을 재지정하는 기능을 기반으로 합니다. 이러한 멀티 클러스터 인그레스 기능을 제공하는 솔루션이 멀티 클러스터 인그레스입니다. 멀티 클러스터 인그레스는 Google Cloud에서 호스팅되는 GKE 클러스터를 위한 멀티 클러스터 인그레스 컨트롤러이며, 클러스터 간 그리고 리전 간에 공유 부하 분산 리소스를 배포할 수 있도록 지원합니다. 멀티 클러스터 인그레스는 여러 리전에 걸쳐 많은 클러스터로 실행되는 분산 서비스로 클라이언트 트래픽을 가져오기 위한 솔루션입니다. GKE용 인그레스와 마찬가지로, Cloud Load Balancing을 사용해서 트래픽을 백엔드 서비스로 전송합니다. 백엔드 서비스는 분산 서비스입니다. 백엔드 서비스는 여러 GKE 클러스터에서 실행되는 Kubernetes 서비스인 여러 backends로 트래픽을 전송합니다. 클러스터 간의 서비스 간 트래픽의 경우 Cloud Service Mesh 또는 Istio와 같이 분산 서비스 간에 비슷한 기능을 제공하는 서비스 메시 기술을 사용할 수 있습니다.
GKE 멀티 클러스터 환경에서는 이전에 설명된 클러스터 수명 주기 관리 전략에 대해 멀티 클러스터 인그레스를 사용해서 여러 클러스터에 대한 트래픽을 조작할 수 있습니다. 블루/그린 전략을 사용하여 GKE용 멀티 클러스터 인그레스 업그레이드를 사용하는 튜토리얼을 따라할 수 있습니다.
다음 단계
- 멀티 클러스터 인그레스 자세히 알아보기
- 클러스터에 멀티 클러스터 인그레스를 배포하는 방법 알아보기