Istio sidecar 中的流量类型及 iptables 规则详解

标签: istio sidecar 流量 | 发表时间:2022-05-07 11:18 | 作者:
出处:https://jimmysong.io/blog/

我在 之前的一篇博客中讲解过 Istio 中 sidecar 的注入、使用 iptables 进行透明流量拦截及流量路由的详细过程,并以 Bookinfo 示例中的 productpage 服务访问 reviews 服务,和 reviews 服务访问 ratings 服务为例绘制了透明流量劫持示意图。在那个示意图中仅展示了 reviews pod 接收流量和对外访问的路由,实际上 sidecar 内的流量远不止于此。

本文将向你展示 Istio sidecar 中的六种流量类型及其 iptables 规则,并以示意图的形式带你一览其全貌。

Sidecar 中的 iptables 流量路由

Sidecar 中的流量可以划分为以下几类:

  • 远程服务访问本地服务:Remote Pod -> Local Pod
  • 本地服务访问远程服务:Local Pod -> Remote Pod
  • Prometheus 抓取本地服务的 metrics:Prometheus -> Local Pod
  • 本地 Pod 服务间的流量:Local Pod -> Local Pod
  • Envoy 内部的进程间 TCP 流量
  • Sidecar 到 Istiod 的流量

下面将依次解释每个场景下 Sidecar 内的 iptables 路由规则。

类型一:Remote Pod -> Local Pod

以下是远程服务、应用或客户端访问数据平面本地 Pod IP 的 iptables 规则。

Remote Pod -> RREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> Envoy 15006(Inbound)-> OUTPUT -> ISTIO_OUTPUT RULE 1 -> POSTROUTING -> Local Pod

我们看到流量只经过一次 Envoy 15006 Inbound 端口。这种场景下的 iptables 规则的示意图如下。

Remote Pod -> Local Pod

类型二:Local Pod -> Remote Pod

以下是本地 Pod IP 访问远程服务经过的 iptables 规则。

Local Pod-> OUTPUT -> ISTIO_OUTPUT RULE 9 -> ISTIO_REDIRECT -> Envoy 15001(Outbound)-> OUTPUT -> ISTIO_OUTPUT RULE 4 -> POSTROUTING -> Remote Pod

我们看到流量只经过 Envoy 15001 Outbound 端口。这种场景下的 iptables 规则的示意图如下。

Local Pod -> Remote Pod

以上两种场景中的流量都只经过一次 Envoy,因为该 Pod 中只有发出或接受请求一种场景发生。

类型三:Prometheus -> Local Pod

Prometheus 抓取数据平面 metrics 的流量不会也无须经过 Envoy 代理。

这些流量通过的 iptables 规则如下。

Prometheus-> RREROUTING -> ISTIO_INBOUND(对目的地为 15002、15090 端口流量将转到 INPUT)-> INPUT -> OUTPUT -> ISTIO_OUTPUT RULE 3 -> POSTROUTING -> Local Pod

这种场景下的 iptables 规则的示意图如下。

Prometheus -> Local Pod

类型四:Local Pod -> Local Pod

一个 Pod 可能同时存在两个或多个服务,如果 Local Pod 访问的服务也在该当前 Pod 上,流量会依次经过 Envoy 15001 和 Envoy 15006 端口最后到达本地 Pod 的服务端口上。

这些流量通过的 iptables 规则如下。

Local Pod-> OUTPUT -> ISTIO_OUTPUT RULE 9 -> ISTIO_REDIRECT -> Envoy 15001(Outbound)-> OUTPUT -> ISTIO_OUTPUT RULE 2 -> ISTIO_IN_REDIRECT -> Envoy 15006(Inbound)-> OUTPUT -> ISTIO_OUTPUT RULE 1 -> POSTROUTING -> Local Pod

这种场景下的 iptables 规则的示意图如下。

Local Pod -> Local Pod

类型五:Envoy 内部的进程间 TCP 流量

Envoy 内部进程的 UID 和 GID 为 1337,它们之间的流量将使用 lo 网卡,使用 localhost 域名来通信。

这些流量通过的 iptables 规则如下。

Envoy 进程(Localhost) -> OUTPUT -> ISTIO_OUTPUT RULE 8 -> POSTROUTING -> Envoy 进程(Localhost)

这种场景下的 iptables 规则的示意图如下。

Envoy 内部的进程间 TCP 流量

类型六:Sidecar 到 Istiod 的流量

Sidecar 需要访问 Istiod 以同步配置,因此 Envoy 会有向 Istiod 发送流量。

这些流量通过的 iptables 规则如下。

Local Pod-> OUTPUT -> ISTIO_OUTPUT RULE 4 -> POSTROUTING -> Istiod

这种场景下的 iptables 规则的示意图如下。

Sidecar 到 Istiod 的流量

总结

Istio 注入在 Pod 内或虚拟机中安装的所有 sidecar 代理组成了服务网格的数据平面,也是 Istio 的主要工作负载所在地,通过 Istio 中的透明流量劫持 及这篇博客,相信你一定对 sidecar 代理中的流量有了一个深刻的了解,但这还只是管中窥豹,略见一斑,在我的 下一篇博客中,我将带你了解 Envoy 中各个组件的端口及其功能,这样可以让我们对 Istio 中的流量有一个更全面的了解。

相关 [istio sidecar 流量] 推荐:

Istio sidecar 中的流量类型及 iptables 规则详解

- - Jimmy Song - 云原生|开源|社区 – 博客
我在 之前的一篇博客中讲解过 Istio 中 sidecar 的注入、使用 iptables 进行透明流量拦截及流量路由的详细过程,并以 Bookinfo 示例中的 productpage 服务访问 reviews 服务,和 reviews 服务访问 ratings 服务为例绘制了透明流量劫持示意图.

Istio 中的服务和流量的抽象模型

- - IT瘾-dev
本文介绍了 Istio 和 Kubernetes 中的一些服务和流量的抽象模型. 虽然 Istio 一开始确定的抽象模型与对接的底层平台无关,但目前来看基本绑定 Kubernetes,本文仅以 Kubernetes 说明. 另外在 ServiceMesher 社区中最近有很多关于 Istio、Envoy、Kubernetes 之中的服务模型关系的讨论,本文作为一个开篇说明,Kubernetes 和 Isito 之间有哪些共有的服务模型,Istio 在 Kubernetes 的服务模型之上又增加了什么,为什么说 Kubernetes service 存在的意义仅剩下做服务发现.

如何理解 Istio 中的 mTLS 流量加密?

- - Jimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式 – 博客
Istio 服务网格可以帮助云原生应用实现自动 mTLS,完成网格内的流量加密,有助于缩小云原生部署的攻击面,是构建零信任应用网络的关键框架. 为了理解 Istio 中的 mTLS 流量加密,本文将包括以下内容:. 介绍什么是 TLS、mTLS 和 TLS 终止. 介绍 Istio 中如何实现 TLS 加密.

istio灰度发布流量管理_llarao的博客-CSDN博客_istio使用

- -
VirtualService路由规则配置. 1.HttpRoute的路由目标. 2.HTTPRedirect重定向. 3.HTTPRewrite重写. 4.HTTPRerty重试. 6.HttpFaultInjection故障注入. DestinationRule目标规则. DestinationRule规则定义.

istio 原理简介

- - 掘金 架构
由于 istio 自 1.5 版本以后架构上有了较大变化,控制面从多组件变成了单体的 istiod 组件,所以下文会先介绍 1.5 之前的架构,再介绍 1.5 之后的,是一个由繁到简的过程. istio 1.5 之前架构. Istio 的架构分为控制平面和数据平面. 数据平面:由一组智能代理(Envoy)以 sidecar 模式部署,协调和控制所有服务之间的网络通信.

Istio 常见的 10 个异常分析

- - DockOne.io
本文总结了使用 Istio 常见的 10 个异常. Istio 支持多平台,不过 Istio 和 Kubernetes 的兼容性是最优的,不管是设计理念,核心团队还是社区, 都有一脉相承的意思. 但 Istio 和 Kubernetes 的适配并非完全没有冲突,一个典型问题就是 Istio 需要 Kubernetes Service 按照协议进行端口命名(Port Naming).

Istio究竟是干嘛的? - 知乎

- -
当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:. 一个进程实现业务逻辑,biz,即上图白色方块. 一个进程实现底层技术体系,proxy,即上图蓝色方块,负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现. biz不管是调用服务,还是提供服务,都只与本地的proxy进行本地通信.

使用 Istio 进行金丝雀部署

- -
本篇博客最后更新时间 2018 年 5 月 16 号,采用了最新版本的流量管理模型. Istio项目的一大好处就是为服务金丝雀方式部署提供了控制便利. 金丝雀部署(或上线)背后的想法是通过让一小部分用户流量引入的新版本进行测试,如果一切顺利,则可以增加(可能逐渐增加)百分比,逐步替换旧版本. 如在过程中出现任何问题,则可以中止并回滚到旧版本.

实践k8s istio熔断 - fat_girl_spring - 博客园

- -
熔断主要是无感的处理服务异常并保证不会发生级联甚至雪崩的服务异常. 在微服务方面体现是对异常的服务情况进行快速失败,它对已经调用失败的服务不再会继续调用,如果仍需要调用此异常服务,它将立刻返回失败. 与此同时,它一直监控服务的健康状况,一旦服务恢复正常,则立刻恢复对此服务的正常访问. 这样的快速失败策略可以降低服务负载压力,很好地保护服务免受高负载的影响.

知乎落地的 Service Mesh Istio

- -
在知乎,我们很早就进行了非常彻底的容器化部署. 全站在线运行的微服务数量高达两千多个. 这些微服务通过我们自己维护的 RPC 框架和 Kodor 体系来实现服务互联的能力. 在这其中,我们也存在一系列的问题:. 各种基础组件维护成本比较高,单点风险存在. 各语言客户端特性难以统一,熔断、重试等特性实现颇有不同,且不能做到动态线上进行调整.