基于K8s的云原生AI基础设施：架构、部署与实践【006】-AI算力的基础脉络

在前面的章节中，容器平台、镜像仓库以及多租户边界已经逐步搭建起来。

但对于一个真正可运行的 Kubernetes 集群来说，这些能力还只是基础设施的一部分。因为无论是控制面组件、系统 DaemonSet，还是后续模型服务、训练任务和租户工作负载，最终都要建立在一张稳定可用的集群网络之上。

在 Kubernetes 中，Pod 并不是孤立运行的。它们需要跨节点互通，需要通过 Service 被访问，需要依赖 CoreDNS 解析服务地址，也需要与控制平面和节点组件维持正常通信。如果这一层网络本身没有打通，那么后续无论是多租户、镜像分发、监控采集，还是更复杂的多网络和高性能网络能力，都无从谈起。

也正因为如此，在进入更复杂的网络方案之前，首先需要把集群最基础的一张 Pod 网络搭起来。这一章要讨论的，正是这张基础网络底座，以及 Flannel 在这一层究竟解决了什么问题。

1. 为什么 AI 集群首先需要一张基础网络

对于 Kubernetes 而言，Pod 网络不是一个可有可无的附加能力，而是整个平台运行的基本前提。原因很直接，因为 Kubernetes 中大量基础能力都天然依赖网络：

  • Pod 之间需要直接通信；
  • Pod 需要访问 Service；
  • Service 需要借助 DNS 进行名字解析；
  • 节点上的系统组件需要与控制平面保持连接；
  • 监控、日志、探针和 Webhook 等能力也都依赖底层网络链路。

在 AI 场景下，这一点只会更加明显。无论是模型服务实例之间的互访、训练任务中的组件通信，还是镜像拉取、指标采集和租户工作负载的服务暴露，本质上都要求集群首先具备一张稳定、可预期的基础 Pod 网络。

如果这一层本身就不稳定，那么后续更复杂的网络能力——例如多张网卡和高性能网络——不仅没有意义，反而会让问题更难定位。因此，在 AI 算力平台建设中，基础网络不是“后面再补”的模块，而是所有上层能力得以运行的前提条件。

2. Flannel 解决的是什么问题

在 Kubernetes 中，基础网络首先要回答的是一个很朴素的问题：集群中的 Pod，如何在跨节点场景下仍然能够彼此通信。从 Kubernetes 的设计出发，Pod 网络通常有几个基本要求：

  • 每个 Pod 都应拥有独立 IP；
  • Pod 之间在默认情况下应能够直接互通；
  • 不同节点上的 Pod 也应能够跨节点通信；
  • 节点和 Pod 之间的流量路径应尽量可预测、可维护。

而 Flannel 所做的事情，本质上就是为这套要求提供一个相对简单的实现。

它通过为每个节点分配 Pod 网段，并在节点之间建立覆盖网络或路由转发机制，使不同节点上的 Pod 能够完成互通，从而为 Kubernetes 提供最基础的容器网络能力。从这个角度看，Flannel 的定位不是“高级网络方案”，而是一层基础网络底座。它解决的是：先让 Pod 网络跑起来，先让集群具备最基本的跨节点通信能力。

3. 为什么这里先选 Flannel

在 Kubernetes 的 CNI 生态中，Flannel 和 Calico 都是非常常见的选择，但它们的定位并不完全相同。Flannel 更强调提供简单、直接的基础 Pod 网络能力，而 Calico 除了网络连通之外，还进一步提供 NetworkPolicy 以及更强的安全与可观测能力。

因此，这里选择 Flannel，并不是因为它代表了网络体系的最终形态，而是因为当前阶段首先要解决的是更基础的问题：先让 Kubernetes 集群具备一张稳定、可工作的 Pod 网络，让节点进入 Ready，让不同节点上的 Pod 可以跨节点互通。在这个目标下，Flannel 作为基础网络底座是足够合适的起步方案。

而对于 AI 算力平台来说，基础 Pod 网络和真正的算力网络并不是同一层能力。Flannel 解决的是前者；后续涉及多网络接入、租户专属网络以及 RDMA / RoCE 等高性能通信能力，则属于后续网络体系建设的范围。

4. Flannel 的部署与基础验证

在明确了 Flannel 的定位之后，接下来就进入实际部署。

这一部分的目标比较明确：先把 Flannel 安装到集群中，让 Kubernetes 真正具备基础 Pod 网络能力，然后完成最基本的安装结果检查和网段一致性验证。

# 安装 Flannel
kubectl apply-f kube-flannel.yml

# 检查 DaemonSet 和 Pod 状态
kubectl-n kube-flannelget ds kube-flannel-ds-o wide
kubectl-n kube-flannelget pods-o wide

# 如果修改了默认 pod CIDR，Flannel 配置也需要同步修改
# net-conf.json:
# {
#   "Network": "10.86.0.0/16",
#   "EnableNFTables": false,
#   "Backend": {
#     "Type": "vxlan"
#   }
# }

# 确认 Flannel 使用的网段与 kubeadm 初始化时保持一致
kubectl-n kube-flannelget cm kube-flannel-cfg-o yaml |grep-n'"Network"'

# 确认节点的 Pod CIDR
kubectlget nodes-ocustom-columns=NAME:.metadata.name,PODCIDR:.spec.podCIDR

这里需要重点关注两件事：

第一，Flannel 相关 Pod 和 DaemonSet 是否已经正常拉起；

第二，Flannel 配置中的 Pod 网段是否与集群初始化时的 pod-network-cidr 保持一致。

如果两者不一致，那么即使网络组件已经启动，后续 Pod 通信也可能出现问题。

5. 小结

Flannel 能够较好地解决 Kubernetes 集群的基础 Pod 网络问题，但它的定位始终是一层“基础网络底座”，而不是完整的 AI 网络方案。

它的价值在于先把最基本的 Pod 通信路径打通，让集群具备继续运行和演进的前提条件。

但对于 AI 算力平台来说，后续还会出现更复杂的网络诉求，例如多网络接入、租户专属网络，以及面向高性能通信的 RDMA / RoCE 网络。

这些能力都超出了 Flannel 本身的边界，也正是后续网络章节要继续展开的内容。也就是说，Flannel 的意义不在于“网络建设到此为止”，而在于：先把基础网络底座打稳，再继续向更复杂的网络能力演进。

Leave a Reply