社区版部署环境准备
事先准备Kubernetes集群用于部署knative
选定isitio用来路由和治理流量
需要部署的Knative组件
Serving
Eventing（这里不做部署使用）
Kn（Knative CLI）
环境要求
单节点的Kubernetes集群，需要至少有6个CPU核心，6G内存和30G磁盘空间
多节点的Kubernetes集群，每个节点至少有2个CPU核心，4G内存和20G磁盘空间
安装步骤
– 部署Serving核心组件
– 部署网络层（Networking layer）组件Istio
Serving专用CRD
只列出常用的
Serving.knative.dev群组
– Service
– Configuation
– Revision
– Route
– DomainMapping
autoscaling.internal.knative.dev群组
– Metric
– PodAutoscaler
networking.internal.knative.dev群组
– ServerlessService
– ClusterDoaminClaim
– Certificate
Knative Serving工作模式
主要包含四个CRD
– Service
对自动编排Serverless类型应用的功能的抽像，负责自动管理工作负载的整个生命周期
– Configuation
反映了Service当前期望状态(Spen)的配置，Service对像的更新，也将导致Configuation的更新
– Revision
Service的每次代码或配置变理都会生成一个Revision
– Route
将请求流量路由到目标Revion
支持将流量按比例切分并路由到多个Revision
访问模式:
首先从ingress gateway转发代理流量至k8s service接着转发至Activator，Activator会告知KPA通知Deployment进行扩容>=1个。具体扩容数量需要根据请求量来决定。再次访问K8s service请求Activator已经完成扩容之后。下次再请求则会直接k8s service至queue proxy再转发至业务容器，而不再经过Activator
Queue Proxy
Knative Serving会为每个Pod注入一个称为Queue Proxy的容器
-为业务代码提供代理功能
ingressgw热收到请求后，将期发往目标Pod实例上由Queue Proxy监听的8012端口，而后，Queue Proxy再将请求转发给业务代码容器监听的端口
– 报告实例上的多个有关客户服务器托管网端请求的关键指标给KPA
– Pod健康状态检测
-为超出实例最大并发量的请求提供缓冲队列
Queue Proxy预留端口
– 8012：HTTP协义的代理端口
– 8013: HTTP/2端口，用于代理gRPC
– 8022:管理端口，如检健检测等
– 9090:暴露给Autoscaler进行指标采集的端口
– 9091:暴露给Prometheus进行监控指标采集的端口
运行Knative应用
在Serving上，可通过创建Knativeserice对像来运行用，该service资源会自动创建。
一个Configuration对像，它会创建一个Revision，并由该Revision自动创建如下两个对像
Configuration –> Revision （如下由Revision创建）
Deployment
PodAutoScal服务器托管网er（KPA）
一个Route 对像他它创建
– 1个Kubernetes Service 对像
– 1组VirtualService资源对象(istio network layer)
{serivce-name}-ingress： 访问该Knative Service的来自于集群外部流量
{service-name}-mesh: 访问该Knative Service的来自于集群内部流量
启用了网格功能时：VirtualService
未启用网格功能时：流量转给istio-system/knative-local-service
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
