Crossplane ou la combination d'opérateurs

Dans ce nouvel épisode de la série sur les opérateurs Kubernetes, on va parler d'un opérateur qui existe déjà : Crossplane.

Qu'est-ce que Crossplane ?

Crossplane est un opérateur Kubernetes qui permet de gérer depuis Kubernetes des ressources dans différents cloud provider. (AWS, GCP ...)

Ca signifie que depuis votre cluster Kubernetes, vous pouvez créer des ressources dans un cloud Provider.

L'exemple suivant permet de créer un bucket S3 dans AWS

apiVersion: s3.aws.upbound.io/v1beta1 
kind: Bucket 
metadata: 
    generateName: crossplane-bucket- 
    labels:
        docs.crossplane.io/example: provider-aws 
spec: 
    forProvider:
        region: us-east-2 
    providerConfigRef: 
        name: default

Les possibilités deviennent dingues non?

Comment l'installer?

Si vous êtes intéressés pour installer Crossplane sur votre cluster et l'utiliser, je vous invite à regarder les liens suivants, la documentation est très bien :

• Setup pour AWS
• Setup pour Azure
• Setup pour GCP

Utiliser crossplane depuis un autre opérateur?

Vu qu'on peut installer Crossplane sur notre cluster Kubernetes, toutes ses ressources personnalisées sont donc disponibles sur le cluster. Par conséquent votre opérateur peut gérer la création/mise à jour de ces ressources.

Dans les articles précédents de cette série, on a mentionné le fait qu'un opérateur pouvait nous permettre de faciliter la gestion de déploiements Grafana, Prometheus, Postgres et OpenTelemetry. Sachant que les 3 premiers font partis des services mis à disposition dans AWS, ça veut dire que dans votre opérateur vous pourriez créer dynamiquement les ressources pour vos clients dans AWS !

Note: Pour l'ensemble des exemples suivants, je ne parlerais que d'AWS, mais tout est disponible pour les autres cloud providers.

Télécharger les librairies

La première chose à faire est de télécharger les librairies crossplane dans votre projet

go install github.com/crossplane-contrib/provider-aws 
go install github.com/crossplane/crossplane-runtime

Elles vont vous permettre d'accéder à l'ensemble des ressources communes de Crossplane, ainsi qu'à toutes les ressources spécifiques à AWS.

Gérer les schémas

Dans le fichier main.go, il y a la déclaration de la fonction init que l'on a pas mal ignoré jusqu'à présent.

func init() {  
   utilruntime.Must(clientgoscheme.AddToScheme(scheme))  
}

Déclarée ainsi (en simplifiant vulgairement), elle donne accès à l'opérateur à l'ensemble des ressources de bases Kubernetes via la méthode AddToScheme.

Par conséquent, si on veut accéder à des ressources qui ne font pas partie des éléments de base, il faut ajouter une nouvelle déclaration.

import (
    crossplane "github.com/crossplane-contrib/provider-aws/apis"
)

func init() {  
    utilruntime.Must(clientgoscheme.AddToScheme(scheme))    
    utilruntime.Must(crossplane.AddToScheme(scheme))
}

Fonctionnant toujours avec le même format, il faut aller importer la méthode AddToScheme de la librairie contenant les ressources qui vous intéresse et l'appeler dans la fonction init.

RBAC

C'est quelque chose d'important à ne pas oublier! Aller ajouter les annotations dont vous avez besoin pour autoriser votre opérateur à utiliser ces nouvelles ressources.

Utilisation des nouvelles ressources

Maintenant que vous avez fait tout ce qu'il fallait pour permettre à votre opérateur d'utiliser ces nouvelles ressources, vous pouvez les utiliser dans vos traîtements!

Exemple

import (
    "github.com/crossplane-contrib/provider-aws/apis/s3/v1beta1"
)

...
    myBucket := &v1beta1.Bucket{}
    err := r.Get(ctx, req.NamespacedName, myBucket)
...

Conclusion

Au final dans cet article, on aura vu qu'il était possible de combiner des opérateurs avec l'exemple de Crossplane. Et des opérateurs il en existe beaucoup! Datadog, Grafana, Kong ou encore Litmus Chaos pour ne citer que ceux-là!

Si vous en cherchez, le meilleur endroit à regarder est Operatorhub.io.

Mais au final cette imbrication d'opérateurs permet de développer beaucoup de choses bien plus facilements, tels des microservices qui ont chacun un scope précis. Donc imaginez tout ce qui peut être possible au niveau de l'automatisation!

Et justement, on va parler de ça dans la dernière partie de cette série où on va parler de Crossplane vs Terraform.

J'espère que ça vous aidera et si jamais vous avez des questions, quelles qu'elles soient (Il n'y a jamais de questions bêtes!) ou des points qui ne sont pas clairs pour vous, n'hésitez pas à laisser un message dans les commentaires ou à me joindre directement sur LinkedIn (même pour parler d'autres sujets!).