k0rdent de Mirantis : Plongée au Cœur d'une Plateforme de Gestion de Conteneurs Distribuée (DCME) Open Source pour Kubernetes

Dans le paysage actuel de l'IT, la gestion de Kubernetes à grande échelle et dans des environnements distribués (multi-cloud, edge) représente un défi complexe. Mirantis, acteur majeur de l'écosystème Kubernetes, a répondu à ce besoin avec k0rdent, une plateforme open source de gestion de conteneurs distribuée (DCME - Distributed Container Management Environment). k0rdent se positionne comme un "super plan de contrôle" orchestrant et simplifiant la gestion d'infrastructures Kubernetes hétérogènes. Cet article explore en profondeur l'architecture, les composants, les fonctionnalités techniques et les avantages de k0rdent.

Architecture de k0rdent : Une Vision en Couches pour la Gestion Distribuée

L'architecture de k0rdent est conçue selon une approche modulaire et distribuée, permettant une gestion centralisée tout en respectant les principes de scalabilité et de résilience. Elle s'articule autour de trois composants clés, chacun jouant un rôle spécifique dans l'orchestration de l'environnement Kubernetes :

1. k0rdent Cluster Manager (kcm) : Le Chef d'Orchestre des Clusters Kubernetes

   Le kcm est le cœur de k0rdent, responsable de la gestion du cycle de vie complet des clusters Kubernetes. Il s'appuie sur l'API Cluster (CAPI - Cluster API), un projet open source de la CNCF (Cloud Native Computing Foundation), pour automatiser la création, la configuration, la mise à niveau et la suppression des clusters Kubernetes à travers diverses infrastructures. CAPI permet une approche déclarative de la gestion des clusters, où l'état désiré est défini, et le kcm se charge de le réaliser.

   • Abstraction de l'Infrastructure : Le kcm abstrait la complexité des infrastructures sous-jacentes (AWS, Azure, vSphere, OpenStack, bare metal). Grâce à CAPI et à ses fournisseurs d'infrastructure (Infrastructure Providers), k0rdent peut déployer et gérer des clusters sur différentes plateformes de manière uniforme. L'utilisateur interagit avec une API standardisée, indépendamment du fournisseur cloud ou de l'infrastructure on-premise.

   • Gestion du Cycle de Vie Déclarative : Le kcm met en œuvre une gestion du cycle de vie déclarative. Les configurations de clusters sont définies dans des fichiers YAML, qui sont ensuite appliqués par le kcm. Les mises à jour, les mises à l'échelle et les autres opérations sont également gérées de manière déclarative, garantissant la cohérence et la reproductibilité. Cette approche s'inscrit dans les principes du GitOps, favorisant l'infrastructure as code.

   • Reprise Après Sinistre Intégrée : La robustesse est au cœur de la conception du kcm. Il intègre des mécanismes de sauvegarde et de restauration pour assurer la reprise après sinistre. Les données critiques du kcm, notamment les configurations et les métadonnées des clusters, peuvent être sauvegardées sur une infrastructure externe (par exemple, un stockage objet S3 compatible). En cas de défaillance, ces données peuvent être restaurées pour rétablir rapidement la plateforme de gestion.

   • Extensibilité via les Fournisseurs CAPI : L'architecture basée sur CAPI rend k0rdent hautement extensible. De nouveaux fournisseurs d'infrastructure CAPI peuvent être ajoutés pour supporter de nouvelles plateformes cloud ou on-premise. Cela permet à k0rdent de s'adapter aux environnements hybrides et multi-cloud complexes.

2. k0rdent State Manager (ksm) : Le Gardien de la Configuration et des Politiques

   Le ksm est responsable de la gestion de l'état et de la configuration des clusters Kubernetes gérés par k0rdent. Il va au-delà de la simple gestion de l'infrastructure et se concentre sur la configuration logicielle et les politiques applicables aux clusters.

   • Gestion Centralisée des Configurations : Le ksm permet de définir et d'appliquer des configurations cohérentes à l'ensemble des clusters gérés. Cela inclut les configurations Kubernetes (RBAC, NetworkPolicies, etc.), mais aussi la configuration d'outils et de services externes déployés sur les clusters. Cette centralisation simplifie la gouvernance et assure la conformité.

   • Installation de Services "Beach-Head" : Le concept de "beach-head services" est central au ksm. Il permet de déployer de manière automatisée des services fondamentaux et partagés sur chaque cluster Kubernetes géré. Ces services peuvent inclure :

     • Outils d'Observabilité : Agents Prometheus, Grafana, outils de logging (Fluentd, Elasticsearch, Kibana).
     • Outils de Sécurité : Solutions de sécurité réseau, scanners de vulnérabilités.
     • Outils de Gestion des Politiques : OPA (Open Policy Agent), Kyverno pour l'application de politiques de sécurité et de conformité.
     • Outils de Mise en Réseau : Service meshes (Istio, Linkerd), Ingress controllers.

     Ces services "beach-head" sont déployés de manière uniforme sur tous les clusters, garantissant un environnement cohérent et sécurisé.

   • Gestion des Politiques et de la Conformité : Le ksm peut intégrer des moteurs de politiques comme OPA ou Kyverno pour appliquer des politiques de sécurité, de gouvernance et de conformité à l'échelle de la flotte de clusters. Ces politiques peuvent être définies de manière centralisée et appliquées automatiquement à tous les clusters, assurant la conformité aux exigences réglementaires et aux standards de sécurité de l'organisation.

   • Intégration GitOps : Le ksm s'intègre naturellement avec les flux de travail GitOps. Les configurations et les politiques sont versionnées dans un dépôt Git, et les modifications sont automatiquement synchronisées avec les clusters gérés par le ksm. Cela renforce la traçabilité, l'auditabilité et la reproductibilité des configurations.

3. k0rdent Observability and FinOps (kof) : La Visibilité et l'Optimisation des Coûts

   Le kof fournit une vue unifiée sur l'observabilité et les aspects FinOps (Financial Operations) des clusters Kubernetes gérés. Il agrège les données de monitoring, de logging et de coût provenant de l'ensemble de la flotte de clusters, offrant une visibilité centralisée et des outils d'optimisation.

   • Observabilité Unifiée : Le kof collecte et agrège les métriques, les logs et les traces provenant de tous les clusters gérés. Il offre des tableaux de bord centralisés pour visualiser l'état de santé, les performances et les événements de l'ensemble de l'environnement Kubernetes. Cela facilite la détection et la résolution des problèmes, ainsi que l'analyse des performances globales.

   • Monitoring Approfondi : Le kof va au-delà du monitoring de base des clusters et des nœuds. Il permet de surveiller les applications, les services et les workloads déployés sur les clusters. Des métriques spécifiques aux applications peuvent être collectées et analysées, offrant une visibilité granulaire sur les performances et le comportement des applications distribuées.

   • Gestion des Logs Centralisée : Le kof centralise la gestion des logs provenant de tous les clusters. Il permet de rechercher, d'analyser et de corréler les logs pour diagnostiquer les problèmes et comprendre le comportement du système. L'intégration avec des outils de logging populaires (Elasticsearch, Loki, etc.) est généralement proposée.

   • Fonctionnalités FinOps : Le kof intègre des fonctionnalités FinOps pour aider les organisations à maîtriser les coûts de leur infrastructure Kubernetes. Cela peut inclure :

     • Visualisation des Coûts : Tableaux de bord affichant les coûts par cluster, par namespace, par application, etc.
     • Allocation des Coûts : Attribution des coûts aux différentes équipes ou départements.
     • Recommandations d'Optimisation : Suggestions pour optimiser l'utilisation des ressources et réduire les coûts (redimensionnement des pods, autoscaling, etc.).
     • Politiques de Gestion des Coûts : Définition de budgets et d'alertes pour contrôler les dépenses.

   • Alerting et Notifications : Le kof configure des alertes basées sur des seuils de performance, des erreurs ou des anomalies détectées dans les logs ou les métriques. Ces alertes peuvent être envoyées par email, Slack, PagerDuty ou d'autres canaux de notification, permettant une réponse rapide aux problèmes.

Fonctionnement et Flux de Travail de k0rdent

Le fonctionnement de k0rdent peut être résumé par le flux de travail suivant :

1. Définition de la Configuration du Cluster : L'utilisateur définit la configuration du cluster Kubernetes souhaité (type d'infrastructure, version de Kubernetes, ressources, etc.) à l'aide de fichiers YAML compatibles avec CAPI.

2. Déploiement du Cluster via kcm : Le kcm, en utilisant CAPI et le fournisseur d'infrastructure approprié, provisionne et configure le cluster Kubernetes sur l'infrastructure cible.

3. Configuration et Politiques via ksm : Le ksm, en se basant sur les configurations définies (souvent versionnées dans Git), configure les services "beach-head", applique les politiques de sécurité et de conformité sur le cluster nouvellement créé.

4. Observabilité et FinOps via kof : Le kof collecte et agrège les données de monitoring, de logging et de coût du cluster. Les utilisateurs peuvent visualiser ces données via les tableaux de bord du kof pour surveiller l'état du cluster, analyser les performances et optimiser les coûts.

5. Gestion Continue du Cycle de Vie : Le kcm continue de surveiller le cluster et permet de réaliser des opérations de mise à niveau, de mise à l'échelle, de sauvegarde et de restauration de manière déclarative.

Avantages Techniques Clés de k0rdent

• Gestion Centralisée et Unifiée : k0rdent offre un point de contrôle unique pour gérer l'ensemble de l'infrastructure Kubernetes distribuée, simplifiant les opérations et réduisant la complexité.

• Automatisation Déclarative et GitOps : L'approche déclarative et l'intégration GitOps facilitent l'infrastructure as code, la reproductibilité, la traçabilité et l'automatisation des opérations Kubernetes.

• Abstraction de l'Infrastructure et Portabilité : Grâce à CAPI, k0rdent abstrait la complexité des infrastructures sous-jacentes, permettant de déployer et de gérer des clusters Kubernetes sur divers environnements de manière uniforme et portable.

• Extensibilité et Adaptabilité : L'architecture modulaire et l'utilisation de standards open source (CAPI, OPA, Prometheus, etc.) rendent k0rdent extensible et adaptable à des environnements variés et à des besoins spécifiques.

• Observabilité Intégrée et FinOps : Le kof fournit une visibilité centralisée sur l'état de santé, les performances et les coûts de l'infrastructure Kubernetes, permettant une gestion proactive et une optimisation des ressources.

• Facilitation des Plateformes de Développement Internes (IDP) : k0rdent simplifie la création de plateformes de développement internes en fournissant une infrastructure Kubernetes gérée et cohérente, ainsi que des outils d'observabilité et de gestion des politiques. Les développeurs peuvent se concentrer sur le développement d'applications sans se soucier de la complexité de la gestion de Kubernetes.

Cas d'Utilisation Techniques

• Environnements Multi-Cloud et Hybrides : Gestion centralisée de clusters Kubernetes déployés sur différents fournisseurs cloud (AWS, Azure, GCP) et environnements on-premise.
• Edge Computing : Déploiement et gestion de clusters Kubernetes distribués en périphérie (edge) pour des applications nécessitant une faible latence et un traitement local des données.
• Grandes Entreprises avec de Nombreuses Équipes et Clusters : Simplification de la gestion et de la gouvernance d'un grand nombre de clusters Kubernetes, réduisant la charge opérationnelle des équipes DevOps et assurant la cohérence et la conformité.
• Fournisseurs de Services Gérés (MSP) : Offre de services Kubernetes managés à leurs clients en s'appuyant sur k0rdent pour la gestion centralisée et automatisée des clusters.

Les ServiceTemplate de k0rdent : Déployer des Services Facilement sur Kubernetes

k0rdent utilise des ServiceTemplate pour simplifier le déploiement d'applications et de services sur les clusters Kubernetes gérés. Ces templates sont basés sur des charts Helm et permettent de définir comment installer un service spécifique.

Points Clés :

• Définition des ServiceTemplate : Ils indiquent à k0rdent où trouver un chart Helm (souvent dans un dépôt privé) pour installer une application. L'exemple de Nginx Ingress montre comment définir le chart, la version et le dépôt Helm dans un ServiceTemplate.
• Intégration dans ClusterDeployment : Pour déployer un service sur un cluster, on référence le ServiceTemplate dans la section serviceSpec d'un objet ClusterDeployment. Cela indique à k0rdent d'inclure ce service lors de la création ou de la modification du cluster.
• Services de base ("Beach-head services") : Les ServiceTemplate sont idéaux pour déployer des services fondamentaux comme Kyverno ou Ingress Nginx sur tous les clusters gérés de manière cohérente.
• Personnalisation via values : On peut personnaliser la configuration des services en passant des valeurs Helm spécifiques dans la section values du ClusterDeployment. Ces valeurs sont fusionnées avec la configuration par défaut du chart Helm. On peut aussi utiliser valuesFrom pour charger les valeurs depuis un ConfigMap ou Secret.
• Templating des valeurs : k0rdent permet d'utiliser le templating (avec Sveltos) dans les values pour récupérer dynamiquement des informations du cluster Kubernetes cible (comme l'endpoint du control plane).
• Suivi de l'état : L'état du déploiement des services (installé, erreurs, etc.) est visible dans la section status.services de l'objet ClusterDeployment.

• Suppression de services : Pour supprimer un service déployé via ServiceTemplate, il suffit de retirer sa définition de la section serviceSpec du ClusterDeployment.

• Un exemple simple

Scénario : Nous voulons déployer une application web simple (Nginx) sur un cluster Kubernetes géré par k0rdent, en utilisant un ServiceTemplate.

1. Définition du ServiceTemplate pour Nginx :

Imaginons que nous ayons un chart Helm simple pour déployer Nginx, disponible dans un dépôt Helm public (ou privé). Nous allons créer un ServiceTemplate qui pointe vers ce chart.

apiVersion: k0rdent.mirantis.com/v1alpha1
kind: ServiceTemplate
metadata:
  name: simple-nginx-template-1.0.0 # Nom du ServiceTemplate (versionné)
  namespace: k0rdent-system # Namespace où le ServiceTemplate est défini (gestion)
spec:
  displayName: "Nginx Web Server Simple" # Nom affiché dans l'interface utilisateur
  description: "Déploie un serveur web Nginx basique." # Description du template
  helm: # Spécification du chart Helm
    chartSpec:
      chart: simple-nginx # Nom du chart Helm (dans le dépôt)
      version: 1.0.0 # Version du chart Helm
      sourceRef: # Référence au dépôt Helm
        kind: HelmRepository
        name: k0rdent-public-charts # Nom du HelmRepository (défini ailleurs dans k0rdent)

Explication du ServiceTemplate :

• apiVersion, kind, metadata : Définition standard d'un objet Kubernetes ServiceTemplate.
• metadata.name : simple-nginx-template-1.0.0 - Nom unique pour identifier ce template. La version 1.0.0 est incluse pour le versionnement.
• metadata.namespace : k0rdent-system - On place généralement les ServiceTemplate de gestion dans un namespace système.
• spec.displayName, spec.description : Informations pour l'affichage dans l'interface utilisateur de k0rdent, pour aider les utilisateurs à comprendre ce que fait ce template.
• spec.helm : Indique que ce ServiceTemplate utilise un chart Helm pour le déploiement.
  • chartSpec.chart : simple-nginx - Nom du chart Helm que nous voulons utiliser.
  • chartSpec.version : 1.0.0 - Version spécifique du chart Helm à utiliser.
  • chartSpec.sourceRef : Indique où trouver le dépôt Helm.
    • kind: HelmRepository : Type de référence (dépôt Helm).
    • name: k0rdent-public-charts : Nom d'un objet HelmRepository qui aurait été préalablement défini dans k0rdent et qui pointe vers l'URL du dépôt Helm public contenant le chart simple-nginx. (La définition de HelmRepository n'est pas montrée ici pour simplifier).

2. Déploiement de Nginx sur un Cluster via ClusterDeployment :

Maintenant, pour déployer ce Nginx sur un cluster géré par k0rdent, nous allons créer ou modifier un ClusterDeployment et y référencer notre ServiceTemplate.

apiVersion: k0rdent.mirantis.com/v1alpha1
kind: ClusterDeployment
metadata:
  name: mon-cluster-web # Nom de notre ClusterDeployment
  namespace: mon-organisation # Namespace pour notre organisation
spec:
  template: aws-standalone-cp-0-1-0 # Template de cluster utilisé (défini ailleurs)
  credential: aws-credential # Credential AWS pour ce cluster (défini ailleurs)
  serviceSpec: # Spécification des services à déployer sur ce cluster
    services:
      - template: simple-nginx-template-1.0.0 # Référence au ServiceTemplate Nginx
        name: nginx-web # Nom de l'instance du service (release Helm)
        namespace: applications-web # Namespace où Nginx sera déployé sur le cluster cible
    priority: 100 # Priorité des services (peut être utilisé pour ordonnancer les déploiements)

Explication du ClusterDeployment :

• apiVersion, kind, metadata : Définition standard d'un objet ClusterDeployment.
• metadata.name : mon-cluster-web - Nom de notre déploiement de cluster.
• metadata.namespace : mon-organisation - Namespace pour organiser nos déploiements.
• spec.template, spec.credential : Définissent le template de cluster et les informations d'identification pour l'infrastructure sous-jacente (AWS dans cet exemple). Ces parties ne sont pas directement liées aux ServiceTemplate, mais sont nécessaires pour un ClusterDeployment complet.
• spec.serviceSpec.services : La partie cruciale pour les ServiceTemplate.
  • - template: simple-nginx-template-1.0.0 : Indique que nous voulons utiliser le ServiceTemplate que nous avons défini pour Nginx. On le référence par son nom.
  • name: nginx-web : Donne un nom à cette instance de service. Ce nom sera utilisé comme nom de release Helm.
  • namespace: applications-web : Spécifie le namespace applications-web sur le cluster cible où Nginx sera déployé. Si ce namespace n'existe pas, k0rdent peut le créer (selon la configuration).
  • priority: 100 : Définit une priorité pour ce service. Si vous avez plusieurs services, vous pouvez utiliser les priorités pour contrôler l'ordre de déploiement.

Ce qui se passe lorsque vous appliquez le ClusterDeployment :

1. k0rdent lit le ClusterDeployment et détecte la section serviceSpec.services.
2. Pour le service nginx-web, il recherche le ServiceTemplate nommé simple-nginx-template-1.0.0 dans le namespace k0rdent-system.
3. k0rdent récupère la définition du ServiceTemplate, notamment les informations sur le chart Helm (simple-nginx version 1.0.0 depuis le dépôt k0rdent-public-charts).
4. k0rdent utilise Helm pour déployer le chart simple-nginx sur le cluster Kubernetes cible, dans le namespace applications-web, en utilisant le nom de release nginx-web.

Vérification :

Une fois le ClusterDeployment appliqué et k0rdent a terminé le déploiement, vous pouvez vérifier sur le cluster cible (via kubectl) que le service Nginx est bien déployé dans le namespace applications-web. Vous devriez voir des Pods Nginx en cours d'exécution et un Service Nginx créé.

kubectl get pods -n applications-web
kubectl get service -n applications-web

Conclusion

k0rdent de Mirantis représente une solution technique robuste et complète pour la gestion de conteneurs distribuée avec Kubernetes. Son architecture modulaire, son approche déclarative, son intégration avec CAPI et son focus sur l'observabilité et le FinOps en font une plateforme puissante pour les organisations qui cherchent à maîtriser la complexité de Kubernetes à grande échelle et dans des environnements distribués. En tant que projet open source, k0rdent bénéficie de la contribution de la communauté, assurant son évolution et son adaptation aux besoins du marché. Pour les architectes, les ingénieurs DevOps et les responsables de plateformes Kubernetes, k0rdent est une solution à considérer sérieusement pour simplifier et optimiser la gestion de leurs infrastructures conteneurisées.