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

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

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

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

準(zhǔn)備

創(chuàng)建 Kubernetes cluster

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

安裝 Knative

這個過程分為兩步：

安裝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`

這個安裝需要一點時間，但是是必須的。因為Knative依賴Istio來聯(lián)接Serverless，而不是直接通過Kubernetes。等到所有的安裝完成后，我們要開啟Istio 自動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 安裝后等待一會并確認(rèn)： kubectl get pods -n knative-serving -w kubectl get pods -n knative-build -w

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

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

同樣的，運行這個命令來確認(rèn)：

kubectl get pods -n knative-eventing -w

Build

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

在實現(xiàn)上，Build是一個Kubernetes Custom Resource Definition (CRD)。如同其它的Kubernetes CRD，定義的方式是通過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。

但是，這樣做有個問題：Kaniko怎么訪問用戶的docker account呢？因此，我們需要創(chuàng)建一個secret，把用戶的docker username和password存在里面。然后，還需要一個service account來綁定這個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換成你自己的帳號信息，然后保存。
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 來訪問secret。用這個之前把里面的destination換成你自己的docker id，保存后用kubectl apply -f build.yaml?來執(zhí)行。

那么，如何知道遠(yuǎn)程的Kaniko到底做好了沒有呢？Kubernetes 會為kind: Build??創(chuàng)建一個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。要找的信息是：

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

Serving

這個部分與普通的Kubetnetes服務(wù)發(fā)布差別不大。先定義一個服務(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"

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

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

接著運行：

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

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

Eventing

對于FaaS的來說，Eventing就是觸發(fā)這個function的機制。上面我們用curl去訪問服務(wù)，其實是為了測試而已。在真實的部署過程中，這個function應(yīng)該是有事件觸發(fā)的。

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

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

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

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

Flows: 定義對事件的反應(yīng)。這可以是連鎖的反應(yīng)而不是單一的。
所以，我們要做的事就是，選一個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內(nèi)部產(chǎn)生的，要接收的話，必須要通過一個Service Account 來授權(quán)。這是Kubernetes的要求，不是本文重點，如前面一樣，保存后執(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

接下來是主要的一步，創(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

接著運行kubectl apply -f flow.yaml就可以了。

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

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中我們定義有什么樣的處理方式，本例中就直接調(diào)用了helloworld-go service。

結(jié)論

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

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

?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的在阿里云上试用 Knative的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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