Pour notre troisième article de cette série sur ce que nous avons retenu de la KubeCon Europe 2022, après les performances applicatives et la scalabilité et les performances bas niveau, le système et le réseau, passons à la Developper eXperience, à l’outillage, à la CI/CD, aux rollback, à l’observabilité et aux incidents !

Une nouvelle journée commence, @ KubeCon 2022 !

La prod est tombée !

Dans notre secteur d’activité, nous avons tous subis des incidents de production et le retour d’expérience, qu’il soit interne ou public, est important et formateur.
En effet, même si les incidents de production sont malheureusement inéluctables dans nos métiers, il est important de les analyser afin de mieux les comprendre et demieux s’en prémunir.

Preuve de l’importance de ces sujets : nous avons assisté à deux conférences très intéressantes sur ce thème dans des salles pleines à craquer !
Toutes deux portaient sur des incidents de production majeurs suite à une modification de code qui peut paraître anodine : la première était donnée par Influxdata, la seconde par Skyscanner.
Les conférences étaient particulièrement joviales et bienveillantes : les réactions du public à certains slides montraient bien que ce genre de situations sentait le vécu pour certains !

Nous avons tous à apprendre de ces cas concrets d’incident, aussi, nous vous conseillons de visionner les vidéos de ces conférences : skyscanner et influxdata.
Mais si nous devions les résumer : l’automatisation de bout en bout demande une grande maturité, beaucoup (beaucoup !) de tests et des reviews de qualité !

Et comme il est dit dans une des slides :

Debugger, en production, avec des conteneurs éphémères

Nous utilisons régulièrement la commande kubectl exec pour entrer dans conteneur / pod et y lancer des commandes de débogage – parce que certains problèmes ne sont pas reproductibles ailleurs qu’en production, ou parce qu’il faut comprendre ce qu’il se passe avant de savoir reproduire en environnement de développement.

Cela dit, cette approche n’est pas géniale : si nous modifions des choses dans un conteneur, ces modifications persistent.
Aussi, il faut pouvoir installer des outils de débug dans un conteneur (ce qu’on ne peut pas facilement faire chez Bedrock, où nos conteneurs ne s’exécutent pas en root et ont souvent un filesystem read-only), ou les embarquer dans les images (ce qui les grossit considérablement, sans compter l’augmentation du risque de failles de sécurité).

Pour remédier à cette problématique, la fonctionnalité de conteneurs éphémères (vidéo) arrive en bêta dans Kubernetes 1.23 et ça semble absolument génial !
L’outil parfait pour lancer des conteneurs temporaires à l’intérieur de pods existant et incroyablement puissant pour débugger !
Nous allons pouvoir réduire le nombre d’outils de debug intégrés à nos images et parvenir à débugger plus aisément des problèmes qui ne surviennent qu’en production !

Les risques de l’observabilité / Observabilité piratée

“How attackers use exposed Prometheus Server to Exploit Kubernetes Clusters” (vidéo) par David de Torres et Miguel Hernandez, ou “comment obtenir l’empreinte de vos clusters k8s à travers vos données de monitoring”.

Sysdig est venu nous remémorer que le monitoring, c’est bien, mais que ne pas exposer ses données de monitoring, c’est mieux !
En effet, attention aux informations qui sont exposées à l’extérieur, elles pourraient être recueillies par des attaquants externes pour acquérir des connaissances sur votre plateforme (provider cloud, version de l’OS utilisé…) et s’en servir ensuite pour s’introduire dans votre infrastructure (fuite de données, cryptominage ou ransomware).

À travers un cas d’utilisation fictif, ils nous ont démontré la facilité de récupération de ces informations et comment elles sont utilisées pour monter une attaque.
Enfin, ils nous ont rappelé que pour se prémunir de ces attaques, il suffit de suivre les recommandations de sécurité ! CQFD.
Il est toujours bon d’avoir ces piqures de rappel et de toujours bien penser aux données que l’on expose vers l’extérieur.

CI/CD, déploiement progressif

Chez Bedrock, nous sommes en pleine refonte de notre chaîne de CI/CD : nous basculons tous nos projets du bon vieux Jenkins “temporaire”, que nous avions monté au début de notre migration vers Le Cloud, vers Github Actions.
Au passage, nous nous demandons forcément comment nous pourrions améliorer nos déploiements et les rendre plus sécurisés, tant pour la santé de notre plateforme que pour la paix d’esprit de nos équipes et de nos utilisateurs.

La conférence “Automated progressive delivery using gitops and service mesh” (vidéo) parlait de déploiement progressif avec Argo CD, pour améliorer l’excellence opérationnelle, réduire le MTTR, accroître l’automatisation et la fiabilité des processus de déploiement. Bref, des idées qui nous parlent !

Reste des fonctionnalités, qui nous semblent primordiales avant de se lancer sur un autre outil, qui ne sont pas encore gérées, hélas : mirroring de traffic, routing basé sur des en-têtes (typiquement : pour faire du déploiement progressif à la maille “utilisateur” et pas à la maille “requête HTTP”), détection d’anomalie et rollback automatisé…
Un projet à suivre, donc, qui pourrait mûrir dans les prochains mois.

Au niveau des aspects moins sympathiques : cette approche de déploiement progressif passe par un service mesh (envoy, ici).
Or nous n’en avons pas en place et depuis quatre ans n’avons toujours pas trouvé les bons arguments pour en introduire dans nos clusters, notamment à cause de la complexité ajoutée…

Une autre conférence (vidéo) mentionnait l’outil Flagger pour des déploiements Canary.

Quelques autres idées à retenir

Nous avons aussi vu quelques autres conférences dont nous avons tiré quelques idées, en plus bref :

• Kubernetes 1.23 apporte (en alpha) une nouvelle commande kubectl events, qui retourne ses résultats dans l’ordre chronologique. Ce que l’actuel kubectl get events ne fait pas et ça peut être bien embêtant. Vue comme de la culture générale, la conférence “The soul of a new command: adding ‘events’ to kubectl” (vidéo) racontait comment cette fonctionnalité a été implémentée et était fort intéressante.
• Un speaker parlait de la mise en place de Crossplane dans son entreprise (vidéo). Sujet potentiellement intéressant, mais qui ne correspond pas à notre approche actuelle. Nous avons toutefois retenu quelques points autour de comment il fournit des outils à ses collègues développeurs : documentation, composition de services, management d’attentes, utilisation de l’écosystème… Des problématiques auxquelles nous nous sommes confrontés de nombreuses fois, pour encourager nos équipes à adopter des évolutions ou de nouveaux outils !
• Si vous commencez à mettre en place votre stack de logs, la conférence “Show me your labels and I’ll tell you who you are” (vidéo) est faite pour vous. L’idée d’utiliser les labels assignés aux pods pour aller jusqu’à filtrer l’accès aux logs via RBAC, terrible ! Aussi, la création de flux de logs avec Logging Operator a l’air fort sympathique. Si ce talk était venu trois ans plus tôt, c’est quelque chose que nous essayerons !

Conclusion

Ces conférences nous ont permis d’approfondir les questions que nous nous posons actuellement alors que notre changeons de CI/CD (déploiement progressif, rollback automatisé ou non…).

Plus globalement, nous sommes contents de voir que l’outillage autour de Kubernetes continue à progresser et que la Developer eXperience est un sujet pris au sérieux dans notre communauté.

Rejoignez-nos équipes et venez vivre les prochaines conférences avec nous l’an prochain