Crossplane — Panorama
| Fiche express | |
|---|---|
| Type | Control plane déclaratif cloud-native (dans Kubernetes) |
| Statut | Projet CNCF gradué (octobre 2025), v2 |
| Équivalent de | Terraform, en mode continu plutôt que ponctuel |
| État | Aucun fichier de state : vit dans l'API Kubernetes (etcd) |
| Voir aussi | Terraform — Concepts fondamentaux · Frontière IaC — Terraform, Ansible, GitOps · Glossaire cloud-native |
Crossplane est l'équivalent déclaratif cloud-native de Terraform : il transforme Kubernetes en plan de contrôle universel pour provisionner et réconcilier de l'infrastructure via des API déclaratives. Projet CNCF gradué (octobre 2025), version majeure v2. Cette page situe l'outil et indique quand la discussion se justifie.
Idée centrale
Là où Terraform exécute un plan/apply ponctuel et conserve un state, Crossplane installe des controllers dans un cluster Kubernetes qui réconcilient en continu l'état souhaité (exprimé en ressources custom) vers l'infrastructure réelle. Il n'y a pas de fichier de state distinct : l'état vit dans l'API Kubernetes (etcd) et le drift est corrigé automatiquement, comme pour un Deployment.
<mermaid> flowchart LR
DEV[Développeur] -->|kubectl apply
claim: Database| API[API Kubernetes] API --> XP[Controllers Crossplane] XP -->|provider AWS/Azure/vSphere...| CLOUD[(Infra réelle)] XP -.réconciliation continue.-> CLOUD
</mermaid>
Composants
- Providers — étendent l'API K8s avec des types de ressources managées (VPC, base, bucket, cluster). Un provider
terraformpermet même de réutiliser des modules Terraform existants. - Managed Resources — objets d'infra unitaires réconciliés.
- Compositions / XRDs — abstractions de plateforme : on expose une API métier (
Environment,Database) et une composition traduit en ressources concrètes. C'est le cœur de l'usage « plateforme interne / self-service ».
Terraform vs Crossplane
| Critère | Terraform | Crossplane |
|---|---|---|
| Exécution | Ponctuelle (apply CLI/CI) | Continue (controllers in-cluster) |
| État | Fichier de state | API Kubernetes (etcd) |
| Drift | Détecté au prochain plan | Corrigé en continu |
| Interface | HCL + CLI | CRD + kubectl/GitOps |
| Public cible | Ops/infra | Équipes plateforme exposant du self-service |
| Courbe | Modérée, écosystème mûr | Plus raide (compositions, débogage controllers) |
Quand la discussion se justifie
- On construit une plateforme interne (IDP) offrant du self-service infra aux équipes, piloté en GitOps.
- On veut drift auto-corrigé et cohérence multi-cloud via une API homogène.
- On standardise déjà tout autour de Kubernetes.
Quand rester sur Terraform
- Provisionnement ponctuel, équipe réduite, écosystème/modules déjà en place.
- Périmètre hors Kubernetes (pas de cluster « socle » à héberger le control plane).
- Volonté d'éviter la complexité opérationnelle des compositions.
Note : les deux ne s'excluent pas. Crossplane peut piloter des modules Terraform (provider-terraform), servant de couche de réconciliation au-dessus de l'existant.