TP26 : Platform Engineering : Crossplane et kro

Une équipe plateforme ne veut pas que chaque développeur écrive des dizaines de lignes Terraform et YAML pour obtenir « une application avec son stockage ». Elle préfère lui offrir une API de plateforme simple (kind: WebApp, trois champs) et encoder, une fois pour toutes, les bonnes pratiques derrière cette API. Crossplane étend Kubernetes pour piloter des ressources cloud et les composer en API de haut niveau. kro (Kube Resource Orchestrator) compose des ressources Kubernetes à partir d’un schéma simple et d’expressions CEL. Les ressources AWS sont créées dans Floci (TP13).

Fichiers de départ : crossplane.zip, kro.zip

1. Objectifs pédagogiques

À l’issue du TP, vous serez capable de :

• expliquer le modèle de Crossplane : providers, Managed Resources, ProviderConfig, réconciliation continue ;
• créer une ressource AWS (dans Floci) depuis Kubernetes et observer la correction de dérive ;
• définir une API de plateforme avec une CompositeResourceDefinition (XRD) et l’implémenter avec une Composition (pipeline de fonctions) ;
• composer des ressources avec kro (ResourceGraphDefinition, CEL, includeWhen) ;
• comparer Terraform, Crossplane, kro, Helm et Kustomize.

Les images de cette page sont des schémas explicatifs, pas des captures d’écran.

2. Environnement du TP

• Le cluster K3s du TP14 (≥ 3 Go de RAM libres) et Helm (TP15).

• Floci démarré sur la VM de lab et joignable depuis le cluster (http://<IP-VM-lab>:4566), AWS CLI configuré (TP13).

• Installer Crossplane (ce TP suit le modèle de Crossplane v2 ; vérifiez la version installée avec kubectl get deploy -n crossplane-system crossplane -o jsonpath='{..image}') :

  helm repo add crossplane-stable https://charts.crossplane.io/stable && helm repo update
  helm install crossplane crossplane-stable/crossplane -n crossplane-system --create-namespace
  kubectl get crd | grep crossplane

3. Partie 1 : Providers et ProviderConfig vers Floci

• Installer les providers et la fonction, puis attendre qu’ils soient HEALTHY :

  kubectl apply -f crossplane/10-providers.yaml
  kubectl get providers,functions -w
  kubectl get crd | grep aws.upbound.io | wc -l

• Créer le Secret d’identifiants fictifs (commande en tête de 20-providerconfig-floci.yaml), remplacer l’IP et appliquer.

4. Partie 2 : Première Managed Resource

• Créer le bucket 30-bucket-mr.yaml et vérifier des deux côtés :

  kubectl apply -f crossplane/30-bucket-mr.yaml
  kubectl get managed                       # SYNCED / READY
  kubectl describe bucket tp26-first-bucket
  aws s3 ls | grep tp26

• Dérive : supprimer le bucket avec AWS CLI (aws s3 rb s3://tp26-first-bucket), puis attendre : Crossplane le recrée. Comparer avec Terraform, qui ne corrige la dérive qu’au prochain apply.

• Supprimer la Managed Resource (kubectl delete bucket tp26-first-bucket) : que devient le bucket dans Floci ? Quel champ change ce comportement (deletionPolicy) ?

5. Partie 3 : API de plateforme : XRD et Composition

• Lire 40-xrd.yaml : quel nouveau type est créé ? Quels champs sont validés par le schéma (valeurs par défaut, minimum, maximum) ? Ajouter le champ environment (enum).

• Compléter 50-composition.yaml : la file SQS, le patch de replicas, le Service.

• Appliquer et vérifier :

  kubectl apply -f crossplane/40-xrd.yaml -f crossplane/50-composition.yaml
  kubectl get xrd
  kubectl api-resources | grep webapps

6. Partie 4 : Consommer l’API

• Créer le namespace shop, puis la ressource 60-webapp.yaml : huit lignes pour le développeur.

  kubectl create namespace shop
  kubectl apply -f crossplane/60-webapp.yaml
  crossplane beta trace webapp shop        # arbre des ressources composées (CLI crossplane)
  kubectl -n shop get deploy,svc
  aws s3 ls && aws sqs list-queues

• Tenter replicas: 10 : que répond l’API server ? Où cette règle est-elle définie ?

• Modifier replicas à 3 dans la WebApp : le Deployment suit. Supprimer la WebApp : tout est nettoyé.

• Rédiger quelques lignes sur la différence entre Terraform et Crossplane (modèle d’exécution, état, réconciliation, public visé).

7. Partie 5 : Composer avec kro

• Installer kro en suivant la documentation officielle (chart Helm OCI), puis vérifier : kubectl get crd | grep kro.

• Compléter kro/webapplication-rgd.yaml : sélecteur du Service à partir des labels du Deployment, Ingress conditionnel (includeWhen: ["${schema.spec.ingress.enabled}"]).

• Appliquer la définition puis l’instance :

  kubectl apply -f kro/webapplication-rgd.yaml
  kubectl get resourcegraphdefinitions          # STATE Active
  kubectl get crd | grep webapplications
  kubectl apply -f kro/shop-instance.yaml
  kubectl get webapplications -o wide           # statut calculé : availableReplicas
  kubectl get deploy,svc,ingress -l app=shop-kro

• Passer ingress.enabled à false : l’Ingress disparaît-il ?

8. Partie 6 : Comparaison

• Compléter le tableau, en vous appuyant sur les TP6, TP13, TP15 et ce TP :

Défi

1. Créer une seconde Composition webapp-minimal (sans file SQS) pour la même XRD et choisir entre les deux avec spec.crossplane.compositionSelector (labels).
2. Faire déployer la XRD, la Composition et les WebApp par Argo CD (TP19) : la plateforme elle-même devient GitOps.

9. Livrables

Captures à déposer dans captures/ :

Ainsi que la XRD, la Composition, la RGD complétées et le tableau comparatif.