‫Vous avez probablement déjà vu dans les exemples des
‫métadonnées dans ce fichier YAML et y
‫avez réfléchi en vous demandant à quoi servent les étiquettes et
‫les annotations.
‫Vous n'avez probablement pas réalisé leur signification.
‫Ils sont un élément clé de Kubernetes et de la manière dont les choses
‫se connectent les unes aux autres.
‫Beaucoup plus que Swarm.
‫Le premier est les étiquettes. Les étiquettes sont placées sous
‫la clé de métadonnées à la racine du fichier, elles
‫sont donc facultatives. Vous n'êtes pas obligé de les
‫mettre, mais elles constituent une valeur de clé, ou une liste de valeurs de clé,
‫sous l'en-tête des étiquettes.
‫Celles-ci sont là pour plusieurs raisons.
‫Ils ne sont pas toujours nécessaires, mais vous pouvez
‫en avoir besoin pour sélectionner les objets, les
‫regrouper et même les filtrer ultérieurement.
‫Cela peut être n'importe quoi qui décrit
‫l'objet ou la ressource.
‫Il peut s'agir d'une paire clé-valeur que la valeur est simplement
‫vraie ou fausse.
‫Les clés peuvent être ce que vous voulez.
‫Il ne peut tout simplement pas y avoir plus d'une clé dans chaque
‫objet. Par conséquent, vous ne pouvez pas avoir deux clés consécutives
‫dans le YAML pour le même objet ayant le nom de
‫clé de, disons app, à droite. Ceux-ci sont vraiment utilisés
‫pour décrire l'objet. Ces ressources que nous
‫créons ont des propriétés différentes.
‫Peut-être que c'est l'environnement comme prod, dev ou test.
‫Peut-être que c'est l'emplacement comme dmz, ou
‫backend ou frontend. Peut-être que c'est le nom de l'application,
‫ou peut-être le nom du client, si vous hébergez des sites clients ou
‫quelque chose du genre. Ce pourrait être simplement ce que
‫vous voulez et il n'y a pas beaucoup de normes.
‫La documentation Kubernetes répertoriée dans les ressources ci-dessous vous en donne
‫quelques exemples, mais ce ne sont que des exemples.
‫Il n'y a pas beaucoup de normes dans l'industrie.
‫C'est vraiment à votre équipe et à votre entreprise de
‫décider comment vous voulez décrire cette chose.
‫Nous avons aussi des annotations. Ils sont en quelque sorte un yin et un yang.
‫Les étiquettes sont très simples.
‫Ils sont très limités en taille et quels caractères
‫vous pouvez y mettre. Ils sont destinés à décrire la ressource.
‫Avec les annotations, c'est pour des données plus complexes et des
‫données à valeurs multiples, des choses comme ça.
‫Vous verrez généralement les annotations utilisées lorsque vous ajoutez
‫des éléments personnalisés dans Kubernetes qui peuvent parler à
‫Kubernetes et en extraire des données.
‫Les annotations sont là pour peut-être stocker des
‫données de configuration, comme les mandataires et les éléments d'entrée
‫peuvent souvent stocker différentes configurations, dans des annotations différentes.
‫Donc, ceux-ci ne sont pas nécessairement
‫là pour décrire, mais plus pour la configuration.
‫Revenons un instant aux étiquettes, car c’est
‫beaucoup plus important pour comprendre comment tout cela fonctionne
‫dans Kubernetes.
‫La première chose à faire est que nous pouvons faire de simples filtres en
‫limitant les étiquettes à partir de la ligne de commande.
‫Nous pouvons faire des pods get et simplement dire, montrez-moi
‫seulement les pods portant cette étiquette.
‫Vous pouvez même utiliser une virgule pour ajouter plusieurs étiquettes.
‫En fait, il y a tout un niveau de syntaxe dans cette
‫chose où vous pouvez faire différents types de syntaxes, différents or
‫et et et.
‫Vraiment, c’est l’une de ces choses pour
‫lesquelles je ne veux pas vous apprendre tout cela, car
‫c’est comme apprendre Regex. C'est quelque chose où vous ne l'apprendrez pas
‫vraiment en essayant juste une fois.
‫C'est seulement quand vous en avez besoin que vous
‫allez vraiment le comprendre. La documentation de Kubernetes
‫est vraiment excellente. Ils ont de nombreux
‫liens dans les ressources qui vous guideront à travers les différentes
‫manières dont vous pourriez avoir besoin d'étiquettes.
‫Franchement, vous n'avez pas vraiment besoin d'apprendre cela avant de savoir
‫que vous en avez besoin pour résoudre un problème.
‫Vous pouvez même l'utiliser pour appliquer des commandes.
‫Si vous aviez beaucoup de choses dans un seul gros fichier YAML
‫et que vous ne vouliez appliquer que certaines parties de
‫ce fichier YAML.
‫Je ne fais pas cela beaucoup, mais c'est
‫là que vous pouvez vous limiter, appliquez uniquement les modifications ou
‫les informations que vous avez insérées dans le YAML pour
‫des étiquettes spécifiques.
‫Bien sûr, encore une fois avec celui-ci, vous pouvez
‫utiliser la même syntaxe. Vous pouvez simplement avoir une seule étiquette.
‫Vous pouvez mettre des virgules, y avoir plusieurs étiquettes
‫et valeurs. C'est à vous.
‫Les étiquettes font une autre chose qui est importante
‫pour le fonctionnement de Kubernetes.
‫En résumé, certaines ressources peuvent communiquer avec d’autres
‫ressources, se connecter à elles ou
‫y sont liées.
‫Cependant, vous voulez le dire. Le bon exemple
‫est que les services doivent savoir à quels
‫pods envoyer leur trafic. Vous pourriez vous demander comment il sait?
‫Je veux dire, lorsque vous le tapez, si vous exécutez une commande
‫de service kubectl et que vous le dirigez vers
‫le déploiement, à quoi l'utilise-t-il exactement pour identifier ce déploiement?
‫Eh bien, dans l'interface de ligne de commande, vous pourriez penser que cela
‫pointe en fait sur l'objet de déploiement.
‫Mais vraiment, le service doit parler aux pods, pas
‫au déploiement lui-même.
‫Il utilise quelque chose appelé sélecteurs d'étiquettes.
‫Ceci est commun avec beaucoup de ressources différentes qui sont
‫des niveaux plus élevés d’abstraction des pods.
‫Pour qu’ils puissent s’identifier aux pods ou savoir à qui ils
‫appartiennent, ils utilisent des sélecteurs d’étiquettes. Vous verrez cela dans
‫le YAML de notre dépôt que vous avez
‫utilisé lors des dernières conférences.
‫Si vous regardez dans l'application. yml, vous remarquerez que depuis le
‫début, nous avons eu deux ou trois choses dont
‫nous n’avons pas parlé. Le premier est dans
‫la partie supérieure du service, nous avons un sélecteur sous la spécification.
‫Cela doit être là.
‫Nous lui indiquons la clé et la valeur d'une étiquette pour
‫les pods sur lesquels elle doit diriger le trafic.
‫C'est juste un match simple.
‫Il doit trouver des gousses avec ça.
‫Ensuite, dans le déploiement ci-dessous, vous verrez
‫que notre spécification a son propre
‫sélecteur, matchLabels, app, app-nginx.
‫Ce qui se passe là-bas, c'est que ces deux objets
‫sélectionnent des modules en fonction de cette correspondance.
‫Cela signifie que dans le modèle sous notre
‫spécification, où nous modélisons les pods, il doit y
‫avoir cette étiquette afin que ces ressources puissent trouver
‫leurs pods.
‫La bonne chose est dans les dernières versions
‫de Kubernetes, c'est qu'au moins avec un seul déploiement,
‫ceux-ci doivent être synchronisés. Le déploiement échouera s'il
‫constate que les étiquettes de correspondance de sélecteur ne correspondent
‫pas aux étiquettes de métadonnées du modèle, car elles doivent
‫le faire pour même déployer les modules et
‫pouvoir les contrôler.
‫Il est là pour vous empêcher de le
‫faire par inadvertance. Il s'attendra à ce
‫que vous ayez ces pièces là-bas. Dans les versions plus anciennes, il
‫existait un moyen de les générer automatiquement, par défaut, afin que
‫vous puissiez omettre les éléments. Ils ont cessé de le faire maintenant,
‫et ils vous obligent à mettre cela dedans. Je pense que
‫c'est une bonne chose, en particulier à quel point
‫ces sélecteurs d'étiquettes sont importants. Techniquement, si vous revenez à Swarm,
‫Swarm fait un peu de cet out-of-the-the-box où il a des étiquettes
‫qui correspondent à des choses allant de piles à des services,
‫des piles à leurs volumes, et des choses comme ça.
‫Nous ne pouvons pas vraiment le contrôler, et nous ne le voyons
‫pas beaucoup dans l'interface. C'est en quelque sorte
‫fait en arrière-plan pour nous dans Swarm.
‫Mais c'est aussi très limitant.
‫Vous ne pouvez pas changer les choses à la volée.
‫Vous ne pouvez pas forcément personnaliser ces options pour des
‫configurations vraiment uniques.
‫Ici, nous pourrions éventuellement demander à un service de
‫parler à plusieurs déploiements si nous
‫voulions changer ces sélecteurs.
‫Les sélecteurs ne se limitent pas à lier des ressources.
‫Il faut aussi contrôler où ils vont.
‫Sur les nœuds, vous pouvez utiliser des étiquettes et des sélecteurs
‫pour contrôler leur déplacement.
‫Vous pouvez utiliser une personnalisation encore plus poussée avec des choses
‫appelées «tainting» et «tolérance» qui sont en quelque sorte
‫l'inverse de celle où vous dites aux nœuds qu'ils ne peuvent pas
‫faire certaines choses, afin que Kubernetes sache où contrôler
‫en gros où vont vos pods.
‫Ces choses deviennent vraiment personnalisées et vraiment
‫avancées assez rapidement. Les faire tous ensemble peut
‫devenir un peu poilu et fou.
‫Je vous recommande de prendre votre temps avec eux.
‫Gardez le tout simple et prêt à l'emploi.
‫Évitez les souillures et les tolérances jusqu'à ce que vous ayez vraiment
‫besoin de les examiner.
‫D'accord. Nettoyons pour toute cette section.
‫Si quelque chose tourne dans un espace de noms par défaut pour
‫votre cluster, si vous ne faites que tout obtenir par
‫kubectl, et que vous voyez des éléments autres que l'API Kubernetes
‫elle-même, supprimez toutes ces ressources, car nous allons passer à autre
‫chose. . Nous n'aurons pas besoin de ceux-ci.