Meilleures pratiques Kubernetes. Organisation de Kubernetes avec des espaces de noms

Meilleures pratiques Kubernetes. Création de petits conteneurs

Au fur et à mesure que vous commencez à créer de plus en plus de services Kubernetes, des tâches simples au début commencent à devenir compliquées. Par exemple, les équipes de développeurs ne peuvent pas créer de services ou de déploiements avec le même nom. Si vous avez des milliers de pods, énumérer ces derniers peut prendre beaucoup de temps, sans parler de la nécessité de garantir une gestion efficace. Et ce n'est que la partie émergée de l'iceberg.

Examinons comment les namespaces facilitent la gestion des ressources Kubernetes. Mais qu'est-ce qu'un namespace ? Un namespace peut être considéré comme un cluster virtuel à l'intérieur de votre cluster Kubernetes. Vous pouvez avoir plusieurs namespaces isolés les uns des autres au sein d'un même cluster Kubernetes. Ils peuvent vraiment vous aider, vous et vos équipes, en termes d'organisation, de sécurité et même de performance du système.

Dans la plupart des distributions Kubernetes, le cluster est livré « prêt à l'emploi » avec un namespace nommé « default ». En réalité, il existe trois namespaces avec lesquels Kubernetes interagit : default, kube-system et kube-public. Actuellement, kube-public n'est pas souvent utilisé.

Il est conseillé de ne pas toucher au namespace kube, surtout dans un système géré comme Google Kubernetes Engine. Il utilise le namespace « default » comme emplacement où vos services et applications sont créés. Il n'y a rien de vraiment spécial à propos de celui-ci, si ce n'est que Kubernetes est configuré pour l'utiliser par défaut et que vous ne pouvez pas le supprimer. Cela convient parfaitement pour démarrer et pour les systèmes à faible performance, mais je ne recommanderais pas d'utiliser le namespace default dans de grandes systèmes de production. Dans ce dernier cas, une équipe de développeurs pourrait facilement écraser le code d'une autre équipe et perturber son fonctionnement sans même s'en rendre compte.

Il est donc recommandé de créer plusieurs namespaces et de les utiliser pour segmenter vos services en unités gérées. Un namespace peut être créé avec une simple commande. Si vous souhaitez créer un namespace nommé 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 voir tous les namespaces à 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 ». Examinons un fichier YAML simple destiné à créer un pod. Vous remarquerez qu'il n'y a aucune mention d'espace de noms.

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 2 façons de signaler à Kubernetes dans quel espace de noms vous souhaitez créer votre ressource. La première méthode consiste à utiliser l'option d'espace de noms lors de la création de la ressource.

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

Si vous spécifiez l'espace de noms dans le YAML, la ressource sera toujours créée dans cet espace. Si vous essayez d'utiliser un autre espace de noms en utilisant l'option d'espace de noms, la commande échouera. Maintenant, si vous essayez de trouver votre pod, vous ne pourrez pas le faire.

Cela se produit parce que toutes les commandes s'exécutent en dehors de l'espace de noms actif actuel. Pour trouver votre pod, vous devez utiliser l'option d'espace de noms, mais cela devient vite 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 cette option pour chaque commande distincte. Voyons comment cela peut être corrigé.

Par défaut, votre espace de noms actif s'appelle default. 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 actif par défaut. Malheureusement, tenter de gérer l'espace de noms actif avec kubectl peut être voué à l'échec. Cependant, il existe un excellent outil appelé Kubens qui simplifie énormément 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 changer l'espace de noms actif en l'espace de noms test, il vous suffit d'exécuter la commande $ kubens test. Si vous entrez à nouveau la commande $ kubens après cela, vous verrez que le nouvel espace de noms actif est désormais souligné – test.

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

Ainsi, les espaces de noms sont cachés les uns des autres, mais ne sont pas isolés les uns des autres. Un service dans un espace de noms peut facilement communiquer avec un service dans un autre espace de noms, ce qui est souvent très utile. La possibilité de communication entre différents espaces de noms signifie que le service de vos développeurs peut interagir avec le service d'une autre équipe de développement dans un autre espace de noms.

En général, lorsque votre application souhaite accéder à un service Kubernetes, vous utilisez le service de découverte DNS intégré et indiquez simplement à votre application le nom du service. Cependant, vous pouvez créer un service avec le même nom dans plusieurs espaces de noms, ce qui n'est pas autorisé.

Heureusement, il est facile de contourner cela en utilisant la forme entièrement qualifiée de l'adresse DNS. Les services dans Kubernetes exposent leurs points de terminaison en utilisant un modèle DNS commun. Cela ressemble à peu près à ceci :

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

Cependant, si vous devez accéder à un 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 d'un service dans l'espace de noms test, vous pouvez utiliser l'adresse database.test.

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

Si vous souhaitez vraiment isoler et restreindre l'accès à l'espace de noms, Kubernetes permet de le faire grâce aux politiques de réseau Kubernetes Network Policies. J'en parlerai dans la prochaine série.

On me pose souvent la question de savoir combien d'espaces de noms créer et dans quel but ? Qu'est-ce qu'un fragment de données géré ?

Si vous créez trop de namespaces, ils vous gêneront simplement. En revanche, 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 lors de la création de sa structure organisationnelle. Selon l'étape de développement à laquelle votre projet ou entreprise est arrivé, vous pouvez adopter une stratégie de création de namespace appropriée.

Imaginez que vous faites partie d'une petite équipe travaillant sur le développement de 5 à 10 microservices et que vous pouvez facilement rassembler tous les développeurs dans une même pièce. Dans cette situation, il a du sens de lancer tous les services de production dans l'espace de nom par défaut. Bien sûr, pour plus de flexibilité, vous pouvez utiliser deux espaces de noms — un pour la production et un pour le développement. Et il est probable que vous testiez votre développement sur votre ordinateur local avec quelque chose comme Minikube.

Supposons que les conditions aient changé et que vous ayez maintenant une équipe en forte croissance travaillant simultanément sur plus de 10 microservices. Il vient un moment où il est nécessaire d'utiliser plusieurs clusters ou namespaces, séparément pour la production et le développement. Vous pouvez diviser l'équipe en plusieurs sous-groupes, chacun ayant ses propres microservices et chaque équipe pouvant choisir son propre namespace pour faciliter le processus de gestion du développement et du déploiement logiciel.

À mesure que chaque membre de l'équipe comprend comment fonctionne le système dans son ensemble, il devient de plus en plus difficile de coordonner chaque changement avec tous les autres développeurs. Essayer de faire tourner toute la pile sur votre ordinateur local devient de plus en plus complexe.

Dans les grandes entreprises, les développeurs ne savent souvent pas qui travaille sur quoi en particulier. Les équipes communiquent via des contrats de service ou utilisent la technologie Service Mesh, qui ajoute un niveau d'abstraction au réseau, comme l'outil de configuration Istio. Essayer de lancer toute la pile localement est tout simplement impossible. Je recommande vivement d'utiliser dans Kubernetes une plateforme de livraison continue (CD) telle que Spinnaker. Ainsi, vient un moment où chaque équipe a définitivement besoin de son propre espace de noms. Chaque équipe peut même choisir plusieurs espaces de noms pour l'environnement de développement et l'environnement de production.

Enfin, il existe de grandes entreprises où un groupe de développeurs ne sait même pas que d'autres groupes existent. Une telle entreprise peut même embaucher des développeurs externes qui interagissent via des API bien documentées. Dans chaque groupe, il y a plusieurs équipes et plusieurs microservices. Dans ce cas, il est nécessaire d'utiliser tous les outils dont j'ai parlé précédemment.

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

Ainsi, une bonne utilisation des espaces de noms par votre organisation permet de rendre Kubernetes plus gérable, contrôlable, sûr et flexible.

Les développeurs de Xenoblade Chronicles: Definitive Edition dans le dernier numéro du magazine Weekly Famitsu.

Un peu de publicité 🙂

Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, VPS cloud pour développeurs à partir de 4,99 $, un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbps à partir de 19 $ ou comment bien diviser un serveur ? (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To à partir de 199 $ aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 coûtant 9000 euros pour des clopinettes ?

Source : habr.com