· overview · 6 min read · Written by Marouane Bouaricha

Introduction à CrossPlane

Comme nous l’avons vu récemment, Crossplane a pris le contrôle du monde de l’ingénierie de plateforme offrant un moyen absolument facile et puissant de construire des contrôle planes natifs dans le cloud. Mais comment cela fonctionne-t-il? Comment puis-je l’utiliser? Quels sont les gains?

Comme nous l’avons vu récemment, Crossplane a pris le contrôle du monde de l’ingénierie de plateforme offrant un moyen absolument facile et puissant de construire des contrôle planes natifs dans le cloud. Mais comment cela fonctionne-t-il? Comment puis-je l’utiliser? Quels sont les gains?

Introduction

Crossplane est une plateforme open-source qui permet la création et la gestion d’applications cloud natives de manière cohérente et évolutive. Il fournit un contrôle plane unifié pour la gestion de l’infrastructure, des services et des applications sur plusieurs fournisseurs de cloud et environnements sur site. Mais qu’est-ce qu’un contrôle plane ?

Les control planes

Une architecture de controle plane/data plane consiste à avoir un composant pour organiser, gérer et observer tout et un autre composant qui est, en fait, les « choses » que le plan de contrôle observe et gère. Pour une meilleure compréhension, nous pouvons parler d’un aéroport et des avions, où les avions sont l’avion de données et la tour de contrôle de l’aéroport est le contrôle plane.

Airport and Crossplane comparison

Nous pourrions donc dire que le plan des données est la valeur commerciale, et le contrôle plane est le cerveau pour qu’il fonctionne correctement. En parlant du monde de l’ingénierie de plateforme, nous utilisons déjà des applications que tout le monde connaît de ce travail sur l’architecture de contrôle plane/ data plane. L’un d’eux est Istio Service Mesh qui est utilisé sur Kubernetes Clusters pour la gestion du trafic, la télémétrie, la sécurité et tout ce qui est lié au réseau.

Isito Architecture

Comme nous pouvons le voir, Istio a contrôle plane qui est responsable de la gestion et de la configuration des proxy pour acheminer le trafic. Le data plane Istio est composé d’un ensemble de proxies (Envoy) qui sont déployés en tant que side-cars, capables de médiatiser et de contrôler toutes les communications réseau entre les microservices.

Pourquoi CrossPlane

Maintenant que nous connaissons le but d’un contrôle plane, vous vous demandez peut-être : pourquoi Crossplane?

Imaginez-vous comme l’équipe de plate-forme d’une grande entreprise et être responsable de soutenir plusieurs équipes avec des problèmes d’infrastructure et d’architecture.

Lorsqu’une équipe a besoin d’un bucket AWS S3 ou d’un compte de stockage Azure, elle doit s’assurer qu’il répond aux exigences de sécurité, y compris l’accès public désactivé et le stockage sécurisé des détails de connexion.

Je suis sûr que vous pensez : ce n’est pas un problème, je peux le gérer en utilisant Terraform!

C’est possible, et je suis aussi un fan de Terraform, mais la mise à l’échelle peut rendre Terraform trop difficile à gérer, et nous nous mettons également sur le chemin critique de nos ingénieurs produits.

Crossplane diffère de Terraform en ce qu’il nous permet d’étendre le plan de contrôle de Kubernetes et de créer de nouvelles API avec lesquelles nos ingénieurs produits peuvent interagir. Ils peuvent créer toutes les ressources dont ils ont besoin, mais nous contrôlons quelles propriétés ils peuvent accéder et lesquelles ils ne peuvent pas.

Concepts Clés

  • Ressources gérées : Crossplane définit les ressources gérées comme toute ressource cloud ou sur site qui peut être créée, gérée et mise à jour via une API déclarative.
  • Définitions de ressources personnalisées (CRD) : Les CRD sont des objets Kubernetes qui définissent le schéma et le comportement des ressources gérées.
  • Contrôleurs : Les contrôleurs sont des composants Kubernetes qui implémentent l’état souhaité des ressources gérées en réconciliant leur état réel avec l’état souhaité défini dans les CRD.
  • Fournisseur : Un fournisseur est un composant qui résume les détails de mise en œuvre d’un fournisseur de cloud ou d’une plateforme d’infrastructure spécifique.

Crossplane Composite Resources

Cas d’usage

CrossPlane peut être utilisé dans divers cas d’utilisation, notamment :

  • Gestion multi-cloud : Gérer l’infrastructure et les applications de plusieurs fournisseurs de cloud de manière cohérente.
  • Gestion du cloud hybride : Combler le fossé entre les environnements cloud et sur site en gérant les ressources dans les deux cas.
  • Gestion du cycle de vie des applications : Automatisez le déploiement, la mise à l’échelle et la gestion des applications dans différents environnements.
  • Infrastructure as Code : Définir et gérer les ressources de l’infrastructure à l’aide de code déclaratif, en assurant la cohérence et la reproductibilité.
  • Service Brokering : Fournir un portail libre-service aux utilisateurs pour qu’ils puissent accéder aux services infonuagiques et les gérer.

QuickStart avec Azure

Prérequis

Ce démarrage rapide nécessite :

  • un cluster Kubernetes avec au moins 2 Go de RAM
  • permissions pour créer des pods et des secrets dans le cluster Kubernetes
  • Version Helm v3.2.0 ou ultérieure
  • un compte Azure avec des permissions pour créer une machine virtuelle Azure et un réseau virtuel
  • un compte Azure avec des permissions pour créer un service principal Azure et un groupe de ressources Azure

Installation de Crossplane

Installation le Helm chart de CrossPlane

helm repo add \
crossplane-stable https://charts.crossplane.io/stable
helm repo update

Installation des composants de CrossPlane utilisant helm install.

helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace

Verifier que Crossplane est installé avec kubectl get pods.

$ kubectl get pods -n crossplane-system
NAME                                      READY   STATUS    RESTARTS   AGE
crossplane-d4cd8d784-ldcgb                1/1     Running   0          54s
crossplane-rbac-manager-84769b574-6mw6f   1/1     Running   0          54s

Installation du Azure provider

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-azure-network
spec:
  package: xpkg.upbound.io/upbound/provider-azure-network:v0.42.1
EOF

Verifier que le provider est installé avec kubectl get providers.

$ kubectl get providers
NAME                            INSTALLED   HEALTHY   PACKAGE                                                  AGE
provider-azure-network          True        True      xpkg.upbound.io/upbound/provider-azure-network:v0.42.1   38s
upbound-provider-family-azure   True        True      xpkg.upbound.io/upbound/provider-family-azure:v0.42.1    26s

Créer un secret Kubernetes pour Azure

az ad sp create-for-rbac \
--sdk-auth \
--role Owner \
--scopes /subscriptions/

Sauvgarder le retour Azure JSON en azure-credentials.json

Créer un secret Kubernetes avec les informations d’identification Azure

kubectl create secret \
generic azure-secret \
-n crossplane-system \
--from-file=creds=./azure-credentials.json

Creation d’un ProviderConfig

Un ProviderConfig personnalise les paramètres du fournisseur Azure. Appliquer la commande ProviderConfig avec :

cat <<EOF | kubectl apply -f -
apiVersion: azure.upbound.io/v1beta1
metadata:
  name: default
kind: ProviderConfig
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: azure-secret
      key: creds
EOF

Cela attache les informations d’identification Azure, enregistrées comme un secret Kubernetes, comme un secretRef.

Creation d’une ressource managée

Cet exemple crée un réseau virtuel Azure avec Crossplane. Le réseau virtuel est une ressource managée.

cat <<EOF | kubectl create -f -
apiVersion: network.azure.upbound.io/v1beta1
kind: VirtualNetwork
metadata:
  name: crossplane-quickstart-network
spec:
  forProvider:
    addressSpace:
      - 10.0.0.0/16
    location: "West Europe"
    resourceGroupName: myresourceGroup
EOF

Verifier que Crossplane a créer le réseau virtuel.

$ kubectl get virtualnetwork.network
NAME                            READY   SYNCED   EXTERNAL-NAME                   AGE
crossplane-quickstart-network   True    True     crossplane-quickstart-network   10m

Supprimer la ressource managée

Utilisez kubectl delete virtualnetwork.network pour supprimer le réseau virtuel.

$ kubectl delete virtualnetwork.network crossplane-quickstart-network
virtualnetwork.network.azure.upbound.io "crossplane-quickstart-network" deleted

Conclusion

Alors que Crossplane continue d’évoluer, nous pouvons nous attendre à voir encore plus de cas d’utilisation innovants et d’intégrations avec d’autres technologies cloud natives. Sa nature open source et sa communauté active garantissent que Crossplane restera un outil précieux pour la gestion des applications et de l’infrastructure cloud natives pour les années à venir.

Références

  1. End-to-End Automation with Kubernetes and Crossplane
  2. https://docs.crossplane.io/
Back to Blog