使用Argo和Kubernetes构建Kubernetes集群

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

问卷链接（https://www.wjx.cn/jq/97146486.aspx）

---

客座文章来自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微信公众号。