DocsICP FilingConsole
官方文档
首页

GitOps FAQ

更新时间：
复制 MD 格式
产品详情
我的收藏

This topic answers frequently asked questions (FAQs) about using GitOps.

Connect to a private Git repository

Due to security concerns, private Git repositories are typically not accessible from the public internet. To connect ACK One GitOps to a private Git repository, you must establish network connectivity and then perform the required configuration.

Step 1: Configure domain name resolution

The following steps use git.abc.cn as an example domain name for the Git repository.

  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 PrivateZone for 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, and then click Add Zone. In the dialog box, configure the following parameters and click OK.

      • Authoritative Zone: abc.cn (using the Git repository domain git.abc.cn as an example)

      • Recursive Resolution Proxy for Subdomain Names: Enable

      • Effective Scope > Alibaba Cloud VPC: Select the VPC that is bound to ACK One.

    2. In the list of domain names, find the PrivateZone that you just created. In the Actions column, click Settings to open the Settings page.

    3. On the Settings page, click Add Record. In the dialog box, configure the following parameters and click OK.

      • Record Type: A

      • Hostname: git (using git.abc.cn as an example)

      • Record Value: Enter the IP address of the internal Git repository.

Step 2: Connect to the Git repository

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 deploy applications. For more information, see Private Repositories.

Application grouping on the console

When you have a large number of applications, grouping them can improve usability. In the left-side navigation pane of the GitOps console, you can:

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

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

Control application deployments

You often need to control application deployments, especially within automated CI/CD pipelines. You can use the following methods:

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

  • Manually update the image version in the deployment repository. If you are not automatically monitoring the image repository for changes, an O&M engineer must verify new images. After verification, they can manually update the image version in the application deployment repository, which triggers an application sync 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 a code review and merges the code, the CI pipeline automatically builds and pushes the image. Argo CD then automatically detects the image change and deploys it to environments configured with AutoSync. You can also manually deploy to environments configured for ManualSync.

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

Symptom

When you check the logs by running the kubectl -nargocd logs xxxx command, the repo-server returns 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...

Solution

This problem occurs because insufficient disk space causes a write failure to the .git/index.lock file. To resolve this, increase the temporary storage for the Pods of the ACK One GitOps Argo CD component. These components run on Elastic Container Instance (ECI) and have 30 GiB of default temporary storage. Follow these steps to increase the storage. For billing information, see Billing of temporary storage space.

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

  2. In the Pod Template of the relevant Deployment, add the k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" annotation to the Pod. You can customize the amount of temporary storage.

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

      kubectl edit deployment -nargocd argocd-server

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

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

Prevent tracking of non-application resources

Background Information

Argo CD uses the app.kubernetes.io/instance label to track Kubernetes resources. If a resource has this label and its value matches the Application name, Argo CD tracks it. This can cause the Application's status to remain OutOfSync and may result in the unintended deletion of the non-application resource. To prevent this behavior, use one of the following solutions.

Solutions

  • Solution 1: In the argocd/argocd-cm ConfigMap of the fleet instance, add resource.exclusions to ignore the tracked non-application resources. 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 ConfigMap of the fleet instance, add the custom tracking label application.instanceLabelKey: argocd.argoproj.io/instance. After this change, resources managed by Argo CD will use the argocd.argoproj.io/instance label. This prevents Argo CD from tracking other resources that only have the app.kubernetes.io/instance label. After you apply this configuration, existing Applications may show an OutOfSync status until they are resynchronized.

    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

Restart components after ConfigMap changes

In Argo CD, some ConfigMap changes only take effect after the corresponding Argo CD component is restarted.

The following table lists commonly modified ConfigMaps.

Parameter

Description

Restart required?

argocd-cm

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

A restart is usually not required. However, if the configuration does not take effect, restart argocd-server.

argocd-cmd-params-cm

Used to configure environment variables for Argo CD components.

A restart of the corresponding component or argocd-server is required.

argocd-rbac-cm

Used to configure Argo CD's Role-Based Access Control (RBAC) permissions.

Usually, no restart is needed.

argocd-image-updater-config

Used to manage configurations for the image-updater.

A restart of the corresponding component or argocd-server is required.

argocd-notifications-cm

Used to manage configurations for the argocd-notification-controller.

A restart of the corresponding component or argocd-server is required.
Note

ACK One GitOps provides two operational modes:

  1. In default mode, all components run within a single Deployment. To apply changes, restart the argocd-server Deployment.

  2. In High-availability Mode, components are split into multiple Deployments. You can restart individual components as needed.

    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

Follow these steps to restart a component:

  1. On the Multi-cluster GitOps page, find the Argo CD Component section within the GitOps collapsible panel.

  2. Click Restart next to Argo CD Component.

  3. In the dialog box, select the component to restart from the Select Application to Restart drop-down list, for example argocd-server, and then click OK.

Git generator does not reflect directory changes

Symptom

When using the Git generator with an Argo CD ApplicationSet, you may find that new Application resources fail to be created after a dependent directory in the Git repository is added or renamed. This issue can occur 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 refresh its cache when a directory path changes. To resolve this, force a refresh by adding the argocd.argoproj.io/application-set-refresh="true" annotation to the ApplicationSet that contains the Git generator. See the following example:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  ···
  annotations:
    ···
    argocd.argoproj.io/application-set-refresh: "true"
spec:
  ···
  generators:
    - git:
        ···     
  template:
    ···
Previous：Migrate Self-Managed ArgoCD to ACK One GitOpsNext：Application distribution