在今年的Google Cloud Next大会上,Google发布了Knative, 这是由Google、Pivotal、Redhat和IBM等云厂商共同推出的Serverless开源工具组件,它与Istio,Kubernetes一起,形成了开源Serverless服务的三驾马车。
本文来自阿里巴巴中间件事业部美国团队高级技术专家 Andy在 Knative的实践,Andy长期关注Service Mesh技术领域,在Cloud Foundry,Kubernetes,Envoy上等有着丰富的实践和开发经验。加入Service Mesh开发者群,微信添加“zjjxg2018”,并备注公司-城市信息。
有意思的是:上述几家公司是相互竞争的,但却能把各自擅长的技术贡献给同一个开源项目。另一个有意思的地方是对Serverless定义的转变。以前说到Serverless,大家就等同于FaaS,就感觉只要把function代码提交,然后定义event trigger就好了。现在Knative把Serverless这个概念转变成了免运维:用户还是要有server的,只是运维上比管理一个Kubernetes cluster更省心,而且不用的时候并不需要为server资源支付费用。除此之外,FaaS的应用场景很小,只有很小很快的函数才能比较容易部署。Knative以自助的方式实现部署,应用场景更广,且一般的应用都可以部署成Serverless。
根据Knative提供的文档介绍,一个完整的Serverless分为__Build__,__Serve__和__Eventing__三个部分。在本文中,我们将在阿里云上按照Knative github的安装指南,逐步操作,以实现一个Knative应用。
准备
创建 Kubernetes cluster
在阿里云上创建一个Kubernetes cluster,用系统默认的设置就行,但要保证你有Admin权限。如果你用已有的 cluster,请确认Kubernetes的版本是1.10以上。
安装 Knative
这个过程分为两步:
安装Istio:
Knative的Istio有一些自己定义的资源,所以不要用Istio网站的缺省安装。但是Knative现有指南未更新,还是0.8,有些旧。我所用的是1.0:
curl https://raw.githubusercontent.com/knative/serving/master/third_party/istio-1.0.0/istio.yaml
这个安装需要一点时间,但是是必须的。因为Knative依赖Istio来联接Serverless,而不是直接通过Kubernetes。等到所有的安装完成后,我们要开启Istio 自动injection:
kubectl label namespace default istio-injection=enabled
1
安装 Knative组件:
执行下面的命令:
kubectl apply -f https://github.com/knative/serving/releases/download/v0.1.1/release.yaml
安装后等待一会并确认:
kubectl get pods -n knative-serving -w
kubectl get pods -n knative-build -w
细心的同学会发现这里只安装了两部分:Build 和 Serving,那么Eventing呢?是需要单独安装的。
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release.yaml
同样的,运行这个命令来确认:
kubectl get pods -n knative-eventing -w
1
Build
Build是目前Knative项目中内容最丰富的部分。因为Pivotal拿出了压箱宝build packs加入Knative。而Google之前多年做app engine,也在这方面累计了很多经验。
在实现上,Build是一个Kubernetes Custom Resource Definition (CRD)。如同其它的Kubernetes CRD,定义的方式是通过YAML,调用的方式是API。用户可以选择不同的build template,比如Google的kaniko,Pivotal的build pack等。在本文中,我们选择kaniko build。
先安装Kaniko Build Template:
kubectl apply -f https://raw.githubusercontent.com/knative/build-templates/master/kaniko/kaniko.yaml
Kaniko build template和Docker build template最大的不同在于用户不需要本地安装Docker engine, Kaniko把代码搬到云上生成Image。源代码可以在远程的服务器上,还要指定相应的Dockerfile。
但是,这样做有个问题:Kaniko怎么访问用户的docker account呢?因此,我们需要创建一个secret,把用户的docker username和password存在里面。然后,还需要一个service account来绑定这个secret。
vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: docker-user-pass
annotations:
build.knative.dev/docker-0: https://index.docker.io/v1/
type: kubernetes.io/basic-auth
stringData:
username: <docker username in plain text>
password: <docker password in plain text>
把这里的username和password换成你自己的帐号信息,然后保存。
kubectl apply -f secret.yaml
vim service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-bot
secrets:
- name: docker-user-pass
保存后执行:
kubectl apply -f service-account.yaml
然后我们创建Kubernetes manifest vim build.yaml:
apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: docker-build
spec:
serviceAccountName: build-bot #service account created above
source:
git:
revision: master
url: "https://github.com/szihai/hello-go.git"
steps:
-
args:
- "--dockerfile=/workspace/Dockerfile"
- "--destination=docker.io/xxx/helloworld-go"
image: "gcr.io/kaniko-project/executor:v0.1.0"
name: build-and-push
本文所用的sample app是从Knative repo 上fork的。(例子)
在这里,我们指定了template用Kaniko。然后可以看到我们引用了前面的ServiceAccount 来访问secret。用这个之前把里面的destination换成你自己的docker id,保存后用kubectl apply -f build.yaml 来执行。
那么,如何知道远程的Kaniko到底做好了没有呢?Kubernetes 会为kind: Build 创建一个job。用kubectl get pods 找到一个 docker-build-xxxx 的pod。然后运行:kubectl -n default logs docker-build-xxxx -c build-step-build-and-push 来观察build的情况。
我们也可以直接查看Kubetnetes build objects: kubectl describe builds。要找的信息是:
当然,最直接的方法是去自己的Docker hub上找到这个Image。
Serving
这个部分与普通的Kubetnetes服务发布差别不大。先定义一个服务:vim service.yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: docker.io/{username}/helloworld-go
env:
- name: TARGET
value: "Go Sample v1"
运行kubectl apply -f service.yaml。需要注意的是这里我们用了serving.knative.dev 的API。所以与其它部署有所不同:不需要deployment.yaml。这可理解为deployment被knative给包办了。如果运行kubectl get deployments,就可以看到helloworld-go-xxxx-deployment。
下一个问题就是,如何访问这个服务呢?这时候,Istio就出场了。平时我们要自己创建Ingress 或LB,现在knative通过 Istio帮我们做了。首先我们得到Ingress Gateway的IP地址:
kubectl get svc knative-ingressgateway -n istio-system
这里找到EXTERNAL-IP。然后我们找到Domain name:
kubectl get service.serving.knative.dev helloworld-go -o=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain
1
接着运行:
curl -H "Host: {DOMAIN}" http://{EXTERNAL-IP}
1
结果应该是:Hello World: Go Sample v1!
如果有一段时间没访问该服务,就会发现运行kubectl get pods 的时候,这几个helloworld-go pod不见了。那是knative把replica数降为0。
Eventing
对于FaaS的来说,Eventing就是触发这个function的机制。上面我们用curl去访问服务,其实是为了测试而已。在真实的部署过程中,这个function应该是有事件触发的。
Eventing是传统的FaaS的主要功能,也是除源代码外唯一与开发者真正相关的部分。正因为如此,其它FaaS,如Lambda, Openshift等,都可以通过这一层与Knative接口。
Knative设计的Eventing包括3个主要的概念:
Source: 就是事件发生的起源,可以理解为与其它系统的接口,目前支持的包括K8sevents,GitHub和GCP PubSub 。
Buses: 事件传输的途径,目前支持的有Stub,Kafka和GCP PubSub。
Flows: 定义对事件的反应。这可以是连锁的反应而不是单一的。
所以,我们要做的事就是,选一个Source,选一个Bus, 然后定义一个Flow,就可以啦。
本文中,我们选用K8events和Stub ClusterBus。先把它们装上:
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-clusterbus-stub.yaml
kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release-source-k8sevents.yaml
在生成flow之前,有一个小问题:K8 event是Kubernetes内部产生的,要接收的话,必须要通过一个Service Account 来授权。这是Kubernetes的要求,不是本文重点,如前面一样,保存后执行:
apiVersion: v1
kind: ServiceAccount
metadata:
name: feed-sa
namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: create-deployment
namespace: default
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
---
# This enables the feed-sa to deploy the receive adapter.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: feed-sa-deploy
namespace: default
subjects:
- kind: ServiceAccount
name: feed-sa
namespace: default
roleRef:
kind: Role
name: create-deployment
apiGroup: rbac.authorization.k8s.io
---
# This enables reading k8s events from all namespaces.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: feed-admin
subjects:
- kind: ServiceAccount
name: feed-sa
namespace: default
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io
接下来是主要的一步,创建flow:vim flow.yaml :
apiVersion: flows.knative.dev/v1alpha1
kind: Flow
metadata:
name: k8s-event-flow
namespace: default
spec:
serviceAccountName: feed-sa
trigger:
eventType: dev.knative.k8s.event
resource: k8sevents/dev.knative.k8s.event
service: k8sevents
parameters:
namespace: default
action:
target:
kind: Route
apiVersion: serving.knative.dev/v1alpha1
name: helloworld-go
接着运行kubectl apply -f flow.yaml就可以了。
我们来看一下是不是真的运行了呢?过一会儿运行:
kubectl get pods会看到k8s-event-flow-xxx的job运行完了。然后helloworld-go的pod都启动了。我们看一下日志: kubectl logs helloworld-go-xxxxx user-container,就会看到如下的结果:
Hello world received a request.
Hello world received a request.
Hello world received a request.
Hello world received a request.
...
这说明这条链路是起作用的。那么,这个flow的定义说了什么呢?首先是用了刚刚定义的service account。然后在trigger中定义什么样的event可以符合条件,这里我们说所有在 default namespace 的k8events 都符合。在action中我们定义有什么样的处理方式,本例中就直接调用了helloworld-go service。
结论
Knative是今年最新的云计算演进方向之一。阿里云支持Kubernetes,可以成功运行Knative和Istio等应用,大家也可以到阿里云上自己体验一番!
当然,作为一个新的备受瞩目的项目,Knative也会经历其成长的烦恼。我们会持续跟进,并提供和Knative相关、但不限于实践的分享,敬请期待。
---------------------