Istio社区一直在快速更新中，每个Istio功能模块的相对成熟度和支持级别也随之在不断地变化。社区对这些功能模块的不同发展阶段进行了定义，参见表9-1。
表9-1 Istio功能模块的不同发展阶段
不同的功能模块成熟度和发展阶段不尽相同，熟悉这些阶段进展情况，对于选择Istio的哪些功能模块应用到生产环境中非常有帮助。这些信息在每月Istio发布后会及时更新，读者可以及时从官方网站了解最新进展：https://istio.io/about/feature-stages/。
总体而言，Istio Pilot和Envoy相关的流量管理功能模块比较成熟，除了自定义Envoy Filter的支持处于Alpha状态外，其他功能模块都是Beta或者Stable。Istio 1.4中的具体状态摘录参见表9-2。
表9-2 Istio 1.4中的功能模块状态
1.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就会重新建立连接（一直尝试重连）并获取最新的网格配置。
2.Mixer的稳定性
Mixer 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错误。当Mixer停止后，我们在网格中执行的操作（例如新增规则、更新配置等）都不会对应用产生影响，直到Mixer重新启动。
Mixer Telemetry为Istio插件提供遥测信息。Sidecar什么时候调用Telemetry pod取决于两个因素：批量完成100次请求和请求时间超过1秒钟（默认配置），这两个条件只要有一个先满足就会执行该操作，这是为了避免对Telemetry pod造成过于频繁的调用。
当Telemetry pod停止以后，Sidecar记录一次失败信息（在pod标准错误输出里），并丢弃遥测信息。请求不会受到影响，正如Policy pod停止时一样。当Telemetry pod重新启动以后，就会继续从Sidecar收到遥测信息。
此外，Istio允许自定义控制平面的组件。例如，如果不需要Policy，你可以完全禁用Mixer Policy。Pilot、Mixer Policy和Mixer Telemetry在高可用部署场景工作得也很好，可以同时运行多副本。实际上，默认配置通过HorizontalPodAutoscaler允许启动1到5个pod。