大家好！欢迎各位探索Kubernetes网络世界的朋友。🚀
您是否刚刚安装了当下最热门的CNI(Container Network Interface)——Cilium？或者正在考虑安装它？被Cilium强大的eBPF性能和功能所吸引并完成安装后，您可能会突然产生这样的疑问：
“我的Pod到底是如何获取IP地址的？Cilium是自动处理的吗？”
是的，没错！Cilium确实是自动处理的。但这种“自动处理”的方式也有多种！而且Cilium采用了最普遍和稳定的方式作为默认值(Default)。今天，我们就来揭开这种默认方式的真面目，并深入探讨为什么选择这种方式而非其他方式作为默认的深层原因。
🕵️♂️ 罪魁祸首就是… Kubernetes Native IPAM！
如果您在没有进行特殊配置的情况下，通过Helm等工具安装了Cilium，那么您的集群有99%的概率正在以Kubernetes Native IPAM模式，即ipam: kubernetes模式运行。
这到底意味着什么呢？我们来用一个非常简单的比喻。
想象一下，有一个巨大的“新城市”叫做Kubernetes集群。🏙️
>
新城市规划总管 (Kubernetes Control Plane)：在规划新城市时，会为每个社区(Node)预先分配居民(Pod)可以使用的地址范围(PodCIDR)。比如，“A社区使用10.1.1.0-255的地址”，“B社区使用10.1.2.0-255的地址”。
>
社区管理员 (Cilium Agent)：派驻到各个社区的管理员(Cilium Agent)会确认总管部下发的本社区地址范围。
>
1. 入住申请 (Pod创建)：当有新居民(Pod)搬入A社区时，A社区管理员(Cilium)会分配一个空闲的地址(IP)，比如“10.1.1.10”给它！
也就是说，Cilium并非独立管理IP地址范围，而是直接使用Kubernetes已经为每个节点(Node)分配的IP地址范围(PodCIDR)，并在其中为Pod分配IP。Cilium就像是在Kubernetes准备好的饭桌上添了一双筷子，这是一种非常明智且高效的方法！😄
那么，我们亲自确认一下吧？
让我们直接查看您的集群节点被分配了哪些IP地址范围(PodCIDR)。请在终端中输入以下命令：
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"t"}{.spec.podCIDR}{"
"}{end}'然后您会看到类似以下的结果：
# 输出结果示例
master-node 10.244.0.0/24
worker-node-1 10.244.1.0/24
worker-node-2 10.244.2.0/24看到了吗？Kubernetes的kube-controller-manager公平地为每个节点分配了/24大小的IP地址范围。
当Pod在worker-node-1上创建时，Cilium会在10.244.1.0/24范围内寻找并分配一个空闲的IP。所有这些信息都记录并管理在名为CiliumNode的CRD(Custom Resource Definition)中。
🤔 那么，为什么其他方式不是默认值呢？
Cilium除了kubernetes模式外，还支持多种IPAM方式。通过其主要竞争对手cluster-pool模式，我们可以反过来理解为什么kubernetes模式被选为默认值。
❌ Cluster Pool IPAM (ipam: cluster-pool)
这种方式是Cilium自行管理一个巨大的IP地址池的方式。
我们再回到新城市的比喻。🏙️
>
新城市规划总管(Kubernetes)不再为每个社区分配地址范围。取而代之的是，Cilium这个专业的房地产开发商宣称：“这个新城市的所有IP都由我来管理！10.10.0.0/16这个范围都是我的！”然后，它会根据需要，将IP地址范围一点点地分配（Delegation）给各个社区(Node)。
优点:
- 在非云环境或不希望依赖Kubernetes的PodCIDR分配功能时非常有用。
- 可以更灵活、更精细地控制IP地址范围。
缺点 (以及为什么不是默认值):
- 需要额外配置！ 😭 用户必须在Cilium配置文件中明确指定整个集群将使用的IP地址范围(clusterPoolIPv4PodCIDRList)。
# Helm values.yaml 示例
ipam:
mode: cluster-pool
operator:
clusterPoolIPv4PodCIDRList: ["10.10.0.0/16"]- 默认值的理念是“最简单、最直观、无需额外配置(zero-config)即可良好运行”。cluster-pool方式与此理念相悖。最大限度地利用Kubernetes的默认功能更符合“Kubernetes原生”的理念，并为用户提供便利，因此kubernetes模式被选为默认值。
☁️ 云专用 IPAM (AWS ENI, Azure IPAM 等)
在AWS、GCP、Azure等云环境中，也有利用相应云提供商的原生网络功能来分配IP的模式。例如，AWS ENI模式可以直接将EC2的辅助IP分配给Pod，从而实现卓越的性能。
不是默认值的原因:
- 原因很明确。这些方式依赖于特定的云平台。🔗
- Cilium的默认值必须在任何环境（本地部署、所有云、本地开发环境等）中普遍适用。因此，通用性最佳的kubernetes模式占据了默认值的位置。
🖼️ 从大局理解：为什么这很重要？
了解各个IPAM模式固然重要，但理解Cilium为何提供这些选项的整体背景才是关键。
| IPAM 模式 | 核心思想 | 优点 | 缺点/特点 |
|---|---|---|---|
| Kubernetes (默认) | “信任并遵循 Kubernetes！” | 安装后立即运行，无需额外配置，最标准化 | 依赖 Kubernetes 的 PodCIDR 分配能力 |
| Cluster Pool | “IP 管理由 Cilium 直接负责！” | 灵活的 IP 地址范围管理，摆脱 K8s 依赖 | 用户需要手动配置 IP 地址范围 |
| Cloud-Specific | “在此云环境中，此方法最佳！” | 最大化云原生性能 | 依赖于特定云，通用性不足 |
最终，Cilium 的默认策略是“简单与集成”。它提供了一种作为 Kubernetes 生态系统成员最自然融入的方式作为默认，并为有更特殊需求的高级用户开放了其他强大的选项。
✨ 总结
今天，我们深入探讨了 Cilium 为 Pod 分配 IP 地址的默认方式——Kubernetes Native IPAM。现在，安装 Cilium 后，您将能够自信地解释您的 Pod IP 来自何处，以及为什么选择这种方式作为默认。
在大多数情况下，此默认配置运行得非常好。但是，如果您的集群环境有特殊要求，那么今天我们一起探讨的其他 IPAM 选项也将是下一步的绝佳选择！
发表回复