Hé Habr !
Nous représentons l'équipe de la plateforme Exness. Nos confrères avaient déjà écrit un article sur . Aujourd'hui, nous souhaitons partager notre expérience de migration de services vers Kubernetes.
Pour commencer, nous vous proposons quelques chiffres pour mieux comprendre ce qui sera abordé :
- Notre service de développement est composé de plus de 100 personnes, dont plus de 10 équipes différentes dotées de processus QA, DevOps et Scrum autonomes. Pile de développement - Python, PHP, C++, Java et Golang.
- La taille des environnements de test et de production est d'environ 2000 1.6 conteneurs chacun. Ils exécutent Rancher vXNUMX sur leur propre virtualisation et sous VMware.
Motivation
Comme on dit, rien n'est éternel et Rancher a annoncé il y a longtemps la fin du support de la version 1.6. Oui, en plus de trois ans, nous avons appris à le préparer et à résoudre les problèmes qui se présentent, 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 soit faire presque tout, soit rien.
Même si la virtualisation propriétaire permettait un meilleur contrôle sur le stockage des données et leur sécurité, elle imposait des coûts d'exploitation difficiles à accepter compte tenu de la croissance constante de l'entreprise, du nombre de projets et de leurs exigences.
Nous voulions suivre les normes IaC et, si nécessaire, obtenir de la capacité rapidement, dans n'importe quel emplacement géographique et sans blocage de fournisseur, et également pouvoir l'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 opérationnels d’interaction avec la plateforme qui fournit l’énergie.
Bien sûr, la première chose qui nous est venue à l’esprit était Kubernetes, mais nous ne nous sommes pas enthousiasmés et avons fait quelques recherches pour voir si c’était le bon choix. Nous avons évalué uniquement des solutions open source et, dans une bataille injuste, Kubernetes a gagné sans condition.
Vint ensuite la question du choix d’un outil de création de clusters. Nous avons comparé les solutions les plus populaires : kops, kubespray, kubeadm.
Au début, kubeadm nous semblait être un chemin trop compliqué, un peu comme une sorte d'inventeur d'un « vélo », et les kops n'avaient pas assez de flexibilité.
Et le gagnant était :
Nous avons commencé à expérimenter notre propre virtualisation et AWS, en essayant de recréer quelque chose à peu près similaire à notre précédent modèle de gestion des ressources, où tout le monde partageait le même « cluster ». Et maintenant, nous avons notre premier cluster de 10 petites machines virtuelles, dont quelques-unes sont situées dans AWS. Nous avons commencé à essayer de migrer les équipes là-bas, tout semblait « bien » et l'histoire pouvait être terminée, mais...
Premiers problèmes
Ansible est sur lequel kubespray est construit, ce n'est pas un outil qui vous permet de suivre IaC : lors de la mise en service/désaffectation de nœuds, quelque chose se passait constamment mal et une sorte d'intervention était nécessaire, et lors de l'utilisation de différents systèmes d'exploitation, le playbook se comportait différemment. . À mesure que le nombre d'équipes et de nœuds dans le cluster augmentait, nous avons commencé à remarquer que le playbook prenait de plus en plus de temps à compléter, et par conséquent, notre record était de 3,5 heures, qu'en est-il du vôtre ? 🙂
Et il semble que kubespray ne soit qu'Ansible, et tout est clair à première vue, mais :
Au début du voyage, la tâche consistait à lancer des capacités uniquement dans AWS et sur la virtualisation, mais ensuite, comme cela arrive souvent, les exigences ont changé.
À la lumière de cela, il est devenu clair que notre ancien modèle consistant à combiner les ressources dans un seul système d'orchestration n'était pas adapté - dans le cas où les clusters sont très distants 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 des NodeSelector mal installés pouvaient voler vers l'hôte « étranger » d'une autre équipe et y utiliser des ressources, et si la teinte était définie, il y avait des demandes constantes indiquant que l'un ou l'autre service ne fonctionnait pas, pas distribué correctement en raison du facteur humain. Un autre problème consistait à calculer le coût, en particulier compte tenu des problèmes de distribution des services entre les nœuds.
Une autre histoire a été la délivrance des droits aux salariés : chaque équipe voulait être « à la tête » du cluster et le gérer entièrement, ce qui pourrait provoquer un effondrement complet, puisque les équipes sont fondamentalement indépendantes les unes des autres.
Que faire?
Compte tenu de ce qui précède et des souhaits 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 le troisième cluster :
Puis nous avons commencé à réfléchir : disons que 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 certains tests.
Kubernetes complet viendrait ! Il s'avère qu'il s'agit d'une sorte de MultiKubernetes.
Dans le même temps, nous devrons tous, d’une manière ou d’une autre, maintenir tous ces clusters, être capables d’en gérer facilement l’accès, ainsi qu’en créer de nouveaux et mettre hors service les anciens sans intervention manuelle.
Un certain temps s'est écoulé depuis le début de notre voyage dans le monde de Kubernetes, 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.
Lors de la première étape de nos recherches, Rancher Labs avait déjà réalisé la première version de la version 2, mais même si elle pouvait être augmentée très rapidement en lançant un conteneur sans dépendances externes avec quelques paramètres ou en utilisant le HELM Chart officiel, cela semblait grossier à nous, et nous ne savions pas si nous pouvions nous fier à cette décision pour savoir si elle serait développée ou rapidement abandonnée. Le paradigme cluster = clics dans l'interface utilisateur elle-même ne nous convenait pas non plus, et nous ne voulions pas nous lier à RKE, car il s'agit d'un outil plutôt étroitement ciblé.
La version Rancher 2.2 avait déjà une apparence plus fonctionnelle et, avec les précédentes, possédait un tas de fonctionnalités intéressantes prêtes à l'emploi, telles que l'intégration avec de nombreux fournisseurs externes, un point unique de distribution des droits et des fichiers kubeconfig, le lancement d'un kubectl image avec vos droits dans l'interface utilisateur, les espaces de noms imbriqués, également appelés projets.
Il y avait aussi une communauté déjà formée autour de Rancher 2, et un fournisseur appelé HashiCorp Terraform a été créé pour la gérer, ce qui nous a aidé à tout mettre en place.
Qu'est-il arrivé
En conséquence, nous nous sommes retrouvés avec un petit cluster exécutant Rancher, accessible à tous les autres clusters, ainsi qu'à de nombreux clusters qui y sont connectés, dont l'accès à n'importe lequel d'entre eux peut être accordé aussi simplement que l'ajout d'un utilisateur au répertoire ldap, indépendamment de où il se trouve et quelles ressources du fournisseur il utilise.
À l'aide de gitlab-ci et Terraform, un système a été créé qui vous permet de créer un cluster de n'importe quelle configuration chez des fournisseurs de cloud ou notre propre infrastructure et de les connecter à Rancher. Tout cela est fait dans le style IaC, où chaque cluster est décrit par un référentiel et son état est versionné. Dans le même temps, la plupart des modules sont connectés à partir de référentiels externes, il ne reste donc plus qu'à transmettre des variables ou à décrire votre configuration personnalisée pour les instances, ce qui permet de réduire le pourcentage de répétition de code.
Bien sûr, notre voyage est loin d'être terminé et il reste encore de nombreuses tâches intéressantes à venir, comme un point de travail unique avec les journaux et les métriques de tous les clusters, un maillage de services, des gitops pour gérer les charges dans un multicluster et bien plus encore. Nous espérons que vous trouverez notre expérience intéressante !
L'article a été rédigé par A. Antipov, A. Ganush, Platform Engineers.
Source: habr.com