Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add ambient mesh data path zh blog #25

Merged
merged 2 commits into from
Oct 13, 2022
Merged

Add ambient mesh data path zh blog #25

merged 2 commits into from
Oct 13, 2022

Conversation

kebe7jun
Copy link
Member

No description provided.

@kebe7jun kebe7jun requested a review from a team as a code owner October 13, 2022 06:14
@mergify
Copy link
Contributor

mergify bot commented Oct 13, 2022

Welcome to the Merbridge OpenSource Community!👏

We're delighted to have you onboard 💘

@netlify
Copy link

netlify bot commented Oct 13, 2022 •
edited
Loading

❌ Deploy Preview for stupendous-strudel-5c776f failed.

Name Link
🔨 Latest commit 9f89d08
🔍 Latest deploy log https://app.netlify.com/sites/stupendous-strudel-5c776f/deploys/6347bcac4fd4fe00089bae8d

Michelle951
Michelle951 reviewed Oct 13, 2022
View reviewed changes
content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
linkTitle: 深入 Ambient Mesh - 流量路径
date: 2022-10-13
weight: 1
description: 此篇博客介绍 Ambient Mesh 中，数据面的流量路径。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: 此篇博客介绍 Ambient Mesh 中，数据面的流量路径。
description: 此篇博客介绍 Ambient Mesh 中数据面的流量路径。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
author: Kebe Liu
---

Ambient Mesh 宣布已经有一段时间，已经有不少文章讲述了其用法和架构。本文将深入梳理一下，数据面流量在 Ambient 模式下的路径，帮助大家全面的理解 Ambient 数据面的实现方案。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Ambient Mesh 宣布已经有一段时间，已经有不少文章讲述了其用法和架构。本文将深入梳理一下，数据面流量在 Ambient 模式下的路径，帮助大家全面的理解 Ambient 数据面的实现方案。
Ambient Mesh 发布已经有一段时间，已经有不少文章讲述了其用法和架构。本文将深入梳理一下，数据面流量在 Ambient 模式下的路径，帮助大家全面的理解 Ambient 数据面的实现方案。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

Ambient Mesh 宣布已经有一段时间，已经有不少文章讲述了其用法和架构。本文将深入梳理一下，数据面流量在 Ambient 模式下的路径，帮助大家全面的理解 Ambient 数据面的实现方案。

在阅读本文章之前，需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构，本文不在赘述。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
在阅读本文章之前，需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构，本文不在赘述。
在阅读本文之前，需要先阅读 [Ambient Mesh 介绍](https://istio.io/latest/blog/2022/introducing-ambient-mesh/) 以了解基本的架构，本文不再赘述。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
ztunnel-xkz4s 1/1 Running 0 20h
```

我们发现在 Ambient 模式下 istio-cni 变成了默认组件，我们知道，istio-cni 在 Sidecar 模式下，主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件，但是 Ambient 模式下，理论上不需要 Sidecar，为什么还需要 istio-cni 呢？
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们发现在 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.

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
1. 添加 Pod 到 ipset
2. 添加了一个路由规则到 table 100（后面介绍用途）

我们可以在起所在的节点上查看一下 ipset 里面的内容（注意，这里使用 kind 集群，所在主机需要用 docker exec 先进入，后面不再赘述）：
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们可以在起所在的节点上查看一下 ipset 里面的内容（注意，这里使用 kind 集群，所在主机需要用 docker exec 先进入，后面不再赘述）：
我们可以在其所在的节点上查看一下 ipset 里面的内容（注意，这里使用 kind 集群，需要用 docker exec 先进入所在主机，后面不再赘述）：

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
cache
```

我们可以看到，当访问 10.244.1.7 时，流量会被路由到 `192.168.126.2`，而这条规则正式上面由 istio-cni 添加的。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们可以看到，当访问 10.244.1.7 时，流量会被路由到 `192.168.126.2`，而这条规则正式上面由 istio-cni 添加的。
我们可以看到，当访问 10.244.1.7 时，流量会被路由到 `192.168.126.2`，而这条规则正是由上面 istio-cni 添加的。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

我们可以看到，当访问 10.244.1.7 时，流量会被路由到 `192.168.126.2`，而这条规则正式上面由 istio-cni 添加的。

同样的 `192.168.126.2` 这个 IP 属于 ztunnel：
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
同样的 `192.168.126.2` 这个 IP 属于 ztunnel：
同样地，`192.168.126.2` 这个 IP 属于 ztunnel：

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
...
```

我们可以知道，如果我们直接在节点上访问 PodIP Pod 端口的时候，会被转发到 ztunnel 的 15006 端口，而这，就是 Istio 处理入口流量的端口。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们可以知道，如果我们直接在节点上访问 PodIP Pod 端口的时候，会被转发到 ztunnel 的 15006 端口，而这，就是 Istio 处理入口流量的端口。
我们可以知道，如果我们直接在节点上访问 PodIP Pod 端口，流量会被转发到 ztunnel 的 15006 端口，而这就是 Istio 处理入口流量的端口。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

我们可以知道，如果我们直接在节点上访问 PodIP Pod 端口的时候，会被转发到 ztunnel 的 15006 端口，而这，就是 Istio 处理入口流量的端口。

至于目标端口为 15008 端口的流量，这是 ztunnel 用来做四层流量隧道的端口。我们后面再详聊。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
至于目标端口为 15008 端口的流量，这是 ztunnel 用来做四层流量隧道的端口。我们后面再详聊。
至于目标端口为 15008 端口的流量，这是 ztunnel 用来做四层流量隧道的端口，本文暂不细述。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

## 对于 Envoy 自身的流量处理

我们知道，在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络 NS 中，对于业务容器的流量，我们需要全部拦截，以保证对流量的完成掌控，但是在 Ambient 模式下是否需要呢？
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们知道，在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络 NS 中，对于业务容器的流量，我们需要全部拦截，以保证对流量的完成掌控，但是在 Ambient 模式下是否需要呢？
我们知道，在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络 NS 中。对于业务容器的流量，我们需要全部拦截，以保证对流量的完成掌控，但是在 Ambient 模式下是否需要呢？

windsonsea
windsonsea reviewed Oct 13, 2022
View reviewed changes
Copy link
Member

@windsonsea windsonsea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

我们知道 这样的口语可以适当去掉一些，像我不太知道，就感觉有点尬和嘲 😄

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
ztunnel-xkz4s 1/1 Running 0 20h
```

我们发现在 Ambient 模式下 istio-cni 变成了默认组件，我们知道，istio-cni 在 Sidecar 模式下，主要是为了避免使用 istio-init 容器处理 iptables 规则而造成权限泄露等情况推出的 CNI 插件，但是 Ambient 模式下，理论上不需要 Sidecar，为什么还需要 istio-cni 呢？
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们发现在 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 呢？

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
Comment on lines 48 to 50
```console

kebe@Kebe-DaoCloud-PC  ~  kubectl -n istio-system logs istio-cni-node-qsvsz
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
```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 名字去掉会更简洁一点，下同

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated
要了解出口流量拦截的方案，我们首先可以看一下控制面组件：

```console
kebe@Kebe-DaoCloud-PC  ~  kubectl -n istio-system get po
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
kebe@Kebe-DaoCloud-PC  ~  kubectl -n istio-system get po
$ kubectl -n istio-system get po

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

很清晰了，默认网关被换成了 `192.168.127.2`，且走了 istioout 网卡。

这里就有问题了，`192.168.127.2` 这个 IP 并不属于节点 IP 、Pod IP、Cluster IP 中的任意一种，istioout 网卡默认应该也不存在，那他们是谁创建的呢？因为流量最终是需要发往 ztunnel 的，我们可以看看 ztunnel 的配置，看看能否找到答案。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
这里就有问题了，`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 的配置，看看能否找到答案。

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

有了上面的经验，我们不难发现，Ambient 模式下，对于流量的拦截主要通过 MARK 路由 TPROXY 的方式，入口流量应该也差不多。

我们采用最简单的分析方式看一下，分析一下，当节点上的进程，或者其他主机上的程序相应访问当前节点上的 Pod 时，流量会经过主机的路由表，我们查看一下当相应访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息：
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们采用最简单的分析方式看一下，分析一下，当节点上的进程，或者其他主机上的程序相应访问当前节点上的 Pod 时，流量会经过主机的路由表，我们查看一下当相应访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息：
我们采用最简单的分析方式看一下，分析一下，当节点上的进程或者其他主机上的程序相应访问当前节点上的 Pod 时，流量会经过主机的哪些路由表。以下是访问 productpage-v1-7c548b785b-w9zl6(10.244.1.7) 时的路由信息：

content/zh/blog/2022/ambient-mesh-data-path/index.md Outdated

## 对于 Envoy 自身的流量处理

我们知道，在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络 NS 中，对于业务容器的流量，我们需要全部拦截，以保证对流量的完成掌控，但是在 Ambient 模式下是否需要呢？
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
我们知道，在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络 NS 中，对于业务容器的流量，我们需要全部拦截，以保证对流量的完成掌控，但是在 Ambient 模式下是否需要呢？
在 Sidecar 模式下，Envoy 和业务容器运行在相同的网络命名空间中，对于业务容器的流量，我们需要全部拦截，以保证对流量的完全掌控，但是在 Ambient 模式下是否需要呢？

content/zh/blog/2022/ambient-mesh-data-path/index.md

## 未完待续…

上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案，还没有涉及到七成流量的处理，以及 ztunnel 实现的具体原理，后续我将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案，还没有涉及到七成流量的处理，以及 ztunnel 实现的具体原理，后续我将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。
上面我们主要分析了在 Ambient 模式下对于 Pod 流量拦截的方案，还没有涉及到七层流量的处理以及 ztunnel 实现的具体原理，后续将分析流量在 ztunnel 和 waypoint proxy 中详细的处理路径。

@merbridge merbridge deleted a comment from Michelle951 Oct 13, 2022
@mergify mergify bot merged commit e1bc2be into main Oct 13, 2022
@windsonsea
Copy link
Member

哇，现在 merge 这么快！

@kebe7jun kebe7jun deleted the ambient-mesh-data-path branch October 13, 2022 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Michelle951 Michelle951 Michelle951 left review comments

@windsonsea windsonsea windsonsea approved these changes

Assignees

@hanxiaop hanxiaop

@windsonsea windsonsea

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@kebe7jun @windsonsea @Michelle951 @hanxiaop