Source｜Communauté open source KubeAdmiral
Adresse du projet : https://github.com/kubewharf/kubeadmiral
Depuis son lancement en open source en 2014, Kubernetes est devenu le standard de facto pour les systèmes d'orchestration et de planification, offrant aux développeurs une grande commodité. Alors que de plus en plus d'entreprises adoptent le cloud natif, l'échelle de l'infrastructure cloud mondiale continue de s'accélérer. Le cluster unique de 5 000 nœuds de la version communautaire Kubernetes n'est plus en mesure de répondre aux scénarios d'applications à grande échelle au niveau de l'entreprise. De plus en plus d'entreprises choisissent d'utiliser une architecture multi-cloud pour répondre à leurs besoins. Avec les exigences de réduction des coûts et d'amélioration de l'efficacité, de reprise après sinistre à distance et d'isolation environnementale, la nécessité d'une gestion multicluster devient de plus en plus évidente.
arrière-plan
Avec le développement rapide des affaires, le nombre de clusters Kubernetes au sein de ByteDance a également continué de croître. Le nombre de clusters dépasse 500 et le nombre de copies d'applications varie de 0 à 20 000. La plus grande application dépasse 100 W de cœur.
Au début, pour des raisons d'isolement et de sécurité, chaque secteur d'activité de Byte disposait de clusters exclusifs. Ces clusters exclusifs créaient des îlots de ressources, ce qui affectait finalement l'efficacité élastique des ressources. Cela se reflète d'abord dans la nécessité de maintenir des tampons indépendants pour chaque secteur d'activité ; deuxièmement, l'entreprise est profondément liée au cluster, l'entreprise connaît un grand nombre de clusters et alloue également des ressources à l'application entre les clusters. doit être profondément conscient de l'entreprise et des clusters en termes de ressources opérationnelles, ce qui conduit finalement à une rotation lente des ressources entre les différents secteurs d'activité, à une faible efficacité d'automatisation et à des taux de déploiement sous-optimaux. Par conséquent, nous devons introduire une fédération, découpler les relations entre les applications et les clusters, mutualiser les ressources de chaque secteur d'activité, réduire les tampons et améliorer l'efficacité de l'automatisation des ressources.
Alors que le multicloud et le cloud hybride deviennent de plus en plus courants dans l'industrie et que Kubernetes devient un système d'exploitation cloud natif, diverses infrastructures sont encore plus abstraites et standardisées pour fournir des interfaces standard plus unifiées pour les applications. Sur cette base, nous espérons introduire la fédération comme base du système cloud natif dans les scénarios de cloud distribué, fournir une entrée de plate-forme unifiée pour les applications, améliorer la capacité de distribuer les applications entre les clusters, faire du bon travail dans la distribution et la planification des applications à travers clusters et gérez plusieurs infrastructures cloud dans des scénarios natifs.
Implémentation des octets KubeFed V2
Face aux défis posés par la gestion multi-cluster, l'équipe infrastructure a démarré la construction d'une fédération de cluster basée sur la communauté KubeFed V2 en 2019. KubeFed V2 fait la distinction entre les clusters maîtres et les clusters membres. Les utilisateurs créent des « objets de fédération » dans le cluster maître, et plusieurs contrôleurs KubeFed distribuent les ressources entre les clusters membres en fonction des objets de fédération. Il existe trois champs sur l'objet fédéré : Modèle (modèle d'objet), Placement (cluster cible) et Remplacements (différenciation de cluster) pour déclarer l'état de déploiement de l'objet. Par exemple, vous pouvez créer un FederatedDeployment comme indiqué ci-dessous dans le cluster maître pour la distribution Deployment :
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
Pour les déploiements et les ReplicaSets, KubeFed permet également de spécifier des stratégies de distribution de répliques plus avancées via ReplicaSchedulingPreference (RSP). Les utilisateurs peuvent configurer le poids, le nombre minimum et maximum de répliques de chaque cluster sur RSP, et le contrôleur RSP calcule automatiquement le placement, remplace les champs et met à jour FederatedDeployment ou FederatedReplicaSet.
Source de l'image : https://www.kubernetes.org.cn/5702.html
Cependant, lors de la mise en œuvre, nous avons constaté que KubeFed ne pouvait pas répondre aux exigences de l'environnement de production :
- Faible utilisation des ressources : la politique de planification des répliques de KubeFed, RSP, ne peut définir que des pondérations statiques pour chaque cluster membre et ne peut pas répondre de manière flexible aux modifications des ressources du cluster, ce qui entraîne des niveaux de déploiement inégaux des différents clusters membres.
- Les changements ne sont pas assez fluides : une répartition inégale des instances se produit souvent lors d'une mise à l'échelle vers le haut ou vers le bas, ce qui entraîne une réduction des capacités de reprise après sinistre.
- Limitations sémantiques de la planification : seulement une bonne prise en charge des ressources sans état, une prise en charge insuffisante de diverses ressources telles que des services et des emplois avec état, et une mauvaise évolutivité de la planification.
- Le coût d'accès est élevé : il doit être réparti via la création d'objets fédérés, il n'est pas compatible avec les API natives et les utilisateurs et la plateforme supérieure doivent changer complètement leurs habitudes d'utilisation.
Avec l'évolution de l'infrastructure de Bytedance, nous avons mis en avant des exigences plus élevées en matière d'efficacité, d'évolutivité, de performances et de coûts, car les scénarios commerciaux tels que les services avec état, le stockage, les opérations hors ligne et l'apprentissage automatique adoptent davantage le cloud natif et prennent en charge diverses Les capacités d’orchestration et de planification inter-clusters dans des scénarios spécialisés sont devenues de plus en plus importantes. Nous avons donc développé fin 2021 un système de fédération de clusters de nouvelle génération KubeAdmiral basé sur KubeFed v2.
Évolution de l'architecture KubeAdmiral
Le nom KubeAdmiral est dérivé d'amiral (prononcé [ˈædm(ə)rəl]), qui signifie à l'origine commandant de flotte. L'ajout du préfixe Kube(rnetes) signifie que l'outil dispose de puissantes capacités d'orchestration et de planification multicluster Kubernetes.
KubeAdmiral prend en charge l'API native Kubernetes, fournit un cadre de planification riche et évolutif et peaufine soigneusement l'algorithme de planification et le processus de distribution. Certaines fonctionnalités notables sont décrites en détail ci-dessous :
1. Riches capacités de planification multicluster
Le planificateur est le composant principal du système fédéré. Il est responsable de l'allocation des ressources aux clusters membres. Dans le scénario de planification des réplicas, il est également responsable du calcul des réplicas que chaque cluster mérite. Sa logique de planification affecte directement la reprise après sinistre multicluster fédéré. , l'efficacité des ressources, des fonctionnalités importantes telles que la stabilité.
KubeFed fournit le planificateur RSP pour la planification des répliques, mais sa personnalisation et son évolutivité sont très limitées, et son abstraction logique est insuffisante pour changer son comportement, il faut le compléter en modifiant le code. En même temps, il manque de prise en charge des services avec état. , ressources d'emploi, etc.
KubeAdmiral introduit une sémantique de planification plus riche, prend en charge une sélection de cluster plus flexible via des étiquettes, des taches, etc., fournit des capacités de planification de ressources avec état et de type tâche et introduit des optimisations telles que la planification de suivi des dépendances. La sémantique de la planification peut être configurée via l'objet PropagationPolicy comme indiqué ci-dessous :
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 # 是否开启依赖调度
Dans le même temps, pour les ressources planifiées sur différents clusters, OverridePolicy peut être utilisé pour différencier en fonction des noms ou des étiquettes de cluster :
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. Les capacités de planification peuvent être étendues
KubeAdmiral fait référence à la conception de Kube-scheduler et fournit un cadre de planification extensible. Il résume la logique de planification en quatre étapes : filtre, score, sélection et réplication, et utilise plusieurs plug-ins relativement indépendants pour implémenter sa logique à chaque étape. Presque tous les champs de PropagaionPolicy illustrés dans la figure ci-dessus sont implémentés par un plug-in de planification intégré indépendant. Les plug-ins n'interfèrent pas les uns avec les autres et le planificateur appelle les plug-ins requis pour l'orchestration globale.
De plus, le planificateur KubeAdmiral prend également en charge l'interaction avec des plug-ins externes via le protocole http. Les utilisateurs peuvent écrire et déployer une logique de planification personnalisée pour répondre aux besoins d'accès au système interne de l'entreprise pour la planification. Le plug-in intégré implémente des fonctionnalités plus générales et complète le plug-in externe. Les utilisateurs peuvent étendre la logique de planification à un coût minimal et sans modifier le plan de contrôle de la fédération, et s'appuyer sur la puissante capacité de distribution multicluster de KubeAdmiral pour effectuer la planification. des résultats efficaces.
3. Migration automatique en cas d'échec de la planification de l'application
Pour les ressources planifiées par les réplicas, KubeAdmiral calculera le nombre de réplicas que chaque cluster membre mérite, écrasera les champs de nombre de réplicas, puis les fournira à chaque cluster membre. Ce processus est appelé planification fédérée une fois les ressources livrées, le kube de chaque cluster membre ; Le planificateur allouera le pod correspondant à la ressource au nœud correspondant. Ce processus devient une planification à cluster unique.
Une fois les ressources émises, la planification d'un cluster unique peut parfois échouer en raison d'un nœud hors ligne, de ressources insuffisantes, d'une affinité de nœud insatisfaite, etc. Si elle n'est pas gérée, les instances métier disponibles seront inférieures aux attentes. KubeAdmiral fournit la fonction de migration automatique en cas d'échec de la planification. Lorsqu'il est activé, il peut identifier les réplicas non planifiables dans les clusters membres et les migrer vers des clusters pouvant accueillir des réplicas redondants, réalisant ainsi une rotation des ressources multiclusters.
Par exemple, trois clusters A, B et C se voient attribuer 6 copies de poids égal. Après la planification de la fédération initiale, chaque cluster se verra attribuer 2 copies. Si deux copies du cluster C ne parviennent pas à être planifiées dans un seul cluster, KubeAdmiral les migrera automatiquement vers A et B.
| grappe | UN | B | C |
|---|---|---|---|
| Poids | 1 | 1 | 1 |
| Nombre d'instances de planification fédérée initiales | 2 | 2 | 2 |
| Réplicas qui ne parviennent pas à être planifiés dans un seul cluster | 0 | 0 | 2 |
| Nombre d'instances de planification fédérée après la migration automatique | 3 | 3 | 0 |
4. Planifiez dynamiquement les ressources en fonction des niveaux d'eau du cluster
Dans un environnement multicluster, les niveaux de ressources de chaque cluster changent de manière dynamique à mesure que les machines se connectent et se déconnectent. S'appuyer uniquement sur les répliques de planification de poids statique fournies par KubeFed RSP peut facilement conduire à des niveaux d'eau inégaux pour les clusters avec des taux de déploiement trop élevés. sujets à des problèmes lors des mises à niveau du service, les pods semblent être en attente depuis longtemps et les ressources du cluster avec un faible taux de déploiement ne peuvent pas être pleinement utilisées. À cet égard, KubeAdmiral introduit une planification de poids dynamique basée sur le niveau d'eau du cluster. Il calcule la quantité disponible en collectant la quantité totale de ressources et l'utilisation de chaque cluster, et utilise la quantité de ressources disponibles comme poids de planification des copies, pour finalement parvenir à un équilibrage de charge. chaque cluster membre. Et le taux de déploiement de tous les clusters membres est maintenu au-dessus de 95 %.
5. Amélioration de l'algorithme d'allocation de copies
L'algorithme d'allocation de copies de KubeFed entraîne souvent un écart entre le nombre d'instances et les attentes lors d'une mise à l'échelle vers le haut ou vers le bas, par exemple :
30 instances sont réparties dans trois clusters membres A, B et C. Dans le cas de rsp.rebalance = false, l'utilisateur souhaite réduire à 15 instances :
Avant de rétrécir :
| grappe | UN | B | C |
|---|---|---|---|
| Poids | dix | dix | dix |
| Nombre de cas | 15 | 15 | 0 |
Après rétrécissement :
| grappe | UN | B | C |
|---|---|---|---|
| Poids | dix | dix | dix |
| Nombre de cas | 15 | 0 | 0 |
La raison de ce phénomène est que l'algorithme de réplique de KubeFed pré-attribue d'abord le nombre d'instances actuellement existantes dans le cluster, puis alloue les instances restantes en fonction du poids de chaque cluster. S'il y a trop de répliques dans le cluster actuel, il le fait. cela conduit à de sérieux écarts entre la distribution des instances et leur poids.
KubeAdmiral optimise l'algorithme de copie de KubeFed pour rendre la distribution finale aussi proche que possible d'une distribution de poids tout en garantissant qu'aucune migration inattendue ne se produit pendant l'expansion et la contraction. En prenant comme exemple la mise à l'échelle de 30 instances à 15, le processus d'algorithme simplifié est le suivant :
- distribution actuelle = [15, 15, 0], nombre total de répliques : 30
- distribution souhaitée = [5, 5, 5], nombre total de répliques : 15
- distance = souhaitée - courant = [-10, -10, 5], distance totale : 15
- Pour les scénarios de réduction, supprimez le terme positif distance = [-10, -10, 0]
- En utilisant la distance comme poids, redistribuez la différence 15 : [-7, -8, 0]
- Résultat final de la planification : [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| grappe | UN | B | C |
|---|---|---|---|
| Poids | dix | dix | dix |
| Nombre de cas | 8 | 7 | 0 |
6. Soutenir les ressources natives
Contrairement à KubeFed, qui oblige les utilisateurs à utiliser une nouvelle API totalement incompatible, KubeAdmiral répond aux habitudes d'utilisation des utilisateurs de cluster unique Kubernetes et prend en charge les API Kubernetes natives. Une fois que les utilisateurs ont créé des ressources natives (telles que le déploiement), le contrôleur fédéré les convertit automatiquement en objets internes fédérés pour une utilisation par d'autres contrôleurs. Les utilisateurs peuvent rapidement migrer d'un cluster unique vers une architecture multicluster et profiter de la commodité de plusieurs clusters avec un. seuil bas.
KubeAdmiral ne s'arrête pas là. Dans un seul cluster, le contrôleur natif de Kubernetes mettra à jour l'état de certaines ressources pour refléter leur état actuel. Les utilisateurs ou les systèmes de couche supérieure s'appuient souvent sur l'état pour afficher des informations telles que l'état de déploiement et l'état de santé. Dans plusieurs clusters, l'état des ressources est dispersé sur plusieurs clusters. Pour afficher l'état global, les utilisateurs doivent afficher l'état des ressources dans chaque cluster une par une, ce qui entraîne des problèmes tels que des vues fragmentées et une faible efficacité de fonctionnement et de maintenance. Afin de résoudre ce problème et de prendre en charge de manière transparente les ressources natives, KubeAdmiral fournit des capacités d'agrégation de statut qui fusionne et intègre le statut des ressources dans plusieurs clusters membres et les réécrit dans les ressources natives, afin que les utilisateurs n'aient pas besoin d'être conscients de plusieurs clusters. -topologie de cluster L'état des ressources dans l'ensemble de la fédération peut être observé en un coup d'œil.
présent et futur
KubeAdmiral est incubé au sein de Byte depuis de nombreuses années. Il soutient fortement la plate-forme commerciale TCE de Byte Group et gère plus de 210 000 machines et plus de 10 millions de pods. Il a été peaufiné par des entreprises à grande échelle telles que Douyin et Toutiao, et a accumulé beaucoup de valeur. expérience pratique. . Afin de redonner à la communauté, KubeAdmiral a été officiellement open source sur GitHub. Dans le même temps, Volcano Engine construit un nouveau modèle de gestion multi-cloud et multi-cluster au niveau de l'entreprise basé sur KubeAdmiral - la plateforme native du cloud distribué (DCP), alors restez à l'écoute.
En regardant vers l’avenir, nous prévoyons de continuer à évoluer dans les aspects suivants :
- Continuez à améliorer les capacités d'orchestration et de planification des ressources avec état, de type travail et autres, et développez des fonctionnalités avancées telles que la migration automatique et la planification de comparaison de prix pour accueillir l'avènement de l'ère multi-cloud et multi-cluster du calcul par lots.
- Améliorez l’expérience utilisateur et proposez des solutions prêtes à l’emploi pour réduire davantage la charge cognitive des utilisateurs.
- Améliorez l’observabilité, optimisez les indicateurs de journalisation et de surveillance et améliorez l’interprétabilité du planificateur.
- Explorez des fonctions telles que la fédération en un clic et la migration multi-cluster pour libérer pleinement le potentiel de l'architecture multi-cluster.
L'orchestration et la planification multiclusters ne sont pas simples par nature. Un système fédéré multicluster universel et complet doit être peaufiné dans divers scénarios. Nous attendons avec impatience que davantage d'amis prêtent attention et rejoignent la communauté KubeAdmiral. et faites-nous part de diverses suggestions!
GitHub ：https://github.com/kubewharf/kubeadmiral
Un camarade de poulet "open source" deepin-IDE et a finalement réalisé l'amorçage ! Bon gars, Tencent a vraiment transformé Switch en une « machine d'apprentissage pensante » Examen des échecs de Tencent Cloud le 8 avril et explication de la situation Reconstruction du démarrage du bureau à distance RustDesk Client Web La base de données de terminal open source de WeChat basée sur SQLite WCDB a inauguré une mise à niveau majeure Liste d'avril TIOBE : PHP est tombé à un plus bas historique, Fabrice Bellard, le père de FFmpeg, a sorti l'outil de compression audio TSAC , Google a sorti un gros modèle de code, CodeGemma , est-ce que ça va vous tuer ? C'est tellement bon qu'il est open source - outil d'édition d'images et d'affiches open source