在我们部署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
结论
当然还会有一些辅助组件和监控日志领域的组件,这些将在后续的系列中详细一一解读。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。