Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Azure Kubernetes Service (AKS) expliqué : plan de contrôle, nœuds, réseau, sécurité et coûts (Doublage IA)

Transcript

Azure Kubernetes Service (AKS) expliqué : plan de contrôle, nœuds, réseau, sécurité et coûts (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Vous avez entendu parler de Kubernetes et d'AKS dans les
0:02
Speaker 2: discussions sur le cloud. Vous avez peut-être acquiescé, mais concrètement,
0:05
Speaker 2: qu'est-ce que cela signifie pour quelqu'un qui exécute des applications
0:07
Speaker 2: dans le cloud? Les conteneurs ont changé notre façon de
0:10
Speaker 2: concevoir les logiciels car ils sont légers, portables et cohérents.
0:13
Speaker 2: Le problème est que les gérer manuellement devient vite un casse-tête.
0:16
Speaker 2: Vous pouvez gérer une poignée de conteneurs, mais quand vous
0:18
Speaker 2: en avez des dizaines ou des centaines, vous passez tout
0:20
Speaker 2: votre temps sur la mise à l'échelle, les mises à
0:22
Speaker 2: jour et les pannes, au lieu de créer votre produit.
0:25
Speaker 2: A la fin de cet épisode, vous comprendrez les 4
0:27
Speaker 2: points majeurs qu'Azure Kubernetes Service gère pour vous. Le plan
0:29
Speaker 2: de contrôle, les nœuds, le réseau et la sécurité. Nous
0:33
Speaker 2: détaillerons également ce que cela coûte réellement. Pas de jargon marketing,
0:36
Speaker 2: juste des explications claires. Le problème des conteneurs, pourquoi nous
0:39
Speaker 2: avons besoin d'AKS? Les conteneurs se sont imposés car ils
0:41
Speaker 2: résolvent un vrai problème. Un package regroupant votre code applicatif,
0:44
Speaker 2: vos bibliothèques d'exécution et votre configuration. Ils s'exécutent de la
0:47
Speaker 2: même manière sur votre ordinateur portable, sur un serveur de
0:49
Speaker 2: test ou en production. Fini les problèmes du type que
0:51
Speaker 2: ça fonctionne sur un machine. Exécuter quelques conteneurs fonctionne très bien.
0:55
Speaker 2: ou les lancer manuellement, vérifier leurs journaux et les redémarrer
0:58
Speaker 2: quand ils plantent. Mais une fois que vous en avez
0:59
Speaker 2: des dizaines ou des centaines réparties sur plusieurs serveurs, vous
1:02
Speaker 2: rencontrez une toute nouvelle série de problèmes. Vous devez décider
1:05
Speaker 2: où va chaque conteneur, quel serveur reçoit quel conteneur et
1:07
Speaker 2: comment il se trouve sur le réseau. Que se passe-t-il
1:10
Speaker 2: quand l'un d'eux plante à 3h du matin? Et comment
1:12
Speaker 2: gérer un pic de trafic nécessitant 50 copies supplémentaires de
1:15
Speaker 2: votre application en 30 secondes? Kubernetes est une plateforme open
1:18
Speaker 2: source conçue précisément pour ces problèmes. Il planifie les conteneurs
1:21
Speaker 2: sur les serveurs, ajuste leur mise à l'échelle, vérifie leur
1:24
Speaker 2: état et achemine le trafic entre eux. C'est le standard
1:26
Speaker 2: de l'industrie pour l'orchestration de conteneurs. Mais Kubernetes résout un
1:30
Speaker 2: problème et en crée un autre. Le gérer soi-même est complexe.
1:33
Speaker 2: Vous devez configurer et maintenir un plan de contrôle, le
1:36
Speaker 2: cerveau du cluster, gérer les nœuds de travail, appliquer les
1:38
Speaker 2: correctifs de sécurité, mettre à niveau les versions et sauvegarder
1:40
Speaker 2: les versions et sauvegarder les données de configuration. C'est un
1:42
Speaker 2: travail à plein temps pour quelqu'un qui sait ce qu'il fait.
1:44
Speaker 2: Les services gérés, comme Azure Kubernetes Service, vous déchargent de
1:47
Speaker 2: ce fardeau opérationnel. Microsoft gère le plan de contrôle pour
1:50
Speaker 2: vous et s'occupe des mises à niveau, des correctifs et
1:52
Speaker 2: des sauvegardes. Vous vous concentrez sur vos applications. Alors que
1:55
Speaker 2: fait exactement AKS pour vous? Commençons par l'élément le plus important,
1:58
Speaker 2: le plan de contrôle. Qu'est-ce qu'Azure Kubernetes Service? AKS est
2:02
Speaker 2: la version gérée de Kubernetes par Microsoft. Tout simplement, vous
2:06
Speaker 2: obtenez un cluster Kubernetes entièrement fonctionnel sans avoir à installer
2:09
Speaker 2: ou maintenir l'infrastructure sous-jacente. Microsoft gère le plan de contrôle
2:12
Speaker 2: pour vous et vous concentrez sur le déploiement et l'exécution
2:14
Speaker 2: de vos applications. Voyez cela comme la différence entre louer
2:16
Speaker 2: un appartement et construire une maison. Lorsque vous construisez une maison,
2:19
Speaker 2: vous êtes responsable de tout, les fondations, la plomberie, l'électricité,
2:22
Speaker 2: le toit. Lorsque vous louez, le propriétaire s'occupe de tout cela.
2:24
Speaker 2: Vous n'avez plus qu'à emménager et déco. AKS est votre propriétaire.
2:27
Speaker 2: Microsoft gère les fondations, le plan de contrôle, la mise
2:29
Speaker 2: en réseau, les correctifs de sécurité et les mises à jour.
2:32
Speaker 2: Vous apportez les meubles, vos applications containerisées, les configurations et
2:34
Speaker 2: les pipelines de déploiement. Mais AKS n'est pas seulement un
2:37
Speaker 2: cluster Kubernetes autonome. Il fonctionne en étroite intégration avec le
2:39
Speaker 2: reste de la plateforme Azure. EntraID gère l'authentification des utilisateurs
2:43
Speaker 2: et le contrôle d'accès. Azure Monitor collecte les journaux et
2:45
Speaker 2: les métriques de votre cluster et de vos applications. Azure
2:48
Speaker 2: Policy vous permet d'appliquer des règles sur tous vos clusters automatiquement.
2:50
Speaker 2: comme interdire l'exécution de conteneurs en route ou exiger que
2:52
Speaker 2: toutes les images proviennent d'un registre approuvé. C'est ce qui
2:56
Speaker 2: fait d'AKS bien plus que du Kubernetes tournant sur des
2:58
Speaker 2: machines virtuelles Azure. Bien sûr, vous devez toujours connaître les
3:01
Speaker 2: concepts de base de Kubernetes, pods, déploiements et services. C'est
3:05
Speaker 2: le savoir que vous apportez. AKS ne remplace pas cela.
3:08
Speaker 2: Ce qu'il supprime, c'est la charge opérationnelle liée au maintien
3:10
Speaker 2: de la santé du cluster. Vous ne vous souciez pas
3:12
Speaker 2: d'une panne contrôle. Vous ne mettez pas à jour manuellement
3:14
Speaker 2: les versions de Kubernetes. Vous ne sauvegardez pas ETCD, la
3:17
Speaker 2: base de données de configuration du cluster. Microsoft gère tout cela.
3:20
Speaker 2: Levons donc le voile sur ce cerveau, le plan de contrôle.
3:23
Speaker 2: Plan de contrôle? Le cerveau géré par Microsoft. Que contient
3:26
Speaker 2: exactement ce plan de contrôle? Quatre composants principaux. Le serveur
3:29
Speaker 2: API et la porte d'entrée. Chaque commande, requête et interaction
3:32
Speaker 2: avec votre cluster passe par lui. Le planificateur décide quel
3:35
Speaker 2: nœud exécute chaque nouveau pod. Le gestionnaire de contrôleur surveille
3:38
Speaker 2: l'état du cluster et s'assure que la réalité correspond à
3:40
Speaker 2: ce que vous avez demandé. Et ETCD stocke toutes les
3:42
Speaker 2: données de configuration. Voyez-le comme la mémoire de votre cluster.
3:45
Speaker 2: Si ETCD est corrompu ou perdu, vous perdez votre cluster...
3:49
Speaker 2: Si vous installez Kubernetes vous-même, vous êtes responsable de tout cela.
3:51
Speaker 2: Vous corrigez le serveur API lorsque des vulnérabilités apparaissent. Vous
3:54
Speaker 2: sauvegardez le TCD régulièrement. Vous gérez les pannes matérielles sur
3:57
Speaker 2: les machines qui exécutent ces composants. C'est beaucoup de travail.
3:59
Speaker 2: Avec AKS, Microsoft vous est responsabilité. Ils exécutent le plan
4:02
Speaker 2: de contrôle sur leur propre infrastructure. Ils le corrigent, le
4:05
Speaker 2: sauvegardent et le surveillent. Vous ne voyez jamais les machines sous-jacentes.
4:08
Speaker 2: Vous interagissez simplement avec le point de terminaison du serveur API.
4:10
Speaker 2: Et tout le reste se passe en coulisses. Cependant, tous
4:13
Speaker 2: les plans de contrôle ne sont pas identiques. AKS propose
4:15
Speaker 2: trois niveaux. Gratuit, standard et premium. Le niveau gratuit vous
4:18
Speaker 2: offre le plan de contrôle sans coût supplémentaire, sans SLA
4:20
Speaker 2: sur le serveur API. Il convient à l'apprentissage, au développement,
4:24
Speaker 2: aux environnements de test où quelques minutes d'indisponibilité ne posent
4:26
Speaker 2: pas problème. Pour les charges de travail en production, vous
4:28
Speaker 2: voudrez probablement davantage. Le niveau standard coûte environ 72$ par
4:31
Speaker 2: mois et par cluster. Cela vous offre un SLA de 99,95%
4:34
Speaker 2: sur le serveur API lorsque vous utilisez des zones de
4:37
Speaker 2: disponibilité si le plan de contrôle tombe en panne, Microsoft
4:40
Speaker 2: vous crédite. C'est le choix par défaut pour la plupart
4:42
Speaker 2: des clusters de production. Le niveau premium coûte environ 430$
4:44
Speaker 2: par mois Vous bénéficiez de tout ce qui est inclus
4:47
Speaker 2: dans le standard, avec en plus un support à long
4:49
Speaker 2: terme pour les versions de Kubernetes. Si vous exécutez une
4:51
Speaker 2: charge de travail réglementée qui doit rester sur une version
4:53
Speaker 2: spécifique pendant des mois ou des années, c'est là que
4:55
Speaker 2: le premium est justifié. Voici le point clé cependant. Vous
4:58
Speaker 2: ne payez pas réellement pour le plan de contrôle lui-même.
5:00
Speaker 2: Le niveau gratuit est réellement gratuit. Le standard et le
5:03
Speaker 2: premium sont des frais pour le SLA et le support
5:05
Speaker 2: à long terme, pas pour les ressources du plan de contrôle.
5:07
Speaker 2: Ce que vous payez, ce sont les nœuds de travail
5:08
Speaker 2: et les machines virtuelles qui exécutent vos conteneurs, sans facturer
5:10
Speaker 2: séparément au tarif standard des machines virtuelles Azure. Voyez les
5:13
Speaker 2: choses ainsi. Le plan de contrôle et le cerveau. Microsoft
5:16
Speaker 2: le gère pour vous. Vous choisissez le niveau de service
5:18
Speaker 2: en fonction de vos besoins en fiabilité. Mais le véritable
5:20
Speaker 2: travail d'exécution de vos applications se fait sur les nœuds
5:22
Speaker 2: de travail. Ces nœuds de travail sont là où vos
5:24
Speaker 2: applications s'exécutent réellement. Parlons-en. Les nœuds, les travailleurs pour lesquels
5:28
Speaker 2: vous payez. Les nœuds sont des machines virtuelles Azure, tout simplement.
5:32
Speaker 2: Des machines virtuelles Azure standard qui hébergent vos pods, qui
5:34
Speaker 2: sont la plus petite unité dans Kubernetes exécutant un ou
5:36
Speaker 2: plusieurs conteneurs. Vous choisissez la taille et le nombre. Ainsi,
5:39
Speaker 2: si vous voulez une D2S Torf V3 avec 2 VCPU
5:41
Speaker 2: et 8Go de RAM, vous pouvez le faire. Besoin du
5:44
Speaker 2: nœud 32 optimisé pour la mémoire avec 32 vCPU et
5:46
Speaker 2: 256 Go, cela fonctionne aussi. Maintenant, vous ne vous contentez
5:50
Speaker 2: pas de regrouper des machines virtuelles au hasard. AKS les
5:52
Speaker 2: organise en pool de nœuds. Un pool de nœuds est
5:55
Speaker 2: un groupe de machines virtuelles identiques avec la même taille
5:57
Speaker 2: et configuration. Vous pouvez avoir plusieurs pools de nœuds dans
5:59
Speaker 2: un seul cluster. Un pool avec des VM de série
6:01
Speaker 2: D à usage général pour votre interface web, un autre
6:03
Speaker 2: avec des VM de série E optimisé pour la mémoire
6:05
Speaker 2: pour votre base de données et un troisième avec des
6:07
Speaker 2: VM compatibles GPU pour l'apprentissage automatique. Chaque pool s'adapte indépendamment
6:11
Speaker 2: et cette mise à l'échelle est automatique. Le mise à
6:13
Speaker 2: l'échelle automatique du cluster se révèle. Lorsqu'ils ont besoin de
6:15
Speaker 2: plus de ressources que ce que les nœuds actuels peuvent fournir,
6:17
Speaker 2: ils ajoutent de nouveaux nœuds. Et lorsque le trafic diminue
6:19
Speaker 2: et que les charges restent largement inutilisées, ils les suppriment.
6:22
Speaker 2: Vous définissez la taille minimale et maximale pour chaque pool
6:24
Speaker 2: et AKS gère le reste. C'est ici que vous faites
6:26
Speaker 2: de vraies économies. Vous ne payez pas pour de la
6:28
Speaker 2: capacité inutilisée pendant les heures creuses. Les mises à jour
6:31
Speaker 2: des nœuds sont une autre tâche gérée par AKS. Lorsqu'un
6:33
Speaker 2: nouveau correctif de sécurité du système d'exploitation sort, AKS peut
6:36
Speaker 2: l'appliquer à vos nœuds. Et lorsqu'une nouvelle version de Kubernetes
6:38
Speaker 2: est publiée, AKS peut mettre à jour votre cluster. Contrôlez
6:41
Speaker 2: le calendrier. C'est vous qui décidez quand les mises à
6:43
Speaker 2: jour ont lieu, pas Microsoft. Le travail réel de drainage
6:45
Speaker 2: des pods, de mise à jour des nœuds et de
6:47
Speaker 2: remise en ligne est effectué pour vous. Passons maintenant au coût.
6:50
Speaker 2: Vous payez les tarifs standards des machines virtuelles Azure pour
6:52
Speaker 2: vos nœuds. Une D2S V3 dans la région USA coûte
6:55
Speaker 2: environ 70$ par mois et une machine virtuelle plus grande
6:57
Speaker 2: coûte plus cher. Mais il existe des moyens de réduire
6:59
Speaker 2: ces coûts de manière significative. Les instances réservées vous permettent
7:02
Speaker 2: de vous engager sur un ou trois ans en échange
7:03
Speaker 2: d'une réduction, économisant jusqu'à 72% par rapport au paiement à l'utilisation.
7:07
Speaker 2: Si vous connaissez votre capacité de base, c'est-à-dire les nœuds
7:09
Speaker 2: dont vous avez toujours besoin, les réserver est très judicieux.
7:12
Speaker 2: Les machines Virtual Spot sont encore moins chères, avec jusqu'à
7:14
Speaker 2: 90% de réduction sur les tarifs et l'utilisation. Mais voici
7:16
Speaker 2: le piège. Azure peut récupérer cette capacité à tout moment,
7:19
Speaker 2: en prévenant vos nœuds 30 secondes avant leur éviction. C'est
7:23
Speaker 2: parfait pour les tâches par lot, les pipelines CI-CD ou
7:26
Speaker 2: les charges de travail sans état qui supportent les interruptions,
7:28
Speaker 2: mais pas pour votre API de production destinée aux clients. Ainsi,
7:31
Speaker 2: vous payez pour les nœuds de travail, vous choisissez leur taille,
7:33
Speaker 2: leur nombre et le modèle de tarification, tandis qu'AKS gère
7:35
Speaker 2: les pools, la mise à l'échelle et les mises à jour.
7:37
Speaker 2: Vos nœuds et vos pods doivent communiquer entre eux. Et
7:40
Speaker 2: c'est là qu'intervient la mise en réseau. La mise en réseau.
7:43
Speaker 2: Comment les pods communiquent? Chaque pod de votre cluster a
7:45
Speaker 2: besoin d'une adresse IP, mais les pods vont et viennent constamment.
7:48
Speaker 2: Ils plantent, ils montent en charge, ils sont remplacés. Il
7:50
Speaker 2: vous faut donc un système qui distribue les adresses IP
7:52
Speaker 2: dynamiquement et garantisse que les pods puissent se joindre. C'est
7:55
Speaker 2: ce que fait l'interface réseau de conteneurs, CENI. Azure CENI
7:57
Speaker 2: est l'implémentation de Microsoft. Elle gère l'attribution des adresses aux
8:00
Speaker 2: pods et la circulation du trafic entre eux. Il existe
8:03
Speaker 2: deux modèles de mise en réseau principaux au choix. Le
8:05
Speaker 2: réseau en surcouche, Overlay, attribue aux pods des IP issus
8:08
Speaker 2: d'une plage d'adresse distincte, non intégrée à votre réseau virtuel.
8:11
Speaker 2: C'est l'option la plus évolutive. Vous pouvez avoir jusqu'à 5
8:13
Speaker 2: zérinoneux et un quart de million de pods dans un
8:15
Speaker 2: seul cluster. Comme les IP des pods sont isolés de
8:18
Speaker 2: votre Vnet, vous pouvez réutiliser le même espace d'adressage sur
8:20
Speaker 2: plusieurs clusters sans conflit. La contrepartie est que les pods
8:23
Speaker 2: ne peuvent pas être accédés directement depuis l'extérieur du cluster.
8:26
Speaker 2: Le trafic quittant un pod est traduit par l'adresse IP
8:28
Speaker 2: du nœud. L'autre option est le réseau plat, où les
8:31
Speaker 2: pods obtiennent des adresses IP directement depuis la plage de
8:33
Speaker 2: votre Vnet. Les systèmes externes peuvent atteindre les pods directement
8:36
Speaker 2: si nécessaire, mais l'inconvénient est que vous consommez des adresses
8:39
Speaker 2: IP de votre VNets, ce qui peut s'épuiser rapidement si
8:41
Speaker 2: vous avez beaucoup de pods. Vous devez planifier soigneusement la
8:44
Speaker 2: taille de vos sous-réseaux. Parlons maintenant du trafic qui guide
8:46
Speaker 2: votre cluster. Lorsqu'un pod doit atteindre une ressource sur Internet,
8:49
Speaker 2: une API externe, une base de données ou un service tiers,
8:52
Speaker 2: ce trafic doit passer par un intermédiaire. Par défaut, AKS
8:55
Speaker 2: utilise un équilibre de charge Azure pour les connexions sortantes,
8:57
Speaker 2: ce qui fonctionne bien pour la plupart des charges de travail.
9:00
Speaker 2: Si vos applications effectuent beaucoup de connexions sortantes, vous pouvez
9:02
Speaker 2: être confronté à ce qu'on appelle l'épuisement des ports SNAT.
9:05
Speaker 2: Chaque nœud dispose d'un nombre fixe de ports de traduction
9:07
Speaker 2: d'adresses réseau source, et lorsqu'ils sont épuisés, les nouvelles connexions échouent.
9:11
Speaker 2: La solution est Azure NAT Gateway qui gère bien mieux
9:14
Speaker 2: un grand nombre de connexions. Pour exposer vos applications sur Internet,
9:17
Speaker 2: il existe deux approches principales. Pour les applications qui communiquent
9:21
Speaker 2: via TCP ou UDP comme les serveurs de jeu, les
9:23
Speaker 2: bases de données ou les protocoles personnalisés, vous utilisez un
9:25
Speaker 2: service d'équilibrage de charges. Il fournit à votre application une
9:28
Speaker 2: adresse IP publique et transfère le trafic au niveau de
9:29
Speaker 2: la couche 1. Pour les applications web utilisant HTTP ou HTTPS,
9:32
Speaker 2: vous devez utiliser un contrôleur d'entrée. Il fonctionne au niveau
9:35
Speaker 2: de la couche 7. Il comprend les URL, les chemins
9:37
Speaker 2: d'accès et les noms d'hôtes. Vous pouvez acheminer le trafic
9:39
Speaker 2: vers différents services en fonction du nom de domaine ou
9:41
Speaker 2: du chemin d'URL et une seule adresse IP publique peut
9:43
Speaker 2: servir des dizaines d'applications. AKS prend en charge des options
9:47
Speaker 2: d'ingresse gérées comme la passerelle d'application pour les conteneurs où
9:49
Speaker 2: vous pouvez exécuter la vôtre comme NGINX, comme NX. Une
9:52
Speaker 2: erreur souvent commise consiste à créer un cluster AKS avec
9:54
Speaker 2: un sous-réseau trop petit. Peut-être un sous-réseau 11h28, soit 16
9:57
Speaker 2: adresses IP au total. Cela fonctionne pour un petit cluster
10:00
Speaker 2: de test, mais AKS réserve des adresses IP par nœud.
10:02
Speaker 2: Un cluster de 3 nœuds avec un sous-réseau 28 peut
10:04
Speaker 2: convenir aujourd'hui, mais le mois prochain vous ajoutez un pool
10:06
Speaker 2: de nœuds, votre trafic augmente et soudainement vous ne pouvez
10:07
Speaker 2: plus passer à l'échelle. Et vous ne pouvez pas modifier
10:09
Speaker 2: le CIDR du sous-réseau une fois le cluster créé. Vous
10:12
Speaker 2: devrez reconstruire le cluster, ou créer un nouveau pool de
10:14
Speaker 2: nœuds sur un sous-réseau différent, émigrer vos charges de travail.
10:17
Speaker 2: Planifiez la taille de vos sous-réseaux pour permettre la croissance
10:19
Speaker 2: dès le 1er Une fois votre application opérationnelle et accessible,
10:22
Speaker 2: vous devez la sécuriser. Sécurité. Qui peut y accéder? Alors,
10:25
Speaker 2: comment fonctionne réellement la sécurité dans un caisse? Imaginez cela
10:28
Speaker 2: comme un bâtiment doté de plusieurs couches de protection. La
10:30
Speaker 2: première couche concerne l'identité et l'accès. Qui est autorisé à
10:32
Speaker 2: franchir un pas? Vous connectez votre cluster à EntraID, qui
10:35
Speaker 2: est le service d'identité de Microsoft. Il s'appelait auparavant Azure
10:39
Speaker 2: Active Directory. Votre équipe se connecte avec ses identifiants professionnels habituels,
10:42
Speaker 2: aucun compte supplémentaire n'est requis. Ensuite, par-dessus cela, vous ajoutez
10:45
Speaker 2: le RBC Kubernetes, c'est-à-dire le contrôle d'accès basé sur les routes.
10:48
Speaker 2: Cela détermine qui peut voir quoi, qui peut déployer des pods,
10:50
Speaker 2: qui peut supprimer des ressources. Un développeur peut n'avoir accès
10:53
Speaker 2: qu'à son propre namespace, tandis qu'un opérateur a un accès
10:55
Speaker 2: en lecture sur tout le cluster et un administrateur, un
10:57
Speaker 2: contrôle total. Vous pouvez mapper les groupes entrées directement au
11:00
Speaker 2: rôle Kubernetes ainsi. Lorsqu'une personne rejoint ou quitte l'équipe, vous
11:03
Speaker 2: mettez à jour le groupe entrée et les permissions suivent automatiquement.
11:06
Speaker 2: C'est la réception qui gère les accès pour tout le bâtiment.
11:09
Speaker 2: La sécurité réseau constitue une dure. Par défaut, le serveur
11:12
Speaker 2: API de votre cluster AKS est accessible via l'Internet public.
11:14
Speaker 2: Et bien que vous puissiez le restreindre à des plages
11:16
Speaker 2: IP spécifiques, le point de terminaison reste exposé. Pour les
11:19
Speaker 2: charges de travail en production, vous préférez un cluster privé.
11:22
Speaker 2: De cette façon, le serveur API reçoit une IP interne
11:24
Speaker 2: de votre VNet, accessible uniquement via Azure Private Link, sans
11:27
Speaker 2: aucune exposition publique. Quiconque gère le cluster doit être connecté
11:30
Speaker 2: à votre réseau, que ce soit via un VPN express
11:32
Speaker 2: route ou une machine de rebond au sein du VNet. Ensuite,
11:35
Speaker 2: nous passons à la sécurité des pods, là où se
11:36
Speaker 2: trouvent la plupart des vulnérabilités des conteneurs. La règle numéro 1,
11:39
Speaker 2: ne jamais exécuter de conteneur en tant qu'hôte. Si un
11:41
Speaker 2: conteneur tourne en route et qu'un attaquant s'introduit, il obtient
11:44
Speaker 2: un accès route sur l'hôte. Même chose pour l'escalade de privilèges. Désactivez-la.
11:48
Speaker 2: Utilisez Azure Policy pour Kubernetes afin d'appliquer ces règles automatiquement.
11:51
Speaker 2: Vous pouvez définir qu'aucun conteneur dans ce namespace ne peut
11:53
Speaker 2: s'exécuter en route et la politique bloque tout déploiement qui
11:56
Speaker 2: enfreint cette règle avant même qu'il n'atteigne un nœud. Les
11:58
Speaker 2: secrets sont le point important suivant. Ne stockez jamais de
12:00
Speaker 2: mots de passe, clés API ou chaînes de connexion dans
12:02
Speaker 2: votre code ou vos images Les gens le font tout
12:05
Speaker 2: le temps, ils codent en dur un mot de passe
12:07
Speaker 2: de base de données dans un fichier de config, construisent l'image,
12:10
Speaker 2: la poussent vers un registre et ce mot de passe
12:12
Speaker 2: est intégré pour toujours. Quiconque ayant accès au registre peut l'extraire.
12:15
Speaker 2: A la place, utilisez Azure Key Vault. Stockez-y vos secrets
12:18
Speaker 2: et laissez vos pods y accéder via le pilote SecretStore CSI.
12:22
Speaker 2: Le pod montre le secret en tant que volume ou
12:23
Speaker 2: variable d'environnement au moment de l'exécution et le secret ne
12:25
Speaker 2: touche jamais votre image ou votre code source. Enfin, la surveillance.
12:29
Speaker 2: Microsoft Defender for Containers analyse vos images de conteneurs à
12:32
Speaker 2: la recherche de vulnérabilités connues et surveille votre cluster pour
12:34
Speaker 2: détecter les activités suspectes, les tentatives d'escalade de privilèges, les
12:37
Speaker 2: connexions réseau inhabituelles ou le crypto-minage. Ce n'est pas un
12:41
Speaker 2: outil qu'on installe et qu'on oublie, mais il repère des
12:42
Speaker 2: éléments que vous pourriez manquer vous-même. Même avec tout cela,
12:45
Speaker 2: des problèmes peuvent survenir. Alors, examinons les pièges les plus courts.
12:48
Speaker 2: Piège courant, qu'est-ce qui tourne mal? Qu'est-ce qui fait trébucher
12:51
Speaker 2: les gens de plus haut? Passons en revue les suspects habituels.
12:53
Speaker 2: Tout d'abord, les limites de quotas azur. Votre abonnement Azure
12:56
Speaker 2: impose des limites sur le nombre de VCPU utilisables dans
12:58
Speaker 2: une région donnée, ainsi que pour les adresses IP publiques,
13:00
Speaker 2: les équilibres de charges et d'autres ressources. Lorsque vous créez
13:03
Speaker 2: un cluster AKS, cela consomme une partie de ce quota.
13:05
Speaker 2: Si vous atteignez la limite, la création du cluster échoue,
13:07
Speaker 2: la mise à l'échelle ne fonctionne plus. La solution est simple,
13:10
Speaker 2: demandez une augmentation de quota via le portail Azure. Mais
13:13
Speaker 2: faites-le avant d'en avoir besoin, pas lorsqu'un déploiement est bloqué
13:16
Speaker 2: à 2h du matin. Ensuite vient le dimensionnement des sous-réseaux,
13:18
Speaker 2: un point délicat car irréversible après coup. AKS réserve des
13:22
Speaker 2: adresses IP par nœud et chaque nœud a besoin d'un
13:24
Speaker 2: certain nombre d'IP pour les pods. Si votre sous-réseau est
13:27
Speaker 2: trop petit, vous manquerez d'adresse et vous ne pourrez pas
13:29
Speaker 2: l'éteindre une fois le cluster créé. En conséquent, prévoyez la croissance.
13:32
Speaker 2: Si vous pensez avoir besoin de 10 nœuds aujourd'hui, provisionnez
13:34
Speaker 2: suffisamment d'IP pour 50. Un sous-réseau en 64 offre 250
13:37
Speaker 2: IP utilisables, ce qui constitue un bon point de départ
13:40
Speaker 2: pour la plupart des clusters. Image pullback off est probablement
13:43
Speaker 2: l'erreur de pod la plus courante. Votre pod tente de
13:46
Speaker 2: récupérer une image de conteneur et échoue. Il s'agit généralement
13:49
Speaker 2: d'un problème d'authentification. Votre cluster ne parvient pas à accéder
13:51
Speaker 2: au registre de compte. Peut-être utilisez-vous un registre privé sans
13:54
Speaker 2: identifiant où ces derniers ont expiré. Vérifiez vos secrets de
13:57
Speaker 2: récupération d'images, assurez-vous que le compte de service a accès
13:59
Speaker 2: au registre et vérifiez que le nom de l'image est correct.
14:01
Speaker 2: Il s'agit rarement d'un bug de Kubernetes. Crash loop back-off,
14:03
Speaker 2: qu'est une autre erreur fréquente. Votre pod démarre, tourne quelques secondes, plante, redémarre,
14:07
Speaker 2: puis replante. L'instinct naturel est de blâmer Kubernetes, mais ne
14:11
Speaker 2: le faites pas. 9 fois sur 10, c'est votre application.
14:13
Speaker 2: Une variable d'environnement mal configurée, une dépendance manquante ou une
14:16
Speaker 2: chaîne de connexion à la base de données pointant vers
14:18
Speaker 2: le mauvais serveur, Vérifiez les journaux du pod avec Ubectum.
14:21
Speaker 2: Le message d'erreur s'y trouve généralement. Et puis, il y
14:23
Speaker 2: a l'épuisement des connexions sortantes. Vos applications établissent de nombreuses
14:26
Speaker 2: connexions vers des services externes, des API, des bases de
14:29
Speaker 2: données ou des outils tiers. Chaque connexion utilise un port
14:32
Speaker 2: SNAT et chaque nœud dispose d'un nombre limité de ces ports.
14:35
Speaker 2: Lorsqu'ils sont épuisés, les nouvelles connexions échouent silencieusement. Votre application
14:38
Speaker 2: semble saine, mais elle ne peut rien atteindre en dehors
14:40
Speaker 2: du cluster. La solution consiste à passer à Azure NAT Gateway,
14:43
Speaker 2: qui gère bien mieux le nombre élevé de connexions que
14:45
Speaker 2: l'équilibre de charges par défaut, ou à utiliser des nœuds
14:47
Speaker 2: plus grands offrant plus de ports SNAT. Tous ces éléments
14:50
Speaker 2: ont un coût. Alors, voyons ce que vous allez réellement payer.
14:53
Speaker 2: Coût de tarification. Alors, combien coûte réellement AKS? Soyons clairs.
14:57
Speaker 2: La majeure partie de votre facture provient des machines virtuelles,
14:59
Speaker 2: des noeuds de travail, du calcul, du stockage et du réseau.
15:02
Speaker 2: C'est là que parle l'essentiel de votre argent. Un noeud
15:03
Speaker 2: D2S V3 dans la région Est des Etats-Unis coûte environ
15:05
Speaker 2: 70 dollars par mois. 5 noeuds, 350 dollars. 10 noeuds,
15:10
Speaker 2: 700 dollars. Ces coûts de machines virtuelles grimpent vite. Le
15:13
Speaker 2: plan de contrôle propose 3 niveaux de tarification. L'offre gratuite
15:15
Speaker 2: vous donne accès au plan de contrôle sans surcoût, mais
15:17
Speaker 2: sans garantie de niveau de service. L'offre standard coûte environ
15:19
Speaker 2: 72 dollars par mois et par cluster, avec un SLA
15:22
Speaker 2: de 80 in-the-fugue et 80 kamso-sans sur le serveur API API.
15:26
Speaker 2: L'offre premium est à environ 432 dollars par mois et
15:28
Speaker 2: ajoute un support à long terme pour les versions de Kubernetes.
15:31
Speaker 2: Pour la plupart des charges de travail en production, le
15:33
Speaker 2: niveau standard est idéal, mais vous pouvez réduire ses coûts
15:35
Speaker 2: de VM. Les instances réservées permettent de s'engager sur un
15:38
Speaker 2: ou trois ans, économisant jusqu'à 72% par rapport au paiement
15:40
Speaker 2: à l'usage. Si vous connaissez votre capacité de base, les
15:43
Speaker 2: nœuds qui doivent toujours tourner, les réserver est une évidence.
15:47
Speaker 2: Les plans d'épargne Azure fonctionnent de manière similaire, mais offrent
15:49
Speaker 2: plus de flexibilité entre différentes familles de VM. Vous engagez
15:52
Speaker 2: sur une dépense horaire et Azure applique la remise automatiquement.
15:55
Speaker 2: Les économies peuvent atteindre 65 francs. Les VM spots sont
15:57
Speaker 2: l'option la moins chère, jusqu'à 90% de réduction. Mais il
15:59
Speaker 2: y a une condition. Azure peut récupérer cette capacité à
16:02
Speaker 2: tout moment. Vos nœuds sont expulsés et vos pods sont reprogrammés.
16:06
Speaker 2: Cela convient bien aux travaux par lot, aux exécuteurs CI
16:08
Speaker 2: sans état, beaucoup moins pour votre API de production. L'optimisation
16:12
Speaker 2: des coûts ne se résume pas aux remises. Dimensionnez correctement
16:14
Speaker 2: vos nœuds. Ne provisionnez pas une VM à 16 cœurs
16:16
Speaker 2: quand vos potes n'en utilisent que 2. Utilisez l'autoscale et
16:18
Speaker 2: le cluster pour ne pas payer de nœuds inutilisés en
16:20
Speaker 2: période de faible trafic. Pour les charges de travail à
16:22
Speaker 2: faible CPU, envisagez les VM de série B. Elles sont
16:25
Speaker 2: extensibles et nettement moins chères que la série D. N'oubliez
16:27
Speaker 2: pas non plus le stockage et le transfert de données.
16:29
Speaker 2: Les volumes persistants augmentent la facture. Azure Disk est rapide,
16:32
Speaker 2: mais coûteux. Azure Files est moins cher, mais plus lent.
16:35
Speaker 2: Faites votre choix selon les besoins de performance de votre
16:36
Speaker 2: charge de travail. La sortie de données, le trafic qui
16:39
Speaker 2: tend Azure, coûte également de l'argent. Gardez votre trafic au
16:42
Speaker 2: sein de la même région autant possible. Alors, quand AKS
16:44
Speaker 2: est-il réellement pertinent? Parlons de conseils concrets. Quand devriez-vous utiliser AKS?
16:49
Speaker 2: AKS excelle avec l'architecture en microservices. Vous avez plusieurs services
16:52
Speaker 2: indépendants qui doivent évoluer séparément. Le front-end peut nécessiter 10
16:55
Speaker 2: réplicas aux heures de pointe, tandis que le back-end n'en
16:57
Speaker 2: demande que 3. AKS gère cela naturellement. Chaque service évolue
17:02
Speaker 2: indépendamment en fonction de son propre trafic. La haute disponibilité
17:05
Speaker 2: est un autre argument majeur. AKS distribue vos pods sur
17:07
Speaker 2: plusieurs nœuds. Si un nœud échoue, les pods sont reprogrammés
17:10
Speaker 2: sur des nœuds sains, Pour les applications qui doivent être
17:16
Speaker 2: opérationnelles 24h et 24h, 24h c'est presque. L'intégration CICD est
17:19
Speaker 2: là où AKS devient vraiment rentable. Vous créez votre image
17:22
Speaker 2: de conteneur, l'envoyez vers un registre et AKS déploie la
17:25
Speaker 2: nouvelle version par mise à jour progressive. Aucun temps d'arrêt.
17:28
Speaker 2: Si quelque chose ne va pas, vous annulez les changements.
17:29
Speaker 2: Fini les connexions SSH manuel et le copier-coller de fichiers.
17:32
Speaker 2: Le pipeline s'occupe de tout. Mais AKS n'est pas toujours
17:34
Speaker 2: la solution idéale. Si vous avez une application monolithique simple
17:37
Speaker 2: sur une seule VM, AKS ajoute de la complexité sans
17:40
Speaker 2: réel avantage. Vous géreriez Kubernetes juste pour le plaisir de
17:43
Speaker 2: le gérer? Parfois, une VM, un service d'application ou même
17:46
Speaker 2: Azure Functions est un choix plus simple et moins coûteux.
17:48
Speaker 2: Si vous débutez, utilisez le niveau gratuit. Créez un cluster,
17:51
Speaker 2: déployez une application de test, faites des erreurs et corrigez-les.
17:54
Speaker 2: Apprenez les concepts sans vous soucier des coûts. Quand vous
17:56
Speaker 2: serez prêt pour la production, passez au niveau standard. Faisons
17:58
Speaker 2: le point. Voici ce que vous devez retenir. AKS occupe
18:02
Speaker 2: de 4 choses majeures. Microsoft gère le plan de contrôle,
18:04
Speaker 2: le cerveau du cluster. Vous choisissez la taille et le
18:07
Speaker 2: nombre de nœuds, les VM de travail et AKS gère
18:09
Speaker 2: les poules et le dimensionnement. Pour le réseau, les pods
18:12
Speaker 2: communiquent entre eux et avec l'extérieur via Azure CNI qu'AKS
18:15
Speaker 2: intègre pour assurer le fonctionnement. Les outils de sécurité sont intégrés. Identité,
18:19
Speaker 2: isolation réseau, durcissement des pods. Vous ne payez que pour
18:23
Speaker 2: le calcul, les nœuds, le stockage et le réseau. Le
18:25
Speaker 2: plan de contrôle lui-même est gratuit avec le niveau gratuit.
18:27
Speaker 2: Vous n'avez besoin du niveau standard ou premium que pour
18:29
Speaker 2: le SLA ou un support à long terme. Votre prochaine étape,
18:33
Speaker 2: créer un cluster AKS gratuit dans le portail Azure. Déployer
18:35
Speaker 2: une application de test simple, NGINX ou un conteneur Hello World.
18:39
Speaker 2: Voyez comment ça marche, cassez-le et réparez-le. Cette expérience pratique
18:41
Speaker 2: vaut mieux que n'importe quel tutoriel. Si cet épisode vous
18:44
Speaker 2: a aidé, abonnez-vous pour d'autres explications Azure simples et partagez-le
18:48
Speaker 2: avec quelqu'un qui débute dans le cloud. Nous vous remercierons
18:50
Speaker 2: plus tard.