Aller au contenu
  1. Docs/
  2. K3s Kubernetes/

Argocd

·Temps de lecture : 8 minutes· loading · loading · ·
K3s Kubernetes ArgoCD GitOps DevOps CI/CD MetalLB Helm
ksh2177
Auteur
ksh2177
Ingénieur DevOps passionné par l’automatisation, la fiabilité et le design système.
Table des matières

🤔 Qu’est-ce qu’Argo CD ?
#

Les définitions, configurations et environnements d’application doivent être déclaratifs et contrôlés par version. Le déploiement et la gestion du cycle de vie des applications doivent être automatisés, vérifiables et faciles à comprendre.

Ainsi, Argo CD recherche dans le référentiel Git des fichiers .yaml, helm charts etc.. et les déploie sur votre Kubernetes. Vous pouvez ensuite facilement déployer vos applications sur un ou plusieurs clusters. Les fichiers .yaml seront bien sous le contrôle de Git et vous pourrez voir les modifications en arrière dans le temps. Fini les dossiers remplis de fichiers.

Il a une interface utilisateur agréable et, ce qui est un gros avantage, il suit si votre application est réellement déployée, ne se contente pas de déclencher le déploiement et de l’oublier. Mais il garde une trace. Vous donne même un accès facile aux journaux de pod depuis l’interface utilisateur.

Argo CD s’exécute dans votre cluster Kubernetes, ce qui correspond tout à fait à ma philosophie, qui consiste à conserver tout ce qui est contenu dans Kubernetes. Cela contribue également à la sécurité, vous n’avez pas besoin de fournir le fichier de configuration kubectl à qui que ce soit.

🧩 Installer Argo CD
#

#Créez un namespace
root@control00:~# kubectl create namespace argocd
#Installez comme sur n'importe quel autre cluster
root@control00:~# kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Après le déploiement, vous devriez voir les pods suivants :

root@control00:~# kubectl get pods  -n argocd
NAME                                                 READY   STATUS    RESTARTS   AGE
argocd-application-controller-0                     1/1     Running   0          3m54s
argocd-applicationset-controller-744b76d7fd-hwr28   1/1     Running   0          3m57s
argocd-dex-server-5bf5dbc64d-m7z6r                  1/1     Running   0          3m57s
argocd-notifications-controller-84f5bf6896-dh6kc    1/1     Running   0          3m56s
argocd-redis-74b8999f94-fr5nf                       1/1     Running   0          3m56s
argocd-repo-server-57f4899557-4cvn2                 1/1     Running   0          3m56s
argocd-server-7bc7b97977-77gkv                      1/1     Running   0          3m55s

Et les services suivants :

root@control00# kubectl get svc -n argocd
NAME                                          TYPE        CLUSTER-IP      EXTERNAL-IP        PORT(S)             AGE
argocd-applicationset-controller          ClusterIP   10.43.251.189   <none>        7000/TCP,8080/TCP            3m10s
argocd-dex-server                         ClusterIP   10.43.14.220    <none>        5556/TCP,5557/TCP,5558/TCP   3m9s
argocd-metrics                            ClusterIP   10.43.80.82     <none>        8082/TCP                     3m9s
argocd-notifications-controller-metrics   ClusterIP   10.43.210.27    <none>        9001/TCP                     3m9s
argocd-redis                              ClusterIP   10.43.3.127     <none>        6379/TCP                     3m9s
argocd-repo-server                        ClusterIP   10.43.194.228   <none>        8081/TCP,8084/TCP            3m9s
argocd-server                             ClusterIP   10.43.91.70     <none>        80/TCP,443/TCP               3m8s
argocd-server-metrics                     ClusterIP   10.43.88.157    <none>        8083/TCP                     3m8s

Puisque j’utilise metallb, je souhaite attacher une adresse IP externe à l’interface utilisateur. Je vais modifier le service existant argocd-server en le corrigeant.

root@control00:~# kubectl patch service argocd-server -n argocd --patch '{ "spec": { "type": "LoadBalancer", "loadBalancerIP": "192.168.1.208" } }'

Je viens d’ajouter type: LoadBalancer et loadBalancerIP. Vous pouvez faire la même chose en patchant directement le service avec la commande :

Vérifiez ensuite le service :

root@control00:~/argo_cd# kubectl get svc -n argocd
NAME                                           TYPE              CLUSTER-IP      EXTERNAL-IP     PORT(S)                         AGE
argocd-applicationset-controller             ClusterIP          10.43.7.236     <none>          7000/TCP,8080/TCP                3h7m
argocd-dex-server                            ClusterIP          10.43.231.214   <none>          5556/TCP,5557/TCP,5558/TCP       3h7m
argocd-metrics                               ClusterIP          10.43.79.79     <none>          8082/TCP                         3h7m
argocd-notifications-controller-metrics      ClusterIP          10.43.47.65     <none>          9001/TCP                         3h7m
argocd-redis                                 ClusterIP          10.43.98.160    <none>          6379/TCP                         3h7m
argocd-repo-server                           ClusterIP          10.43.61.116    <none>          8081/TCP,8084/TCP                3h7m
argocd-server-metrics                        ClusterIP          10.43.234.98    <none>          8083/TCP                         3h7m
argocd-server                              LoadBalancer         10.43.240.143   192.168.1.208   80:30936/TCP,443:32119/TCP       3h7m

J’ai maintenant accès à l’interface utilisateur sous IP : 192.168.1.208 et port : 80 mais cela basculera 443 de toute façon.

Argo UI
Argo UI

Nom d’utilisateur : admin et mot de passe générés aléatoirement. Voici comment procéder :

root@control00:~/argo_cd# kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
Argo CD n’utilise pas le mot de passe de ce secret. Il le stocke simplement pour que vous puissiez l’obtenir. Connectez-vous à l’interface utilisateur ou via CLI et remplacez-le par le vôtre. Vous pouvez ensuite supprimer le secret.
Login Argo
Login Argo

📥 Installer l’outil CLI Argo CD
#

Nous pouvons installer l’outil Argo CD CLI en suivant les étapes suivantes :

root@control00:~/argo_cd# curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-arm64
root@control00:~/argo_cd# chmod +x /usr/local/bin/argocd

Connectez-vous à l’IP du serveur argo, dans mon cas 192.168.1.208 :

root@control00:~/argo_cd# argocd login 192.168.1.208
WARNING: server certificate had error: x509: cannot validate certificate for 192.168.1.208 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y
Username: admin
Password:
'admin:login' logged in successfully
Context '192.168.1.208' updated

Lister les serveurs argo :

root@control00:~/argo_cd# argocd cluster list
SERVER                          NAME        VERSION  STATUS   MESSAGE                                                  PROJECT
https://kubernetes.default.svc  in-cluster           Unknown  Cluster has no applications and is not being monitored.

Vous pouvez voir le statut Unknown, mais cela devrait changer dès que nous essayons de déployer quelque chose.

🚀 Déploiement des tests
#

Juste pour nous assurer que tout fonctionne, nous allons déployer une hello world application simple. Argo CD, comme son nom l’indique, est un CD. Un outil de livraison continue. Il ne construit pas votre application, ne crée pas d’image Docker et ne la pousse pas vers le registre. Il déploie simplement votre application et surveille son état d’exécution. De plus, il mettra à jour votre application si le déploiement change. Je suis actuellement à la recherche de la partie CI, qui pourrait résider dans mon cluster Kubernetes, comme Argo.

Mais pour l’instant, nous allons faire aussi simple que possible.

✅ Créer un nouveau dépôt
#

Créez un dépôt git avec votre projet (Argo CD accepte YAML, les graphiques Helm, etc.) dans GitHub, GitLab ou tout autre fournisseur git que vous utilisez. Je devrai peut-être créer une page helm spéciale, juste pour parler des graphiques Helm. C’est assez intéressant, et vous voudrez peut-être l’utiliser. Mais pour cet exemple, je n’utiliserai que des fichiers YAML.

Et là-dedans, j’ai créé un dossier appelé hello-world. L’idée est que vous devez pointer le CD Argo vers un répertoire, il n’aime pas utiliser la racine du dépôt git.

Notre déploiement est une image officielle de Docker NGINX Hello World . Elle prend en charge l’architecture arm64, donc pas besoin de travailler plus dur.

Dans notre dossier git/, j’ai ajouté les fichiers suivants :

deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-world
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - image: nginxdemos/hello
        name: hello-world
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "384Mi"
            cpu: "500m"
        ports:
        - containerPort: 80
          protocol: TCP
          name: hello-world

Un service pour que nous puissions accéder aux répliques : service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  selector:
    app: hello-world
  type: LoadBalancer
  ports:
    - name: hello-world
      protocol: TCP
      port: 80
      targetPort: 80
  loadBalancerIP: 192.168.1.209

Rien de spécial, il devrait créer une réplique en cours d’exécution de l’application NGINX hello-world, qui, si elle accède au port 80 via un navigateur, devrait renvoyer des informations de base sur le nœud sur lequel elle s’exécute. Et le service lui attribuera l’IP : 192.168.1.209. Cela devrait suffire à nous lancer.

🆕 Nouvelle application sur Argo CD
#

Accédez maintenant à l’interface utilisateur du CD Argo et créez une nouvelle application. Nous pourrions utiliser la CLI et tout définir sur une seule ligne, mais de cette façon, ce que nous faisons est plus clair visuellement. Vous pouvez toujours utiliser la CLI pour tout faire plus tard.

New App
New App

Et commencez à remplir les bases.

  • Application Name : hello-world - Faites attention à ce que vous tapez ici, utilisez des minuscules et pas d’espaces.
  • Project Name : default - Vous ne pouvez sélectionner que le projet que vous avez créé ou default. Plus d’informations ici
  • CAuto-create namespace: : yes - J’ai coché cette case pour créer un nouvel espace de noms pour l’application.
  • Cluster URL : https://kubernetes.default.svc - Il s’agit de l’URL interne du cluster, elle doit exister par défaut dans notre cluster k3s.

Le reste est assez explicite.

Create App
Create App

Cliquez Create en haut à gauche. Vous devriez obtenir la page suivante :

App Created
App Created

Comme je n’ai pas défini la synchronisation automatique sur yes, je dois synchroniser manuellement l’application. Appuyez sur le bouton Sync puis à nouveau sur le haut Synchorize.

App Sync
App Sync

Après un certain temps (il faut télécharger l’image), vous devriez voir ce qui suit:

App Synced
App Synced

Cool, non ? Mais ce n’est pas tout ! Cliquez sur la case avec le nom de l’application et vous devriez voir ce qui suit :

App Details
App Details

Cliquez sur chaque case et vous obtiendrez plus d’informations sur chaque partie de l’application et du déploiement. Vous pouvez même obtenir des journaux à partir des conteneurs, ce qui est très pratique.

Allez également vérifier l’IP de l’application via le navigateur.

nginx OK
NGINX OK

♾️ Livraison continue
#

Passons maintenant à la magie de la livraison continue. Cliquez sur App Details en haut à gauche. Ensuite Edit , en bas, il y a une optionSYNC POLICY, activez-la. Cela fera que Argo CD recherchera périodiquement (je pense que c’est toutes les 3 à 5 minutes) ce git et appliquera les modifications que vous y avez apportées.

!!! info "" N’oubliez pas de sauvegarder les modifications que vous avez apportées, en haut.

Maintenant, accédez aux fichiers de déploiement dans git et modifiez une ligne.

replicas: 1

à

replicas: 2

Appuyez et attendez, ArgoCD devrait effectuer les modifications sur le cluster.

App Replicas
App Replicas

Cliquez également sur les différentes vues en haut à droite, vous en serez ravi.

💡 Exemple
#

Je suis en train de tout déplacer dans GitOps Argo CD pour mon cluster Kubernetes. Tout ce que j’ai déployé manuellement dans ce guide sera éventuellement géré via GitOps et Argo CD. Il y a encore quelques problèmes, par exemple Argo CD en ce moment, avant la version 2.5, il n’autorise pas de valeurs.yaml distinctes pour le graphique Helm et nécessite qu’il soit dans le même référentiel que le graphique Helm. Ce qui est un problème, car si vous comptez utiliser l’emplacement du référentiel officiel, vous ne pouvez pas modifier ce fichier…

Argo All App
Argo All App

Il y a beaucoup de choses que vous pouvez faire et configurer, mais je dois m’arrêter ici. C’est déjà un guide assez long, et les bases pour vous aider à démarrer sont ici. Vous pouvez continuer avec le manuel officiel si vous le souhaitez.

Maintenant, fais une pause, mange et bois un peu de café. Et peut-être que tu pourras m’en apporter un aussi.

Articles connexes

Network settings
·Temps de lecture : 4 minutes· loading · loading
K3s Kubernetes MetalLB LoadBalancer Helm Network ClusterIP Homelab DevOps
Déploiement de MetalLB pour gérer des adresses IP externes avec K3s : installation via Helm, configuration d’un pool d’IP et vérifications réseau.
Docker registry setup
·Temps de lecture : 11 minutes· loading · loading
K3s Kubernetes Docker Registry TLS Longhorn MetalLB DevOps
Installation d’un registre Docker privé avec TLS via MetalLB, stockage persistant Longhorn et configuration K3s complète pour le push d’images depuis le cluster.
Helm arkade
·Temps de lecture : 2 minutes· loading · loading
K3s Kubernetes Helm Arkade Package Manager CLI Tools DevOps Homelab
Installation de Helm et Arkade sur le cluster K3s : deux outils indispensables pour déployer et gérer des applications Kubernetes simplement.
Docker setup
·Temps de lecture : 2 minutes· loading · loading
K3s Kubernetes Docker OpenFaaS ARM64 Registry Buildx Homelab DevOps
Installation de Docker avec support multi-arch sur DietPi pour builder localement des fonctions OpenFaaS en arm64 et publier sur un registre privé.
Storage settings
·Temps de lecture : 9 minutes· loading · loading
K3s Kubernetes Storage Longhorn Ansible Raspberry Pi PersistentVolume DevOps Homelab
Choix, préparation et installation de Longhorn comme solution de stockage persistant Kubernetes pour K3s sur Raspberry Pi, avec montage automatique via Ansible.
Os settings
·Temps de lecture : 1 minutes· loading · loading
K3s Kubernetes DietPi Linux OS Iptables Ansible Homelab DevOps
Réglages système post-installation pour DietPi : mise à jour de l’OS, configuration réseau, iptables et préparation à Kubernetes.
Conf noeuds
·Temps de lecture : 4 minutes· loading · loading
K3s Kubernetes Ansible Raspberry Pi Homelab SSH Inventory Automation DevOps
Préparer les nœuds Raspberry Pi pour le cluster K3s : connectivité, SSH sans mot de passe, configuration d’Ansible et inventaire dynamique.
Intro
· loading · loading
K3s Kubernetes
Mise en place du monitoring
Kube install
·Temps de lecture : 4 minutes· loading · loading
K3s Kubernetes Cluster Control Plane Ansible Labels Taints Homelab Automation
Installation de K3s sur le nœud maître, ajout des workers via Ansible, configuration des rôles, labels et variables d’environnement Kubernetes.