All Products
Search

This Product

    Container Service for Kubernetes:GitOps FAQ

    Document Center

    Container Service for Kubernetes:GitOps FAQ

    Last Updated:Dec 01, 2025

    This topic addresses common issues and provides solutions for using GitOps.

    How do I connect GitOps to a private Git repository?

    Private Git repositories usually cannot be accessed over the Internet because of security concerns. Therefore, to connect ACK One GitOps to a private Git repository, you must establish network connectivity and perform the required configurations.

    Step 1: Configure domain name resolution to make the private Git repository accessible to GitOps

    The following example shows how to perform the configuration for the Git repository domain name git.abc.cn.

    1. Connect your on-premises network to the ACK One VPC network. For more information, see Connect an on-premises IDC to a VPC.

    2. Use internal DNS resolution to implement domain name resolution within the VPC.

      1. Log on to the Alibaba Cloud DNS console. On the Private Zone page, click the User Defined Zones tab under the Authoritative Zone tab. Then, click Add Zone. In the panel that appears, configure the following parameters and click OK.

        • Authoritative Zone: abc.cn (The Git repository domain name git.abc.cn is used as an example.)

        • Recursive Resolution Proxy for Subdomain Names: Enable

        • Effective Scope > Current Account > Standard VPC: Select the VPC to which ACK One is attached.

      2. In the list of domain names, find the private zone that you created. In the Actions column, click Settings.

      3. On the Settings tab, click Add Record. In the panel that appears, configure the following parameters and click OK.

        • Record Type: A

        • Hostname: git (The Git repository domain name git.abc.cn is used as an example.)

        • Record Values: Enter the IP address of the private Git repository.

    Step 2: Connect to the Git repository using the console or CLI

    After you configure domain name resolution, ACK One GitOps can access the private Git repository. You can then connect to the Git repository from the GitOps console or command-line interface (CLI) to publish applications. For more information, see Private Repositories.

    How do I group applications for display in the GitOps console?

    If you have many applications, you can group them to improve user experience. In the left-side menu bar of the GitOps console, you can:

    • Filter applications by Favorites Only, SYNC STATUS, or HEALTH STATUS.

    • Group applications by LABELS, PROJECTS, CLUSTERS, NAMESPACES, or AUTO SYNC.

    image

    How can O&M engineers control application publishing?

    You can control the application publishing process, especially in an automated CI/CD pipeline, using the following methods:

    • Use applications in ManualSync mode. After the code is pushed, an O&M engineer verifies the application. If the application meets the requirements, the O&M engineer can manually click Sync to synchronize it to the destination cluster.

    • Modify the image version in the application deployment repository. If image changes in the repository are not automatically monitored, an O&M engineer must confirm the images. After confirmation, the engineer can manually modify the image version in the application deployment repository to automatically trigger application synchronization in Argo CD.

    • Establish a code review mechanism for the business code repository in your automated CI/CD pipeline. After an O&M engineer approves the code review, the code is merged. This merge automatically triggers the CI pipeline to build and push the image. Argo CD then automatically monitors for image changes and publishes the application. Applications in environments configured with AutoSync are published automatically. Applications in environments configured with ManualSync can be published manually.

    What do I do if the Argo CD repo-server reports an Out of disk space error?

    Symptoms

    Run the kubectl -n argocd logs xxxx command to view the logs. The repo-server reports the following error message:

    '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...

    Solutions

    This issue occurs because the system cannot write data to the .git/index.lock file due to insufficient disk space. To resolve this issue, increase the temporary storage space for the ACK One GitOps Argo CD component pods. By default, these components run on ECI and have 30 GiB of temporary storage space. The following steps describe how to increase this space. For more information about billing, see Billing of temporary storage space.

    1. Obtain the KubeConfig file of the fleet instance from the ACK One console and use kubectl to connect to the fleet instance. For more information, see Obtain the KubeConfig file of a cluster and use kubectl to connect to the cluster.

    2. In the pod template of the corresponding deployment, add the k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" annotation to the pod. You can customize the size of the temporary storage space.

      • If GitOps is in default mode, add the annotation to the argocd-server deployment.

        kubectl edit deployment -n argocd argocd-server

      • If GitOps is in High-availability Mode, add the annotation to the argocd-dex-imageupdate-repo-server deployment.

        kubectl edit deployment -n argocd argocd-dex-imageupdate-repo-server
      apiVersion: apps/v1
kind: Deployment
metadata:
  ...
...
spec:
  template:
    metadata:
      annotations:
        # Add 20 GiB of temporary storage space to the default 30 GiB. The total temporary storage space is 50 GiB. You can customize the size of the temporary storage space to be added.
        k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi"
      ...
    ...
  ...

    How do I prevent a GitOps application from tracking non-application resources?

    Background information

    Argo CD uses the label app.kubernetes.io/instance to track Kubernetes resources. If a resource has this label and its value is the same as the application name, the resource is tracked by the application. This may cause the application to remain in the OutOfSync state or cause non-application resources to be continuously deleted. To avoid this unexpected behavior, you can use one of the following solutions.

    Solutions

    • Solution 1: In the argocd/argocd-cm file of the fleet, add resource.exclusions to prevent non-application resources from being tracked. The following configuration ignores CiliumIdentity resources.

    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: In the argocd/argocd-cm file of the fleet, add the custom tag application.instanceLabelKey: argocd.argoproj.io/instance. After you add the tag, the resources of applications delivered by Argo CD contain the label argocd.argoproj.io/instance. Therefore, resources that have only the label app.kubernetes.io/instance are not tracked. After the configuration takes effect, the status of existing applications may be displayed as OutOfSync.

      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

    How do I restart the corresponding Argo CD components after modifying an Argo CD ConfigMap?

    In Argo CD, after you modify a ConfigMap, you may need to restart the corresponding Argo CD component for the modification to take effect.

    The following table describes the ConfigMaps that you may frequently modify:

    Configuration item

    Description

    Whether to restart Argo CD components

    argocd-cm

    Used to configure custom OpenID Connect (OIDC), custom access url, local users, and other settings.

    You do not need to restart Argo CD components. If the configuration does not take effect, you can restart argocd-server.

    argocd-cmd-params-cm

    Used to configure environment variables for Argo CD components.

    You need to restart the corresponding component or argocd-server for the configuration to take effect.

    argocd-rbac-cm

    Used to configure the role-based access control (RBAC) permissions of Argo CD.

    You do not need to restart the components.

    argocd-image-updater-config

    Used to manage configurations related to image-updater.

    You need to restart the corresponding component or argocd-server for the configuration to take effect.

    argocd-notifications-cm

    Used to manage configurations related to argocd-notification-controller.

    You need to restart the corresponding component or argocd-server for the configuration to take effect.

    Note

    ACK One GitOps has two modes:

    1. Default mode: All components are in one deployment. To restart the components, you must restart argocd-server.

    2. High-availability Mode: The components are distributed in the following deployments. To restart a component, you can restart the corresponding deployment.

      1. argocd-server.

      2. argocd-application-controller: contains application-controller and applicationset-controller.

      3. argocd-repo-server.

      4. argocd-dex-imageupdate-notification: contains image-updater, notification-controller, and dex.

      5. argocd-redis.

    You can perform the following steps to restart a component:

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

    2. Click Restart next to Argo CD Component.

    3. In the dialog box that appears, select the name of the component that you want to restart from the drop-down list, such as argocd-server, and then click OK.

    When I use the git generator of ApplicationSet, are changes to Git repository directories not supported?

    Symptoms

    When you use the Git generator of an Argo CD ApplicationSet, you might encounter an issue. If you add or rename a directory in the Git repository that the generator depends on, the expected Application resource may not be created. This can happen even if you immediately update the ApplicationSet resource to point to the new directory path.

    Solution

    This issue occurs because Argo CD does not automatically update its cache after the directory name is changed. To resolve this issue, you can force a refresh by adding the argocd.argoproj.io/application-set-refresh="true" annotation to the ApplicationSet that uses the Git generator. The following code provides an example:

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