Au fil des années, les 300 millions d'utilisateurs de Pinterest ont créé plus de 200 milliards d'épingles sur plus de 4 milliards de tableaux. Pour servir cette armée d'utilisateurs et cette vaste base de contenu, le portail a développé des milliers de services, allant des microservices pouvant être gérés par quelques processeurs jusqu'aux monolithes géants fonctionnant sur toute une flotte de machines virtuelles. Et puis le moment est venu où les yeux de l’entreprise se sont tournés vers les K8. Pourquoi le « cube » avait-il une belle apparence sur Pinterest ? Vous en apprendrez davantage grâce à notre traduction d'un article récent de .
Donc, des centaines de millions d’utilisateurs et des centaines de milliards de pins. Pour servir cette armée d’utilisateurs et cette vaste base de contenu, nous avons développé des milliers de services, allant des microservices pouvant être gérés par quelques processeurs jusqu’aux monolithes géants fonctionnant sur des flottes entières de machines virtuelles. De plus, nous disposons d’une variété de frameworks qui peuvent également nécessiter un accès au processeur, à la mémoire ou aux E/S.
En maintenant ce zoo d'outils, l'équipe de développement est confrontée à un certain nombre de défis :
- Il n’existe pas de manière uniforme pour les ingénieurs de gérer un environnement de production. Les services sans état, les services avec état et les projets en développement actif sont basés sur des piles technologiques complètement différentes. Cela a conduit à la création d'une formation complète pour les ingénieurs, et complique également sérieusement le travail de notre équipe infrastructure.
- Les développeurs disposant de leur propre parc de machines virtuelles représentent une énorme charge pour les administrateurs internes. En conséquence, des opérations aussi simples que la mise à jour du système d’exploitation ou de l’AMI prennent des semaines et des mois. Cela conduit à une charge de travail accrue dans des situations apparemment absolument quotidiennes.
- Difficultés à créer des outils de gestion globale des infrastructures en plus des solutions existantes. La situation est encore compliquée par le fait qu'il n'est pas facile de trouver les propriétaires des machines virtuelles. Autrement dit, nous ne savons pas si cette capacité peut être extraite en toute sécurité pour fonctionner dans d’autres parties de notre infrastructure.
Les systèmes d'orchestration de conteneurs sont un moyen d'unifier la gestion de la charge de travail. Ils ouvrent la porte à une vitesse de développement accrue et simplifient la gestion de l'infrastructure, puisque toutes les ressources impliquées dans le projet sont gérées par un système centralisé.
Figure 1 : Priorités de l'infrastructure (fiabilité, productivité des développeurs et efficacité).
L'équipe Cloud Management Platform de Pinterest a découvert les K8 en 2017. Au premier semestre 2017, nous avions documenté la plupart de nos capacités de production, y compris l'API et tous nos serveurs Web. Ensuite, nous avons procédé à une évaluation approfondie de divers systèmes permettant d'orchestrer des solutions de conteneurs, de créer des clusters et de travailler avec eux. Vers fin 2017, nous avons décidé d'utiliser Kubernetes. Il était assez flexible et largement pris en charge par la communauté des développeurs.
À ce jour, nous avons créé nos propres outils de démarrage de cluster basés sur Kops et migré les composants d'infrastructure existants tels que la mise en réseau, la sécurité, les métriques, la journalisation, la gestion des identités et le trafic vers Kubernetes. Nous avons également mis en place un système de modélisation de la charge de travail pour notre ressource, dont la complexité est cachée aux développeurs. Nous nous concentrons désormais sur la stabilité du cluster, sa mise à l'échelle et la connexion de nouveaux clients.
Kubernetes : la méthode Pinterest
Démarrer avec Kubernetes à l'échelle de Pinterest en tant que plate-forme que nos ingénieurs adoreraient comportait de nombreux défis.
En tant que grande entreprise, nous avons investi massivement dans des outils d’infrastructure. Les exemples incluent les outils de sécurité qui gèrent le traitement des certificats et la distribution des clés, les composants de contrôle du trafic, les systèmes de découverte de services, les composants de visibilité et les composants de répartition des journaux et des métriques. Tout cela a été collecté pour une raison : nous avons suivi le chemin normal des essais et des erreurs, et c'est pourquoi nous avons voulu intégrer tous ces équipements dans la nouvelle infrastructure sur Kubernetes au lieu de réinventer l'ancienne roue sur une nouvelle plate-forme. Cette approche a globalement simplifié la migration, puisque tout le support applicatif existe déjà et n'a pas besoin d'être créé à partir de zéro.
D'un autre côté, les modèles de prévision de charge dans Kubernetes lui-même (tels que les déploiements, les tâches et les ensembles de démons) ne suffisent pas pour notre projet. Ces problèmes d’utilisabilité constituent d’énormes obstacles au passage à Kubernetes. Par exemple, nous avons entendu des développeurs de services se plaindre de paramètres de connexion manquants ou incorrects. Nous avons également rencontré une utilisation incorrecte des moteurs de modèles, lorsque des centaines de copies étaient créées avec les mêmes spécifications et tâches, ce qui entraînait des problèmes de débogage cauchemardesques.
Il était également très difficile de conserver différentes versions dans le même cluster. Imaginez la complexité du support client si vous devez travailler simultanément sur plusieurs versions du même environnement d'exécution, avec tous leurs problèmes, bugs et mises à jour.
Propriétés utilisateur et contrôleurs Pinterest
Pour faciliter la mise en œuvre de Kubernetes par nos ingénieurs, ainsi que pour simplifier et accélérer notre infrastructure, nous avons développé nos propres définitions de ressources personnalisées (CRD).
Les CRD offrent les fonctionnalités suivantes :
- Combiner différentes ressources Kubernetes natives afin qu'elles fonctionnent comme une seule charge de travail. Par exemple, la ressource PinterestService comprend un déploiement, un service de connexion et une carte de configuration. Cela permet aux développeurs de ne pas se soucier de la configuration du DNS.
- Mettre en œuvre le support applicatif nécessaire. L'utilisateur doit se concentrer uniquement sur la spécification du conteneur en fonction de sa logique métier, tandis que le contrôleur CRD implémente tous les conteneurs d'initialisation, variables d'environnement et spécifications de pod nécessaires. Cela offre un niveau de confort fondamentalement différent aux développeurs.
- Les contrôleurs CRD gèrent également le cycle de vie des ressources natives et améliorent la disponibilité du débogage. Cela inclut le rapprochement des spécifications souhaitées et réelles, la mise à jour du statut CRD et la tenue des journaux d'événements, et bien plus encore. Sans CRD, les développeurs seraient obligés de gérer plusieurs ressources, ce qui ne ferait qu'augmenter le risque d'erreur.
Voici un exemple de PinterestService et de ressource interne gérés par notre contrôleur :
Comme vous pouvez le voir ci-dessus, pour prendre en charge un conteneur personnalisé, nous devons intégrer un conteneur d'initialisation et plusieurs modules complémentaires pour assurer la sécurité, la visibilité et le trafic réseau. De plus, nous avons créé des modèles de carte de configuration et implémenté la prise en charge des modèles PVC pour les tâches par lots, ainsi que le suivi de plusieurs variables d'environnement pour suivre l'identité, la consommation des ressources et le garbage collection.
Il est difficile d'imaginer que les développeurs veuillent écrire ces fichiers de configuration à la main sans le support CRD, et encore moins maintenir et déboguer davantage les configurations.
Flux de travail de déploiement d'applications
L'image ci-dessus montre comment déployer une ressource personnalisée Pinterest sur un cluster Kubernetes :
- Les développeurs interagissent avec notre cluster Kubernetes via la CLI et l'interface utilisateur.
- Les outils CLI/UI récupèrent les fichiers YAML de configuration du flux de travail et d'autres propriétés de build (même ID de version) à partir d'Artifactory, puis les soumettent au service de soumission de tâches. Cette étape garantit que seules les versions de production sont livrées au cluster.
- JSS est une passerelle pour diverses plateformes, dont Kubernetes. Ici, l'utilisateur est authentifié, des quotas sont émis et la configuration de notre CRD est partiellement vérifiée.
- Après avoir vérifié le CRD côté JSS, les informations sont envoyées à l'API de la plateforme k8s.
- Notre contrôleur CRD surveille les événements sur toutes les ressources utilisateur. Il convertit les CR en ressources k8s natives, ajoute les modules nécessaires, définit les variables d'environnement appropriées et effectue d'autres travaux de support pour garantir que les applications utilisateur conteneurisées disposent d'un support d'infrastructure suffisant.
- Le contrôleur CRD transmet ensuite les données reçues à l'API Kubernetes afin qu'elles puissent être traitées par le planificateur et mises en production.
Noter: Ce flux de travail de pré-version du déploiement a été créé pour les premiers utilisateurs de la nouvelle plateforme k8s. Nous sommes actuellement en train d'affiner ce processus pour l'intégrer pleinement à notre nouveau CI/CD. Cela signifie que nous ne pouvons pas vous dire tout ce qui concerne Kubernetes. Nous sommes impatients de partager notre expérience et les progrès de l'équipe dans cette direction dans notre prochain article de blog, « Créer une plateforme CI/CD pour Pinterest ».
Types de ressources spéciales
Sur la base des besoins spécifiques de Pinterest, nous avons développé les CRD suivants pour s'adapter à différents flux de travail :
- PinterestService sont des services sans état qui fonctionnent depuis longtemps. Beaucoup de nos systèmes centraux sont basés sur un ensemble de tels services.
- PinterestJobSet modélise les tâches par lots à cycle complet. Un scénario courant sur Pinterest est que plusieurs tâches exécutent les mêmes conteneurs en parallèle, quels que soient les autres processus similaires.
- PinterestCronJob est largement utilisé avec de petites charges périodiques. Il s'agit d'un wrapper pour le travail cron natif avec les mécanismes de support Pinterest qui sont responsables de la sécurité, du trafic, des journaux et des métriques.
- PinterestDaemon inclut des démons d'infrastructure. Cette famille continue de s'agrandir à mesure que nous ajoutons davantage de soutien à nos clusters.
- PinterestTrainingJob s'étend aux processus Tensorflow et Pytorch, offrant le même niveau de prise en charge d'exécution que tous les autres CRD. Étant donné que Pinterest utilise activement Tensorflow et d'autres systèmes d'apprentissage automatique, nous avions une raison de créer un CRD distinct autour d'eux.
Nous travaillons également sur PinterestStatefulSet, qui sera bientôt adapté aux entrepôts de données et autres systèmes avec état.
Prise en charge de l'exécution
Lorsqu'un pod d'application s'exécute sur Kubernetes, il reçoit automatiquement un certificat pour s'identifier. Ce certificat est utilisé pour accéder au stockage secret ou pour communiquer avec d'autres services via mTLS. Pendant ce temps, le configurateur et le démon Container Init téléchargeront toutes les dépendances nécessaires avant d'exécuter l'application conteneurisée. Lorsque tout sera prêt, le side-car de trafic et Daemon enregistreront l'adresse IP du module auprès de notre Zookeeper afin que les clients puissent la découvrir. Tout cela fonctionnera car le module réseau a été configuré avant le lancement de l'application.
Les exemples ci-dessus sont des exemples typiques de prise en charge d’exécution pour les charges de travail. D'autres types de charges de travail peuvent nécessiter une prise en charge légèrement différente, mais ils se présentent tous sous la forme de side-cars au niveau du pod, de démons au niveau du nœud ou de la machine virtuelle. Nous veillons à ce que tout cela soit déployé au sein de l'infrastructure de gestion et soit cohérent entre les applications, ce qui réduit considérablement la charge en termes de travail technique et de support client.
Tests et assurance qualité
Nous avons construit un pipeline de tests de bout en bout au-dessus de l'infrastructure de test Kubernetes existante. Ces tests s'appliquent à l'ensemble de nos clusters. Notre pipeline a subi de nombreuses révisions avant de devenir partie intégrante du cluster de produits.
En plus de tester les systèmes, nous disposons de systèmes de surveillance et d'alerte qui surveillent en permanence l'état des composants du système, la consommation des ressources et d'autres indicateurs importants, nous avertissant uniquement lorsqu'une intervention humaine est nécessaire.
Des alternatives
Nous avons examiné quelques alternatives aux ressources personnalisées, telles que les contrôleurs d'accès aux mutations et les systèmes de modèles. Cependant, ils comportent tous des défis opérationnels importants, c’est pourquoi nous avons choisi la voie CRD.
Un contrôleur d'admission mutationnel a été utilisé pour introduire des side-cars, des variables d'environnement et d'autres supports d'exécution. Cependant, il a été confronté à divers problèmes, tels que la liaison des ressources et la gestion du cycle de vie, alors que de tels problèmes ne se posent pas dans CRD.
Note: Les systèmes de modèles tels que les graphiques Helm sont également largement utilisés pour exécuter des applications avec des configurations similaires. Cependant, nos applications professionnelles sont trop diverses pour être gérées à l’aide de modèles. De plus, lors d'un déploiement continu, il y aura trop d'erreurs lors de l'utilisation des modèles.
Travaux à venir
Nous sommes actuellement confrontés à une charge mixte sur tous nos clusters. Pour prendre en charge de tels processus de différents types et tailles, nous travaillons dans les domaines suivants :
- Un ensemble de clusters distribue des applications volumineuses sur différents clusters pour des raisons d'évolutivité et de stabilité.
- Assurer la stabilité, l’évolutivité et la visibilité du cluster pour créer une connectivité applicative et des SLA.
- Gérer les ressources et les quotas afin que les applications n'entrent pas en conflit les unes avec les autres et que l'échelle du cluster soit contrôlée de notre part.
- Une nouvelle plateforme CI/CD pour prendre en charge et déployer des applications sur Kubernetes.
Source: habr.com