ArgoCD のベストプラクティス 10 選

この記事では、私が発見した Argo のベスト プラクティスをいくつか紹介します。

1. 空の retryStrategy は許可されません

プロジェクト: Argo ワークフロー

ベスト プラクティス: ユーザーは retryStrategy を指定して、ワークフロー内の失敗したステップやエラーのあるステップを再試行する方法を示すことができます。空の retryStrategy (つまり retryStrategy: {}) を指定すると、コンテナーは完了するまで再試行し、最終的に OOM の問題が発生します。

2. ワークフローポッドがデフォルトのサービスアカウントを使用するように設定されていないことを確認します。

プロジェクト: Argo ワークフロー

ベスト プラクティス: ワークフロー内のすべてのポッドは、workflow.spec.serviceAccountName​ で指定されたサービス アカウントを使用して実行できます。省略した場合、Argo はワークフロー名前空間のデフォルトのサービス アカウントを使用します。これにより、ワークフロー (ポッドなど) が Kubernetes API サーバーと対話できるようになります。これにより、単一のコンテナにアクセスできる攻撃者が、AutomountServiceAccountToken​ を使用して Kubernetes を悪用できるようになります。 AutomountServiceAccountToken オプションが無効になっている場合、Argo が使用するデフォルトのサービス アカウントには権限がないため、ワークフローは失敗します。

適切なロールを持つ専用のユーザー管理サービス アカウントを作成することをお勧めします。

3. ConfigMapsラベルにpart-of: argocdが存在することを確認する

プロジェクト: アルゴ CD

ベスト プラクティス: Argo CD は、app.kubernetes.io/part-of: argocd のタグが付いていない ConfigMap リソースを使用しません。

Argo CD をインストールすると、そのアトミック構成には多数のサービスと configMaps が含まれます。 ConfigMap および Secret リソースの特定のタイプごとに、サポートされるリソース名は 1 つだけなので、マージする必要がある場合は、作成する前に何かを行う必要があります。 ConfigMap リソースに app.kubernetes.io/part-of: argocd というラベルを付けることが重要です。そうしないと、Argo CD はそれらを使用できなくなります。

4. DAG で無効にして、FailFast = false を設定します。

プロジェクト: Argo ワークフロー

ベスト プラクティス: ワークフローで一連のステップを指定する代わりに、各タスクの依存関係を指定して、ワークフローを有向非巡回グラフ (DAG) として定義できます。 DAG ロジックには、DAG ノードの 1 つで障害が検出されるとすぐに新しいステップのスケジュールを停止する高速フェイル機能が組み込まれています。その後、すべての DAG ノードが完了するまで待機してから、DAG 自体を失敗させます。 FailFast[4]フラグはデフォルトでtrueに設定されます。 false に設定すると、DAG 内のブランチの失敗結果に関係なく、DAG は DAG のすべてのブランチを完了 (成功または失敗) まで実行できるようになります。

5. ロールアウト一時停止ステップの継続時間が設定されていることを確認する

プロジェクト: Argo ロールアウト

ベスト プラクティス: ロールアウトごとに、手順のリストを定義できます。各ステップには、setWeight と pause の 2 つのフィールドのいずれかを設定できます。 setWeight フィールドは、カナリアに送信されるトラフィックの割合を示し、pause は文字通りデプロイメントの一時停止を示します。

舞台裏では、Argo コントローラーは次の手順を使用して、ロールアウト中に ReplicaSet を操作します。コントローラーがロールアウトの一時停止ステップに到達すると、.status.PauseConditions フィールドに PauseCondition​ 構造が追加されます。 Pause 構造の Duration フィールドが設定されている場合、デプロイメントは Duration フィールドの値を待機する前に次のステップに進みません。ただし、期間フィールドが省略されている場合、追加された一時停止条件が削除されるまでロールアウトは無期限に待機する可能性があります。

6. ロールアウトのrevisionHistoryLimitを指定する

プロジェクト: Argo ロールアウト

ベスト プラクティス: .spec.revisionHistoryLimit​ は、ロールバックを可能にするために保持する必要がある古い ReplicaSet の数を示すオプション フィールドです。これらの古い ReplicaSets は etcd のリソースを消費し、kubectl get rs の出力を圧迫します。各デプロイメント リビジョンの構成は、そのレプリカ セットに保存されます。したがって、古いレプリカセットを削除すると、そのバージョンのデプロイメントにロールバックすることはできません。

デフォルトでは、10 個の古いレプリカセットが保持されますが、理想的な値は新しいデプロイメントの頻度と安定性によって異なります。具体的には、このフィールドをゼロに設定すると、レプリカが 0 個の古い ReplicaSet がすべてクリーンアップされます。この場合、変更履歴が消去されているため、新しいデプロイメントを元に戻すことはできません。

7. クラスター内のノード間でiptablesの伝播を確実にするために、scaleDownDelaySecondsを30秒に設定します。

プロジェクト: Argo ロールアウト

ベスト プラクティス: ロールアウトによってサービスのセレクターが変更されると、すべてのノードが iptables を更新してトラフィックを古い Pod ではなく新しい Pod に送信するまでに伝播遅延が発生します。この遅延中にノードが更新されなかった場合、トラフィックは古いポッドに送信されます。古いポッドを強制終了したノードにパケットが送信されないようにするために、ロールアウトは scaleDownDelaySeconds フィールドを使用して、ノードに iptables の変更をブロードキャストするのに十分な時間を与えます。省略した場合、Rollout は以前の ReplicaSet をスケールダウンする前に 30 秒間待機します。

iptables がクラスター内のノード全体に伝播されるようにするには、scaleDownDelaySeconds を少なくとも 30 秒に設定することをお勧めします。その理由は、Kubernetes が終了猶予期間と呼ばれる指定された時間待機するためです。デフォルトでは 30 秒です。

8. Error と TransientError の再試行を確実に行う

プロジェクト: Argo ワークフロー

ベスト プラクティス: retryStrategy は、ワークフロー ステップの再試行を制御する Workflow CRD のオプション フィールドです。 retryStrategy のフィールドの 1 つは retryPolicy です。これは再試行される NodePhase 状態の戦略を定義します (NodePhase は現在のノードの状態です)。 retryPolicy​ のオプションは、Always、OnError、または OnTransientError です。さらに、ユーザーは式[9]を使用して再試行回数をさらに制御することができます。

• retryPolicy=Always: ユーザーはシステムレベルのエラー (ノードが停止したり、プリエンプトされたりした場合など) のみを再試行しますが、ユーザーレベルのコードで発生したエラーは、バグを示しているため再試行しません。さらに、このオプションは、ジョブとしてのワークフローよりも、長時間実行されるコンテナーに適しています。
• retryPolicy=OnError: プリエンプションは処理しませんが、ノードの消失やポッドの削除などのシステムレベルのエラーを処理します。ただし、Pod の正常な終了中、kubelet は終了した Pod に失敗ステータスとシャットダウン理由を割り当てます。したがって、ノードのプリエンプションにより、ノードのステータスはエラーではなく失敗となり、プリエンプションは再試行されません。

retryPolicy: "Always" を設定し、次の式を使用することをお勧めします。

 'lastRetry.status == "Error" または (lastRetry.status == "Failed" かつ asInt(lastRetry.exitCode) が [0] に含まれない)'

9. progressDeadlineAbortがtrueに設定されていることを確認してください。特にprogressDeadlineSecondsが設定されている場合は、

プロジェクト: Argo ロールアウト

ベスト プラクティス: ユーザーは、更新中にロールアウトが失敗と見なされるまでに進行する必要がある最大時間を秒単位で指定する progressDeadlineSeconds を設定できます。

ロールアウト ポッドがエラー状態 (イメージのプルバックなど) で停止した場合、進行期限後にロールアウトはダウングレードされますが、失敗したレプリカ セット/ポッドはスケールダウンされません。ポッドは再試行を続け、最終的にロールアウト メッセージに「ProgressDeadlineExceeded: The replicaset has time out progressing​」と表示されます。ロールアウトを中止するには、ユーザーは progressDeadlineSeconds​ と progressDeadlineAbort: true の両方を設定する必要があります。

10. カスタムリソースがArgoCDインスタンスの名前空間と一致していることを確認します。

プロジェクト: アルゴ CD

ベスト プラクティス: 各リポジトリ内で、すべてのアプリケーションおよび AppProject マニフェストは同じ metadata.namespace と一致する必要があります。理由は、Argo CD をどのようにインストールしたかによって異なります。

通常のデプロイメントで Argo CD をデプロイした場合、Argo CD はバックグラウンドで 2 つの ClusterRole と ClusterRoleBinding を作成し、これらはデフォルトで argocd 名前空間を参照します。この場合、すべての Argo CD リソースが Argo CD インスタンスの名前空間と一致することを確認するだけでなく、argocd 名前空間を使用することをお勧めします。そうしないと、すべての Argo CD 内部リソース内の名前空間参照が更新されることを確認する必要があります。

ただし、Argo CD を外部クラスターにデプロイする場合 (「名前空間分離モード」)、Argo は、Argo CD がデプロイされている名前空間に ClusterRole と ClusterRoleBinding​ ではなく、ロールと関連する RoleBinding​ を作成します。作成されたサービス アカウントには制限されたレベルの管理アクセスが付与されるため、Argo CD が期待どおりに機能するには、名前空間へのアクセスを明示的に付与する必要があります。この場合、Application や AppProject を含むすべてのリソースが ArgoCD インスタンスの正しい名前空間を使用するようにすることをお勧めします。

元記事: https://datree.io/resources/argocd-best-practices-you-should-know​