1.2.4. 既知の問題

Argo CD イメージアップデーターは、spec.source の代わりに spec.sourceHydrator を使用するアプリケーションの更新をコミットできません。Helm の書き戻し方法 (helmvalues:./values.yaml カスタムターゲットまたは argocd の 書き戻し方法) を使用すると、イメージアップデーターは成功メッセージをログに記録しますが、更新されたイメージタグを Git にコミットしません。この問題は、イメージアップデーターの内部コードが、実際のアプリケーション仕様ではなく、sourceHydrator アプリケーションのソース設定のローカルコピーを変更するために発生します。その結果、変更内容は破棄されます。

この問題を回避するには、spec.sourceHydrator.drySource に、ドライソースのツールタイプに一致する空のツールブロックを追加します。

Helm ベースのドライソースの例:

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://example.com/repo.git
      path: charts/app
      targetRevision: HEAD
      helm: {}  # Add this empty block for Helm charts
    syncSource:
      targetBranch: env/dev
      path: charts/app

Kustomize ベースのドライソースの例:

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://example.com/repo.git
      path: overlays/production
      targetRevision: HEAD
      kustomize: {}  # Add this empty block for Kustomize overlays
    syncSource:
      targetBranch: env/production
      path: overlays/production

GITOPS-11441

Red Hat OpenShift GitOps 1.22 にアップグレードし、Redis 高可用性 (HA) を有効にすると、*-redis-ha-server-N Pod がライブネスプローブの失敗を伴う不整合な状態になり、最終的に CrashLoopBackOff 状態 になります。Pod の仕様更新を強制し、通常の動作を再開するには、手動による介入が必要です。

この問題を回避するには、影響を受ける Redis HA Pod を 1 つずつ削除し、StatefulSet が更新された設定でそれらを再作成するのを待ちます。

$ oc delete pod <argocd-instance>-redis-ha-server-0 -n <namespace>

次の Pod を削除する前に、Pod が再作成され、実行 状態になるまで待機してください。StatefulSet 内のすべての redis-ha-server Pod に対して、このプロセスを繰り返します。

GITOPS-11294

Red Hat OpenShift GitOps 1.22 では、gitopsservice クラスター CR で spec.runOnInfra: true を有効にすると、ワークロード Pod テンプレートを更新するのではなく、名前空間アノテーションによってインフラストラクチャーノードのスケジューリングが適用されます。この設定が有効になっている場合、既存の Pod はインフラストラクチャーノードに自動的に再スケジュールされません。

spec.runOnInfra: true を有効にした後、既存のワークロードをインフラストラクチャーノードに移動するには、影響を受ける Pod を手動で再起動します。

$ oc delete pod <pod-name> -n <namespace>

再作成された Pod は、名前空間アノテーションに従ってインフラストラクチャーノードにスケジュールされます。

GITOPS-11499