Construisez une Plateforme Moderne avec Crossplane, Anthos et ArgoCD : L’avenir de la Gestion d’Infrastructures
Dans un monde où les applications conteneurisées et leurs dépendances ne cessent de croître, la gestion des infrastructures cloud devient de plus en plus complexe.
Cet article explore comment adopter une approche GitOps avec Crossplane pour simplifier le déploiement et la maintenance des plateformes cloud modernes. En s’appuyant sur les principes de Kubernetes et en mettant l’accent sur la traçabilité, la collaboration et la détection des drifts de configuration, Crossplane offre une alternative intéressante aux solutions traditionnelles telles que Terraform.
De plus, la portabilité des applications est facilitée grâce à la capacité de Crossplane à définir des abstractions pour les ressources d’infrastructure, simplifiant ainsi la migration et l’adoption de plusieurs clouds. Dans ce contexte, Anthos se révèle être un atout précieux. En tant que plateforme de gestion de clusters Kubernetes hybrides et multicloud de Google, Anthos facilite la gestion unifiée des environnements cloud et sur site, améliore la portabilité des applications et optimise les processus de développement et d’exploitation.
Nous présenterons une architecture intégrant Anthos, Crossplane et ArgoCD pour orchestrer l’infrastructure, garantir la cohérence des configurations et unifier la gestion du cycle de vie des applications et des infrastructures. Ainsi, les équipes travaillant avec Kubernetes pourront bénéficier d’une expérience plus fluide, tout en facilitant la migration et l’adoption de plusieurs environnements cloud.
Construire une plateforme moderne : Les 3 outils incontournables à connaître — Crossplane, Anthos et ArgoCD
Crossplane : Implémenter une approche Gitops pour votre infrastructure
Crossplane est un outil open source permettant de gérer les resources cloud avec Kubernetes et sa logique , Crossplane vous permets de centraliser et de simplifier le déploiements de vos ressources Cloud , d’y appliquer les mêmes logiques de sécurité que dans vos workloads Kubernetes et d’implémenter une approche Full Gitops y compris pour vos services Cloud.
Argocd : Automatisez vos déploiements en toute confiance avec Argo CD
ArgoCD est un outil open source permettant d’implémenter la partie continuous déploiement de vos workloads Kubernetes avec une approche déclarative.
ArgoCD fourni une multitudes de fonctionnalités dans la gestion des environnements , dans les strategies diverses et variées de déploiement ( canary release , A/B Testing , rolling update ) ,
ArgoCD. fourni également une interface web afin de gérer et de visualiser le statut de vos déploiements.
Anthos : Simplifiez la gestion de vos workloads Kubernetes avec Anthos
Anthos est une plateforme hybrid et multicloud vous permettant de déployer et de gérer une large fleet de cluster Kubernetes , d’y assurer la cohérence, la compliance , l’observabilité et le management à l’échelle.
Anthos fourni des fonctionnalités telles que :
- Anthos clusters ( GKE — Anthos on AWS — Anthos on Azure — Anthos on vmware — Anthos edge — anthos bare metal )
- Anthos config management , il s’agit d’un outil orienté Gitops permettant de gérer depuis un ou plusieurs repository git la configuration et la sécurité ( OPA gatekeeper ) de l’ensemble de vos clusters ou qu’ils soient déployés
- Anthos service mesh , comme son nom l’indique il s’agit d’un service mesh géré basé sur istio , déployable n’importe ou
- Anthos connect gateway vous offre la possibilité de simplifier l’authentification et l’authorisation à vos clusters ou qu’ils soient déployer via l’authentification Google cloud.
Zoom sur Crossplane : fonctionnement et spécificités
Crossplane est un outil de gestion d’infrastructure basé sur Kubernetes qui permet de déployer et gérer les ressources cloud de manière déclarative et automatisée. Contrairement à Terraform, Crossplane utilise les API et les principes de Kubernetes pour définir et gérer les ressources d’infrastructure, offrant ainsi une interface unifiée pour les développeurs et les opérateurs.
Les principaux termes utilisés dans Crossplane incluent :
- Provider : Les providers sont des extensions de Crossplane qui permettent de déployer et gérer les ressources d’infrastructures pour différents fournisseurs de services cloud, tels que AWS, GCP, Azure, etc. Documentation
- Custom Resource Definition (CRD) : Les CRD sont des extensions des API Kubernetes pour définir de nouveaux types de ressources d’infrastructure. Documentation
- Managed Resources : Ce sont les instances des CRD qui représentent les ressources d’infrastructure spécifiques à un provider. Documentation
- Composition : Une composition Crossplane est un modèle défini par l’utilisateur qui décrit comment combiner et configurer des ressources gérées pour créer une solution d’infrastructure personnalisée et réutilisable.Documentation
- Claim : Les compositions représentent les demandes d’utilisation des ressources d’infrastructure par les applications. Documentation
- CompositeResourceDefinition (XRD): XRD est dans Crossplane une extension des API Kubernetes qui définit un nouveau type de ressource composite, permettant de créer des abstractions personnalisées pour les ressources d’infrastructure
Pourquoi Crossplane ?
Nous souhaitons fournir d’avantage de flexibilité et de simplicité aux développeurs tout en ayant le controle sur la sécurité et l’architecture.
Offrir aux développeurs la possibilité de consommer des resources Cloud comme n’importe quelle ressource Kubernetes mais cette fois-ci pour leurs besoins en infrastructure, pour ce faire crossplane réponds exactement à notre besoin.
Imaginons qu’une équipe produit à besoin de déployer une application sur GKE avec comme besoins pour cette application :
- Un Bucket cloud storage
- Un service account Google
- Un policy binding de ce service account avec le role roles/storage.objectViewver
- Le setup Workload identity pour le GSA + le KSA fourni par l’équipe produit.
En tant que plateform admin je souhaite fournir une interface simple à mes développeurs afin qu’ils accèdent à ces ressources cloud sur demande.
Pour ce faire,nous allons utiliser les fonctionnalités de Crossplane pour définir un nouvel objet Kubernetes se nommant GkeWiBucket.
Dans un premier temps, nous allons créer une composition Crossplane qui défini une suite logique d’étapes comme vous pourriez le faire avec terraform.
Ce n’est qu’un exemple de code , qui n’est pas du plus optimal.
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: gke-wi-bucket
spec:
compositeTypeRef:
apiVersion: dev.onepoint.org/v1alpha1
kind: XGkeWiBucket
resources:
- name: crossplane-bucket-plateform
base:
apiVersion: storage.gcp.crossplane.io/v1alpha3
kind: Bucket
metadata:
name: test
spec:
forProvider:
location: US
providerConfigRef:
name: default
patches:
- fromFieldPath: spec.location
toFieldPath: spec.forProvider.location
- fromFieldPath: spec.bucketname
toFieldPath: metadata.name
- name: crossplane-bucket-sa
base:
apiVersion: iam.gcp.crossplane.io/v1alpha1
kind: ServiceAccount
metadata:
name: "{{ .inputs.googlesa }}"
spec:
forProvider:
displayName: test
providerConfigRef:
name: default
patches:
- fromFieldPath: spec.googlesa
toFieldPath: metadata.name
- fromFieldPath: spec.googlesa
toFieldPath: spec.forProvider.displayName
####################@
- name: crossplane-bucket-sa-role-binding
base:
apiVersion: iam.gcp.crossplane.io/v1alpha1
kind: ServiceAccountPolicy
metadata:
name: crossplane-bucket-sa-role-binding
spec:
forProvider:
serviceAccountRef:
name: my-top-gsa
policy:
bindings:
- members:
- serviceAccount:vincent-ledan-378413.svc.id.goog[test/vincent-test]
# - serviceAccount:my-top-gsa@vincent-ledan-378413.iam.gserviceaccount.com
role: roles/iam.workloadIdentityUser
providerConfigRef:
name: default
patches:
- fromFieldPath: spec.googlesaid
toFieldPath: spec.forProvider.policy.bindings[0].members[0]
- fromFieldPath: spec.roleserviceaccount
toFieldPath: spec.forProvider.policy.bindings[0].role
- name: crossplane-bucket-sa-role-binding-role
base:
apiVersion: iam.gcp.crossplane.io/v1alpha1
kind: ServiceAccountPolicy
metadata:
name: crossplane-bucket-sa-role-binding-role
spec:
forProvider:
policy:
bindings:
- members:
- serviceAccount:vincent-ledan-11111.svc.id.goog[test/vincent-test]
# - serviceAccount:my-top-gsa@vincent-ledan-378413.iam.gserviceaccount.com
role: roles/storage.objectViewver
providerConfigRef:
name: default
patches:
- fromFieldPath: spec.googlesaid
toFieldPath: spec.forProvider.policy.bindings[0].members[0]
- fromFieldPath: spec.roleserviceaccount
toFieldPath: spec.forProvider.policy.bindings[0].role
Puis créer une CompositeResourceDefinition qui définira le schéma de l’objet à présenter aux développeurs , en voici un exemple :
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xgkewibuckets.dev.onepoint.org
spec:
group: dev.onepoint.org
names:
kind: XGkeWiBucket
plural: xgkewibuckets
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
location:
type: string
bucketname:
type: string
googlesa:
type: string
saname:
type: string
sanamespace:
type: string
roleserviceaccount:
type: string
projectid:
type: string
googlesaid:
type: string
required:
- location
- bucketname
- saname
- sanamespace
- googlesa
- roleserviceaccount
- projectid
- googlesaid
claimNames:
kind: GkeWiBucket
plural: gkewibucketsPuis vous pourrez présenter à vos développeurs le Kind suivant :
apiVersion: dev.onepoint.org/v1alpha1
kind: GkeWiBucket
metadata:
name: claimed-gke-bucket
namespace: test
spec:
location: "US" ### region bucket
bucketname: "vincentledan-test-my-app" ###bucket name
googlesa: "my-top-gsa" ### service account google IAM
roleserviceaccount: "roles/storage.objectViewer" ### role du service account
saname: vincent-kube-sa ### nom du kubernetes account à lié
sanamespace: default ### namespace du Kubernetes service account
projectid: vincent-ledan-1111 ### google project id
googlesaid: my-top-gsa@vincent-ledan-378413.iam.gserviceaccount.com ### nom complet du googlesa Nous venons de voir un exemple concernant les besoins d’une équipe de développeurs et comment fournir as a service des services cloud depuis Kubernetes.
la logique ci-dessus considère que nous étions dans un cluster Multi-tenant , les objets Composition et CompositeResourceDefinition sont cluster scoped et le claim GkeWiBucket est lui namespace scoped ce qui permets de fournir des droits à une équipe dans ce namespace et qu’ils soient autonome pour déployer leurs applications et leurs infrastructures cloud de la même manière.
Guide pratique : Assembler Crossplane, Anthos et ArgoCD pour une plateforme optimisée
Aujourd’hui, l’objectif est d’étendre cette approche à l’échelle de l’organisation.
L’architecture proposée vise à simplifier le déploiement d’applications, principalement sur Kubernetes, renforcer la sécurité grâce à Anthos Config Manager et Policy Controller, et adopter une approche GitOps pour la gestion et le déploiement des ressources cloud en utilisant Crossplane. Nous passerons en revue les étapes essentielles de la construction de cette plateforme
Étape 1 : Initialisation du Control plane
En tant que plateform team nous créons un cluster GKE autopilot avec Anthos config management activé. ACM se chargera de configurer Crossplane et ArgoCD via un repository que vous lui aurez mis à disposition.
Ensuite nous allons par exemple créer une composition Crossplane permettant de créer et configurer un cluster GKE/Anthos et d’utiliser une claim comme précédemment utilisée dans un namespace dédié aux équipes infrastructure.
Concernant l’enregistrement des clusters GKE auprès de ArgoCD , il est possible de centraliser et de ne pas exposer de secrets grace à l’implémentation de Connect Gateway Anthos.
À ce stade votre control plane est configuré de la façon suivante :
- l’authentification entre GKE et ArgoCD passe par la gateway connect Anthos
- Argocd est installé et prêt à l’usage
- 1 projet Argocd est configuré et contient une compostion crossplane pour déployer l’infrastructure GKE.
Étape 2 : Configuration des accès pour les développeurs
Nous allons partir du postulat que nous avons 2 équipes déployant des applications dans 2 clusters régionaux.
l’équipe plateforme configurera les RBAC pour autoriser la team1 à déployer dans le namespace : product1-team et la team2 dans product2-team.
l’équipe plateform configurera également deux projets spécifiques dans ArgoCD et configurera les groupes OIDC pour autoriser les bon droits pour les bonnes équipes dans les bon projets.
Chaque projet Argocd aura des Clusters assignés :
- Projet team1 verra uniquement ses clusters APP1 et APP2
- Projet team2 verra uniquement ses clusters APP3 et APP4
Depuis la version ArgoCD 2.5, il est désormais possible de déployer des Kinds Application directement dans certains namespaces ce qui donne plus d’autonomie et n’oblige pas les utilisateurs à déployer dans le namespace system d’ArgoCD.
Étapes 3 : Stratégie et Configuration des différents repositories Gitlab
Prenons l’exemple de configuration pour l’application APP1 qui doit être déployée dans le cluster APP1.
l’équipe en charge du déploiement créera un repository contenant une CI/CD pour la gestion du helm chart mais également pour déployer via un script ou autre la partie /Argocdconfigs qui contient 2 Kinds Application , une pour déployer l’infrastructure via crossplane et une pour déployer l’application dans le cluster cible.
lorsque que ces deux applications auront été appliquées sur le cluster control plane de config , ArgoCD fera un sync et appliquera les helms chart , la partie infra sera déployer dans le namespace team1 en local et crossplane prendra le relais pour créer et gérer l’infrastructure, et l’application applicative sera déployée directement dans le cluster distant.
À ce stade l’architecture ci-dessous sera en place.
Étape 4: Sécurisé l’ensemble de vos déploiements grâce à Crossplane et Policy controller
Pour finir on peux faire un focus sur la partie Anthos config management et plus particulièrement de la fonctionnalité Policy controller qui est l’implémentation d’OPA Gatekeeper chez google cloud.
Étant donné que l’ensemble des ressources tant infrastructure que applicatives sont désormais gérées par kubernetes nous pouvons facilement implémenter de façon cohérente des règles de compliance as code pour les workloads Kubernetes mais également pour nos customs resources.
Par exemple si nous souhaitons controller le nom des services account GCP créés par notre nouvelle ressource GkeWiBucket , typiquement la valeur de googlesa
apiVersion: dev.onepoint.org/v1alpha1
kind: GkeWiBucket
metadata:
name: claimed-gke-bucket
namespace: test
spec:
.............................
googlesa: "my-top-gsa" ### service account google IAM
.............................Nous pouvons facilement créer la règle OPA suivante.
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: deny-admin-sa
spec:
crd:
spec:
names:
kind: DenyAdminSA
validation:
openAPIV3Schema:
properties:
spec:
properties:
googlesa:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package deny_admin_sa
deny[msg] {
input.kind == "GkeWiBucket"
input.spec.googlesa.startswith("admin.mycompany")
msg := sprintf("Deployment of %v denied because spec.googlesa starts with 'admin.mycompany'", [input.metadata.name])
}
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DenyAdminSA
metadata:
name: deny-admin-sa
spec:
match:
kinds:
- apiGroups: ["dev.onepoint.org"]
kinds: ["GkeWiBucket"]
parameters:
googlesa: "admin.mycompany"
Conclusion
En conclusion, l’adoption d’une approche GitOps et l’utilisation d’outils tels que Crossplane, Anthos et ArgoCD permettent de simplifier la gestion des infrastructures cloud et d’accélérer la mise en place de plateformes modernes. Avec la montée en puissance des pratiques de plateforme engineering, on peut s’attendre à une croissance continue de ces solutions et à une évolution des méthodes de gestion des infrastructures dans les années à venir. Les organisations qui adoptent ces approches innovantes seront mieux positionnées pour relever les défis du futur et tirer pleinement parti des avantages offerts par les technologies modernes.
Je tiens à souligner que cette architecture est largement sujet à discussion , Cet article à pour but de montrer une approche alternative à terraform et aux déploiement plus traditionnel.
