🤢 🛒 👏 "Utilisons Kubernetes!" Vous avez maintenant 8 problèmes 📁 🚵 👩‍👦‍👦

Si vous utilisez Docker, la prochaine étape logique semble passer à Kubernetes, ce sont les K8, non? Eh bien, supposez. Cependant, les solutions conçues pour 500 ingénieurs logiciels développant simultanément une seule application sont très différentes des solutions pour 50 personnes. Et la solution pour une équipe de 5 programmeurs est une autre histoire.

Si vous travaillez dans une petite équipe, Kubernetes n'est probablement pas pour vous. Cela vous apportera beaucoup de douleur en échange d'avantages extrêmement modestes.
Voyons pourquoi cela peut arriver.

Tout le monde aime les «pièces mobiles»

Kubernetes bouge et change beaucoup: concepts, sous-systèmes, processus, machines, code ... Et tout cela signifie beaucoup de difficultés.

Plusieurs voitures

Kubernetes est un système distribué: il a une machine hôte qui contrôle le reste, les travailleurs. Chaque machine effectue des travaux dans des conteneurs.
Nous parlons donc déjà d'au moins deux machines physiques ou virtuelles, qui ne sont nécessaires que pour le faire fonctionner. Mais en fait, vous obtenez ... une seule voiture. Si vous allez évoluer (c'est là que le chien est enterré!), Vous aurez besoin de trois, quatre ou peut-être jusqu'à dix-sept machines virtuelles.

Très, beaucoup de code

La base de code Kubernetes au début du mois de mars 2020 comprend plus de 580 000 lignes de code sur Go. Et ce n'est que du code propre, à l'exclusion des commentaires, des lignes vides et des packages de fournisseurs. L'examen de la sécurité de 2019 décrit la base de code comme suit:
«La base de code Kubernetes peut être considérablement améliorée. Il est grand et complexe, contient de grandes sections de code avec une documentation minimale et un grand nombre de dépendances, y compris des systèmes qui ne font pas partie de Kubernetes. Dans la base de code, il existe également de nombreux cas de réimplémentation de la logique, qui pourraient être centralisés dans les bibliothèques de support, ce qui réduirait la complexité, simplifierait les corrections et réduirait la charge des documents dans divers domaines de la base de code. »
Pour être honnête, on peut en dire autant de nombreux autres grands projets, mais tout ce code devrait fonctionner correctement si vous ne voulez pas que votre application échoue.

Complexité architecturale, opérationnelle, de configuration et conceptuelle

Kubernetes est un système complet avec de nombreux services, systèmes et plus.
Avant de pouvoir lancer votre seule application, vous devrez fournir l'architecture considérablement simplifiée suivante (l'image d'origine est tirée de la documentation de Kubernetes):

La documentation du concept K8s comprend de nombreux éléments purement «éducatifs», tels que l'extrait de code suivant:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

En fait, je comprends de quoi il s'agit, mais faites attention au nombre de concepts que vous devez apprendre: EndpointSlice, Service, selector, Pod, Endpoint.

Et - oui, la plupart du temps, vous n'utiliserez pas toutes ces fonctionnalités. Par conséquent, la plupart du temps, vous n'aurez pas du tout besoin de Kubernetes.

Voici un autre extrait aléatoire:

Par défaut, le trafic envoyé à un service ClusterIP ou NodePort peut être acheminé vers n'importe quelle adresse principale du service. Depuis Kubernetes 1.7, il a été possible d'acheminer le trafic «externe» vers les pods exécutés sur le nœud qui a reçu le trafic, mais cela n'est pas pris en charge pour les services ClusterIP, et les topologies plus complexes - telles que le routage zonal - n'ont pas été possibles. La fonctionnalité Topologie de service résout ce problème en permettant au créateur du service de définir une stratégie de routage du trafic en fonction des étiquettes de nœud pour les nœuds d'origine et de destination.

Voici ce que la revue de sécurité en dit:

Kubernetes — , . , Kubernetes — , , , .

Plus vous en obtenez chez Kubernetes, plus le processus de développement normal devient difficile: vous avez besoin de tous ces concepts (Pod, Déploiement, Service, etc.) juste pour faire fonctionner votre code. Ainsi, vous devez promouvoir un système K8 à part entière, même uniquement pour les tests via une machine virtuelle ou des conteneurs Docker imbriqués.

Et, comme votre application devient plus difficile à exécuter localement, le développement est compliqué par de nombreuses options pour résoudre ce problème, d'un environnement de banc au proxy d'un processus local à un cluster (j'ai écrit cet outil il y a quelques années ) et au proxy d'un processus distant à une machine locale ...

Vous pouvez choisissez une option, mais aucune ne sera parfaite. La façon la plus simple de ne pas utiliser du tout Kubernetes.

Microservices (c'est une mauvaise idée)

Un problème secondaire est que, puisque votre système vous permet d'exécuter de nombreux services, vous devez écrire ces nombreux services. Mauvaise idée.
La qualité de l'application distribuée est difficile à écrire. En effet , plus les pièces sont mobiles, plus ces problèmes interfèrent avec le travail.

Les applications distribuées sont difficiles à déboguer. Vous aurez besoin d'un tout nouveau type d'outils de débogage et de journalisation, qui vous donnera toujours moins que les journaux d'une application monolithique.

Les microservices sont l'une des techniques de mise à l'échelle dans les organisations: lorsque vous avez 500 développeurs qui desservent un site Web productif, il est logique de composer avec le coût d'un système distribué à grande échelle s'il permet aux équipes de développement de travailler de manière indépendante. Ainsi, chaque équipe de 5 personnes reçoit un seul microservice et prétend que tous les autres microservices sont des services externes auxquels vous ne devez pas faire confiance.

Si toute votre équipe est composée de 5 personnes, vous disposez de 20 microservices et les circonstances de force majeure ne vous obligent pas à créer un système distribué, alors quelque part vous avez mal calculé. Au lieu de 5 personnes pour 1 microservice, comme dans les grandes entreprises, vous obtenez 0,25 personne.

Kubernetes n'est-il pas utile du tout?

Mise à l'échelle

Kubernetes peut être utile si vous avez besoin d'une évolutivité sérieuse. Cependant, voyons quelles alternatives vous avez:

Vous pouvez acheter des machines virtuelles dans le cloud et elles auront jusqu'à 416 CPU virtuels et 8 To de RAM, c'est-à-dire une puissance totalement peu flatteuse. Cela vous coûtera un joli sou, mais ce sera extrêmement simple à faire.
De nombreuses applications Web simples peuvent être mises à l'échelle de manière assez simple avec des services tels que Heroku.

Il est supposé, bien sûr, qu'une augmentation du nombre de machines virtuelles actives jouera également entre vos mains:

La plupart des applications ne nécessitent pas de mise à l'échelle significative, elles auront une optimisation suffisante de haute qualité.
Le goulot d'étranglement pour la mise à l'échelle de la plupart des applications Web est les bases de données, pas les travailleurs Web

Fiabilité

Plus il y a de pièces mobiles, plus le risque d'erreur se produise.
Les capacités de Kubernetes, renforcées par une fiabilité accrue (contrôles d'intégrité, déploiements roulants), peuvent dans de nombreux cas être déjà intégrées ou implémentées beaucoup plus facilement. Par exemple, nginx peut effectuer des contrôles d' intégrité sur les processus de travail, et vous pouvez également utiliser docker-autoheal ou quelque chose de similaire pour redémarrer automatiquement ces processus.

Si vous êtes particulièrement préoccupé par les temps d'arrêt, la première pensée qui vous rendra visite ne devrait pas être "comment puis-je réduire les temps d'arrêt lors du déploiement de 1 seconde à 1 milliseconde), mais ce devrait être" comment puis-je m'assurer que les modifications apportées au schéma de la base de données permettent un retour en arrière si je quelque part quelque part? "
Et si vous avez besoin de travailleurs Web fiables sans une seule machine comme point de défaillance, il existe de nombreuses façons de l'implémenter sans Kubernetes.

Meilleures pratiques?

En fait, aucune meilleure pratique n'existe dans la nature. Il n'y a que les meilleures pratiques pour chaque situation spécifique. Par conséquent, si quelque chose est à la mode et populaire, cela ne signifie pas du tout que c'est le bon choix pour vous en particulier.
Dans certains cas, Kubernetes est la meilleure option. Le reste est une perte de temps.

À moins que vous ne ressentiez le besoin urgent de toutes ces complexités, vous disposez d'une large sélection d'outils qui résoudront vos problèmes: Docker Compose pour une machine, Hashicorp's Nomad pour l'orchestration, Heroku et systèmes similaires pour la mise à l'échelle, et quelque chose comme Shakemake pour le calcul des pipelines.

Mot de la rédaction

En tant que fournisseur de cloud, nous rencontrons régulièrement une grande variété de clients, des petites startups aux grandes organisations avec des processus métier complexes et des demandes d'infrastructure connexes. Quelle que soit la qualité de la technologie, il y aura toujours des précédents dans lesquels son application entraînera des difficultés inutiles. Vous devez toujours partir de la situation et peser soigneusement les avantages et les inconvénients des options disponibles. L'auteur de l'article a un peu épaissi ses couleurs, mais son message est assez clair: parfois, pour prendre la bonne décision, il vaut la peine de se détourner des tendances et d'évaluer de manière impartiale votre projet. Cela permettra de sauver la force des développeurs et l'utilisation des ressources de l'entreprise le rendra plus approprié.

"Utilisons Kubernetes!" Vous avez maintenant 8 problèmes