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.
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.
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.
La multi-tenancy consiste à permettre à plusieurs équipes d’utiliser l’infrastructure Kubernetes, sans s’impacter. Kubernetes vient déjà avec des solutions :
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.
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.
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.
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 :
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 :
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.
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 :
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