Kubernetes est devenu un standard de l'industrie, avec jusqu'à 94% des organisations déployant leurs services et applications sur la plate-forme d'orchestration de conteneurs, selon les enquêtes. L'une des principales raisons pour lesquelles les entreprises mettent en œuvre Kubernetes est la standardisation, qui permet aux utilisateurs expérimentés de bénéficier d'un double avantage en termes de productivité.
La standardisation sur Kubernetes donne aux organisations la possibilité de déployer n'importe quel conteneur, n'importe où. Mais il manquait une pièce : la technologie supposait que les conteneurs étaient temporaires, ce qui signifie que seuls les conteneurs sans état pouvaient être déployés en toute sécurité sur Kubernetes. Cependant, la communauté a récemment changé de paradigme et apporté des fonctionnalités telles que StatefulSets et Storage Classes, qui rendent possible l'utilisation des données dans Kubernetes.
Bien qu'il soit possible d'exécuter des conteneurs avec état sur Kubernetes, cela reste un défi.
fais le progressivement
Kubernetes est en passe de devenir aussi populaire que Linux et le moyen de facto d'exécuter n'importe quelle application, n'importe où, de manière distribuée. L'utilisation de Kubernetes implique l'apprentissage de nombreux concepts et vocabulaire techniques. Par exemple, les nouveaux arrivants peuvent avoir des problèmes avec les nombreuses unités logiques de Kubernetes, telles que les conteneurs, les pods, les nœuds et les clusters.
Si vous n'exécutez pas déjà Kubernetes en production, ce n'est pas une bonne idée de sauter directement dans les conteneurs de données. Il est préférable de commencer par déplacer les applications sans état pour éviter la perte de données en cas de problème.
Si vous ne trouvez pas d'opérateur qui correspond à vos besoins, ne vous inquiétez pas, car la plupart d'entre eux sont open source.
Comprendre les limites et les spécificités
Une fois que vous êtes familiarisé avec les concepts généraux de Kubernetes, vous pouvez vous plonger dans les détails des concepts avec état. Par exemple, étant donné que les applications peuvent avoir des besoins de stockage différents, tels que des exigences de performances ou de capacité, le système de stockage sous-jacent approprié doit être fourni.
Ce que l'industrie appelle généralement les "profils" de stockage sont appelés classes de stockage dans Kubernetes. Ils permettent de décrire les différents types de classes auxquelles un cluster Kubernetes peut accéder. Les classes de stockage peuvent avoir différents niveaux de QoS, tels que des opérations d'E/S par seconde par Gio, des politiques de sauvegarde ou des politiques arbitraires, telles que des modes de liaison et des topologies autorisées.
Un autre composant essentiel à comprendre est StatefulSet. Il s'agit de l'objet API Kubernetes utilisé pour gérer les applications avec état et offre des fonctionnalités clés telles que :
- Des identifiants réseau uniques et stables qui vous permettent de suivre le volume et de vous déconnecter et vous reconnecter quand vous le souhaitez
- Stockage stable et persistant pour protéger vos données
- Déploiement et mise à l'échelle soignés et ordonnés, qui sont nécessaires pour de nombreuses opérations du jour 2.
Bien que StatefulSet ait réussi à remplacer le tristement célèbre PetSet (maintenant obsolète), il est encore imparfait et a des limites. Par exemple, le contrôleur StatefulSet vient pas de support intégré pour le redimensionnement de volume (PVC) — ce qui représente un grand défi si la taille de l'ensemble de données de votre application est sur le point de dépasser la capacité de stockage actuellement allouée. exister solutions alternatives mais ces limitations doivent être comprises bien à l'avance afin que l'équipe d'ingénierie sache comment les gérer.
Avoir un plan
Une fois à l'aise avec les concepts d'état de Kubernetes, vous pouvez progressivement migrer les tâches liées aux données dans un ordre spécifique. Cela vous permet d'apprendre de vos erreurs et d'éviter d'être submergé, car toutes les technologies de données ne sont pas aussi faciles à exécuter sur Kubernetes.
Les technologies établies telles que les bases de données et le stockage doivent être migrées en premier, et les technologies émergentes telles que l'IA et le ML doivent être migrées en dernier. Cela se reflète dans un rapport récent, qui a révélé que la base de données et le stockage persistant sont les deux charges de travail de données les plus exécutées sur Kubernetes. La raison principale est le manque d'outils pour les opérations du jour 2.
Disponibilité des opérateurs
Le déplacement des conteneurs avec état vers Kubernetes ne représente que la moitié du travail, c'est-à-dire le jour 1. Il est maintenant temps de gérer les opérations du jour 2 (l'un des sujets les plus discutés lors de la dernière KubeCon). C'est là que les choses se compliquent. Il y a des tonnes d'opérations du jour 2 que Kubernetes ne peut pas gérer de manière native, comme les correctifs et les mises à jour, la sauvegarde et la restauration, le traitement des journaux, la surveillance, la mise à l'échelle et le réglage.
Toutes ces opérations sont spécifiques à l'application. Par exemple, un cluster PostgreSQL et MySQL nécessitera deux approches complètement différentes lors du choix d'un nouveau serveur principal dans une configuration de cluster HA. Kubernetes ne peut pas connaître toutes les opérations spécifiques du jour 2 de l'application. C'est là qu'interviennent les opérateurs.
Les opérateurs sont des extensions scriptables qui effectuent des opérations que Kubernetes ne peut pas gérer de manière native. Les opérateurs fournissent des capacités de gestion dynamiques et intelligentes en étendant les fonctionnalités de l'API Kubernetes. L'une des utilisations les plus courantes consiste à effectuer ces opérations du jour 2. Ces opérateurs ne sont pas développés par les mainteneurs de Kubernetes mais par des développeurs et des organisations tiers.
Avant de déplacer une tâche de données vers Kubernetes, assurez-vous qu'il existe un opérateur pour celle-ci. OperatorHub fait un excellent travail d'indexation. Avec 282 opérateurs disponibles sur le site, la distribution fait écho à ce qui précède : certains emplois ont des outils de support et d'autres non. Par exemple, la catégorie base de données a 38 opérateurs (il y en a huit pour PostgreSQL seul), tandis que la catégorie ML/IA entière n'en a que sept.
Le bon niveau de compétence de l'opérateur
Avoir un opérateur pour votre technologie ne suffit pas, car ils peuvent avoir des capacités différentes et existent souvent à différents niveaux de maturité. L'OperatorFramework propose un modèle de capacité qui catégorise les opérateurs en fonction de leurs caractéristiques :
- Niveau 1 – Fonctionne pour une installation de base, telle que le provisionnement automatisé des applications et la gestion de la configuration.
- Niveau 2 : prend en charge les mises à niveau, les correctifs et les mises à niveau de versions mineures sans problème.
- Niveau 3 – Gère l'ensemble du cycle de vie de l'application et du stockage (sauvegarde, basculement, etc.).
- Niveau 4 – Fournit des informations, des métriques, des alertes, le traitement des journaux et une analyse de la charge de travail.
- Niveau 5 – Fournit une mise à l'échelle horizontale/verticale automatique, un réglage automatique de la configuration, une détection des anomalies et un réglage de la planification.
Lors du choix d'un opérateur, vous devez vous assurer que ses capacités correspondent à vos besoins. Si vous ne savez pas quel niveau est le bon, le rapport Data on Kubernetes 2022 a révélé que la plupart des organisations recherchent des opérateurs qui sont au moins au niveau 3. Avoir une sauvegarde pour vos conteneurs est une bonne pratique.
Si vous ne trouvez pas d'opérateur qui correspond à vos besoins, ce n'est pas un problème car la plupart d'entre eux sont open source. Vous pouvez étendre les capacités des opérateurs existants avec un développement interne, ou mieux encore, contribuer au projet open source.
comprendre l'opérateur
L'extensibilité des opérateurs est sa force, mais aussi sa faiblesse. L'absence de normes signifie qu'ils sont programmés de différentes manières, vous devez donc consulter vos fichiers de configuration pour choisir le format qui vous convient le mieux.
De plus, les opérateurs peuvent utiliser différentes voies techniques pour atteindre le même objectif. Par exemple, l'un des huit opérateurs PostgreSQL, CloudNativePG, n'utilise pas StatefulSets et utilise à la place son propre gestionnaire personnalisé. C'est assez inattendu étant donné que StatefulSets est la base des conteneurs avec état dans Kubernetes.
Ses développeurs ont décidé d'opter pour cette conception en raison de l'incapacité de StatefulSet à redimensionner les PVC (comme nous l'avons vu ci-dessus). Comme l'explique la documentation de l'opérateur, le choix de "différentes options de mise en page mène à plusieurs chemins". Par conséquent, lors du choix d'un opérateur, assurez-vous de bien comprendre sa mise en œuvre, ses avantages et ses inconvénients, et choisissez celui qui vous convient le mieux.
vaut la peine
Exécuter des données sur Kubernetes n'est pas toujours facile, mais la bonne nouvelle est que cela en vaut la peine : 54 % des organisations interrogées attribuent plus de 10 % de leurs revenus à l'exécution de données sur Kubernetes. De plus, 33 % ont déclaré que cela avait un impact transformationnel sur la productivité et 51 % supplémentaires ont vu un impact positif significatif.
Alors que les organisations adoptent de plus en plus une infrastructure multicloud pour optimiser leurs coûts et leurs performances, Kubernetes est devenu l'outil préféré. Avec environ 66 % des pays disposant d'une certaine forme de législation sur la confidentialité des données et les droits des consommateurs, qui nécessite souvent l'application de la gouvernance des données, les entreprises doivent de plus en plus héberger les données des utilisateurs dans les pays dans lesquels elles opèrent.
