在我们部署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 9090/TCP,8008/TCP,80/TCP,81/TCP 24h
autoscaler ClusterIP 10.100.73.90 9090/TCP,8008/TCP,8080/TCP,443/TCP 24h
controller ClusterIP 10.100.109.204 9090/TCP,8008/TCP 24h
webhook ClusterIP 10.100.101.64 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 18000/TCP 21h
kourier-internal ClusterIP 10.100.113.134 执行下面的命令，以查看部署的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
结论
当然还会有一些辅助组件和监控日志领域的组件，这些将在后续的系列中详细一一解读。