Rancher et Argo CD

01Qui fait quoi

Les deux tournent sur le cluster mgmt et sont publiés sur l'ingress de mgmt, avec CrowdSec et des mots de passe forts tirés de SOPS. L'authentification unique avec double facteur fera partie de la page consacrée à la sécurité des accès.

02Installer Rancher

hostname: rancher.k8s.exemple.fr
replicas: 1                    # mgmt n'a qu'un noeud
ingress:
  ingressClassName: traefik
  tls:
    source: letsEncrypt
letsEncrypt:
  email: admin@exemple.fr
  ingress:
    class: traefik
agentTLSMode: system-store     # voir l'encadré ci-dessous

Le mot de passe initial est injecté depuis SOPS par le bootstrap, comme au chapitre 02. Rancher fixe aussi le plafond de Kubernetes : la version 2.15 n'accepte pas encore Kubernetes 1.37, d'où le plafond posé dans Renovate.

03Importer le cluster demo

Dans Rancher, Import Existing, type Generic : Rancher fournit un manifeste à appliquer sur le cluster demo, qui y installe son agent. C'est aujourd'hui la seule étape manuelle de toute la reconstruction.

04Projets et accès des développeurs

Rancher regroupe des namespaces dans des projets, auxquels on donne des droits. Pour les développeurs, un projet par équipe, un namespace par application ou par personne, et le rôle Project Member :

• ils voient et gèrent tout dans les namespaces de leur projet, et rien ailleurs ;
• un quota par projet borne le processeur, la mémoire et le stockage consommés ;
• leur kubeconfig, téléchargé depuis Rancher, passe par Rancher : pas de VPN, pas d'accès à l'API du cluster, et l'accès se coupe en désactivant le compte.

Côté sécurité des pods, Talos applique par défaut le niveau baseline (pas de conteneur privilégié, pas d'accès au système du noeud) et avertit sur le niveau restricted. Les développeurs voient donc passer des avertissements pédagogiques avant de rencontrer un vrai refus. Le guide déployer ses applications leur explique comment les satisfaire.

05Argo CD déclaratif

Argo CD est installé par Helm sur mgmt, et tout ce qu'il connaît est déclaré dans le dépôt : le dépôt lui-même (clé de déploiement en lecture seule, depuis SOPS), le cluster demo, et les applications. Pour piloter demo, le bootstrap de demo crée un compte de service argocd-manager, et celui de mgmt déclare le cluster avec son jeton :

apiVersion: v1
kind: Secret
metadata:
  name: cluster-demo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: demo
  server: https://10.20.1.10:6443
  config: |
    { "bearerToken": "<jeton du compte argocd-manager>",
      "tlsClientConfig": { "caData": "<autorité du cluster demo>" } }

06Une application en GitOps

Une application Argo CD dit d'où viennent les manifestes et où les appliquer. Toutes sont rangées dans k8s/argocd/apps/ :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-whoami
  namespace: argocd
spec:
  project: default
  source:
    repoURL: git@gitlab.exemple.fr:infra/k8s-proxmox.git
    targetRevision: main
    path: k8s/demo-whoami
  destination:
    name: demo
    namespace: demo-whoami
  syncPolicy:
    automated:
      prune: true              # ce qui disparaît du dépôt disparaît du cluster
      selfHeal: true           # ce qui est modifié à la main est remis en place
    syncOptions: [CreateNamespace=true]

Modifier une ressource à la main dans le cluster ? Argo CD la remet en place en quelques secondes, avec la patience d'un majordome anglais. C'est déroutant au début, et c'est tout l'intérêt : ce qui tourne est ce qui est dans Git, et l'historique Git dit qui a changé quoi.