Knative 系列（三）：Serving篇-InfoQ

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

Knative 系列（三）：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 系列（三）：Serving篇

样例

现在让我们来看一个最简单的 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 获取相应数据对应用扩缩容。

Knative 系列（三）：Serving篇

自动扩缩容

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 系列（三）：Serving 篇

Serving 部署

安装 istio

安装 Serving

Serving 概念和试用

概念

样例

Serving 原理

总结

评论

订阅

	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

	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

	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

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

	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

	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

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

Knative 系列（三）：Serving 篇

Serving 部署

安装 istio

安装 Serving

Serving 概念和试用

概念

样例

Serving 原理

总结

评论

推荐阅读

7 天热点

订阅