前一篇文章已经介绍了Build的使用方式和原理，本文将紧接上文介绍Serving。

简而言之，Serving 提供了Serverless应用或函数（Function）的部署能力，并通过 istio 实现服务管理，提供容器扩缩容能力。接管应用的部署和运维，节省开发者在应用部署和运维上消耗的精力。同时，在应用运维方面，Serving提供了根据应用访问量自动扩缩容的能力，在没有访问的时候能把应用实例缩减到0，本文通过将Serving部署到K8s平台之上试用，以讲解这一组件的原理。

Serving部署

安装istio

安装Serving之前，我们需要先安装istio，这里使用Knative提供的简易方式安装。

kubectl apply --filename https://raw.githubusercontent.com/knative/serving/release-0.6/third_party/istio-1.1.3/istio-crds.yaml \   
--filename https://raw.githubusercontent.com/knative/serving/release-0.6/third_party/istio-1.1.3/istio.yaml

安装Serving

Serving可以单独部署，但是也可以和Build一起部署，我们先来看Serving单独部署模式：

kubectl apply --selector   knative.dev/crd-install=true \   
--filename https://github.com/knative/serving/releases/download/v0.6.0/serving.yaml  --selector   networking.knative.dev/certificate-provider!=cert-manager

执行成功以后，可以通过以下命令查看：

kubectl get pods   --namespace knative-serving

当pod全部正常执行后，我们就可以开始使用Serving。

Serving概念和试用

概念

Knative把应用里的所有能力全都放到统一的CRD资源中管理—Service。这里的Service与K8s原生用户访问的Service不同，这是Knative的自定义资源，管理Knative应用的整个生命周期。

Service：service.serving.knative.dev资源管理着工作负载的整个生命周期。它控制其他对象（Route、Configration、Revison）的创建，并确保每次对Service的更新都作用到其他对象。
Route: route.serving.knative.dev资源将网络端点映射到一个或多个Revision。可以通过配置Route实现多种流量管理方式，包括部分流量和命名路由。
Configuration：configuration.serving.knative.dev资源保持部署所需的状态。它提供了代码和配置之间的清晰分离，并遵循十二要素应用程序方法。修改Configuration将创建新的Revision。
Revision：revision.serving.knative.dev资源是对工作负荷所做的每个修改的代码和配置的时间点快照。修订是不变的对象，只要有用就可以保留。Revision可以根据进入的流量自动扩缩容。

样例

现在让我们来看一个最简单的Knative Service样例：

apiVersion:   serving.knative.dev/v1alpha1   
kind: Service   
metadata:     
name: autoscale-go     
namespace: default   
spec:     
template:       
metadata:         
annotations:           
# Target 10 in-flight-requests per   pod.           
autoscaling.knative.dev/target:   "10"       
spec:         
containers:         
- image:   gcr.io/knative-samples/autoscale-go:0.1

可以发现，一个Service相当简洁，在最简单的模式下只需要填写一个镜像即可，其他都会默认填充。现在把这个样例创建到集群中，并查看它自动创建的资源。

kubectl apply --filename https://raw.githubusercontent.com/knative/docs/release-0.6/docs/serving/samples/autoscale-go/service.yaml   
kubectl get serving.knative.dev

创建Service之后，自动创建Configuration、Route、Revision、Deployment等资源。

自动扩缩容

接下来测试Service的自动扩缩容功能，在上文例子中，annotations里面设置了每个Pod的请求并发数为10。

INGRESSGATEWAY=istio-ingressgateway   
export IP_ADDRESS=`kubectl get svc   $INGRESSGATEWAY --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*].ip}"`      
hey -z 30s -c 50 \      
 -host "autoscale-go.default.example.com" \      
 "http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5"   \       
&& kubectl get pods   
Summary:       
Total:        30.3379 secs       
Slowest:      0.7433 secs       
Fastest:      0.1672 secs       
Average:      0.2778 secs       
Requests/sec: 178.7861          
Total data:   542038 bytes       
Size/request: 99 bytes      
Response time histogram:      
0.167 [1]     \|       
0.225 [1462]    \|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■       
0.282 [1303]  \|■■■■■■■■■■■■■■■■■■■■■■■■■■■■       0.340 [1894]    \|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■      
 0.398 [471]   \|■■■■■■■■■■       
0.455 [159]   \|■■■       
0.513 [68]    \|■      
0.570 [18]    \|       
0.628 [14]    \|       
0.686 [21]    \|       
0.743 [13]    \|      
Latency distribution:       
10% in 0.1805 secs       
25% in 0.2197 secs       
50% in 0.2801 secs       
75% in 0.3129 secs       
90% in 0.3596 secs       
95% in 0.4020 secs       
99% in 0.5457 secs      
Details (average, fastest, slowest):       
DNS+dialup:   0.0007 secs,   0.1672 secs, 0.7433 secs       
DNS-lookup:   0.0000 secs,   0.0000 secs, 0.0000 secs       
req write:    0.0001 secs,   0.0000 secs, 0.0045 secs       
resp wait:    0.2766 secs,   0.1669 secs, 0.6633 secs       
resp read:    0.0002 secs,   0.0000 secs, 0.0065 secs      
Status code distribution:       
[200] 5424 responses   NAME                                             READY   STATUS      
RESTARTS   AGE   
autoscale-go-00001-deployment-78cdc67bf4-2w4sk   3/3       Running   0          26s   
autoscale-go-00001-deployment-78cdc67bf4-dd2zb   3/3       Running   0          24s   
autoscale-go-00001-deployment-78cdc67bf4-pg55p   3/3       Running   0          18s   
autoscale-go-00001-deployment-78cdc67bf4-q8bf9   3/3       Running   0          1m   
autoscale-go-00001-deployment-78cdc67bf4-thjbq   3/3       Running   0          26s

以50qps去访问autoscale-go时，autoscale-go自动从1个实例扩展到5个实例，刚好和我们设置的并发匹配。

当我们等待一段时间不访问autoscale-go后再去获取实例数量，可以看到实例数被缩减到0。

kubectl get pods   
NAME                                          READY   STATUS    RESTARTS     AGE

多版本管理

这次，换个应用，我们先创建一个Service：

cat >   stock.yaml << EOF   
apiVersion: serving.knative.dev/v1alpha1   
kind: Service  
metadata:     
name: stock-service-example     
namespace: default   spec:     
template:       
metadata:         
name: stock-service-example-first       
spec:         
containers:         
- image: ${REPO}/rest-api-go          
env:             
- name: RESOURCE               
value: stock           
readinessProbe:             
httpGet:               
path: /             
initialDelaySeconds: 0             
periodSeconds: 3     
traffic:     
- tag: current       
revisionName: stock-service-example-first       
percent: 100     
- tag: latest       
latestRevision: true   	
percent: 0   
EOF   
kubectl create -f   stock.yaml

这个Service配置了流量信息，但是第一次创建时，我们先把所有的流量都导到Revision:stock-service-example-first上。

之后修改Service，另起创建新的Revision，并将一半流量切换到新的Revision。

cat >   stock.yaml << EOF   
apiVersion:   serving.knative.dev/v1alpha1   
kind: Service   
metadata:     
name: stock-service-example     
namespace: default   
spec:     
template:       
metadata:         
name: stock-service-example-second       
spec:         
containers:         
- image: ${REPO}/rest-api-go           
env:             
- name: RESOURCE               
value: share           
readinessProbe:             
httpGet:               
path: /             
initialDelaySeconds: 0             
periodSeconds: 3     
traffic:     
- tag: current       
revisionName: stock-service-example-first       
percent: 50     
- tag: candidate       
revisionName:   stock-service-example-second       
percent: 50     
- tag: latest       
latestRevision: true       
percent: 0   
EOF   
kubectl create -f   stock.yaml

接着，我们通过域名访问Service，多次的结果分别为Welcome to the share app! 或者 Welcome to the stock app!，比例大致为各一半。

 curl   --header "Host: stock-service-example.default.example.com"  
 http://${INGRESS_IP}

Serving原理

Serving总共有5个组件，其中4个在knative-serving这个namespace下面，是controller 、webhook 、autoscaler、activator这四个组件；还有一个queue, 运行在每个应用的pod里，作为pod的sidecar存在。

1. Controller负载Service整个生命周期的管理，涉及、Configuration、Route、Revision等的CURD。
2. Webhook主要负责创建和更新的参数校验。
3. Autoscaler根据应用的请求并发量对应用扩缩容。
4. Activator 在应用缩容到0后，拦截用户的请求，通知autoscaler启动相应应用实例，等待启动后将请求转发。
5. Queue负载拦截转发给Pod的请求，用于统计Pod的请求并发量等，autoscaler会访问queue获取相应数据对应用扩缩容。

自动扩缩容

1->n: 任何访问应用的请求在进入Pod后都会被Queue拦截，统计当前Pod的请求并发数，同时Queue会开放一个metric接口，autoscalor通过访问该端口去获取Pod的请求并发量并计算是否需要扩缩容。当需要扩缩容时，autoscalor会通过修改Revision下的deployment的实例个数达到扩缩容的效果。

0->1: 在应用长时间无请求访问时，实例会缩减到0。这个时候，访问应用的请求会被转发到activator，并在请求在转发到activator之前会被标记请求访问的Revision信息（由controller修改VirtualService实现）。activator接收到请求后，会将改Revision的并发量加1，并将metric推送给autoscalor，启动Pod。同时，activator监控Revision的启动状态，Revision正常启动后，将请求转发给相应的Pod。

当然，在Revision正常启动后，应用的请求将不会再发送到activator，而且直接发送至应用的Pod（由controller修改VirtualService实现）。

Knative网络模式

网络模式分两个部分，一个为Service之间的访问，一个为外部访问。

Service之间的访问：

istio会解析Knative Service的VirtualService下发给各个Pod的Envoy，当应用通过域名相互访问时，Envoy会拦截请求直接转发给相应的Pod。

外部访问：

如果是在集群外访问，素哟有的请求入口为ingressgateway，ingressgateway将请求根据访问域名转发到应用。
如果是在集群节点上访问，每个Knative Service都对应一个k8s Service, 这个Service的后端都为ingressgateway，ingressgateway会根据访问域名转发到应用。

总结

Knative的Serving在istio基础上，实现应用的简易部署和多版本管理，把开发人员从应用的部署和运维中真正的解放出来；同时动态扩缩容能力避免了资源冗余造成的浪费，有效节省应用成本。

相关文章：

《Knative 系列（一）：基本概念和原理解读》
《Knative 系列（二）：兵马未动粮草先行之 Build 篇》

创作场景

Knative 系列（三）：Serving 篇