您好,登錄后才能下訂單哦!
怎么進行Knative實踐,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
在今年的Google Cloud Next大會上,Google發(fā)布了Knative, 這是由Google、Pivotal、Redhat和IBM等云廠商共同推出的Serverless開源工具組件,它與Istio,Kubernetes一起,形成了開源Serverless服務的三駕馬車。
本文來自阿里巴巴中間件事業(yè)部美國團隊高級技術專家 Andy在 Knative的實踐,Andy長期關注Service Mesh技術領域,在Cloud Foundry,Kubernetes,Envoy上等有著豐富的實踐和開發(fā)經(jīng)驗。加入Service Mesh開發(fā)者群,微信添加“zjjxg2018”,并備注公司-城市信息。
有意思的是:上述幾家公司是相互競爭的,但卻能把各自擅長的技術貢獻給同一個開源項目。另一個有意思的地方是對Serverless定義的轉變。以前說到Serverless,大家就等同于FaaS,就感覺只要把function代碼提交,然后定義event trigger就好了。現(xiàn)在Knative把Serverless這個概念轉變成了免運維:用戶還是要有server的,只是運維上比管理一個Kubernetes cluster更省心,而且不用的時候并不需要為server資源支付費用。除此之外,F(xiàn)aaS的應用場景很小,只有很小很快的函數(shù)才能比較容易部署。Knative以自助的方式實現(xiàn)部署,應用場景更廣,且一般的應用都可以部署成Serverless。
根據(jù)Knative提供的文檔介紹,一個完整的Serverless分為__Build__,__Serve__和__Eventing__三個部分。在本文中,我們將在阿里云上按照Knative github的安裝指南,逐步操作,以實現(xiàn)一個Knative應用。
準備
創(chuàng)建 Kubernetes cluster
在阿里云上創(chuàng)建一個Kubernetes cluster,用系統(tǒng)默認的設置就行,但要保證你有Admin權限。如果你用已有的 cluster,請確認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
1
安裝 Knative組件:
執(zhí)行下面的命令:
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
細心的同學會發(fā)現(xiàn)這里只安裝了兩部分: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項目中內(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。源代碼可以在遠程的服務器上,還要指定相應的Dockerfile。
但是,這樣做有個問題:Kaniko怎么訪問用戶的docker account呢?因此,我們需要創(chuàng)建一個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
保存后執(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 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 來執(zhí)行。
那么,如何知道遠程的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。要找的信息是:
當然,最直接的方法是去自己的Docker hub上找到這個Image。
Serving
這個部分與普通的Kubetnetes服務發(fā)布差別不大。先定義一個服務: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就出場了。平時我們要自己創(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
1
接著運行:
curl -H "Host: {DOMAIN}" http://{EXTERNAL-IP}
1
結果應該是:Hello World: Go Sample v1!
如果有一段時間沒訪問該服務,就會發(fā)現(xiàn)運行kubectl get pods 的時候,這幾個helloworld-go pod不見了。那是knative把replica數(shù)降為0。
Eventing
對于FaaS的來說,Eventing就是觸發(fā)這個function的機制。上面我們用curl去訪問服務,其實是為了測試而已。在真實的部署過程中,這個function應該是有事件觸發(fā)的。
Eventing是傳統(tǒng)的FaaS的主要功能,也是除源代碼外唯一與開發(fā)者真正相關的部分。正因為如此,其它FaaS,如Lambda, Openshift等,都可以通過這一層與Knative接口。
Knative設計的Eventing包括3個主要的概念:
Source: 就是事件發(fā)生的起源,可以理解為與其它系統(tǒng)的接口,目前支持的包括K8sevents,GitHub和GCP PubSub 。
Buses: 事件傳輸?shù)耐緩?,目前支持的有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內(nèi)部產(chǎn)生的,要接收的話,必須要通過一個Service Account 來授權。這是Kubernetes的要求,不是本文重點,如前面一樣,保存后執(zhí)行:
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
接下來是主要的一步,創(chuàng)建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中我們定義有什么樣的處理方式,本例中就直接調(diào)用了helloworld-go service。
結論
Knative是今年最新的云計算演進方向之一。阿里云支持Kubernetes,可以成功運行Knative和Istio等應用,大家也可以到阿里云上自己體驗一番!
當然,作為一個新的備受矚目的項目,Knative也會經(jīng)歷其成長的煩惱。我們會持續(xù)跟進,并提供和Knative相關、但不限于實踐的分享,敬請期待。
看完上述內(nèi)容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業(yè)資訊頻道,感謝您對億速云的支持。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。