接下来能够直接访问了，如何保证滚动更新时的可用性保证呢？我们找到了官方提供的一个特性ReadinessGate。这个特性在1.12正式提供出来，主要是用来控制Pod的状态。默认情况下，Pod有以下Condition：PodScheduled、Initialized、ContainersReady，当这几个状态都Ready的时候，Pod Ready的Condition就通过了。但是在云原生的场景下面，Pod的状态是非常有可能需要参考其他状态的。ReadinessGate提供了这样一个机制，允许为Pod的状态判断添加一个栅栏，由第三方来进行判断与控制。这样Pod的状态就和第三方关联起来了。
负载均衡流量对比 传统NodePort模式请求流量进入负载均衡
请求被负载均衡转发到某一个节点的NodePort
KubeProxy将来自NodePort的流量进行NAT转发，目的地址是随机的一个Pod。
请求进入容器网络，并根据Pod地址转发到对应节点。
请求来到Pod所属节点，转发到Pod。
新的Pod直连模式请求流量进入负载均衡
请求被负载均衡转发到某一个Pod的ENI弹性网卡
直连与Local访问的区别看起来这两种访问方式的效果是一样的，但是在细节上还是存在一些差别。
从性能上区别不大，开启Local访问时，流量不会进行NAT操作也不会进行跨节点转发，所以仅仅多了一个到容器网络的路由。
没有进行NAT操作，来源IP就能够正确获取了。会话保持功能可能会有以下问题，当一个节点上存在多个Pod时，流量到哪一个Pod是随机的，这个机制可能会使话保持出现问题。
ReadinessGate的引入前面有两个细节，可以在这里得到解答。
为什么要求集群版本高于 1.12
为什么kubectl get pod -o wide的结果中READINESS GATES列有内容。
这里涉及到一个滚动更新相关的问题
当用户开始为应用做滚动更新的时候，Kubernetes会根据更新策略进行滚动更新。但是其判断一批Pod启动的标识仅包括Pod自身的状态，并不会考虑这个Pod在负载均衡上是否已经进行配置健康检查是否通过。有的时候当接入层组件高负载，不能及时对这些Pod进行及时调度的话，这些滚动更新成功的Pod可能并没有正在对外提供服务，从而导致服务的中断。为了将滚动更新和负载均衡的后端状态关联起来，TKE接入层组件引入了Kubernetes 1.12中引入的新特性ReadinessGate。TKE接入层组件只有在确认后端绑定成功并且健康检查通过时，通过配置ReadinessGate的状态来使Pod达到Ready的状态，从而推动整个工作负载的滚动更新。
在集群中使用ReadinessGate的细节
Kubernetes集群提供的是一个服务注册的机制，你只需要将你的服务以MutatingWebhookConfigurations资源的形式注册到集群中就可以了。集群会在Pod创建的时候按照你的配置的回调路径通知你，这个时候就可以对Pod做一些创建前的操作，在这个Case里面就是给Pod加上ReadinessGate。唯一需要注意的就是这个回调过程必须是Https的，所以标配需要在MutatingWebhookConfigurations中配置签发请求的CA，并在服务端配置该CA签发的证书。
ReadinessGate机制的灾难恢复
用户集群中的服务注册或是证书有可能被用户删除，虽然这些系统组件资源不应该被用户修改或破坏。但在用户对集群的探索或是误操作下，这类问题会不可避免的出现。所以接入层组件在启动时会检查以上资源的完整性，在完整性受到破坏时会重建以上资源，加强系统的鲁棒性。
直连与NodePort是服务应用的接入层方案，其实最终参与工作的还是用户部署的工作负载，用户工作负载的能力直接决定了业务的QPS等指标。所以我们针对这两种接入层方案，在工作负载压力较低的情况下，重点针对网络链路的时延进行了一些对比测试。直连在接入层的网络链路上能够优化10%左右的时间。同时测试中的监控也发现，直连模式减少了大量VPC网络内的流量。测试场景，从20节点到80节点，逐步增大集群规模，通过wrk工具对集群进行网络延时的测试。针对QPS和网络时延，下图给出了直连场景与NodePort的对比测试。