4、服务网格与 Istio 入门指南

服务网格与 Istio 入门指南

1. kube - proxy 的局限性

kube - proxy 使用 iptables 或 IPVS 存在一些问题。它无法提供细粒度的配置，所有设置会应用到节点上的所有流量。kube - proxy 只能进行简单的 TCP、UDP 和 SCTP 流转发，或者在一组后端之间进行轮询式的 TCP、UDP 和 SCTP 转发。随着 Kubernetes 服务数量的增加，iptables 中的规则集数量也会增多。由于 iptables 规则是按顺序处理的，这会随着微服务数量的增长导致性能下降。而且，iptables 仅支持使用简单概率来进行流量分配，非常基础。Kubernetes 虽有其他一些方法，但不足以满足微服务之间的弹性通信需求。

2. 弹性、容错通信所需的能力

2.1 重试机制、熔断、超时和截止时间

• 重试机制 ：如果一个 Pod 出现故障，流量应自动发送到另一个 Pod。重试需要在一定约束下进行，避免使通信情况恶化。例如，调用失败后，系统可能需要等待一段时间再重试；若重试仍不成功，可适当增加等待时间；若多次重试都失败，可能需要放弃重试并熔断后续连接。
• 熔断机制 ：类似于电路断路器，当系统出现故障，继续操作不安全时，电路断路器会自动跳闸。在微服务通信中，若一个服务调用另一个服务，而被调用服务无响应、响应过慢影响调用服务，或这种情况达到预定义阈值，就应熔断通信，避免下游系统调用上游系统，防止网络带宽、线程、IO、CPU 和内存等资源浪费在高失败概率的活动上。熔断不能解决通信问题，但可防止问题扩散影响其他系统