容器运行时技术内幕 (小结)
先放过往链接：
容器运行时硬核技术内幕 (2) 震惊，美女程序员竟为蔡徐坤做出这件事
到今天为止，我们对Kubernetes的容器运行时技术进行了较为深入的剖析。
我们知道，虚拟机交付的是操作系统及部分运行时依赖库的一个实例，而容器技术，能够对外交付应用的一个实例，多个docker container可以共用一个操作系统和运行时依赖库。
而Kubernetes交付的则是一个应用本身。应用由多个组件组成，每个组件又可能由多个实例进行负载分担。一般地，每个实例是一个pod，而pod内有一个或多个container。container由容器运行时引擎创建和维护。
最常见的容器运行时引擎，就是大名鼎鼎的docker。一开始，Kubernetes直接在代码中调用了docker的API与docker对接。当然，随着CoreOS rkt等其他容器运行时引擎的流行，这种紧耦合方式也被改为另一种松耦合方式，这就是cri接口。
cri接口是基于grpc的。由于grpc没有使用HTTP协议，而是使用了高效率的http/2，序列化和反序列化的开销大大低于RESTAPI，因此，它的效率非常高，适合大规模弹性伸缩的场景。
当然，Kubernetes执行弹性伸缩的依据，是容器资源的消耗量以及容器的可用性。Kubernetes可以通过ExecAction, TCPSocketAction和HttpGetAction这三种方法监控容器运行状态，也可以通过Prometheus等中间件来监控容器的资源使用量和响应性能。基于这些数据，Kubernetes就可以执行容器的弹性伸缩了。
实际上，Kubernetes具备的这些特性，离交付应用本身，还有一些差距。
让我们举一个例子。
小B同学作为江疏影的粉头，下载了一大堆江疏影的照片和视频，供夜深人静时欣赏，并试图利用基于GAN的AI图形处理框架去掉马赛克或图片水印。但由于容器化部署的应用没有持久化存储，导致容器被销毁后，江疏影依然是有码的。
怎么样解决这个问题呢？
请看下一个专题——云存储硬核技术内幕。