跟我一块儿学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

结论

固然还会有一些辅助组件和监控日志领域的组件，这些将在后续的系列中详细一一解读。