ArgoCD ressources CRDs Application et ApplicationSet

ArgoCD CRDs

• Application
• ApplicationSet

---

Application

L'objet Application est au cœur d'ArgoCD. Il définit ce qui doit être déployé et où.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  
  # Source des manifestes
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
    
    # Configuration Helm (optionnelle)
    helm:
      valueFiles:
      - values-prod.yaml
      parameters:
      - name: replicaCount
        value: "3"
      
  # Destination de déploiement
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
    
  # Stratégie de synchronisation
  syncPolicy:
    automated:
      prune: true      # Supprime les ressources qui ne sont plus dans Git
      selfHeal: true   # Rectifie les déviations
      allowEmpty: false # Empêche la suppression de toutes les ressources
    syncOptions:
    - CreateNamespace=true
    - PrunePropagationPolicy=foreground
    - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m
        
  # Ignorer certaines différences
  ignoreDifferences:
  - group: apps
    kind: Deployment
    jsonPointers:
    - /spec/replicas
  - group: ""
    kind: Service
    jsonPointers:
    - /spec/clusterIP

 

On peut egalement indiquer des fichiers values from un autre repo git

  sources:
  - repoURL: "registry.techledger.io:10025/charts"
    targetRevision: 0.6.5
    chart: api-chart
    helm:
      # Select the required values file according to your environment
      valueFiles:
      - $values/api/api-values/api-values.yaml
  - repoURL: git@git.techledger.io:gitops/helm-values/apis-values.git
    targetRevision: main
    ref: values

 

• L'objet Application offre de nombreuses options de configuration :
  • source : Définit l'emplacement des manifestes (Git, Helm, Kustomize, etc.)
  • destination : Spécifie le cluster et le namespace cible
  • syncPolicy : Configure le comportement de synchronisation automatique
  • ignoreDifferences : Permet d'ignorer certaines différences entre l'état souhaité et l'état réel
• Fonctionnalités avancées des Applications :
  • Support pour les hooks de synchronisation (PreSync, Sync, PostSync)
  • Ordonnancement précis des déploiements avec les ondes de synchronisation (sync waves)
  • Intégration avec des outils comme Kustomize ou Helm
  • Annotations et libellés pour l'intégration avec d'autres systèmes

 

Exemple de deploiement d'une application

• Cette argo nginx-web-server.yaml  va deployer nginx web server avec 3 replicas sur e cluster rke2-tools-dev

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-server  # le nom qu'on donne au crd
  namespace: argocd # toujours deployer cet abjet dans le namesapce ou argocd est déployé
spec:
  project: web-server # cette argo app sera dans le argo poject default
  source:
    chart: nginx # le nom du chart telque definit dans le chart bitnami
    repoURL: registry-1.docker.io/bitnamicharts # le repo du chart bitnami
    targetRevision: 20.0.2  # la version du chart nginx
    helm:
      valuesObject:
        replicaCount: 3
        service:
          type: LoadBalancer  # ClusterIP
  destination:
    name: rke2-tools-dev # cluster downstream destination
    namespace: web-server  # namesapce ou l'application gnixn sera deployée
  syncPolicy:
    automated:
      prune: true      # Supprime les ressources qui ne sont plus dans Git
      selfHeal: true   # Rectifie les déviations
      allowEmpty: false # Empêche la suppression de toutes les ressources  
    syncOptions:
    - CreateNamespace=true   # Argocd crée automatiquement le namespace
    - PrunePropagationPolicy=foreground
    - PruneLast=true    

 

• Appliquer le fichier nginx-web-server.yaml sur le cluster argo

kubectl apply -f nginx-web-server.yaml

 

 

 

Sur l'ui d'argo je peu filter par projet ou par cluster ...

 

• Pour supprimer

kubectl delete -f nginx-web-server.yaml

 

App of Apps

• Similaire à ApplicationSet, c'est une stratégie où une application Argo CD (souvent nommée root-app, bootstrap, ou main-app) déclare d'autres applications Argo CD dans ses manifests YAML (souvent dans un répertoire git apps/).

• Cette approche permet de centraliser le déploiement d’un ensemble d’applications gérées chacune indépendamment par Argo CD.

 

ApplicationSet

L'objet ApplicationSet permet de gérer plusieurs Applications ArgoCD à grande échelle. Il est particulièrement utile dans les environnements multi-clusters ou multi-tenants.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
  namespace: argocd
spec:
  generators:
  # Génération basée sur des clusters
  - clusters:
      selector:
        matchLabels:
          environment: production
  
  # Génération basée sur des listes
  - list:
      elements:
      - cluster: engineering-dev
        url: https://kubernetes.dev.example.com
      - cluster: engineering-staging
        url: https://kubernetes.staging.example.com
      - cluster: engineering-prod
        url: https://kubernetes.prod.example.com
 
  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps.git
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{url}}'
        namespace: guestbook
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

 

Les ApplicationSets introduisent le concept de générateurs, qui créent dynamiquement des Applications ArgoCD :

1. Générateur Cluster :
   • Crée une Application pour chaque cluster enregistré dans ArgoCD
   • Peut filtrer les clusters par labels
2. Générateur List :
   • Définit explicitement une liste de valeurs pour générer des Applications
   • Flexible pour toute structure de données
3. Générateur Git :
   • Génère des Applications basées sur la structure des répertoires dans un repository Git
   • Idéal pour les approches basées sur les pull requests
4. Générateur Matrix :
   • Combine plusieurs générateurs pour créer un produit cartésien de configurations
   • Particulièrement puissant pour les déploiements complexes

Les ApplicationSets permettent d'implémenter des modèles de déploiement avancés :

• Déploiement progressif à travers plusieurs clusters
• Gestion centralisée de configurations spécifiques à l'environnement
• Applications multi-tenants avec isolation des ressources
• Automatisation complète du cycle de vie des applications

Les ApplicationSets sont au cœur des déploiements à grande échelle avec ArgoCD, permettant d'appliquer les principes GitOps de manière cohérente à travers des environnements multiples et complexes.

 

Exemple de deploiement d'une applicationSet

• On va deployer nginx web server sur 3 cluster avec applicationSet, au lieu de créer 3 argo app, on va créer une seule applicationset qui va generer les 3 argo app pour les 3 clusters.
• On crée 2 cluster rke2 plus le cluster argo pour completer à 3
• Pour créer les 2 clusters, suivre ces etapes
  • Créer 2 vm avec 2vCPU et 3 GB de ram
  • Executer les commandes suivantes sur chaque vm

# server node
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE="server" INSTALL_RKE2_VERSION="v1.32.4+rke2r1" sh -

systemctl enable rke2-server.service

sudo mkdir -p /etc/rancher/rke2

sudo tee /etc/rancher/rke2/config.yaml << EOF
token: JDKJDKJFDkdklfdlkdf14528654455211566332
disable:
  - rke2-ingress-nginx
EOF

systemctl start rke2-server.service

 

• Recuperer le kubeconfig

cat /etc/rancher/rke2/rke2.yaml

 

• Créer le sa et generer le token d'acces au cluster downstream. A appliquer sur les 2 clusters downstream

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd-manager
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: argocd-manager-binding
subjects:
- kind: ServiceAccount
  name: argocd-manager
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Secret
metadata:
  name: argocd-manager-token
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: argocd-manager
type: kubernetes.io/service-account-token

 

• Créer le secret argocd pour chaque cluster downstream et l'appliquer sur le cluster à argo

# server
kubectl config view --raw --minify --flatten --output='jsonpath={.clusters[].cluster.server}'

# bearerToken
kubectl -n kube-system get secret argocd-manager-token --output='go-template={{ .data.token }}' | base64 --decode

# caData
kubectl -n kube-system get secret argocd-manager-token --output='go-template={{ index .data "ca.crt" }}'

 

apiVersion: v1
kind: Secret
metadata:
  name: argocd-<nom-cluster>-secret
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: <nom-cluster>
  server: <api-server-end-point>
  config: |
    {
      "bearerToken": <bearerToken>,
      "tlsClientConfig": {
        "insecure": false,
        "caData": "<caData-base64>"
      }
    }

 

• Appliquer chaque secret sur le cluster argocd. Les cluster seront visiblent sur l'ui argo

 

• On peut maintenant ecrire notre applicationset.yaml et l'appliquer sur le cluster argocd

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: web-server
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - list:
      elements:
      - cluster: techledger-cluster-preprod
      - cluster: techledger-cluster-prod
      - cluster: rke2-tools-dev
  template:
    metadata:
      name: '{{.cluster}}-web-server'
    spec:
      project: web-server # cette argo app sera dans le argo poject default
      source:
        chart: nginx # le nom du chart telque definit dans le chart bitnami
        repoURL: registry-1.docker.io/bitnamicharts # le repo du chart bitnami
        targetRevision: 20.0.2  # la version du chart nginx
        helm:
          valuesObject:
            replicaCount: 1
            service:
              type: ClusterIP
      destination:
        name: '{{.cluster}}'
        namespace: web-server  # namesapce ou l'application gnixn sera deployée
      syncPolicy:
        automated:
          prune: true      # Supprime les ressources qui ne sont plus dans Git
          selfHeal: true   # Rectifie les déviations
          allowEmpty: false # Empêche la suppression de toutes les ressources  
        syncOptions:
        - CreateNamespace=true   # Argocd crée automatiquement le namespace
        - PrunePropagationPolicy=foreground
        - PruneLast=true        

 

• Appliquer sur le cluster argocd

kubectl apply -f applicationset.yaml

 

• L'applicationset a generé automatiquement les argocd app en ciblant chaque cluster

 

• Supprimer l'applicationset

kubectl delete -f applicationset.yaml

 

On peut aussi cibler un repertoir en fonction d'un pattern.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: comm-external-dns
spec:
  goTemplate: true
  generators:
  - list:
      elements:
      - cluster: k8s-engineering-dev
        foo: bar
      - cluster: k8s-engineering-prod
        foo: baz
  template:
    metadata:
      name: '{{.cluster}}-external-dns'
      labels:
        foo: '{{.foo}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/argo-cd.git
        targetRevision: HEAD
        path: applicationset/examples/list-generator/comm-app/{{.cluster}}
      destination:
        server: '{{.url}}'
        namespace: external-dns
  syncPolicy:
    applicationsSync: create-update