출처｜KubeAdmiral 오픈소스 커뮤니티
2014년에 오픈 소스로 공개된 이후 Kubernetes는 오케스트레이션 및 예약 시스템의 사실상 표준이 되어 개발자에게 큰 편의성을 제공합니다. 점점 더 많은 기업이 클라우드 네이티브를 채택함에 따라 글로벌 클라우드 인프라의 규모가 여전히 가속화되고 있습니다. 동시에 Kubernetes 커뮤니티 버전의 5,000개 노드 단일 클러스터는 더 이상 기업 수준의 대규모 애플리케이션 시나리오를 충족할 수 없습니다. 비용 절감과 효율성 향상, 원격 재해 복구, 환경 격리에 대한 요구가 높아지면서 멀티 클러스터 관리의 필요성이 점점 더 커지고 있습니다.
배경
비즈니스의 급속한 발전과 함께 ByteDance 내의 Kubernetes 클러스터 수도 계속해서 증가하고 있으며, 클러스터 수는 500개를 초과하고, 애플리케이션 사본 수는 0~20,000개에 이릅니다. 가장 큰 애플리케이션은 100W 코어를 초과합니다.
초기에는 격리 및 보안 문제로 인해 바이트의 각 사업 부문에는 독점적인 클러스터가 있었습니다. 이러한 독점 클러스터는 리소스 섬을 발생시켰고, 이는 궁극적으로 리소스의 탄력적인 효율성에 영향을 미쳤습니다. 이는 먼저 각 비즈니스 라인에 대해 독립적인 버퍼를 유지해야 한다는 필요성에 반영됩니다. 두 번째로 비즈니스는 클러스터에 깊이 연결되어 있으며, 비즈니스는 많은 수의 클러스터를 인식하고 클러스터 간에도 애플리케이션에 리소스를 할당합니다. 운영 리소스 측면에서 비즈니스와 클러스터를 깊이 인식해야 하며, 이는 궁극적으로 다양한 비즈니스 라인 간의 리소스 회전 속도 저하, 낮은 자동화 효율성 및 차선의 배포 속도로 이어집니다. 따라서 페더레이션을 도입하고, 애플리케이션과 클러스터 간의 바인딩 관계를 분리하고, 각 비즈니스 라인의 리소스를 풀링하고, 버퍼를 줄이고, 리소스의 자동화 효율성을 향상시켜야 합니다.
멀티클라우드와 하이브리드 클라우드가 점점 업계의 주류가 되고, 쿠버네티스가 클라우드 네이티브 운영 체제가 되면서 다양한 인프라가 더욱 추상화되고 표준화되어 애플리케이션에 더욱 통합된 표준 인터페이스를 제공합니다. 이를 바탕으로 우리는 분산 클라우드 시나리오에서 클라우드 네이티브 시스템의 기반으로 페더레이션을 도입하고, 애플리케이션에 대한 통합 플랫폼 입구를 제공하고, 클러스터 전체에 애플리케이션을 배포하는 기능을 개선하고, 전체 애플리케이션 배포 및 예약 작업을 훌륭하게 수행하기를 희망합니다. 클러스터링하고 기본 시나리오에서 여러 클라우드를 관리합니다.
KubeFed V2 바이트 구현
멀티 클러스터 관리로 인한 문제에 직면한 인프라 팀은 2019년 커뮤니티 KubeFed V2를 기반으로 클러스터 페더레이션 구축을 시작했습니다 . KubeFed V2는 마스터 클러스터와 멤버 클러스터를 구별합니다. 사용자는 마스터 클러스터에서 "페더레이션 개체"를 생성하고 여러 KubeFed 컨트롤러는 페더레이션 개체를 기반으로 멤버 클러스터 간에 리소스를 배포합니다. 연합 객체에는 객체의 배포 상태를 선언하기 위한 템플릿(객체 템플릿), 배치(대상 클러스터) 및 재정의(클러스터 차별화)라는 세 가지 필드가 있습니다. 예를 들어 배포 배포를 위해 마스터 클러스터에 아래와 같이 FederatedDeployment를 생성할 수 있습니다.
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod template 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
# 分发到指定的两个集群中
clusters:
- name: cluster1
- name: cluster2
overrides:
# 在cluster2中修改副本数为5
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
배포 및 ReplicaSet의 경우 KubeFed는 ReplicaSchedulingPreference(RSP)를 통해 고급 복제본 배포 전략을 지정할 수도 있습니다. 사용자는 RSP에서 각 클러스터의 복제본의 가중치, 최소 및 최대 수를 구성할 수 있으며, RSP 컨트롤러는 자동으로 배치를 계산하고 필드를 재정의하며 FederatedDeployment 또는 FederatedReplicaSet를 업데이트합니다.
그러나 구현 과정에서 KubeFed가 프로덕션 환경의 요구 사항을 충족할 수 없다는 사실을 발견했습니다.
- 낮은 리소스 활용도 - KubeFed의 복제본 예약 정책 RSP는 각 구성원 클러스터에 대해 정적 가중치만 설정할 수 있으며 클러스터 리소스 변경에 유연하게 대응할 수 없으므로 서로 다른 구성원 클러스터의 배포 수준이 고르지 않습니다.
- 변경이 충분히 원활하지 않습니다. 확장 또는 축소할 때 인스턴스가 고르지 않게 분산되어 재해 복구 기능이 저하되는 경우가 많습니다.
- 예약 시맨틱 제한 - 상태 비저장 리소스에 대한 지원만 우수하고 상태 저장 서비스 및 작업과 같은 다양한 리소스에 대한 지원이 부족하며 예약 확장성이 낮습니다.
- 액세스 비용이 높습니다. 연합 개체 생성을 통해 배포해야 하며 기본 API와 호환되지 않으며 사용자와 상위 플랫폼의 사용 습관을 완전히 바꿔야 합니다.
Bytedance 인프라의 발전과 함께 상태 저장 서비스, 스토리지, 오프라인 운영 및 기계 학습과 같은 비즈니스 시나리오가 클라우드 네이티브를 더욱 수용하고 다양한 지원을 제공함에 따라 효율성, 규모, 성능 및 비용에 대한 더 높은 요구 사항을 제시했습니다. 특수한 시나리오에서 클러스터 간 오케스트레이션 및 예약 기능이 점점 더 중요해지고 있습니다. 이에 우리는 2021년 말 KubeFed v2를 기반으로 한 차세대 클러스터 연합 시스템 KubeAdmiral을 개발했습니다.
KubeAdmiral 아키텍처 진화
KubeAdmiral이라는 이름은 원래 함대 사령관을 의미하는 admiral([ˈædm(ə)rəl]로 발음)에서 파생되었습니다. Kube(rnetes) 접두사가 추가된 것은 도구에 강력한 Kubernetes 다중 클러스터 조정 및 예약 기능이 있음을 의미합니다.
KubeAdmiral은 Kubernetes 기본 API를 지원하고 풍부하고 확장 가능한 일정 프레임워크를 제공하며 일정 알고리즘 및 배포 프로세스를 신중하게 다듬습니다. 몇 가지 주목할만한 기능은 아래에 자세히 설명되어 있습니다.
1. 풍부한 다중 클러스터 스케줄링 기능
스케줄러는 페더레이션된 시스템의 핵심 구성 요소입니다. 복제본 예약 시나리오에서는 스케줄링 논리가 페더레이션된 다중 클러스터 재해 복구에 직접적인 영향을 미칩니다. , 자원 효율성, 안정성 등 중요한 기능입니다.
KubeFed는 복제본 예약을 위한 RSP 스케줄러를 제공하지만 사용자 정의 및 확장성이 매우 제한적이고 논리적 추상화가 부족하여 동작을 변경하려면 코드를 수정해야 합니다. 동시에 상태 저장 서비스에 대한 지원도 부족합니다. , 직업 자원 등
KubeAdmiral은 더욱 풍부한 스케줄링 의미를 도입하고, 레이블, 얼룩 등을 통해 보다 유연한 클러스터 선택을 지원하고, 상태 저장 작업 유형 리소스 스케줄링 기능을 제공하며, 종속성 추적 스케줄링과 같은 최적화를 도입합니다. 스케줄링의 의미는 아래와 같이 PropagationPolicy 개체를 통해 구성할 수 있습니다.
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# 提供多种集群选择方式，最终结果取交集
placement: # 手动指定集群与权重
- cluster: Cluster-01
preferences:
weight: 40
- cluster: Cluster-02
preferences:
weight: 30
- cluster: Cluster-03
preferences:
weight: 40
clusterSelector: # 类似Pod.Spec.NodeSelector，通过label过滤集群
IPv6: "true"
clusterAffinity: # 类似Pod.Spec.NodeAffinity，通过label过滤集群，语法比clusterSelector更加灵活
- matchExpressions:
- key: region
operator: In
values:
- beijing
tolerations: # 通过污点过滤集群
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
schedulingMode: Divide # 是否为副本数调度
stickyCluster: false # 仅在首次调度，适合有状态服务或作业类服务
maxClusters: 1 # 最多可分发到多少个子集群，适合有状态服务或作业类服务
disableFollowerScheduling: false # 是否开启依赖调度
동시에 다른 클러스터에 예약된 리소스의 경우 OverridePolicy를 사용하여 클러스터 이름이나 레이블을 기준으로 구별할 수 있습니다.
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# 最终匹配的集群是所有rule匹配集群的交集
overrideRules:
- targetClusters:
# 通过名称匹配集群
clusters:
- member1
- member2
# 通过标签selector匹配集群
clusterSelector:
region: beijing
az: zone1
# 通过基于标签的affinity匹配集群
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- beijing
- key: provider
operator: In
values:
- volcengine
# 在匹配的集群中，使用jsonpatch语法修改第一个容器的镜像
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
2. 스케줄링 기능 확장 가능
KubeAdmiral은 kube-scheduler의 설계를 참조하고 확장 가능한 스케줄링 프레임워크를 제공합니다. 이는 스케줄링 로직을 필터, 점수, 선택 및 복제의 4단계로 추상화하고 상대적으로 독립적인 여러 플러그인을 사용하여 각 단계에서 로직을 구현합니다. 위 그림에 표시된 PropagaionPolicy의 거의 모든 필드는 독립적인 내장 스케줄링 플러그인에 의해 구현됩니다. 플러그인은 서로 간섭하지 않으며 스케줄러는 글로벌 오케스트레이션에 필요한 플러그인을 호출합니다.
또한 KubeAdmiral 스케줄러는 http 프로토콜을 통해 외부 플러그인과의 상호 작용도 지원합니다. 사용자는 일정 관리를 위해 회사 내부 시스템에 액세스하는 요구 사항을 충족하기 위해 맞춤형 일정 논리를 작성하고 배포할 수 있습니다. 내장된 플러그인은 보다 일반적인 기능을 구현하고 외부 플러그인을 보완합니다. 사용자는 연합 제어 플레인을 변경하지 않고도 최소한의 비용으로 스케줄링 로직을 확장할 수 있으며 KubeAdmiral의 강력한 다중 클러스터 배포 기능을 사용하여 스케줄링을 수행할 수 있습니다. 결과가 효과적입니다.
3. 신청예약 실패시 자동 마이그레이션
복제본으로 예약된 리소스의 경우 KubeAdmiral은 각 구성원 클러스터에 적합한 복제본 수를 계산하고 복제본 수 필드를 덮어쓴 다음 이를 각 구성원 클러스터에 전달합니다. 이 프로세스를 리소스가 전달된 후 각 구성원 클러스터의 kube- 스케줄러는 리소스에 해당하는 포드를 해당 노드에 할당합니다. 이 프로세스는 단일 클러스터 스케줄링이 됩니다.
리소스가 발행된 후 노드 오프라인, 리소스 부족, 만족스럽지 못한 노드 선호도 등으로 인해 단일 클러스터 스케줄링이 실패하는 경우가 있습니다. 처리하지 않으면 사용 가능한 비즈니스 인스턴스가 예상보다 낮아집니다. KubeAdmiral은 예약 실패 시 자동 마이그레이션 기능을 제공하며, 활성화되면 구성원 클러스터에서 예약할 수 없는 복제본을 식별하고 이를 중복 복제본을 수용할 수 있는 클러스터로 마이그레이션하여 다중 클러스터 리소스 회전을 실현할 수 있습니다.
예를 들어, 3개의 클러스터 A, B, C에는 동일한 가중치를 갖는 6개의 복사본이 할당되며, 초기 연합 스케줄링 후에 각 클러스터에는 2개의 복사본이 할당됩니다. 클러스터 C의 두 복사본이 단일 클러스터에 예약되지 않으면 KubeAdmiral은 자동으로 이를 A와 B로 마이그레이션합니다.
| 무리 | ㅏ | 비 | 씨 |
|---|---|---|---|
| 가중치 | 1 | 1 | 1 |
| 초기 연합 스케줄링 인스턴스 수 | 2 | 2 | 2 |
| 단일 클러스터에서 예약되지 않는 복제본 | 0 | 0 | 2 |
| 자동 마이그레이션 후 통합 예약 인스턴스 수 | 삼 | 삼 | 0 |
4. 클러스터 수위에 따라 리소스를 동적으로 예약합니다.
다중 클러스터 환경에서는 시스템이 온라인 및 오프라인으로 전환됨에 따라 각 클러스터의 리소스 수준이 동적으로 변경됩니다. KubeFed RSP에서 제공하는 정적 가중치 스케줄링 복제본에만 의존하면 배포 속도가 너무 높은 클러스터의 수위가 고르지 않게 될 수 있습니다. 서비스 업그레이드 중에 문제가 발생하기 쉬우며, 포드가 오랫동안 보류된 것으로 보이며 배포 속도가 낮은 클러스터 리소스를 완전히 활용할 수 없습니다. 이에 KubeAdmiral은 클러스터 수위 기반의 동적 가중치 스케줄링을 도입하여 각 클러스터의 총 자원량과 사용량을 수집하여 가용량을 계산하고, 가용 자원량을 복사 스케줄링의 가중치로 사용하여 궁극적으로 클러스터의 로드 밸런싱을 달성합니다. 각 멤버 클러스터의 배포율은 95% 이상으로 유지됩니다.
5. 복사 할당 알고리즘 개선
KubeFed의 복사 할당 알고리즘으로 인해 규모를 확장하거나 축소할 때 인스턴스 수가 예상과 벗어나는 경우가 많습니다. 예를 들면 다음과 같습니다.
30개의 인스턴스가 3개의 멤버 클러스터 A, B, C에 배포됩니다. rsp.rebalance = false인 경우 사용자는 15개의 인스턴스로 축소하려고 합니다.
축소 전:
| 무리 | ㅏ | 비 | 씨 |
|---|---|---|---|
| 가중치 | 10 | 10 | 10 |
| 인스턴스 수 | 15 | 15 | 0 |
축소 후:
| 무리 | ㅏ | 비 | 씨 |
|---|---|---|---|
| 가중치 | 10 | 10 | 10 |
| 인스턴스 수 | 15 | 0 | 0 |
이러한 현상이 나타나는 이유는 KubeFed의 복제 알고리즘이 클러스터에 현재 존재하는 인스턴스 수를 먼저 미리 할당한 후, 각 클러스터의 가중치에 따라 나머지 인스턴스를 할당하기 때문입니다. 현재 클러스터에 복제본이 너무 많으면 이는 인스턴스 분포와 가중치 사이에 심각한 편차를 초래합니다.
KubeAdmiral은 KubeFed의 복사 알고리즘을 최적화하여 최종 분포를 가중치 분포에 최대한 가깝게 만드는 동시에 확장 및 수축 중에 예기치 않은 마이그레이션이 발생하지 않도록 합니다. 예를 들어 인스턴스 30개에서 15개로 확장하면 단순화된 알고리즘 프로세스는 다음과 같습니다.
- 현재 분포 = [15, 15, 0], 총 복제본: 30
- 원하는 배포 = [5, 5, 5], 총 복제본: 15
- 거리 = 원하는 - 현재 = [-10, -10, 5], 총 거리: 15
- 축소 시나리오의 경우 양수항 distance = [-10, -10, 0]을 제거합니다.
- 거리를 가중치로 사용하여 차이 15를 재분배합니다: [-7, -8, 0]
- 최종 스케줄링 결과: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| 무리 | ㅏ | 비 | 씨 |
|---|---|---|---|
| 가중치 | 10 | 10 | 10 |
| 인스턴스 수 | 8 | 7 | 0 |
6. 기본 리소스 지원
사용자가 완전히 호환되지 않는 새로운 API를 사용해야 하는 KubeFed와 달리 KubeAdmiral은 Kubernetes 단일 클러스터 사용자의 사용 습관을 충족하고 기본 Kubernetes API에 대한 지원을 제공합니다. 사용자가 기본 리소스(예: 배포)를 생성한 후 Federate Controller는 이를 다른 컨트롤러에서 사용할 수 있도록 페더레이션된 내부 개체로 자동 변환합니다. 낮은 문턱.
KubeAdmiral은 여기서 멈추지 않습니다. 단일 클러스터에서 Kubernetes의 기본 컨트롤러는 일부 리소스의 상태를 업데이트하여 현재 상태를 반영합니다. 사용자 또는 상위 계층 시스템은 배포 상태 및 상태와 같은 정보를 보기 위해 상태를 사용하는 경우가 많습니다. 여러 클러스터에서 리소스 상태가 여러 클러스터에 분산되어 있으므로 전체 상태를 보려면 사용자가 각 클러스터의 리소스 상태를 하나씩 확인해야 하므로 보기가 단편화되고 운영 및 유지 관리 효율성이 떨어지는 등의 문제가 발생합니다. 이 문제를 해결하고 네이티브 리소스를 원활하게 지원하기 위해 KubeAdmiral은 상태 집계 기능을 제공합니다. Status Aggregator는 여러 멤버 클러스터의 리소스 상태를 병합 및 통합하고 이를 다시 네이티브 리소스에 기록하므로 사용자가 다중을 인식할 필요가 없습니다. - 클러스터 토폴로지. 연합 전체의 자원 현황을 한눈에 확인할 수 있습니다.
현재와 미래
KubeAdmiral은 수년 동안 Byte Group의 비즈니스 TCE 플랫폼을 강력하게 지원하고 210,000개 이상의 머신과 1천만 개 이상의 포드를 관리하며 Douyin 및 Toutiao와 같은 대규모 기업에 의해 연마되었으며 많은 가치를 축적했습니다. 실제 경험. 커뮤니티에 환원하기 위해 KubeAdmiral은 GitHub에서 공식적으로 오픈소스화되었습니다. 동시에 Volcano Engine은 DCP(Distributed Cloud Native Platform)인 KubeAdmiral을 기반으로 새로운 엔터프라이즈급 멀티 클라우드 및 멀티 클러스터 관리 모델을 구축하고 있으므로 계속 지켜봐 주시기 바랍니다.
앞으로도 우리는 다음과 같은 측면에서 지속적으로 발전해 나갈 계획입니다.
- 상태 저장, 작업 유형 및 기타 리소스의 조정 및 예약 기능을 지속적으로 개선하고 자동 마이그레이션 및 가격 비교 예약과 같은 고급 기능을 개발하여 배치 컴퓨팅의 멀티 클라우드 및 멀티 클러스터 시대의 도래를 수용합니다.
- 사용자 경험을 개선하고 즉시 사용 가능한 솔루션을 제공하여 사용자의 인지 부하를 더욱 줄입니다.
- 관찰 가능성을 향상시키고, 로그 및 모니터링 지표를 최적화하고, 스케줄러의 해석 가능성을 향상시킵니다.
- 원클릭 페더레이션 및 멀티 클러스터 마이그레이션과 같은 기능을 탐색하여 멀티 클러스터 아키텍처의 잠재력을 최대한 활용하세요.
다중 클러스터 오케스트레이션 및 스케줄링은 본질적으로 간단하지 않습니다. 보편적이고 완전한 다중 클러스터 연합 시스템은 다양한 시나리오에서 개선되어야 합니다. KubeAdmiral 커뮤니티에 관심을 갖고 참여하는 모든 분들을 환영합니다. 다양한 제안을 해주세요!
GitHub : https://github.com/kubewharf/kubeadmiral
동료 치킨 "오픈 소스" deepin-IDE 및 마침내 부트스트랩을 달성했습니다! 좋은 친구, Tencent는 Switch를 "생각하는 학습 기계"로 전환했습니다. Tencent Cloud의 4월 8일 실패 검토 및 상황 설명 RustDesk 원격 데스크톱 시작 재구성 웹 클라이언트 WeChat의 SQLite 기반 오픈 소스 터미널 데이터베이스 WCDB의 주요 업그레이드 TIOBE 4월 목록: PHP 사상 최저치로 떨어졌고 FFmpeg의 아버지인 Fabrice Bellard는 오디오 압축 도구인 TSAC를 출시했으며 Google은 대규모 코드 모델인 CodeGemma를 출시했습니다 . 오픈소스라서 너무 좋아요 - 오픈소스 사진 및 포스터 편집기 도구