跟我一塊兒學Knative(3)--Knative Seving部署模型

在咱們部署Knative Serving service 以前，重要的是要了解其部署模型和構成Knative服務的Kubernetes資源。

上一節咱們安裝部署了Knative Serving。文本主要介紹當咱們安裝了Knative Serving以後，安裝了那些Kubernetes 服務。總共包含了兩個方面。serving-core 和網絡層。下面咱們分別查看一下。

serving-core

執行下面的命令，以查看部署了那些k8s service：

kubectl get services -n knative-serving

能夠看到以下的輸出：

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                              AGE
activator-service   ClusterIP   10.100.157.161   <none>        9090/TCP,8008/TCP,80/TCP,81/TCP      24h
autoscaler          ClusterIP   10.100.73.90     <none>        9090/TCP,8008/TCP,8080/TCP,443/TCP   24h
controller          ClusterIP   10.100.109.204   <none>        9090/TCP,8008/TCP                    24h
webhook             ClusterIP   10.100.101.64    <none>        9090/TCP,8008/TCP,443/TCP            24h

執行下面的命令，以查看部署了那些Deployments：

kubectl get deployments -n knative-serving

能夠看到以下輸出：

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
activator    1/1     1            1           24h
autoscaler   1/1     1            1           24h
controller   1/1     1            1           24h
webhook      1/1     1            1           24h

服務

activator

激活器負責接收和緩衝非活動修訂的請求，並向autoscaler報告指標。在autoscaler根據報告的指標縮放修訂版本後，它還會重試對修訂的請求。

autoscaler

自動縮放器接收請求指標並調整處理流量負載所需的Pod數量。關於此處咱們會在下一章詳細講解。

controller

控制器服務協調全部公共Knative對象和自動縮放CRD。當用戶向Kubernetes API應用Knative服務時，這將建立配置和路由。它將配置轉換爲修訂版，並將修訂版本轉換爲部署和Knative Pod自動縮放器（KPA）。

webhook

Webhook攔截全部Kubernetes API調用以及全部CRD插入和更新。它設置默認值，拒毫不一致和無效的對象，並驗證和更改Kubernetes API調用。

網絡層

咱們網絡層選擇的是kourier。

執行下面的命令，以查看安裝的service：

kubectl get services -n kourier-system

能夠看到以下的輸出：

NAME               TYPE           CLUSTER-IP       EXTERNAL-IP                                                                          PORT(S)                      AGE
kourier            LoadBalancer   10.100.47.159    a2f4c64ef34ea408933e1137ef-424fef949c9c7ad3.elb.ap-southeast-1.amazonaws.com   80:32327/TCP,443:31313/TCP   21h
kourier-control    ClusterIP      10.100.163.167   <none>                                                                               18000/TCP                    21h
kourier-internal   ClusterIP      10.100.113.134   <none>

執行下面的命令，以查看部署的deployments：

kubectl get deployments -n kourier-system

能夠看到以下的輸出：

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
3scale-kourier-control   1/1     1            1           21h
3scale-kourier-gateway   1/1     1            1           21h

組件

kourier本質上是一個基於envoy的ingress gateway。負責南北向流量分發和治理。

3scale-kourier-control

envoy的控制層，本質上也是一個controller，能夠監聽knative serving 建立的關於ingress資源對象，並轉換爲envoy的配置文件，經過xds方式，下發給envoy。

3scale-kourier-gateway

envoy代理，即數據層。負責真實流量的轉發和治理。

深刻理解Serving 部署模型

以下圖所示，在部署Knative Serving Service（ksvc）的過程當中，Knative Serving控制器會建立配置，修訂版和路由。

與任何Kubernetes資源YAML中同樣，apiVersion定義了Knative Service的API組。這些API資源可經過在前面文章部署的Kubernetes CRD得到。此類是與Knative服務相對應的Kubernetes資源。爲了不與Kubernetes內置服務產生混淆，Knative服務與其apiVersion和種類（即service.serving.knative.dev）相關聯。

資源YAML的spec塊與Kubernetes PodSpec徹底相同，但刪除了如下屬性：

• InitContainers
• RestartPolicy
• TerminationGracePeriodSeconds • ActiveDeadlineSeconds
• DNSPolicy
• NodeSelector
• AutomountServiceAccountToken • NodeName
• HostNetwork
• HostPID
• HostIPC
• ShareProcessNamespace
• SecurityContext
• Hostname
• Subdomain
• Affinity
• SchedulerName
• Tolerations
• HostAliases
• PriorityClassName
• Priority
• DNSConfig
• ReadinessGates
• RuntimeClassName

結論

固然還會有一些輔助組件和監控日誌領域的組件，這些將在後續的系列中詳細一一解讀。