近期的热点之一是美国大选。由于美国大选没有部署基于容器的高性能应用平台，用于快速精确统计选票，而是采用传统的选举人票制度，导致红蓝双方争论不休，互相指责部分摇摆州的统计数据造假，导致整个国家出现了混乱。
因此，为了避免这种情况的发生，我们就更应当透彻理解Kubernetes的工作机制了。
让我们梳理一下前几期提到的问题：
一、docker为代表的容器运行时引擎，对外交付的实际上是应用程序所需要的组件的一个实例，而kubernetes这样的容器编排平台才能交付应用程序本身；
二、正如应用程序是由各个组件的每个实例组成的那样，kubernetes本身也并不提供容器运行时功能，最终依然需要调用容器运行时平台执行容器的创建和停止等功能；
三、最初的Kubernetes直接在实现代码中调用了docker提供的接口，为了与docker解耦，在1.5版本以后使用了cri接口，可以兼容其他的容器运行时引擎；
四、cri接口实际上是在容器运行时引擎上运行grpc服务器端，在kubernetes上运行grpc客户端实现的，每次启动和停止容器均会使用grpc调用的方法；
我们也提到了一个重要的概念——Pod。Pod实际上是Kubernetes调度的基本单位，由pause容器作为根，在pause容器中启动其他所有容器，如服务主容器main container和边车容器sidecar container。
如果我们开发一个在线投票的应用，前端使用apache httpd，为了保证k8s需要在httpd容器忙不过来的时候，自动弹性扩容，如下图所示：
同时，由于方老师的学生们学艺不精，开发Web应用的时候留下了一些Bug，导致Web应用会逐渐变得不可用。Kubernetes需要感知到Pod的这种异常状态，并且重启Pod。
这两个问题应该怎么解决呢？
先解决比较简单的第二个问题。
Kubernetes支持对容器存活性的探测，目前有三种机制：ExecAction, TCPSocketAction和HttpGetAction。
ExecAction机制是通过在pod内的容器上运行命令，探测存活性的机制；
TCPSocketAction是通过对容器上指定的端口发起连接，探测存活性的机制；
而HttpGetAction则是通过从容器的Http服务端拉取特定的URL，探测存活性的机制；
显然，这三种存活性机制的开销从小到大，而准确性却反之。
Kubernetes除了支持存活性探测外，还支持就绪性探测。就绪性探测也可以利用ExecAction, TCPSocketAction和HttpGetAction这三种机制。
划重点：如果一个Pod对象，没有定义就绪性探测，会在进入running状态后立即被设定为就绪状态。但由于Pod中的服务还需要时间启动，并不能立即正确响应客户端需求，Service机制会错误地将请求转发到这种尚未真正Ready的Pod。因此，我们在配置Pod时还是应该为它设定就绪性探测机制。
第一个问题相对比较复杂，我们下期再探讨，先卖个关子——
