큐브-온-큐브, 메타클러스터, 벌집, 리소스 분배

쌀. 1. Alibaba Cloud의 Kubernetes 생태계

2015년부터 Kubernetes용 Alibaba Cloud Container Service(ACK)는 Alibaba Cloud에서 가장 빠르게 성장하는 클라우드 서비스 중 하나입니다. 수많은 고객에게 서비스를 제공하고 Alibaba의 내부 인프라와 회사의 기타 클라우드 서비스도 지원합니다.

세계적 수준의 클라우드 제공업체가 제공하는 유사한 컨테이너 서비스와 마찬가지로 우리의 최우선 순위는 안정성과 가용성입니다. 따라서 수만 개의 Kubernetes 클러스터를 위해 확장 가능하고 전 세계적으로 액세스 가능한 플랫폼이 만들어졌습니다.

이 기사에서는 클라우드 인프라에서 다수의 Kubernetes 클러스터를 관리한 경험과 기본 플랫폼의 아키텍처를 공유합니다.

기입

Kubernetes는 클라우드의 다양한 워크로드에 대한 사실상의 표준이 되었습니다. 그림과 같이 위의 1에 따르면 현재 Kubernetes 클러스터에서 상태 저장 및 상태 비저장 애플리케이션과 애플리케이션 관리자 등 점점 더 많은 Alibaba Cloud 애플리케이션이 실행되고 있습니다. Kubernetes 관리는 인프라를 구축하고 유지 관리하는 엔지니어에게 항상 흥미롭고 진지한 토론 주제였습니다. Alibaba Cloud와 같은 클라우드 제공업체의 경우 확장 문제가 가장 중요합니다. 이 규모로 Kubernetes 클러스터를 관리하는 방법은 무엇입니까? 우리는 이미 거대한 10개 노드로 구성된 Kubernetes 클러스터를 관리하기 위한 모범 사례를 다루었습니다. 물론 이것은 흥미로운 스케일링 문제입니다. 그러나 또 다른 척도가 있습니다: 수량 클러스터 자체.

우리는 많은 ACK 사용자들과 이 주제에 대해 논의했습니다. 이들 중 대부분은 수백 개는 아니더라도 수십 개의 중소 규모 Kubernetes 클러스터를 실행하기로 선택합니다. 여기에는 타당한 이유가 있습니다. 잠재적인 피해를 제한하고, 여러 팀을 위해 클러스터를 분리하고, 테스트용 가상 클러스터를 생성하는 것입니다. ACK가 이 사용 모델을 통해 전 세계 사용자에게 서비스를 제공하려는 경우 20개 이상의 지역에 걸쳐 많은 수의 클러스터를 안정적이고 효율적으로 관리해야 합니다.

쌀. 2. 엄청난 수의 Kubernetes 클러스터를 관리하는 데 따른 문제

이 규모로 클러스터를 관리하는 데 있어 주요 과제는 무엇입니까? 그림에서 볼 수 있듯이 처리해야 할 네 가지 문제가 있습니다.

• 이질

ACK는 표준, 서버리스, Edge, Windows 등을 포함한 다양한 유형의 클러스터를 지원해야 합니다. 다양한 클러스터에는 다양한 옵션, 구성 요소 및 호스팅 모델이 필요합니다. 일부 고객은 특정 사례에 맞게 사용자 정의하는 데 도움이 필요합니다.

• 다양한 클러스터 크기

클러스터의 크기는 몇 개의 포드가 있는 노드 두 개부터 수천 개의 포드가 있는 수만 개의 노드까지 다양합니다. 리소스 요구 사항도 크게 다릅니다. 부적절한 리소스 할당은 성능에 영향을 미치거나 심지어 오류를 일으킬 수도 있습니다.

• 다른 버전

Kubernetes는 매우 빠르게 발전하고 있습니다. 몇 달에 한 번씩 새 버전이 출시됩니다. 고객은 항상 새로운 기능을 기꺼이 시도하고 싶어합니다. 따라서 그들은 새 버전의 Kubernetes에 테스트 로드를 배치하고 안정적인 버전에 프로덕션 로드를 배치하려고 합니다. 이 요구 사항을 충족하기 위해 ACK는 안정적인 버전을 유지하면서 고객에게 Kubernetes의 새로운 버전을 지속적으로 제공해야 합니다.

• 보안 규정 준수

클러스터는 여러 지역에 분산되어 있습니다. 따라서 다양한 안전 요구 사항과 공식 규정을 준수해야 합니다. 예를 들어 유럽의 클러스터는 GDPR을 준수해야 하며, 중국의 금융 클라우드에는 추가 보호 계층이 있어야 합니다. 이러한 요구 사항은 필수이며 이를 무시하는 것은 용납될 수 없습니다. 이는 클라우드 플랫폼 클라이언트에게 엄청난 위험을 초래하기 때문입니다.

ACK 플랫폼은 위의 문제 대부분을 해결하도록 설계되었습니다. 현재 전 세계 10만 개가 넘는 Kubernetes 클러스터를 안정적이고 안정적으로 관리하고 있습니다. 몇 가지 주요 디자인/아키텍처 원칙을 포함하여 이것이 어떻게 달성되었는지 살펴보겠습니다.

디자인

큐브 온 큐브 및 벌집

중앙 집중식 계층 구조와 달리 셀 기반 아키텍처는 일반적으로 단일 데이터 센터 이상으로 플랫폼을 확장하거나 재해 복구 범위를 확장하는 데 사용됩니다.

Alibaba Cloud의 각 지역은 여러 영역(AZ)으로 구성되며 일반적으로 특정 데이터 센터에 해당합니다. 대규모 지역(예: 황저우)에는 ACK를 실행하는 수천 개의 Kubernetes 클라이언트 클러스터가 있는 경우가 많습니다.

ACK는 Kubernetes 자체를 사용하여 이러한 Kubernetes 클러스터를 관리합니다. 즉, 클라이언트 Kubernetes 클러스터를 관리하기 위해 실행되는 Kubernetes 메타클러스터가 있다는 의미입니다. 이 아키텍처를 "kube-on-kube"(KoK)라고도 합니다. KoK 아키텍처는 클러스터 배포가 간단하고 결정적이기 때문에 클라이언트 클러스터 관리를 단순화합니다. 더 중요한 것은 기본 Kubernetes 기능을 재사용할 수 있다는 것입니다. 예를 들어 배포를 통해 API 서버를 관리하고 etcd 연산자를 사용하여 여러 etcd를 관리합니다. 이러한 재귀는 항상 특별한 즐거움을 가져다줍니다.

클라이언트 수에 따라 여러 Kubernetes 메타클러스터가 한 지역 내에 배포됩니다. 우리는 이러한 메타클러스터를 셀이라고 부릅니다. 전체 영역의 오류로부터 보호하기 위해 ACK는 단일 지역에서 다중 활성 배포를 지원합니다. 즉, 메타클러스터는 Kubernetes 클라이언트 클러스터 마스터 구성 요소를 여러 영역에 배포하고 동시에, 즉 다중 활성 모드에서 실행합니다. 마스터의 신뢰성과 효율성을 보장하기 위해 ACK는 구성 요소 배치를 최적화하고 API 서버와 etcd가 서로 가까이 있는지 확인합니다.

이 모델을 사용하면 Kubernetes를 효율적이고 유연하며 안정적으로 관리할 수 있습니다.

메타클러스터 자원 계획

이미 언급했듯이 각 지역의 메타클러스터 수는 클라이언트 수에 따라 다릅니다. 하지만 어느 시점에 새로운 메타클러스터를 추가해야 할까요? 이는 전형적인 자원 계획 문제입니다. 일반적으로 기존 메타클러스터의 리소스가 모두 소진되면 새 메타클러스터를 생성하는 것이 일반적입니다.

예를 들어 네트워크 리소스를 살펴보겠습니다. KoK 아키텍처에서 클라이언트 클러스터의 Kubernetes 구성 요소는 메타클러스터에 포드로 배포됩니다. 우리는 사용 터웨이 (그림 3)은 Alibaba Cloud가 컨테이너 네트워크 관리를 위해 개발한 고성능 플러그인입니다. 다양한 보안 정책을 제공하며 Alibaba Cloud ENI(탄력적 네트워킹 인터페이스)를 통해 고객의 가상 프라이빗 클라우드(VPC)에 연결할 수 있습니다. 메타클러스터의 노드, 포드 및 서비스 전반에 네트워크 리소스를 효과적으로 배포하려면 가상 프라이빗 클라우드의 메타클러스터 내 사용량을 주의 깊게 모니터링해야 합니다. 네트워크 리소스가 끝나면 새 셀이 생성됩니다.

각 메타클러스터에서 최적의 클라이언트 클러스터 수를 결정하기 위해 비용, 밀도 요구 사항, 리소스 할당량, 안정성 요구 사항 및 통계도 고려합니다. 새로운 메타클러스터를 생성하기로 한 결정은 이 모든 정보를 바탕으로 내려집니다. 소규모 클러스터는 향후 크게 확장될 수 있으므로 클러스터 수를 그대로 유지하더라도 리소스 소비가 증가한다는 점에 유의하시기 바랍니다. 우리는 일반적으로 각 클러스터가 성장할 수 있도록 충분한 여유 공간을 남겨 둡니다.

쌀. 3. Terway 네트워크 아키텍처

클라이언트 클러스터 전반에 걸쳐 마법사 구성 요소 크기 조정

마법사 구성 요소에는 다양한 리소스 요구 사항이 있습니다. 이는 클러스터의 노드 및 포드 수, APIServer와 상호 작용하는 비표준 컨트롤러/운영자 수에 따라 달라집니다.

ACK에서는 각 Kubernetes 클라이언트 클러스터의 크기와 런타임 요구 사항이 다릅니다. 마법사 구성 요소 배치에 대한 범용 구성은 없습니다. 대규모 클라이언트에 대해 실수로 리소스 제한을 낮게 설정하면 해당 클러스터가 로드를 처리할 수 없습니다. 모든 클러스터에 대해 보수적으로 높은 제한을 설정하면 리소스가 낭비됩니다.

신뢰성과 비용 사이의 미묘한 균형을 찾기 위해 ACK는 유형 시스템을 사용합니다. 즉, 소형, 중형, 대형의 세 가지 유형의 클러스터를 정의합니다. 각 유형에는 별도의 리소스 할당 프로필이 있습니다. 유형은 마법사 구성 요소의 로드, 노드 수 및 기타 요인에 따라 결정됩니다. 클러스터 유형은 시간이 지남에 따라 변경될 수 있습니다. ACK는 이러한 요소를 지속적으로 모니터링하고 이에 따라 유형을 상향/하향시킬 수 있습니다. 클러스터 유형이 변경되면 최소한의 사용자 개입으로 리소스 할당이 자동으로 업데이트됩니다.

우리는 이러한 변경이 보다 원활하게 이루어지고 보다 경제적으로 이루어질 수 있도록 보다 세밀한 크기 조정과 보다 정확한 유형 업데이트를 통해 이 시스템을 개선하기 위해 노력하고 있습니다.

쌀. 4. 지능형 다단식 스위칭

규모에 따른 클라이언트 클러스터의 진화

이전 섹션에서는 다수의 Kubernetes 클러스터를 관리하는 몇 가지 측면을 다루었습니다. 그러나 해결해야 할 또 다른 문제가 있습니다. 바로 클러스터의 진화입니다.

Kubernetes는 클라우드 세계의 "Linux"입니다. 지속적으로 업데이트되고 더욱 모듈화됩니다. 우리는 지속적으로 고객에게 새 버전을 제공하고, 취약점을 수정하고, 기존 클러스터를 업데이트해야 하며, 수많은 관련 구성요소(CSI, CNI, 장치 플러그인, 스케줄러 플러그인 등)를 관리해야 합니다.

Kubernetes 구성 요소 관리를 예로 들어 보겠습니다. 우선 우리는 연결된 모든 구성 요소를 등록하고 관리하기 위한 중앙 집중식 시스템을 개발했습니다.

쌀. 5. 유연하고 플러그 가능한 구성 요소

계속 진행하기 전에 업데이트가 성공했는지 확인해야 합니다. 이를 위해 우리는 구성 요소의 기능을 확인하는 시스템을 개발했습니다. 업데이트 전후에 확인이 수행됩니다.

쌀. 6. 클러스터 구성요소 사전 점검

이러한 구성 요소를 빠르고 안정적으로 업데이트하기 위해 지속적인 배포 시스템은 부분 발전(회색조), 일시 중지 및 기타 기능을 지원합니다. 표준 Kubernetes 컨트롤러는 이 사용 사례에 적합하지 않습니다. 따라서 클러스터 구성 요소를 관리하기 위해 플러그인 및 보조 제어 모듈(사이드카 관리)을 포함한 전문 컨트롤러 세트를 개발했습니다.

예를 들어 BroadcastJob 컨트롤러는 각 작업자 시스템의 구성 요소를 업데이트하거나 각 시스템의 노드를 확인하도록 설계되었습니다. 브로드캐스트 작업은 DaemonSet처럼 클러스터의 각 노드에서 Pod를 실행합니다. 그러나 DaemonSet은 항상 Pod를 오랫동안 실행하는 반면 BroadcastJob은 Pod를 축소합니다. 또한 브로드캐스트 컨트롤러는 새로 가입된 노드에서 포드를 시작하고 필요한 구성 요소로 노드를 초기화합니다. 2019년 XNUMX월, 회사 내에서 직접 사용하고 있는 OpenKruise 자동화 엔진의 소스 코드를 공개했습니다.

쌀. 7. OpenKurise는 모든 노드에서 브로드캐스트 작업 실행을 구성합니다.

고객이 올바른 클러스터 구성을 선택할 수 있도록 서버리스, Edge, Windows 및 Bare Metal 프로필을 포함하여 사전 정의된 프로필 세트도 제공합니다. 환경이 확장되고 고객의 요구 사항이 증가함에 따라 지루한 설정 프로세스를 단순화하기 위해 더 많은 프로필을 추가할 예정입니다.

쌀. 8. 다양한 시나리오를 위한 고급스럽고 유연한 클러스터 프로필

데이터 센터 전반에 걸친 글로벌 관측 가능성

아래 그림과 같이. 9, Alibaba Cloud 컨테이너 클라우드 서비스는 전 세계 XNUMX개 지역에 배포되었습니다. 이러한 규모를 고려할 때 ACK의 주요 목표 중 하나는 실행 중인 클러스터의 상태를 쉽게 모니터링하여 클라이언트 클러스터에 문제가 발생할 경우 신속하게 상황에 대응할 수 있도록 하는 것입니다. 즉, 모든 지역의 클라이언트 클러스터로부터 실시간으로 효율적이고 안전하게 통계를 수집하고 그 결과를 시각적으로 표시할 수 있는 솔루션을 마련해야 합니다.

쌀. 9. XNUMX개 지역에 Alibaba Cloud 컨테이너 서비스의 글로벌 배포

많은 Kubernetes 모니터링 시스템과 마찬가지로 Prometheus를 기본 도구로 사용합니다. 각 메타클러스터에 대해 Prometheus 에이전트는 다음 측정항목을 수집합니다.

• 호스트 리소스(CPU, 메모리, 디스크 등) 및 네트워크 대역폭과 같은 OS 지표.
• kube-apiserver, kube-controller-manager 및 kube-scheduler와 같은 메타클러스터 및 클라이언트 클러스터 관리 시스템에 대한 지표입니다.
• kubernetes-state-metrics 및 cadvisor의 메트릭.
• 디스크 쓰기 시간, 데이터베이스 크기, 노드 간 연결 처리량 등과 같은 etcd 측정항목

글로벌 통계는 일반적인 다계층 집계 모델을 사용하여 수집됩니다. 각 메타클러스터의 모니터링 데이터는 먼저 각 지역에서 집계된 후 전체 그림을 보여주는 중앙 서버로 전송됩니다. 모든 것이 연합 메커니즘을 통해 작동합니다. 각 데이터 센터의 Prometheus 서버는 해당 데이터 센터에서 메트릭을 수집하고 중앙 Prometheus 서버는 모니터링 데이터 집계를 담당합니다. AlertManager는 중앙 Prometheus에 연결하고 필요한 경우 DingTalk, 이메일, SMS 등을 통해 경고를 보냅니다. 시각화 - Grafana를 사용합니다.

그림 10에서 모니터링 시스템은 세 가지 수준으로 나눌 수 있습니다.

• 경계 수준

중심에서 가장 먼 레이어입니다. Prometheus Edge Server는 각 메타클러스터에서 실행되어 동일한 네트워크 도메인 내의 메타 및 클라이언트 클러스터에서 메트릭을 수집합니다.

• 캐스케이드 레벨

Prometheus 캐스케이드 레이어의 기능은 여러 지역에서 모니터링 데이터를 수집하는 것입니다. 이러한 서버는 중국, 아시아, 유럽 및 미국과 같은 더 큰 지리적 단위 수준에서 작동합니다. 클러스터가 성장함에 따라 지역을 나눌 수 있으며, 그러면 새로운 대규모 지역 각각에 캐스케이드 수준의 Prometheus 서버가 나타납니다. 이 전략을 사용하면 필요에 따라 원활하게 확장할 수 있습니다.

• 중앙 수준

중앙 Prometheus 서버는 모든 캐스케이드 서버에 연결하여 최종 데이터 집계를 수행합니다. 안정성을 위해 두 개의 중앙 Prometheus 인스턴스가 서로 다른 영역에서 생성되어 동일한 캐스케이드 서버에 연결되었습니다.

쌀. 10. Prometheus 연합 메커니즘을 기반으로 한 글로벌 다단계 모니터링 아키텍처

개요

Kubernetes 기반 클라우드 솔루션은 계속해서 업계를 변화시키고 있습니다. Alibaba Cloud 컨테이너 서비스는 안전하고 안정적인 고성능 호스팅을 제공하며 최고의 Kubernetes 클라우드 호스팅 중 하나입니다. Alibaba Cloud 팀은 오픈 소스와 오픈 소스 커뮤니티의 원칙을 굳게 믿습니다. 우리는 클라우드 기술 운영 및 관리 분야의 지식을 계속해서 공유할 것입니다.

출처 : habr.com