0x01 一些官方介绍

都是一些概念，浏览一遍即可，没说很具体

Kubernetes 网络模型

服务、负载均衡和联网

Kubernetes 网络背后的概念和资源。

https://kubernetes.io/zh-cn/docs/concepts/services-networking/

Kubernetes 网络解决四方面的问题：

• 一个 Pod 中的容器之间通过本地回路（loopback）通信。

• 集群网络在不同 Pod 之间提供通信。

• Service API 允许你向外暴露 Pod 中运行的应用， 以支持来自于集群外部的访问。
• Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能。

• 你也可以使用 Service 来发布仅供集群内部使用的服务。

 

Service 与 Pod 的 DNS

你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。

https://kubernetes.io/zh-cn/docs/concepts/services-networking/dns-pod-service/

 

集群网络系统

集群网络系统

集群网络系统是 Kubernetes 的核心部分，但是想要准确了解它的工作原理可是个不小的挑战。 下面列出的是网络系统的的四个主要问题： 高度耦合的容器间通信：这个已经被 Pod 和 localhost 通信解决了。 Pod 间通信：这是本文档讲述的重点。 Pod 与 Service 间通信：涵盖在 Service 中。 外部与 Service 间通信：也涵盖在 Service 中。 Kubernetes 的宗旨就是在应用之间共享机器。 通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间 去大规模地协调端口是件很困难的事情，尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。 动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数， 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 要了解 Kubernetes 网络模型，请参阅此处。 如何实现 Kubernetes 的网络模型 网络模型由每个节点上的容器运行时实现。最常见的容器运行时使用 Container Network Interface (CNI) 插件来管理其网络和安全功能。 许多不同的 CNI 插件来自于许多不同的供应商。其中一些仅提供添加和删除网络接口的基本功能， 而另一些则提供更复杂的解决方案，例如与其他容器编排系统集成、运行多个 CNI 插件、高级 IPAM 功能等。 请参阅此页面了解 Kubernetes 支持的网络插件的非详尽列表。 接下来 网络模型的早期设计、运行原理以及未来的一些计划， 都在联网设计文档里有更详细的描述。

https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model

1. 高度耦合的容器间通信：这个已经被 Pod 和 localhost 通信解决了。

2. Pod 间通信：这是本文档讲述的重点。

3. Pod 与 Service 间通信：涵盖在 Service 中。

4. 外部与 Service 间通信：也涵盖在 Service 中。

 

网络插件

Kubernetes 1.27 支持用于集群联网的容器网络接口 (CNI) 插件。 你必须使用和你的集群相兼容并且满足你的需求的 CNI 插件。 在更广泛的 Kubernetes 生态系统中你可以使用不同的插件（开源和闭源）。 要实现 Kubernetes 网络模型，你需要一个 CNI 插件。 你必须使用与 v0.4.0 或更高版本的 CNI 规范相符合的 CNI 插件。 Kubernetes 推荐使用一个兼容 v1.0.0 CNI 规范的插件（插件可以兼容多个规范版本）。 安装 在网络语境中，容器运行时（Container Runtime）是在节点上的守护进程， 被配置用来为 kubelet 提供 CRI 服务。具体而言，容器运行时必须配置为加载所需的 CNI 插件，从而实现 Kubernetes 网络模型。 说明： 在 Kubernetes 1.24 之前，CNI 插件也可以由 kubelet 使用命令行参数 cni-bin-dir 和 network-plugin 管理。Kubernetes 1.24 移除了这些命令行参数， CNI 的管理不再是 kubelet 的工作。 如果你在移除 dockershim 之后遇到问题， 请参阅排查 CNI 插件相关的错误。 要了解容器运行时如何管理 CNI 插件的具体信息，可参见对应容器运行时的文档，例如： containerd CRI-O 要了解如何安装和管理 CNI 插件的具体信息，可参阅对应的插件或 网络驱动（Networking Provider） 的文档。

https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/

0x02 不安装网络插件Pod本地通信

containerd 通过 runC 创建的容器，需要直接通过宿主机网络通信

在master节点创建记得先把污点去掉～ kubectl describe node 把 taint 里面的都 kubectl taint nodes archlinux node-role.kubernetes.io/control-plane- 或 kubectl taint nodes --all node-role.kubernetes.io/control-plane-

 

使用主机网络

正常创建

此时Pod使用的网卡为宿主机网络

0x03 安装插件Pod通信 - cilium

对于不同的网络插件，下面可能会有较大的差异

1. # Source: cilium/templates/cilium-agent-serviceaccount.yaml

2. # Source: cilium/templates/cilium-operator-serviceaccount.yaml

3. # Source: cilium/templates/cilium-configmap.yaml

4. # Source: cilium/templates/cilium-agent-clusterrole.yaml

5. # Source: cilium/templates/cilium-operator-clusterrole.yaml

6. # Source: cilium/templates/cilium-agent-clusterrolebinding.yaml

7. # Source: cilium/templates/cilium-operator-clusterrolebinding.yaml

8. # Source: cilium/templates/cilium-agent-daemonset.yaml

9. # Source: cilium/templates/cilium-operator-deployment.yaml

Component Overview — Cilium 1.13.2 documentation

https://docs.cilium.io/en/stable/overview/component-overview/#cilium

• Agent 运行于集群中的每个节点上，通过Kubernetes或API接收描述网络、服务负载均衡、网络策略以及可视化和监控需求的配置。它监听来自编排系统（如Kubernetes）的事件，以了解容器或工作负载何时启动和停止。Agent 也管理Linux内核使用的eBPF程序，用于控制这些容器内/外的所有网络访问

• Operator 一般位于master节点上，负责用于IP地址管理（IPAM），给Pod分配新的IP CIDR地址和更新kvstore心跳

0x01 路由

Networking Concepts — Cilium 1.13.2 documentation

https://docs.cilium.io/en/stable/network/concepts/

• vxlan

• geneve

• disabled

0x02 IP管理（IPAM）

1. 通过 v1.Node resource 字段

需要 kube-controller-manager 通过--allocate-node cidrs 启动指定应分配PodCIDR范围

1. 通过 v1.Node annotation 字段

基于annotation的机制主要与旧的Kubernetes版本结合使用，这些版本还不支持spec.podCIDR，但支持IPv4和IPv6。

0x03 Masquerading

1. 基于 eBPF（默认）

• 当用 cilium 完全代替 kube-proxy时不支持 --nodeport-addresses - 官方说后面会解决

• Pod → 外部K8S节点 IP 通信无法 masquerading

• 目前不支持 IPv6流量masquerading

1. 基于 iptables

0x04 IPv4 分段

0x05 网络策略（安全）

1. K8S原生L3-L4的POD入站和出站网络策略

2. 通过CRD（CustomResourceDefinition） 定义 CiliumNetworkPolicy 拓展策略以在L3-L7层支持入站和出站网络策略

3. CiliumClusterwideNetworkPolicy 集群范围 CRD，由Cilium强制执行的集群范围的策略

目前存在疑问🤔️

1. kubelet 和 cilium 是如何协调，在容器中创建出网卡的，可以看看 [1] 这篇文章，好像是 调用 cni 二进制程序做到的，难道这部分是写在 cni 里的？https://github.com/containernetworking/cni/blob/main/SPEC.md

2. 容器内的 vxlan 是如何跨容器进行通信，以及这个 vxlan 是如何被维护的

0x04 Cilium 和 kubelet源码阅读

• kubelet 版本: v1.26.3 commit: 9e644106593f3f4aa98f8a84b23db5fa378900bd

• Cilium 版本: v1.9 commit: 638f8ddac2ffc05a036df66ccf9c5a920c9e5323

1. cilium-operator deployment

2. cilium-agent daemonset

0x01 Cilium operator

0x02 Cilium Agent

Containerd 创建 Pod 网络在创建 Pod 中的调用栈

[github.com/containerd/containerd/vendor/k8s.io/cri-api/pkg/apis/runtime/v1]

• api.proto:40 - rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}

为啥不是 github.com/containerd/containerd/third_party/k8s.io/cri-api/pkg/apis/runtime/v1alpha2？

因为 RunPodSandbox 的方法的接收器为 criService，而 criService 实现的是 CRIService，CRIService 接口里定义了 runtime.RuntimeServiceServer，

RuntimeServiceServer 接口对应 api.proto:34 service RuntimeService {

 

[github.com/containerd/containerd/pkg/cri/server]

• sandbox_run.go:58 - func (c *criService) RunPodSandbox(ctx context.Context, r *runtime.RunPodSandboxRequest) (_ *runtime.RunPodSandboxResponse, retErr error)

• sandbox_run.go:59 - config := r.GetConfig()

• sandbox_run.go:91 - 101

--> RuntimeHandler: r.GetRuntimeHandler(),

注意这个 Goland 自动跳转是不准的，会跳到 PodSandboxStatus 里，正确的应该是跳到 RunPodSandboxRequest 里

[github.com/containerd/containerd/vendor/k8s.io/cri-api/pkg/apis/runtime/v1]

api.pb.go:1499-1504

对应

[github.com/containerd/containerd/vendor/k8s.io/cri-api/pkg/apis/runtime/v1]

api.proto:455-464

462行带有一个官方文档

https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/585-runtime-class#api

https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/585-runtime-class#runtime-handler

 

即这个 RuntimeHandler 就是我们平常认识的运行时 runC、Kata、gVisor

 

网络设置

[github.com/containerd/containerd/pkg/cri/server]

• sandbox_run.go:336 或 • sandbox_run.go:457 - c.setupPodNetwork(ctx, &sandbox);

• sandbox_run.go:531 - func (c *criService) setupPodNetwork(ctx context.Context, sandbox *sandboxstore.Sandbox) error

• sandbox_run.go:536 - netPlugin = c.getNetworkPlugin(sandbox.RuntimeHandler)

想知道这个 RuntimeHandler 是什么

sandbox.RuntimeHandler 在 sandbox_run.go:91 - 101 中初始化，即对应上面的 RuntimeHandler: r.GetRuntimeHandler()

• sandbox_run.go:367 - netPlugin.Setup(ctx, id, path, opts...)

[github.com/containerd/containerd/vendor/github.com/containerd/go-cni]

• cni.go:163 - c.attachNetworks(ctx, ns)

• cni.go:218 - go asynchAttach(ctx, i, network, ns, &wg, rc)

• cni.go:206 - n.Attach(ctx, ns)

[github.com/containerd/containerd/vendor/github.com/containerd/go-cni]

• namespace.go:33 - n.cni.AddNetworkList(ctx, n.config, ns.config(n.ifName))

[github.com/containerd/containerd/vendor/github.com/containernetworking/cni/libcni]

• api.go:422 - c.addNetwork(ctx, list.Name, list.CNIVersion, net, result, rt)

 

• api.go:395 - pluginPath, err := c.exec.FindInPath(net.Network.Type, c.Path)

这里的 c 为 CNIConfig 即上面 containerd启动流程调用栈 里分析出来的路径 /opt/cni/bin ，net.Network.Type 经分析为 /etc/cni/net.d/05-cilium.conf 里的 type 字段

所以 pluginPath 为 /opt/cni/bin/cilium-cni

 

• api.go:414 - invoke.ExecPluginWithResult(ctx, pluginPath, newConf.Bytes, c.args("ADD", rt), c.exec) [github.com/containerd/containerd/vendor/github.com/containernetworking/cni/pkg/invoke]

• exec.go:126 - stdoutBytes, err := exec.ExecPlugin(ctx, pluginPath, netconf, args.AsEnv())

 

cilium-cni 创建 Pod 网络调用栈

对应的代码在 github.com/cilium/cilium/plugins/cilium-cni 包

先看 main 函数

cniVersion 参数指定插件支持的 cni 版本，这里最高支持 0.3.1，这与 https://github.com/containernetworking/cni/blob/spec-v0.3.1/SPEC.md#parameters 文档描述 cni 插件 0.3.1 必须支持的一致，即容器增加网络、删除网络和直接运行 cilium-cni 时，返回支持的 cni 版本（注意与spec-v1.0版本是有不同的），可以看这个表 https://github.com/containernetworking/cni/blob/main/SPEC.md#released-versions

 

跟进 cmdAdd研究如何增加容器网络

[src/github.com/cilium/cilium/plugins/cilium-cni]

• cilium-cni.go:80 - skel.PluginMain(cmdAdd,

• cilium-cni.go:358 - configResult, err := c.ConfigGet()

• config.go:25 - resp, err := c.Daemon.GetConfig(nil)

[github.com/cilium/cilium/api/v1/client/daemon]

• daemon_client.go:99 -

通过调用接口获取配置向 cilium-agent （作为服务端）获取配置

 

cilium-agent 接口定义

[github.com/cilium/cilium/api/v1/server/restapi]

• cilium_api_api.go:629 - o.handlers["GET"]["/config"] = daemon.NewGetConfig(o.context, o.DaemonGetConfigHandler)

最终调用

[github.com/cilium/cilium/daemon/cmd]

• config.go:108 - func (h *getConfig) Handle(params GetConfigParams) middleware.Responder

 

接下来根据从服务端读到的配置，选择相应的虚拟化网卡模式

关于 VETH 和 IPVLAN可以看文章的 [VETH虚拟网卡技术] 和 [IPVLAN虚拟网卡技术] 部分

个人觉得主要区别是 veth 实现逻辑更简单，ipvlan 更复杂，但相应的 ipvlan 在使用 vepa 模式时，性能更高

[src/github.com/cilium/cilium/plugins/cilium-cni]

• cilium-cni.go:381 - case datapathOption.DatapathModeVeth:

• cilium-cni.go:410 - case datapathOption.DatapathModeIpvlan:

默认一般用 veth 模式较多

 

• cilium-cni.go:387 - veth, peer, tmpIfName, err = connector.SetupVeth(ep.ContainerID, int(conf.DeviceMTU), ep)

创建 veth pair，并通过 SetupVethWithNames 设置 mac mtu等信息

• host 侧网卡命名: lxc + sha256(containerID))，如 lxceb7fcc8be80b63438e0f737d76aae32e9d2aabc857c33def4ec6098e5c2c7624；

• container 侧网卡命名：tmp + maxLen(containerID, 5)

 

SetupVethWithNames(lxcIfName, tmpIfName, mtu, ep) 底层通过系统调用创建 AF_NETLINK 套接字使用原始套接字向Linux内核发送Netlink消息（用户态 → 内核态）创建 veth

[github.com/cilium/cilium/vendor/github.com/vishvananda/netlink/nl]

• nl_linux.go:428 - s, err = getNetlinkSocket(sockType)

• nl_linux.go:516 - fd, err := unix.Socket(unix.AF_NETLINK, unix.SOCK_RAW|unix.SOCK_CLOEXEC, protocol)

• nl_linux.go:446 - s.Send(req)

libnetlink.c « lib - iproute2/iproute2.git - Iproute2 routing commands and utilities (kernel.org) ip 命令也是这样做的

 

[github.com/cilium/cilium/plugins/cilium-cni]

• cilium-cni.go:400 - netlink.LinkSetNsFd(*peer, int(netNs.Fd()))

• cilium-cni.go:405 - connector.SetupVethRemoteNs(netNs, tmpIfName, args.IfName)

上述两行代码实现把容器侧的网卡放入新的命名空间中，并重命名网卡名称

 

配置容器侧路由

• cilium-cni.go:481 - prepareIP(ep.Addressing.IPV4, false, &state, int(conf.RouteMTU))

• cilium-cni.go:238 - state.IP4routes, err = connector.IPv4Routes(state.HostAddr, mtu); • cilium-cni.go:506- macAddrStr, err = configureIface(ipam, args.IfName, &state)

 

代码执行结果可以通过下面操作查看

找到容器的的进程id pid

进入容器网络命名空间并查看容器侧路由表

继续往下走

 

/opt/cni/bin/cilium-cni 二进制文件作为客户端调用 Cilium Agent Pod 服务端分配IP。

• cilium-cni.go:427 - ipam, err = c.IPAMAllocate("", podName, true)

[github.com/cilium/cilium/pkg/client]

• ipam.go:29 - func (c *Client) IPAMAllocate(family, owner string, expiration bool) (*models.IPAMResponse, error)

• ipam.go:42 - resp, err := c.Ipam.PostIpam(params)

 

[github.com/cilium/cilium/api/v1/client/ipam]

• ipam_client.go:85 - func (a *Client) PostIpam(params *PostIpamParams) (*PostIpamCreated, error)

 

服务端 ipam server ipam 模块逻辑 可看

Cilium 创建 pod network 源码解析 - 掘金 (juejin.cn)

主要逻辑还是通过本机 pod cidr 中分配出一个 pod ip

[github.com/cilium/cilium/daemon/cmd/ipam]

• ipam_client.go:85 -

 

[github.com/cilium/cilium/pkg/ipam]

• ipam.go:379 -

• ipam.go:111 -

 

通过一系列函数调用，会调用 hostScopeAllocator.AllocateNext() 来获取 pod ip

• hostscope.go:32 -

• hostscope.go:65 -

 

和上文说到 cilium 使用 k8s 源码中从 cluster cidr 划分多个 pod cidr 一样，cilium 也是复用了 k8s 源码中从 pod cidr 中划分出一个个 pod ip 的逻辑，cilium 为了防止引入其他 k8s 依赖包，单独把 k8s 源码中 ip allocator 逻辑 单独出来一个包 cilium/ipam 。

该包支持 pod ip 两种分配策略：随机顺序分配 randomScanStrategy 和连续顺序分配 contiguousScanStrategy，默认使用随机顺序分配（这种 IP 分配是DHCP服务端会根据POD的mac地址取哈希的方式去获取一个IP）。

 

总之，cilium cni 二进制作为客户端调用 cilium daemon 服务端 IPAM 模块，来从 pod cidr 中随机分配获取 pod ip，并在上文第一步中配置 pod 网卡。

0x03 eBPF

0x05 Reference