乐趣区

关于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 微信公众号。

退出移动版