대규모 Kubernetes 클러스터를 운영하기에 적합한 컨트롤 플레인이란?

F5 에코시스템 | 2020년 1월 24일

이 블로그에서는 Volterra가 사용자가 애플리케이션과 인프라를 하나의 플릿처럼 운영할 수 있도록 지원하는 방법을 설명합니다. 또한 Volterra의 컨트롤 플레인 기반 접근 방식이 대규모 애플리케이션 클러스터 플릿의 운영을 어떻게 간소화하는지 살펴보고, Google Anthos, Azure Arc, Rancher 등의 다른 멀티 클러스터 관리 플레인 접근 방식과 비교합니다.

이쯤 되면 우리가 멀티 클러스터 관리를 단지 마케팅 차원에서 포장해 플릿 운영이라고 부르는 것은 아닌지 궁금하실 수 있습니다! 멀티 클러스터 관리와 플릿 운영 방식은 서로 다른 사용 사례를 다루며, 아키텍처도 근본적으로 다릅니다. 멀티 클러스터 방식은 클러스터 수가 비교적 적고 사용자가 일관된 운영 모델을 통해 이러한 인프라 클러스터를 관리하려는 시나리오를 위해 설계되었습니다. 반면 플릿 방식은 로봇, 자동차, 산업용 게이트웨이의 K8s 클러스터나 수십 개의 퍼블릭 클라우드 리전처럼 대규모 클러스터가 존재하고, 사용자가 이러한 대규모 클러스터에 동일한 애플리케이션과 네트워크/보안 구성을 배포하려는 시나리오를 위해 설계되었습니다. 다음 두 섹션에서는 멀티 클러스터 방식과 플릿 운영 방식을 더 자세히 설명하고 비교합니다.

멀티 클러스터 접근 방식

멀티 클러스터 관리 방식은 단일 팀이 비교적 적은 수의 클러스터를 운영하는 사용 사례를 지원하도록 설계되었습니다. 이러한 시나리오의 예로는 장애 영향 범위를 줄이기 위해 몇 개의 가용 영역에 수십 개의 클러스터를 분산하는 경우가 있습니다. 마찬가지로 규제 요건을 충족하기 위해 몇 개의 리전에 여러 클러스터를 배치할 수도 있습니다.

다음 두 가지 예는 멀티 클러스터 솔루션의 작동 방식을 개괄적으로 보여줍니다:

구성

그림 1과 같이 Rancher의 멀티 클러스터 방식을 사용하여 애플리케이션을 배포하는 예를 살펴보겠습니다. 멀티 클러스터 방식에서는 고객이 애플리케이션을 배포할 대상 사이트를 하나씩 선택합니다. 대상 사이트를 하나씩 선택하는 이 방식은 클러스터가 몇 개뿐일 때는 효과적입니다. 하지만 클러스터가 수천 개에 달하는 환경을 고려하여 설계된 방식은 아닙니다.

그림 1

관측 가능성

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

클러스터 1:

클러스터 2:

그림 2

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

export KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f checkoutservice.yaml

하지만 배포, 업그레이드, 정책, 리소스 예약 등 각 작업에 맞는 자동화를 구축해야 합니다. 이러한 자동화는 여러 클러스터에서 개별 작업을 수행할 뿐만 아니라 장애 상황도 처리해야 합니다. 또한 일부 클러스터에서의 베타 테스트나 모든 클러스터에 걸친 롤링 업그레이드와 같은 복잡한 시나리오에서는 자동화가 점점 더 복잡해집니다. 저희는 프로세스 초기에 이를 인식하고, 다음에 설명할 플릿 운영 방식을 사용해 이러한 모든 기능을 제공하는 분산형 컨트롤 플레인을 구축했습니다.

Volterra의 플릿 운영 접근 방식

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

의도가 적용되면 시스템에서 사용자가 플릿의 상태와 건전성을 확인할 수 있습니다. 즉, 사용자는 단일 화면에서 플릿 내 모든 사이트의 인프라 및 애플리케이션 건전성을 종합적으로 파악할 수 있으므로 고객 운영 팀의 운영 복잡성이 줄어듭니다. 사용자는 건전성을 확인하기 위해 각 사이트나 클러스터를 일일이 클릭하거나 정보를 취합하는 자동화 도구를 작성할 필요가 없습니다.

Volterra의 플릿 운영 접근 방식은 세 가지 주요 구성 요소인 세분화, 구성 및 관찰 가능성으로 이루어져 있으며, 이에 대해서는 다음 섹션에서 살펴보겠습니다.

플릿 세분화

사용자는 개발, 테스트, 프로덕션 컴퓨팅 사이트 등 다양한 사이트를 하나의 플릿으로 운영하는 경우가 많습니다. 개발 워크로드는 개발 사이트에만 배포해야 한다는 등의 조직 정책에 따라 각 워크로드를 특정 사이트 세그먼트에 배포해야 합니다. 사용자는 키와 값의 두 부분으로 구성된 레이블을 사용하여 사이트에 유연하게 태그를 지정할 수 있습니다. 예시는 다음과 같습니다:

레이블 키=region. 레이블 값 = US-West, JP-North, JP-south
모델 연도=(2015, 2016, 2017, 2018)
function=(스프레이, 용접)

사이트에 태그를 지정한 후 사용자는 레이블 키-값 조건을 사용하여 “가상 사이트”를 정의할 수 있습니다. 멀티 클라우드 환경에서는 예를 들어 사이트에 dev, pre-prod, prod 태그를 지정할 수 있습니다. 다음 그림 3은 앞서 설명한 레이블 키-값을 사용하는 로보틱스 사용 사례의 예를 보여 줍니다.

그림 3

다음은 사용자가 blend/go-sdk 구문을 사용하여 가상 사이트를 생성할 수 있는 Volterra 구성 코드 조각입니다. 이 예에서는 각 사이트에 레이블 키 key=ves.io/country와 레이블 값 ves-io-jpn이 지정되었습니다.

그림 4

사용자는 사전에 플릿의 세그먼트를 정의한 다음, 사이트를 프로비저닝할 때 태그를 지정하여 해당 플릿에 포함하는 운영 모델에 익숙합니다. 가상 사이트는 이러한 기존 운영 모델과 완벽하게 부합합니다. 새 사이트가 적절한 태그와 함께 프로비저닝되면 별도의 수동 단계 없이 이전에 정의된 가상 사이트에 자동으로 포함됩니다. 또한 Volterra는 하드웨어 제조업체나 퍼블릭 클라우드 유형과 같은 사전 프로비저닝 정보를 검색하여 시스템 태그를 미리 채웁니다. 사용자는 선택적으로 자동 검색된 이러한 태그를 사용하여 가상 사이트를 정의할 수 있습니다.

플릿 구성

플릿 구성 기능은 다음 세 가지 예를 통해 가장 잘 설명할 수 있습니다:

네트워크/보안 정책 구성 -- 각 클러스터가 특정 URL(예: github.com)과 통신할 수 있어야 하는 새로운 서비스를 고객이 배포하는 경우를 예로 들어 보겠습니다. 일반적으로 사용자는 허용 목록 방식을 사용하므로 클러스터는 지정된 대상에만 접근할 수 있습니다. 따라서 이 새로운 서비스를 배포하려면 사용자가 각 클러스터에서 네트워크 정책을 수정하여 허용 목록에 github.com을 추가해야 합니다. 또한 고객은 모든 사이트에 배포하기 전에 몇몇 테스트 사이트에서 이를 시험해 보고자 합니다. Volterra에서 이를 구현하기 위해 고객은 먼저 Volterra SaaS 콘솔에서 플릿의 일부를 선택하는 “test” 가상 사이트를 정의합니다. 그런 다음 URL 허용 목록(이 예에서는 github.com)과 같은 네트워크 정책을 정의하고 이를 “test” 가상 사이트에 적용합니다. Volterra의 분산 제어 플레인은 위에서 정의한 대로 가상 사이트가 선택한 각 사이트의 로컬 제어 플레인에 네트워크 정책을 전송합니다. 각 사이트의 로컬 제어 플레인은 네트워크 정책을 적용하고 사이트별 규칙 적중 통계를 수집합니다. 서비스가 예상대로 작동하는 것을 확인한 후 고객은 플릿의 나머지 사이트를 선택하는 “prod” 가상 사이트에 네트워크 정책을 적용할 수 있습니다. 다음은 JSON 및 Volterra 시스템의 UI를 사용한 구성 예시입니다.

그림 5

그림 6

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

그림 7

전체 플릿에 애플리케이션 배포 -- Volterra는 사용자가 Kubernetes API를 사용하여 전체 플릿의 애플리케이션을 관리할 수 있도록 Virtual Kubernetes(vK8s)라는 객체를 제공합니다. 사용자는 배포 매니페스트 파일과 함께 표준 Kubernetes 방식(즉, Kubeconfig 파일 및 Kubernetes API)을 사용하여 애플리케이션을 배포하고, 애플리케이션을 배포할 사이트 그룹(또는 전체 플릿)을 지정합니다. 그러면 Volterra의 Virtual Kubernetes(vK8s)가 플릿의 모든 사이트(또는 지정된 그룹)에 애플리케이션을 배포하는 작업을 담당합니다. 애플리케이션 배포 중 연결 또는 인프라 장애와 같은 문제가 발생하면 Volterra Virtual Kubernetes는 최종적 일관성 모델이라는 Kubernetes 패러다임에 따라 배포를 계속 재시도합니다. 다음 스크린샷은 사용자가 플릿 내 140개 사이트를 선택하는 “jpn-all-sites”라는 가상 사이트에 “kuard”라는 애플리케이션을 배포하는 예를 보여 줍니다(참조: Kubernetes-up-and-running-demo-app). 새 배포를 추가하려면 “Add Deployment”를 클릭하고 가상 사이트를 기준으로 배포 위치를 지정하기만 하면 됩니다.

그림 8

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

플릿 관측성

가상 사이트와 가상 Kubernetes(vK8s)는 구성에만 사용되는 것이 아니라, 플릿 내에 분산된 여러 사이트의 상태를 통합하는 데에도 사용됩니다. 이는 사용자가 각 사이트의 상태를 일일이 확인하고 정보를 통합하기 위한 도구를 직접 작성해야 하는 다른 솔루션과 비교할 때 매우 강력한 기능입니다. 시스템은 모든 사이트의 상태를 단일 화면에 자동으로 통합하여 고객 운영팀의 운영 복잡성을 줄여 줍니다. 수집되는 상태 정보에는 애플리케이션 배포 상태, 사이트 상태, 애플리케이션 상태 등 다양한 항목이 포함됩니다.

사용자는 다음 스크린샷과 같이 지도에서 모든 사이트의 상태를 한눈에 빠르게 확인할 수 있습니다. 색상은 상태 점수가 75보다 높으면 녹색, 40~75이면 주황색, 40보다 낮으면 빨간색으로 표시됩니다. 상태 점수는 연결성, 안정성, 보안 및 성능(즉, 리소스 사용량)을 종합한 점수입니다.

그림 9

사용자는 사이트 상태와 함께 모든 사이트의 연결성을 집계한 보기도 확인할 수 있습니다. 그림 10과 같이 사이트를 Volterra 백본에 연결하는 각 링크의 연결 상태도 시각적으로 표시됩니다. 사용자는 상태가 좋지 않은 링크를 클릭하여 요청 및 오류에 대한 상세 통계를 확인하고, 그림 11과 같이 연결 문제를 해결할 수 있습니다.

그림 10

그림 11

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