Knatives實戰之Knative-Serving

Knative是google主導的一個opensource項目，主要面向的領域是serverless。今年的google大會基於Knative，google發佈了google could run，這也令knative變得炙手可熱了。

最近玩了玩，總結下，以供後查。

項目地址：https://github.com/knative

可以看到Knative分了六個子項目，不少了，我們逐一認識：

Docs: 就是docs，沒什麼好說的，初學者必刷。

Serving是本篇的主要內容了。

這個項目主要是關於部署的,支持了serverless的一些理念: 如replicate爲0。

另外還有流量控制方面的,如藍綠測試 另外還實現了版本的管理和快照, 還有路由等等, 內容還是非常充實的。

我們看看設計,

在Knative serving中，引入了一個新的CRD: Service (注意區別於k8s Service), 後文稱該CRD爲KService。

Kservice被創建後，會生成若干新的CRD， 如Configuration, Route, Revision, 當然還有若干k8s的resource，如Service， pod等等，我們接下來詳細講講。

先用一張管網圖鎮樓：

• Kservice: 包含了所有的信息, 在一個Kservice建立以後它要負責建立Route, Configuration和至少一個Revision
• Route: 是這個Kservice小系統的入口, 會生成一個Hostname: 像這樣：helloworld-go.servingk.example.com 並註冊到Istio中, Istio負責將對改hostname的請求抓發到Route。Route接收到外部流量後根據Route的路由配置把流量導入到相應的Revision.
• Revision: 就是字面意思, 版本,每一次對Kserevice的改動都會生成一個新的版本.
• Configuration: 負責記錄版本的歷史信息，並且所有的配置信息。

他們一起提供了serverless的功能，拿一個case舉例：

先定義一個Kservice:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld-go
  namespace: servingk
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: vincentpli/knative-serving-helloworld:latest
            env:
            - name: TARGET
              value: "Go Sample v1"

注意，這裏面有很多信息:

1. runLatest: 這個意思是說Route總是會把外部請求導向最新的Revision
2. revisionTemplate: 這個部分是定義了Revision, 你可以看到有image, env等等,這個image會在收到http請求後打出”Hello Go Sample v1”的字樣.

這是部署以後的情形，這麼多CRD, 當然還會有k8s內置的如service等等，對了我們看看pod：

沒有，是啊，沒請求就不會起pod，就是replicate爲0，這也是Knative serving的關鍵特性.

我們試着發個request:

因爲我的Istio在31380端口,注意Hostname

在看看pod:

有了哈!

還記的之前提起的, runLatest會自動把請求導向最新的一個Revision,我們繼續試驗: 修改之前的Kservice, 注意看最後部分：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld-go
  namespace: servingk
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: vincentpli/knative-serving-helloworld:latest
            env:
            - name: TARGET
              value: "Go Sample v2"

部署之。兩個Revision

發個請求試試:

變了哈, 確實把所有的請求都路由到了最新的Revision, 我們在Route的配置中找找端倪

這是在Route中找到的, 嗯, 好像有點奇怪。請求100%被導入到Configuration: hellowold-go中了， 看看該Configuration:

雖然有點怪，但是是對的。

但是如果我們想要控制請求的去向呢，如Revision #1 50%, Revision #2 50%要怎麼實現呢，我們試試啊。

之前說到runLatest是把所有的請求導向最新的Revision, 如果要分流量，我們要用到：release

看看新改的kservice：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld-go
  namespace: servingk
spec:
  release:
    revisions: ["helloworld-go-6gznq", "helloworld-go-z6z8d" ]
    rolloutPercent: 50
    configuration:
      revisionTemplate:
        spec:
          container:
            image: vincentpli/knative-serving-helloworld:latest
            env:
            - name: TARGET
              value: "Go Sample v2"

部署之： 記得，這次用 kubectl replace不能用kubectl apply

基本上是50:50

去Route找找端倪吧:

符合我們的猜想。

 

Knative serving基本就是這樣，當然不限於這樣。