十個(gè)關(guān)于 ArgoCD 的優(yōu)秀實(shí)踐

作者：Noaa Barki 2022-08-12 07:48:49
云計(jì)算
云原生 在本文中，我們將探索我發(fā)現(xiàn)的一些 Argo 優(yōu)秀實(shí)踐。

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

1. 不允許提供空的 retryStrategy

項(xiàng)目：Argo Workflows

優(yōu)秀實(shí)踐： 用戶可以指定一個(gè)retryStrategy?來指示如何在工作流中重試失敗或錯(cuò)誤的步驟。提供一個(gè)空的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ù)器交互的能力。這允許訪問單個(gè)容器的攻擊者通過使用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 不會(huì)使用未標(biāo)記app.kubernetes.io/part-of: argocd 的相關(guān) ConfigMap 資源。

安裝 Argo CD 時(shí)，其原子配置包含一些services和configMaps?。對(duì)于每種特定類型的 ConfigMap 和 Secret 資源，只有一個(gè)受支持的資源名稱，如果您需要在創(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?中指定步驟序列的替代方法，您可以通過指定每個(gè)任務(wù)的依賴關(guān)系將工作流定義為有向無環(huán)圖 (DAG)。DAG 邏輯具有內(nèi)置的快速故障功能，可在檢測(cè)到其中一個(gè) DAG 節(jié)點(diǎn)發(fā)生故障時(shí)立即停止調(diào)度新步驟。然后它會(huì)等到所有 DAG 節(jié)點(diǎn)都完成后才會(huì)使 DAG 本身失敗。FailFast[4]標(biāo)志默認(rèn)為true?。如果設(shè)置為false，它將允許 DAG 運(yùn)行 DAG 的所有分支以完成（成功或失?。?，而不管 DAG 中分支的失敗結(jié)果。

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

項(xiàng)目：Argo Rollouts

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

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

6. 指定 Rollout 的 revisionHistoryLimit

項(xiàng)目：Argo Rollouts

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

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

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

項(xiàng)目：Argo Rollouts

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

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

8. 確保在 Error 和 TransientError 時(shí)重試

項(xiàng)目：Argo Workflows

優(yōu)秀實(shí)踐：  retryStrategy是Workflow? CRD 的一個(gè)可選字段，它提供了用于重試工作流步驟的控件。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)級(jí)錯(cuò)誤（例如，節(jié)點(diǎn)死亡或被搶占），但不想重試用戶級(jí)代碼中發(fā)生的錯(cuò)誤，因?yàn)檫@些失敗表明存在錯(cuò)誤。此外，與作為作業(yè)的工作流相比，此選項(xiàng)更適合長(zhǎng)時(shí)間運(yùn)行的容器。
• retryPolicy=OnError：不處理搶占，處理一些系統(tǒng)級(jí)錯(cuò)誤，例如節(jié)點(diǎn)消失或 pod 被刪除。但是，在 Pod 正常終止期間，kubelet 會(huì)為終止的 Pod 分配一個(gè)失敗狀態(tài)和一個(gè)關(guān)閉原因。因此，節(jié)點(diǎn)搶占導(dǎo)致節(jié)點(diǎn)狀態(tài)為Failure?，而不是Error，因此不會(huì)重試搶占。

我們建議設(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)展的最長(zhǎng)時(shí)間，然后才被認(rèn)為失敗。

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

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

項(xiàng)目：Argo CD

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

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

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

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

分享文章：十個(gè)關(guān)于ArgoCD的優(yōu)秀實(shí)踐
鏈接地址：http://www.dlmjj.cn/article/dhpsejo.html