Container Days Hamburg : Aperçu d'une conférence sur les technologies natives du Coud

La récente conférence Container Days Hamburg a rassemblé un large éventail de participants du secteur et un grand nombre de présentations très  informatives. Même la nourriture était bonne ! Il semble que les Allemands excellent non seulement dans la fabrication et l'ingénierie automobile, mais aussi dans la restauration événementielle. KubeCon prend en notes !

Les exposants habituels tels que Camptocamp, Isovalent, Sysdig, SUSE étaient présents pour faire leur travail : présenter leurs produits et services dans la zone d'exposition, distribuer des cadeaux et échanger des idées.

L’événement proposait une gamme variée de conférences, couvrant le développement d'applications, les opérations, l'IA et l'apprentissage automatique, la mise en réseau, la sécurité et l'informatique de pointe. Les sessions ont offert des perspectives pratiques aux développeurs et aux ingénieurs, en mettant en évidence les tendances et les défis clés dans les environnements cloud-native.

Mes 3 présentations préférées étaient :

1. Tests de sécurité continus avec OWASP secureCodeBox dans Kubernetes.

La présentation de Jannik Hollenbach s'est concentrée sur l'OWASP secureCodeBox, une puissante boîte à outils permettant d'automatiser et d'exécuter des outils d'analyse de sécurité dans les environnements Kubernetes. La secureCodeBox s'exécute en tant qu'opérateur Kubernetes, en utilisant des définitions de ressources personnalisées (CRD) pour définir les tâches d'analyse. Ce projet Open Source permet d'effectuer des tests de sécurité en continu en intégrant divers outils de scan tels que Nmap, ZAP, Nuclei et Trivy.

L'une de ses capacités les plus notables est la découverte automatique, qui peut identifier les composants s'exécutant dans le cluster Kubernetes et lancer automatiquement les scans appropriés. Par exemple, il peut lancer des analyses Trivy sur toutes les images de conteneurs pour vérifier les vulnérabilités et les dépendances, ou bien utiliser ZAP pour analyser les services avec des ports HTTP. Même si je ne l'ai pas encore testée, la solution semble plutôt prête à l'emploi.

2. Leçons tirées de la mise en œuvre de GitOps et de la livraison continue à l'échelle.

Dans le contexte de la gestion de 100+ clusters Kubernetes et du traitement de 100+ sources diverses pour les applications, les défis présentés par les outils GitOps mainstream peuvent se heurter à quelques problèmes de performance et de sécurité. SUSE a présenté certains cas d'utilisation où la complexité de la mise en œuvre de GitOps et de la livraison continue augmente de façon exponentielle en raison de l'échelle, ce qui nécessite des stratégies et des outils adaptés.

Les architectures alternatives proposées lors de la présentation ont mis l'accent sur la délégation des responsabilités à des agents en cluster au lieu des solutions centralisées plus classiques pour le CD. Les présentateurs ont également discuté de l'utilisation de mécanismes de mise à jour basées sur la traction et de stratégies de synchronisation flexibles qui seraient vitales pour gérer la vaste gamme d'applications provenant de différentes sources, permettant des déploiements plus contrôlés et échelonnés des mises à jour sur des milliers de clusters.

Les présentateurs ont encouragé le public à essayer Rancher Fleet. C'est simple, c'est la solution austère à la gestion des déploiements. Les créateurs le définissent comme un outil basé sur GitOps pour gérer les clusters Kubernetes à l'échelle. Il se démarque en gérant des milliers de clusters, prend en charge la gestion multi-repo centralisée, utilise un système de bundle, permet les déploiements groupées et aussi cibler des customization par cluster et s'intègre bien avec Helm et Kustomize. Il fournit également un RBAC avancé et un contrôle des politiques, ce qui le rend idéal pour les configurations multi-clusters à grande échelle.

3. Passer à l'échelle pour tes 10 premiers millions d'utilisateurs - L'édition Kubernetes.

As-tu regardé la célèbre série « Scaling up to your first 10 million users » sur la chaîne youtube d'AWS? Eh bien, Marco Ballerini d'AWS, a exposé une analyse similaire, cette fois-ci pour les clusters Kubernetes.

L'une des belles prises de la présentation est que la mise à l'échelle n'est pas seulement une question de technologie. Il a énuméré les exigences auxquelles tu devras peut-être répondre lorsque tes clusters commenceront à grandir. L'analyse s'est développée -comme n'importe quel produit- à partir de petits clusters (~10 nœuds), vers des clusters de taille moyenne (~ 50 nœuds), jusqu'à ce que tes clusters atteignent plus de 100 nœuds.

Je me fais l'écho ci-dessous de quelques aspects organisationnels et opérationnels de cette analyse des besoins de « mise à l'échelle » que j'ai trouvés les plus perspicaces.

Pour les petites grappes, le raisonnement est qu'il faut commencer par des bases solides, tout en restant simple. Mets en place des procédures standard pour la création de clusters, implémente très tôt l'Infrastructure as Code (IaC), pas de clickOps en production et, s'il te plaît, n'oublie pas la reprise après sinistre. Rédige ton plan de reprise après sinistre très tôt et tu éviteras l'épuisement des ingénieurs lorsque le moment viendra où tu devras en activer un.

Lorsque tu passeras à des clusters de taille moyenne, concentre-toi sur le contrôle d'accès basé sur les rôles (RBAC), adopte GitOps (ce n'est pas négociable !). N'oublie pas d'utiliser les services gérés lorsque tu le peux, ils peuvent coûter quelques sous pesos supplémentaires mais le temps de ton équipe d'ingénieurs aussi.

Lorsque tu entres dans la cour des grands avec de grandes grappes, tout est une question de gestion intelligente. Dans les systèmes à grande échelle, l'effet papillon est réel : ce qui semble être un oubli mineur peut se transformer en problèmes majeurs lorsqu'il est amplifié sur des millions d'instances. La vigilance en matière de prévention et de traitement des erreurs devient primordiale, alors pense à la gestion des changements. Automatise ta gestion des changements, affine-la pour suivre le rythme des équipes de développement. Envisage d'utiliser des définitions de ressources personnalisées (CRD) pour enrichir l'API de ton cluster, les utilisateurs te remercieront. Reste simple, utilise IaC et GitOps, et tu seras sur le bon chemin vers les 10M d'utilisateurs !

Voici un discours d'ascenseur DevSecOps lu en 15 minutes sur les recommandations de mise à l'échelle des clusters Kubernetes, la gestion des déploiements à l'échelle et la surveillance et les tests de sécurité en continu sur les clusters Kubernetes. Reste à l'écoute pour plus d'actualités et de tuyaux sur les meilleures pratiques de #DevSecOps, #IaC et #Kubernetes - parce que le voyage cloud-native ne fait que commencer !
 

As-tu besoin d'aide pour mettre en place des pratiques DevSecOps ou pour préparer ton infrastructure à toucher un plus grand nombre d'utilisateurs ? Prends contact avec nous !