많은 수의 쿠버네티스 클러스터를 운영하기에 좋은 제어 평면은 무엇입니까?

프라나브 다르와드카르

2020년 1월 24일 게시

이 특정 블로그에서는 Volterra가 사용자가 애플리케이션과 인프라를 함대처럼 운영하는 데 어떻게 도움이 되는지 설명합니다. 우리의 제어 평면 기반 접근 방식이 어떻게 대규모 앱 클러스터의 운영을 용이하게 하는지 설명하고 이를 Google Anthos, Azure Arc, Rancher 등과 같은 다른 다중 클러스터 관리 평면 접근 방식과 비교해 보겠습니다.

이제 여러분은 우리가 단지 마케팅 전략을 구사하고 다중 클러스터 관리를 함대 운영이라고 부르는 게 아닐까 하고 궁금해하고 있을 겁니다. 다중 클러스터 관리와 차량 운영 접근 방식은 서로 다른 사용 사례를 다루며 아키텍처가 근본적으로 다릅니다. 다중 클러스터 방식은 클러스터가 비교적 적고 사용자가 일관된 운영 모델을 사용하여 이러한 인프라 클러스터를 관리하려는 시나리오를 해결하도록 설계되었습니다. 반면, 플릿 방식은 대규모 클러스터(예: 로봇, 자동차, 산업용 게이트웨이, 수십 개의 퍼블릭 클라우드 지역 내의 K8s 클러스터 등)가 있고 사용자가 이러한 대규모 클러스터에 동일한 애플리케이션과 네트워크/보안을 배포하려는 시나리오를 해결하도록 설계되었습니다. 다음 두 섹션에서는 다중 클러스터와 함대 운영 방식을 더 자세히 설명하고 비교합니다.

멀티 클러스터 접근 방식

다중 클러스터 관리 방식은 단일 팀이 운영하는 클러스터가 비교적 적은 경우의 사용 사례를 처리하도록 설계되었습니다. 이러한 시나리오의 예로는 폭발 반경을 줄이기 위해 몇 개의 가용성 영역에 걸쳐 10개의 클러스터를 배치하는 것이 있습니다. 마찬가지로, 사용자는 규제 요구 사항을 충족하기 위해 몇몇 지역에 걸쳐 여러 클러스터를 두는 것을 선택할 수 있습니다.

다음 두 가지 예는 다중 클러스터 솔루션이 (높은 수준에서) 작동하는 방식을 강조합니다.

구성

그림 1에 표시된 것처럼 Rancher의 멀티 클러스터 접근 방식을 사용하여 애플리케이션 배포의 예를 살펴보겠습니다. 다중 클러스터 방식에서는 고객이 애플리케이션을 배포할 대상 사이트를 하나씩 선택합니다. 클러스터가 여러 개 있는 경우 대상 사이트를 하나씩 선택하는 이러한 접근 방식이 효과적입니다. 하지만 이 접근 방식은 수천 개의 클러스터를 위해 설계된 것이 아닙니다.

관찰 가능성

그림 2는 Rancher를 예로 들어 다중 클러스터 방식에서 관찰성이 어떻게 작동하는지 보여줍니다. 다중 클러스터 방식에서 고객은 각 클러스터를 하나씩 두 번 클릭하여 배포된 Pod 상태, CPU 및 메모리 리소스 사용률을 확인해야 합니다. 대상 사이트를 하나씩 관찰하는 이러한 접근 방식은 소수의 클러스터에는 적합하지만, 많은 수의 클러스터를 관리하는 데는 적합하지 않습니다.

클러스터 1:

클러스터 2:

첫 번째 예에서 설명한 문제를 해결하는 확실한 방법은 각 클러스터에 대해 작업을 반복하는 일종의 자동화를 작성하는 것입니다. 예를 들어, 새 클러스터가 추가될 때마다 스크립트는 다음 작업을 수행하여 새 애플리케이션(예: checkoutservice)을 배포할 수 있습니다.

KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging을 내보냅니다.

kubectl 적용 -f 체크아웃서비스.yaml

그러나 배포, 업그레이드, 정책, 리소스 예약 등 각 작업에 대해 자동화를 구축해야 합니다. 이러한 자동화는 여러 클러스터에서 개별 작업을 수행할 뿐만 아니라 오류 조건 처리도 처리해야 합니다. 또한 복잡한 시나리오가 있는 경우(예: 클러스터 하위 집합에 대한 베타 테스트, 모든 클러스터에 걸친 롤링 업그레이드) 자동화는 점점 더 복잡해집니다. 우리는 프로세스 초기부터 이를 깨닫고 이 모든 기능을 제공하는 분산 제어 평면을 구축했습니다. 이는 다음에 설명할 함대 운영 방식을 사용하여 이루어집니다.

Volterra의 함대 운영 접근 방식

차량 운영이란 고객이 차량에 대한 의도를 한 번만 선언적으로 정의하고, 시스템이 영향을 받는 사이트가 정의된 의도와 일치하도록 보장하는 책임을 맡는 것을 의미합니다. 의도의 예로는 애플리케이션 소프트웨어 버전, 인프라 소프트웨어 버전(예: 운영 체제 버전), 네트워크 정책, 보안 정책, 리소스 예약 등이 있습니다.

의도가 적용되면 시스템에서 사용자는 함대의 상태와 운영 상태를 볼 수 있습니다. 이는 사용자가 단일 창에서 모든 사이트의 인프라 및 애플리케이션 상태를 집계하여 볼 수 있으므로 고객 운영 팀의 운영 복잡성이 줄어든다는 것을 의미합니다. 사용자는 각 사이트나 클러스터를 하나하나 클릭해서 상태를 확인하고 자동화 도구를 작성해서 정보를 집계할 필요가 없습니다.

Volterra의 함대 운영 접근 방식은 세 가지 주요 구성 요소, 즉 세분화, 구성 및 관찰성으로 구성되어 있으며, 다음 섹션에서 이에 대해 설명합니다.

차량 세분화

사용자는 개발, 테스트, 프로덕션 컴퓨팅 사이트 등 다양한 사이트를 혼합하여 사용하는 경우가 많습니다. 개발 워크로드는 개발 사이트에만 적용해야 하는 등의 조직 정책으로 인해 특정 사이트 세그먼트에 다른 워크로드를 배포해야 합니다. 우리는 사용자가 키와 값의 두 부분으로 구성된 라벨을 사용하여 사이트를 유연하게 태그할 수 있도록 허용합니다. 다음은 그 예입니다.

라벨-키=지역. 레이블 값 = 미국 서부, 일본 북부, 일본 남부
모델 연도=(2015, 2016, 2017, 2018)
기능=(스프레이, 웰드)

사이트에 태그가 지정되면 사용자는 레이블 키-값 조건을 사용하여 "가상 사이트"를 정의할 수 있습니다. 멀티 클라우드 시나리오에서 사용자는 자신의 사이트를 개발, 사전 프로덕션, 프로덕션 등으로 태그 지정할 수 있습니다. 다음 그림 3은 앞서 설명한 레이블-키 값을 사용하는 로봇 사용 사례의 예를 보여줍니다.

다음은 Volterra에서 사용자가 blend/go-sdk 구문을 사용하여 가상 사이트를 만들 수 있는 구성 스니펫입니다. 이 특정 예에서 개별 사이트는 레이블 키=ves.io/country 및 레이블 값 ves-io-jpn으로 태그되었습니다.

사용자는 사전에 자신의 플릿 세그먼트를 정의하고 프로비저닝 시점에 플릿에 포함될 사이트에 태그를 지정하는 운영 모델에 익숙합니다. 가상 사이트는 사용자의 기존 운영 모델과 완벽하게 일치합니다. 적절한 태그가 적용된 새 사이트가 제공되면 추가적인 수동 단계 없이 앞서 정의한 가상 사이트에 자동으로 포함됩니다. 또한 Volterra는 하드웨어 제조업체나 퍼블릭 클라우드 유형과 같은 사전 제공된 정보를 발견하여 시스템 태그를 미리 채웁니다. 사용자는 선택적으로 자동 검색된 태그를 사용하여 가상 사이트를 정의할 수 있습니다.

함대 구성

다음 세 가지 예를 통해 함대 구성 기능을 가장 잘 설명할 수 있습니다.

네트워크/보안 정책 구성 -- 특정 URL(예: github.com )과 통신할 수 있는 기능이 필요한 새로운 서비스를 출시하는 고객의 예를 들어보겠습니다. 일반적으로 사용자는 허용 목록을 사용합니다. 즉, 클러스터는 특정 대상에만 도달할 수 있습니다. 따라서 이 새로운 서비스를 출시하려면 사용자가 각 클러스터로 가서 네트워크 정책을 수정하여 github.com을 허용 목록에 추가해야 합니다. 더욱이, 고객은 모든 사이트에 적용하기에 앞서 몇몇 테스트 사이트에서 이를 테스트하고 싶어합니다. Volterra에서 이러한 의도를 달성하기 위해 고객은 Volterra SaaS 콘솔에서 "테스트" 가상 사이트를 정의하여 차량의 세그먼트를 선택하는 것으로 시작합니다. 그런 다음 사용자는 허용된 URL 목록(이 예에서는 github.com )과 같은 네트워크 정책을 정의하고 "테스트" 가상 사이트에 적용합니다. Volterra의 분산 제어 평면은 가상 사이트(위에서 정의한 대로)에서 선택한 각 사이트의 로컬 제어 평면으로 네트워크 정책을 전송합니다. 각 사이트의 로컬 제어 평면은 네트워크 정책을 적용하고 사이트별로 적용된 규칙에 대한 통계를 수집합니다. 고객이 서비스가 예상대로 작동한다고 만족하면 고객은 네트워크 정책을 "prod" 가상 사이트에 적용할 수 있으며, 이를 통해 플릿의 나머지 사이트가 선택됩니다. 다음은 Volterra 시스템의 UI와 Json을 사용한 구성 스니펫입니다.

인프라 소프트웨어 업그레이드 -- 차량 구성 기능을 통해 사용자는 전체 차량(또는 차량 일부)에 대한 인프라 소프트웨어(예: 운영 체제 버전)를 업그레이드할 수 있습니다. 먼저, 사용자는 운영 체제를 버전 1에서 버전 2로 업그레이드하려는 의도를 정의합니다. 다음으로, 사용자는 롤링 업데이트, 블루/그린 등 전체 함대에 대한 배포 전략을 정의합니다. 롤링 업데이트란 전체 사이트(또는 일부 사이트)의 운영 체제가 순차적으로 업그레이드된다는 것을 의미합니다. 블루/그린 배포 전략은 사용자가 일련의 "블루" 사이트(예: 개발 사이트)에서 업그레이드를 테스트하고 업그레이드되지 않은 "그린" 사이트(예: 프로덕션 사이트)와 상태를 비교하려는 것을 의미합니다. 어느 경우든 Volterra의 분산 제어 플레인은 가상 사이트에서 선택한 각 사이트의 로컬 제어 플레인으로 버전 2 소프트웨어를 전송하고 배포 전략에 정의된 대로 전송합니다. 각 사이트의 로컬 제어 플레인은 A/B 방식으로 운영 체제를 업그레이드합니다. 즉, 새로운 파티션을 만들고, 새로운 파티션에 버전 2를 배포하고, 고객이 상태를 측정할 수 있도록 합니다. 버전 2 설치가 성공적이지 않으면 시스템은 원래 파티션에서 버전 1로 자동으로 롤백됩니다. 다음은 사용자가 Volterra SaaS 포털을 사용하여 인프라 소프트웨어를 업그레이드하는 방법에 대한 몇 가지 스크린샷입니다. 다음 그림에서 보듯이 사용자는 현재 인프라 소프트웨어 버전과 모든 사이트에서 사용할 수 있는 최신 소프트웨어 버전을 볼 수 있습니다. 사용자는 운영 모델에 따라 특정 사이트나 모든 사이트를 쉽게 업그레이드할 수 있습니다.

전체 함대에 걸친 애플리케이션 배포 -- Volterra는 Kubernetes API를 사용하여 사용자가 전체 함대에서 애플리케이션을 관리할 수 있도록 하는 Virtual Kubernetes(vK8s)라는 객체를 제공합니다. 사용자는 배포 매니페스트 파일과 함께 표준 Kubernetes 방법(예: Kubeconfig 파일 및 Kubernetes API)을 사용하여 애플리케이션을 배포하고, 애플리케이션을 배포해야 하는 사이트 세그먼트(또는 전체 플릿)를 표시합니다. 그러면 Volterra의 Virtual Kubernetes(vK8s)가 플릿의 모든 사이트(또는 세그먼트)에 애플리케이션을 배포하는 책임을 맡습니다. 애플리케이션 배포 중에 연결이나 인프라 장애 등의 오류가 발생하면 Volterra Virtual Kubernetes는 결국 일관된 모델이라는 Kubernetes 패러다임에 따라 배포를 계속 재시도합니다. 다음 스크린샷은 사용자가 "jpn-all-sites"라는 가상 사이트에 "kuard"라는 애플리케이션을 배포하는 예를 보여줍니다( Kubernetes-up-and-running-demo-app 참조). 이 사이트는 플릿에서 140개 사이트를 선택합니다. 새로운 배포를 추가하려면 사용자는 "배포 추가"를 클릭하고 가상 사이트의 관점에서 배포 위치를 지정하여 새로운 배포를 추가하기만 하면 됩니다.

적절한 레이블이 지정된 새로운 사이트가 플릿에 추가되면, 새로운 사이트가 자동으로 가상 사이트(이 예에서는 jpn-all-sites)에 추가되고 플릿 구성(이 예에서는 Kuard 배포)이 새로 추가된 사이트에 자동으로 적용되어 운영팀의 부담을 줄이고 인적 오류를 없앱니다.

함대 관찰성

가상 사이트와 가상 쿠버네티스(vK8s)는 구성에만 사용되는 것이 아니라 플릿 내 분산 사이트의 상태를 집계하는 데에도 사용됩니다. 이것은 사용자가 모든 사이트의 상태를 하나하나 파악하고 정보를 집계하는 도구를 작성해야 하는 다른 솔루션과 비교했을 때 정말 강력한 도구입니다. 이 시스템은 모든 사이트의 상태를 단일 창에서 자동으로 집계하여 고객 운영 팀의 운영 복잡성을 줄여줍니다. 수집된 상태에는 애플리케이션 배포 상태, 사이트 상태, 애플리케이션 상태 등 여러 측면이 포함됩니다.

다음 스크린샷에 표시된 것처럼 사용자는 지도에서 모든 사이트의 상태를 빠르게 살펴볼 수 있습니다. 건강 점수가 75보다 크면(녹색), 40~75 사이이면(주황색), 40보다 작으면 빨간색으로 표시됩니다. 상태 점수는 연결성, 안정성, 보안, 성능(즉, 리소스 소비)을 종합한 점수입니다.

사용자는 사이트 상태와 함께 모든 사이트의 연결성을 집계하여 볼 수도 있습니다. 그림 10에서는 사이트를 Volterra 백본에 연결하는 각 링크의 연결 상태도 시각화하여 보여줍니다. 그림 11에서 보듯이, 사용자는 상태에 따라 성능이 낮은 링크를 클릭하여 요청 및 오류에 대한 자세한 통계를 확인하고 연결 문제를 해결할 수 있습니다.

다음으로, 사용자는 사이트 전체의 CPU 및 메모리 부하 분포를 통해 모든 사이트의 집계된 정보를 볼 수 있습니다. 이 정보는 IT 관리자나 사이트 관리자가 어떤 사이트가 많이 활용되고 있고 리소스가 고갈될 위험이 있는지 파악하는 데 유용합니다. 사이트 관리자는 리소스 소비가 임계값을 초과하면 알림을 받도록 설정할 수 있습니다. 이 스크린샷에서 사용자는 사이트의 절반이 사용 가능한 메모리의 75% 이상을 사용하고 있음을 확인할 수 있습니다. 이 정보를 얻기 위해 개별 사이트를 클릭할 필요도 없고, 추가 도구를 작성할 필요도 없습니다.