Container Service for Kubernetes:GitOps FAQ

Etapa 1: Configure a resolução de nomes de domínio

Os passos a seguir usam git.abc.cn como exemplo de nome de domínio para o repositório git.

Etapa 2: Conectar-se ao repositório git

Após configurar a resolução de nomes de domínio, o ACK One GitOps poderá acessar o repositório git privado. Em seguida, conecte-se ao repositório git pelo console do GitOps ou pela interface de linha de comando (cli) para implantar aplicações. Para mais detalhes, consulte Repositórios Privados.

Sintoma

Ao verificar os logs executando o comando kubectl -nargocd logs xxxx, o repo-server retorna a seguinte mensagem de erro:

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

Solução

Esse problema ocorre porque a falta de espaço em disco causa falha na gravação do arquivo .git/index.lock. Para resolver, aumente o armazenamento temporário dos Pods do componente Argo CD do ACK One GitOps. Esses componentes são executados no Elastic Container Instance (ECI) e possuem 30 GiB de armazenamento temporário padrão. Siga os passos abaixo para aumentar o armazenamento. Para informações sobre faturamento, consulte Faturamento de espaço de armazenamento temporário.

1. Obtenha o KubeConfig da instância fleet no console do ACK One e conecte-se à instância fleet usando kubectl. Para mais informações, consulte Obter o KubeConfig de um cluster e usar kubectl para conectar-se ao cluster.

2. No modelo de Pod do Deployment correspondente, adicione a anotação k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" ao Pod. É possível personalizar a quantidade de armazenamento temporário.

   • Se o GitOps estiver no modo padrão, adicione a anotação ao Deployment argocd-server.

     kubectl edit deployment -nargocd argocd-server

   • Caso o GitOps esteja no Modo de Alta Disponibilidade, adicione a anotação ao 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"
         ...
       ...
     ...

Informações de base

O Argo CD usa o rótulo app.kubernetes.io/instance para rastrear recursos do Kubernetes. Se um recurso possuir esse rótulo e seu valor corresponder ao nome da Application, o Argo CD o rastreará. Isso pode manter o status da Application como OutOfSync e resultar na exclusão não intencional do recurso externo à aplicação. Para evitar esse comportamento, use uma das soluções a seguir.

Soluções

• Solução 1: No ConfigMap argocd/argocd-cm da instância fleet, adicione resource.exclusions para ignorar os recursos rastreados que não pertençam à aplicação. A configuração abaixo ignora recursos 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:
      - "*"

• Solução 2: No ConfigMap argocd/argocd-cm da instância fleet, adicione o rótulo de rastreamento personalizado application.instanceLabelKey: argocd.argoproj.io/instance. Após essa alteração, os recursos gerenciados pelo Argo CD passarão a usar o rótulo argocd.argoproj.io/instance. Isso impede que o Argo CD rastreie outros recursos que possuam apenas o rótulo app.kubernetes.io/instance. Ao aplicar essa configuração, as Applications existentes podem apresentar status OutOfSync até serem ressincronizadas.

  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

Sintoma

Ao usar o gerador git com um ApplicationSet do Argo CD, novos recursos Application podem falhar ao serem criados após a adição ou renomeação de um diretório dependente no repositório git. Esse problema pode ocorrer mesmo que você atualize imediatamente o recurso ApplicationSet para apontar para o novo caminho do diretório.

Solução

Isso acontece porque o Argo CD não atualize automaticamente seu cache quando há mudança no caminho de um diretório. Para corrigir, force uma atualização adicionando a anotação argocd.argoproj.io/application-set-refresh="true" ao ApplicationSet que contém o gerador git. Veja o exemplo a seguir:

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