你填了吗？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微信公众号。