在本文中，我們將探索我發現的一些 Argo 優秀實踐。

1. 不允許提供空的 retryStrategy

項目：Argo Workflows

優秀實踐： 用戶可以指定一個retryStrategy?來指示如何在工作流中重試失敗或錯誤的步驟。提供一個空的retryStrategy（即retryStrategy: {}）將導致容器重試直到完成并最終導致 OOM 問題。

2. 確保未將 Workflow pod 配置為使用默認服務帳戶

項目：Argo Workflows

優秀實踐： 工作流中的所有 pod 都可以使用在workflow.spec.serviceAccountName? 中指定的服務帳戶運行。如果省略，Argo 將使用工作流命名空間的默認服務帳戶。這為工作流（即 pod）提供了與 Kubernetes API 服務器交互的能力。這允許訪問單個容器的攻擊者通過使用AutomountServiceAccountToken?濫用 Kubernetes 。禁用了AutomountServiceAccountToken選項，那么 Argo 將使用的默認服務帳戶將沒有任何權限，并且工作流將失敗。

建議創建具有適當角色的專用用戶管理服務帳戶。

3. 確保 ConfigMaps label 中存在 part-of: argocd

項目：Argo CD

優秀實踐： Argo CD 不會使用未標記app.kubernetes.io/part-of: argocd 的相關 ConfigMap 資源。

安裝 Argo CD 時，其原子配置包含一些services和configMaps?。對于每種特定類型的 ConfigMap 和 Secret 資源，只有一個受支持的資源名稱，如果您需要在創建它們之前合并您需要做的事情。使用標簽 app.kubernetes.io/part-of: argocd 注釋您的 ConfigMap 資源很重要，否則 Argo CD 將無法使用它們。

4. 用 DAG 禁用以設置 FailFast = false

項目：Argo Workflows

優秀實踐： 作為在Workflow?中指定步驟序列的替代方法，您可以通過指定每個任務的依賴關系將工作流定義為有向無環圖 (DAG)。DAG 邏輯具有內置的快速故障功能，可在檢測到其中一個 DAG 節點發生故障時立即停止調度新步驟。然后它會等到所有 DAG 節點都完成后才會使 DAG 本身失敗。FailFast[4]標志默認為true?。如果設置為false，它將允許 DAG 運行 DAG 的所有分支以完成（成功或失敗），而不管 DAG 中分支的失敗結果。

5. 確保 Rollout 暫停步驟具有配置的持續時間

項目：Argo Rollouts

優秀實踐： 對于每個 Rollout，我們可以定義一個步驟列表。每個步驟都可以有兩個字段之一：setWeight和pause。setWeight?字段指示應該發送到金絲雀的流量百分比，而 pause字面意思是指示部署暫停。

在幕后，Argo 控制器使用這些步驟在推出期間操作 ReplicaSet?。當控制器達到推出的暫停步驟時，它會將PauseCondition?結構添加到.status.PauseConditions字段。如果設置了暫停結構中的持續時間字段，則在等待持續時間字段的值之前，部署不會進行到下一步。但是，如果省略了持續時間字段，則推出可能會無限期地等待，直到添加的暫停條件被刪除。

6. 指定 Rollout 的 revisionHistoryLimit

項目：Argo Rollouts

優秀實踐： .spec.revisionHistoryLimit? 是一個可選字段，指示應保留的舊 ReplicaSet 的數量以允許回滾。這些舊的 ReplicaSet 消耗 etcd 中的資源并擠占kubectl get rs的輸出。每個 Deployment 修訂的配置都存儲在它的 ReplicaSets 中；因此，一旦刪除了舊的 ReplicaSet，您就無法回滾到該版本的 Deployment。

默認情況下，會保留 10 個舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩定性。更具體地說，將此字段設置為零意味著將清除所有具有 0 個副本的舊 ReplicaSet。在這種情況下，新的部署無法撤消，因為它的修訂歷史已被清除。

7. 將 scaleDownDelaySeconds 設置為 30s 以確保 iptables 跨集群中的節點傳播

項目：Argo Rollouts

優秀實踐： 當 rollout? 更改service?上的selector?時，在所有節點更新其 iptables?以將流量發送到新 Pod 而不是舊 Pod 之前存在傳播延遲。如果在此延遲期間節點尚未更新，則流量將被定向到舊 pod。為了防止數據包被發送到殺死舊 pod 的節點，rollout 使用scaleDownDelaySeconds?字段給節點足夠的時間廣播 iptables 的變化。如果省略，Rollout 會等待 30 秒，然后再縮減之前的 ReplicaSet。

建議將scaleDownDelaySeconds?設置為至少 30 秒，以確保 iptables在集群中的節點間傳播。原因是 Kubernetes 等待一個稱為終止寬限期的指定時間。默認情況下，這是 30 秒。

8. 確保在 Error 和 TransientError 時重試

項目：Argo Workflows

優秀實踐：  retryStrategy是Workflow? CRD 的一個可選字段，它提供了用于重試工作流步驟的控件。retryStrategy?的字段之一是retryPolicy?，它定義了將被重試的 NodePhase 狀態的策略（NodePhase 是當前節點的狀態）。retryPolicy?的選項可以是：Always、OnError或OnTransientError。此外，用戶可以使用表達式[9]來控制更多的重試次數。

• retryPolicy=Always：用戶只想重試系統級錯誤（例如，節點死亡或被搶占），但不想重試用戶級代碼中發生的錯誤，因為這些失敗表明存在錯誤。此外，與作為作業的工作流相比，此選項更適合長時間運行的容器。
• retryPolicy=OnError：不處理搶占，處理一些系統級錯誤，例如節點消失或 pod 被刪除。但是，在 Pod 正常終止期間，kubelet 會為終止的 Pod 分配一個失敗狀態和一個關閉原因。因此，節點搶占導致節點狀態為Failure?，而不是Error，因此不會重試搶占。

我們建議設置retryPolicy: "Always"并使用以下表達式：

'lastRetry.status == "Error" or (lastRetry.status == "Failed" and asInt(lastRetry.exitCode) not in [0])'

9. 確保 progressDeadlineAbort 設置為 true，特別是如果 progressDeadlineSeconds 已設置

項目：Argo Rollouts

優秀實踐： 用戶可以設置progressDeadlineSeconds，它以秒為單位說明在更新期間推出必須取得進展的最長時間，然后才被認為失敗。

如果 rollout pod 陷入錯誤狀態（例如image pull back off?），則 rollout 會在超過進度期限后降級，但錯誤的replica set/pods? 不會按比例縮小。Pod 將不斷重試，最終推出消息將顯示ProgressDeadlineExceeded: The replicaset has timed out progressing?。要中止推出，用戶應同時設置progressDeadlineSeconds?和設置progressDeadlineAbort: true

10. 確保自定義資源與 ArgoCD 實例的命名空間匹配

項目：Argo CD

優秀實踐： 在每個存儲庫中，所有Application和AppProject?清單都應匹配相同的metadata.namespace。原因實際上取決于您如何安裝 Argo CD。

如果您在典型部署中部署了 Argo CD，則 Argo CD 會在后臺創建兩個ClusterRoles和ClusterRoleBinding?，默認情況下它們引用argocd?命名空間。在這種情況下，建議不僅要確保所有 Argo CD 資源與 Argo CD 實例的命名空間匹配，還要使用argocd命名空間，否則，您需要確保更新所有 Argo CD 內部資源中的命名空間引用。

但是，如果您為外部集群部署 Argo CD（在“命名空間隔離模式”中），那么 Argo 會在部署 Argo CD 的命名空間中創建角色和關聯的RoleBinding?，而不是ClusterRole和ClusterRoleBinding?。創建的服務帳戶被授予有限級別的管理訪問權限，因此要使 Argo CD 能夠按需要運行，必須明確授予對命名空間的訪問權限。在這種情況下，建議確保所有資源，包括 Application和AppProject，使用 ArgoCD 實例的正確命名空間。

原文：https://datree.io/resources/argocd-best-practices-you-should-know?