À mesure que vous commencez à créer de plus en plus de services Kubernetes, les tâches initialement simples commencent à devenir plus complexes. 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 possédez des milliers de pods, le simple fait de les lister prendra beaucoup de temps, sans parler de les gérer correctement. Et ce n'est que la pointe de l'iceberg.
Voyons comment l'espace de noms facilite la gestion des ressources Kubernetes. Alors, qu’est-ce qu’un espace de noms ? L'espace de noms peut être considéré comme un cluster virtuel au sein de votre cluster Kubernetes. Vous pouvez avoir plusieurs espaces de noms isolés les uns des autres au sein d'un seul cluster Kubernetes. Ils peuvent vraiment vous aider, vous et vos équipes, en termes d'organisation, de sécurité et même de performances du système.
Sur la plupart des distributions Kubernetes, le cluster sort de la boîte avec un espace de noms appelé « par défaut ». Kubernetes gère en fait trois espaces de noms : default, kube-system et kube-public. Actuellement, Kube-public n’est pas utilisé très souvent.
Laisser l'espace de noms Kube seul est une bonne idée, en particulier sur un système géré comme Google Kubernetes Engine. Il utilise l'espace de noms « par défaut » comme endroit où vos services et applications sont créés. Il n'y a absolument rien de spécial, sauf que Kubernetes est configuré immédiatement pour l'utiliser et que vous ne pouvez pas le supprimer. C'est idéal pour démarrer et pour les systèmes peu performants, mais je ne recommanderais pas d'utiliser l'espace de noms par défaut sur 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 interrompre 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 unités gérables. Un espace de noms peut être créé avec une seule commande. Si vous souhaitez créer un espace de noms 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 afficher tous les espaces de noms à l'aide de la commande $ kubectl get namespace.
Une fois cela fait, 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 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 actuellement actif. Ce sera l'espace de noms par défaut jusqu'à ce que vous le modifiiez. Il existe deux façons d'indiquer à Kubernetes dans quel espace de noms vous souhaitez créer votre ressource. La première consiste à utiliser un indicateur d'espace de noms lors de la création d'une 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 de noms. Si vous essayez d'utiliser un espace de noms différent tout en utilisant l'indicateur d'espace de noms, la commande échouera. Désormais, si vous essayez de trouver votre pod, vous ne pourrez pas le faire.
Cela se produit car toutes les commandes sont exécutées en dehors de l'espace de noms actuellement actif. Pour trouver votre pod, vous devez utiliser un indicateur d'espace de noms, mais cela devient vite ennuyeux, surtout si vous êtes un développeur dans une équipe qui utilise son propre espace de noms et ne souhaite pas utiliser cet indicateur pour chaque commande. Voyons comment nous pouvons résoudre ce problème.
Par défaut, votre espace de noms actif est appelé par défaut. Si vous ne spécifiez pas d'espace de noms dans la ressource YAML, toutes les commandes Kubernetes utiliseront cet espace de noms actif par défaut. Malheureusement, essayer de gérer l'espace de noms actif à l'aide de kubectl peut échouer. Cependant, il existe un très bon outil appelé Kubens qui facilite grandement ce processus. Lorsque vous exécutez la commande kubens, vous voyez tous les espaces de noms avec l'espace de noms actif en surbrillance.
Pour basculer l'espace de noms actif vers l'espace de noms de test, exécutez simplement la commande $kubens test. Si vous exécutez ensuite à nouveau la commande $kubens, vous verrez qu'un nouvel espace de noms actif est désormais alloué - test.
Cela signifie que vous n'avez pas besoin de l'indicateur d'espace de noms pour voir le pod dans l'espace de noms de test.
De cette façon, les espaces de noms sont cachés les uns des autres, mais pas isolés les uns des autres. Un service dans un espace de noms peut communiquer assez facilement avec un service dans un autre espace de noms, ce qui est souvent très utile. La possibilité de communiquer entre différents espaces de noms signifie que le service de vos développeurs peut communiquer avec le service d'une autre équipe de développement dans un espace de noms différent.
En règle générale, lorsque votre application souhaite accéder à un service Kubernetes, vous utilisez le service de découverte DNS intégré et donnez simplement à votre application le nom du service. Cependant, ce faisant, vous pouvez créer un service sous le même nom dans plusieurs espaces de noms, ce qui n'est pas acceptable.
Heureusement, il est facile de contourner ce problème 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 du nom du service et DNS déterminera automatiquement l’adresse complète.
Cependant, si vous devez accéder à un service dans un espace de noms différent, utilisez simplement le nom du service plus le nom de l'espace de noms :
Par exemple, si vous souhaitez vous connecter à une base de données de service dans un espace de noms de test, vous pouvez utiliser la base de données d'adresses database.test
Si vous souhaitez vous connecter à la base de données du 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 vous permet de le faire à l'aide des stratégies réseau Kubernetes. J'en parlerai dans le prochain épisode.
On me pose souvent la question : combien d’espaces de noms dois-je créer et dans quel but ? Qu’est-ce qu’une donnée gérée ?
Si vous créez trop d’espaces de noms, ils vous gêneront. S’ils sont trop peu nombreux, vous perdrez tous les bénéfices d’une telle solution. Je pense qu'il y a quatre étapes principales que traverse chaque entreprise lors de la création de sa structure organisationnelle. En fonction du stade de développement de votre projet ou de votre entreprise, vous souhaiterez peut-être adopter une stratégie d'espace de noms appropriée.
Imaginez que vous faites partie d'une petite équipe qui travaille au développement de 5 à 10 microservices et que vous pouvez facilement rassembler tous les développeurs dans une seule pièce. Dans cette situation, il est logique d'exécuter tous les services de production dans l'espace de noms par défaut. Bien entendu, pour plus de flexibilité, vous pouvez utiliser 2 espaces de noms – séparément pour la production et le développement. Et très probablement, vous testez votre développement sur votre ordinateur local en utilisant quelque chose comme Minikube.
Disons que les choses changent et que vous disposez désormais d'une équipe en croissance rapide travaillant sur plus de 10 microservices à la fois. Il arrive un moment où il est nécessaire d'utiliser plusieurs clusters ou espaces de noms, séparément pour la prod et le dev. Vous pouvez diviser l'équipe en plusieurs sous-équipes afin que chacune d'entre elles dispose de 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 publication de logiciels.
À mesure que chaque membre de l’équipe comprend mieux le fonctionnement du système dans son ensemble, il devient de plus en plus difficile de coordonner chaque changement avec tous les autres développeurs. Essayer de créer une pile complète sur votre machine locale devient de plus en plus difficile chaque jour.
Dans les grandes entreprises, les développeurs ne savent généralement pas qui travaille exactement sur quoi. Les équipes communiquent à l'aide de contrats de service ou utilisent la technologie de maillage de services, qui ajoute une couche d'abstraction sur le réseau, comme l'outil de configuration Istio. Essayer d'exécuter une 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. Il arrive donc un moment où chaque commande 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 entrepreneuriales dans lesquelles un groupe de développeurs ne connaît même pas l'existence d'autres groupes. Une telle entreprise peut généralement embaucher des développeurs tiers qui interagissent avec elle via des API bien documentées. Chacun de ces groupes contient plusieurs équipes et plusieurs microservices. Dans ce cas, vous devez utiliser tous les outils dont j'ai parlé plus tôt.
Les programmeurs ne doivent pas déployer manuellement de services 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 de souffle » des applications mal configurées, pour simplifier les processus de facturation et la gestion des ressources.
Ainsi, une utilisation appropriée des espaces de noms par votre organisation vous permet de rendre Kubernetes plus gérable, contrôlable, sécurisé et flexible.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com