Container Service for Kubernetes:GitOps よくある質問

GitOps を非公開 Git リポジトリに接続するにはどうすればよいですか？

非公開 Git リポジトリは通常、パブリックインターネット経由では到達できません。ACK One GitOps を非公開 Git リポジトリに接続するには、ネットワーク接続を確立してからリポジトリを登録します。

GitOps コンソールでアプリケーションをグループ化するにはどうすればよいですか？

GitOps コンソールの左側のメニューバーで、アプリケーションをフィルターおよびグループ化できます。

• フィルター条件: [お気に入り]、[同期ステータス]、または [ヘルスステータス]

• グループ化条件: [ラベル]、[プロジェクト]、[クラスター]、[名前空間]、または [自動同期]

運用保守エンジニアはアプリケーションの公開をどのように制御できますか？

自動化された CI/CD パイプラインでは、運用保守エンジニアが公開される内容を制御するための 3 つのオプションがあります。

オプション 1: ManualSync モードを使用する

環境を ManualSync で構成します。コードがプッシュされた後、運用保守エンジニアは変更を確認および検証し、手動で [同期] をクリックして送信先クラスターにデプロイします。

オプション 2: イメージバージョンを手動で更新する

Argo CD Image Updater がリポジトリをモニタリングしていない場合、運用保守エンジニアは新しいイメージを確認し、デプロイメントリポジトリ内のイメージバージョンを手動で更新します。これにより、Argo CD の同期が自動的にトリガーされます。

オプション 3: CI パイプラインが実行される前にコードレビューを要求する

CI/CD パイプラインにコードレビューゲートを追加します。運用保守エンジニアがレビューを承認すると、コードがマージされ、CI パイプラインがトリガーされてイメージがビルドおよびプッシュされます。その後、Argo CD はイメージの変更を検出し、アプリケーションを公開します。AutoSync が設定されたアプリケーションは自動的にデプロイされます。ManualSync が設定されたアプリケーションは手動同期を待ちます。

ConfigMap を変更した後、どの Argo CD コンポーネントを再起動する必要がありますか？

変更した ConfigMap によって異なります。

再起動する Deployment は、GitOps モードによって異なります。

• デフォルトモード: すべてのコンポーネントは単一の Deployment で実行されます。argocd-server を再起動します。

• 高可用性モード： コンポーネントは個別のデプロイメントに分割されます。必要なものだけを再起動します：

  Deployment	含まれるコンポーネント
  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

コンソールからコンポーネントを再起動するには:

1. [Multi-cluster GitOps] ページで、[GitOps] セクションにある Argo CD コンポーネント を探します。

2. Argo CD Component の横にある [再起動] をクリックします。

3. ドロップダウンリストからコンポーネント (たとえば argocd-server) を選択し、[OK] をクリックします。

Argo CD repo-server が「ディスク容量不足」を報告しています。どうすれば修正できますか？

まずログを確認して、このエラーを特定します。

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

次のようなメッセージが表示される場合、Pod はエフェメラルストレージを使い果たしています。

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

デフォルトでは、ACK One GitOps は Argo CD コンポーネントを Elastic Container Instance (ECI) 上で 30 GiB のエフェメラルストレージで実行します。これを修正するには、k8s.aliyun.com/eci-extra-ephemeral-storage アノテーションを追加してストレージ制限を増やします。

1. ACK One コンソールからフリートインスタンスの kubeconfig ファイルを取得し、kubectl で接続します。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続」をご参照ください。

2. repo-server を実行する Deployment を編集します。

   • デフォルトモード — argocd-server を編集します。

     kubectl edit deployment -n argocd argocd-server

   • 高可用性モード — argocd-dex-imageupdate-repo-server の編集:

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

3. Pod テンプレートの metadata.annotations にアノテーションを追加します。次の例では、デフォルトの 30 GiB に 20 GiB を追加し、合計 50 GiB にします。ワークロードに合わせて値をカスタマイズしてください。

   spec:
     template:
       metadata:
         annotations:
           # デフォルトの 30 GiB に 20 GiB を追加 (合計 50 GiB)。必要に応じてカスタマイズしてください。
           k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi"

エフェメラルストレージの課金詳細については、「一時記憶領域の課金」をご参照ください。

アプリケーションが追跡すべきではないリソースを追跡しています。これを停止するにはどうすればよいですか？

これを修正するには 2 つの方法があります。

オプション 1: 影響を受けるリソースタイプを除外する

フリート内の argocd-cm ConfigMap に resource.exclusions を追加します。次の例では、すべてのクラスターから 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:
      - "*"

オプション 2: カスタム追跡ラベルに切り替える

argocd-cm ConfigMap に application.instanceLabelKey: argocd.argoproj.io/instance を追加します。この変更後、Argo CD は app.kubernetes.io/instance の代わりに argocd.argoproj.io/instance を使用してリソースを追跡するため、古いラベルのみを持つリソースは追跡されなくなります。

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

この変更を適用した後、既存のアプリケーションは次の調停まで OutOfSync と表示される場合があります。

背景情報: Argo CD は、app.kubernetes.io/instance ラベルを使用して Kubernetes リソースを追跡します。このラベルがアプリケーション名に設定されているリソースは、そのアプリケーションの一部と見なされます。クラスター内の他のコントローラーがこのラベルを個別に設定すると、Argo CD がそれらのリソースの管理を開始し、次の同期で OutOfSync と表示されたり、削除されたりする可能性があります。

Git でディレクトリの名前を変更した後、ApplicationSet git generator が期待される Application を作成しません。なぜですか？

これはキャッシュの問題です。git generator が依存するディレクトリの名前を変更したり追加したりしても、Argo CD は自動的にリビジョンキャッシュを無効化しません。generator は古いキャッシュされた状態を読み取り続けるため、新しい Application リソースは作成されません。ApplicationSet を新しいパスを指すように更新した場合でも同様です。

強制的にリフレッシュするには、ApplicationSet に argocd.argoproj.io/application-set-refresh: "true" アノテーションを追加します。

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