Kubernetes扩展神器Argo实践
Kubernetes扩展神器Argo实践

int32bit
来自专栏Kubernetes
1 关于Argo
Argo是一个开源的项目,其项目宗旨为:
Get stuff done with Kubernetes.
我的理解有两个意思:一是通过Argo能够更好地把应用运行在Kubernetes平台,二是扩展Kubernetes的原生功能,实现原生Kubernetes没有完成的事。
目前Argo包含多个子项目:
Argo Workflows:基于容器的任务编排工具。
Argo CD:基于GitOps声明的持续交付工具。
Argo Events:事件驱动工具。
Argo Rollouts:支持金丝雀以及蓝绿发布的应用渐进式发布工具。
本文接下来将分别介绍如上4个工具。
2 Job编排神器Argo Workflow
2.1 Kubernetes Job的问题
Kubernetes平台主要运行一些持续运行的应用,即daemon服务,其中最擅长的就是无状态服务托管,比如Web服务,滚动升级rollout和水平扩展scale out都非常方便。
而针对基于事件触发的非持续运行的任务,Kubernetes原生能力可以通过Job实现,不过,Job仅解决了单一任务的执行,目前Kubernetes原生还没有提供多任务的编排能力,无法解决多任务的依赖以及数据交互问题。
比如启动一个测试任务,首先需要从仓库拉取最新的代码,然后执行编译,最后跑批单元测试。这些小的子任务是串行的,必须在前一个任务完成后,才能继续下一个任务。
如果使用Job,不太优雅的做法是每个任务都轮询上一个任务的状态直到结束。或者通过initContainers实现,因为initContainer是按顺序执行的,可以把前两个任务放initContainer,最后单元测试放到主Job模板中,这样Job启动时前面的initContainer任务保证是成功执行完毕。
不过initContainer只能解决非常简单的按顺序执行的串行多任务问题,无法解决一些复杂的非线性任务编排,这些任务的依赖往往形成一个复杂的DAG(有向图),比如:
图中hello2a、hello2b任务依赖于hello1,必须等待A完成之后才能继续,hello1完成后hello2a、hello2b两个任务是可以并行的,因为彼此并无依赖,但hello3必须等待hello2a、hello2b都完成后才能继续。
这种问题通过Kubernetes的原生能力目前还不能很好的解决。
以一个实际场景为例,我们需要实现iPaaS中间件在公有云上自动部署,大致为两个过程,首先通过Terraform创建虚拟机,然后通过Ansible实现中间件的自动化部署和配置。如果使用Kubernetes Job,需要解决两个问题:
Terraform创建虚拟机完成后如何通知Ansible?
Terraform如何把虚拟机的IP、公钥等信息传递给Ansible,如何动态生成inventory?
显然如果单纯使用Kubernetes Job很难完美实现,除非在容器中封装一个很复杂的逻辑,实现一个复杂的编排engine,这就不是Job的问题了。
2.2 Argo workflow介绍
Argo workflow专门设计解决Kubernetes工作流任务编排问题,这个和OpenStack平台的Mistral项目作用类似。
上面的任务可以很轻易地通过Workflow编排:
# ...省略
templates:
- name: hello
# Instead of just running a container
# This template has a sequence of steps
steps:
- - name: hello1 # hello1 is run before the following steps
template: whalesay
arguments:
parameters:
- name: message
value: "hello1"
- - name: hello2a # double dash => run after previous step
template: whalesay
arguments:
parameters:
- name: message
value: "hello2a"
- name: hello2b # single dash => run in parallel with previous step
template: whalesay
arguments:
parameters:
- name: message
value: "hello2b"
- - name: hello3 # double dash => run after previous step
template: whalesay
arguments:
parameters:
- name: message
value: "hello3"
# This is the same template as from the previous example
- name: whalesay
inputs:
parameters:
- name: message
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
steps定义任务的执行步骤,其中- -表示与前面的任务串行,即必须等待前面的任务完成才能继续。而-表示任务不依赖于前一个任务,即可以与前一个任务并行。
因为Workflow实现了Kubernetes的CRD,因此提交workflow任务可以直接通过kubectl apply,当然也可以通过argo submit提交。
argo submit step-demo.yaml
查看任务状态:
从状态图中也可以看出hello2a和hello2b是并行执行的。
2.3 DAG图
通过steps可以很方便的定义按顺序执行的线性任务,不过如果任务依赖不是线性的而是多层树依赖,则可以通过dag进行定义,dag即前面介绍的DAG有向无环图,每个任务需要明确定义所依赖的其他任务名称。
dag:
tasks:
- name: hello1
template: whalesay
arguments:
parameters:
- name: message
value: "hello1"
- name: hello2
dependencies: [hello1]
template: whalesay
arguments:
parameters:
- name: message
value: "hello2"
- name: hello3
dependencies: [hello1]
template: whalesay
arguments:
parameters:
- name: message
value: "hello3"
- name: hello4
dependencies: [hello2, hello3]
template: whalesay
arguments:
parameters:
- name: message
value: "hello4"
- name: hello5
dependencies: [hello4]
template: whalesay
arguments:
parameters:
- name: message
value: "hello5"
dag中的tasks通过dependencies明确定义依赖的任务,如上DAG如图:
2.4 分支、循环与递归
除了正向依赖关系,Workflow还支持分支、循环、递归等,以官方的一个硬币分支为例:
templates:
- name: coinflip
steps:
- - name: flip-coin
template: flip-coin
- - name: heads
template: heads
when: "{{steps.flip-coin.outputs.result}} == 1"
- name: tails
template: tails
when: "{{steps.flip-coin.outputs.result}} == 0"
- name: flip-coin
script:
image: python:alpine3.6
command: [python]
source: |
import random
print(random.randint(0,1))
- name: heads
container:
image: alpine:3.6
command: [sh, -c]
args: ["echo \"it was heads\""]
- name: tails
container:
image: alpine:3.6
command: [sh, -c]
args: ["echo \"it was tails\""]
如上flip-coin通过Python随机生成0或者1,当为1时heads任务执行,反之tails任务执行:
如上由于结果为0,因此heads没有执行,而tails执行了,并且输出了it was tails。
2.5 input与output
任务之间除了定义依赖关系,还可以通过input、output实现数据交互,即一个task的output可以作为另一个task的input。
templates:
- name: output-parameter
steps:
- - name: generate-parameter
template: whalesay
- - name: consume-parameter
template: print-message
arguments:
parameters:
- name: message
value: "{{steps.generate-parameter.outputs.parameters.hello-param}}"
- name: whalesay
container:
image: docker/whalesay:latest
command: [sh, -c]
args: ["echo -n hello world > /tmp/hello_world.txt"]
outputs:
parameters:
- name: hello-param
valueFrom:
path: /tmp/hello_world.txt
- name: print-message
inputs:
parameters:
- name: message
container:
image: docker/whalesay:latest
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
如上generate-parameter通过whalesay输出hello world到/tmp/hello_world.txt上并作为outputs输出。而print-message直接读取了generate-parameter outputs作为参数当作inputs。
2.6 Artifacts
除了通过input和output实现数据交互,对于数据比较大的,比如二进制文件,则可以通过Artifacts制品进行共享,这些制品可以是提前准备好的,比如已经存储在git仓库或者s3中,也可以通过任务生成制品供其他任务读取。
如下为官方的一个例子:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: artifact-example-
spec:
entrypoint: main
templates:
- name: main
steps:
- - name: generate-artifact
template: whalesay
- - name: consume-artifact
template: print-message
arguments:
artifacts:
- name: message
from: "{{steps.generate-artifact.outputs.artifacts.hello-art}}"
- name: whalesay
container:
image: docker/whalesay:latest
command: [sh, -c]
args: ["sleep 1; cowsay hello world | tee /tmp/hello_world.txt"]
outputs:
artifacts:
- name: hello-art
path: /tmp/hello_world.txt
- name: print-message
inputs:
artifacts:
- name: message
path: /tmp/message
container:
image: alpine:latest
command: [sh, -c]
args: ["cat /tmp/message"]
如上generate-artifact任务完成后output输出一个名为hello-art的制品,这个制品会把/tmp/hello_world.txt这个文件打包后上传到制品库中,默认制品库可以通过configmap配置,通常是放在S3上。
print-message会从制品库中读取hello-art这个制品内容并输出。
2.7 其他功能
前面涉及的任务都是非持续运行任务,Workflow也支持后台Daemon任务,但是一旦所有的任务结束,即整个workflow完成,这些Daemon任务也会自动删除,这种场景主要用于自动化测试,比如产品API测试,但是API可能依赖于数据库,此时可以通过Workflow的task先启动一个数据库,然后执行自动化测试,测试完成后会自动清理环境,非常方便。
另外,Workflow的template中container和Pod的Container参数基本类似,即Pod能使用的参数Workflow也能用,比如PVC、env、resource request/limit等。
2.8 总结
Job解决了在Kubernetes单次执行任务的问题,但不支持任务的编排,难以解决多任务之间的依赖和数据共享。Argo Workflow弥补了这个缺陷,支持通过yaml编排Job任务,并通过input/output以及artifacts实现Job之间数据传递。
3 Deployment扩展之Argo Rollout
3.1 Kubernetes应用发布
早期Kubernetes在还没有Deployment时,可以认为应用是不支持原地滚动升级的,虽然针对ReplicationController,kubectl看似有一个rolling-update的自动升级操作,但这个操作的步骤其实都是客户端实现的,比如创建新版本ReplicationContrller,增加新版本副本数减少老版本副本数都是客户端通过调用api-server实现,如果本地网络故障或者kubectl进程异常退出,则会导致升级失败,使RC处于半升级异常状态。
而后Deployment出现,ReplicationContrller废弃被Replicasets替代,Kubernetes应用渐进式滚动升级完美解决,整个步骤都是由Deployment Controller负责的,无需客户端干预,并且还支持了应用的版本管理,可以很方便的回滚到任意版本上。
Deployment还支持配置maxSurge、maxUnavailable控制渐进式版本升级过程,但目前原生还不支持版本发布策略,比如常见的金丝雀发布、蓝绿发布等。
当然你可以通过手动创建一个新的Deployment共享一个Service来模拟金丝雀和蓝绿发布,不过这种方式只能手动去维护应用版本和Deployment资源,而集成外部工具比如Spinnaker则会比较复杂。
3.2 Argo Rollout
Argo Rollout可以看做是Kubernetes Deployment的功能扩展,弥补了Deployment发布策略的功能缺失部分,支持通过.spec.strategy配置金丝雀或者蓝绿升级发布策略。
把一个Deployment转化成Rollout也非常简单,只需要:
apiVersion由apps/v1改成argoproj.io/v1alpha1。
kind由Deployment改成Rollout。
在原来的.spec.strategy中增加canary或者bluegreen配置。
3.3 金丝雀发布
以Kubernetes经典教程的Kubernetes-bootcamp为例:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
labels:
app: canary-demo
name: canary-demo
spec:
replicas: 5
selector:
matchLabels:
app: canary-demo
strategy:
canary:
steps:
- setWeight: 20
- pause: {}
- setWeight: 40
- pause: {duration: 10m}
- setWeight: 60
- pause: {duration: 10m}
- setWeight: 80
- pause: {duration: 10m}
template:
metadata:
labels:
app: canary-demo
spec:
containers:
- image: jocatalin/kubernetes-bootcamp:v1
name: kubernetes-bootcamp
字段配置和Deployment基本完全一样,主要关注.spec.strategy,这里定义了金丝雀canary策略,发布共分为8个步骤,其中pause为停止,如果没有指定时间则会一直处于停止状态,直到有外部事件触发,比如通过自动化工具触发或者用户手动promote。
第一步设置weight为20%,由于一共5个副本,因此升级20%意味着只升级一个副本,后续的40%、60%、80%依次类推。
创建完后我们直接通过kubectl edit修改镜像为jocatalin/kubernetes-bootcamp:v2,此时触发升级。
我们查看rollout实例如下:
我们发现新版本有一个副本,占比20%。
由于我们没有通过canaryService以及stableService,因此Service没有做流量分割,大概会有20%的流量会转发给到新版本。当然这种流量切割粒度有点粗略,如果想要更细粒度的控制流量,可以通过ingress或者istio实现基于权值的流量转发策略。
如果在.spec.strategy中指定了canaryService以及stableService,则升级后会做流量分割,canaryService只会转发到新版本流量,而stableService则只转发到老版本服务,这是通过修改Service的Selector实现的,升级后会自动给这两个Service加上一个Hash。
手动执行promote后进入下一步,此时新版本为40%:
由此可见,我们可以通过定义canary策略,使用rollout渐进式的发布我们的服务。
3.4 蓝绿发布
与金丝雀发布不一样,蓝绿发布通常同时部署两套完全一样的不同版本的服务,然后通过负载均衡进行流量切换。
rollout支持blueGreen策略,配置也非常简单,如下:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
labels:
app: bluegreen-demo
name: bluegreen-demo
spec:
replicas: 5
selector:
matchLabels:
app: bluegreen-demo
strategy:
blueGreen:
activeService: bluegreen-active
previewService: bluegreen-preview
autoPromotionEnabled: false
template:
metadata:
labels:
app: bluegreen-demo
spec:
containers:
- image: jocatalin/kubernetes-bootcamp:v1
name: kubernetes-bootcamp
如上配置了blueGreen策略,相比canary配置会更简单,其中配置了两个Service,分别为activeService和previewService,分别负责老版本和新版本的流量转发。
我们修改image为v2后,查看rollout信息如下:
我们发现同时部署了一个新版本和老版本,通过不同的Service访问不同的版本,基本可以等同于部署了两个Deployment。
执行promote后老版本默认会在30秒后自动销毁,并自动把active指向新版本。
3.5 Analysis
无论是采用何种发布策略,在新版本正式上线前,通常都需要进行大量的测试,只有测试没有问题之后才能安全地切换流量,正式发布到新版本。
测试既可以手动测试,也可以自动测试。前面我们的canary和bluegreen Demo都是手动promote发布的,这显然不是效率最高的方法,事实上rollout提供了类似Kayenta的自动化测试分析的工具,能够在金丝雀或者蓝绿发布过程中自动进行分析测试,如果新版本测试不通过,则升级过程会自动终止并回滚到老版本。
测试的指标来源包括:
prometheus: 通过prometheus的监控指标分析测试结果,比如服务如果返回5xx则测试不通过。
kayenta: 通过kayenta工具分析。
web: web测试,如果结果返回OK则测试通过,可以使用服务的healthcheck接口进行测试。
Job: 自己定义一个Job进行测试,如果Job返回成功则测试通过。
这里以Job为例,配置Analysis模板为例:
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: analysis-demo
spec:
metrics:
- name: analysis-demo
interval: 10s
failureLimit: 3
provider:
job:
spec:
backoffLimit: 0
template:
spec:
containers:
- name: test
image: busybox
imagePullPolicy: IfNotPresent
command:
- sh
- -c
- '[[ $(expr $RANDOM % 2) -eq 1 ]]'
restartPolicy: Never
这个Job没有意义,只是随机返回成功和失败,如果失败次数超过3则认为整个分析过程失败。
我们仍然以前面的金丝雀发布为例,加上Analysis如下:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
labels:
app: canary-demo
name: canary-demo
spec:
replicas: 5
selector:
matchLabels:
app: canary-demo
strategy:
canary:
analysis:
templates:
- templateName: analysis-demo # 引用analysis模板
steps:
- setWeight: 20
- pause: {duration: 2m}
- setWeight: 40
- pause: {duration: 2m}
- setWeight: 60
- pause: {duration: 2m}
- setWeight: 80
- pause: {duration: 2m}
template:
metadata:
labels:
app: canary-demo
spec:
containers:
- image: jocatalin/kubernetes-bootcamp:v1
imagePullPolicy: IfNotPresent
name: kubernetes-bootcamp
部署如上应用并通过kubectl edit修改image为kubernetes-bootcamp:v2,查看rollout信息如下:
当失败次数超过3时,发布失败,自动降级回滚:
3.6 总结
Argo Rollout可以认为是Deployment的扩展,增加了蓝绿发布和金丝雀发布策略配置,并且支持通过自动测试实现服务发布或者回滚。
4 Argo Event
4.1 Argo Event简介
Event事件大家都很熟悉,可以说Kubernetes就是完全由事件驱动的,不同的controller manager本质就是实现了不同的事件处理函数,比如所有ReplicaSet对象是由ReplicaSetController控制器管理,该控制器通过Informer监听ReplicaSet以及其关联的Pod的事件变化,从而维持运行状态和我们声明spec保持一致。
当然Kubernetes无论是什么Controller,其监听和处理的都是内部事件,而在应用层上我们也有很多外部事件,比如CICD事件、Webhook事件、日志事件等等,如何处理这些事件呢,目前Kubernetes原生是无法实现的。
当然你可以自己实现一个event handler运行在Kubernetes平台,不过实现难度也不小。而Argo Event组件完美解决了这个问题。
如图是Argo Event官方提供的的流程图:
首先事件源EventSource可以是Webhook、S3、Github、SQS等等,中间会经过一个叫Gateway(新版本叫EventBus)的组件,更准确地说老版本原来gateway的配置功能已经合并到EventSource了,EventBus是新引入的组件,后端默认基于高性能分布式消息中间件NATS[1]实现,当然其他中间件比如Kafka也是可以的。
这个EventBus可以看做是事件的一个消息队列,消息生产者连接EvenSource,EventSource又连接到Sensor。更详细地说EvenSource把事件发送给EvenBus,Sensor会订阅EvenBus的消息队列,EvenBus负责把事件转发到已订阅该事件的Sensor组件,EventSorce在上图中没有体现,具体设计文档可以参考Argo-events Enhancement Proposals[2]。
有些人可能会说为什么EventBus不直接到Trigger,中间引入一个Sensor,这主要是两个原因,一是为了使事件转发和处理松耦合,二是为了实现Trigger事件的参数化,通过Sensor不仅可以实现事件的过滤,还可以实现事件的参数化,比如后面的Trigger是创建一个Kubernetes Pod,那这个Pod的metadata、env等,都可以根据事件内容进行填充。
Sensor组件注册关联了一个或者多个触发器,这些触发器可以触发AWS Lambda事件、Argo Workflow事件、Kubernetes Objects等,通俗简单地说,可以执行Lambda函数,可以动态地创建Kubernetes的对象或者创建前面的介绍的Workflow。
还记得前面介绍的Argo Rollout吗,我们演示了手动promote实现应用发布或者回滚,通过Argo Event就可以很完美地和测试平台或者CI/CD事件结合起来,实现自动应用自动发布或者回滚。
4.2 一个简单的Webhook例子
关于Argo Event的部署非常简单,直接通过kubecl apply或者helm均可,可以参考文档Installation[3],这里不再赘述。
Argo Event部署完成后注意还需要部署EventBus,官方推荐使用NATS中间件,文档中有部署NATS stateful的文档。
接下来我们以一个最简单的Webhook事件为例,从而了解Argo Event的几个组件功能以及用法。
首先按照前面的介绍,我们需要先定义EventSource:
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
name: webhook
spec:
service:
ports:
- port: 12000
targetPort: 12000
webhook:
webhook_example:
port: "12000"
endpoint: /webhook
method: POST
这个EventSource定义了一个webhook webhook_example,端口为12000,路径为/webhook,一般Webhook为POST方法,因此该Webhhok处理器我们配置只接收POST方法。
为了把这个Webhook EventSource暴露,我们还创建了一个Service,端口也是12000。
此时我们可以手动curl该Service:
# kubectl get svc -l eventsource-name=webhook
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
webhook-eventsource-svc ClusterIP 10.96.93.24 <none> 12000/TCP 5m49s
# curl -X POST -d '{}' 10.96.93.24:12000/webhook
success
当然此时由于没有注册任何的Sensor,因此什么都不会发生。
接下来我们定义Sensor:
首先在dependencies中定义了订阅的EventSource以及具体的Webhook,由于一个EventSource可以定义多个Webhook,因此必须同时指定EventSource和Webhook两个参数。
在Trigger中我们定义了对应Action为create一个workflow,这个workflow的spec定义在resource中配置。
最后的parameters部分定义了workflow的参数,这些参数值从event中获取,这里我们会把整个event都当作workflow的input。当然你可以通过dataKey只汲取body部分:dataKey: body.message。
此时我们再次curl这个webhook事件:
curl -X POST -d '{"message": "HelloWorld!"}' 10.96.93.24:12000/webhook
此时我们获取argo workflow列表发现新创建了一个实例:
# argo list
NAME STATUS AGE DURATION PRIORITY
webhook-8xt4s Succeeded 1m 18s 0
查看workflow输出如下:
由于我们是把整个event作为workflow input发过去的,因此data内容部分是base64编码,我们可以查看解码后的内容如下:
{
"header": {
"Accept": [
"*/*"
],
"Content-Length": [
"26"
],
"Content-Type": [
"application/x-www-form-urlencoded"
],
"User-Agent": [
"curl/7.58.0"
]
},
"body": {
"message": "HelloWorld!"
}
}
从这里我们也可以看出Event包含两个部分,一个是context,一个是data,data中又包含header部分以及body部分,在parameters中可以通过Key获取任意部分内容。
如上的webhook触发是通过手动curl的,你可以很容易地在github或者bitbucket上配置到webhook中,这样一旦代码有更新就能触发这个事件了。
4.3 Kubernetes触发AWS Lambda函数
前面的例子中的EventSource使用了Webhook,除了Webhook,Argo Event还支持很多的EventSource,比如:
amqp
aws-sns
aws-sqs
github/gitlab
hdfs
kafka
redis
Kubernetes resource
...
Trigger也同样支持很多,比如:
aws lambda
amqp
kafka
...
如上官方都提供了非常丰富的例子,可以参考argo events examples[4]。
这里以Kubernetes resource事件源为例,这个事件监听Kubernetes的资源状态,比如Pod创建、删除等,这里以创建Pod为例:
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
name: k8s-resource-demo
spec:
template:
serviceAccountName: argo-events-sa
resource:
pod_demo:
namespace: argo-events
version: v1
resource: pods
eventTypes:
- ADD
filter:
afterStart: true
labels:
- key: app
operation: "=="
value: my-pod
如上例子监听Pods的ADD事件,即创建Pod,filter中过滤只有包含app=my-pod标签的Pod,特别需要注意的是使用的serviceaccount argo-events-sa必须具有Pod的list、watch权限。
接下来我们使用AWS Lambda触发器,Lambda函数已经在AWS提前创建好:
这个Lambda函数很简单,直接返回event本身。
创建Sensor如下:
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
name: aws-lambda-trigger-demo
spec:
template:
serviceAccountName: argo-events-sa
dependencies:
- name: test-dep
eventSourceName: k8s-resource-demo
eventName: pod_demo
triggers:
- template:
name: lambda-trigger
awsLambda:
functionName: hello
accessKey:
name: aws-secret
key: accesskey
secretKey:
name: aws-secret
key: secretkey
namespace: argo-events
region: cn-northwest-1
payload:
- src:
dependencyName: test-dep
dataKey: body.name
dest: name
如上AWS access key和access secret需要提前放到aws-secret中。
此时我们创建一个新的Pod my-pod:
apiVersion: v1
kind: Pod
metadata:
labels:
app: my-pod
name: my-pod
spec:
containers:
- image: nginx
name: my-pod
dnsPolicy: ClusterFirst
restartPolicy: Always
当Pod启动后,我们发现AWS Lambda函数被触发执行:
4.4 event filter
前面的例子中webhook中所有的事件都会被sensor触发,我们有时不需要处理所有的事件,Argo Event支持基于data以及context过滤,比如我们只处理message为hello或者为hey的事件,其他消息忽略,只需要在原来的dependencies中test-dep增加filter即可:
dependencies:
- name: test-dep
eventSourceName: webhook
eventName: webhook_example
filters:
- name: data-filter
data:
- path: body.message
type: string
value:
- "hello"
- "hey"
filter指定了基于data过滤,过滤的字段为body.message,匹配的内容为hello、hey。
4.5 trigger policy
trigger policy主要用来判断最后触发器执行的结果是成功还是失败,如果是创建Kubernetes资源比如Workflow,可以根据Workflow最终状态决定这个Trigger的执行结果,而如果是触发一个HTTP或者AWS Lambda,则需要自定义policy status。
awsLambda:
functionName: hello
accessKey:
name: aws-secret
key: accesskey
secretKey:
name: aws-secret
key: secretkey
namespace: argo-events
region: us-east-1
payload:
- src:
dependencyName: test-dep
dataKey: body.message
dest: message
policy:
status:
allow:
- 200
- 201
如上表示当AWS Lambda返回200或者201时表示Trigger成功。
4.6 总结
前面介绍的例子都是单事件源单触发器,Argo Event可以支持多种事件源以及触发器,支持各种组合,从而实现把内部以及外部事件结合起来,通过事件驱动把应用以及外围系统连接起来,目前我们已经通过监听代码仓库Push或者PR Merge更新自动触发Workflow收集C7N policy到自动化平台系统中。
5 Argo CD
5.1 关于GitOps
最近各种Ops盛行,比如DevOps、DevSecOps、AIOps、GOps、ChatOps、GitOps等等,这些都可以认为是持续交付的一种方式,而本章主要关注其中的GitOps。
GitOps的概念最初来源于Weaveworks的联合创始Alexis在2017年8月发表的一篇博客GitOps - Operations by Pull Request[5],由命名就可以看出GitOps将Git作为交付流水线的核心。
通俗地讲,就是通过代码(code)定义基础设施(infrastructure)以及应用(application),这些代码可以是Terraform的声明文件或者Kubernetes或者Ansible的yaml声明文件,总之都是代码。
这些代码均可以通过git代码仓库(如github、gitlab、bitbuket)进行版本管理。这样就相当于把基础设施和应用通过git仓库管理起来了,如果需要做应用变更,只需要提交一个Pull Request,merge后持续交付工具自动根据变更的声明文件进行变更,收敛到最终期望的状态。应用回滚则只需要通过git revert即可。
通过git log可以方便地查看应用的版本信息,通过git的多分支可以指定交付的不同环境,比如开发测试环境、预发环境、生产环境等。
GitOps特别适合云原生应用,yaml定义一切,因此GitOps在Weaveworks的推广下流行起来,目前Jenkins X、Argo CD、Weave Flux、Spinnaker等均是基于GitOps模型的持续交付工具。
本章主要介绍其中的Argo CD工具。
5.2 Argo CD
Argo CD也是Argoproj项目中开源的一个持续集成工具,功能类似Spinnaker。
其部署也非常简单,可以参考官方文档Getting Started[6]。
ArgoCD内置了WebUI以及CLI工具,CLI工具功能比较全,比如只能通过CLI添加cluster,在WebUI上无法完成。
ArgoCD主要包含如下实体:
Repository: 代码仓库,支持HTTPS或者SSH协议纳管代码仓库,代码仓库中包含Kubernetes yaml文件或者Helm Chart等。
Cluster:Kubernetes集群,通常需要托管多个Kubernetes,比如生产环境、测试环境、预发环境、版本环境等。
Project:其实就是Repository和Cluster建立关系,即把Repository中的声明的应用部署到指定的Cluster中。
APP:Project的运行态。
5.3 Argo CD简单演示
Argo CD由于已经提供了WebUI,只需要按照UI界面提示一步步操作即可,没有什么难度。这里快速演示下如何使用Argo CD。
首先在github上创建了一个my-app的仓库,仓库的app目录下创建了一个my-app.yaml文件:
my-app.yaml文件内容如下:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: my-app
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- image: jocatalin/kubernetes-bootcamp:v1
name: my-app
在Argo CD中创建一个Repository:
接着在Argo CD中创建一个Project,指定Repository以及Cluster:
最后创建App即可:
此时应用自动进行同步和部署:
同步完成后,所有创建的资源都是可视化的:
现在我们把版本升级到v2:
git checkout -b v2
sed -i 's#jocatalin/kubernetes-bootcamp:v1#jocatalin/kubernetes-bootcamp:v2#g' app/my-app.yaml
git add .
git commit -m "Upgrade my app to v2"
git push --set-upstream origin v2
如上我们也可以直接push代码到master分支,不过为了按照GitOps的标准流程,我们创建了一个新的分支v2,通过Pull Request合并到master分支中。
在github上创建Pull Request并Merge后,应用自动进行了更新:
5.4 总结
Argo CD是基于GitOps模型的持续集成工具,搭配CI工具完成应用的自动构建并推送镜像到仓库中,配合CD完成应用的持续交付。
参考资料
[1]
NATS: https://nats.io/
[2]
Argo-events Enhancement Proposals: https://docs.google.com/document/d/1uPt2DyvzObEzZVbREqjW-o1gKCZ_hB8QS5Syw7_MLT8/edit#
[3]
Installation: https://argoproj.github.io/argo-events/installation/
[4]
argo events examples: https://github.com/argoproj/argo-events/tree/master/examples
[5]
GitOps - Operations by Pull Request: https://www.weave.works/blog/gitops-operations-by-pull-request
[6]
Getting Started: https://argoproj.github.io/argo-cd/