DEV Community: Λ\: Laurent Noireterre

Cloud : un peu d’ARM avec votre cluster Kubernetes ?

Λ\: Laurent Noireterre — Mon, 06 May 2024 12:10:04 +0000

La majorité des clouds providers proposent des solutions basées sur des architectures processeurs ARM, tel que Graviton chez AWS ou Tau T2A chez GCP. Les avantages de tels processeurs sont multiples : efficacité énergétique, couts réduits, performances… Ils sont de plus tout à fait adaptés aux environnements conteneurisés.

Exécuter vos workloads Kubernetes sur des processeurs ARM parait donc être un bonne idée. Cela rentre aussi dans une approche FinOps, car l’utilisation de processeurs arm en lieu et place de processeurs x86 va permettre des réductions de coûts non négligeables (de l’ordre de 20% avec des processeurs Graviton) à performances égales voire supérieures.

Si la mise en place d’une architecture arm peut paraitre assez simple sur de nouveaux clusters, qu’en est-il de la migration d’une architecture existante amd64 vers une architecture arm64 ?

Considérations

Avant de se lancer dans la migration vers une architecture arm, quelques considérations sont à prendre en compte vis-à-vis des applications qui tournent sur votre cluster.

Langages et librairies

La majorité des langages supportent maintenant des architectures ARM. Les langages interprétés (NodeJS, Python…) ou byte-code compilés (Java, .Net) devraient fonctionner sans modifications majeures. Attention cependant si vous utilisez des librairies ou fragments de codes natifs (JNI), une recompilation sera necessaire.

Les langages compilés (C/C++, Go…) supportent pour la plus grande majorité les architectures ARM mais ils devront être recompilés.

Images Docker

De manière générale nos applications packagées pour s’executer dans des conteneurs utilisent une image de base (le FROM du Dockerfile). Attention à bien vérifier que cette image aussi supporte ARM. C’est le cas de la majorité des standards et cela peut se vérifier rapidement en se connectant sur le registry depuis lequel elles sont tirées. Par exemple pour l’image officielle OpenJDK sur Dockerhub, on remarque que les 2 types d’architectures sont bien supportées :

Services tiers

Des services tiers tels que Prometheus ou ArgoCD peuvent aussi tourner sur nos cluster Kubernetes afin d’assurer diverses taches (observabilité, déploiement, sécurité…). Il faudra donc s’assurer là aussi que ces services sont déployables sur une architecture ARM.

Système d’exploitation

Si vous utilisez des services cloud entièrement managés tel que EKS Fargate ou GKE Autopilot il n’y aura aucun impact. Par contre si vous avez des noeuds que vous managez vous-même, une migration du système d’exploitation sera nécessaire.

Construction : Docker multi-architecture

Maintenant que vous vous êtes assuré que vos applications sont bien éligibles à une plateforme arm, il s’agit de les reconstruire afin qu’elles puissent tourner sur ce type d’architecture.

Principe

La meilleure solution pour pouvoir instancier vos conteneurs sur une architecture ARM n’est pas d’effectuer un build de vos images pour ce type d’architecture spécifiquement, mais plutôt d’utiliser une méthode de build multi-architecture. Votre image sera alors construite en même temps et à partir de la même source (DockerFile) pour une liste d’architecture que vous aurez prédéfinie.

Cela permettra de déployer ces nouvelles images sur vos clusters nouvellement configurés avec des noeuds arm, mais aussi de pouvoir lancer indifféremment vos containers sur des architectures plus classiques type amd64 pour du développement ou des tests par exemple.

Ce sera le runtime de conteneur qui, au moment du pull, récupérera les layers de l’image correspondant au type d’architecture sur lequel il tourne :

Mise en place

Solution 1 : Docker buildx

Une approche courante pour construire des images Docker multi-architecture consiste à utiliser le plugin docker buildx (https://docs.docker.com/build/architecture/#buildx).

Ce plugin se base sur QEMU (Quick Emulator) pour construire des images multi-architectures. QEMU est un émulateur de processeur qui permet d'exécuter du code destiné à une architecture spécifique depuis un autre type d’architecture. Cela va permettre de construire des images Docker pour des architectures différentes de celle de l'hôte.

Concrètement, tout ce que vous aurez à faire est d’installer le plugin docker buildx (vérifier la compatibilité avec votre version de docker), et de lancer un build en listant les plateformes cibles :

docker buildx create --use --name mybuild node-amd64
mybuild
docker buildx create --append --name mybuild node-arm64
docker buildx build --platform linux/amd64,linux/arm64 .

Le build et le push de l’image peuvent se faire avec une seule et même instruction :

docker buildx build --tag my-user/my-image --platform linux/arm64/v8,linux/amd64 --push .

Pour plus de détails vous pouvez vous référer à la procédure Docker: https://docs.docker.com/build/building/multi-platform/

Solution 2 : Manisfest

Une seconde solution, plus complexe, est la méthode “Do It Yourself”. Elle consiste à une création manuelle du manifest d'image après avoir effectué 2 builds, un pour chaque type d’architecture.

Elle fait aussi intervenir 3 registres d’images, car chacune des images construites doit être poussée dans son propre registre avant d’être poussée une 3ème fois dans un registre multi-architecture.

Donc pour résumer :

1 - On construit et on pousse une image pour chaque architecture

# AMD64
$ docker build -t my-user/my-image-amd64 --build-arg ARCH=amd64/ .
$ docker push my-user/my-image-amd64

# ARM64V8
$ docker build -t my-user/my-image-arm --build-arg ARCH=arm64v8/ .
$ docker push my-user/my-image-arm

2 - On créé un manifeste à partir de chacune des images

docker manifest create \
my-user/my-image \
--amend my-user/my-image-amd64 \
--amend my-user/my-image-arm

3 - On pousse le nouveau manifest

docker manifest push my-user/my-image

Remarque : il est aussi possible de jouer sur les tags des différentes images pour n’utiliser qu’un seul registry

Cette solution peut être utile si vous construisez vos images avec un autre outils que Docker, tels que Kaniko ou Buildah.

Un post sur le blog de Docker détaille ces 2 méthodes: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Hosting : Cluster Kubernetes Hybride

Vous avez maintenant des images Docker multi-architectures capable de tourner indifféremment sur de l’amd64 ou de l’arm. Mais il est possible que pour une raison ou une autre, certaines de vos applications n’aient pas pu être construites pour architecture arm et que vous deviez donc conserver des noeuds type amd64 pour celles-ci.

Dans ce cas pas de panique, vous pouvez jouer sur les teintes et node selector (ou node affinity) de Kubernetes.

Je m’explique. Les clusters Kubernetes managés sont capables de gérer plusieurs groupes de noeuds, chacun de ces groupes pouvant s’appuyer sur des propriétés différentes (type d’instance, nombre d’instances…). Il est alors tout à fait possible de créer 2 groupes de noeuds distincts, l’un comportant des machines de type amd64 et l’autre de type arm. Pour garder la maitrise sur les workloads qui vont être déployés par la suite sur l’un ou l’autre groupe de noeuds, on appliquera une teinte sur l’un des groupes :

(Si vous n’êtes pas familier avec la notion de teinte et de node selector je vous invite à consulter à la documentation Kubernetes https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ et https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)

Par défaut tous nos pods seront ainsi déployés sur le node group arm. On utilisera alors un node selector ainsi qu’une tolération au niveau des pods que l’on souhaite assigner à un type d’architecture amd64.

tolerations:
- effect: NoSchedule
  key: node-arch-type
  value: amd64
nodeSelector:
  kubernetes.io/arch: amd64

Cela permet de continuer de faire tourner sans risque vos applications nos compatibles arm sur des noeuds amd64.

Remarque: on peut tout à fait envisager le mécanisme inverse, à savoir un déploiement par défaut sur des noeuds type amd64 (non teintés) et prévoir une sélection d’applications à déployer sur des noeuds type arm (grâce aux teintes et node selectors). Cela permet dans un cluster existant amd64, d’envisager une stratégie de migration de vos applications par lot.

Conclusion

Félicitations ! Vous avez maintenant un cluster Kubernetes capable d’héberger plusieurs types d’architectures, et des applications pouvant se déployer indifféremment sur l’une ou l’autre tout en gérant vous même cette répartition.

Ce type d'architecture de plus en plus répandu mérite vraiment de s'y intéresser, surtout dans le cas de la mise en place d'une nouvelle plateforme.

Pour ce qui est de la migration d'une plateforme existante, le ROI est de manière générale très intéressant mais une stratégie de migration doit impérativement être mise en place.

AWS Summit Paris 2024

Λ\: Laurent Noireterre — Fri, 12 Apr 2024 10:21:24 +0000

Article co-écrit avec Hicham Yahiaoui (Cloud Architect @Stack-Labs) et Yoann Metenier (Cloud Architect @Stack-Labs)

Keynote

La GenAI c’est génIAl

L'AWS Summit Paris 2024 s’est déroulée au palais des congrès. Le lieu était plus que nécessaire au vu du nombre de personnes présentes à cet évènement. Dès notre arrivée, et après avoir récupéré nos cartes d’accès, nous nous sommes installés dans le grand amphithéâtre afin d’assister à la Keynote d’ouverture.

Julien Groues (General Manager - Europe South, AWS) a effectué quelques présentations sur AWS en début de keynote pour ensuite laisser la main à Mai-Lan Tomsen-Bukovec (VP of Technology, AWS) qui est venu pour discuter des nouveautés 2024 AWS : la GenAI.

Tout au long de cette keynote de 1h30 plusieurs intervenants sont montés sur scène afin de présenter leurs besoins et utilisations de la GenAI sur AWS. Cependant, une annonce surprise a été effectuée en début de session : AWS x Mistal AI.
En effet le premier intervenant sur scène n’est autre que Arthur Mensch CEO de Mistral AI. Il est venu pour confirmer son partenariat avec AWS permettant aux utilisateurs de disposer de Mistral AI dans AWS Bedrock pour la région Europe ! Les versions disponibles sont : Mistral Large, Mistral 7B et Mistral 8x7B.
A la suite de cette annonce forte excitante, les intervenants suivants sont venu présenter leurs utilisation du cloud AWS pour dynamiser leur activité et enrichir l'expérience de leurs clients:

Fabien Mangeant (Chief Data and AI Officer, Air Liquide)
Thomas Wolf (Co-Founder, Hugging Face)
Raphaëlle Deflesselle (CTO, Groupe TF1)
Tom Brown (Co-Founder, Anthropic)

A la fin de la keynote, nous avons poursuivi notre périple AWS en participant à quelques conférences parmi les 175 disponibles et en discutant sur les stands des partenaires afin de découvrir des projets et utilisations de diverses solutions sur AWS. Nous avons choisi de vous présenter dans la suite de cet article 3 conférences auxquelles nous avons assisté.

Multi-régions Zéro latence avec Kubernetes, Couchbase & Qovery

Laurent Doguin (Developer Advocate Couchbase) et Romaric Philogène (CEO Qovery) nous ont fait le plaisir d’effectuer une présentation de l’intégration entre Couchbase et Qovery permettant de réduire et stabiliser une connexion BDD – Kubernetes dans un environnement multi-région sur AWS.

Un peu de contexte

Le temps d’attente de réponse d’une application peut provoquer une lassitude des utilisateurs d’autant plus à notre époque où nous sommes habitués à des services qui répondent rapidement. Nos interlocuteurs nous présentent les résultats d’une étude AWS qui dit :

100 ms de latence sur la page amazon.com = 1% de baisse des ventes
De manière générale :
- 2 secondes de chargement pour un site internet = 9% des utilisateurs abandonneront la navigation,
- 5 secondes de chargement pour un site internet = 38% des utilisateurs,
- 3 secondes de chargement via smartphone = 53% des utilisateurs

Le problème posé

Dans une architecture multi-région comment puis-je faire pour disposer d’un temps de lecture/écriture acceptable pour n’importe quel client indépendamment de sa localisation géographique ?
Nous pouvons représenter ce problème avec le schéma suivant :

Nous pouvons voir que dans cette situation les client aux Etats-Unis et en Asie dispose d’un temps de lecture et écriture nettement supérieur à ceux en Europe. Comme expliqué dans notre contexte, ce délai supplémentaire peut provoquer de la frustration et donc amener à une perte d’utilisateurs sur ces régions.

A la suite de cette mise en contexte, Laurent et Romaric ont proposé une solution de base souvent utilisée, appelée « active/passive ». Cette méthode consiste à déployer plusieurs instances d’application dans les différentes régions et d’utiliser des read réplicas pour les base de données (schéma ci-dessous).

Via cette solution nous constatons une nette amélioration concernant la lecture du contenu en base. Si la lecture représente la plus grande partie des actions réalisées par les clients, alors cette solution est viable. Mais quid de la situation où l'écriture est aussi un aspect important pour les clients ? Dans ce cas la solution basique devient non valide car nous disposons toujours d’un temps d’écriture très élevé pour les deux régions éloignées.

Plusieurs solutions se présentent alors :

Retravailler le modèle de données pour séparer les régions entre-elles et que chacune repose sur sa propre base de données (beaucoup de travail à faire et peut-être pas possible en fonction du modèle de données)
Utiliser un schéma plus horizontale avec la possibilité d’écrire/lire les données de chaque base de données correspondant à sa région et gérer un système de réplication de données (complexe à mettre en œuvre et gestion des conflits sur les données à gérer soi-même)
Utiliser la solution « active/active » proposé par Couchbase et Qovery afin de permettre à la fois de disposer de bases de données par région et synchronisées entre elles de manière efficace via Couchbase, mais également de disposer du gestionnaire de déploiement serverless des ressources et plateformes centralisé, Qovery, connecté aux instances Couchbase

Les présentateurs ont conclu leur conférence par la présentation de la solution (vous l’aurez deviné) N°3 : l’utilisation de Couchbase (Capella) et Qovery (schéma ci-dessous). Dans cette dernière, les utilisateurs de n’importe quelle région disposent tous du même temps de lecture et écriture sur l’application tout en bénéficiant d’une synchronisation des données avec latence faible complètement gérée par Couchbase.
A noter également que la solution proposée par Couchbase permet de disposer des données de manière active/active tout en gérant l’aspect conformité de ces dernières (via l’utilisation de filtres) vis à vis des lois en vigueurs dans les régions et pays de déploiements.

En conclusion

Couchbase x Qovery est un couple prometteur. En effet, la solution exige un coût supplémentaire par rapport à une solution gérée par le client lui-même. Cependant, aujourd’hui de nombreux clients souhaitent réduire l’aspect maintenance et opérabilité de leurs infrastructures sur le Cloud.
Avec des interfaces claires et faciles d’utilisation (qui changent grandement de l’interface console AWS) la solution proposée peut être une alternative intéressante pour des clients avec un besoin spécifique et rapide avec une infrastructure simple.

Vous pouvez retrouver une démo ici : https://www.youtube.com/watch?v=nza3ldlPI7w

Optimisez les coûts et la mise à l'échelle d'EKS avec Karpenter

Imane Zeroual (AWS), Sebastien Allamand (AWS) et Martinho Moreira (Voodoo) nous présente le projet Karpenter, sa mise en place dans un cluster EKS et un retour d'expérience sur les bénéfices apportés par cette solution.

Maximiser l'Efficacité des Clusters Kubernetes avec Karpenter

Kubernetes s'est imposé comme l'une des solutions les plus populaires pour la gestion des applications conteneurisées à grande échelle. Cependant, malgré ses avantages indéniables, Kubernetes peut présenter des défis en matière de gestion des ressources et d'optimisation des clusters. C'est là que Karpenter entre en jeu.

Qu'est-ce que Karpenter ?

Karpenter est un projet open-source développé par AWS qui vise à optimiser les clusters Kubernetes en automatisant le dimensionnement des nœuds. Son objectif principal est de garantir que les ressources sont utilisées de manière efficace tout en maintenant les performances et la disponibilité des applications.

Comment fonctionne Karpenter ?

Karpenter s’installe dans le cluster Kubernetes en tant qu’opérateur et va remplacer le mécanisme d’autoscaling d’AWS pour provisionner les nœuds.

Karpenter analyse les demandes de ressources des pods et les regroupe en fonction de leurs caractéristiques. En utilisant ces informations, il peut déterminer la meilleure façon de répartir les charges de travail sur les nœuds disponibles, et ainsi réduire le nombre de nœuds nécessaires.

Par exemple, il peut regrouper plusieurs pods légers sur un seul nœud pour libérer des ressources sur d'autres nœuds et ainsi les supprimer du cluster.

Karpenter peut également s'intégrer avec des services cloud tels qu'AWS Spot Instances ou des instances de type Graviton, ce qui permet d'optimiser les coûts tout en maintenant les performances des applications.

Afin de paramétrer et utiliser au mieux Karpenter, Sébastien Allamand nous présente ensuite quelques outils et méthodes tels que les détections de Drift du dataplane ou l’analyse approfondie de la perturbation des nœuds.

Retour d'expérience

Pour finir cette session, Martinho Moreira de chez Voodoo nous fait un retour d'expérience sur leur mise en place de Karpenter, l’architecture et les points de vigilance qu’ils en ont retiré.

Les slides parlent d’eux même :

En conclusion

Cette conférence fut très intéressante pour une découverte de cet outil de plus en plus utilisé dans le cadre d’optimisations FinOps.
La présentation a été accompagnée d’une démo qui nous a permis de rendre concret certains use cases, et de constater en live le fonctionnement de l’outil et les optimisations réalisées par Karpenter.
La 2ème partie de la conférence a bien complété ce talk avec un retour d'expérience concret de la part de Voodoo. Ils ont ainsi pu nous partager factuellement les retombées en termes de bénéfice de l’outil, les étapes de migration et les pièges à éviter lors de la mise en place de Karpenter.

Accelerate Gen AI with Amazon Bedrock and Snowflake:

Nadir Djadi de Snowflake a présenté une approche accélérée de l'intelligence artificielle générative en utilisant Amazon Bedrock et Snowflake.
Après une brève introduction sur le rôle de Snowflake, il a présenté une vue d'ensemble de la plateforme en mettant en avant trois points clés : L'IA accessible au quotidien sans expertise, le déploiement rapide d'applications avec personnalisation, la sécurité et la gouvernance des données garanties.

Ensuite, nous avons exploré certaines fonctionnalités offertes par Snowflake avant de nous concentrer sur la partie Amazon Bedrock. Cette dernière offre une intégration transparente des modèles fondamentaux (FMs) de divers fournisseurs pour des applications d'intelligence artificielle générative évolutive, avec des options de personnalisation privées.

Nous avons ensuite passé en revue les FM disponibles sur Amazon Bedrock, en notant que Mistral n'a pas été inclus dans la liste puisqu'il a été annoncé le jour même.

Enfin, il a conclu en montrant comment Snowflake peut interagir avec Amazon Bedrock via Snowpark External Access, qui repose sur des identifiants temporaires de AWS Security Token Service (STS) pour authentifier et accéder aux endpoint des modèles Amazon Bedrock.

En conclusion, je trouve la solution présentée par Nadir Djadi très intéressante, surtout pour son aspect permettant une utilisation rapide de l'IA sans nécessiter une expertise préalable. Cela me donne vraiment envie d'expérimenter Amazon Bedrock dans mes projets futurs.

Alors l’AWS Summit Paris c’est génIAl?

Cette année encore AWS nous gratifie d’un show à la taille de son investissement en France. En effet, l’acteur n°1 du cloud public a réussi à nous faire sentir à l’étroit sur les 3 étages du Palais des congrès de Paris. Nous avons pu profiter un maximum, même si pour certaines conférences il était difficile d’avoir une place.

Cette année s’annonce très intéressante sur le secteur de la GenAI. AWS compte bien rattraper son retard sur les aspects data et IA, en consacrant une attention particulière dans l’accompagnement de ses partenaires et clients voulant explorer ces solutions.

Nous resterons bien sûr à l’écoute des nouveautés qu’AWS pourraient annoncer dans les mois à venir, et nous n'hésiterons pas à vous les partager sur notre blog.

KubeCon 2022 - Jour 3

Λ\: Laurent Noireterre — Fri, 20 May 2022 17:50:41 +0000

Clap de fin pour la KubeCon 2022. Cette troisième et dernière journée a elle aussi été riche en thématiques et découvertes. En voici un condensé.

Par @vixsty, @eisenkremer, @aimbot31, @psclgllt, @launoirt

Kubernetes Everywhere: Lessons Learned From Going Multi-Cloud - Niko Smeds, Grafana Labs

Niko Smeds de chez Grafana nous fait un retour d'expérience de leur infrastructure multi-cloud, les raisons d’utiliser plusieurs provider cloud et les leçons apprises.

Niko nous énumère tout d’abord les raisons pour lesquelles une organisation devrait considérer le multi-cloud selon lui:

augmenter les régions disponibles
réduire le vendor lock-in
des raisons plus orientés préférences utilisateurs (par exemple la souveraineté des données)

Voici le découpage des briques communes à chaque cloud provider chez Grafana:

Cette structure permet d’avoir une gouvernance commune entre chaque cloud provider, mais les équipes de Grafana sont confrontés à plusieurs problématiques d’implémentation dûes aux spécificités de chaque provider:

Réseau:
- sur GCP les VPC sont globaux, sur AWS ils sont régionaux
- les CIDR ranges supportés sont différents entre GCP et AWS (GCP supporte le range /28 -> /8, AWS supporte /28 -> /16)
Différences dans les services managés (Load Balancers, Volumes, Object Storage)
Gestion des credentials applicatifs (GCP Service Account vs AWS IAM Roles)
Performances des disques : mauvaise performance de la classe de stockage par défaut sur Azure AKS
Docker Hub rate limit: problème de performance lors du démarrage des pods sur AWS à cause du pull des images Docker depuis une même adresse IP de la NAT Gateway, alors que GCP propose par défaut un cache des images
Différences de quotas des services pour chaque cloud provider

Voici en conclusion de ce talk les leçons apprises par les équipes de Grafana lors de leur mise en place et utilisation multi-cloud:

Logs Told Us It Was DNS, It Felt Like DNS, It Had To Be DNS, It Wasn’t DNS - Laurent Bernaille & Elijah Andrews, Datadog

Nous retrouvons Laurent Bernaille et Elijah Andrews, respectivement Staff Engineer et Senior Software Engineer chez Datadog, qui nous présente l'investigation qu'ils ont mené autour d'un problème survenant à chaque redéploiement du service "Metrics service".

Nous avons trouvé cette présentation tellement intéressante que nous préférons ne pas en dire trop. À la place nous préférons vous encourager à visionner cette présentation lorsqu'elle sera accessible.
Ils y détaillent chaques étapes de leurs réflexions et chaques pistes explorées pour comprendre la cause du problème, en passant par les raisons de son apparition et sa résolution.

Better Bandwidth Management with eBPF - Daniel Borkmann & Christopher M. Luciano, Isovalent

Dans cette présentation, Isovalent, société à l'origine de Cilium, soulève les problèmes et les limites dans la gestion réseau d'aujourd'hui et comment Cilium choisi et implémente des techniques pour y remédier.

Deux techniques nous sont particulièrement présentées :

Le changement vers un modèle EDT dont vous pouvez retrouver la publication google.

Ce modèle consiste à améliorer la vitesse à laquelle une trame va se retrouver dans la queue de la carte réseau.

Le 2nd point est l'évolution du TCP vers TCP BBR qui permet pour vulgariser d'adapter le TCP à la performance des réseaux de nos jours

Ici, on met en évidence que le TCP est un protocole créé pour des réseaux des années 1980 et que depuis nos réseaux ont bien changé.

C'est au travers d'une démonstration de streaming vidéo que l'on a pu voir de façon flagrante la différence entre sans et avec ces techniques.
L'ensemble permettant d'améliorer les capacités du réseau de façon très impressionnante.

A Treasure Map of Hacking (and Defending) Kubernetes

Andrew Martin qui a écrit le livre “Hacking Kubernetes” (et qui est disponible en téléchargement ici) nous a présenté les grandes étapes qui mènent à la compromission d’un cluster Kubernetes.
Voici une cartographie de toutes les potentielles vulnérabilités qui peuvent affecter un workload :

Le point d'entrée pris pour exemple ici est une attaque de plus en plus courante de nos jours : la supply chain attack. L’exemple le plus connu de supply chain attaque est la compromission du logiciel Solar Wind.
Via cette supply chain attaque, il obtient un reverse shell dans le contexte du pod. Nous voici en position d’exécuter des commandes et du code sur le container.

Ensuite plusieurs possibilités : lancer un autre pod malveillant ou s’évader du container.

La liste suivante des CVE résume bien l’état de sécurité de l’isolation des containers dans cette liste compilée par @Krisnova :

En exploitant la vulnérabilité Dirty Pipe (CVE-2022-0847), il s’évade du container et est maintenant root sur le node kubernetes.

Il a ensuite énuméré les secrets kubernetes qui sont accessibles depuis l’hôte et pris l’exemple d’une access key AWS, avec un petit twist car il s’agissait en réalité d’un honeypot.

C’est en effet une bonne idée de laisser des access key liées à un compte sans droit et de monitorer toute action réalisée par ce compte. Si la clé est utilisée on sait que l’on a été compromis et on peut prendre les actions nécessaires pour identifier et bloquer l’attaque rapidement.

Observing Fastly's network at scale thanks to k8s and the Strimzi operator

Daniel Caballero Rodriguez (Principal Engineer) & Fernando Crespo Gravalos (Staff Engineer) @ Fastly nous parlent de l’arrivé de kubernetes à Fastly ainsi que de leur système “Autopilot” sur kube qui permet d’optimiser la gestion du traffic sortant. Dans cet article, nous allons nous intéresser à la première partie afin de rester concis.

Au commencement de kubernetes à Fastly, les équipes lançaient des clusters kubernetes dans tous les sens. Fastly a observé que beaucoup de clusters étaient utilisés pour seulement une application, les besoins étaient souvent les mêmes et les bonnes pratiques pas toujours respectées.

De ce constat, Fastly a décidé de lancer le plan “Elevation”. La première itération “d’elevation” consistait à mutualiser les clusters avec une gestion par un équipe de SRE. 1 cluster de dev/staging/prod ainsi qu’une seule région. Un autre point important était l’agnosticité afin de ne pas dépendre d’un cloud provider dans le futur. Pour ce faire, Fastly a adopté les modalités suivantes :

Auth avec IdP, afin de ne pas dépendre du Cloud IAM
Harbor comme Container/Helm Charts registry
Vault pour la gestion des secrets
Nginx Ingress
Cert-Manager pour la génération des certificats https avec Lets Encrypt
Observability: Prometheus/Grafana, FluentD/Splunk
Service Mesh with Linkerd

De cette V1.0 les feedbacks suivant sont ressortis :

Plus de régions, plus de cloud providers, possibilité d’avoir des clusters baremetal
Réduire le ticket d’entrée pour utiliser kube
Prise en charge de Kafka en cluster
Courbe d'apprentissage abrupte
Améliorer l'observabilité du maillage des services

Afin de prendre en compte les améliorations de la version 1.0, Fastly à lancé la V2.0 en prenant en compte les retours :

Utilisation des ClusterPolicy avec kyverno pour la gestion des secrets
Utilisation d’opérateur pour certains besoin d’automatisation
Ajouts de plusieurs régions/cloud providers
De l’abstraction avec la possiblité de décrire l’application en 10 lignes de YAML afin qu’elle soit déployée avec un chart Helm standard maintenu par l’équipe SRE
Ajout de dashboards standardisés maintenu par l’équipe SRE afin d’avoir les informations sur chaque application pour chaque équipe déployant sur le cluster

A Guided Tour of Cilium Service Mesh - Liz Rice, Isovalent

Une autre présentation autour de Cilium mais cette foi dans une utilisation en tant que Service Mesh. Liz Rice revient sur les différentes formes qu'a pu prendre le service mesh jusqu'à une nouvelle hypothèse, et si le service mesh était inclus au niveau du Kernel ?

Mais le problème, et pas des moindre, est qu'au niveau du kernel, la couche TCP 7, pour laquelle le service mesh intervient, n'est pas visible. Donc eBPF et Cilium ne peuvent pas intervenir directement.

Dans son architecture du service mesh, Cilium propose donc la mise en place d'un reverse proxy Envoy sur la machine afin de pouvoir gérer cette couche TCP 7.

Cette approche permet d'éviter le "sidecar" à chaque pods mais impose un "sidecar" par node. Cela nous pose immédiatement des questions tant qu'à la scalabilité qu'à la gestion des exclusions. Envoy étant sur les nodes et les nodes exécutant des pods de divers namespaces.

S'enchaine des démonstrations, des commentaires de bêta testeurs et des benchmarks face à Istio. Globalement les chiffres sont intéressants et les commentaires confirment que la communauté espère plus.

On fini avec la gestion des contrôles planes. On peut choisir, mais l'intégration n'est pas native et il vous faudra gérer et maintenir cette intégration.

KubeCon 2022 - Jour 2

Λ\: Laurent Noireterre — Thu, 19 May 2022 21:16:17 +0000

Deuxième jour de la KubeCon 2022, voici notre sélection de talks !

Par @vixsty, @eisenkremer, @aimbot31, @psclgllt, @launoirt

Keynotes

Kubernetes Project Updates - Jasmine James, Senior Engineering Manager-Developer Experience; Ricardo Rocha, Computing Engineer, CERN; Emily Fox, Security Engineer, Apple

La keynote de ce second jour de KubeCon débute avec une présentation des nouveautés de Kubernetes 1.24. Nous vous avons détaillé ces nouveautés dans un article complet ici

Conférences

Case Study: Bringing Chaos Engineering to the Cloud Native Developers - Uma Mukkara, ChaosNative & Ramiro Berrelleza, Okteto

Après une petite introduction au bien fait du chaos engineering dans un monde de micro services et de pratique DevOps en constante évolution:

S'ensuit une démo nous expliquant pourquoi et comment rendre ça accessible dès le développement.

La démo s'appuie sur 2 outils, Litmus Chaos qui est une plateforme open source de "Chaos Engineering" et Okteto qui est un outil permettant de créer rapidement un nouvel environnement pré-configuré.

L'ensemble permettant de réaliser des workflows de chaos testing dès la phase de développement et de pouvoir corriger directement les problèmes identifiés durant les tests.

The Soul of a New Command: Adding ‘Events’ to kubectl - Bryan Boreham, Grafana Labs

Bryan Boreham nous explique ici les limitations de la commande kubectl get events avec les issues remontées par la communauté:

kubectl get events doesn't sort events by last seen time kubernetes#29838 opened 1 Aug 2016

Improve watch behavior for events kubernetes#65646, kubectl#793

Improve events printing kubectl#704, kubectl#151

kubectl get events should give a timeline of events kubernetes#36304

Pour palier à ça, Bryan ouvre une PR avec la création d’une nouvelle API ainsi que la commande kubectl events correspondante.

Une explication du process de validation des demandes de nouvelles fonctionnalités Kubernetes Enhancement Process (ou KEP) nous est alors détaillé:

Le KEP-1440 est alors ouvert pour demander l’ajout de l’api events et sera implémenté le 29 octobre 2021 et intégré à la version alpha 1.23 de Kubernetes.

La nouvelle commande kubectl events couvre tous les problèmes remontés par la communauté, notamment le tri des événements dans l’ordre chronologique.

Implementing Cert-Manager in K8s

Jose Manuel Ortega nous a présenté comment mettre en place cert manager dans un cluster k8s afin d'automatiser la génération de certificats pour les services avec Let's encrypt ou Hashicorp Vault.

Il nous a également présenté les autres fonctionnalités de Cert-manager comme la vérification de validité de certificats sur les différents environnements.

Better Reliability Through Observability and Experimentation - Julie Gunderson, Gremlin & Kerim Satirli, HashiCorp

Kerim Satirli, Sr. Developer Advocate, HashiCorp
Julie Gunderson, Sr. Reliability Advocate, Gremlin

Disclaimer: Si vous vous attendez à une conférence très technique, n’allez pas plus loin.

Dans cette conférence, Julie et Kerim vont essayer de démystifier l’observabilité dans nos systèmes informatiques. Cette dernière, comme dit plus haut, ne traitera pas le sujet de façon technique mais viendra vous aider à porter une réflexion sur certaines pratiques, notamment le Chaos Engineering.

Pour aborder ce point nous nous mettons dans un cas d’usage non technique; vous êtes le pilote d’un avion et vous perdez la connexion avec la tour de contrôle.
Que va-t-il se passer? Quel problème êtes vous en train de rencontrer?...

Tout d’abord, les piliers de l’observabilité :

Les logs:
si vous n’avez pas de log; vous ne pouvez pas investiguer
Les traces
si vous n’avez pas de trace, vous ne pouvez pas debugger
Les mesures
si vous n’avez pas de mesures, vous ne pouvez pas comprendre

Le but principal de l’observabilité est de réduire le temps de détection d’une erreur et si possible de la détecter avant le client.

Les techniques de Chaos Engineering permettent de valoriser ces piliers mais attention à bien avoir des backups et qu’ils soient fonctionnels; sinon ne faites pas ça !

Il peut être simple de faire des tests afin de trouver un point de rupture de votre application ou de votre architecture de façon relativement simple. Ci dessous quelques exemples de simulation que vous pouvez effectuer:

Engendrer de la latence
Créer volontairement des erreurs
Créer un goulet d'étranglement sur le réseau
Saturer et stresser l’application ou l’architecture

Tout cela permet de valider le point de rupture de votre application / architecture et de vous démontrer, si cela se présente, comment elle réagit à ce genre de problématique.

En conclusion, pour effectuer ces tests il existe plusieurs technologies et toutes ont leur intérêt mais assurez-vous de bien comprendre leurs fonctionnements et leurs retours. Enfin documentez tout ce que vous pouvez afin de réduire le temps de résolution.

KubeCon 2022 - Jour 1

Λ\: Laurent Noireterre — Wed, 18 May 2022 23:15:35 +0000

Aujourd'hui mercredi 18 mai avait lieu l'ouverture de la KubeCon 2022 ! Voici ce que les Stackers sur place ont retenu de cette première journée.

Par @vixsty, @eisenkremer, @aimbot31, @psclgllt, @launoirt

Keynote

Finding Your Power to Accelerate to a Sustainable Future

Une des keynotes d'ouverture de la KubeCon 2022, présentée par Kate Mulhall & Emma Collins d'Intel, adresse la nécessité de renforcer l'efficacité énergétique des data centers. À titre d'exemple, les data centers consomment aujourd'hui 2% de l'électricité produite mondialement, 8% d'ici 2030. Les CPUs sont utilisés entre 20 et 40% de leur capacité seulement. Les présentatrices rappellent aussi le désormais célèbre classement des langages de programmation par efficacité énergétique: des plus sobres C et Rust,... jusqu'à Perl, le plus énergivore.
En partant du hardware, et en passant par une meilleure conception des charges de travail et leur orchestration plus intelligente, il est possible de réduire la consommation d'énergie et par conséquent réduire notre empreinte carbone. La collecte des données d'observabilité (télémétrie) et leur analyse, et l'apprentissage machine jouent un rôle important pour y parvenir. Les optimisations peuvent être faites à tous les niveaux compute, réseau et stockage.
Intel aspire à être un leader mondial en matière de développement durable (voir https://www.intel.com/content/www/us/en/environment/intel-and-the-environment.html).
Au delà du discours, cette présentation nous rappelle que la responsabilité écologique et ses solutions se trouvent d'abord entre les mains des développeurs.

La présentation "working your K8s cluster: smarter scheduling decisions for your workloads" qui suit l'après-midi, toujours par Intel, rentre dans le vif du sujet et aborde des solutions concrètes. Voir https://github.com/intel/platform-aware-scheduling

Incremental Deep Learning for Satellites with KubeEdge and MindSpore

Zhipeng Huang, Director, AI Open Source, Huawei
Xiaoman Hu, Community Operation Director, Huawei
Yue Bao, Software Engineer, Huawei

Dans cette keynote, Huawei, nous démontre une nouvelle façon de gérer la communication avec des satellites, en étendant votre cluster Kubernetes jusque dans vos satellites. Cela permet d’uniformiser vos déploiements de bout en bout.
KubeEdge propose de manager vos satellites en déployant vos workload de la meme façon que sur un worker node classique.

Le son de cette keynote, enregistrée au préalable étant de très mauvaise qualité, nous vous conseillons de retrouver les slides de présentation dans le programme de la KubeCon.

Conférences

Bypassing Falco: How to Compromise a Cluster without Tripping the SOC - Shay Berkovich, BlackBerry

Falco est un outil de détection d'évènements pour Kubernetes. Il permet de lever une alerte en cas de détection d'activité suspecte comme une connexion SSH sur un pod.

Dans cette présentation Shay Berkovich nous explique comment compromettre un cluster sans déclencher d'alerte sur Falco.

Il a présenté plusieurs types de méthodes :

Chemin relatif sur un lien symbolique
Utiliser une implémentation différente d'un exploit de CVE
Renommer les exécutables
Lien symbolique d'un exécutable
Exécution de script au lieu de commande
Utilisation de mknod et mkfifo pour un reverse shell

Il a publié une image contenant tous les outils pour tester ces techniques d'évasion.

Vous pouvez la trouver ici :

Docker Hub

Il a conclu sa présentation avec les recommandations suivantes pour la création de règles Falco :

Bien choisir les hooking points pour augmenter la fiabilité des règles
Éviter d'utiliser des règles basées sur proc.name / proc.aname et filename car elles sont faciles à contourner
Ne pas introduire d'exception “and not” car cela crée une porte d'entrée pour les attaquants
Réévaluer la priorité des règles dans le contexte d'une évasion de règles
Faire une veille régulière des exploits publics
Développer ses propres règles privées pour que l'attaquant ne sache pas ce qui est surveillé et comment contourner les règles

Effective Disaster Recovery: The Day We Deleted Production - Rick Spencer & Wojciech Kocjan, InfluxData

InfluxData nous fait ici un retour d'expérience suite à la perte accidentelle de tout un cluster de production.

Voici le dur réveil du VP Engineer en ce vendredi de septembre :

L'incident a débuté suite au merge d'une PR qui paraissait anodine, mais qui a mené à une collision de noms d'applications dans ArgoCD et ainsi à la destruction du cluster Kubernetes.

Trois minutes après le merge de la PR, leur système de monitoring InfluxData commence à lever des alertes.

Quinze minutes plus tard, la support team commence à répondre aux premiers incidents clients.

S'en suit un revert de la PR et le début du process de recovery.

Cinq heure trente après le début de l'incident, le cluster est de nouveau opérationnel.

Sans rentrer dans le long détail de ce process, voici ce que InfluxData en a retiré.

Tout d'abord ce qui a bien fonctionné :

L'effort des différentes équipes pour remonter l'environnement
Application indisponible (downtime) mais aucune perte de données
Les équipes ont évité de céder à la panique, arrêté les tentatives infructueuses de rollback rapide et mis en place un plan d'action
Les backups de données ont bien fonctionnés

Ce qui n'a pas marché :

Leur chaîne de déploiement et d'automatisation n'a pas empêché la catastrophe
Premiers rollback sous-optimaux
Aucune procédure de reconstruction d'un cluster n'avait été écrite jusque là

Les équipes ont par la suite mis en place toute une série de règles et process pour éviter que cela ne se reproduise, notamment avec une meilleure revue des PR et l'amélioration de la configuration d’ArgoCD.

Multi-cluster Failover Using Linkerd - Charles Pretzer, Buoyant, Inc.

Charles Pretzer, field engineer at Buoyant, nous parle du produit linkerd, plus particulièrement comment faire du failover entre plusieurs clusters avec linkerd.

Dans ce talk, le speaker se sert « d’emojivoto »comme application d’exemple, cette appli génère du traffic avec 1/4 d’error rate.

Linkerd propose une fonctionnalité « multicluster » qui va nous permettre plusieurs choses :

chiffrement du traffic entre les différents clusters
Création de « services mirror »

Cette dernière fonctionnalité va être très intéressante pour contacter un service présent sur l’autre cluster afin de répartir la charge ou ségrégué le traffic en fonction de certains critères (localisation notamment). Un nouveau service va être créé sur l’autre cluster portant le même nom avec le nom du context de l’autre cluster à la fin.

Au niveau sécurité, les communications via les « services mirror » sont chiffrées via mTLS comme les communications dans le cluster.

Nous pouvons aussi nous servir de la spec SMI (ServiceMeshInterface) afin de spliter le traffic a travers les différents clusters de manière transparente pour les applications (sans changements dans l’application).

Les communications entre clusters peuvent-être unidirectionnelles ou bi-directionnelles. Une communication bi-directionnelle peut entraîner des checks circulaires, par chance, linkerd embarque une protection contre ce problème.

Plus d’informations : https://linkerd.io/2.10/features/multicluster/

How Lombard Odier Deployed VPA to Increase Resource Usage Efficiency - Vincent Sevel, Lombard Odier SA

Vincent Sevel, Architect / Platform Ops

Vincent nous propose d’essayer de répondre à la problématique suivante : “0/27 nodes are available: 19 Insufficient cpu”
Cette dernière est souvent induite par une mauvaise configuration des “requests” et “limits” de nos pods.

Le but:

Optimiser le placement
Ajuster les ressources des worker nodes
Économiser de l’argent

Pour répondre à cela nous allons essayer de récupérer dynamiquement les informations de consommation de nos pods afin de pouvoir les ajuster.

Le scale vertical de pod permet de :
Down-scale or Up-scale
Memory & CPU
Apply the recommendation (Opt)
React to OOM
Tous cela intégré dans des manifests Kubernetes

Ci dessous les ressource “économiser” grâce à ce set up:

La gestion de la mémoire est toujours en développement mais le projet est prometteur et réponds à un besoin de plus en plus présent.

Dans le futur :
Assess Memory/Initial
Densify
Bare Metal
Mix VPA with HPA/serverless
Expand VPA to Third Party packages

Si le sujet vous intéresse, vous pouvez lire cette article : https://povilasv.me/vertical-pod-autoscaling-the-definitive-guide/

Working your Cluster: Smarter Scheduling Decisions for Your Workloads - Madalina Lazar & Denisio Togashi, Intel

C’est ici une présentation des capacités de Platrorm Aware Scheduling et des problématiques que ce Kubernetes Scheduler Extenders tente de résoudre.

À savoir, permettre à nos exécutables d’avoir les ressources dont ils ont besoin en évitant de sur allouer. Avoir un Scheduling des pods plus intelligents que la simple utilisation de « resources request » permet d’y répondre. C’est rendu possible en permettant notamment l’utilisation de metrics externes et des stratégies plus évoluées.

Nous avons apprécié cette présentation qui tente d’apporter une réponse aux problématiques de sous consommation et de surcharge rencontré mais de notre première compréhension nous avons le sentiment que cela nécessitera du temps pour gérer une véritable stratégie. On rajoutera une petite attention particulière sur la gestion de deschedule qui peut être source de « flapping »

How to switch container runtime in a Kubernetes cluster

Λ\: Laurent Noireterre — Tue, 02 Mar 2021 09:20:27 +0000

As you might know, Kubernetes has deprecated Docker as container runtime, and Docker support will be removed in next versions (currently planned for the 1.22 release in late 2021).

If you are using a managed Kubernetes cluster (like GKE, EKS, AKS) you shouldn't have a lot to handle and it should be pretty straight forward for you. But if you are managing a cluster by yourself (with kubeadm for example) and use Docker as container runtime, you will have to handle that runtime switch soon or later to keep enjoying Kubernetes updates.

The aim of this post is not to deep dive into the reasons of that change introduced by Kubernetes, or deep dive into container runtime behaviour in a Kubernetes cluster, but to step by step describe how to switch your container runtime from Docker to any runtime that implements Container Runtime Interface (CRI). If you need more details on the reasons which lead to Docker deprecation, you can read Kubernetes Blog post Don't Panic: Kubernetes and Docker

What to check in the first place

Appart from the changes linked to Kubernetes installation itself, the impacts on the workloads running in your cluster should be limited, if not non-existent. One of the only thing you have to care about is if you are using Docker-in-Docker in any of your container workload by mounting the Docker socket /var/run/docker.sock. In that case you will have to find an alternative (Kaniko for example) before switching from Docker to your new container runtime.

It's also warmly advised to backup your data before proceeding with the container runtime switch!

Let's proceed with the changes !

Ok now that you are ready to apply the container runtime switch, let's proceed with the changes. I will use containerd as container runtime in this post but the steps below can be adapted to any container runtime (like CRI-O)

We will first start by impacting all worker nodes, and then finish by the control plane.

Worker nodes

The steps below have to be applied on each worker node.

1. First we will cordon and drain the node so that no more workload will be scheduled and executed on the node during the procedure.

kubectl cordon <node_name>
kubectl drain <node_name>

Remark: if you have DaemonSets running on the node, you can use the flag --ignore-daemonsets to proceed with the drain without evicting the pods linked to your DaemonSet (which is by the way impossible with the drain command). Don't worry, these pods will be automatically restarted by kubelet at the end of the procedure with the new container runtime. If you have critical workload linked to the DaemonSets and don't want to let them run during the process, you can either specify a nodeSelector on your DaemonSet or completely uninstall and reinstall them at the end of the process.

2. Once the node is drained, stop the kubelet service:

sudo systemctl stop kubelet
sudo systemctl status kubelet

3. Uninstall Docker.
I will not detail the commands here as it depends on your Linux distribution and the way you have installed Docker. Just be carefull if you want completely clean Docker artifacts, you might have to manually remove some files (for example /var/lib/docker)

You can check Docker documentation to help you uninstalling the engine.

4. Install containerd (same here, I let you choose your favorite way to install it following containerd documentation)

5. Enable and Start containerd service

sudo systemctl enable containerd
sudo systemctl start containerd
sudo systemctl status containerd

6. Kubernetes communicates with the container runtime through the CRI plugin. Be sure this plugin is not disabled in your containerd installation by editing the config file /etc/containerd/config.toml and check the disabled_plugins list:

disabled_plugins = [""]

Then restart containerd service if needed

sudo systemctl restart containerd

7. Edit kubelet configuration file /var/lib/kubelet/kubeadm-flags.env to add the following flags to KUBELET_KUBEADM_ARGS variable (adapt container-runtime-endpoint path if needed):

--container-runtime=remote --container-runtime-endpoint=/run/containerd/containerd.sock

8. Start kubelet

sudo systemctl start kubelet

9. Check if the new runtime has been correctly taken into account on the node:

kubectl describe node <node_name>

You should see the container runtime version and name:

System Info:
  Machine ID:                 21a5dd31f86c4
  System UUID:                4227EF55-BA3BCCB57BCE
  Boot ID:                    77229747-9ea581ec6773
  Kernel Version:             3.10.0-1127.10.1.el7.x86_64
  OS Image:                   Red Hat Enterprise Linux Server 7.8 (Maipo)
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.4.3
  Kubelet Version:            v1.20.2
  Kube-Proxy Version:         v1.20.2

10. Uncordon the node to mark it as schedulable and check your pods running status

kubectl uncordon <node_name>

That's it, once all your pods have been restarted you can proceed with the next worker node !

Control Plane

The procedure to upgrade the container runtime on master nodes is exactly the same than on the worker node. However you have to be careful if you are on a single master node configuration. Indeed, while the new container runtime will pull kube-apiserver, etcd and coredns images and then create corresponding containers, the cluster will be unavailable. You shouldn't also be able to run kubectl command.

Here are some tips to help you follow the new container runtime start and troubleshoot potential problems:

1. Use journalctl to follow kubelet logs:

journalctl -u kubelet

2. As well watch containerd logs:

journalctl -u containerd

3. Use crictl command to follow container deployments

crictl --runtime-endpoint /run/containerd/containerd.sock ps

4. Check at the end of the upgrade that you are well using the new container runtime by executing a describe command on your master nodes:

kubectl describe node <master_node_name>

Congratulations! You are now running a Kubernetes cluster without Docker and are now ready to receive future releases!