Network

在 Kubernetes 集群中，Service 是核心资源之一，其中 LoadBalancer 类型服务是业务对外暴露的核心方式。但原生 K8s 仅为公有云集群（AWS、阿里云、腾讯云等）提供 LoadBalancer 实现，裸金属、本地机房、私有部署的 K8s 集群默认不支持 LoadBalancer 类型 Service，只能依赖 NodePort、Ingress 实现流量暴露，存在端口散乱、运维复杂、无统一入口、负载均衡能力薄弱等问题。 MetalLB 正是这样一款专为私有/裸金属K8s集群设计的开源负载均衡组件，完全开源免费、轻量无侵入，完美补齐了私有 K8s 集群无原生 LoadBalancer 的短板，是本地机房 K8s 生产集群的标配组件。 1. 项目介绍 1.1 项目定位与核心作用 MetalLB 是 Kubernetes官方认可的负载均衡解决方案，专为非云环境（裸金属服务器、虚拟机、本地私有集群）设计。其核心作用是：为集群内 LoadBalancer 类型的 Service 自动分配外部静态 IP，实现四层流量负载均衡，替代原生 NodePort 的低效暴露方式，让私有集群拥有与公有云一致的 Service 负载均衡能力。 核心价值： 统一业务暴露方式：与公有云 K8s 开发规范对齐，无需适配 NodePort 特殊逻辑。 稳定四层负载均衡：支持 TCP/UDP 协议，适配后端服务、数据库、中间件等各类业务。 简化运维：固定服务外部 IP，无需节点端口映射，流量入口统一可控。 轻量高性能：无复杂依赖，资源占用极低，不侵入 K8s 核心组件。 1.2 架构原理 MetalLB 采用控制器 + 转发节点的分布式架构，整体由两大核心组件组成，全部运行在集群内部，以 Pod 形式部署。 1.2.1 Controller（控制器组件） 全局唯一的调度组件，默认单副本部署，核心职责： 监听集群内所有 LoadBalancer 类型的 Service 资源变更。 维护 IP 地址池，为新的 LoadBalancer Service 自动分配可用外部 IP。 回收废弃 Service 的 IP 资源，避免 IP 泄露与占用。 校验 IP 分配合法性，保证全局唯一性。 1.2.2 Speaker（转发组件） 集群节点级组件，默认每个集群节点部署一个Pod（DaemonSet部署），核心职责： ...

Kubernetes 的网络是一个多层虚拟网络体系，流量从客户端到后端 Pod 的路径涉及多个组件。排查网络问题时，如果"东戳一下西戳一下"没有章法，可能需要耗费大量时间。如何最快的定位网络问题的根源？记住常见的具体现象和应对办法，遵循从内到外的原则（先确认"自己没问题"，再确认"中间没问题"，最后确认"外面没问题"）或许能够帮你节约大量的时间，。 下面按照从具体访问现象出发的思路，由浅入深展开。 1. 第一层：Pod 自身状态确认 现象：Pod 完全无法访问，任何请求都无响应 这是最基础的一层。在排查任何网络问题之前，先确认 Pod 本身是否健康运行。 1.1 检查 Pod 状态 kubectl get pods -o wide 关注以下状态： 状态 含义 可能原因 Running 正常运行 正常 Pending 等待调度 资源不足、节点亲和性不匹配 CrashLoopBackOff 反复崩溃重启 应用启动失败、配置错误 OOMKilled 内存超限被杀 resources.limits.memory 设置过低 ImagePullBackOff 镜像拉取失败 镜像名错误、仓库认证失败 ContainerCreating 容器创建中 CNI 插件分配 IP 失败、存储卷挂载失败 如果 Pod 不在 Running 状态，网络问题只是表象，根因在 Pod 本身： # 查看 Pod 详细事件 kubectl describe pod <pod-name> -n <namespace> # 查看容器日志（如果容器曾启动过） kubectl logs <pod-name> -n <namespace> # 查看前一个崩溃容器的日志 kubectl logs <pod-name> -n <namespace> --previous 1.2 确认 Pod 有 IP 地址 kubectl get pods -o wide 如果 Pod 状态是 Running 但 IP 为空，说明 CNI 插件没有成功分配 IP。此时需要检查： ...