Container Service for Kubernetes:GitOps FAQ

How do I connect GitOps to a private Git repository?

Private Git repositories are typically unreachable over the public internet. To connect ACK One GitOps to one, establish network connectivity and then register the repository.

How do I group applications in the GitOps console?

In the left-side menu bar of the GitOps console, you can filter and group applications:

• Filter by: Favorites Only, SYNC STATUS, or HEALTH STATUS

• Group by: LABELS, PROJECTS, CLUSTERS, NAMESPACES, or AUTO SYNC

How can O&M engineers control application publishing?

In an automated CI/CD pipeline, you have three options for keeping O&M engineers in control of what gets published.

Option 1: Use ManualSync mode

Configure the environment with ManualSync. After code is pushed, the O&M engineer reviews and verifies the change, then manually clicks Sync to deploy to the destination cluster.

Option 2: Manually update the image version

If Argo CD Image Updater is not monitoring the repository, the O&M engineer confirms the new image and manually updates the image version in the deployment repository. This triggers an Argo CD sync automatically.

Option 3: Require a code review before the CI pipeline runs

Add a code review gate to your CI/CD pipeline. After the O&M engineer approves the review, the code merges, which triggers the CI pipeline to build and push the image. Argo CD then detects the image change and publishes the application. Applications with AutoSync deploy automatically; applications with ManualSync wait for a manual sync.

Which Argo CD components need a restart after I modify a ConfigMap?

It depends on which ConfigMap you modified:

Which deployment to restart depends on your GitOps mode:

• Default mode: All components run in a single deployment. Restart argocd-server.

• High-availability Mode: Components are split across separate deployments. Restart only the one you need:

  Deployment	Components it contains
  argocd-server	argocd-server
  argocd-application-controller	application-controller, applicationset-controller
  argocd-repo-server	repo-server
  argocd-dex-imageupdate-notification	image-updater, notification-controller, dex
  argocd-redis	redis

To restart a component from the console:

1. On the Multi-cluster GitOps page, find Argo CD Component in the GitOps section.

2. Click Restart next to Argo CD Component.

3. Select the component from the drop-down list (for example, argocd-server) and click OK.

The Argo CD repo-server reports "Out of disk space" — how do I fix it?

Check the logs first to confirm this error:

kubectl -n argocd logs <repo-server-pod-name>

If you see a message similar to the following, the pod has run out of ephemeral storage:

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

By default, ACK One GitOps runs Argo CD components on Elastic Container Instances (ECI) with 30 GiB of ephemeral storage. To fix this, add the k8s.aliyun.com/eci-extra-ephemeral-storage annotation to increase the storage limit.

1. Get the kubeconfig file for your fleet instance from the ACK One console and connect with kubectl. For details, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

2. Edit the deployment that runs the repo-server:

   • Default mode — edit argocd-server:

     kubectl edit deployment -n argocd argocd-server

   • High-availability Mode — edit argocd-dex-imageupdate-repo-server:

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

3. In the pod template's metadata.annotations, add the annotation. The example below adds 20 GiB, bringing the total to 50 GiB. Adjust the value to fit your workload.

   spec:
     template:
       metadata:
         annotations:
           # Adds 20 GiB to the default 30 GiB (total: 50 GiB). Customize as needed.
           k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi"

For billing details on ephemeral storage, see Billing of temporary storage space.

An application is tracking resources it shouldn't — how do I stop that?

There are two ways to fix this.

Option 1: Exclude the affected resource types

Add resource.exclusions to the argocd-cm ConfigMap in the fleet. The following example excludes CiliumIdentity resources from all clusters:

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:
      - "*"

Option 2: Switch to a custom tracking label

Add application.instanceLabelKey: argocd.argoproj.io/instance to the argocd-cm ConfigMap. After this change, Argo CD tracks resources using argocd.argoproj.io/instance instead of app.kubernetes.io/instance, so resources that only carry the old label are no longer tracked.

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

After applying this change, existing applications may show OutOfSync until their next reconciliation.

Background: Argo CD uses the label app.kubernetes.io/instance to track Kubernetes resources — any resource with this label set to the application name is considered part of that application. If other controllers in your cluster set this label independently, Argo CD may start managing those resources, causing them to appear OutOfSync or get deleted on the next sync.

After I rename a directory in Git, the ApplicationSet git generator doesn't create the expected Application — why?

This is a caching issue. When you rename or add a directory that the git generator depends on, Argo CD doesn't automatically invalidate its revision cache. The generator continues reading the old cached state, so the new Application resource isn't created — even if you've already updated the ApplicationSet to point to the new path.

To force a refresh, add the argocd.argoproj.io/application-set-refresh: "true" annotation to the ApplicationSet:

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