Container Service for Kubernetes:GitOps FAQ

Étape 1 : Configurer la résolution des noms de domaine

Les étapes suivantes utilisent git.abc.cn comme exemple de nom de domaine pour le dépôt Git.

Étape 2 : Se connecter au dépôt Git

Une fois la résolution des noms de domaine configurée, ACK One GitOps peut accéder au dépôt Git privé. Vous pouvez ensuite vous connecter au dépôt Git depuis la console GitOps ou l'interface de ligne de commande (CLI) pour déployer des applications. Pour plus d'informations, consultez la documentation Private Repositories.

Symptôme

Lorsque vous consultez les journaux en exécutant la commande kubectl -nargocd logs xxxx, le serveur de dépôt renvoie le message d'erreur suivant :

'git checkout --force xxx' failed exit status 128: error: unable to write file templates/deployment.yaml\nfat al: sha1 file '/tmp/_argocd-repo/xxx/.git/index.lock' write error. Out of diskspace...

Solution

Ce problème survient lorsque l'espace disque insuffisant entraîne un échec d'écriture dans le fichier .git/index.lock. Pour résoudre ce problème, augmentez le stockage temporaire des Pods du composant Argo CD d'ACK One GitOps. Ces composants s'exécutent sur Elastic Container Instance (ECI) et disposent de 30 GiB de stockage temporaire par défaut. Suivez ces étapes pour augmenter le stockage. Pour plus d'informations sur la facturation, consultez la rubrique Facturation de l'espace de stockage temporaire.

1. Obtenez le KubeConfig de l'instance de flotte depuis la console ACK One et connectez-vous à l'instance de flotte à l'aide de kubectl. Pour plus d'informations, consultez la rubrique Obtenir le KubeConfig d'un cluster et utiliser kubectl pour se connecter au cluster.

2. Dans le modèle de Pod du Deployment concerné, ajoutez l'annotation k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" au Pod. Vous pouvez personnaliser la quantité de stockage temporaire.

   • Si GitOps est en mode par défaut, ajoutez l'annotation au Deployment argocd-server.

     kubectl edit deployment -nargocd argocd-server

   • Si GitOps est en mode haute disponibilité, ajoutez l'annotation au Deployment argocd-dex-imageupdate-repo-server.

     kubectl edit deployment -nargocd argocd-dex-imageupdate-repo-server

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     ...
   ...
   spec:
     template:
       metadata:
         annotations:
           # This adds 20 GiB to the default 30 GiB, for a total of 50 GiB. The amount of extra temporary storage is customizable.
           k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi"
         ...
       ...
     ...

Informations générales

Argo CD utilise le libellé app.kubernetes.io/instance pour suivre les ressources Kubernetes. Si une ressource possède ce libellé et que sa valeur correspond au nom de l'application, Argo CD la suit. Cela peut entraîner le maintien du statut OutOfSync de l'application et provoquer la suppression involontaire de la ressource non applicative. Pour éviter ce comportement, utilisez l'une des solutions suivantes.

Solutions

• Solution 1 : dans le ConfigMap argocd/argocd-cm de l'instance de flotte, ajoutez resource.exclusions pour ignorer les ressources non applicatives suivies. La configuration suivante ignore les ressources CiliumIdentity.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  ...
  resource.exclusions: |
    - apiGroups:
      - cilium.io
      kinds:
      - CiliumIdentity
      clusters:
      - "*"

• Solution 2 : dans le ConfigMap argocd/argocd-cm de l'instance de flotte, ajoutez le libellé de suivi personnalisé application.instanceLabelKey: argocd.argoproj.io/instance. Après cette modification, les ressources gérées par Argo CD utiliseront le libellé argocd.argoproj.io/instance. Cela empêche Argo CD de suivre d'autres ressources qui ne possèdent que le libellé app.kubernetes.io/instance. Après avoir appliqué cette configuration, les applications existantes peuvent afficher un statut OutOfSync jusqu'à ce qu'elles soient resynchronisées.

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: argocd-cm
    labels:
      app.kubernetes.io/name: argocd-cm
      app.kubernetes.io/part-of: argocd
  data:
    ...
    application.instanceLabelKey: argocd.argoproj.io/instance

Symptôme

Lors de l'utilisation du générateur Git avec un ApplicationSet Argo CD, vous pouvez constater que les nouvelles ressources Application ne parviennent pas à être créées après l'ajout ou le renommage d'un répertoire dépendant dans le dépôt Git. Ce problème peut survenir même si vous mettez immédiatement à jour la ressource ApplicationSet pour pointer vers le nouveau chemin de répertoire.

Solution

Ce problème survient car Argo CD n'actualise pas automatiquement son cache lorsqu'un chemin de répertoire change. Pour résoudre ce problème, forcez une actualisation en ajoutant l'annotation argocd.argoproj.io/application-set-refresh="true" à l'ApplicationSet contenant le générateur Git. Voir l'exemple suivant :

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  ···
  annotations:
    ···
    argocd.argoproj.io/application-set-refresh: "true"
spec:
  ···
  generators:
    - git:
        ···     
  template:
    ···