当前位置:网站首页>使用Argo和Kubernetes构建Kubernetes集群

使用Argo和Kubernetes构建Kubernetes集群

2020-12-08 11:09:21 Donald

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

版权声明
本文为[Donald]所创,转载请带上原文链接,感谢
https://segmentfault.com/a/1190000038409935