Meilleures pratiques Kubernetes. Organisation Kubernetes avec espace de noms

Meilleures pratiques Kubernetes. Création de petits conteneurs

Lorsque vous commencez à créer de plus en plus de services Kubernetes, les tâches faciles à démarrer deviennent plus compliquées. Par exemple, les équipes de développement ne peuvent pas créer de services ou de déploiements sous le même nom. Si vous avez des milliers de foyers, une simple liste d'entre eux prendra beaucoup de temps, sans oublier de leur fournir une gestion normale. Et ce n'est que la pointe de l'iceberg.

Voyons comment l'espace de noms namespace facilite la gestion des ressources Kubernetes. Alors, qu'est-ce qu'un espace de noms exactement? L'espace de noms peut être considéré comme un cluster virtuel à l'intérieur de votre cluster Kubernetes. Vous pouvez avoir plusieurs espaces de noms isolés les uns des autres dans le même cluster Kubernetes. Ils peuvent vraiment vous aider, vous et vos équipes, dans l'organisation, la sécurité et même les performances du système.



Sur la plupart des distributions Kubernetes, le cluster est «prêt à l'emploi» avec un espace de noms appelé «par défaut». Il y a en fait trois espaces de noms que Kubernetes gère: default, kube-system et kube-public. Actuellement, Kube-public n'est pas utilisé très souvent.



Ne pas toucher l'espace de noms du kube est une bonne idée, en particulier sur un système géré comme le moteur Google Kubernetes. Il utilise l'espace de noms par défaut comme lieu de création de vos services et applications. Il n'y a absolument rien de spécial à ce sujet, sauf que Kubernetes est prêt à l'emploi pour être utilisé et que vous ne pouvez pas le supprimer. C'est idéal pour démarrer et les systèmes avec peu de performances, mais je ne recommanderais pas d'utiliser l'espace de noms par défaut dans les grands systèmes de production. Dans ce dernier cas, une équipe de développement peut facilement réécrire le code de quelqu'un d'autre et perturber le travail d'une autre équipe sans même s'en rendre compte.

Par conséquent, vous devez créer plusieurs espaces de noms et les utiliser pour segmenter vos services en liens gérables. Un espace de noms peut être créé avec une seule commande. Si vous souhaitez créer un espace de noms appelé test, utilisez la commande $ kubectl create namespace test ou créez simplement un fichier YAML et utilisez-le comme n'importe quelle autre ressource Kubernetes.



Vous pouvez afficher tous les espaces de noms à l'aide de la commande $ kubectl get namespace.



Après son exécution, vous verrez trois espaces de noms intégrés et un nouvel espace de noms appelé "test". Regardons un simple fichier YAML pour créer des pods. Vous remarquerez peut-être qu'il n'y a aucune mention d'espace de noms dedans.



Si vous utilisez kubectl pour exécuter ce fichier, il créera le module mypod dans l'espace de noms actif actuel. Ce sera l'espace de noms par défaut jusqu'à ce que vous le changiez. Il existe deux façons de dire à Kubernetes dans quel espace de noms vous souhaitez créer votre ressource. La première consiste à utiliser l'indicateur d'espace de noms lors de la création de la ressource.



La deuxième façon consiste à spécifier l'espace de noms dans la déclaration YAML.



Si vous spécifiez un espace de noms dans YAML, la ressource sera toujours créée dans cet espace. Si vous essayez d'utiliser un espace de noms différent lors de l'utilisation de l'indicateur d'espace de noms, la commande échouera. Maintenant, si vous essayez de trouver votre pod, vous ne pouvez pas le faire.



En effet, toutes les commandes sont exécutées en dehors de l'espace de noms actif actuel. Pour trouver votre module, vous devez utiliser l'indicateur d'espace de noms, mais cela est rapidement ennuyeux, surtout si vous travaillez en tant que développeur dans un groupe qui utilise son propre espace de noms et ne souhaite pas utiliser un tel indicateur pour chaque commande individuelle. Voyons comment cela peut être résolu.



Hors de la boîte, votre espace de noms actif est appelé par défaut. Si vous ne spécifiez pas l'espace de noms dans le YAML de la ressource, toutes les commandes Kubernetes utiliseront cet espace de noms par défaut actif. Malheureusement, une tentative de gestion de l'espace de noms actif à l'aide de kubectl peut échouer. Cependant, il existe un très bon outil appelé Kubens, qui simplifie considérablement ce processus. Lorsque vous exécutez la commande kubens, vous voyez tous les espaces de noms avec l'espace de noms actif mis en surbrillance.



Pour basculer l'espace de noms actif vers l'espace de noms de test, il vous suffit d'exécuter la commande de test $ kubens. Si après cela, vous entrez à nouveau la commande $ kubens, vous pouvez voir qu'un nouvel espace de noms actif est maintenant alloué - test.



Cela signifie que vous n'avez pas besoin d'un indicateur d'espace de noms pour voir le pod dans l'espace de noms de test.



Par conséquent, les espaces de noms sont masqués les uns des autres, mais pas isolés les uns des autres. Un service d'un espace de noms peut assez facilement communiquer avec un service d'un autre espace de noms, ce qui est souvent très utile. La capacité de communiquer entre différents espaces de noms signifie que le service de vos développeurs peut interagir avec le service d'une autre commande dev dans un espace de noms différent.

Habituellement, lorsque votre application souhaite accéder au service Kubernetes, vous utilisez le service de découverte DNS intégré et donnez simplement à votre application le nom du service. Cependant, vous pouvez créer un service sous le même nom dans plusieurs espaces de noms, ce qui n'est pas valide.



Heureusement, cela est facilement contourné en utilisant la forme étendue de l'adresse DNS. Les services de Kubernetes exposent leurs points de terminaison à l'aide d'un modèle DNS commun. Cela ressemble à ceci:



En règle générale, vous avez juste besoin d'un nom de service et DNS déterminera automatiquement l'adresse complète.



Cependant, si vous devez accéder au service dans un autre espace de noms, utilisez simplement le nom du service plus le nom de l'espace de noms:



Par exemple, si vous souhaitez vous connecter à la base de données de service dans l'espace de noms de test, vous pouvez utiliser l'adresse de base de données database.test



Si vous souhaitez vous connecter à la base de données de service dans l'espace de noms prod, vous utilisez database.prod.



Si vous voulez vraiment isoler et restreindre l'accès à l'espace de noms, Kubernetes vous permet de le faire à l'aide des stratégies réseau de Kubernetes. J'en parlerai dans la prochaine série.

On me demande souvent combien d'espaces de noms doivent être créés et à quelles fins? Qu'est-ce qu'une donnée gérée?

Si vous créez trop d'espaces de noms, ils se mettent en travers de votre chemin. S'il y en a trop peu, vous perdrez tous les avantages d'une telle solution. Je pense qu'il y a quatre étapes principales que chaque entreprise traverse dans le processus de création de sa propre structure organisationnelle. Selon le stade de développement où se situe votre projet ou entreprise, vous pouvez adopter la stratégie appropriée pour créer un espace de noms.

Imaginez que vous faites partie d'une petite équipe qui travaille sur le développement de 5 à 10 microservices et que vous pouvez facilement assembler tous les développeurs dans une seule pièce. Dans cette situation, il est logique d'exécuter tous les services prod dans l'espace de noms par défaut. Bien sûr, pour un champ d'action plus large, vous pouvez utiliser 2 espaces de noms - séparément pour prod et dev. Et très probablement, vous testez votre développement sur un ordinateur local en utilisant quelque chose comme Minikube.

Supposons que les conditions ont changé et que vous disposez maintenant d'une équipe en croissance rapide qui travaille simultanément sur plus de 10 microservices. Il arrive un moment où vous devez utiliser plusieurs clusters ou espaces de noms, séparément pour prod et dev. Vous pouvez diviser une équipe en plusieurs sous-groupes afin que chacun d'eux ait ses propres microservices et que chacune de ces équipes puisse choisir son propre espace de noms pour faciliter le processus de gestion du développement et de la sortie du logiciel.



Au fur et à mesure que chaque membre de l'équipe a une idée du fonctionnement du système dans son ensemble, la coordination de chaque changement avec tous les autres développeurs devient de plus en plus difficile. Essayer de faire tourner une pile complète sur votre ordinateur local devient chaque jour plus difficile.

Dans les grandes entreprises, les développeurs ne savent pas du tout qui travaille exactement sur quoi. Les équipes communiquent à l'aide de contrats de service ou utilisent la technologie de maillage de service, qui ajoute une couche d'abstraction sur le réseau, comme l'outil de configuration Istio. Tenter d'exécuter la pile entière localement n'est tout simplement pas possible. Je recommande fortement d'utiliser une plate-forme de livraison continue (CD) comme Spinnaker sur Kubernetes. Ainsi, le moment vient où chaque équipe a définitivement besoin de son propre espace de noms. Chaque commande peut même sélectionner plusieurs espaces de noms pour l'environnement de développement et l'environnement de production.

Enfin, il existe de grandes entreprises entrepreneuriales dans lesquelles un groupe de développement n'est même pas conscient de l'existence d'autres groupes. Une telle entreprise peut généralement embaucher des développeurs tiers qui interagissent avec des API bien documentées. Dans chacun de ces groupes, il existe plusieurs équipes et plusieurs microservices. Dans ce cas, vous devez utiliser tous les outils que j'ai mentionnés précédemment.



Les programmeurs ne doivent pas déployer les services manuellement et ne doivent pas avoir accès aux espaces de noms qui ne les concernent pas. A ce stade, il est conseillé de disposer de plusieurs clusters pour réduire le "rayon d'explosion" des applications mal configurées, afin de simplifier les processus de facturation et de gestion des ressources.

Ainsi, l'utilisation correcte des espaces de noms de votre organisation rend Kubernetes plus gérable, gérable, sécurisé et flexible.

Meilleures pratiques Kubernetes. Test de viabilité de Kubernetes avec tests de préparation et de vivacité

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?