Toute l'actualité devOps

🗞 Actus DevOps est ton #podcast de veille #DevOps et #Cloud mensuel. 👕 DevOps addict ? 🔥 Montre-le avec swag ! : https://bref.lydra.fr/cddgoodies Faute de place les liens sont sur l'article de blog. https://lydra.fr/blog/ca-bouge-chez-hashicorp-actus-devops-janvier-2024 Sommaire 00:00 Intro - Mon bilan 2023 : https://youtube.com/live/MI2pnlBMYt0?feature=share 01:04 Vos messages ❓ Pose-nous une question : http://question.compagnons-devops.fr 10:58 Sortie de Rudder 8 23:28 Sponsor : Accélérateur GitLab ⚡️ Accélère ton apprentissage de Git et GitLab https://bref.lydra.fr/accelerateur-gitlab 25:38 Rachat de VMWare par Broadcom 43:48 Cisco achète Isovalent 54:43 Les news d'HashiCorp 1:11:11 Nos outils - **Glance** : te permet de surveiller vos performances. https://nicolargo.github.io/glances - **Crane** : est un outil dédié à la manipulation d'images de conteneur. https://github.com/google/go-containerregistry - **Reaction** : est une alternative à fail2ban. https://linuxfr.org/news/reaction-remplacant-de-fail2ban - **Huh** : est une bibliothèque de prompt interactif en Go. https://github.com/charmbracelet/huh - **Termtris** : te permet de jouer à Tetris dans un terminal. https://github.com/jtsiomb/termtris && https://twitter.com/wesley974/status/1737732382961348995 1:26:55 Clôture 💬 Rejoins la communauté sur le forum : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - Nidouille sur les réseaux. Tous ses liens : http://labperso.ovh - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Nicolas Ledez : devops chez CGWire. Il travaille dans l'IT depuis 20 ans. Il est "Schizophréne" : adminsys et développeur suivant le moment de la journée. Il paraît que ça s'appelle "devops", même si il déteste mettre ce nom sur un poste. Découvre le : https://lydra.fr/ea-8-le-podcasteur-nicolas/ | LinkedIn : https://www.linkedin.com/in/nicolasledez | Twitter : https://twitter.com/nledez | Github : https://github.com/nledez | Le reste : https://nicolas.ledez.net ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Image de Mitchell Hashimoto (HashiCorp) 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #Podcast #Rudder #Hashicorp #VMWare #Cilium Vidéos similaires : https://youtu.be/MCwMd1R4XyA?si=6OBncIM-D7cEdjyl https://youtu.be/JA-NSCnF3nQ?si=i66qN3ZHAre2Vjw2 https://youtu.be/NRb0Irk7OO8?si=N1WJ4QEujagTnfIL https://youtu.be/YGy-P3neoCw?si=F2nylRZjweLc4Wi8 https://youtu.be/S9d9YYEcfCo?si=b8o3jNscQxxz12K0 https://youtu.be/L5_pr7ox5Jo?si=v4_r-PwSFpfKuHNU https://youtu.be/He2v0Ot4OWc?si=ElQY7k0U9wVoB2jL Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://youtu.be/nQEzYiZRBds?si=rbRWPcMe3ZpvQVTo

📊 Les mise à jour Kubernetes vont-elle être plus simple ? 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ➡️ Extrait d'Actus DevOps de décembre 2023 L'épisode complet : https://youtu.be/91oj80WD_xQ - https://www.silicon.fr/kubernetes-lts-473943.html - https://matduggan.com/why-kubernetes-needs-an-lts/ - https://news.ycombinator.com/item?id=38516717 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Erwan Ben Soudien : DevOps chez Scaleway (ex Toucan Toco, Deezer, Antelink, Weborama - ex sysadmin ) - professeur vacataire à Paris XIII / IUT Creteil. Découvre le : https://lydra.fr/ea-2-le-podcasteur-erwan/ | Linkedin : https://www.linkedin.com/in/erwan-ben-souiden-8b8084152 - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Image de vectorjuice : https://www.freepik.com/free-vector/engineers-consolidating-structuring-data-center-big-data-engineering-massive-data-operation-big-data-architecture-concept-bright-vibrant-violet-isolated-illustration_10780533.htm 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #kubernetes

Découvrez comment le Minisforum NB6 transforme les homelabs DevOps grâce à ses performances élevées et sa polyvalence.

Découvrez comment X-Pipe simplifie la gestion des connexions shell et des fichiers à distance, y compris les containers.

Découvrez comment le Minisforum nab6 transforme les homelabs DevOps grâce à ses performances élevées et sa polyvalence.

Guide complet sur ASSH pour une gestion avancée des configurations SSH.

Un tour d'horizon complet d'OpenTofu 1.6.0, le fork open-source de Terraform.

🚀 Et si tu gérais ton propre cloud avec le logiciel open source ProxMox ? 💬 Rejoins les Compagnons du DevOps : https://www.compagnons-devops.fr ## Sommaire 00:00 Introduction 02:01 Qui est Valentin Ouvrard ? 03:18 Sa définition du DevOps 05:23 Sa rencontre avec le DevOps 06:39 ProxMox comme solution Cloud privée 09:19 Pourquoi choisir ProxMox ? 15:23 Utiliser Terraform avec ProxMox 22:54 Interface Web d'administration des VM - Le projet Sauron sur GitLab : https://gitlab.com/nautile.nc/sauron 27:50 Comment gérer un gros agregat ProxMox ? 32:26 Ceph et Proxmox - https://rook.io/ 42:19 Hyperconvergence avec ProxMox et Ceph 47:20 Son entreprise Ops.nc Les réseaux de Valentin - https://ops.nc/ - X/Twitter : https://twitter.com/valentin_ops - LinkedIn : https://www.linkedin.com/in/valentin-ouvrard-57823aa7 50:25 Ses ressources conseillés - Linux bible : https://www.wiley.com/en-us/Linux+Bible%2C+10th+Edition-p-9781119578895 - Un talk sympa de Kelsey Hightower : https://youtu.be/U6SfRPwTKqo?si=yDRZS1pCyFQLES_t 💬 Rejoins la communauté sur le forum : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 📩 Si tu n'es pas déjà abonné, alors **abonnes-toi** pour ne pas rater les prochaines vidéos. ❓ Pose-nous une question : http://question.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- Bienvenue, chez les compagnons sur **Radio DevOps**. La Baladodiffusion des **Compagnons du DevOps**. Le podcast en français dédié à notre mouvement. Nos émissions : - **🗞 Actus Devops :** est une émission animée par des membres de la communauté des Compagnons du DevOps. Dans chaque épisode nous étudierons l'actualité Cloud et DevOps. - **📻 Radio DevOps :** est l'émission phare animée par des membres de la communauté des Compagnons du DevOps. Dans chaque épisode nous débattrons sur un sujet de fond. - **🛋 En aparté :** est une émission où je m'entretiendrai avec un invité sur le mouvement DevOps en entreprise. - **🎙️ En Solo  :** est une émission où je serai seul pour vous parler de DevOps ou de Cloud. 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater ces émissions. --- ## Crédits Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur de l'association [Bed Food Coffee](https://www.bedfoodcoffee.com/) et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. L'image est généré avec DALL·E 3 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #Podcast #DevOps #Proxmox #terraform #Ceph Vidéos similaires : https://youtu.be/-haxDKIOEao https://youtu.be/jiV4R4-DyMY https://youtu.be/dvyeoDBUtsU https://youtu.be/h8151t8lP5c https://youtu.be/dvyeoDBUtsU https://youtu.be/OkJAPc9Xo5Q https://youtu.be/1nf3WOEFq1Y Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

📰 Ça bouge chez AWS et OVHCloud ! 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr ➡️ Extrait d'Actus DevOps de décembre 2023 L'épisode complet : https://youtu.be/91oj80WD_xQ - https://next.ink/118670/reinvent-2023-amazon-lance-son-assistant-q-et-plusieurs-services-ia-dont-la-generation-dimages/ - https://www.aboutamazon.com/news/aws-reinvent-2023-live - https://next.ink/118176/ovhcloud-summit-2023-secnumcloud-ia-et-local-zones/ 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset ## Crédits ### Les podcasteurs - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - DamyR : SRE chez Waays / DevOps, passionné d'open source & de logicel libre, :man_teacher: professeur vacataire à l'université Léonard de Vinci. Son credo : "*La connaissance n'a de valeur que si elle est partagée*" ;-). Découvre le : https://lydra.fr/ea-1-le-podcasteur-damyr/ | Linkedin : linkedin.com/in/tgerardin/ | Twitter : https://twitter.com/damyr_fr | Blog : https://www.damyr.fr - Erwan Ben Soudien : DevOps chez Scaleway (ex Toucan Toco, Deezer, Antelink, Weborama - ex sysadmin ) - professeur vacataire à Paris XIII / IUT Creteil. Découvre le : https://lydra.fr/ea-2-le-podcasteur-erwan/ | Linkedin : https://www.linkedin.com/in/erwan-ben-souiden-8b8084152 - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ ### Habillage sonore - L'intro et la fin sont de Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Image de  rawpixel.com : https://www.freepik.com/free-photo/white-woman-using-computer-cloud-network_2894248.htm 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #ovhcloud #AWS

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Code source : https://gitlab.com/xavki/k8s-vagrant Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

Contrairement à ce que l’on pourrait penser, je suis rarement "hypé" par des outils. Mais parfois ça arrive, et c’est le cas pour Karpenter qui est en train de révolutionner la gestion des noeuds sur Kubernetes. Le monde avant Karpenter Les conteneurs (pods) gérés par Kubernetes tournent sur des workers (généralement des machines virtuelles). Gérer ces workers peut rapidement devenir pénible pour plusieurs raisons. Sur la majorité des offres Kubernetes dans le cloud (mais aussi sur des implémentations on prem) une abstraction "nodepool" existe, représentant un groupe de machines similaires. On choisit par exemple pour un nodepool les caractéristiques des machines à lancer (nombre de CPU, mémoire, image), la configuration réseau (firewalling, réseau privé), la taille du disque root, et toutes sortes d’options selon le cloud provider (IAM, clés SSH, configuration de cloud init…​). Toutes les instances du Nodepool sont donc identiques. Une fois un nodepool créé, il est possible de configurer sa taille (et donc le nombre de workers à déployer pour ce nodepool) et de la changer à tout moment (manuellement ou via des outils d’autoscaling). Le problème qui se pose rapidement est la multiplication du nombre de nodepools à gérer, par exemple: Avoir des nodepools avec des types d’instances (CPU, mémoire, disques, AMI, génération d’instances…​) différents dans le but de faire tourner certains workloads gourmands sur des noeuds dédiés: un nodepool avec des machines 4CPU/16GB de mémoire, un autre 8CPU/32GB…​ Avoir des nodepools utilisant des instances de type "spot" (comme par exemple chez AWS): dans ce cas de figure on veut maximiser l’utilisation d’instances spot pour faire baisser la facture cloud tout en démarrant des instances classiques en cas de non disponibilité des spot. Faire du multi availability zone (AZ): cela peut demander la création d’un nodepool par availability zone pour chaque type de nodepool. On se retrouve donc rapidement avec 3, 6, 10…​ nodepools par cluster et cela devient difficile à gérer: il faut les gérer via de l’infra as code (Terraform par exemple) et donc de manière assez statique et il faut les mettre à jour un par un lors de mise à jour de clusters ou d’AMI. Faire des économies via un placement intelligent des pods devient également compliqué car tout doit être fait "à la main": je me rappelle par exemple lorsqu’on avait de multiples groupes de machines du type "memory optimized", "high memory optimized" dupliqués par AZ pour faire tourner certaines applications gourmandes: on avait toujours des noeuds sous utilisés. Gérer le cycle de vie des noeuds peut également être assez pénible: On utilise généralement le cluster autoscaler de Kubernetes pour l’autoscaling des noeuds. Il fonctionne globalement bien mais est assez basique dans son fonctionnement. Lorsqu’un noeud est supprimé (downscaling, mise à jour…​) il faut d’abord drain les pods sur le noeud et seulement ensuite le supprimer. Sur le cloud et notamment lorsqu’on utilise des instances spot on veut aussi parfois préventivement supprimer un noeud qui risque d’être réclamé par le cloud provider dans un futur proche. Sur AWS cela se fait via une gestion d’événements poussés dans une queue SQS et l’utilisation d’un composant supplémentaire à déployer (AWS node termination handler). AIlleurs, c’est souvent à vous de construire l’outillage pour le faire. Karpenter Karpenter est un outil open source développé par AWS pour répondre à la problématique de gestion des workers dans Kubernetes. L’outil s’est longtemps limité à la gestion de noeuds sur AWS, mais son architecture modulaire (une partie "core" et une "plugin" pour les intégrations spécifiques à chaque cloud provider) et la qualité de l’outil font qu’il est en train de prendre de l’ampleur. L’outil autrefois géré sur le compte github d’AWS a maintenant rejoint la communauté Kubernetes (sigs autoscaling), et Microsoft Azure vient également de le rendre disponible sur son cloud. Pour moi, Karpenter est le futur de la gestion de noeuds sur Kubernetes, et va dans les prochaines années complètement remplacer cluster-autoscaler. Je vais expliquer pourquoi en expliquant rapidement comment fonctionne Karpenter sur AWS. En pratique Karpenter est un operator Kubernetes et doit donc s’installer sur le cluster (via helm par exemple), ou du moins communiquer avec l’apiserver pour pouvoir gérer les noeuds. AWS sortira d’ailleurs Karpenter en tant qu’Addons complètement géré par AWS dans les mois à venir. Il se configure ensuite via des CRD spécifiques comme n’importe quel operator Kubernetes. Sur AWS, on utilisera les ressources EC2NodeClass (spécifiques à AWS) et NodePool (générique). Je présume que sur Azure EC2NodeClass serait remplacé par une autre CRD, et que dans le futur chaque cloud (ou outil déployant du Kubernetes on prem avec une intégration Karpenter) aura sa CRD dédiée. EC2NodeClass Voici un exemple d’EC2NodeClass appelé example: apiVersion: karpenter.k8s.aws/v1beta1 kind: EC2NodeClass metadata: name: example spec: amiFamily: AL2 blockDeviceMappings: - deviceName: /dev/xvda ebs: encrypted: true volumeSize: 70Gi volumeType: gp3 metadataOptions: httpEndpoint: enabled httpPutResponseHopLimit: 1 httpTokens: required role: karpenter-example-iam-role securityGroupSelectorTerms: - id: sg-1cb731bc101ab1e3f - id: sg-2a3fa43a111ab1a54 subnetSelectorTerms: - tags: Name: kubernetes-* tags: Name: example-karpenter environment: production managed-by: karpenter userData: | #!/bin/bash echo "optional cloud init user data" Cette ressource représente la configuration AWS d’un worker: l’AMI à utiliser: ici, on se contente de spécifier la famille d’AMI à utiliser (AL2, Amazon Linux 2 ici). Karpenter prendra automatiquement l’AMI la plus récente pour la version du cluster Kubernetes cible, mais il est également possible de spécifier l’image exacte à configurer. La configuration du disque racine (taille, chiffrement, storage class…​). Des options liées au serveur de metadata de l’instance. Le role à attacher à l’instance (sur AWS on configure généralement très finement les permissions de chaque machine notamment sur EKS). Les security groups (règles de firewalling) à attacher à l’instance. Il est possible de choisir ces security groups par ID (ce que je fais dans cet exemple), par nom, par tags (et donc d’inclure tout ceux avec un tag donné), ou une combinaison de tout ça. Les subnets de réseaux privés (VPC) à utiliser pour la machine (là aussi la sélection peut se faire via différents critères). Des tags à attacher aux machines. Des user data pour avoir si besoin une configuration cloud init spécifique. Comme dit précédemment tout ceci est assez spécifique à AWS mais on retrouvera des choses similaires dans d’autres implémentations futures de Karpenter sur l’autres plateformes. En conclusion, vous définissez ici à quoi doit ressembler la partie "infra" de vos noeuds via un simple fichier YAML. Voyons maintenant la partie NodePool. NodePool La CRD NodePool représente un groupe de noeuds et permet de lier une NodeClass avec une gestion de cycle de vie des noeuds. Si le scheduler de Kubernetes n’arrive pas à éployer un pod par manque de capacité, Karpenter sélectionnera un NodePool qui par sa configuration pourrait accueillir le pod et et créera un nouveau noeud. Karpenter s’occupera également de tout l’aspect autoscaling (donc cluster autoscaler n’est plus nécessaire) et comme nous allons le voir, de bien plus. Voici un exemple de NodePool: apiVersion: karpenter.sh/v1beta1 kind: NodePool metadata: name: example spec: disruption: consolidationPolicy: WhenUnderutilized expireAfter: 24h0m0s limits: cpu: "400" template: metadata: labels: purpose: example spec: nodeClassRef: name: example requirements: - key: karpenter.k8s.aws/instance-category operator: In values: - c - m - r - key: kubernetes.io/arch operator: In values: - amd64 - key: karpenter.sh/capacity-type operator: In values: - spot - on-demand - key: kubernetes.io/os operator: In values: - linux La première chose très intéressante dans la configuration d’un NodePool est la partie disruption. Ici, la partie consolidationPolicy indique à Karpenter d’optimiser continuellement le placement des pods sur le cluster pour utiliser le moins de ressources (et donc de noeuds) possibles. Rien que ça est génial et permet de faire baisser de manière non négligeable votre facture cloud, et d’avoir un taux d’occupation de vos noeuds Kubernetes très important ! Encore mieux, Karpenter fera également en sorte d’utiliser les noeuds disponibles sur le cloud les moins chers, mais j’en reparlerai juste après. L’option expireAfter permet d’ajouter un TTL sur les noeuds. Ici, les noeuds seront automatiquement recyclés (supprimés et recréés) toutes les 24 heures. Cela apporte de nombreux avantages: Les noeuds se mettent à jour tout seul, que ce soit en cas de nouvelle version de l’image (AMI) référencée par la NodeClass, ou en cas de mise à jour du cluster Kubernetes à une nouvelle version. On a une vraie approche "infrastructure immuable" sur la gestion des noeuds, qui sont vraiment des ressources jetables et remplaçables à tout moment. Cela force tous les utilisateurs du cluster Kubernetes (dev comme ops) à construire des programmes et des architectures pouvant supporter un recyclage permanent des noeuds. Lorsque l’on fait un recyclage des noeuds que tous les 3 mois par exemple, on a tendance à ne pas voir certains problèmes applicatifs sous-jacents: applications tolérant mal le drain de ses pods, problèmes réseaux transitoires causant de la perte de traffic…​ Tout péter toutes les 24H met très rapidement en évidence des problèmes et donc force les gens à les corriger, ce qui améliore grandement la résilience des applications de manière générale. D’ailleurs ce pattern est clairement génial, qu’on soit sur Kubernetes ou non. La partie limits de la spec permet de mettre une limite sur la capacité totale du NodePool. Ici, la somme des CPU des machines gérées par ce NodePool ne pourra pas dépasser 400. C’est intéressant pour éviter de scale à l’infini un NodePool. La configuration template.metadata contiendra des labels (et annotations si besoin) à propager aux noeuds créés. Enfin, la partie template.spec.requirements permet de définir des conditions pour les noeuds qui seront provisionnés. Dans cet exemple, que des machines des classes d’instances c, m, et r d’AWS (via karpenter.k8s.aws/instance-category), des instances amd64 (via kubernetes.io/arch), des instances spot ou on demand (via karpenter.sh/capacity-type) et enfin des instance Linux (kubernetes.io/os) pourront être démarrées par ce NodePool. Il existe de nombreux autres requirements possibles qui sont listés dans la documentation de Karpenter. On peut par exemple ajouter une taille maximum (en terme de CPU/mémoire) ou minimum pour les noeuds. Cette CRD permet également de configurer des taints sur les noeuds gérés par un NodePool, ainsi que la configuration de Kubelet. J’avais expliqué précédemment que Karpenter essaye d’optimiser le déploiement des noeuds pour que cela coûte le moins cher possible via la consolidation. Dans cet exemple, Karpenter essayerait par exemple de démarrer en priorité des instances "spot", ou bien tentera en permanence de créer des workers optimisés pour les workloads. La chose importante à garder en tête est les noeuds d’un NodePool Karpenter peuvent avoir différentes tailles (ce qui n’est généralement pas le cas sans Karpenter). Si Karpenter détecte que le plus rentable en terme de prix (facture cloud) est d’avoir un noeud avec 64 GB de mémoire et 16 CPU et 3 noeuds de 32 GB de mémoire et 8 CPU pour les pods tournant sur le cluster, le tout faisant partie d’une certaine catégorie d’instances, c’est ce qu’il déploiera. Au bout d’un moment, peut être qu’il remplacera les 3 noeuds par 2 noeuds plus gros, en spot par exemple, car moins cher. L’infrastructure est donc très dynamique car en permanence modifiée pour optimiser la facture. Vous n’avez donc pas à créer beaucoup de Nodepool Karpenter comme c’était le cas avant pour les Nodepool "non Karpenter" (où on créeait un NodePool par taille de macine à déployer sur le cluster). On se contente de laisser Karpenter créer les meilleures instances (bonne taille, coût le moins cher…​) pour nos workloads, et des pods très disparates en terme d’utilisation de ressources cohabiterons sans problème sur le même NodePool. Drift Une fonctionnalité intéressante des NodePool Karpenter est également la gestion du drift, qui se configure dans la partie disruption de la CRD. En cas de changement de configuration d’un NodePool ou NodeClass, si les workers actuels (ou un subset d’instances) ne sont plus valides en terme de configuration, Karpenter les recréera automatiquement car il détectera que l’instance n’est plus valide. Après, si vous mettez expireAfter à 24 heures comme dans cet exemple, juste attendre peut être suffisant: après un jour toutes les instances seront forcément mises à jour. On peut également tout simplement supprimer un noeud de manière sûre via kubectl delete node grâe à Karpenter: ce dernier s’occupera de drain le noeud et d’en démarrer un nouveau si nécessaire. Précautions à prendre Comme dit précédemment, Karpenter passera son temps à supprimer et recréer des noeuds (TTL sur les noeuds, consolidation, drift…​). Il faut donc que les applications tolèrent ça mais c’est de toute façon obligatoire d’avoir des applications "cloud native" sur Kubernetes, ou même ailleurs. Il faudra également configurer correctement des PodDisruptionBudget sur vos pods. Sans cela, vous n’aurez pas de garantie sur le nombre minimum de replica "up" pour par exemple un déploiement. Karpenter comprend nativement toutes les primitives de Kubernetes (PDB, affinity et anti affinity, Topology Spread Constraints…​). Enfin, ajouter l’annotation karpenter.sh/do-not-disrupt: "true" sur un pod indiquera à Karpenter de ne jamais supprimer le noeud où tourne le pod. Il ne faut bien sûr pas ajouter cela sur un pod tournant en continu (type déploiement), sinon le noeud ne pourra jamais se mettre à jour. Mais elle est très utile sur les pods générés par des Jobs (et donc aussi CronJob): cela permettra à Karpenter d’attendre la fin d’un job avant de supprimer un noeud, et de ne pas l’interrompre en plein milieu. Conclusion Il y a eu pour moi un avant et un après Karpenter dans mon utilisation de Kubernetes. C’est comme dans le cochon, tout est bon dans le produit. Je pense qu’il va vraiment prendre de l’ampleur dans la communauté Kubernetes ces prochaines années et qu’avoir une intégration Karpenter sera vraiment un différentiateur entre offres Kubernetes, notamment sur le cloud mais pas que: pourquoi ne pas écrire des plugins Karpenter pour l’on prem également ? Lien vers la doc officielle de Karpenter si vous souhaitez creuser le sujet

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Sources : - chicago bulls theme allan parsons project :https://www.youtube.com/watch?v=pWBXBo7ZH-E - Electric Romeo (No Choir) : https://www.youtube.com/watch?v=1onvcuzzqCc Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃