Objets cl\u00e9s<\/h3>\n\n\n\n
Les deux objets cl\u00e9s sont les Pods et les Nodes (n\u0153uds).<\/p>\n\n\n\n
Pods<\/h4>\n\n\n\n
Un Pod est ce qui se rapproche le plus d\u2019un conteneur dans Kubernetes. Il contient un conteneur et lui fournit les ressources dont il a besoin pour fonctionner, notamment la RAM, le stockage, l\u2019acc\u00e8s au CPU, une adresse IP, un port TCP\/UDP, etc.<\/p>\n\n\n\n
(En r\u00e9alit\u00e9, si plusieurs conteneurs peuvent fonctionner avec le m\u00eame ensemble de ressources, vous pouvez placer tous ces conteneurs dans un seul Pod.)<\/p>\n\n\n\n
Le sch\u00e9ma ci-dessous illustre un Pod contenant deux conteneurs, ainsi qu\u2019une adresse IP, de la RAM et du stockage. C\u2019est \u00e9galement un bon moment pour pr\u00e9ciser que chaque Pod re\u00e7oit dynamiquement une adresse IP lors de sa cr\u00e9ation, de mani\u00e8re similaire au fonctionnement de DHCP.<\/p>\n\n\n
![\"Kubernetes](\"https:\/\/www.cengn.ca\/wp-content\/uploads\/2022\/04\/Pods-1024x1024.png\")
<\/figure>\n<\/div>\n\n\nLes n\u0153uds<\/h4>\n\n\n\n
Un Node est une plateforme de calcul (par exemple, une machine virtuelle). Dans Kubernetes, il existe deux types de Nodes :<\/p>\n\n\n\n
- \n
- N\u0153uds workers : plateformes sur lesquelles les Pods sont ex\u00e9cut\u00e9s.<\/li>\n\n\n\n
- N\u0153uds ma\u00eetres : ils g\u00e8rent un ensemble de Worker Nodes associ\u00e9s ainsi que leurs Pods. Cet ensemble est appel\u00e9 un Cluster (cluster).<\/li>\n<\/ul>\n\n\n\n
Comme illustr\u00e9 ci-dessous, les utilisateurs finaux interagissent g\u00e9n\u00e9ralement avec les Worker Nodes…<\/p>\n\n\n
\n![\"Kubernetes](\"https:\/\/www.cengn.ca\/wp-content\/uploads\/2022\/04\/Nodes-1024x786.png\")
<\/figure>\n<\/div>\n\n\nConcepts cl\u00e9s<\/h3>\n\n\n\n
Les deux concepts cl\u00e9s sont \u00ab l\u2019\u00e9tat souhait\u00e9 \u00bb (desired state<\/em>) et \u00ab l\u2019\u00e9tat actuel \u00bb (current state<\/em>).<\/p>\n\n\n\n
L\u2019\u00e9tat souhait\u00e9 correspond \u00e0 l\u2019\u00e9tat id\u00e9al dans lequel vous voulez que votre Cluster se trouve.<\/p>\n\n\n\n
L\u2019\u00e9tat actuel correspond \u00e0 la situation r\u00e9elle de votre Cluster \u00e0 un instant donn\u00e9.<\/p>\n\n\n\n
Kubernetes vous permet de d\u00e9finir l\u2019\u00e9tat souhait\u00e9 de votre Cluster \u2014 par exemple : 100 Pods Nginx ex\u00e9cut\u00e9s sur des Nodes \u00e0 Ottawa, 200 Pods Nginx ex\u00e9cut\u00e9s sur des Nodes \u00e0 Chicago, 50 Pods MySQL ex\u00e9cut\u00e9s sur des Nodes \u00e0 Toronto, etc. Une fois cet \u00e9tat d\u00e9fini, les Master Nodes de Kubernetes surveillent l\u2019ensemble des Workers et des Pods du Cluster afin de s\u2019assurer que son \u00e9tat actuel correspond \u00e0 l\u2019\u00e9tat souhait\u00e9 configur\u00e9. Si l\u2019un des Pods Nginx \u00e0 Ottawa cesse de r\u00e9pondre, les Master Nodes prennent automatiquement les mesures n\u00e9cessaires pour r\u00e9soudre le probl\u00e8me.<\/p>\n\n\n\n
Pour parvenir \u00e0 cet objectif, qui consiste \u00e0 faire correspondre l\u2019\u00e9tat actuel \u00e0 l\u2019\u00e9tat souhait\u00e9, Kubernetes utilise une architecture en couches, \u00e0 la fois ing\u00e9nieuse et complexe. Chaque objet poss\u00e8de ses propres responsabilit\u00e9s et collabore avec d\u2019autres objets ayant leurs propres fonctions.<\/p>\n\n\n\n
Au le plus bas, le r\u00f4le d\u2019un Pod est d\u2019ex\u00e9cuter le ou les conteneurs qu\u2019il contient. De plus, les Pods sont con\u00e7us pour \u00eatre \u00e9ph\u00e9m\u00e8res : ne vous attendez donc pas \u00e0 ce que les Pods que vous cr\u00e9ez aujourd\u2019hui soient encore l\u00e0 demain. Si un conteneur \u00e0 l\u2019int\u00e9rieur d\u2019un Pod tombe en panne, le Pod ne va pas activement signaler ce probl\u00e8me aux autres composants ; cette responsabilit\u00e9 incombe \u00e0 un autre \u00e9l\u00e9ment de l\u2019architecture.<\/p>\n\n\n\n
Un niveau au-dessus des Pods se trouve le Deployment, qui g\u00e8re un ensemble de Pods et surveille leur \u00e9tat de sant\u00e9. Dans notre sc\u00e9nario pr\u00e9c\u00e9dent, nous pourrions cr\u00e9er un Deployment charg\u00e9 de maintenir les 100 Pods d\u2019Ottawa en fonctionnement. Si l\u2019un de ces Pods cesse de r\u00e9pondre, plut\u00f4t que de perdre du temps \u00e0 essayer de le r\u00e9parer, le Pod est supprim\u00e9 et un nouveau Pod est cr\u00e9\u00e9 pour le remplacer (au niveau du Deployment).<\/p>\n\n\n\n
Cette approche ressemble au support informatique dans une grande organisation : lorsqu\u2019un ordinateur portable rencontre un probl\u00e8me, la solution la plus rapide consiste souvent \u00e0 r\u00e9installer compl\u00e8tement le syst\u00e8me (re-image<\/em>) ou m\u00eame \u00e0 remplacer l\u2019ordinateur.<\/p>\n\n\n\n
Cette approche est excellente pour cr\u00e9er des applications hautement disponibles et \u00e9volutives, reposant sur un grand nombre de Pods. Cependant, elle introduit \u00e9galement certains d\u00e9fis en mati\u00e8re de r\u00e9seau.<\/p>\n\n\n\n
Plus particuli\u00e8rement, chaque Pod re\u00e7oit dynamiquement son adresse IP au moment de sa cr\u00e9ation. Un syst\u00e8me de mise en r\u00e9seau bas\u00e9 sur les adresses IP des Pods serait donc impossible \u00e0 g\u00e9rer dans un environnement d\u2019entreprise.<\/p>\n\n\n\n
Les Services r\u00e9seau de Kubernetes<\/h2>\n\n\n\n
Les Services Kubernetes offrent une approche judicieuse pour g\u00e9rer le r\u00e9seau avec des Pods \u00e9ph\u00e9m\u00e8res. Un Service est un objet Kubernetes qui vous permet d\u2019acc\u00e9der \u00e0 plusieurs Pods identiques en fonction des labels qui leur sont associ\u00e9s, ind\u00e9pendamment de leurs adresses IP. Il est utile de consid\u00e9rer les Services comme utilisant des \u00ab noms \u00bb (au sens large) plut\u00f4t que des adresses IP ou des ports. Dans la suite de cet article, nous examinerons cinq types de Services Kubernetes.<\/p>\n\n\n\n
Service ClusterIP<\/h3>\n\n\n\n
\u00a0ClusterIP est le type de Service par d\u00e9faut dans Kubernetes. Le Service ClusterIP est con\u00e7u pour la communication d’application \u00e0 application au sein d’un cluster. Par exemple, prenons le cas d’une application web et d’une application SMB qui doivent fonctionner ensemble. Dans le diagramme, les Pods de l’application web portent l’\u00e9tiquette X, et les Pods SMB portent l’\u00e9tiquette Y.<\/p>\n\n\n\n
Si le Pod de l’application web situ\u00e9 \u00e0 l’adresse 10.0.0.2 a besoin de quelque chose de l’application SMB, il pourrait envoyer une requ\u00eate au Pod situ\u00e9 \u00e0 10.0.0.4:445\u2026 jusqu’\u00e0 ce que ce Pod finisse in\u00e9vitablement par dispara\u00eetre et soit remplac\u00e9 par un Pod identique \u00e0 une autre adresse IP.<\/p>\n\n\n\n
Pour r\u00e9soudre ce probl\u00e8me, nous pouvons d\u00e9finir deux Services ClusterIP : le \u00ab Service X \u00bb pour l’application web et le \u00ab Service Y \u00bb pour l’application SMB. Chaque Service ClusterIP pr\u00e9sente une adresse IP virtuelle stable et une valeur de port par lesquelles les Pods peuvent le contacter. L’autre extr\u00e9mit\u00e9 du Service se connecte aux Pods poss\u00e9dant la valeur d’\u00e9tiquette appropri\u00e9e (les \u00ab endpoints \u00bb), quelle que soit l’adresse IP du Pod. S’il existe plusieurs Pods avec une valeur d’\u00e9tiquette valide, le Service ClusterIP effectue une r\u00e9partition de charge entre ces Pods.<\/p>\n\n\n
\n![\"Kubernetes](\"https:\/\/www.cengn.ca\/wp-content\/uploads\/2022\/04\/ClusterIP-Service-1024x850.png\")
<\/figure>\n<\/div>\n\n\nNotez que le Service ClusterIP peut se connecter aux Pods pertinents \u00e0 travers plusieurs Nodes du cluster. Notez \u00e9galement que l’\u00e9tiquette est d\u00e9finie dans le fichier manifeste du Pod, de sorte que chaque nouvelle instance de ce Pod portera cette m\u00eame \u00e9tiquette, ce qui le rendra accessible au Service quelle que soit son adresse IP.<\/p>\n\n\n\n
Un d\u00e9tail important : l’adresse IP pr\u00e9sent\u00e9e par le Service ClusterIP est appel\u00e9e le \u00ab ClusterIP \u00bb, et le port pr\u00e9sent\u00e9 est appel\u00e9 le \u00ab Port \u00bb. (C’est l\u00e0 que je me demande toujours pourquoi ils n’ont pas simplement appel\u00e9 \u00e7a le \u00ab ClusterPort \u00bb !)<\/p>\n\n\n\n
Pour approfondir un peu, voici un exemple de fichier manifeste de Service ClusterIP :<\/p>\n\n\n\n
apiVersion: v1\nkind: Service\nmetadata:\nname: service-x-cip #ClusterIP for web app\nspec:\n type: ClusterIP #optional for a ClusterIP Service\n ports:\n - port: 8080 #Port for the Service (IP is assigned) \n protocol: TCP \n targetPort: 80 #port on the Pod\n selector:\n app: web-app #Service will look for pods with this Label <\/code><\/pre>\n\n\n\nLe champ \u00ab type \u00bb est facultatif pour un Service ClusterIP ; s’il n’y a pas de champ \u00ab type \u00bb dans le fichier manifeste d’un Service, Kubernetes utilise ClusterIP par d\u00e9faut. De plus, l’adresse ClusterIP est attribu\u00e9e automatiquement par Kubernetes lors de la cr\u00e9ation du Service. Pour afficher cette adresse IP, utilisez cette commande :<\/p>\n\n\n\n
# kubectl get svc service-x-cip<\/code><\/pre>\n\n\n\nPour plus de d\u00e9tails, ajoutez l’option \u00ab -o wide \u00bb. Pour un affichage complet des propri\u00e9t\u00e9s fonctionnelles du Service, utilisez cette commande :<\/p>\n\n\n\n
# kubectl describe svc service-x-cip<\/code><\/pre>\n\n\n\nNodePort Service <\/h3>\n\n\n\n
Le type de Service NodePort rend l’application conteneuris\u00e9e accessible depuis l’ext\u00e9rieur du cluster. Le Service NodePort expose les Pods de l’application sur un port statique (le NodePort) sur chaque Node. Dans la logique de superposition, le Service NodePort cr\u00e9e automatiquement un Service ClusterIP correspondant pour r\u00e9pondre aux besoins de mise en r\u00e9seau d’application \u00e0 application ; le Service NodePort ne reproduit pas la fonctionnalit\u00e9 du ClusterIP.<\/p>\n\n\n
\n![\"Kubernetes](\"https:\/\/www.cengn.ca\/wp-content\/uploads\/2022\/04\/NodePort-Service-1024x576.png\")
<\/figure>\n<\/div>\n\n\nLe diagramme illustre un Service NodePort qui expose le Pod Nginx sur le Node 1. Pour acc\u00e9der \u00e0 ce Pod, l’utilisateur peut naviguer (ou faire un curl) vers 10.0.0.2:30001 (c’est-\u00e0-dire NodeIP:NodePort). Bien que le diagramme ne montre qu’un seul Pod Nginx, plusieurs endpoints sont \u00e9galement possibles. Comme pour un Service ClusterIP, un Service NodePort d\u00e9finit ses endpoints via un s\u00e9lecteur dans le fichier manifeste du Service et des \u00e9tiquettes correspondantes dans le fichier manifeste du Pod. Ainsi, s’il y a plusieurs Pods Nginx sur ce Node, portant l’\u00e9tiquette appropri\u00e9e, le Service NodePort peut envoyer la requ\u00eate \u00e0 n’importe lequel de ces Pods.<\/p>\n\n\n\n
Vous devez acc\u00e9der au Node par adresse IP, ce qui signifie que le Service NodePort est sp\u00e9cifique \u00e0 un Node. Cela diff\u00e8re d’un Service ClusterIP, qui peut acc\u00e9der aux Pods pertinents sur de nombreux autres Nodes du cluster. Cela signifie \u00e9galement que le Service NodePort n’est accessible qu’aux personnes pouvant effectuer un ping vers le Node ; il n’est pas ouvert \u00e0 l’acc\u00e8s public depuis Internet.<\/p>\n\n\n\n
Examinons un fichier manifeste de Service NodePort :
<\/p>\n\n\n\napiVersion: v1\nkind: Service\nmetadata:\n name: service-x-np\nspec:\n type: NodePort # this is required for NodePort Service\n ports: \n - port: 8080 #Port for the ClusterIP Service\n protocol: TCP\n targetPort: 80 #port on the Pod\n selector:\n app: web-app #Service will look for pods with this Label <\/code><\/pre>\n\n\n\nCe fichier manifeste est assez similaire au manifeste ClusterIP. Cependant, vous devez sp\u00e9cifier le type comme \u00ab NodePort \u00bb ; si vous ne le faites pas, Kubernetes utilisera par d\u00e9faut un Service ClusterIP. Et la ligne \u00ab port \u00bb est utilis\u00e9e pour le Service ClusterIP g\u00e9n\u00e9r\u00e9 automatiquement.<\/p>\n\n\n\n
Alors, qu’en est-il du NodePort, le port de ce Service NodePort ?<\/p>\n\n\n\n
Kubernetes vous donne la possibilit\u00e9 de sp\u00e9cifier vous-m\u00eame la valeur du NodePort (port), ou de la laisser \u00eatre d\u00e9finie automatiquement. Dans tous les cas, la valeur du NodePort se situe toujours entre 30 000 et 32 767. Dans l’exemple ci-dessus, nous avons laiss\u00e9 Kubernetes choisir la valeur du NodePort pour nous, et nous avons obtenu 30 001.<\/p>\n\n\n\n
Comme pour notre exemple ClusterIP, pour afficher les valeurs NodeIP et NodePort de ce service, entrez :<\/p>\n\n\n\n
# kubectl get svc service-x-cip<\/code><\/pre>\n\n\n\nPour plus de d\u00e9tails, entrez :<\/p>\n\n\n\n
# kubectl describe svc service-x-cip<\/code><\/pre>\n\n\n\nBien que le Service NodePort soit rattach\u00e9 \u00e0 un Node particulier, vous pouvez l’\u00e9tendre \u00e0 d’autres Nodes du cluster en r\u00e9servant la valeur du port NodePort sur les autres Nodes et en les redirigeant vers le Service NodePort. Par exemple, vous pourriez d\u00e9finir une r\u00e8gle selon laquelle tout trafic vers 10.0.0.3:30001 serait redirig\u00e9 vers 10.0.0.2:30001. Mais cela ne semble gu\u00e8re \u00eatre une mani\u00e8re appropri\u00e9e de rendre une application accessible sur le web\u2026<\/p>\n\n\n\n
Service LoadBalancer<\/strong><\/h3>\n\n\n\n
Un Service LoadBalancer est la mani\u00e8re appropri\u00e9e d’exposer un Service \u00e0 Internet. Ce type de Service s’appuie sur la fonction de r\u00e9partition de charge (load balancer) d’un fournisseur cloud comme AWS ou Azure.<\/p>\n\n\n\n
Examinons un exemple de fichier manifeste pour un Service LoadBalancer :<\/p>\n\n\n\n
apiVersion: v1\nkind: Service\nmetadata:\n name: service-x-lb\nspec:\n type: LoadBalancer # definitely required!\n ports:\n - port: 8080 #Port for the ClusterIP Service\n protocol: TCP\n targetPort: 80 #port on the Pod\n selector:\n app: web-app #Service will look for pods with this Label<\/code><\/pre>\n\n\n\nLa structure devrait maintenant vous \u00eatre famili\u00e8re. Comme pour le Service NodePort, veillez \u00e0 bien sp\u00e9cifier le type de Service, sinon vous vous retrouverez avec un Service ClusterIP. Sans surprise, un Service LoadBalancer cr\u00e9era automatiquement un Service NodePort et un Service ClusterIP pour g\u00e9rer les autres aspects de l’\u00e9quation. Mais c’est le fournisseur cloud qui d\u00e9cidera de la mani\u00e8re dont ces Services sous-jacents sont provisionn\u00e9s. Un Service LoadBalancer g\u00e9n\u00e8re plusieurs machines virtuelles g\u00e9r\u00e9es par le fournisseur, qui traitent le trafic r\u00e9el. Et les d\u00e9cisions fondamentales de r\u00e9partition de charge sont g\u00e9r\u00e9es par le fournisseur, et non par Kubernetes. Cela peut \u00eatre un avantage ou un inconv\u00e9nient selon votre point de vue.<\/p>\n\n\n\n
Le principal inconv\u00e9nient est que chaque Service LoadBalancer n\u00e9cessite sa propre adresse IP publique ; si vous souhaitez plusieurs LoadBalancers, cela peut rapidement devenir co\u00fbteux. Certains fournisseurs cloud vous permettent de sp\u00e9cifier l’adresse IP du Service LoadBalancer, ce qui constitue au moins un point positif.<\/p>\n\n\n\n
Autres types de Service de mise en r\u00e9seau Kubernetes<\/strong><\/h3>\n\n\n\n
Les trois Services ci-dessus visent tous un objectif commun : rendre les applications distribu\u00e9es accessibles sur Internet et garantir qu’elles puissent communiquer entre elles. Bien que cela couvre la plupart des cas d’usage, d’autres sc\u00e9narios entrent parfois en jeu.<\/p>\n\n\n\n
ExternalName Service<\/h4>\n\n\n\n
Le Service ExternalName est con\u00e7u pour pointer vers un nom de domaine canonique en vue d’une r\u00e9solution DNS. Ce type de Service redirige le trafic \u00e0 travers un alias interne, puis vers une ressource externe. Par exemple, vous pourriez utiliser un Service ExternalName pour diriger le trafic des Pods vers une base de donn\u00e9es externe, comme dans le fichier manifeste suivant :<\/p>\n\n\n\n
kind: Service\napiVersion: v1\nmetadata:\n name: external-db\nspec:\n type: ExternalName # don\u2019t forget this line!\n externalName: mysql.cengn.ca # note the FQDN structure\n ports:\n - protocol: TCP\n port: 80 <\/code><\/pre>\n\n\n\nService Headless<\/strong><\/h4>\n\n\n\n
Un Service Headless correspond \u00e0 un Pod sp\u00e9cifique sans cr\u00e9er d’adresse IP virtuelle (ce qui est totalement diff\u00e9rent d’un Service ClusterIP). Les Services Headless conviennent aux applications avec \u00e9tat (stateful), o\u00f9 chaque Pod stocke des donn\u00e9es uniques et persistantes. De plus, ils permettent aux utilisateurs d’interagir directement avec le Pod cible.<\/p>\n\n\n\n
Voici un exemple de fichier manifeste pour un Service Headless. Remarquez que le champ habituel \u00ab type \u00bb est remplac\u00e9 par la ligne \u00ab clusterIP: None \u00bb.<\/p>\n\n\n\n
apiVersion: v1\nkind: Service\nmetadata:\n name: headless-svc\nspec:\n clusterIP: None # this is the crucial bit here\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080\n selector:\n app: myheadlessapp<\/code><\/pre>\n\n\n\nR\u00e9capitulatif<\/strong><\/h2>\n\n\n\n
So, there you have it.<\/p>\n\n\n\n
Kubernetes enables you to run highly available containerized apps using millions of Pods on thousands of Nodes around the world. Along the way, we ran into a serious problem with networking those Pods together, but Kubernetes also provides a clever set of solutions through its networking Services.<\/p>\n\n\n\n
Want to learn more about Kubernetes? Go from intro to expert with CENGN’s Docker + Kubernetes Basics and Advanced courses. <\/em><\/p>\n\n\n\n
Build your confidence with hands-on experience in online labs and learn on your own schedule.<\/em><\/p>\n\n\n\n
Voil\u00e0, vous savez maintenant tout.<\/p>\n\n\n\n
Kubernetes vous permet d’ex\u00e9cuter des applications conteneuris\u00e9es hautement disponibles en utilisant des millions de Pods sur des milliers de Nodes \u00e0 travers le monde. En chemin, nous avons rencontr\u00e9 un probl\u00e8me s\u00e9rieux concernant la mise en r\u00e9seau de ces Pods entre eux, mais Kubernetes propose \u00e9galement un ensemble ing\u00e9nieux de solutions gr\u00e2ce \u00e0 ses Services de mise en r\u00e9seau.<\/p>\n\n\n\n
Vous voulez en apprendre davantage sur Kubernetes ? Passez de d\u00e9butant \u00e0 expert avec les cours Docker + Kubernetes Basics et Advanced de CENGN.<\/em><\/p>\n\n\n\n
D\u00e9veloppez votre confiance gr\u00e2ce \u00e0 une exp\u00e9rience pratique dans des laboratoires en ligne, et apprenez \u00e0 votre propre rythme.<\/em><\/p>\n\n\n\n