在本文中，我們將探索我發(fā)現(xiàn)的一些 Argo 優(yōu)秀實(shí)踐。

1. 不允許提供空的 retryStrategy

項(xiàng)目：Argo Workflows

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

2. 確保未將 Workflow pod 配置為使用默認(rèn)服務(wù)帳戶

項(xiàng)目：Argo Workflows

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

建議創(chuàng)建具有適當(dāng)角色的專用用戶管理服務(wù)帳戶。

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

項(xiàng)目：Argo CD

優(yōu)秀實(shí)踐： Argo CD 不會使用未標(biāo)記app.kubernetes.io/part-of: argocd 的相關(guān) ConfigMap 資源。

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

4. 用 DAG 禁用以設(shè)置 FailFast = false

項(xiàng)目：Argo Workflows

優(yōu)秀實(shí)踐： 作為在Workflow?中指定步驟序列的替代方法，您可以通過指定每個任務(wù)的依賴關(guān)系將工作流定義為有向無環(huán)圖 (DAG)。DAG 邏輯具有內(nèi)置的快速故障功能，可在檢測到其中一個 DAG 節(jié)點(diǎn)發(fā)生故障時立即停止調(diào)度新步驟。然后它會等到所有 DAG 節(jié)點(diǎn)都完成后才會使 DAG 本身失敗。FailFast[4]標(biāo)志默認(rèn)為true?。如果設(shè)置為false，它將允許 DAG 運(yùn)行 DAG 的所有分支以完成（成功或失?。还?DAG 中分支的失敗結(jié)果。

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

項(xiàng)目：Argo Rollouts

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

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

6. 指定 Rollout 的 revisionHistoryLimit

項(xiàng)目：Argo Rollouts

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

默認(rèn)情況下，會保留 10 個舊 ReplicaSet，但其理想值取決于新 Deployment 的頻率和穩(wěn)定性。更具體地說，將此字段設(shè)置為零意味著將清除所有具有 0 個副本的舊 ReplicaSet。在這種情況下，新的部署無法撤消，因?yàn)樗男抻啔v史已被清除。

7. 將 scaleDownDelaySeconds 設(shè)置為 30s 以確保 iptables 跨集群中的節(jié)點(diǎn)傳播

項(xiàng)目：Argo Rollouts

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

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

8. 確保在 Error 和 TransientError 時重試

項(xiàng)目：Argo Workflows

優(yōu)秀實(shí)踐：  retryStrategy是Workflow? CRD 的一個可選字段，它提供了用于重試工作流步驟的控件。retryStrategy?的字段之一是retryPolicy?，它定義了將被重試的 NodePhase 狀態(tài)的策略（NodePhase 是當(dāng)前節(jié)點(diǎn)的狀態(tài)）。retryPolicy?的選項(xiàng)可以是：Always、OnError或OnTransientError。此外，用戶可以使用表達(dá)式[9]來控制更多的重試次數(shù)。

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

我們建議設(shè)置retryPolicy: "Always"并使用以下表達(dá)式：

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

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

項(xiàng)目：Argo Rollouts

優(yōu)秀實(shí)踐： 用戶可以設(shè)置progressDeadlineSeconds，它以秒為單位說明在更新期間推出必須取得進(jìn)展的最長時間，然后才被認(rèn)為失敗。

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

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

項(xiàng)目：Argo CD

優(yōu)秀實(shí)踐： 在每個存儲庫中，所有Application和AppProject?清單都應(yīng)匹配相同的metadata.namespace。原因?qū)嶋H上取決于您如何安裝 Argo CD。

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

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

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