Crossplane : infrastructure-as-code piloté depuis Kubernetes

Dans les organisations qui adoptent Kubernetes comme plateforme centrale, une question récurrente émerge : comment gérer l'infrastructure Cloud (bases de données, buckets de stockage, réseaux) avec la même approche déclarative que les applications ? Comment permettre aux équipes de développement de provisionner leurs ressources sans multiplier les outils et les processus ? Ces interrogations, familières aux équipes Platform Engineering, trouvent une réponse élégante dans un projet qui repense fondamentalement l'Infrastructure-as-Code : Crossplane.

Véritable extension de Kubernetes pour la gestion d'infrastructure, Crossplane transforme le cluster en un control plane universel capable de provisionner et gérer des ressources sur n'importe quel fournisseur Cloud. Projet gradué de la Cloud Native Computing Foundation (CNCF), Crossplane permet de définir des ressources AWS, GCP, Azure ou on-premise directement via des manifestes Kubernetes, en utilisant les mêmes outils et workflows que pour les applications. Adopté par des entreprises comme Upbound, Deutsche Telekom ou encore Groupe Renault, Crossplane incarne une vision où l'infrastructure devient une extension naturelle du cluster Kubernetes, gérée avec kubectl plutôt qu'avec des outils externes.

L'Infrastructure-as-Code revisitée

L'Infrastructure-as-Code (IaC) a révolutionné la manière dont les équipes gèrent leurs environnements Cloud. Plutôt que de cliquer dans des consoles web, on décrit l'infrastructure souhaitée dans des fichiers de configuration, versionnés dans Git et appliqués de manière reproductible. Des outils comme Terraform, Pulumi ou CloudFormation ont démocratisé cette approche, devenant des standards de l'industrie.

Cependant, cette approche traditionnelle présente certaines limitations dans les environnements Kubernetes-centriques. Les équipes doivent maîtriser des outils distincts : kubectl pour les ressources Kubernetes, terraform pour l'infrastructure Cloud, avec des syntaxes, des états et des pipelines différents. La réconciliation entre l'état désiré et l'état réel n'est pas continue : si quelqu'un modifie manuellement une ressource dans la console Cloud, l'outil IaC ne le détecte qu'à la prochaine exécution planifiée.

Crossplane adopte une philosophie radicalement différente en étendant l'API Kubernetes pour y intégrer la gestion des ressources Cloud. Au lieu de définir une base de données RDS dans un fichier Terraform, on la déclare comme une ressource Kubernetes native :

apiVersion: rds.aws.crossplane.io/v1alpha1
kind: RDSInstance
metadata:
  name: ma-base-production
spec:
  forProvider:
    region: eu-west-1
    dbInstanceClass: db.t3.medium
    engine: postgres
    masterUsername: admin
  writeConnectionSecretToRef:
    name: db-credentials
    namespace: production

Cette ressource, appliquée avec un simple kubectl apply, déclenche la création effective de l'instance RDS sur AWS. Crossplane surveille ensuite en permanence l'état de la ressource et la réconcilie automatiquement si une dérive est détectée, exactement comme Kubernetes le fait pour les Pods et les Services.

Les bénéfices de cette approche sont significatifs :

• Unification des outils : une seule interface (kubectl), un seul langage (YAML), un seul workflow pour les applications et l'infrastructure.
• Réconciliation continue : Crossplane détecte et corrige automatiquement les dérives de configuration, garantissant que l'état réel correspond toujours à l'état déclaré.
• Intégration native GitOps : les outils comme ArgoCD ou Flux peuvent gérer l'infrastructure exactement comme les applications, sans configuration spécifique.
• Modèle de sécurité Kubernetes : RBAC, namespaces et autres mécanismes de sécurité Kubernetes s'appliquent naturellement aux ressources d'infrastructure.

Architecture et concepts fondamentaux

Crossplane s'appuie sur le mécanisme d'extension natif de Kubernetes (les Custom Resource Definitions) pour ajouter de nouveaux types de ressources au cluster. Son architecture modulaire distingue plusieurs composants qui collaborent pour offrir une plateforme IaC complète.

Les Providers constituent la couche d'intégration avec les plateformes externes. Chaque provider (AWS, GCP, Azure, Kubernetes, Helm, SQL, etc.) apporte un ensemble de CRDs représentant les ressources de cette plateforme et un controller qui sait comment les créer et les gérer. L'installation d'un provider est elle-même déclarative :

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws
spec:
  package: xpkg.upbound.io/crossplane-contrib/provider-aws:v0.44.0

Les Managed Resources sont les représentations Kubernetes des ressources Cloud externes. Chaque type de ressource (bucket S3, instance EC2, base de données Cloud SQL) possède son propre CRD avec des champs spécifiques. Crossplane maintient une synchronisation bidirectionnelle : les modifications dans le cluster sont propagées vers le Cloud, et l'état Cloud est reflété dans le status de la ressource Kubernetes.

Le concept de Compositions représente la véritable puissance de Crossplane pour les équipes Platform. Une Composition permet de définir des abstractions de haut niveau qui encapsulent la complexité de l'infrastructure. Par exemple, une équipe Platform peut créer une abstraction "PostgreSQLDatabase" qui provisionne automatiquement une instance RDS, configure les security groups appropriés, crée les entrées DNS et génère les secrets Kubernetes contenant les credentials, le tout exposé aux équipes de développement via une interface simplifiée (le Claim).

apiVersion: database.example.org/v1alpha1
kind: PostgreSQLClaim
metadata:
  name: orders-db
  namespace: ecommerce
spec:
  size: medium
  version: "14"

Cette approche permet de créer un véritable self-service où les développeurs provisionnent leur infrastructure sans connaître les détails d'implémentation, tandis que l'équipe Platform garde le contrôle sur les standards et les bonnes pratiques encodés dans les Compositions.

À lire : découvrez notre formation DevOps Engineer

Crossplane face à Terraform

La comparaison entre Crossplane et Terraform est inévitable, ces deux outils adressant le même besoin fondamental : gérer l'infrastructure de manière déclarative. Leurs approches diffèrent cependant significativement, et comprendre ces différences permet de choisir l'outil adapté à chaque contexte.

Terraform fonctionne selon un modèle d'exécution ponctuelle. L'utilisateur lance terraform apply, l'outil calcule les différences entre l'état actuel et l'état désiré, puis applique les changements nécessaires. L'état est stocké dans un fichier (local ou distant) qui doit être partagé et protégé. Cette approche a fait ses preuves et bénéficie d'un écosystème mature avec des milliers de providers et de modules communautaires.

Crossplane adopte un modèle de réconciliation continue, caractéristique des controllers Kubernetes. Une fois une ressource déclarée, Crossplane la surveille en permanence et corrige automatiquement toute dérive. L'état est stocké dans etcd (la base de données de Kubernetes) et bénéficie nativement de la haute disponibilité du cluster. Cette approche élimine le problème classique du state lock et des états désynchronisés.

Le choix entre ces outils dépend largement du contexte organisationnel. Pour les équipes déjà fortement investies dans Kubernetes et adoptant une approche GitOps, Crossplane offre une cohérence remarquable en unifiant la gestion des applications et de l'infrastructure. Pour les organisations avec une expertise Terraform établie ou des besoins d'infrastructure dépassant le périmètre Kubernetes, Terraform reste un choix pertinent.

Il est d'ailleurs courant de voir ces outils coexister : Terraform pour provisionner l'infrastructure fondamentale (le cluster Kubernetes lui-même, les réseaux de base), et Crossplane pour gérer les ressources applicatives consommées par les équipes de développement. Cette approche hybride combine la maturité de Terraform pour les fondations avec la flexibilité de Crossplane pour le self-service au quotidien.

Un aspect différenciant de Crossplane réside dans sa capacité à créer des abstractions personnalisées via les Compositions. Là où Terraform expose directement les ressources des providers (avec leur complexité intrinsèque), Crossplane permet à l'équipe Platform de construire des interfaces simplifiées adaptées aux besoins spécifiques de l'organisation, masquant la complexité tout en garantissant le respect des standards.

À découvrir : notre formation DevOps Engineer

Conclusion

Crossplane représente une évolution naturelle de l'Infrastructure-as-Code pour les organisations qui ont placé Kubernetes au cœur de leur stratégie technique. En transformant le cluster en control plane universel capable de gérer aussi bien les applications que l'infrastructure Cloud, il unifie les outils, les workflows et les compétences autour d'une plateforme unique.

Au-delà de la simplification opérationnelle, Crossplane incarne une vision où les équipes Platform peuvent construire de véritables plateformes self-service internes, exposant des abstractions adaptées aux besoins des développeurs tout en gardant le contrôle sur les standards d'infrastructure. Pour les organisations engagées dans une démarche GitOps et cherchant à réduire la friction entre le développement applicatif et le provisionnement d'infrastructure, Crossplane constitue un investissement stratégique qui s'inscrit dans la continuité logique de l'adoption de Kubernetes.