关于cncf:使用Argo和Kubernetes构建Kubernetes集群

你填了吗？2020 年 CNCF 中国云原生问卷

问卷链接（https://www.wjx.cn/jq/9714648…）

客座文章来自 SAP 高级零碎工程师 Tomas Valasek。Tomas 从 2014 年开始从事容器、云原生和云自动化方面的工作，同时也是 SAP Concur 公司 Kubernetes 的技术倡导者。在这篇文章中，他谈到了 SAP Concur 团队如何应用 Argo Workflows、Argo Events、Helm 和 EKS 来自动化创立、附加组件装置、应用前测试和最终的集群验证。原文连贯。

等等……什么？是的，当我第一次提出应用 Kubernetes 构建 Kubernetes 集群的想法时，我就听到了这种反馈。

然而，对于云基础设施自动化，我想不出比 Kubernetes 更好的工具了。咱们应用一个地方 K8s 集群构建和治理数百个其余 K8s 集群。在本文中，我将向你展现如何做到这一点。

留神：SAP Concur 应用 AWS EKS，相似的概念能够利用于谷歌的 GKE，Azure 的 AKS，或任何其余云提供商的 Kubernetes 产品。

生产就绪

在任何次要的云提供商中构建一个 Kubernetes 集群素来没有这么容易过。使 AWS EKS 集群启动和运行就像：

$ eksctl create cluster

然而，要构建可用于生产的 Kubernetes 集群，还须要更多。尽管生产就绪的定义可能不同，但 SAP Concur 应用这 4 个构建阶段来构建和交付生产就绪的 Kubernetes 集群。

4 个构建阶段

• 应用前测试：针对指标 AWS 环境的一组根本测试，以确保在咱们开始理论的集群构建之前所有需要都已就绪。例如：每个子网的可用 IP 地址、AWS 导出、SSM 参数或其余变量。
• EKS 管制立体和节点组：这是一个理论的 AWS EKS 集群，带有附加的工作节点。
• 插件装置：装璜。这就是让你的集群更甘甜的中央:-) 装置像 Istio、日志集成、autoscaler 等插件。插件的列表是全面和齐全可选的。
• 集群验证：在这个阶段，咱们从性能的角度验证集群（EKS 外围组件和插件），而后再将其签名并移交。你写的测试越多，你的睡眠就越好。（尤其是当你是 on-call 的时候！）

把它们粘合起来！

这 4 个构建阶段都应用不同的工具和技术（我将在前面形容）。咱们正在寻找一种工具，能够将它们粘合在一起，同时反对序列和并行性；API 驱动；并且最好可能可视化每个构建。

瞧！咱们发现了 Argo 产品家族，特地是 Argo Events 和 Argo Workflows。两者都作为 CRD 在 Kubernetes 上运行，并应用在其余 Kubernetes 部署中应用的 YAML 申明式概念。

咱们找到了完满的组合：命令式编排和申明式自动化

应用 Argo Workflows 构建的生产就绪的 K8s 集群

用 Argo Workflows 合成流程

Argo Workflows 是一个开源的容器原生工作流引擎，用于在 Kubernetes 上编排并行作业。Argo Workflows 实现为 Kubernetes CRD。

留神：如果你相熟 K8s YAML，我保障这将很容易。

让咱们看看这 4 个构建阶段在 Argo Workflows 中是什么样的。

1. 应用前测试

应用前测试与失败时的重试并行运行

咱们应用 BATS 测试框架作为一个无效的工具来编写测试。编写一个应用前测试在 BATS 能够简略的如下：

#!/usr/bin/env bats@test“More than 100 available IP addresses in subnet MySubnet”{AvailableIpAddressCount=$(aws ec2 describe-subnets --subnet-ids MySubnet | jq -r‘.Subnets[0].AvailableIpAddressCount’)
 [“${AvailableIpAddressCount}”-gt 100 ]}

并行运行下面的 BATS 测试文件（available-ip-address.bats）和其余 3 个应用 Argo Workflows 的虚构 BATS 测试，会如下所示：

— name: preflight-tests
 templateRef: 
 name: argo-templates
 template: generic-template
 arguments:
 parameters:
 — name: command
 value:“{{item}}”withItems:
 — bats /tests/preflight/accnt-name-export.bats”— bats /tests/preflight/avail-ip-addresses.bats”— bats /tests/preflight/dhcp.bats”— bats /tests/preflight/subnet-export.bats”

2. EKS 管制立体和节点组

EKS 管制立体和具备依赖关系的节点组

你能够自由选择构建理论的 EKS 集群。可用的工具有 eksctl、CloudFormation 或 Terraform 模板。应用 CloudFormation 模板（eks-controlplane.yaml 和 eks-nodegroup.yaml）两个步骤的 Argo Workflows 与依赖关系如下所示。

— name: eks-controlplane
 dependencies: [“preflight-tests”]
 templateRef: 
 name: argo-templates
 template: generic-template
 arguments:
 parameters:
 — name: command
 value: |
 aws cloudformation deploy 
 --stack-name {{workflow.parameters.CLUSTER_NAME}} 
 --template-file /eks-core/eks-controlplane.yaml 
 --capabilities CAPABILITY_IAM- name: eks-nodegroup
 dependencies: [“eks-controlplane”]
 templateRef: 
 name: argo-templates
 template: generic-template
 arguments:
 parameters:
 — name: command
 value: |
 aws cloudformation deploy 
 --stack-name {{workflow.parameters.CLUSTER_NAME}}-nodegroup 
 --template-file /eks-core/eks-nodegroup.yaml 
 --capabilities CAPABILITY_IAM

3. 插件装置

并行插件装置（带依赖）

装置插件应用一般的 kubectl、helm、kustomize 或这些工具组合。例如，应用 helm template 和 kubectl 装置 metrics-server 插件时，只有在要求（有条件的）metrics-server 插件装置时，在 Argo Workflows 中能够这样。

— name: metrics-server
 dependencies: [“eks-nodegroup”]
 templateRef: 
 name: argo-templates
 template: generic-template
 when:“‘{{workflow.parameters.METRICS-SERVER}}’!= none”arguments:
 parameters:
 — name: command
 value: |
 helm template /addons/{{workflow.parameters.METRICS-SERVER}}/ 
 --name“metrics-server”--namespace“kube-system”--set global.registry={{workflow.parameters.CONTAINER_HUB}} | 
 kubectl apply -f -

4. 集群验证

失败时进行重试的并行集群验证

为了验证插件的性能，咱们应用了杰出的 BATS 库 DETIK，这使得编写 K8s 测试变得轻而易举。

#!/usr/bin/env batsload“lib/utils”load“lib/detik”DETIK_CLIENT_NAME=”kubectl”DETIK_CLIENT_NAMESPACE="kube-system"@test“verify the deployment metrics-server”{
 
 run verify“there are 2 pods named‘metrics-server’”[“$status”-eq 0]
 
 run verify“there is 1 service named‘metrics-server’”[“$status”-eq 0]
 
 run try“at most 5 times every 30s to find 2 pods named‘metrics-server’with‘status’being‘running’”[“$status”-eq 0]
 
 run try“at most 5 times every 30s to get pods named‘metrics-server’and verify that‘status’is‘running’”[“$status”-eq 0]
}

执行以上 BATS DETIK 测试文件（metrics-server.bats），只有当装置了 metrics-server 插件，在 Argo Workflows 是这样的：

— name: test-metrics-server
 dependencies: [“metrics-server”]
 templateRef:
 name: worker-containers
 template: addons-tests-template
 when:“‘{{workflow.parameters.METRICS-SERVER}}’!= none”arguments:
 parameters:
 — name: command
 value: |
 bats /addons/test/metrics-server.bats

设想一下你能够在这里插入多少验证测试。你是否须要运行 Sonobuoy conformance tests、Popeye — A Kubernetes Cluster Sanitizer 或 Fairwinds’Polaris？把他们放到 Argo Workflows 上！

如果你曾经做到了这一点，那么你曾经构建了一个性能残缺的、可用于生产的 AWS EKS 集群，并装置、测试了 metrics-server 插件，能够移交了。做得好！

但不要当初就来到，最好的总会在最初呈现。

WorkflowTemplates

Argo Workflows 反对 WorkflowTemplate，容许可重用工作流。这 4 个构建阶段中的每一个都是 WorkflowTemplate。咱们基本上曾经创立了能够依据须要组合的构建块。应用一个“主”工作流能够按程序执行所有构建阶段（如下面的例子），或者每个阶段都能够独立执行。这种灵活性是通过 Argo Events 实现的。

Argo Events

Argo Events 是一个 Kubernetes 的事件驱动的工作流自动化框架，它能够帮忙你触发 K8s 对象、Argo Workflows、无服务器的工作负载等来自各种起源的事件，如 webhook、s3、调度、音讯队列、gcp pubsub、sns、sqs 等。

集群构建由应用 JSON 无效负载的 API 调用（Argo Events）触发。除此之外，这 4 个构建阶段（WorkflowTemplates）中的每一个都有其本人的 API 端点。Kubernetes 操作员能够从中受益匪浅：

• 不确定云环境的状态？调用应用前 API
• 想要构建裸 EKS 集群吗？调用 eks-core（管制立体和节点组）API
• 想要从新 / 装置插件到现有的 EKS 集群？调用插件 API
• 集群呈现问题，你须要疾速运行一系列测试？调用测试 API

Argo 个性

Argo Events 和 Argo Workflows 都提供了大量开箱即用的个性，能够节俭你本人编写。

对于咱们的用例来说，最不便的 7 个是：

• 事件传感器参数
• WorkflowTemplates
• S3 反对
• 重试 – 留神上图中红色的应用前测试和验证测试失败。Argo 主动重试，后果胜利。
• 并行性
• 依赖关系
• 条件

总结

可能应用大量的工具协同工作并强制定义所需的基础架构状态，能够实现灵活性，而不会造成折衷和高我的项目速度。咱们心愿在其余自动化工作中应用 Argo Events 和 Workflows。可能性是有限的。

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月，隶属于 Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。