· 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?
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.
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.
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.
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.