Get best of the week

K8S Multicluster Journey

Bonjour, Habr!

Nous représentons l'équipe de la plateforme Exness. Plus tôt, nos collègues ont déjà écrit un article sur les images prêtes pour la production pour les k8 . Aujourd'hui, nous voulons partager l'expérience de la migration de services dans Kubernetes.



Pour commencer, nous vous proposons quelques chiffres pour une meilleure compréhension de ce qui sera discuté:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


Comme on dit, rien ne dure éternellement, et Rancher a annoncé assez longtemps la fin du support de la version 1.6. Oui, depuis plus de trois ans, nous avons appris à cuisiner et à résoudre les problèmes qui se posent, mais nous sommes de plus en plus souvent confrontés à des problèmes qui ne seront jamais résolus. Rancher 1.6 dispose également d'un système ossifié de délivrance de droits, dans lequel vous pouvez faire presque tout ou rien.

Propre virtualisation, même si elle a permis un meilleur contrôle du stockage et de la sécurité des données, mais a imposé des coûts opérationnels, difficiles à supporter avec la croissance constante de l'entreprise, le nombre de projets et les exigences pour eux.

Nous voulions suivre les normes IaC et, si nécessaire, obtenir le courant rapidement, dans n'importe quel emplacement géographique et sans verrou de fournisseur, et pouvoir également les abandonner rapidement.

Premiers pas


Tout d'abord, nous voulions nous appuyer sur des technologies et des solutions modernes qui permettraient aux équipes d'avoir un cycle de développement plus rapide et de minimiser les coûts d'exploitation pour l'interaction avec une plateforme qui fournit de l'énergie. 
 
Bien sûr, la première chose qui nous est venue à l'esprit était Kubernetes, mais nous ne nous sommes pas excités et avons fait quelques recherches sur le sujet du bon choix. Nous n'avons évalué que des solutions open source et Kubernetes a été battu sans condition dans une bataille déloyale.  

Vient ensuite la question du choix d'un outil de création de clusters. Nous avons comparé les solutions les plus populaires: kops, kubespray, kubeadm.

Pour commencer, le kubeadm nous semblait plutôt trop compliqué, plutôt une sorte d'inventeur du "vélo", et le kops manquait de souplesse.

Et le gagnant est sorti:



Nous avons commencé à expérimenter sur notre propre virtualisation et AWS, essayant de recréer une ressemblance approximative de notre modèle de gestion des ressources précédent, où tout le monde utilise le même «cluster». Et maintenant, nous avons le premier cluster de 10 petites machines virtuelles, dont deux sont dans AWS. Nous avons commencé à essayer de faire migrer les équipes là-bas, tout semblait être «bien», et l'histoire pourrait être terminée, mais ...

Premiers problèmes


Ansible est ce sur quoi kubespray est construit, ce n'est pas l'outil qui permet de suivre l'IaC: quelque chose s'est mal passé lors de l'entrée / sortie des nœuds, et une intervention a été nécessaire, et lors de l'utilisation de différents OS, le playbook s'est comporté en différentes manières. Avec le nombre croissant de commandes et de nœuds dans le cluster, nous avons commencé à remarquer que le playbook prenait de plus en plus de temps, au final, notre record était de 3,5 heures, et le vôtre? :)

Et il semble que kubespray soit simplement Ansible, et tout est clair à première vue, mais:



Au début du voyage, il y avait une tâche pour exécuter les capacités uniquement dans AWS et la virtualisation, mais comme cela arrive souvent, les exigences ont changé.
 


À la lumière de cela, il est devenu clair que notre ancien modèle de combinaison des ressources dans un système d'orchestration n'était pas approprié - dans le cas où les clusters sont très éloignés et sont gérés par différents fournisseurs. 

En outre. Lorsque toutes les équipes travaillent au sein du même cluster, divers services avec NodeSelector installé de manière incorrecte peuvent voler vers l'hôte «étranger» d'une autre équipe et y utiliser des ressources, et dans le cas de la mise en attente, il y avait des appels constants que tel ou tel service ne fonctionnait pas, non distribué correctement en raison du facteur humain. Un autre problème était le calcul du coût, compte tenu notamment des problèmes de répartition des services par nœuds.

Une autre histoire a été la question des droits des employés: chaque équipe voulait être «à la tête» du cluster et le gérer pleinement, ce qui pourrait provoquer un effondrement complet, car les équipes sont fondamentalement indépendantes les unes des autres.

Comment être


Compte tenu de ce qui précède et du souhait des équipes d'être plus indépendantes, nous avons tiré une conclusion simple: une équipe - un cluster. 

Nous en avons donc un deuxième:



Et puis un troisième cluster: 



Puis nous avons commencé à penser: disons, dans un an nos équipes auront plus d'un cluster? Dans différentes zones géographiques, par exemple, ou sous le contrôle de différents prestataires? Et certains d'entre eux voudront pouvoir déployer rapidement un cluster temporaire pour tous les tests. 



Serait plein Kubernetes! Il s'agit d'une sorte de MultiKubernetes, il s'avère. 

Dans le même temps, nous devrons tous prendre en charge tous ces clusters, pouvoir en contrôler facilement l'accès, en créer de nouveaux et retirer les anciens sans intervention manuelle.

Depuis le début de notre voyage dans le monde de Kubernetes, un certain temps s'est écoulé et nous avons décidé de réexaminer les solutions disponibles. Il s'est avéré qu'il existe déjà sur le marché - Rancher 2.2.



À la première étape de nos recherches, Rancher Labs a déjà fait la première version de la version 2, mais bien qu'elle puisse être augmentée très rapidement en exécutant le conteneur sans dépendances externes avec quelques paramètres ou en utilisant le graphique HELM officiel, cela nous a semblé grossier et nous ne savions pas si compter sur cette décision, qu'elle soit développée ou rapidement abandonnée. Le paradigme cluster = clics lui-même dans l'interface utilisateur ne nous convenait pas non plus, et nous ne voulions pas nous attacher à RKE, car il s'agit d'un outil assez étroit d'esprit. 

La version Rancher 2.2 avait déjà un aspect plus efficace et, avec les précédentes, avait un tas de fonctionnalités intéressantes, telles que l'intégration avec de nombreux fournisseurs externes, un point de distribution unique des droits et des fichiers kubeconfig, le lancement d'une image kubectl avec vos droits dans l'interface utilisateur, des espaces de noms imbriqués, alias projets. 

Une communauté s'est déjà formée autour de Rancher 2, et le fournisseur HashiCorp Terraform a été créé pour le gérer, ce qui nous a aidés à tout assembler.

Qu'est-il arrivé


En conséquence, nous avons obtenu un petit cluster dans lequel Rancher est lancé, accessible à tous les autres clusters, ainsi qu'à de nombreux clusters qui lui sont associés, l'accès à chacun d'entre eux pouvant être émis aussi simplement que l'ajout d'un utilisateur au répertoire ldap, quel que soit l'endroit où il se trouve est localisé et les ressources dont le fournisseur utilise.

En utilisant gitlab-ci et Terraform, un système a été créé qui vous permet de créer un cluster de n'importe quelle configuration dans les fournisseurs de cloud ou notre propre infrastructure et de les connecter à Rancher. Tout cela se fait dans le style IaC, où chaque cluster est décrit par un référentiel et son état est versionné. Dans ce cas, la plupart des modules sont connectés à partir de référentiels externes de sorte qu'il ne reste plus qu'à transférer des variables ou à décrire leur configuration personnalisée pour les instances, ce qui contribue à réduire le pourcentage de répétabilité du code.



Bien sûr, notre voyage est loin d'être terminé et il reste encore de nombreuses tâches intéressantes à accomplir, comme un point de travail unique avec les journaux et les métriques de tous les clusters, le maillage de service, les gitops pour gérer les charges dans un multicluster, et bien plus encore. Nous espérons que vous serez intéressé par notre expérience! 

L'article a été écrit par A. Antipov, A. Ganush, Platform Engineers. 

More articles:


All Articles