在阿里雲上試用 Knative

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

本文來自阿里巴巴中間件事業部美國團隊高級技術專家 Andy在 Knative的實踐，Andy長期關注Service Mesh技術領域，在Cloud Foundry，Kubernetes，Envoy上等有着豐富的實踐和開發經驗。加入雲原生開發者羣，微信添加“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

這個過程分爲兩步：

1. 安裝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

2. 安裝 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

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

接着運行：

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

結果應該是：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個主要的概念：

1. Source: 就是事件發生的起源，可以理解爲與其它系統的接口，目前支持的包括K8sevents，GitHub和GCP PubSub 。
2. Buses: 事件傳輸的途徑，目前支持的有Stub，Kafka和GCP PubSub。
3. 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相關、但不限於實踐的分享，敬請期待。

加入雲原生開發者羣，微信添加“zjjxg2018”，並備註公司-城市信息。