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转发pod，而不再经过Activator

Queue Proxy

Knative Serving会为每个Pod注入一个称为Queue Proxy的容器

 - 为业务代码提供代理功能

    ingress gw热收到请求后，将期发往目标Pod实例上由Queue Proxy监听的8012端口，而后，Queue Proxy再将请求转发给业务代码容器监听的端口

 -  报告实例上的多个有关客户端请求的关键指标给KPA

 - Pod健康状态检测

  - 为超出实例最大并发量的请求提供缓冲队列

  Queue Proxy预留端口

    - 8012：HTTP协义的代理端口

    - 8013: HTTP/2端口，用于代理gRPC

     - 8022: 管理端口，如检健检测等 

     - 9090: 暴露给Autoscaler进行指标采集的端口

     - 9091:暴露给Prometheus进行监控指标采集的端口

运行Knative应用

在Serving上，可通过创建Knative serice对像来运行用，该service资源会自动创建。

一个Configuration对像，它会创建一个Revision，并由该Revision自动创建如下两个对像

   Configuration --> Revision  （ 如下由Revision创建）

       Deployment  

       PodAutoScaler（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