当我们想将 k8s 集群里的服务向外暴露时，一般是将 k8s service 指定 LoadBalancer类型。目前大多数云厂商会绑定云平台的负载均衡器，并为其分配一个固定的公网 IP 从而向外提供服务。而对于我们自建的 kubernetes 裸机集群则只能选择类似 MetalLB 这类解决方案，这种情况下如何让用户可以通过这个 IP 访问到自建 k8s 的服务呢，本文来分析一下其实现原理。 本文的环境安装了 MetallB，它指定分配 IP Pool 为内网 IP 地址，实验环境为 https://blog.haohtml.com/posts/install-kubernetes-in-raspberry-pi/。 将外部请求流入集群节点 当我们需要访问一台机器时,无论是使用 IP 地址还是域名,最终都需要将其解析为 IP 地址。而要真正建立连接并传输数据,我们必须获取目标 IP 地址对应的 MAC 地址,这是由于 TCP/IP 协议分层机制决定的。 在 TCP/IP 协议栈的链路层,数据是通过封装成数据帧的方式在局域网内传输的。数据帧中包含了目标 MAC 地址,用于标识应该将数据发送到哪个网络设备。因此,如果我们想要与某台机器建立通信,就必须首先知道其 IP 地址对应的 MAC 地址。 而 ARP 协议正是解决这一问题的利器。它通过在局域网内广播 ARP 请求,询问拥有某 IP 地址的主机的 MAC 地址。拥有该 IP 地址的目标主机会作出 ARP 响应,将自身的 IP 地址和 MAC 地址映射关系回复给发送方。发送方就可以基于这个映射关系,构建含有正确目标 MAC 地址的数据帧,并最终通过物理网络将数据传输到目的地。 搞明白了一点，理解起来就简单多了。 这里先贴一下实验环境，k8s master 节点 ip 配置

这里是 arm64 架构，树莓派 4B, 四核八 G 内存 配置，系统为 Ubuntu 22.04.1 LTS $ uname -a Linux ubuntu 5.15.0-1049-raspi #52-Ubuntu SMP PREEMPT Thu Mar 14 08:39:42 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux $ cat /etc/issue Ubuntu 22.04.1 LTS \n \l 环境检查 由于 k8s 会使用 8080 和 6443 这两个端口，因此要保证端口可用，然后禁用 swap。 sudo swapoff -a 最后对安装环境初始化，参考 https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/ 安装 Docker 参考 https://docs.docker.com/engine/install/ubuntu/ 安装成功后，修改 cgroupdriver 为 systemd，同时为了国内访问 docker 镜像加速，需要设置一下 aliyun 的 docker 镜像地址 sudo tee /etc/docker/daemon.json <<-'EOF' { "exec-opts": ["native.

在做一个试验时，无意中发现使用 kubectl create service 命令无法为一个通过 deployment 创建出来的pod创建对应的 service， 感觉有点奇怪，经过分析才明白怎么回事，这里将过程记录一下。 这里需要说明一下，本文操作全部是通过 kubectl create 命令来完成的，并没有使用 kubectl apply -f pod.yaml 这种方式。 这里先创建一个实验命名空间 lab $ kubectl create ns lab 首先创建一个deployment 对象 $ kubectl create deployment test --image=nginx:1.23-alpine --replicas=2 --port=80 -n lab 确认创建成功 $ kubectl get deploy,pod -n lab NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/test 2/2 2 2 16s NAME DESIRED CURRENT READY AGE replicaset.apps/test-8544f5598b 2 2 2 16s NAME READY STATUS RESTARTS AGE pod/test-8544f5598b-7tfq4 1/1 Running 0 16s pod/test-8544f5598b-d48js 1/1 Running 0 16s 这里我们成功创建了一个 test的 deployment 对象，而由此创建的 Pod.

在上一篇《创建Pod源码解析》文中，我们大概介绍了Pod的整体创建过程。其中有一步很重要，就是在创建三类容器之前必须先创建一个 sandbox （源码)，本篇就来分析一下sandbox这一块的 netns 实现过程。 对 sandbox 的创建由 kubelet 组件通过调用 CRI 容器运行时服务来实现的，对于容器运行的实现目前市面上有多个，如 Docker Engine(不推荐)、 containerd、CRI-O 等，由于目前生产环境中选择 containerd 的占大多数，所以这里我们以 containerd 为例来看一下其实现过程。 https://github.com/containerd/containerd/blob/32bf805e5703bc91387d047fa76625e915ac2b80/pkg/cri/server/sandbox_run.go 对 sandbox 的创建是由 cri 服务调用 RunPodSandbox()方法来实现的。 // RunPodSandbox creates and starts a pod-level sandbox. Runtimes should ensure // the sandbox is in ready state. func (c *criService) RunPodSandbox(ctx context.Context, r *runtime.RunPodSandboxRequest) (_ *runtime.RunPodSandboxResponse, retErr error) { ... // Save sandbox name sandboxInfo.AddLabel("name", name) // 初始化 sandbox, 注意此时的 network namespace 未指定 // Create initial internal sandbox object.

在 Rust 中，闭包就是一种能捕获 上下文环境变量 的函数。 let range = 0..10; let get_range_count = || range.count(); 代码里的这个 get_range_count 就是闭包，range 是被这个闭包捕获的环境变量。 虽然说它是一种函数，但是不通过 fn 进行定义。在 Rust 中，并不把这个闭包的类型处理成 fn 这种函数指针类型，而是有单独的类型定义。 切记这里是将闭包处理成是 单独的类型定义，这一点区别与其它开发语言。 至于按哪一种类型来处理，这个没有办法得知，因为只有在Rust编译器在编译的时候才可以确定其类型，并且在确定类型时，还需要根据这个闭包捕获上下文环境变量时的行为来确定。 闭包trait分类 根据闭包行为划分为三类trait（ 主因是受到所有权影响）： FnOnce 适用于能被调用一次的闭包，所有闭包都至少实现了这个 trait，因为所有闭包都必须能够被调用。一个会将捕获的值移出闭包体的闭包只实现 FnOnce trait，这是因为它只能被调用一次。其获取了上下文环境变量的所有权。 FnMut 适用于不会将捕获的值移出闭包体的闭包，但它可能会修改被捕获的值，这类闭包可以被调用多次。其只获取了上下文环境变量的 &mut 引用。 Fn 适用于既不将被捕获的值移出闭包体也不修改被捕获的值的闭包，当然也包括不从环境中捕获值的闭包。这类闭包可以被调用多次而不改变它们的环境，这在会 多次并发调用闭包的场景中十分重要。其只获取了上下文环境变量的 & 不可变引用。 在编译时会将闭包确定为以上三种类型中的一种或多种组合。 Rust 给我们暴露了 FnOnce、FnMut、Fn 这 3 个 trait，就刚对应上面这三类数据类型。 它们在标准库中的定义为 trait FnOnce<Args> { type Output; fn call_once(self, args: Args) -> Self::Output; } trait FnMut<Args>: FnOnce<Args> { fn call_mut(&mut self, args: Args) -> Self::Output; } trait Fn<Args>: FnMut<Args> { fn call(&self, args: Args) -> Self::Output; } 注意这三者的关系，其中 Fn 继承了 FnMut ，而 FnMut 又继承了 FnOnce，它们三者有层次关系的。