L'abc de Kubernetes

1. Introduction: Ok, bonjour et bienvenue à Kubernetes Warner 1. Ça va être bien. Et puis oui, on va apprendre des trucs, mais absolument on va s'amuser à le faire. Maintenant, tout de suite, tout de suite. Ok, fixons un objectif dans ce cours à ceux d'entre vous qui sont nouveaux à Kubernetes. En fait, vous n'avez même pas vraiment besoin d'utiliser Docker maintenant en informatique ou un arrière-plan de développeur peut être utile, mais vous savez quoi, ce n'est pas une exigence. Donc aucune expérience préalable n'est nécessaire. En outre, comme le titre l'indique, c'est un cours 1.0.1. Ça veut dire que si tu ne le fais pas, tu ne vas pas partir en tant que gourou de Kubernetes, désolé pour ça. Mais vous allez partir en sachant ce qu'est Kubernetes et comment ça marche. Et vous aurez une idée de certaines des choses qu'il peut faire pour vous afin que, j'espère, vous regarderez dans vos premiers pas avec Kubernetes. Eh bien, qui suis-je ? Je suis Nigel, et si vous ne le savez pas déjà, je passe ma vie à enseigner le monde, Docker et Kubernetes. Il est comme si tout ce truc était à moi. Et en plus de cela, je suis sur le circuit des haut-parleurs et je donne des ateliers et des événements comme Docker Con et ce que vous avez. Maintenant. Évidemment, je recommande fortement mes autres trucs pour prendre les prochaines étapes. Mais encore une fois, je ne voudrais pas dire, c'est le mien ont raison. Mais je vais vous dire ce que vous êtes le juge, voir ce que vous ressentez après ce cours. Et si tu aimes ça, laisse-moi te dire que tu vas adorer ça. Quoi qu'il en soit, c'est moi sur Twitter et j'ai envie de me connecter et de parler de technologie. Mais je dois dire ça bien ? Je suis occupé comme vous, donc je ne peux pas être un support technique gratuit. Je veux dire, je suis heureux de parler de technologie, mais de dépannage complexe. Ouais, je suis vraiment désolé. Je n'ai pas le temps. De toute façon. Regarde, je fais ce genre de chose depuis longtemps maintenant. Donc je suis confiant quand je dis, je pense que ça va vous plaire. Et je suis tout aussi confiant que vous partirez en vous sentant que vous avez beaucoup appris. Mais regarde, je gaufre. C' est comme ça que nous faisons les choses. Trancher dans le cours à peu près au milieu, la première moitié. Donc peut-être une heure ou deux. On va clouer la théorie comme les trucs d'architecture de Kubernetes ici. Ensuite, dans la seconde moitié va obtenir la main sur. Maintenant, écoute, c'est un cours vidéo, non ? C' est votre appel, que vous suiviez les choses pratiques ou que vous regardiez totalement votre cœur. Mais ce que je ne veux pas que tu fasses bien. Et croyez-moi, ne sautez pas la théorie parce que c'est vraiment important, comme si je vais l'utiliser pour mettre la scène et vous préparer pour les trucs pratiques. Parce que tu sais quoi ? Je n'ai aucun intérêt à ce que tu sois capable de suivre et d'être brillant ou de taper commandes si tu ne comprends pas vraiment ce qui se passe, crois-moi, non ? J' y suis allé moi-même. Tu ouvres un cours de recyclage. Vous suivez tous les exercices. Parfois, vous ne faites même pas une seule faute de frappe à la fin quand vous ne le faites pas, vous n'êtes pas le plus sage. Vous n'avez rien appris. Donc, comme si quelqu'un vous demandait ce que les commandes dans le truc en fait mort. Je veux dire, qui sait, non ? Donc je ne veux pas que vous suiviez la théorie. En parlant de la théorie, nous allons décrire ce qu'est réellement une application de microservices natifs dans le cloud. Ensuite, nous découvrirons ce qu'est Kubernetes. Nous verrons comment c'est un cluster, puis nous verrons comment c'est un orchestrateur d'applications, h2. Et je sais, c'est beaucoup de mots à la mode, mais tout est bon parce que nous allons expliquer chacun d' entre eux au fur et à mesure que nous allons et aussi contextualiser choses en regardant un flux de travail typique de la façon dont vous prenez l'application de sur l'ordinateur portable d'un développeur pour être réellement dans une application en cours d'exécution. Quoi qu'il en soit, quand on aura fini avec la théorie, alors ce sera la pratique. Nous allons lancer un test rapide. L' environnement Kubernetes va déployer une application, se connecter à elle, tester un échec et dire une partie de l'auto-guérison qui se poursuit. Nous évoluons vers le haut et vers le bas, connectons à un équilibreur de charge et nous ferons une mise à jour progressive. Maintenant. Je sais que ça peut sembler beaucoup de choses, mais nous allons rester simple et nous allons tout expliquer au fur et à mesure. Sonne bien. Faisons-le. 2. Microservices originaux du cloud: Ok, donc parlons de quoi, dans le diable, un microservice natif dans le cloud même maintenant, il y a une tonne de définitions là-bas, donc je vais le faire bouillir pour vous. Mettez les premières choses en premier. Remontons un peu l'horloge. Vous dites, à l'époque, nous construisons nos applications où nous avons regroupé toutes les fonctionnalités et la logique et les différents bits dans un seul programme comme un seul binaire. Maintenant, je suis de haut niveau ici. Mais nous prenons peut être les bits d'interface utilisateur, tous les trucs middleware, ce backend de base de données et les systèmes de reporting et tout ce que l'application a jamais rêvé de faire. Et on s'était regroupés en un seul programme énorme et on l' installait , le sauvegarderait et le gérait et tout ce jazz, ouais. Et c'était comme ça qu'on faisait toujours les choses. Et c'était terrible. Et quand je dis terrible, je parle de perdre des week-ends entiers de ta vie, mais pas des week-ends ordinaires. Ce sont généralement les longs week-ends de vacances. Donc, un problème commun était la mise à niveau de la chose. Je veux dire, c'était si complexe qu'aucune personne ou Ting vraiment nouveau du tout ou n'était responsable de ça. Ce qui est un peu un problème encore quand vous considérez que l'ensemble a été regroupé et regroupé comme une seule unité. De toute façon. Donc, disons que si nous avions besoin de patch peut être les composants de reporting. Oui. Eh bien, pas de blague. Tout était sur le pont pour ces longs week-ends, vous seriez comme préchauffer les fournisseurs et clients et tous ceux qui utilisaient le système et leur dire qu'il serait à partir de cinq heures le vendredi et pas de secours avant 22h dimanche. Et les patrons ont le numéro de téléphone cellulaire du CIO sur la numérotation rapide et la moitié du département informatique sera au bureau tout le week-end et vivra sur la pizza et le café. Et c'était des choses très précieuses. De toute façon. Les questions qui ont forcé qui étaient droit architectural ? Tout était étroitement couplé. Comme si nous ne pouvions pas simplement supprimer les rapports et corriger ceux qui sont indépendants du reste du système. Maintenant, si nous voulions corriger le système de rapports, nous devions tout arrêter. De toute façon. Regarde, c'est comme ça qu'on utilise la ligne. Et nous avons des mots pour des applications comme ça, non ? On les appelle des monolithes. Et dans l'informatique moderne, c'est comme un mot d'ordre, oui, comme si vous exécutez des monolithes dans votre organisation, vous êtes bien gêné à ce sujet. Tu ne le dis certainement pas aux gens. Oui. Bref, chance. Je plaisante, non ? Et maintenant la plupart d'entre nous ont encore des monolithes et c'est bon, non ? Quoi qu'il en soit, les choses changent et beaucoup différentes ces jours-ci parce que nous avons maintenant des microservices natifs dans le cloud. D' accord, disons ça. Donc, le bit de microservices signifie que nous prenons toute la logique que nous avons dit, oui, était-ce comme le Web frontend et middleware et backend et reporting bits ici. Et nous les codons, et nous les avons expédiés indépendamment. Donc, nous avons la même expérience globale d'application ici ou les mêmes bits, mais le rôle indépendant, comme peut-être il y a une équipe spéciale dédiée qui code et s'occupe du pari web et une autre équipe pour la banque de données et une autre pour la système d'établissement de rapports. Donc, ils sont tous codés et expédiés indépendamment, mais ils parlent les uns aux autres et ils forment un utile. Maintenant, j'ai tracé la ligne autour d'eux en tirets exprès parce qu'ils sont tous lâchement couplés cette fois. Donc, ce que cela signifie, c'est que nous pouvons rév chaque composant indépendamment. Comme ça, un peu a un bug ou une faille de sécurité et non, disons le rapport, mais encore une fois, oui. Eh bien, on peut l'enlever et le mettre à jour sans toucher ni affecter les autres paris. Pourtant, comme nous l'avons dit, tout fonctionne encore ensemble pour créer la même application commerciale utile. Eh bien, c'est le bit des microservices, non ? Beaucoup de petits ou microservices différents qui parlent les uns aux autres et composent une application plus grande. Eh bien, le bit natif du nuage. Cela signifie qu'il est conçu pour les exigences du cloud. Ainsi, il peut évoluer rapidement vers le haut et vers le bas. Et je parle que chaque micro-service ici peut évoluer indépendamment. Eh bien, en plus qu'il peut se saluer et nous pouvons faire mises à jour et des rollbacks de version et tout ce genre de choses ici. Mais je connais beaucoup de mots à la mode et je les expliquerai tous en temps voulu. Alors ne vous laissez pas submerger par les mots à la mode ici. Maintenant, quelque chose d'intéressant qui pourrait ne pas être si intuitif. Cloud natif ne signifie absolument pas qu'il s'exécute uniquement dans le cloud public. Au contraire, en fait, et j'irais même jusqu'à dire qu'une exigence d' une application native cloud est qu'elle fonctionnera n'importe où le soir de votre datacenter sur site. C' est donc des microservices natifs dans le cloud. Oui, on construit à partir de petits composants spécialisés. Nous appelons ces microservices, et ceux-ci se parlent tous sur les API habituellement, et ils forment une application utile ou significative. Et les avantages, chaque pièce individuelle ou micro-service peut être mis à l'échelle indépendamment et mis à jour indépendamment. Et ils peuvent se faire la grêle et courir à peu près n'importe où. De bonnes choses. 3. cluster Kubernetes: Ok, il est temps de se concentrer sur Kubernetes. Maintenant, on va penser à Kubernetes comme deux choses. Un en tant que cluster et deux en tant qu'orchestrateur d'applications. Donc, sur le front du cluster, vous savez quoi, un cluster est. Une grappe, n'est-ce pas ? C'est un tas de machines. Et tant que Linux, vous savez quoi, Kubernetes ne s'en fout pas vraiment. Vous auriez pu les voler. Je veux dire, pas que je me recommande stable, bien sûr, mais juste pour être clair, les communautés ne s'en foutent pas. Il peut s'agir d'instances dans le Cloud, machines virtuelles dans votre centre de données ou vous savez quoi ? Il pourrait même y avoir des métaux interdits dans votre propre datacenter tant qu'ils exécutent Linux, Kubernetes est comme, ouais, peu importe. Maintenant, je dis Linux, mais en fait Windows est une chose avec Kubernetes ces jours-ci. En fait, le support de Windows dans Kubernetes est allé GA, donc généralement disponible et entièrement pris en charge dans Kubernetes est 1.Donc 14 à l'été 2019. Donc oui, de toute façon, verrouiller un cluster Kubernetes est un cluster de nœuds. Et comme pour la plupart des clusters, les mêmes anciennes règles s'appliquent toujours. Donc, nous pouvons voir sur l'image que nous avons divisé le cluster en deux parties. Ici. Sur la gauche, nous avons les nœuds du plan de contrôle, et sur la droite, nous avons les nœuds de travail ou supposons des mots. Ok, donc le plan de contrôle, pensez à ceci comme là où existent les cerveaux de Kubernetes ou les smarts de Kubernetes. Oui. Alors le travail est là. C' est là que nous exécutons nos applications utilisateur et nos chroniqueurs comme la moule en grappe, ouais, que j'y reviendrai dans une minute. Maintenant, quand on dit que l'avion de contrôle et que Kubernetes est intelligent, on parle des choses qui font Kubernetes. Kubernetes. Maintenant, nous allons creuser un peu plus profondément dans une seconde. Mais pour l'instant, nous allons préciser qu'il s'agit d'un type typique de cluster, ce qui signifie que toutes les règles habituelles s'appliquent toujours, comme il n'y a pas de magie cachée, cela signifie que vous n'avez plus à vous soucier de choses comme la performance et la disponibilité . Non, ils s'appliquent toujours. Je veux être clair. Tu es honoré du temps. règles de cluster de production testées au combat s'appliquent toujours. Comme sur la photo, on a trois notes dans l'avion de contrôle. Disponibilité, trois ou cinq est probablement recommandé et un est mieux que d'éviter Split Brains. Oui. Ne laissez pas la techno vous embrouiller. Le point à retenir est que vous devez vous assurer que vos nœuds de cluster sont suffisamment puissants. Et vous devez vous assurer que si l'un d'eux échoue, les choses continuent de fonctionner. De toute façon. C' est les bits du plan de contrôle. Et les nœuds qui composent ce plan de contrôle sont généralement appelés nœuds Master ou parfois Head. Ce n'est que du jargon, sur les ouvriers. Maintenant, la raison pour laquelle je fais référence à ceux-ci comme le muscle de cluster est que c'est là que nous exécutons nos applications utilisateur. Ainsi, à quelle vitesse vos applications s'exécutent et à quel point elles peuvent évoluer. Cela dépend beaucoup de la façon dont nous fournissons ces travailleurs. Donc, en fonction des besoins spécifiques de votre application, certains de ces travailleurs peuvent être de grandes machines et d'autres peuvent être des machines plus petites. Mais rappelez-vous, quand je dis machines, je parle de machines Linux et Windows dans le cloud ou sur prime, et il peut s'agir de machines virtuelles ou de métaux BAM. Maintenant, mentionner Windows me rappelle que les machines Windows ne sont prises en charge que comme nœuds de travail. Donc, les nœuds de plan de contrôle ici, ils doivent toujours être Linux, mais les nœuds de travail ici, ceux-ci peuvent être un mélange de Linux et Windows, ce qui, je pense, est le super haut niveau. Jetons un peu d'un coup d'oeil à H fera maîtres d'abord. 4. Maîtres Kubernetes: D' accord, alors les maîtres. Donc c'est un explosé l'huile comme un zoom en vue d'une note de maître. Donc, en fait, un de ceux-là, oui. D' accord, eh bien, à partir du haut, un rappel sur la terminologie. Nous appelons normalement ces nœuds ceux du maître. Mais tu sais quoi, parfois tu entends d'autres noms comme des notes de tête ou quoi que ce soit. Tout cela signifie la même chose, un nœud de cluster exécutant les bits de plan de contrôle, c'est le cerveau du cluster. Oui. Maintenant, si vous exécutez un cluster hautement disponible avec trois ou cinq maîtres, chacun exécutera le même ensemble de services répliqués. De cette façon, si l'un d'entre eux échoue, les autres gardent le cluster en cours d'exécution. Maintenant, il y a plus de services que ceux-ci, mais pour un coût de 101, ce sont les principaux. Donc, le serveur API s'habitue à celui-ci, n'est-ce pas ? C' est comme la passerelle dans le cluster. Donc, chaque fois que nous voulons interroger le cluster ou faire un changement de configuration ou même déployer une application, puis la mettre à jour et tout ce jazz avec, faites tout cela via le serveur d'API. Donc o envoi de commandes au serveur API. Maintenant, sans être trop profond pour ce cours, à droite, il expose une interface HTTP RESTful et chaque commande qu'il reçoit est authentifié ou autorisé et à peu près des contrôles de santé mentale. Mais en parlant d'émettre des commandes, je dois faire un pas en arrière pendant une seconde. Donc, nous avons dit quand nous émettons des commandes, Kubernetes est-ce qu'ils viennent ici sur le serveur de l'API, n'est-ce pas ? Ok, mais comment on envoie ces commandes ? Eh bien, pour la plupart, droite, certainement au niveau 101, nous utilisons l'outil de ligne de commande Kubernetes appelé Cube CTL. Maintenant, dans la vraie tradition Kubernetes sur votre probablement s'habituer à cela. Il y a un million de façons de le prononcer et vous entendrez tout le monde, comme je dis Cube CTL. Mais beaucoup de gens disent la loi sur le contrôle des cubes, Cube cut Locke, qui être câlins que je ferais, et comment tu le nommes, non ? Tout va. L' important, c' est l'outil de ligne de commande Kubernetes. Donc, ce sont des commandes comme Cube CTL créer ceci et Cube CTL décrivent cela. Et Cube CTL supprimer quelque chose. Et ne prenons pas d'avance sur nous-mêmes, n'est-ce pas ? Va voir tout dans un truc pratique plus tard. Je voulais juste combler une lacune potentielle là-bas, non ? Quoi qu'il en soit, nous disions oui les commandes Cube CTL vont au serveur API et elles sont authentifiées ou autorisées et validées. Donc, à titre d'exemple, à droite, peut-être que nous émettons une commande pour, je ne sais pas, peut-être déployer une application ou mettre à jour une application. Ouais, eh bien, tout ce que la commande dit à Kubernetes de faire est enregistré dans le magasin de cluster comme un enregistrement d'intention. Maintenant, le magasin de cluster est une base de données distribuée qui est généralement basée sur le produit open-source appelé Etsy day. Et c'est le seul composant avec état du plan de contrôle, ce qui signifie qu'il conserve les données de configuration localement sur le disque. Maintenant, une fois que l'intention de la commande est persistée dans le magasin, Kubernetes demande ensuite au planificateur d'affecter le travail. Donc, je pense que par souci de simplicité, nous allons supposer que nous déployons une application web. Oui, et disons qu'on veut cinq instances en cours d'exécution. Eh bien, le travail du planificateur est d'aller trouver le meilleur travail dans les notes pour exécuter ces cinq serveurs Web. Maintenant, ce calendrier est à la recherche de choses comme, eh bien, des nœuds sains est un bon début. Oui, il cherche des nœuds avec les bonnes ressources et assez de ces ressources. Une fois qu'il a trouvé certains nœuds, il émet les tâches de travail à ceux-ci et l'application est déployée. Et c'est génial, non ? Mettez. Et c'est le cube magique qui ne s'arrête pas là. Il implémente ensuite des boucles de contrôle en arrière-plan qui surveillent constamment l'état du cluster. Et ils s'assurent que ce que nous avons demandé est ce que nous avons. Maintenant, nous reviendrons à ça correctement dans une minute, non ? Mais dans cet exemple, je pense que nous avons dit que nous avions demandé cinq serveurs web. Eh bien, Kubernetes a mis en place une boucle de contrôle. Ça fait en sorte qu'on en ait toujours cinq de toute façon, n'est-ce pas ? Je pense que pour nous, c'est l'avion de contrôle. C' est le cerveau de la grappe et vous voudrez qu'elle soit hautement disponible. Nous envoyons nos demandes ou commandes au composant serveur API de celui-ci. Ceux-ci sont enregistrés dans le magasin de cluster est notre état désiré. Donc, ce que nous voulons, le planificateur trouve les nœuds pour exécuter le travail. Et puis en arrière-plan, il y a des boucles regardées pour s'assurer que les choses ne se cassent pas. Et s'ils le font, je devrais dire quand ils le font, Kubernetes le répare. Brillant. Eh bien, ça va faire pour l'avion de contrôle pour l'instant. Passons aux nœuds de travail maintenant. 5. Nodes Kubernetes Node: Ok, donc comme la vue éclatée du maître, c'est un zoom en vue d'un travailleur. Et chaque nœud de travail dans le cluster exécute ces trois mêmes composants principaux. Maintenant, du point de vue de la terminologie, vous pouvez certainement appeler ces travailleurs et les gens savent ce que vous voulez dire. Mais pour la plupart, nous les appelons simplement des nœuds. Donc les maîtres pour le plan de contrôle, ouais, euh, les nœuds pour où nous exécutons nos applications. En fait, parfois nous appelons les cubelets de notes. C' est à quel point ce morceau de cubelets est important ici. Pensez aux cubelets comme l'agent principal de Kubernetes. Tout nœud que vous souhaitez faire partie du cluster doit exécuter un cube. Mais maintenant, je suppose que les cubelets parlent d'abord au plan de contrôle et cela rend le nœud CPU et RAM et les goûts disponibles pour le cluster. Donc ce travail peut être planifié sur le noeud, ouais. Mais il surveille aussi l'avion de contrôle et il lui parle. Ainsi, les cubelets surveillent le plan de contrôle pour les nouvelles tâches de travail qu'il doit exécuter, puis il rend compte de l'état de ce travail. Et il est intéressant, juste, tout ce qui parle au plan de contrôle se fait via le serveur API. Je veux être très clair à ce sujet. Toute communication avec le plan de contrôle passe par le serveur API. C' est comme la gare du Grand Central. Oui. Alors les humains d'Assad parlent par Cube, CTL ou autre. Mais aussi, tous les Kubernetes, morceaux et morceaux, littéralement, tout ce qui parle à n'importe quoi sur le plan de contrôle doit passer via le serveur API. Quoi qu'il en soit, les cubelets, c'est l'agent principal de Kubernetes. Il s'exécute sur chaque nœud qui veut être membre du cluster. S' il s'arrête comme échoue ou quoi que ce soit, oui, il essaiera de se redémarrer. Parfait, continents morts dans l'eau que le nœud tombe hors du cluster et son temps de dépannage. Ok, regardez au milieu du diagramme, nous avons le Container Runtime. Maintenant, les attitudes cubaines sont un orchestrateur d'applications. Oui, il peut orchestrer des choses comme des VM et des charges de travail sans serveur. Mais pour la plupart, au niveau un à un, ok, il orchestre les applications conteneurisées. C' est donc des applications qui s'exécutent en tant que conteneurs comme des conteneurs Docker. Oui. Maintenant, nous regardons un travail et note ici, et nous savons que c'est là que Kubernetes sont des applications. Et nous venons de dire pour la plupart, ces conteneurs de coureurs africains. Il est donc logique que chaque nœud ait besoin d'un logiciel pour exécuter et gérer les conteneurs. Je parle de choses de base comme comment extraire une image de conteneur d' un registre, puis comment démarrer et arrêter et mettre à jour les conteneurs. Eh bien, ce logiciel, c'est le Container Runtime ici. Maintenant, au début de Kubernetes, ce Container Runtime était toujours Docker. Donc, nous dirions comme encore, Kubernetes joue exécuter notre application. Le planificateur trouverait le nœud qui pourrait l'exécuter. Le cube allumé sur ce nœud accepterait le travail , puis il serait choisi Docker comme Container Runtime. Tirez l'image et démarrez le conteneur. Mais c'était alors, et c'est le cas maintenant. Et au lieu que Container Runtime soit toujours Docker, nous avons cette chose appelée Container Runtime Interface ou CRI. Si vous êtes comme des acronymes. Couper directement à la poursuite cependant, c'est une couche de plugin. La lettre dit, hey, peut-être que nous ne voulons pas Docker sur ce nœud, nous pourrions avoir besoin d'un autre Container Runtime. Eh bien, le CI rend cela possible. Donc, il est maintenant vraiment facile de dire, hey, sur ce noeud, nous allons courir peut être g visière et ici peut être coupe, et ici peut être contenue un jour. Maintenant, ouais, écoute, nous sommes un parcours 101, donc je vais garder ça aussi simple que possible dans ce cas, d'accord, entre toutes ces différentes versions de conteneurs comme Katherine, conteneur d, et quel choix plus lourd est une bonne chose. Chaque Container Runtime offre potentiellement différentes caractéristiques de performance, ainsi que différents types d'isolation de charge de travail. Ainsi, par exemple, sur l'isolement de droite, quelque chose comme gee, visière ou cata pourrait offrir un environnement d'exécution plus isolé que quelque chose comme Docker. Donc, si vous exécutez deux charges de travail l'une à côté de l'autre, n'est-ce pas ? Parfois, l'isolement de ces charges de travail est important. On sait quoi ? Autrement dit, tout un sujet qui lui est propre et nous n'y allons pas dans ce cours. Il suffit de dire que le Container Runtime est ici le bit qui tourne les conteneurs et les gère. Eh bien. Dernier mais certainement pas le moindre, le proxy cube. Cela permet de s'assurer que la mise en réseau Kubernetes fonctionne. Maintenant, un peu de pas sur le côté, n'est-ce pas ? Lorsque vous créez un cluster Kubernetes, partie de cette opération consiste à créer un réseau POD. Et tu sais, eh bien, c'est tout simple, non ? Le réseau POD est un grand réseau plat qui couvre tous les nœuds. Donc, comme vous pouvez totalement avoir un cluster où tous les nœuds sont sur différents réseaux dans les Likes. Mais Kubernetes superpose ce grand réseau plat sur tous les nœuds. Maintenant, je dis superposition, non ? Il s'agit généralement d'une superposition de terrain VX, mais il peut aussi s'agir de BGP. Nous savons quoi, ce qui est important, c'est ce réseau POD est ce sur quoi toutes nos applications se trouvent. Et c'est joli, simple et plat, non ? Donc, tous nos composants d'application sont assis dessus et peuvent parler entre eux. Brillant. Quoi qu'il en soit, regarde dans les coulisses, non ? Q proxy effectue ici toute la magie pour faire en sorte que ce réseau POD se produise. Des choses comme les tables IP et les règles IPBES si vous êtes intéressé. Mais ce sont des nœuds. Maintenant, nous sommes sur le point de passer à Kubernetes en tant qu'orchestrateur. D' accord. Mais très vite, avant qu'ils ne le fassent, je veux juste jeter un coup d'oeil à quelque chose qui est vraiment populaire de nos jours. Kubernetes hébergé. 6. K8s hébergés: Donc nous avons cette image, ouais, notre cluster Kubernetes et il est tranché ici comme un plan de contrôle et une sorte de plan de données comme les cerveaux Kubernetes vivent dans ce bit et ensuite les applications un ici seulement. Tu sais ce que c'est des glacières ? Kubernetes Tech est un je l'adore, non ? Je suis réaliste et je sais que la technologie n' existe vraiment que pour gérer des applications et construire des entreprises, et bien sûr, des soins de santé et des affaires humanitaires. Oui. Mais ce que je veux dire, c'est que personne ne déploie Kubernetes juste pour qu'ils puissent dire, hey, on a Kubernetes est au moins un espoir que personne ne le fait. Vous dites que vous le déployez pour que vos applications puissent s'exécuter à grande échelle et la mise à jour de Healon et tout ça, n'est-ce pas ? Donc, tout est au sujet de l'application. Mais dans ce monde de mise au point d'application, nous ne nous soucions vraiment que de ces bits ici. Je veux dire, tous les trucs de l'avion de contrôle aussi cool qu'il est, non ? Juste une sorte d'entrave, comme juste passer du temps et des efforts à planifier et mettre en œuvre toutes les choses de haute disponibilité et peut-être certains des trucs de performance. Oui. Je veux dire, tout ce que ça fait c'est nous distraire de construire des applications, ce qui est exactement là où Kubernetes hébergé entre en jeu. Donc, un service Kubernetes hébergé prend les bits de plan de contrôle ici, séparés, dessine une sorte de ligne de démarcation et dit, je vais vous dire quoi. Nous gérerons tous ces trucs d'avion de contrôle pour vous. Et nous allons juste exposer les morceaux de travailleurs. Donc, à un niveau élevé sans entrer dans les détails, vous n'avez pas à donner une seule pensée au plan de contrôle. Tout est géré pour vous. Ainsi, les mises à niveau, la disponibilité, les performances , tout cela, le tout pris en charge par votre fournisseur de cloud. Parlant de ce que tous les principaux fournisseurs ont un service Kubernetes hébergé. Les vrais grands ou Amazon IQ AS Elastic Kubernetes service, Azure Kubernetes service, alias S et G k0, le moteur Google Kubernetes. Mais aussi, océan numérique, IBM Cloud, ces gars les ont tous aussi. Maintenant, je dois dire que c'est le nuage. Les coûts s'appliquent donc. Rien n'est gratuit, non ? Et aussi bien que les avantages sont, comme vous pouvez faire tourner un cluster Kubernetes géré en temps et vous n'avez pas tous les soucis du plan de contrôle. Oui. Eh bien, de l'autre côté, tu abandonnes pour contrôler. Ainsi, par exemple, vous êtes limité aux versions de Kubernetes est pris en charge par un fournisseur de cloud. Et disons que si vous avez besoin de définir des paramètres funky sur le plan de contrôle, vous êtes probablement hors de verrouillage. Donc c'est génial, non ? Mettez-le à l'épée à deux tranchants. La simplicité vient au prix de la configurabilité. Maintenant, et c'est dur de ne pas entrer dans les détails parce que je veux te dire que tu sembles beaucoup, mais je ne veux pas submerger tu veux 101 cours. Quoi qu'il en soit, vous pourriez poser la question, surtout si vous êtes un développeur. Pourquoi dois-je même me soucier des paris de noeud de travailleur ? Pourquoi je ne peux pas simplement donner ma candidature à Kubernetes ? Et que Kubernetes s'occupe de tout pour moi. Et c'est une excellente question. Et le, quelque chose appelé les cubelets virtuels qui va dans cette direction. Donc, pas de vrais nœuds dans votre cluster, comme des trucs vraiment cool et un jour potentiellement, aucun Kubernetes ne l'est. Mais je pense que pour nous, c'est potentiellement vraiment des trucs qui soufflent. Si vous êtes intéressé. Google cubelets virtuels. Bullock, je gaufre. Kubernetes est un cluster de machines, principalement Linux, et elles peuvent fonctionner n'importe où. Ces machines individuelles fonctionnent comme un maître ou des ouvriers mise en œuvre de toute l'habileté Kubernetes et ont besoin d'être hautement disponible et tout le coût habituel à la bonté. Mais nous n'exécutons pas nos applications là sur les nœuds de travail du maître. C' est là que nous exécutons nos applications. Les services Kubernetes bien hébergés existent sur la plupart des plateformes cloud et ils nous cachent principalement le plan de contrôle. Bien que d'autres options hébergées existent. Droit ? De la magie. Voyons maintenant comment Kubernetes est un orchestrateur d'applications. 7. Kubernetes en tant que orchestrateur: Ok, Kubernetes en tant qu'orchestrateur d'applications. Donc d'abord, orchestrateur, ce mot supposé, alors qu'est-ce que ça veut dire ? Ok, supporte avec moi là-dessus pendant une minute. C' est un peu froissé, mais je pense que ça fait ressortir le point. Voici donc un orchestre symphonique, vous savez, un tas d'instruments différents qui se rassemblent et font, espérons-le, une musique étonnante. Seulement en ce moment, ils sont partout et ils n'ont pas de musique à jouer. Donc oui, peut-être Cool, ne pas utiliser beaucoup. Eh bien, amenons le chef d'orchestre. Elle entre donc, met chaque instrument à sa place, distribue la musique et, d'une manière générale, organise tout. Comme quand le début, quand jouer votre rôle particulier est allé un speedo, est allé à voix haute ou calme tout ce jazz, ouais, jazz. Oh chéri. Pas de jeu de mots prévu là-bas. De toute façon. Avec seulement quelques choses, le chef d' orchestre et de la musique comme la partition. Eh bien, nous sommes passés du Chaos à tout le monde jouant leur rôle et potentiellement créant un morceau de musique émouvant. Et ce n'est pas trop difficile de faire le saut vers Kubernetes, où nous avons un tas de services d'application différents ici, tout simplement se détendre, à Medellin et vraiment ne pas avoir une idée de ce qu'il faut faire ou quand exécuter et où s'exécuter. Donc peut-être le moteur X dans le rayon et quelques OAuth et quelques bits personnalisés ici, tout le code légal et les microservices, non ? Mais aucune idée comment ils se réunissent tous et ce que leurs partis particuliers. Donc, nous jetons Kubernetes est dans le mélange, comme la conduite de l'air. Et puis quelques configurations d'application, pensez à la partition. Et soudain, nous avons ce bon travail qui fait quelque chose, j'espère quelque chose d'utile. Maintenant, dans le cas de l'orchestre, il fallait que les dirigées viennent et les organisent, leur dire où le dire, qui suivre est venu dans la façon de jouer toute cette année-là. Et c'est la même chose dans Kubernetes avec notre application. Donc Kubernetes est par exemple, planifié chaque composant. Donc comme leur dit sur quels nœuds exécuter, quels réseaux attacher aux ports pour exposer toute cette bonté. Et dans l'exemple de l'orchestre, tout le monde avait besoin d'une copie de la musique. Eh bien, dans l'application ici, chaque pièce a besoin de sa propre configuration. Donc ce qu'il est censé faire, et cela peut être des choses comme servir des pages Web, faire l'authentification, peut-être faire des recherches sur la base de données. Oui. Ce que de leur propre chef, ces emplois individuels pourraient ne pas sembler beaucoup. Mais quand ils sont tous en cours d'exécution ensemble, nous aurions une application utile. Bien. Oui, j'espère parce que c'était vraiment fromagant. Mais tu sais quoi ? Quand j'ai fait ça, je vis dans des ateliers et j'aime, tout le monde m'a toujours dit que c'était bon. Donc j'espère que cela vous a été utile. De toute façon. Ensuite, nous allons jeter un oeil à l'obtention du code de ordinateur portable d'un développeur à l'exécution sur Kubernetes. 8. Flux de travail de développement: Ok, donc un flux de travail d'application. Donc, ce processus d'obtention du code à partir de l'ordinateur portable d'un développeur jusqu'à l'exécution sur un système en direct. Eh bien, ça ressemble à ça. Vous écrivez du code au dos d'une exigence ou d'une idée. Oui. Maintenant, Kubernetes ne se soucie pas de la façon dont vous écrivez votre code ou des langues dans lesquelles il est. Tant qu'il a été exécuté sous Linux ou Windows, nous devrions être bons. Eh bien, une fois que le code est fait, nous l'empaquetons comme une image de conteneur post-doc dans un registre, et ensuite nous sommes prêts à l'exécuter, c' est pourquoi Kubernetes entre en jeu. Maintenant, verrouiller comme un chemin plus simplifié. Alors ajoutons un peu de détails. Comme nous l'avons dit, vous écrivez votre code dans toutes les langues que vous vouliez, cela ne change pas. Mais puis ce peu ici, l'emballage comme une image de conteneur. Ouais, ça pourrait être nouveau pour toi. Donc, un flux de travail typique serait un développeur avec le bureau Docker sur leur ordinateur portable Mac ou Windows. Ils écrivent ce code qu'ils utilisent les outils Docker pour le construire dans une image, ce qui peut sembler fantaisie, mais il est à peu près juste de mettre votre code d'application plus toutes les dépendances dans un dossier sur votre ordinateur portable, exécutez une commande de construction d'image docker contre cela. Felder et Docker font le travail acharné de construire une image. Quand la construction est terminée, vous avez cette chose qu'on appelle une image, non ? Comme nous avons laissé entendre que la magie de l'image est qu'elle contient tout ce dont votre application a besoin. Donc ton code d'opération, bien sûr, oui. Mettez son puits, il a toutes les dépendances comme les bibliothèques et les constructions de système de fichiers OS. Ce qui signifie que tout ce dont votre application a besoin pour s'exécuter est à l'intérieur de cette image. Ce qui signifie encore une fois, vous pouvez à peu près l'exécuter n'importe où et cela fonctionnera juste. Vous écrivez donc votre code, utilisez les outils Docker pour l'empaqueter en tant qu'image, puis utilisez Docker image push pour l'enregistrer dans un registre quelque part. Maintenant, un registre est juste un endroit pour stocker vos images de conteneur et regarder. Vous pouvez vous exécuter sur Prem ou dans votre propre cloud privé virtuel, ou vous pouvez utiliser un registre basé sur Internet comme Docker Hub. Le point à emporter cependant, une fois vos images sur un registre, il est prêt à être tiré et exécuté en production. Maintenant. La production, oui, bien sûr, c'est ça. Donc, dans ce processus, nous manquons un nombre ridicule d'étapes. Dites oui, comme toutes les choses que nous faisons dans le monde réel avec une intégration continue ou un pipeline de livraison continue. Donc, ce sont des choses comme les builds automatisés, les tests , les analyses de vulnérabilité, tout ça, bonté , oui, nous l'ignorons juste pour garder l'exemple simple. Mais oui, supposons que tous ces trucs ne sont pas tous les builds, tests et analyses que votre image va dans un référentiel de production et votre registre, et vous êtes prêt à déployer, ce qui est là où Kubernetes intervient. Donc, à ce stade, votre flux de travail de développement est terminé et c'est là que les bits d'opérations prennent le contrôle. Maintenant regardez, il y a beaucoup à Kubernetes et il n'y a pas de s'éloigner du fait que c'est une courbe d'apprentissage assez raide. Mais je veux prendre une seconde juste pour vous donner un avant-goût de certaines des choses que Kubernetes propose pour vous aider à exécuter vos applications. Dans l'image ici, nous regardons trois ressources Kubernetes à Daymond set, au déploiement, et un ensemble d'état. Je ne veux pas que vous vous concentriez sur les détails ici. Prends juste la grande photo. D' accord ? Donc, un jeu de démons fait en sorte qu'une instance d'un microservice particulier est toujours en cours d'exécution sur chaque nœud du cluster sont un exemple vraiment commun serait comme des services de journalisation ou de surveillance. Ouais, vous en avez besoin pour fonctionner sur tous les nœuds. Eh bien, devine quoi ? Utilisez un jeu de démons pour accomplir cela. Donc vous auriez votre service de journalisation ou de surveillance, n'est-ce pas ? Tu l'envelopperais dans un ensemble Kubernetes Damon. Donne-le à Kubernetes pour le déployer. Et Kubernetes s'assurera qu'une instance de celui-ci s'exécute sur chaque nœud du cluster. Brillant. Mais si vous ajoutez plus de nœuds à l'avenir, pas de soucis. Kubernetes voit cela et s'assure que les nouveaux nœuds obtiennent une instance. De bonnes choses. Eh bien, un déploiement est différent. Il s'agit d'être capable de mettre à l'échelle, auto-grêle et d'effectuer des mises à jour roulantes. Et on les dira plus tard dans la section pratique. Donc je vais juste garer les déploiements pour l'instant, n'est-ce pas ? Puis le dernier que nous montrons et rappelons qu'il y a beaucoup plus. D'accord ? Les ensembles d'état de Put concernent le déploiement et la gestion des parties avec état de nos applications. Donc, ceux-ci nous donnent des choses comme des noms de pod fiables et des startups ordonnées et les goûts. Oui. Mais regardez où haut niveau ou ne voulez pas se perdre dans les détails en pointant juste, Kubernetes offre de nombreuses façons de déployer et de gérer les différents bits de nos applications. Cool, nous allons regarder en résumé, nous avons trois parties principales pour le flux de travail. Vous codez votre application. Vous utilisez Docker pour tout empaqueter en tant qu'image de conteneur et la pousser dans un registre. Ensuite, vous utilisez Kubernetes pour le déployer et le gérer. Simple. Eh bien, l'un était qu'ils étaient la leçon et ensuite nous allons entrer dans les exemples. 9. État désiré: Dès lors, une chose que nous devons absolument savoir est que l'unité atomique de déploiement ou de mise à l'échelle et Kubernetes est quelque chose qu'on appelle un pod. Et les mots de passe peuvent écrire unité atomique de planification. Oui, c'est ça ? Eh bien sur l'écran ici, nous pouvons dire que VMware complet, l'unité atomique de planification, est la machine virtuelle pour Docker, c'est un conteneur et pour Kubernetes visite le pod. Brillant. Eh bien, cela signifie que si nous déployons une application sur VMware vSphere, nous l'indiquons comme des machines virtuelles. Si nous déployons une application sur Docker, nous l'indiquons comme des conteneurs sur devinez quoi ? Si nous avons déployé les communautés ? Nous le tamponnons comme des gousses. Maintenant, en le butant. Oui. Ce que je dis, c'est que toutes les différentes parties de nos applications sur Kubernetes fonctionneront en tant que pods. Donc, je ne sais pas si nous avons comme un front-end web à notre application. Oui, on doit l'agrandir. Nous l'mettons à l'échelle en ajoutant plus de pièces ou si nous réduisons, nous enlevons des pièces. Brillant. Maintenant, oui, Kubernetes est un orchestre d'applications conteneurisées. Je veux dire, il peut aussi orchestrer des machines virtuelles et des charges de travail sans serveur. Mais pour la plupart, Kubernetes orchestre les applications conteneurisées. Ainsi, les applications des nœuds sont des conteneurs. Seulement. Vous ne pouvez pas réellement déployer un conteneur directement sur Kubernetes. Sérieusement, pour que les conteneurs fonctionnent sur Kubernetes, il doit être enveloppé dans une capsule, oui. Et pour le système d'exploitation intensif maintenant dans son 101 cours, il suffit de penser à un pot est un emballage léger autour du récipient. Tout ce qu'il fait est de laisser qui contiennent une course sur Kubernetes. Et maintenant, nous allons les voir plus tard dans un peu de main et tout deviendra clair alors. Mais j'ai une dernière meilleure théorie. Déploiements déclaratifs, état indésirable par rapport à l'état réel ou bouche correcte. Kubernetes nous aime à y décrire les choses de manière déclarative. Bingo Buzzword, c'est ça ? J' adorerais ces mots à la mode. Oui. Eh bien, à l'écran, nous avons des exigences. C' est ce que nous voulons. Donc dix copies d'un service basé sur n'importe quelle image exposée sur le port 8080 avec une étiquette particulière. C' est ce qu'on veut. Et le terme technique pour cela est l'état souhaité. Eh bien, nous écrivons ça dans un fichier de configuration et nous le donnons à Kubernetes, dix répliques de n'importe quel conteneur sur ce port avec cette étiquette, oui. Et on dit en gros, Kubernetes, allez et faites que ça arrive des pièces. Et c'est tout en ce moment. Ça peut sembler être rien d'autre que d'y penser. Comparez cela à l'effort et à la douleur d'écrire un script humongue avec toutes les commandes et toute la logique pour aimer, eh bien, décider lequel des nœuds à un des dix répliques sur pour commencer, plus toutes les commandes et la logique à tirer les images, toutes les commandes et la logique pour démarrer les conteneurs joints aux réseaux exposent les ports, sont les étiquettes, tous ces trucs, non ? Eh bien, ce modèle déclaratif n'a rien de tout ça. Vous écrivez ce que vous voulez, donnez-le à Kubernetes. Laissez Kubernetes s'occuper des choses difficiles. Oui. Et c'est vraiment génial, non ? Mais tu sais quoi ? Ce n'est que la moitié de l'histoire. Parce que vous voyez, parce que nous déclarons ce que nous voulons aux communautés au lieu de simplement dire, hey, exécutez cette longue liste de commandes. Eh bien, parce que nous lui disons ce que nous voulons, Kubernetes enregistre cet état désiré comme un enregistrement d'intention dans le magasin de cluster, puis ça le fait arriver. Mais après ça, ça tourne. Regardez les boucles qui surveillent le cluster et assurez-vous constamment que ce qui est en cours d'exécution sur le cluster correspond à ce que nous voulons. Maintenant, si c'est le cas, donc si l'état réel correspond à l'état désiré, Brillant, non ? Si ce n'est pas le cas, peut-être qu'on n'a que huit répliques au lieu de dix. Est-ce que Kubernetes fait tout ce qu'il peut pour réparer cette magie ? Eh bien, regarde juste dans les gâteaux dehors snooty, non ? Disons qu'un nœud a échoué et que nous perdons deux réplicas avec lui. Et qu'est-ce qui diable, non ? Ça arrive à trois heures du matin. Kubernetes sait qu'il nous faut dix répliques. On en a perdu trois et il est descendu à sept. Donc ça tourne trois de plus et on est de retour à dix. L' état réel correspond au problème d'état souhaité résolu, non ? Et pas d'appel au milieu de la nuit. Lavett ? Eh bien, ce modèle fait absolument partie intégrante de la façon dont Kubernetes fonctionne et est l'une des choses qui le rend si grand. Et ceci ici, c'est à quoi ça ressemble en fait. Maintenant, si vous n'avez pas vu un fichier YAML comme celui-ci avant et qu'il semble un peu effrayant, une promesse vous, ce n'est pas correct. Comme si vous n'écrivez jamais ces fichiers à partir de zéro. En fait, tu sais, je prends toujours un vieux et je le modifie. Oui. Mais le fait est qu'une fois que vous en avez vu quelques-uns, ils commencent à paraître beaucoup plus simples. Quoi qu'il en soit, écoutez, nous disons dix réplicas, donc dix pods, Ouais, exécutant cette image particulière et écoutant sur ce port ASI, post-doc au serveur API, en supposant qu'il passe toute l'authentification et l'autorisation obtient enregistré dans le magasin de cluster comme l'état souhaité et est déployé sur le cluster. Fabuleux. Mais alors, comme nous l'avons dit, ces boucles de réconciliation sont en arrière-plan et ils regardent toujours la grappe toute la journée, toute la nuit, mais probablement avec un café pour le garder éveillé ou quoi que ce soit. Mettez-le constamment en regardant le cluster. Et chaque fois que l'état observé varie de l'état désiré, Kubernetes essaie de le réparer. Brillante promesse, non ? Vous allez adorer. Et quelque chose d'autre que tu aimes. On en a fini avec la théorie. Il est temps de regarder quelques exemples. 10. Obtenir de Kubernetes: Ok, donc si vous voulez suivre, vous aurez besoin d'un cluster Kubernetes et des exemples d'application et de fichiers de laboratoire. Ce que nous allons faire, c'est vous montrer des moyens très faciles pour obtenir Kubernetes. Ensuite, nous allons vous montrer comment obtenir les fichiers du labo. Donc, sur le front Kubernetes va regarder Docker bureau, jouer avec Kubernetes et le moteur Google Kubernetes. Maintenant, bien sûr, d'autres options existent, et je suppose que si vous avez déjà un cluster, peut-être que vous pouvez simplement l'utiliser cependant. Assurez-vous qu'il ne s'agit pas de votre cluster de production. Quoi qu'il en soit, cherchez le bureau Docker. Vous venez juste sur le site Docker. Ou encore mieux, vous pouvez simplement Google Docker bureau. Mais de toute façon, tu finiras quelque part comme ça. Et puis vous venez de télécharger la version pour vous. Maintenant, je suis sur un Mac en ce moment. Alors je vais les sauter Swan. Et puis quand cela est téléchargé, il est vraiment juste un peu de clicky cliquez sur Suivant, Suivant, Suivant. Honnêtement, ça ne pouvait pas être plus facile. Quoi qu'il en soit, quand vous ne le faites pas, vous aurez cette baleine ou cette poire ou elle sera dans le coin droit si vous êtes sous Windows. Mais en cliquant dessus vous obtenez cette interface utilisateur fantaisie où vous venez et activez Kubernetes. Maintenant, ça peut prendre une minute ou deux pour commencer, mais quand c'est fait, bingo, vous êtes en affaires et vous êtes prêt à aller chercher les dossiers du labo et à se fissurer avec le cours. Maintenant, Docker Desktop est juste à des fins de développement et de test et vous obtenez seulement un cluster de noeud unique C ici une seule note agissant en tant que maître et travailleur. Maintenant, ce n'est évidemment pas ce que vous voulez pour la production, mais c'est certainement assez bon avec le développement. Ok, alors joue avec Kubernetes. Encore une fois, juste arrimer dans Google et suivez le lien. Il veut que vous vous connectiez avec, soit GetHub sur Docker Hub, puis vous suivez simplement les instructions à l'écran et vous construisez un cluster. Jouer avec Kubernetes est gratuit et c'est génial. Honnêtement, j'adore ça. Mais parfois, il n'est pas super réactif ou ne peut pas devenir assez frustrant. Mais rappelez-vous, c'est gratuit et les gars derrière ça font vraiment était un service juste en dehors que oh, vous savez quoi aussi bien. Si vous recherchez ici, il s'agit d'un compte à rebours jusqu'à ce que votre cluster soit supprimé. Encore une fois, comme Docker Desktop, c'est juste une aire de jeux. Et bien sûr, celui-ci a parfois des problèmes de performance. Mais le fait est que c'est limité dans le temps. Donc, quand pas le compteur frappe 0, il est né comme pas choisi à votre cluster et tout ce qui s'exécute dessus. Mais une fois que vous groupez le bateau, honnêtement, ce sont les fichiers de labo et vous êtes prêt à partir. Ok, dernier mais pas le moindre, pour obtenir un cluster et rappelez-vous, d'autres options existent. Mais le moteur Google Kubernetes est une option solide pour Kubernetes hébergé dans le cloud. Et je vais en fait faire beaucoup de démos dans le cours dessus. De toute façon. Écoute, c'est un service cloud, donc ça coûte de l'argent. Ne pas, en aucun cas, faire tourner un cluster pour ce cours, puis l'oublier. Parce que si tu le fais, tu auras un Bill de bienvenue. Quoi qu'il en soit, tant que vous avez un compte Google Cloud avec la facturation activée, il est juste cloud dot google.com se connecter à la console ici, moteur Kubernetes, puis passer par les mouvements de création d'un cluster. Appelez ça ce que vous voulez, décidez où vous le voulez. J' ai tendance à aller chercher ce qui est le plus léger quand je fais un labo. Et puis sous le pool de nœuds ici, c'est à vous de décider. Mais je recommande normalement trois nœuds et une façon qui va. Maintenant, ça va prendre une minute ou quoi que ce soit à construire. Mais quand ce sera fait, je vous paierai de copier cette seule commande G-Cloud. Et tant que vous avez le SDK Google installé avec G Cloud, alors donnez-lui un Rhône rapide. Et un Cube CTL obtenir des nœuds, vous montre en cours d'exécution et prêt à se fissurer. Encore une fois, à ce stade, vous avez un cluster Kubernetes. Et une fois que vous avez les dossiers du labo, vous êtes prêt à faire du rock and roll. Mais comme je l'ai déjà dit, s'il vous plaît, quoi que vous fassiez, n' oubliez pas de supprimer le cluster quand vous avez fini. Ok, donc nous avons un exemple d'application sur certains fichiers de configuration sur GitHub. Et en passant, ne vous inquiétez pas si vous ne savez pas vraiment ce qu'est GetHub, vous n'avez pas besoin de simplement pointer les cheveux de votre navigateur. Si vous êtes intéressé. L' application se trouve dans ce dossier. Et puis ce sont les fichiers de configuration ici à la racine du repo. Mais tout ce dont vous avez réellement besoin est ce lien ici, appuyez sur le bouton Presse-papiers, puis dans une fenêtre de terminal tapez git clone et collez-le dans le lien. Et c'est tout. Ou en fait non, tu sais quoi, tu as un nouveau dossier. Froid. Kubernetes est 101 parts de compétences ou Scotia pour l'abrégé. O de toute façon, allez là-dedans. Et c'est l'application dans les fichiers de configuration. Alors regardez, avec un cluster dans les dossiers du labo, vous êtes prêt à partir, oh, je suis terrible à ça. Et assurez-vous que toutes les commandes que vous exécutez plus tard dans le cours dans l'un des scénarios de laboratoire, ok ? Exécutez-les à partir de ce dossier car vous avez besoin d'accéder au fichier, dites oui, eh bien, c'est tout. Allez. Allons craquer. 11. Déployer un Pod: Ok, donc on va se calmer doucement. Nous avons déjà dit que l'unité atomique de déploiement sur Kubernetes est le pod. Et qu'un pod est juste un wrapper autour d'un conteneur qui le laisse fonctionner sur Kubernetes. Donc plus de photos. Je croyais qu'on avait fini avec les diapositives sérieusement, non ? Si tu crois que tu en as marre, c'est le fléau de ma vie. Donc celui-ci sera très rapide. Nous commençons avec du code, nous le construisons comme un conteneur, enveloppons dans un pod. Charmant. Donc c'est ce que ça ressemble à obtenir. Maintenant, nous parlons, c'est un fichier Kubernetes is YAML. Parfois, nous l'appelons un fichier manifeste, mais celui-ci décrit un pod. Donc, à partir du bas, c'est ce que nous appelons la spécification du conteneur. Donc c'est le conteneur, la capsule va fonctionner. Et puis les choses ici, c'est l'emballage POD, Eh bien, le conteneur, mais c'est assez simple. Si vous avez fait un Docker, vous lui donnez un nom aussi arbitraire, n'est-ce pas ? Appelez ça ce que vous voulez. C' est l'image sur laquelle il est basé. Donc, c'est ce qui contient tout votre code d'application et ses dépendances, Ouais, et l'exposer sur le port 8080, mort facile. Les applications ici l'exécutent comme un conteneur, y accéder sur ce port et lui donner ce nom convivial, boom, qui est conteneur u. Mais pour l'exécuter sur Kubernetes, il a besoin de tout ça ici. Oui, l'emballage de la capsule par défaut d'un meilleur terme. Maintenant, je pense que nous allons traverser celui-ci, d'accord, parce que c'est similaire sur tous les objets Kubernetes. Nous commençons toujours avec la version de l'API et genre que vous pouvez les avoir dans l'un ou l'autre ordre, n'est-ce pas ? Mais la version de l'API v1 et type pod, vous savez quoi ? Ce n'est pas la science de la fusée, nous disons à Kubernetes est facturé comme un pod et le construire sur ce qui est essentiellement une version un du schéma de pod. S' il y a un peu comme un schéma v2, nous nous attendrions à ce qu'il ait encore quelques cloches et sifflets, comme c'est la norme avec les versions ultérieures des choses. Mais oui, donnez-nous un pod basé sur V1 du schéma de pod ou de la spécification de pod. Puis les métadonnées ici, nous lui donnons un nom et nous l'utiliserons dans une minute. Puis on lui a donné quelques étiquettes. Maintenant va voir la puissance des étiquettes un peu plus tard. Mais pour l'instant, laissez-moi vous dire qu'ils sont outrageusement puissants. Mais c'est tout, non ? C' est notre état désiré sur lequel on s'est tapé plus tôt. Donc, au lieu d'écrire un homme qui inscrit avec des tonnes de commandes pour faire choses comme tirer l'image du conteneur dans les commandes pour démarrer le conteneur, ce qui sera en passant différent si vous utilisez des runtimes de conteneur différents, oui. Mais vous aurez également besoin de commandes pour l'attacher à un réseau exposant sur 8080. Toute cette complexité air, eh bien, non merci. On ne veut rien de tout ça. Au lieu de cela, nous allons juste mettre ce que nous voulons dans un fichier ici, envoyer à Kubernetes et laisser Kubernetes comprendre comment le faire. En parlant de ça, envoyons ça à Kubernetes. Maintenant, j'ai une copie du fichier ici dans mon répertoire de travail. Si vous suivez, soit clonez le repo GitHub avec cette commande ici, soit copiez le texte et placez-le dans un fichier de votre répertoire de travail appelé Pod dot yaml. Et puis regardez le nom du fichier est arbitraire, mais je vais juste vous montrer des exemples avec celui-ci appelé Pod dot yaml. Donc Cube CTL appliquer le fichier Pod dot yaml, Et c'est tout. Maintenant, dans les coulisses, Cube CTL a un fichier de configuration. Il se trouve dans un répertoire caché dans votre profil appelé cube. Et puis là, il y a un fichier de configuration, commodément appelé config. Alors qu'il y a des choses comme les clusters, l' API, le point de terminaison et les informations d'identification et d'autres choses. Pour que Cube CTL sache où envoyer la commande et il peut faire l'authentification. Ouais, eh bien, si on obtient des pods Cube CTL, il y a 101 pod et ça marche. Ainsi, le serveur API a accepté notre YAML comme un nouveau magasin d'état souhaité, la copie et le magasin de cluster, et le planificateur a trouvé un nœud sain pour exécuter le Piton. Brillant. Maintenant, nous pouvons exécuter un Cube CTL, obtenir des pods avec le soin de la mouche large pour voir quel noeud il est en cours d'exécution. Et un Cube CTL décrit pods 101 pod. Et cela nous donnera une vue plus détaillée qui est vraiment bien formatée. Maintenant, ces deux commandes, Cube CTL get et Cube CTL décrivent. Ce seront tes meilleurs amis, comme tu l'étais, littéralement compter sur eux tout le temps. Maintenant, une question que l'on me pose tout le temps dans les ateliers dans les goûts est, comment écrire ces fichiers YAML et là comme un nombre ridicule de champs et d'options. Eh bien, au premier sur comment les écrire ? La réponse est assez simple. Pour la plupart. Vous prenez juste un vieux, peut-être même sur le web ou quelque part et vous le modifiez comme même ce super simple pod yaml que nous venons de faire. Je n'ai pas tapé ça à partir de zéro. Donc oui, normalement, vous allez copier un ancien et le modifier. Maintenant, la question de savoir tous les champs possibles et les options et autres choses. Tu sais quoi, cette réponse simple et morte à ça aussi. Oui, la plupart des objets ont une liste d'options redoutable que vous pouvez mettre dans l'AML, mais vous n'avez pas besoin de les mettre dans. Tu viens de mettre ceux dont tu as besoin. Ensuite, ceux que vous avez omis, Kubernetes est les développe avec des valeurs par défaut. Donc, vous savez quoi, si nous exécutons un autre Cube CTL obtenir des pods ici, mais nous passons cette option ici de large à YAML. Vérifie ça. C' est le YAML entièrement développé à partir du magasin de cluster. Et je veux dire, c'est beaucoup plus long que les dix ou 15 lignes ou tout ce que nous avons envoyé au serveur API. Il y a donc des annotations et un espace de noms sous la spécification du conteneur. Il y a bien, il y a un ton, non ? Donc oui, Kubernetes remplit tous les blancs où nous ne définissons pas explicitement de valeurs. Maintenant, haha, ouais, aussi bien que, un peu plus bas, il y a toute cette section de statut ici que nous ne spécifions jamais nos animaux. Mais j'adore ça, non ? Parce que c'est un excellent moyen de renforcer cet état désiré par rapport à l'état observé sur lequel nous avons craqué plus tôt. Donc, la section spec est fondamentalement notre état désiré. Ce qu'on a demandé à Kubernetes est quatre. L' état est bloqué ici cependant, cela représente l'état actuel observé du cluster ou l'état observé au moment où nous exécutons la commande, Yeah. Eh bien, nous avons un conteneur ici basé sur notre image. C' est ce qu'on appelle ça. Il est prêt à courir. C' est son Ip, littéralement une tonne de trucs. Et oui, c'est une capsule. Nous l'avons décrit de manière déclarative dans un simple fichier YAML. Il avait une spécification de conteneur et nous l'avons enveloppé comme un pod. Ensuite, nous avons utilisé Cube CTL pour envoyer ce YAML au serveur API costas. Nous avons évidemment été authentifiés en fonction de ce qui se trouve dans le fichier de configuration du cube. Le YAML a été développé avec toutes les valeurs par défaut et les choses que nous n'avons pas spécifiées. Et il a été stocké dans un magasin de cluster. Ensuite, le pod défini dans celui-ci a été planifié sur le cluster et il est en cours d'exécution. Merveilleux. Eh bien, dans la prochaine leçon, nous verrons comment nous y connecter. 12. Se connecter via un service: Donc, nous avons un pod en cours d'exécution, et à l'intérieur il y a un conteneur en cours d'exécution, une simple application web, mais nous ne nous connectons jamais directement à ce pod. Donc, nous ne prenons jamais son IP ou quoi que ce soit et ouvrons une socket à elle. Maintenant, il y a un tas de raisons à ça et nous en couvrirons quelques-unes sous peu. Ce que nous devons savoir maintenant, c' est que pour accéder aux applications dans un pod, nous avons besoin d'un autre objet Kubernetes est appelé un service. Et ce mort simple, non ? Pensez à un service comme bourdonnement d'un front-end et d'un back-end. Sur le front-end, chaque service obtient un nom, une adresse IP et un port. Et Kubernetes donne une garantie en fonte que ces valeurs ne changeront jamais. Ensuite, sur le backend, ils ont un port et le sélecteur d'étiquettes. Le trafic arrive sur le front-end. Mon service sur le port 30,001 ou quoi que ce soit. Et il est expulsé du backend sur le port 8080 dans cet exemple, et la charge est équilibrée sur tous les pods du cluster avec l'application, une étiquette Web ne peut pas être ESEA. Donc, l'exemple que nous allons ouvrir a eu comme, je ne sais pas, dix parties peuvent l'être, mais le service envoie seulement du trafic à ceux avec l'application est égal à la magie de l'étiquette Web. Eh bien, voici un service Yaml. Nous commençons avec la version de l'API et gentil à nouveau, donc c'est dire, Hey, Kubernetes, Donnez-moi un service, s'il vous plaît, et basez-le sur la définition V1 d'un service. Oui. Mais alors la configuration front-end tout d'abord, nous allons lui donner un nom. Maintenant, cela est enregistré avec le service DNS interne Kubernetes. Cela signifie que le nom de service va être résolu à partir du cluster est SVCs A101. Celui-ci écoute sur deux ports. C' est toujours le front-end, tu te souviens ? Donc, cela diminue à l'intérieur du cluster sur le port 8080 ici et à l'extérieur du cluster. Donc, pour les connexions provenant de sources externes sur le port 30,001. Ainsi, les applications du cluster peuvent atteindre S-phase A101 sur le port 8080 ici et atteindre l'extrémité frontale du service. Aussi. Mais... Ce port de nœud dit ici d'écouter également sur le port 30,001 sur chaque nœud du cluster. Donc, nous pouvons venir de l'extérieur du cluster et frapper n'importe quel nœud du cluster en utilisant son nom ou son IP sur le port 30,001 et le même résultat, nous avons frappé le service, non ? Eh bien, c'est la configuration front-end, la configuration backend comme où le trafic est acheminé ? Eh bien, il sort de l'arrière sur 8080. Encore une fois, dans cet exemple, il n'a pas besoin d'écrire une copie un port différent, mais il ira à n'importe quel pod sur le cluster avec l'étiquette Web de l'API, ce que je pense si nous regardons notre pod ici. Oui, il écoute sur 8080 et il est étiqueté comme AP est égal à Web. Donc si on déploie ce service et que tu vas t'y habituer, non ? J' ai le fichier FVC YAML localement ici. Si vous suivez, assurez-vous de l'avoir également localement. Maintenant, tu peux appeler les noms de fichiers comme tu veux, pas vrai ? Ce n'est pas forcément SBC Dot Yaml. Mais lorsque vous tapez les commandes, si vous avez changé le nom du fichier, assurez-vous de ne pas simplement taper ce que je tape. Oui. Eh bien, regardez, encore une fois, il est envoyé au serveur API, authentifié et autorisé. Nous obtenons une mise à jour de notre état désiré persisté dans le magasin de cluster et le service est créé. air bien. Maintenant, les services et pas comme les pods, ils n'exécutent en fait aucun de nos codes d'application. Fondamentalement, il y a un tas de réseaux dans les trucs, non ? Ainsi, comme les tables IP ou les règles IP VS qui piègent sur l'utilisation de l'adresse IP des services et font tout ce que la magie de réseau est nécessaire pour transférer ou charger équilibré ce trafic vers les pods corrects qui exécutent nos applications. Maintenant comme avant, et vous allez vous habituer à tout ça, non ? Mais vous pouvez les voir avec le Cube CTL habituel obtenir dans Cube CTL décrire les commandes. Donc, il est là, SVCs A101, et ils décrivent nous donne une sortie joliment formatée avec un peu plus de détails. Mais n'oublions pas pourquoi nous avons créé ça, non. Nous avons dit que nous n'avons jamais parlé directement aux pods. On met toujours un service devant eux et on parle au service. Donc, si vous êtes une application exécutée sur le cluster ou que vous savez quoi, vous pourriez même avoir une session exacte dans un pod d'application fonctionnant sur votre cluster. Vous pourriez appeler le nom du service. Le nôtre est SBC 1.0.1 sur le port de services. Maintenant, le port interne, rappelez-vous était 8080 et vous arriverez au service. Maintenant, si vous êtes en dehors du cluster, peut-être que vous êtes sur votre ordinateur portable ou votre client d'application externe ou autre chose, alors vous appuyez simplement sur l'IP publique ou le DNS public, l'un des nœuds du cluster sur ce port, 30 001, et vous y arriverez aussi. Eh bien, écoute, parler, c'est pas cher, non ? Mon cluster Kubernetes se trouve dans Google Cloud. Donc, je recherche l'IP publique de l'un de ces nœuds. Merci comme toujours, Gk pour vos noms de nœuds hideusement longs qui bousillent mes colonnes. Et j'aurai cette adresse IP externe cependant. Et nous allons mettre ça dans une nouvelle session de navigateur, 30,001. Et nous y sommes comme par magie. Maintenant, regarde, euh, vraiment ne veux pas travailler sur le point, mais je veux vraiment que tu t'éloignes de ce cours en comprenant les fondamentaux. Laisse-moi être clair, non ? Ce service obtient un nom stable et une adresse IP sur le cluster. Quand je dis stable, à droite, Kubernetes est super petites promesses que ces valeurs ne changeront jamais tant que le service existe. Le nom du service est enregistré auprès des clusters DNS internes, ce qui signifie que toutes les parties de votre application sur le cluster peuvent envoyer du trafic au nom de l'IP du service sur son port, et il atteindra le service. Une fois que vous atteignez le service, charge du trafic est alors équilibrée entre les modules du cluster avec une étiquette correspondante. Mais on n'a pas fini, non ? Parce que ce service particulier que nous avons créé est un service de port de nœud. D' autres existent, non ? Mais c'est un service de port de noeud, et cela signifie qu'il obtient un port supplémentaire, 30,001 dans notre exemple qui est exposé au monde extérieur via chaque nœud d'un cluster. Ce qui signifie que si vous avez un client externe, comme mon navigateur Web que nous venons de voir, vous pouvez frapper n'importe quel nœud du cluster sur ce port et atteindre la surface. Et finalement l'application, qui comme nous l'avons dit, puis la charge équilibre le trafic, déposant le cluster avec l'API va étiquette web, et atteindre l'application. Maintenant, enfin, je pense que bien, nous pouvons frapper n'importe quel nœud du cluster sur ce port. Ce nœud n'a pas besoin d'exécuter un réplica du conteneur. Qui ? Ok, une dernière chose. Alors pourquoi ils sont Nigel, devons-nous parler à un service au lieu de directement aux pods ? Qui oui, super guide de questions que tu as demandé. Alors imaginez à nouveau ce scénario. Écrivez un tas de pods sur le cluster et vous savez quoi, perdons ceux qui ne correspondent pas à notre étiquette. Ok, on dirait cinq pour moi. Disons que l'hébergement de notre web front end et les augmentations de la demande causent quoi que ce soit, n'est-ce pas ? On a une promotion ou quelque chose comme ça, peut-être que c'est Black Friday. Oui. Nous ajoutons donc plus pour faire face à la demande. Will, comment les autres parties de notre application ont-ils été au courant de ces nouveaux pods que nous venons d'ajouter ? Et ça marche le même. Nous réduisons l'échelle et faisons disparaître certains d'entre eux. Je veux dire, nous ne voulons pas que nos développeurs gonflent leur code en écrivant une logique pour suivre des choses comme ça. Maintenant, alors à la place, nous construisons un service. Cela se trouve devant les pods et il offre ce nom garanti, IP et port. Alors que nous ajoutons et enlevons des pods en bas ici, le service garde la trace gelée et il cache littéralement toute la mise à l'échelle vers le haut et vers le bas qui se passe en bas ici. Droit ? Donc, oui, comme on l'a dit à propos des boucles de montre en arrière-plan, il y a une boucle de contrôle pour l'objet de service en arrière-plan qui est juste assis là jour après nuit, jour après nuit, à grignoter sur du pop-corn, la recherche de nouveaux pods qui correspondent aux étiquettes du service. À mesure que de nouveaux modules correspondants sont ajoutés, le service met à jour sa liste de points de terminaison. Et devinez quoi ? Comme les gousses disparaissent, il fait de même. Toujours maintenir une liste à jour des dosettes assorties en bonne santé. De bonnes choses. Et on a fini. Oui. Ensuite, nous allons parler d'auto-guérison. 13. Utiliser des Deployments Deployments: Maintenant, jusqu'à présent, nous avons déployé un pod et un service. Le pot est l'endroit où fonctionne notre application et le service est la façon dont nous nous connectons à elle seulement. Et ça me grince à chaque fois que j'ai eu la conversation. Nous ne déployons jamais directement des pods. Et voici pourquoi écrire ceci. Voici un pod enveloppant un conteneur et vous savez quoi ? Littéralement la seule chose qu'une dose de pod d' abord est de laisser le conteneur à l'intérieur de celui-ci courir sur Kubernetes. Vous vous souvenez probablement, nous avons dit que les conteneurs ne pouvaient pas fonctionner directement sur Kubernetes. On doit les envelopper dans une capsule. Will magique, c'est génial. Mettez les gousses nous donner dument squat. Donc absolument 0 quand il s'agit de choses comme l'auto-guérison, échelle, l'exécution des mises à jour et les annulations versionnées. Pour toutes ces bonnes choses que nous avons besoin de déployer, qui, comme le montre l'image, enroule autour d'un pod. Donc, c'est un peu comme passer le colis cette année. Nous avons des conteneurs enveloppant notre code d'application, des pods, enveloppant nos conteneurs, et maintenant un déploiement enveloppant un pod. Et comme le montre la photo, le déploiement est ce qui nous donne toutes les bonnes choses. Eh bien, c'est à ça que ça ressemble. Maintenant, en commençant par le bas, on a le même vieux conteneur, non ? Inchangé. Donc nous devrions nous habituer à ça maintenant. Et puis, en quelque sorte, pas nous avons un tas de trucs de pod. Ce sont donc les étiquettes que le POD obtient afin que ce service que nous avons créé puisse lui envoyer du trafic. Oui, comme avant, non ? Et puis enfin, nous avons les trucs de déploiement en haut ici qui enveloppent le POD. Eh bien, en partant du haut cette fois, nous avons notre aversion et notre genre de ressources habituelles. Alors donnez-nous un déploiement, s'il vous plaît. Kubernetes est basé sur la définition du schéma V1 dans le sous-groupe de l'API des applications. Donnez au déploiement lui-même un nom et quelques étiquettes. Maintenant, il ne faut pas les confondre avec les étiquettes POD plus bas. D' accord ? Mais on arrive à des trucs intéressants. Sélectionnez une étiquette de correspondance. C' est comme l'étiquette sélectionnée que nous avons vu dans le fichier de services YAML, non ? Donc, il dit que cet objet de déploiement va gérer les pods sur le cluster avec cette étiquette API appelle web. Ensuite, nous avons des répliques égales à un. Donc, quand nous envoyons ceci au serveur API, il va planifier exactement un pod en fonction de la définition ci-dessous. Maintenant, c'est le bit de mise à l'échelle, non ? Et on y reviendra plus tard. En fait, ça fait partie de l'auto-guérison aussi bien. Mais avant que tout ce type de stratégie ne soit mise à jour mobile. Donc, quand viendra le temps de mettre à jour tout ça ici dans la définition du pod, Kubernetes va faire ce qu'on appelle une mise à jour glissante. Maintenant, je sais beaucoup à digérer ici, non ? Et viendra à chaque bit à tour de rôle. Ne vous inquiétez pas, en pensant que je m'attends à ce que vous fassiez tout ça maintenant, vous n'écrivez pas vous y arriverez en temps voulu. Pour l'instant, ce sont les déploiements ici, définissant toutes les bonnes choses qui nous donnent l'auto-guérison, mises à jour, tout ce genre de jazz, non ? Envelopper autour d'un pod, qui à son tour héberge un seul conteneur. Maintenant, une question que l'on me pose tout le temps est un pod peut-il avoir plus d'un conteneur ? Et la réponse est, oui, définitivement. Mais c'est un cas d'utilisation assez avancé, non ? Où 101 cours. Donc, nous regardons juste le modèle d'un conteneur par pod. Mais laissez-moi juste dire, le modèle de conteneur multiple par pod est vraiment puissant et il est fortement exploité par des choses comme les maillages de service. Maintenant, il y a d'autres choses qui l'exploitent aussi. Mais vous savez ce que les maillages de service sont un sujet brûlant en ce moment et vous savez combien nous aimons un bon mot à la mode. Quoi qu'il en soit, écoute, j'ai le dossier localement. Si vous suivez, vous aurez besoin d'elle-même. Vous avez donc soit cloné le repo GitHub soit copié et collé le contenu de GitHub dans un fichier. Et puis c'est juste notre fidèle Cube CTL apply commande. Et je sais que je suis comme un disque cassé maintenant, non ? Mais cela va au serveur API, authentifié et autorisé, stocké dans ETC, jour non planifié pour le cluster. Donc Cube CTL juste pour s'assurer qu'il fonctionne, ce qui est, oui. Et puis un Cube CTL obtenir des pods. Boum. C' est là. Un tout nouveau pod géré par le déploiement avec toutes les superpuissances qui viennent avec ça, n'est-ce pas ? Donc, comme on dit, auto-guérison, mise à l'échelle, exécution des mises à jour, rollbacks, tout ça, bonté, oui. En fait, vieille capsule tête-à-tête ici, elle est probablement un peu inférieure, mais comme être debout à côté de Tony Stark. Oui. Bref, tu sais quoi, en parlant de superpuissances, ensuite, on va voir un peu d'auto-guérison. 14. Self healing: Très bien, nous avons quelques capsules en cours d'exécution. Celui-ci est géré par un déploiement. Donc c'est Tony Stark WAR avec des superpouvoirs comme l'auto-guérison et d'autres choses. Oui. Mais la vieille 101 partie ici, c'est comme moi, un peu un vieil homme avec des super pouvoirs. Je veux dire, j'ai récemment pris ma retraite de jouer au football ou au football en fonction de l'endroit où vous vivez. Fondamentalement, parce que mes genoux ont 0 pouvoir de guérison ces jours-ci. De toute façon. Un pod géré par un déploiement et l'autre non. Donc si on fait ça ici à 101 pod, c'est parti ? Si on colle une montre et qu'on a des pods ici. D'accord. Il n'est pas parti, mais ça va lui donner quelques secondes à faire. Il est juste de dire que ce ne revient pas 0 superpuissances. Maintenant, si nous regardons notre déploiement ici, c'est la gestion de notre POD restant. Ce qu'il dit ici, c'est toujours s'assurer qu'il y a un de ces modules en cours d'exécution sur le cluster. Et ça pourrait sembler assez simple, non ? Mais croyez-moi, la machinerie et l'arrière-plan, comme toutes les boucles de montre et toutes les autres choses. Qui a eu Italia ? C' est l'ingrédient secret des superpuissances. Cela donne notre POD invincibilité restante. Eh bien, on verra quand même. Donc si nous essayons de le tuer avec l'un de ces trucs, prenez le décongelé, Homer à lui. Nous regarderons à nouveau l'action en direct. Oh, qu'est-ce que c'est ? Regardez dedans ? Comme deux conteneurs. Et c'est quoi cette fin que les autorités commerciales avaient des superpouvoirs. Ce qui se passe ici, c'est qu'on vient de tuer le marteau décongelé. Oui. Et comme on pouvait s'y attendre avec ces marteaux, la capsule est morte. Mais ce que les déploiements ont fait à Lockerbie en haut niveau un peu de cheveux, non ? Mais il a créé un nouveau pod identique à sa place. La seule différence est en fait ce morceau à la fin de son nom ici. Donc on peut maintenant écrire d'une manière que nous trichons. Le pod est mort et il a été remplacé par un autre identique. Donc les anciens sont partis et un nouveau clone, si vous voulez, est à sa place. Mais vous savez quoi, du point de vue de l'application, ce n'est pas la triche. L' application continue. Je veux dire, votre application n'est pas dérangée par les noms de POD ou quoi que ce soit, n'est-ce pas ? Du point de vue de l'application, les preuves sont toujours en cours d'exécution. Et tu sais quoi, non ? C' est beaucoup mieux quand il y a comme plusieurs répliques en cours d'exécution ici et un meurt et est immédiatement remplacé. Habituellement, dans cette situation, l'application ne saute pas battre. Maintenant aussi, non ? C' est la même chose si quelque chose se brise dans le cluster, comme je sais qu'on vient de tuer manuellement la partie de la balle d'écriture. Disons qu'un nœud meurt dans le cluster et qu'il prend des pods avec. Eh bien, si ces pods, Raul Tony s'est approvisionné avec le déploiement. Maintenant, la panique, non ? Les gousses perdues sont remplacées et le monde continue de tourner, ce qui est brillant tout de suite, vous savez quoi ? Nous pouvons même actualiser l'onglet de notre navigateur ici sans changer l'URL. Parce que ce qui s'est passé, c'est l'objet de service qui fait tout le réseau pour le Palladia offre ce point de terminaison super stable. Je suppose qu'on pourrait appeler le terminal Tony Stark aussi. Ouais, c'est garanti de ne jamais changer son invincible, non ? Et il a toujours une liste à jour des pods qui correspondent aux étiquettes qu'il recherche. Et évidemment, le nouveau public a été filé que nous venons de voir là-bas. Il y a les mêmes étiquettes. Ouais, donc on va tous bien. Et que les gens est un aspect de l'année d'auto-guérison. Mais le truc cool, non ? Ça aurait pu arriver à trois heures du matin. Et Kubernetes l'a réparé sans nous réveiller. Mais vous savez quoi, nous sommes loin d'être finis à l'échelle. 15. Mise à l'échelle: Donc, une autre chose que les déploiements nous donnent est de mettre à l'échelle cette capacité pour dire que j'ai plus ou moins besoin d'un pod particulier. Une chose que Gus a dit plus tôt, peut-être que c'est la fin du mois et le rapport pour le faire, allons avoir plus de pods qui prennent en charge l'infrastructure de reporting. Ou peut-être que nous avons des offres sur ou quelque chose et que nous nous attendons à une augmentation du trafic. Nous allons donc augmenter les bits qui prennent en charge la navigation et les recherches dans les Likes. Eh bien, si nous regardons ce que nous avons, oui, un seul déploiement appelé déploiement individuel et il a une réplique. Donc la façon dont nous l'avons mis à l'échelle pour laisser dire cinq, pour ouvrir le déploiement Yaml ici et regarder dans le monde réel, non ? Vous allez gérer cela de la même façon que vous gérez votre code, espérons-le. Donc dans le contrôle de la source ou quelque chose, ouais, mais tu vas vérifier ça et tout ce jazz, ouais. Et puis nous espérons que ces répliques comptent ici jusqu'à cinq. Viens ici et on sauvera nos changements. Et puis on réapplique ça au cluster et on le revérifie dans le contrôle de version, bien sûr, oui. Mais c'est littéralement mettre à jour ce Yammer, qui est notre source de vérité, puis le réémettre sur le serveur d'API qui est enregistré comme un nouvel état désiré jusqu'à un réplica à cinq. La boucle de contrôle de fond s'affiche, hé, on en veut cinq, mais on n'en a qu'un. Donc, ça tourne pour plus. Et il y a cinq gousses. Maintenant, nous pouvons, si nous voulons échelle en utilisant la commande Cube CTL scale. Mais je ne pense pas que ce soit la façon de Kubernetes. Et je vais te dire pourquoi, non ? faire ainsi est la voie impérative, pas la voie déclarative. Alors imaginez avec moi, d'accord, que vous gérez un cluster Kubernetes avec un tas d'applications et qu'il y a un P1 en cours. Oui. Donc c'est comme une alerte rouge toutes les mains aux postes de combat et vous êtes en train de taper en regardant les événements et les journaux et vos patrons suspendus au-dessus de votre épaule et ses patrons constamment au téléphone dans son Bedlam, à droite. Mais c'est génial. Oui. Je veux dire, tu as tout payé. Ils sont vraiment difficiles à battre l'action et l'excitation. Et tu sais quoi ? Tu as tendance à apprendre une tonne. Quoi qu'il en soit, écoute, tout se passe comme ça, non ? Vous faites des changements à la volée impérativement. Oui. Je change des trucs comme tu vas. Et disons que le problème et j'invente cela, d'accord, mais disons que le problème était que le port réseau sur lequel votre application fonctionne ne fonctionne pas. Quoi qu'il en soit, vous changez le port que vous utilisez à la volée. Donc, sur la ligne de commande sans vérifier votre fichier YAML, sans mettre à jour le fichier Yammer, et sans réappliquer cela au cluster. Bref, donc vous changez le port réseau à la volée et c'est des célébrations Q, non ? Vous avez été haut cinq les patrons par de nouvelles boissons après travail et au milieu de toute l'adoration et général devenir fou, vous oubliez que vous changez le port en direct à comme 9 mille ou quelque chose, vous mettez à gauche. Il est 8080 dans votre fichier YAML. Et la raison pour laquelle c'est mauvais, non ? C' est parce que ce qui est en direct sur le cluster ne vous correspond plus. Yaml et Kubernetes n'ont aucun moyen de le savoir. Eh bien, enroulons l'horloge un peu en avant et disons que c'est une semaine ou quoi que ce soit plus tard et que vous poussez une nouvelle image à l'application. Donc, si tout ce que vous procédure normale, à droite, parce que ce n'est plus un P1, donc tout est contrôlé. Oui. Vous récupérez le YAML, vous mettez à jour la version de l'image utilisée et vous poussez le YAML vers le cluster. Seulement. Vous n'avez pas remarqué que la Yamaha dit toujours le vieux port 8080, qui est cassé et ne fonctionne plus. Donc, quand vous le redéployez, oui, vous obtenez une nouvelle image, mais vous récupérez aussi l'ancien port cassé. Maintenant, une promesse ici. Qu' est-ce que l'année de cinq ans ou d'acheter vos boissons cette fois ? Donc, faire un changement impératif comme cela n'est généralement pas recommandé. On sait ce que je gaufre. Nous avons maintenant cinq répliques avec un observateur d'arrière-plan qui regarde juste le cluster toute la journée, assurant que l'état désiré correspond à notre état observé réel. Maintenant, bien sûr, c'est la même chose si nous avons réduit le nombre, écrire, mettre à jour le YAML, le repousser sur le serveur API. Fabuleux. Seulement, tu sais quoi, tout est un peu manuel, n'est-ce pas ? Je veux dire, je veux dire, ou vous êtes un être humain pour faire le travail. Heureusement, Kubernetes a des technologies de mise à l'échelle automatique. Le scaler automatique de pod horizontal qui peut rechercher l' occupation de vos pods et évoluer dynamiquement vers le haut et vers le bas. Et il existe un scaler automatique de cluster qui peut augmenter et diminuer le nombre de nœuds dans votre cluster. Encore une fois, dynamiquement selon qu'il y a suffisamment de capacité dans l'ensemble actuel du cluster pour faire tourner de nouveaux pods dans les J'aime. Malheureusement, ces sujets dépassent le cadre de ce cours 101. Quoi qu'il en soit, verrouiller pour l'instant dans celui-ci j'une cause qui est à l'échelle. À venir. Ensuite, nous allons intégrer l'application avec un équilibreur de charge basé sur le cloud. Apportez-le. 16. Équilibre de charges Cloud: Maintenant, je suis désolé. Si vous suivez votre ordinateur portable avec Docker Desktop, ou si vous suivez avec jouer avec Kubernetes, vous ne pourrez pas suivre ce laboratoire. Ce laboratoire ne fonctionnera que si votre cluster se trouve également sur un nuage public ou un bac à sable magique, qui s'exécute sur un nuage public. Quoi qu'il en soit, les esprits sur Google Cloud, sur le moteur Google Kubernetes. Donc je suis bon d'y aller maintenant, ne pas être capable de suivre. Je suis vraiment désolé, mais tu sais quoi ? Il suffit de regarder. D' accord. Tu l'as toujours compris. Ce n'est pas difficile ce que nous sommes sur le point de faire. Quoi qu'il en soit, écoutez, nous avons une application simple déployée, cinq répliques ici d'un simple serveur web. Et nous avons un service Kubernetes qui fournit une mise en réseau stable pour les réplicas. Mais le type de service que nous avons est un service de port de noeud, qui, si nous rejetons nos esprits, nous permet d'accéder à notre application via un nom ou une adresse IP depuis l'intérieur du cluster sur le port 8080, ce qui est tout bon. Mais si nous voulons accéder de l'extérieur, alors nous avons besoin du nom ou de l'adresse IP publique d'au moins un de nos nœuds. Ensuite, avec notre configuration, nous l'avons frappé sur le port 30,001 et entrerons. C' est bon, c'est ça. Mais soyons honnêtes, c'est un peu dépouillé vraiment. Je veux dire, qui veut garder une trace des noms de nœuds ou des API ? Oui. Donc, un moyen beaucoup plus mince serait de fronter tout avec un équilibreur de charge. Et sérieusement, faire ça ne pourrait pas être plus facile. En fait, je suis gêné de voir à quel point c'est facile. Donc, ce YAML ici, qui va sembler très familier, Il va intégrer ceux avec un équilibreur de charge Cloud. Donc, de toute façon, regardez le même en dehors de mon ancienne version d'API et gentil que nous savons tout à ce sujet. Donnez-lui un nom et une étiquette. Et puis une configuration front-end ici disant le port 8080 sur tout ce que nous obtenons comme équilibreur de charge Cloud. Et puis l'équilibrage de charge hors du backend du service sur 8080 à n'importe quel pod avec l'API est égal à l'étiquette wed. Donc on a vu tout ça, non ? La seule différence réelle par rapport au dernier service que nous avons déployé est ce type d'équilibreur de charge ici. Donc, comme je l'ai dit, si vous êtes sur une plate-forme cloud et que tous les grands utilisent AWS Azure, Google, Digital Ocean, IBM Cloud, vous donnez le nom juste en définissant un seul mot ici. équilibreur de charge, Kubernetes va s'en aller parler à ton nuage. Habit provision, un équilibrage de charge face à Internet qui accepte le trafic sur le port 8080 et assurez-vous qu'il est équilibré de charge sur tous les pods exécutant votre application également sur le port 8080. Je veux dire, à quel point c'est cool en ce moment, la politique, je n'en ai pas trop, non ? Je pense que le point à prendre à la maison est qu'avec peu d'efforts embarrassants, nous obtenons un équilibrage de charge complet et hautement disponible sur Internet intégré à notre application. Encore une fois, un monstre, j'adore ça. Quoi qu'il en soit, écoute, j'ai le dossier localement. Oui. Ce qui signifie qu'il est temps pour notre vieil ami Cube CTL appliquer. Dites-lui le dossier et il s'en va. Maintenant, si je colle une montre sur cette commande ici, sont probablement semblables dans moins d'une minute. Et je vais éditer la vidéo, non ? Donc, vous n'avez pas à regarder l'écran en attente, mettre dans environ une minute, ces valeurs en attente ici sous l'IP externe va changer à une adresse IP publique valide comme ça. Et nous pouvons frapper ça sur le port 8080, qui et comme par magie, c'est notre application. Ainsi, toutes les applications web s'exécutant dans un conteneur, enveloppées dans un module à son tour, enveloppées dans un déploiement sur notre cluster privé Kubernetes, devant un service Kubernetes qui donne un point IPN stable intégré avec un cloud natif équilibrage de charge, n'est-ce pas ? Je veux dire, c'est beaucoup de bonnes choses, non ? Tu sais quoi ? C' est si simple que nous le voyons ici dans une cause individuelle. Je veux dire, à quel point c'est excellent ? Je pense que tu conviendras que c'est très excellent. Et tu sais quoi, non ? N' oublions pas que le service surveille constamment pour s'assurer qu'il a la toute dernière liste de pods à équilibrer à o. et vous savez quoi, il n'équilibre que la charge vers des pods sains. Et nous grattons littéralement la surface. Allez. Espérons que ce n'était pas trop fort si vous écoutez sur un casque. Mais tu sais quoi, on n'a toujours pas fini. Je veux dire, on a failli r, mais pas tout à fait. Une dernière chose, une mise à jour. 17. Mise à jour de Rolling: Ok, dernière bonne leçon. Nous avons une application web simple fonctionnant sur Kubernetes, et nous nous sommes vus, nous allons augmenter et juste que nous l'avons vu se connecter à un équilibrage de charge Cloud face à Internet. Voyons comment nous pouvons faire une mise à jour mobile. Donc, dans l'état actuel des choses, si nous regardons le déploiement, nous devrions voir sur les conteneurs, la version image. Quoi qu'il en soit, ici, on a cinq répliques. Donc cinq pods exécutant un conteneur basé sur cette image. Mais disons que nous avons fait une image mise à jour et qu'elle a passé tous les tests d'intégration et les goûts. Et la dernière étape consiste à le déployer sur le cluster. Eh bien, le déploiement, faites-le sans même casser une sueur. Et la façon dont nous le faisons est la manière déclarative. Donc, nous retournons au YAML ici et c ici sur les répliques, nous avons une stratégie Rolling Update. En fait, je vais coller ces lignes dedans. D' accord. Donc, ce bloc que je mets en évidence, cela nous donne un certain contrôle sur la façon dont la mise à jour glissante se produit. Ce que nous disons est que lorsque nous mettons à jour quelque chose dans le bloc de gabarit plus bas, faites une mise à jour glissante. Cela signifie une réplique à la fois. Les hommes prêts secondes ici, il est dit, Après la mise à jour de chaque réplique, avant de faire la prochaine, attendre dix secondes. Maintenant, peut-être que dans le monde réel, tu dirais quelques minutes ou quelque chose comme ça. L' idée est de vous donner un peu de contrôle et de vous laisser coller l'année de déploiement. Eh bien, Max indisponible dit que pendant que la mise à jour est en cours, ne jamais aller plus d'un en dessous de ce que nous demandons. Maintenant. On en demande cinq. Donc ne jamais aller plus d'un en dessous de ça. Donc néanmoins que pour l'instant avec le maximum disponible était comme deux, puis Kubernetes serait autorisé à descendre à trois lors de la mise à jour. Et de même pour Mac Surge, n'allez jamais plus d'un que ce que nous demandons. Maintenant. Tu sais quoi, non ? Il y a beaucoup plus d'options , y compris les sondes, les tests et les goûts qui s' assurent qu'une fois que vous avez mis à jour un pod, il fonctionne réellement. Oui. Mais tu sais quoi ? Tout d'abord, nous avons maintenant quelques paramètres de mise à jour glissante. Et je pense que probablement celui qui dira avoir le plus d'effet est l'attente de 10 secondes après chaque mise à jour. Mais venons ici et changeons la version de l'image de 1.Donc 0 à deux. Sauve ça. Maintenant, lorsque nous le publions sur le serveur API aura un nouvel état désiré de oui, cinq pods. Mais cette fois, tous les cinq voudront exécuter l'image 2.0., la boucle de réconciliation d'arrière-plan. Nous remarquerons que cela ne correspond pas à ce qui est réellement sur le cluster. Donc, il corrigera les choses seulement les secondes prêtes min et les autres valeurs que nous avons mentionnées exerceront le contrôle sur la façon dont la mise à jour se produit. Alors faisons ça, non ? Et j'ai une commande ici qui surveillera la mise à jour qui est prête à être lancée. Et on s'en va. Laissons ça. D' accord. Écoutez, je suis un, allez-y et accélérez la vidéo en arrière-plan parce qu'on a cette période de 10 secondes. Oui. Et une promesse. Ce ne serait pas amusant de m'écouter chanter pour remplir le temps. Donc oui, eh bien, on peut voir que c'est méthodiquement passer à travers chaque réplique. Maintenant. Il passe à travers deux à la fois ici parce que max indisponible et Max surge sont tous les deux réglés à 11 plus un est deux. Quoi qu'il en soit, si je commence à rafraîchir l'onglet du navigateur ici, nous devrions voir parfois je reçois la version mise à jour et parfois l'ancienne. Et finalement, ou cinq répliques seront à jour. Un tout va obtenir est la nouvelle version. Et que les dames et les hommes quatre rangs sur 101 cours. Ça fera l'affaire. Maintenant. Honnêtement, il y a une tonne de plus comme si ça ne s'arrêtait jamais. Kubernetes est une vaste plateforme qui évolue toujours. Et puis il y a des choses que nous avons examinées sont stables et nous pouvons compter sur toutes ces choses. Put Kubernetes fait beaucoup plus et je ne mentirai pas. Cela peut être intimidant et la courbe d'apprentissage peut être difficile. Bref, on a couvert beaucoup de choses. Restez donc pour un résumé rapide des principaux points à emporter. En plus, je vais vous diriger vers des endroits qui vous aideront à passer au niveau supérieur. 18. Un réacteur vraiment rapide: D' accord, alors où avons-nous commencé ? Oui, nous avons défini ce qu'est une application de microservices natifs dans le cloud. C' est juste une façon moderne de construire une application utile à partir de nombreuses pièces spécialisées que nous avons couplées en utilisant des API simplement parce qu'elles sont appelées natives du cloud ne signifie pas qu'elles sont juste pour le cloud. En fait, j'irais même jusqu'à dire qu'un principe du cloud natif est probablement la possibilité de s'exécuter n'importe où, y compris vos centres de données locaux. Tant que tu conduis Kubernetes là-bas, ouais. Quoi qu'il en soit, nous avons dit que Kubernetes est la plate-forme de facto pour exécuter des applications natives dans le cloud. Et ce Kubernetes est deux choses. C' est un cluster et c'est un orchestrateur d'applications. Donc, le cluster est comme le substrat ou la plate-forme, si vous voulez, sur lequel nous avons exécuté nos applications. Il se compose de maîtres qui exécutent tous les Kubernetes est intelligent et logique. Et il y a un tas de nœuds de travail où nous exécutons nos applications utilisateur. Maintenant, écoute, c'est un groupe de monde irrégulier à la fin de la journée. Nous devons donc penser à des choses comme la disponibilité, la sécurité et les performances, et tout cela. Mon Dieu, oui. Maintenant, sur l'application orchestrent différents Kubernetes peuvent déployer et gérer nos applications. Pour nous, nous avons dit que le modèle préféré est appelé le modèle déclaratif, où nous définissons ce que nous voulons n'importe quel fichier YAML. Et à Kubernetes, nous ferons le dur labeur pour nous. Donc, la façon qui fonctionne est Kubernetes garde un registre de ce que nous voulons comme quelque chose appelé état désiré. Et il exécute un tas de boucles surveillées qui regardent les différents aspects de notre cluster et de nos applications. Et fondamentalement, ils vérifient constamment que ce qui est en cours d'exécution sur le cluster est ce que nous voulons. Chaque fois que l'état observé s'éloigne de cet état désiré, Kubernetes fait tout ce qui est en son pouvoir pour ramener tout en conformité avec l'état désiré. Et qu'avons-nous dit d'autre ? Oui, nous avons dit que nous écrivions nos applications comme normales, utilisons l'outil Docker pour les construire en tant qu' images de conteneur, puis utilisons Kubernetes pour les déployer et les exécuter. Maintenant, oui, Kubernetes orchestre application containerizzate, qui est juste un jargon techno pour les applications qui s'exécutent à l'intérieur de conteneurs. Oui, seuls les conteneurs ne peuvent pas aller directement au-delà de Kubernetes. D' abord, nous devons les emballer comme Potts. Maintenant, on peut encore augmenter les gousses avec beaucoup de choses, non ? Mais celui que nous avons examiné était le déploiement. Et cela donne des super pouvoirs aux pods, oui, comme la possibilité de vendre, d' échouer et de mettre à l'échelle et même de faire 0 mises à jour de temps d'arrêt. Et c'était ceux-là. C' est tout ce qu'on a du temps. Mais oh mon Dieu, il y en a tellement plus. Mais c'est le moment idéal pour apprendre Kubernetes. Maintenant, si vous aimez les livres de Dieu, quelqu'un pourrait aimer Quickstart Kubernetes, ESEA est à peu près au niveau de ce cours. Mais si vous êtes prêt à passer au niveau supérieur que le livre Kubernetes ici est régulièrement répertorié comme un best-seller sur Amazon et il a obtenu le plus d'étoiles de tous les livres sur Kubernetes. Oh, et il est mis à jour chaque année, donc il est toujours à jour. Maintenant, vous pouvez l'obtenir sous forme d'ebook sur Kindle et Leanpub, un livre broché sur Amazon. Il y a des éditions en espagnol, en chinois simplifié et en russe disponibles et une version audio, mais c'est juste un anglais. Oh, mon Dieu. Tu sais quoi ? Il y a même un accrochage sur l'ajout d'hommage. Mais pas de blague. L' édition Klingon, c'est juste la couverture et l'intro qui font appel aux restes en anglais. Bref, écoutez, le temps est court et je commence à gaufrer. N' hésitez pas à vous connecter avec moi. Je suis un support technique gratuit, mais je suis plus que prêt à vous connecter et vous aider à travailler vous premiers pas. Alors ne sois pas timide. Connectez-vous quand même. Ecoute, merci de passer ton temps avec moi. Bonne chance pour votre carrière. Et comme je l'ai dit, restez en contact.