ggaaooppeenngg

为什么计算机科学是无限的但生命是有限的

Knative 架构分析

Knative主要有两个重要的部分,一个是自动扩展一个是流量切换,并且目前的设计已经和istio是相对独立的了。

Knative的service和k8s的service容易混淆,所以用sks指代knative的service,然后service本身是指k8s本身的service。

sks的revision创建的时候会有两个service,一个是 public service,一个是 private service,如果用istio的话会看到一个和ingressgateway关联的有externalname的service,这个service是和ingress实现相关的。主要的实现还是public和private两个service,实现和具体的ingress的实现是独立的。

Private service 对应的是真实的pod的endpoints,public service 有两种模式一个serve模式,一个是proxy模式。当public service出于proxy模式时,其endpoints指向的是activator,当处于serve模式时endpoints指向的是private service所指向的后端endpoints。

在scale从0到1的过程中,会先阻塞在activator上,当有pod启动以后,还是会保持proxy模式,直到超过burst才会切换到private service的endpoints上。在从1到0的过程中会再切换回activator,直到有新的请求到来再触发pod的启动。

activator

Throttler

Throttler is the interface that Handler calls to Try to proxy the user request

Health Handler 注册用于 kubelet 做 readiness 和 health probe 的接口,返回statSink的状态,收到 signal term 的时候就开始返回500。

Network probe handler
knative组件用来 probe 的接口,在header里面会有区分。

Context handler
把header中的revision的name和namespace注入的context当中

Metric Handler
收集request的qps等metrics的信息。

Log Handler
请求日志

Tracing Handler
Trace spans

Cocurrency report Handler

记录请求信息,这些信息会被reporter上报

Activator handler

过一层 throttler 进行proxy,如果没受限制就会proxy request。

Throttler 会根据revID创建一个throttler,revision如果存在的话就会创建throttler。(revision肯定是一直在的哪怕没有起pod)如果超过revision的并发数就会退出。

Throttler 会try对应的revisionThrottler的pods然后转发过去。

controller

Controller 主要是对用户使用的几个CRD的同步:Service、Route、Revision、Configuration。

net-istio

Ingress 的一种实现

internal 的 ingress创建一个 ingress virtualservice 并且将gate指定为isito-gateway,其他的ingress实现其实类似,只是目前没有traefik的支持。knative有没有istio现在是没啥区别了。

domain mappings

一个用于扩展域名的CRD DomainClaim,会根据domainclaim创建一个ingress。

queue-proxy

tracing metrics breaker 都是正常操作。本质是个sidecar层面的反向代理。

Metrcis

Admin

有一个给cocurrency endpoint发 paused 和 resumed 的回调。

Main

Proxy handler 收集 request in 和 request out。

自定义默认域名的问题

kubectl get cm config-network -n knative-serving -o yaml 可以看到默认的模板去修改他

1
domain-template: "{{.Name}}.{{.Namespace}}.{{.Domain}}"