十个关于 ArgoCD 的优秀实践

十个关于 ArgoCD 的优秀实践

作者:Noaa Barki 2022-08-12 07:48:49

云计算

云原生 在本文中,我们将探索我发现的一些 Argo 优秀实践。

在本文中,我们将探索我发现的一些 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​

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/254561.html<

(0)
管理的头像管理
上一篇2025-04-30 10:36
下一篇 2025-04-30 10:38

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注