在今年的Google Cloud Next大會(huì)上，Google發(fā)布了Knative, 這是由Google、Pivotal、Redhat和IBM等云廠商共同推出的Serverless開(kāi)源工具組件，它與Istio，Kubernetes一起，形成了開(kāi)源Serverless服務(wù)的三駕馬車。

本文來(lái)自阿里巴巴中間件事業(yè)部美國(guó)團(tuán)隊(duì)高級(jí)技術(shù)專家 Andy在 Knative的實(shí)踐，Andy長(zhǎng)期關(guān)注Service Mesh技術(shù)領(lǐng)域，在Cloud Foundry，Kubernetes，Envoy上等有著豐富的實(shí)踐和開(kāi)發(fā)經(jīng)驗(yàn)。加入Service Mesh開(kāi)發(fā)者群，微信添加“zjjxg2018”，并備注公司-城市信息。

有意思的是：上述幾家公司是相互競(jìng)爭(zhēng)的，但卻能把各自擅長(zhǎng)的技術(shù)貢獻(xiàn)給同一個(gè)開(kāi)源項(xiàng)目。另一個(gè)有意思的地方是對(duì)Serverless定義的轉(zhuǎn)變。以前說(shuō)到Serverless，大家就等同于FaaS，就感覺(jué)只要把function代碼提交，然后定義event trigger就好了。現(xiàn)在Knative把Serverless這個(gè)概念轉(zhuǎn)變成了免運(yùn)維：用戶還是要有server的，只是運(yùn)維上比管理一個(gè)Kubernetes cluster更省心，而且不用的時(shí)候并不需要為server資源支付費(fèi)用。除此之外，FaaS的應(yīng)用場(chǎng)景很小，只有很小很快的函數(shù)才能比較容易部署。Knative以自助的方式實(shí)現(xiàn)部署，應(yīng)用場(chǎng)景更廣，且一般的應(yīng)用都可以部署成Serverless。

根據(jù)Knative提供的文檔介紹，一個(gè)完整的Serverless分為_(kāi)_Build__，__Serve__和__Eventing__三個(gè)部分。在本文中，我們將在阿里云上按照Knative github的安裝指南，逐步操作，以實(shí)現(xiàn)一個(gè)Knative應(yīng)用。

準(zhǔn)備

創(chuàng)建 Kubernetes cluster

在阿里云上創(chuàng)建一個(gè)Kubernetes cluster，用系統(tǒng)默認(rèn)的設(shè)置就行，但要保證你有Admin權(quán)限。如果你用已有的 cluster，請(qǐng)確認(rèn)Kubernetes的版本是1.10以上。

安裝 Knative

這個(gè)過(guò)程分為兩步：

安裝Istio:
Knative的Istio有一些自己定義的資源，所以不要用Istio網(wǎng)站的缺省安裝。但是Knative現(xiàn)有指南未更新，還是0.8,有些舊。我所用的是1.0:

curl https://raw.githubusercontent.com/knative/serving/master/third_party/istio-1.0.0/istio.yaml

這個(gè)安裝需要一點(diǎn)時(shí)間，但是是必須的。因?yàn)镵native依賴Istio來(lái)聯(lián)接Serverless，而不是直接通過(guò)Kubernetes。等到所有的安裝完成后，我們要開(kāi)啟Istio 自動(dòng)injection：

kubectl label namespace default istio-injection=enabled

安裝 Knative組件：
執(zhí)行下面的命令：

kubectl apply -f https://github.com/knative/serving/releases/download/v0.1.1/release.yaml 安裝后等待一會(huì)并確認(rèn)： kubectl get pods -n knative-serving -w kubectl get pods -n knative-build -w

細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)這里只安裝了兩部分：Build 和 Serving，那么Eventing呢？是需要單獨(dú)安裝的。

kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release.yaml

同樣的，運(yùn)行這個(gè)命令來(lái)確認(rèn)：

kubectl get pods -n knative-eventing -w

Build

Build是目前Knative項(xiàng)目中內(nèi)容最豐富的部分。因?yàn)镻ivotal拿出了壓箱寶build packs加入Knative。而Google之前多年做app engine，也在這方面累計(jì)了很多經(jīng)驗(yàn)。

在實(shí)現(xiàn)上，Build是一個(gè)Kubernetes Custom Resource Definition (CRD)。如同其它的Kubernetes CRD，定義的方式是通過(guò)YAML，調(diào)用的方式是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。源代碼可以在遠(yuǎn)程的服務(wù)器上，還要指定相應(yīng)的Dockerfile。

但是，這樣做有個(gè)問(wèn)題：Kaniko怎么訪問(wèn)用戶的docker account呢？因此，我們需要?jiǎng)?chuàng)建一個(gè)secret，把用戶的docker username和password存在里面。然后，還需要一個(gè)service account來(lái)綁定這個(gè)secret。
vim secret.yaml

apiVersion: v1 kind: Secret metadata:name: docker-user-passannotations: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換成你自己的帳號(hào)信息，然后保存。
kubectl apply -f secret.yaml
vim service-account.yaml

apiVersion: v1 kind: ServiceAccount metadata:name: build-bot secrets:- name: docker-user-pass

保存后執(zhí)行：
kubectl apply -f service-account.yaml

然后我們創(chuàng)建Kubernetes manifest vim build.yaml：

apiVersion: build.knative.dev/v1alpha1 kind: Build metadata:name: docker-build spec:serviceAccountName: build-bot #service account created abovesource:git:revision: masterurl: "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 來(lái)訪問(wèn)secret。用這個(gè)之前把里面的destination換成你自己的docker id，保存后用kubectl apply -f build.yaml 來(lái)執(zhí)行。

那么，如何知道遠(yuǎn)程的Kaniko到底做好了沒(méi)有呢？Kubernetes 會(huì)為kind: Build 創(chuàng)建一個(gè)job。用kubectl get pods 找到一個(gè) docker-build-xxxx 的pod。然后運(yùn)行：kubectl -n default logs docker-build-xxxx -c build-step-build-and-push 來(lái)觀察build的情況。

我們也可以直接查看Kubetnetes build objects: kubectl describe builds。要找的信息是：

當(dāng)然，最直接的方法是去自己的Docker hub上找到這個(gè)Image。

Serving

這個(gè)部分與普通的Kubetnetes服務(wù)發(fā)布差別不大。先定義一個(gè)服務(wù)：vim service.yaml

apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata:name: helloworld-gonamespace: default spec:runLatest:configuration:revisionTemplate:spec:container:image: docker.io/{username}/helloworld-goenv:- name: TARGETvalue: "Go Sample v1"

運(yùn)行kubectl apply -f service.yaml。需要注意的是這里我們用了serving.knative.dev 的API。所以與其它部署有所不同：不需要deployment.yaml。這可理解為deployment被knative給包辦了。如果運(yùn)行kubectl get deployments,就可以看到helloworld-go-xxxx-deployment。

下一個(gè)問(wèn)題就是，如何訪問(wèn)這個(gè)服務(wù)呢？這時(shí)候，Istio就出場(chǎng)了。平時(shí)我們要自己創(chuàng)建Ingress 或LB，現(xiàn)在knative通過(guò) 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

接著運(yùn)行：

curl -H "Host: {DOMAIN}" http://{EXTERNAL-IP}

結(jié)果應(yīng)該是：Hello World: Go Sample v1!
如果有一段時(shí)間沒(méi)訪問(wèn)該服務(wù)，就會(huì)發(fā)現(xiàn)運(yùn)行kubectl get pods 的時(shí)候，這幾個(gè)helloworld-go pod不見(jiàn)了。那是knative把replica數(shù)降為0。

Eventing

對(duì)于FaaS的來(lái)說(shuō)，Eventing就是觸發(fā)這個(gè)function的機(jī)制。上面我們用curl去訪問(wèn)服務(wù)，其實(shí)是為了測(cè)試而已。在真實(shí)的部署過(guò)程中，這個(gè)function應(yīng)該是有事件觸發(fā)的。

Eventing是傳統(tǒng)的FaaS的主要功能，也是除源代碼外唯一與開(kāi)發(fā)者真正相關(guān)的部分。正因?yàn)槿绱?#xff0c;其它FaaS，如Lambda, Openshift等，都可以通過(guò)這一層與Knative接口。

Knative設(shè)計(jì)的Eventing包括3個(gè)主要的概念：

Source: 就是事件發(fā)生的起源，可以理解為與其它系統(tǒng)的接口，目前支持的包括K8sevents，GitHub和GCP PubSub 。

Buses: 事件傳輸?shù)耐緩?#xff0c;目前支持的有Stub，Kafka和GCP PubSub。

Flows: 定義對(duì)事件的反應(yīng)。這可以是連鎖的反應(yīng)而不是單一的。
所以，我們要做的事就是，選一個(gè)Source，選一個(gè)Bus， 然后定義一個(gè)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之前，有一個(gè)小問(wèn)題：K8 event是Kubernetes內(nèi)部產(chǎn)生的，要接收的話，必須要通過(guò)一個(gè)Service Account 來(lái)授權(quán)。這是Kubernetes的要求，不是本文重點(diǎn)，如前面一樣，保存后執(zhí)行：

apiVersion: v1 kind: ServiceAccount metadata:name: feed-sanamespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:name: create-deploymentnamespace: 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-deploynamespace: default subjects:- kind: ServiceAccountname: feed-sanamespace: default roleRef:kind: Rolename: create-deploymentapiGroup: 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: ServiceAccountname: feed-sanamespace: default roleRef:kind: ClusterRolename: viewapiGroup: rbac.authorization.k8s.io

接下來(lái)是主要的一步，創(chuàng)建flow：vim flow.yaml :

apiVersion: flows.knative.dev/v1alpha1 kind: Flow metadata:name: k8s-event-flownamespace: default spec:serviceAccountName: feed-satrigger:eventType: dev.knative.k8s.eventresource: k8sevents/dev.knative.k8s.eventservice: k8seventsparameters:namespace: defaultaction:target:kind: RouteapiVersion: serving.knative.dev/v1alpha1name: helloworld-go

接著運(yùn)行kubectl apply -f flow.yaml就可以了。

我們來(lái)看一下是不是真的運(yùn)行了呢？過(guò)一會(huì)兒運(yùn)行：
kubectl get pods會(huì)看到k8s-event-flow-xxx的job運(yùn)行完了。然后helloworld-go的pod都啟動(dòng)了。我們看一下日志： kubectl logs helloworld-go-xxxxx user-container，就會(huì)看到如下的結(jié)果：

Hello world received a request. Hello world received a request. Hello world received a request. Hello world received a request. ...

這說(shuō)明這條鏈路是起作用的。那么，這個(gè)flow的定義說(shuō)了什么呢？首先是用了剛剛定義的service account。然后在trigger中定義什么樣的event可以符合條件，這里我們說(shuō)所有在 default namespace 的k8events 都符合。在action中我們定義有什么樣的處理方式，本例中就直接調(diào)用了helloworld-go service。

結(jié)論

Knative是今年最新的云計(jì)算演進(jìn)方向之一。阿里云支持Kubernetes，可以成功運(yùn)行Knative和Istio等應(yīng)用，大家也可以到阿里云上自己體驗(yàn)一番！

當(dāng)然，作為一個(gè)新的備受矚目的項(xiàng)目，Knative也會(huì)經(jīng)歷其成長(zhǎng)的煩惱。我們會(huì)持續(xù)跟進(jìn)，并提供和Knative相關(guān)、但不限于實(shí)踐的分享，敬請(qǐng)期待。

加入Service Mesh開(kāi)發(fā)者群，微信添加“zjjxg2018”，并備注公司-城市信息。

總結(jié)

以上是生活随笔為你收集整理的Knative实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。