Istio控制平面故障后会发生什么？

做者：Jonh Wendell 
译者：李守超 
校对：杨传胜 
原文： www.servicemesher.com/blog/istio-…

你们好！我在Istio上作了一些实验，禁用控制平面的组件，并观察应用和服务网格会发生什么。下面是个人笔记。

Pilot

Pilot负责Istio的流量控制特性，同时将Sidecar更新至最新的网格配置。

Pilot启动之后，监听端口15010（gRPC）和8080（HTTP）。

当应用的Sidecar（Envoy，Istio-Proxy）启动之后，它将会链接pilot.istio-system:15010，获取初始配置，并保持长链接。

Pilot会监听Kubernetes资源，只要检测到网格发生变化，就会将最新的配置经过gRPC链接推送到Sidecar上。

• 当Pilot中止之后，Pilot和Sidecar之间的gRPC链接被关闭，同时Sidecar会一直尝试重连。

• 网络流量不会受到Pilot中止的影响，由于全部的配置被推送过来之后，就会存储在Sidecar的内存中。

• 网格中新的变动信息（例如新的Pod、规则、服务等等）不会继续到达Sidecar，由于Pilot再也不监听这些变化并转发。

• 当Pilot从新上线之后，Sidecar就会从新创建链接（一直尝试重连）并获取到最新的网格配置。

Mixer Policy

Policy执行网络策略。

Mixer在启动时读取配置，并监听Kubernetes的资源变化。一旦检测到新的配置，Mixer就会将其加载至内存中。

Sidecar在每次请求服务应用时，检查（发起链接）Mixer Policy Pod。

当Mixer Policy Pod中止之后，全部到服务的请求会失败，并收到 “503 UNAVAILABLE:no healthy upstream” 的错误——由于全部 sidecar 没法链接到这些Pod。

在Istio 1.1版本中新增了[global]配置（policyCheckfailOpen），容许“失败打开”策略，也即当Mixer Policy Pod没法响应时，全部的请求会成功，而不是报 503 错误。默认状况下该配置设置为false，也即“失败关闭”。

当Mixer中止后，咱们在网格中执行的操做（例如新增规则、更新配置等等）都不会对应用产生影响，直到Mixer从新启动。

Mixer Telemetry

Telemetry为Istio插件提供遥测信息。

Sidecar何时调用Telemetry Pod取决于两个因素：批量完成100次请求和请求时间超过1秒钟（默认配置），这两个条件只要有一个先知足就会执行该操做，这是为了不对Telemetry Pod形成过于频繁的调用。

当Telemetry Pod中止之后，Sidecar记录一次失败信息（在Pod标准错误输出里），并丢弃遥测信息。请求不会受到影响，正如Policy Pod中止时同样。当Telemetry Pod从新启动之后，就会继续从Sidecar收到遥测信息。

其它信息

值得注意的是，Istio容许自定义控制平面的组件。例如，若是不须要Policy，你能够彻底禁用Mixer Policy。Istio 1.1对这种模块化的特性支持的更好。更多信息，能够参考这篇文档。

固然，Pilot、Mixer Policy和Mixer Telemetry在高可用部署场景工做的也很好，能够同时运行多副本。实际上，默认配置经过 HorizontalPodAutoscaler 容许启动1到5个Pod。（详细请参考这篇文档和这篇文档）