问卷链接（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_IAM3. 插件安装
并行插件安装（带依赖）
安装插件使用普通的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微信公众号。