开发者学堂课程【如何通过 Knative 轻松实现应用 Serverless 化交付： Knative 冷启动（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/291/detail/3433
Knative 冷启动（二）
五、实例演示
下面打开相应的终端控制台，它就是一个很简单的 hello coffee。左侧使用的是 SK
connective
[root@iZbp1djyqnxhjfv9h9s0edZ serverless]# Ls
ksvc-coffee.yaml ksvc-java11.yaml
[root@iZbp1djyqnxhjfv9h9s@edZ serverless]# cat ksvc-coffee.yaml
apiVersion: serving.knative.dev/v1
kind:Service
metadata;
name：coffee
spec:
template:
metadata:
annotations:
autoscaling,knative.dev/target:"10"
spec;
containers;
image:registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
env:
name:TARGET
value;"coffee"
[root@iZbp1djyqnxhjfv9h9s0edZserverless]#
然后右侧使用的是社区的 connective
[rooteiZZzegdceffr1urv90tpu2Z demo]#ls coffee.yaml
[rooteiZ2zegdceffr1urv90tpu2Z demo]# cat coffee.yaml apiVersion:serving.knative.dev/v1 kind: Service metadata;
name: coffee spec:
template: metadata:
annotations:
autoscaling.knative.dev/target: "10' labels:
eci: "true" spec:
containers:
image:registry.cn-hangzhoualiyuncs.com/knative-sample/helloworld-go:160e4d
c8
env:
name; TARGET
value: "coffee"
[rooteiZZzegdceffrlurv90tpuZZ demo]#
二者的打印信息都是一样的。
最直观的是在 SK connective 的平台上，内容是不需要管控端相应的组件的，没有任何 pod。
而社区的 connective 是在相应的实名运营空间下，是需要相当提供这些管控组件的，这也是我们上面提到的在 SK connective 中对来自设备组件做了一个全托管免运维的优化。
接下来部署相应的服务。
在社区的 connective 部署相应的服务
[root@iZ2zegdceffr1urv90tpu2Z demo]# kubectl apply-f coffeeyaml service.serving.knative.dev/coffee created
[root@iZ2zegdceffrlurv90tpu2Z demo]# kubectl get pod
coffee-ktvk6-deployment-67c5966b7c-59xhs 0/2
Pending 6s
[root@iZZzegdceffr1urv90tpu2Z demo]# watch -n 1 "kubectl get pod
可以看到已经创建完成。
观察一下当前一个 pod 的情况，同时在 SK 平台当中创建相同的 Coffee，也可以观察一下当前 pod 的一个启动情况。
[root@iZbp1djyqnxhjfv9h9s0edZ serverless]# kubectl -n knative-serving get pod No resources found.
[root@iZbp1djyqnxhjfv9h9s0edZ serverless]# kubectl apply -f ksvc-coffeeyaml service.serving.knative.dev/coffee created
[root@iZbp1djyqnxhjfv9h9s0edZ serverless]# watch -n 1 "kubectl get pod"
SK connective 在创建中，然后在社区的 connective 已经创建完成了。
接下来要观察一个现象，就是在没有请求的过程中，然后社区的 connective 会缩容到0，然后在 SK 中提供的 connective 是缩容到的一个保留实例。正常一个周期的缩容是90秒，社区的 connective，已经缩容到0。
SK 的 connective,在这个过程中重新访问请求，再打开一个窗口。
Last login: Tue Aug 11 19:50:58 on ttys004 richard@B-N3TEMD6P-1650 ~%cat ssh120.55.51.3047.94.141.240
8.211.36.198
richard@B-N3TEMD6P-1650~%sshroot@47.94.141240 root@47.94.141.240's password:
Last login: Tue Aug 11 19:51:54 2020 from 42.120.72.81
Welcame to Alibaba Cloud Elastic Campute Service!
[root@iZ2zegdceffr1urv90tpu2Z ~]#
创建保留实例，一旦ready，就会把正常的实例下线掉。在没有请求的时候， connective 已经缩容到0。
再打开社区的 connective。
Last login: Tue Aug 11 20:17:22 on ttys005
richard@B-N3TEMD6P-1650~%ssh
root@120.55.51.30 raot@120.55.51.30's password:
Last login: Tue Aug 11 19:51:05 2020 from 42120.72.81
Welcome to Alibaba Cloud Elastic Compute Service !
[root@iZbp1djyqnxhjfv9h9s0edZ ~]#
此时可以很明显对比出来，社区的 connective 一旦接受请求就会启动pod，大概30秒。在 SK 的 connective 几乎是实时响应。并且在响应过程中一旦接受请求，就会扩容一个正常实例。
一旦正常实例 ready 后，就会平滑的把相应的保留实力下线掉。通过这个对比可以看到，如何在 SK 的 connective 通过保留实例解决冷启动问题，对于服务敏感形的，可以保证实时响应。
六、总结
Knative 冷启动问题包括：当前社区 Knative 从口到1冷启动的问题以及保留实例平衡成本和冷启动。
