Elle est où ton appli ? Dans mon Kube ! - Compte-rendu du talk de Lucas BOISSERIE et Benjamin BRABANT à La Duck Conf 2020

Lucas et Benjamin nous partagent leurs bonnes pratiques, avec pour toile de fond un retour d’expérience d’un peu plus de deux ans avec Kubernetes dans le retail.

A quoi ça sert Kubernetes ?

La principale réponse qu’apporte Kubernetes dans le monde de l’infrastructure et de la conteneurisation c’est de l’orchestration avancée de conteneurs sur un parc de machines, managées comme un ensemble cohérent que l’on appelle aussi “cluster”.

Toujours dans une logique de “Desired State Configuration”, Kubernetes apporte une grande abstraction sur la technique à l’œuvre pour mettre tout ce petit monde en marche.

Où poser mon Kube ?

Si le contexte le permet, Kubernetes managé est la solution préconisée, pour des raisons de simplicité, de pérennité. Mais ces choix dépassent la sphère technologique et vont s’opposer à des contraintes de sécurité, réglementaires ou de marché qui feront que votre choix pourra pencher vers la solution on premise.

Le choix du cluster managé va se payer parfois au prix d’un manque de contrôle. C’est malheureusement difficile d’anticiper les limites que l’on rencontrera avec un service managé et c’est souvent au pied du mur que l’on s’en rendra compte.

Un moyen de s’en prémunir, notamment en phase de construction d’une offre kubernetes, est d’envisager monter une offre blue / green avec un cluster en managé et l’autre en hybride, scénario envisageable si l’on ne fait tourner que du workload stateless sur Kubernetes.

Quel sont les mécanismes pour faire de la multi-tenancy ?

La multi-tenancy consiste à permettre à plusieurs équipes d’utiliser l’infrastructure Kubernetes, sans s’impacter. Kubernetes vient déjà avec des solutions :

• Quotas / Limitations par Namespace pour maîtriser les ressources allouées
• Network Policy pour maîtriser les communications entre applications
• Rôles pour déléguer des droits aux utilisateurs du cluster
• Pod Security Policy pour contrôler le workload exécuté sur le cluster

Mais parfois ça ne suffira pas, notamment si l’on souhaite avoir du cloisonnement par projet sur les logs ou les métriques de monitoring. Se posera alors la question d’aller vers des offres type OpenShift / Rancher ou de se lancer soi-même à étendre ces mécanismes.

Comment j’administre mon cluster ?

Comme on l’a vu auparavant, Kubernetes apporte une couche d’abstraction à travers la notion de ressources. Utiliser ou Administrer le cluster reviendra alors, la majeure partie du temps, à manipuler ces ressources au travers d’une API.

Bien entendu, et selon qu’on aura choisi un cluster managé ou on premise, on aura potentiellement besoin d’accéder aux noeuds sous-jacent, pour certaines actions de maintenance ou pour faire évoluer certaines briques internes au cluster.

Quel sont les changements pour les utilisateurs et administrateurs  ?

Ainsi Kubernetes va réinventer le métier d’ingénieur opérationnel et en simplifier un certain nombres de tâches.

En effet, d’un point de vue administrateur, filtrer les flux réseau, gérer du capacity planning, gérer les accès, toutes ses tâches vont se passer au travers d’abstractions qu’offre Kubernetes.

Également, les habitudes qu’on avait pour déployer des applications, consulter des logs, diagnostiquer un problème vont également être chamboulées.

Kubernetes, ne serait-il pas la silver bullet de mon infrastructure ?

En effet, Kubernetes vient répondre à de très nombreuses problématiques que l’on rencontre lorsqu’on gère une infrastructure, et plus particulièrement une flotte de conteneurs. Mais il ne cherche pas à résoudre tous les problèmes, particulièrement lorsque d’autres solutions matures existent déjà, en offrant des facilités d’intégration notamment pour :

• les secrets : sont simplement matérialisé par une ressources dédiée, encodé pour le moment, mais intégrable à d’autres solutions tel que Hashicorp Vault
• les logs, monitoring, supervision: ne sont pas gérés nativement mais plusieurs acteurs offres des solutions clés-en-main, le plus répandu étant Prometheus.
• le stockage : est de mieux en mieux supportés avec des abstractions élégantes et de nombreuses intégrations. Mais on perdre la facilité de pouvoir jeter facilement un cluster qui ne porterait que du workload stateless, ainsi il est préférable de s’y attarder dans un second temps.

Comment je m’organise pour gérer mon kube ?

Dans ce chantier de transformation profonde de la gestion d’infrastructure, « si on a une équipe centrale qui garde la main sur l'infrastructure on a perdu ». Tout doit être organisé pour donner un maximum d'autonomie aux équipes, et partager la responsabilité avec :

• Une équipe CaaS qui gère une plateforme comme un produit et ne déploie plus les applications des équipes projets. Elle est organisée en mode SRE et met à disposition une plateforme et en assure les maintenance et les évolutions.
• Les équipes applicatives autonomes pour déployer à leur rythme sur la plateforme grâce à une organisation multi-compétences par feature team et l’arrivée d’un OPS dédié.

Sans oublier la culture du partage, en délaissant par exemple l’outil de ticketing classique pour aller vers un autre mode d’outillage, plus ouvert, en mode forum afin de simplifier leurs actions de support.

Comment mon application évolue ?

Commençons par une proposition de définition d’une application Cloud Native.

En effet, les mécanismes d’orchestration vont nous pousser à penser le design applicatif pour être le plus tolérant à la panne possible, Kubernetes n’hésitant pas à détruire et recréer les applications pour ses besoins.

De manière générale, on va devoir se poser la question de déployer une application telle quelle sur Kubernetes ou s’y refuser car son architecture n’est pas appropriée sans envisager une refonte complète. On devra généralement réaliser quelques adaptations plus ou moins à la marge pour respecter quelques patterns, et notamment :

• les 12 factors comme un prérequis à respecter pour votre application
• Bien connaître les contraintes et difficultés connues pour sa stack technique
• Ne pas négliger l'importance d’optimiser la taille des images de conteneurs, le temps de téléchargement pouvant ralentir considérablement l’orchestration de l’application
• Gagner du temps grâce aux outils matures (Google JIB, Buildpack, Kaniko, ... )
• Faire table rase du passé, certains framework embarquant des composants middleware gérés maintenant par Kubernetes.
• Externaliser au maximum ce qui n’est pas directement du ressort de l’application, notamment les logs, sessions, configurations, services
• Exposer la santé de son application en tirant partie du mécanisme riche de probe de Kubernetes.

On retiendra de ce retour d’expérience que du Kubernetes en production avec des applications critiques, tel qu’en atteste ces retours d’expérience d’un peu plus de deux ans, ce n’est pas qu’une illusion. Kubernetes étant à priori présent sur la majorité des Cloud Providers, on pourra même se demander si Kubernetes n’est pas en phase de devenir l’API Universelle de l’infra de mon SI ?

https://www.youtube.com/watch?v=MWqVgmlqqtQ&list=PLXlbmbYadKH5wS5tkVUDuP9ygC3lYOVaA