-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ambient mesh data path zh blog #25
Conversation
Welcome to the Merbridge OpenSource Community!👏 We're delighted to have you onboard 💘 |
❌ Deploy Preview for stupendous-strudel-5c776f failed.
|
linkTitle: 深入 Ambient Mesh - 流量路径 | ||
date: 2022-10-13 | ||
weight: 1 | ||
description: 此篇博客介绍 Ambient Mesh 中,数据面的流量路径。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
description: 此篇博客介绍 Ambient Mesh 中,数据面的流量路径。 | |
description: 此篇博客介绍 Ambient Mesh 中数据面的流量路径。 |
author: Kebe Liu | ||
--- | ||
|
||
Ambient Mesh 宣布已经有一段时间,已经有不少文章讲述了其用法和架构。本文将深入梳理一下,数据面流量在 Ambient 模式下的路径,帮助大家全面的理解 Ambient 数据面的实现方案。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ambient Mesh 宣布已经有一段时间,已经有不少文章讲述了其用法和架构。本文将深入梳理一下,数据面流量在 Ambient 模式下的路径,帮助大家全面的理解 Ambient 数据面的实现方案。 | |
Ambient Mesh 发布已经有一段时间,已经有不少文章讲述了其用法和架构。本文将深入梳理一下,数据面流量在 Ambient 模式下的路径,帮助大家全面的理解 Ambient 数据面的实现方案。 |
|
||
Ambient Mesh 宣布已经有一段时间,已经有不少文章讲述了其用法和架构。本文将深入梳理一下,数据面流量在 Ambient 模式下的路径,帮助大家全面的理解 Ambient 数据面的实现方案。 | ||
|
||
在阅读本文章之前,需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构,本文不在赘述。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
在阅读本文章之前,需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构,本文不在赘述。 | |
在阅读本文之前,需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构,本文不再赘述。 |
ztunnel-xkz4s 1/1 Running 0 20h | ||
``` | ||
|
||
我们发现在 Ambient 模式下 istio-cni 变成了默认组件,我们知道,istio-cni 在 Sidecar 模式下,主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件,但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们发现在 Ambient 模式下 istio-cni 变成了默认组件,我们知道,istio-cni 在 Sidecar 模式下,主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件,但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? | |
我们发现在 Ambient 模式下 istio-cni 变成了默认组件。我们知道,istio-cni 在 Sidecar 模式下,主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件。但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? |
Sentence too long. I separated it with periods.
1. 添加 Pod 到 ipset | ||
2. 添加了一个路由规则到 table 100(后面介绍用途) | ||
|
||
我们可以在起所在的节点上查看一下 ipset 里面的内容(注意,这里使用 kind 集群,所在主机需要用 docker exec 先进入,后面不再赘述): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们可以在起所在的节点上查看一下 ipset 里面的内容(注意,这里使用 kind 集群,所在主机需要用 docker exec 先进入,后面不再赘述): | |
我们可以在其所在的节点上查看一下 ipset 里面的内容(注意,这里使用 kind 集群,需要用 docker exec 先进入所在主机,后面不再赘述): |
cache | ||
``` | ||
|
||
我们可以看到,当访问 10.244.1.7 时,流量会被路由到 `192.168.126.2`,而这条规则正式上面由 istio-cni 添加的。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们可以看到,当访问 10.244.1.7 时,流量会被路由到 `192.168.126.2`,而这条规则正式上面由 istio-cni 添加的。 | |
我们可以看到,当访问 10.244.1.7 时,流量会被路由到 `192.168.126.2`,而这条规则正是由上面 istio-cni 添加的。 |
|
||
我们可以看到,当访问 10.244.1.7 时,流量会被路由到 `192.168.126.2`,而这条规则正式上面由 istio-cni 添加的。 | ||
|
||
同样的 `192.168.126.2` 这个 IP 属于 ztunnel: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
同样的 `192.168.126.2` 这个 IP 属于 ztunnel: | |
同样地,`192.168.126.2` 这个 IP 属于 ztunnel: |
... | ||
``` | ||
|
||
我们可以知道,如果我们直接在节点上访问 PodIP Pod 端口的时候,会被转发到 ztunnel 的 15006 端口,而这,就是 Istio 处理入口流量的端口。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们可以知道,如果我们直接在节点上访问 PodIP Pod 端口的时候,会被转发到 ztunnel 的 15006 端口,而这,就是 Istio 处理入口流量的端口。 | |
我们可以知道,如果我们直接在节点上访问 PodIP Pod 端口,流量会被转发到 ztunnel 的 15006 端口,而这就是 Istio 处理入口流量的端口。 |
|
||
我们可以知道,如果我们直接在节点上访问 PodIP Pod 端口的时候,会被转发到 ztunnel 的 15006 端口,而这,就是 Istio 处理入口流量的端口。 | ||
|
||
至于目标端口为 15008 端口的流量,这是 ztunnel 用来做四层流量隧道的端口。我们后面再详聊。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
至于目标端口为 15008 端口的流量,这是 ztunnel 用来做四层流量隧道的端口。我们后面再详聊。 | |
至于目标端口为 15008 端口的流量,这是 ztunnel 用来做四层流量隧道的端口,本文暂不细述。 |
|
||
## 对于 Envoy 自身的流量处理 | ||
|
||
我们知道,在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络 NS 中,对于业务容器的流量,我们需要全部拦截,以保证对流量的完成掌控,但是在 Ambient 模式下是否需要呢? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们知道,在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络 NS 中,对于业务容器的流量,我们需要全部拦截,以保证对流量的完成掌控,但是在 Ambient 模式下是否需要呢? | |
我们知道,在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络 NS 中。对于业务容器的流量,我们需要全部拦截,以保证对流量的完成掌控,但是在 Ambient 模式下是否需要呢? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们知道
这样的口语可以适当去掉一些,像我不太知道,就感觉有点尬和嘲 😄
ztunnel-xkz4s 1/1 Running 0 20h | ||
``` | ||
|
||
我们发现在 Ambient 模式下 istio-cni 变成了默认组件,我们知道,istio-cni 在 Sidecar 模式下,主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件,但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们发现在 Ambient 模式下 istio-cni 变成了默认组件,我们知道,istio-cni 在 Sidecar 模式下,主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件,但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? | |
在 Ambient 模式下 istio-cni 变成了默认组件。以前 istio-cni 在 Sidecar 模式下主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件,但是 Ambient 模式下,理论上不需要 Sidecar,为什么还需要 istio-cni 呢? |
```console | ||
|
||
kebe@Kebe-DaoCloud-PC ~ kubectl -n istio-system logs istio-cni-node-qsvsz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
```console | |
kebe@Kebe-DaoCloud-PC ~ kubectl -n istio-system logs istio-cni-node-qsvsz | |
```console | |
$ kubectl -n istio-system logs istio-cni-node-qsvsz |
这 pc 名有点长,把 pc 名字去掉会更简洁一点,下同
要了解出口流量拦截的方案,我们首先可以看一下控制面组件: | ||
|
||
```console | ||
kebe@Kebe-DaoCloud-PC ~ kubectl -n istio-system get po |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kebe@Kebe-DaoCloud-PC ~ kubectl -n istio-system get po | |
$ kubectl -n istio-system get po |
|
||
很清晰了,默认网关被换成了 `192.168.127.2`,且走了 istioout 网卡。 | ||
|
||
这里就有问题了,`192.168.127.2` 这个 IP 并不属于节点 IP 、Pod IP、Cluster IP 中的任意一种,istioout 网卡默认应该也不存在,那他们是谁创建的呢?因为流量最终是需要发往 ztunnel 的,我们可以看看 ztunnel 的配置,看看能否找到答案。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这里就有问题了,`192.168.127.2` 这个 IP 并不属于节点 IP 、Pod IP、Cluster IP 中的任意一种,istioout 网卡默认应该也不存在,那他们是谁创建的呢?因为流量最终是需要发往 ztunnel 的,我们可以看看 ztunnel 的配置,看看能否找到答案。 | |
这里就有问题了,`192.168.127.2` 这个 IP 并不属于 NodeIP、PodIP、ClusterIP 中的任意一种,istioout 网卡默认应该也不存在,那这个 IP 是谁创建的呢?因为流量最终需要发往 ztunnel,我们可以查看 ztunnel 的配置,看看能否找到答案。 |
|
||
有了上面的经验,我们不难发现,Ambient 模式下,对于流量的拦截主要通过 MARK 路由 TPROXY 的方式,入口流量应该也差不多。 | ||
|
||
我们采用最简单的分析方式看一下,分析一下,当节点上的进程,或者其他主机上的程序相应访问当前节点上的 Pod 时,流量会经过主机的路由表,我们查看一下当相应访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们采用最简单的分析方式看一下,分析一下,当节点上的进程,或者其他主机上的程序相应访问当前节点上的 Pod 时,流量会经过主机的路由表,我们查看一下当相应访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息: | |
我们采用最简单的分析方式看一下,分析一下,当节点上的进程或者其他主机上的程序相应访问当前节点上的 Pod 时,流量会经过主机的哪些路由表。以下是访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息: |
|
||
## 对于 Envoy 自身的流量处理 | ||
|
||
我们知道,在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络 NS 中,对于业务容器的流量,我们需要全部拦截,以保证对流量的完成掌控,但是在 Ambient 模式下是否需要呢? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我们知道,在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络 NS 中,对于业务容器的流量,我们需要全部拦截,以保证对流量的完成掌控,但是在 Ambient 模式下是否需要呢? | |
在 Sidecar 模式下,Envoy 和业务容器运行在相同的网络命名空间中,对于业务容器的流量,我们需要全部拦截,以保证对流量的完全掌控,但是在 Ambient 模式下是否需要呢? |
|
||
## 未完待续… | ||
|
||
上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案,还没有涉及到七成流量的处理,以及 ztunnel 实现的具体原理,后续我将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案,还没有涉及到七成流量的处理,以及 ztunnel 实现的具体原理,后续我将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。 | |
上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案,还没有涉及到七层流量的处理以及 ztunnel 实现的具体原理,后续将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。 |
哇,现在 merge 这么快! |
No description provided.