Kubernetes负载均衡新方案，告别云厂商依赖，实现动态DNS与高效流量分发

在最近几个月，开源社区和云原生领域对于简化Kubernetes负载均衡的讨论越来越热烈。2024年4月，一个名为OpenELB的开源项目发布了v0.8.0版本，重点增强了在裸金属和边缘计算环境下的负载均衡能力，用户无需依赖特定云平台的负载均衡器服务。与此同时，另一个流行的工具ExternalDNS也在持续更新，更好地支持了将Kubernetes服务与自管理的DNS服务器进行集成，这为构建不依赖云厂商的方案提供了更多可能。

为什么需要新的负载均衡方案

许多公司在使用Kubernetes时，通常会直接使用云服务商提供的负载均衡器，比如AWS的ELB、Google Cloud的Load Balancer或者Azure的Load Balancer。这些服务虽然方便，但也带来了一些问题。首先，费用不低，尤其是当服务数量增多时，每个服务都配一个云负载均衡器，成本会快速上升。其次，用户被牢牢绑定在了一家云服务商身上，如果想迁移到其他云或者自己的数据中心，会非常困难。最后，云厂商的负载均衡器有时反应不够快，当Kubernetes中的应用实例发生扩缩容或者故障转移时，负载均衡器的更新可能会有延迟，影响流量切换。

动态DNS与内部负载均衡器结合

新的方案核心思路是，不再把外部流量直接交给云厂商的负载均衡器，而是用一个运行在Kubernetes集群内部的负载均衡器来接收流量。这个内部的负载均衡器可以是一个像MetalLB这样的软件，它能在集群内分配IP地址，并对外宣告这些地址。对于裸金属集群，MetalLB可以通过ARP或BGP协议让路由器知道该把去往某个IP的流量发送到哪个节点。与此同时，配合一个动态DNS工具，比如ExternalDNS。当Kubernetes中的服务创建或发生变化时，ExternalDNS会自动更新DNS记录，将用户自定义的域名指向内部负载均衡器分配的那个IP地址。这样，用户访问域名时，DNS解析结果就是集群内部的负载均衡IP，流量直接到达集群节点，不再经过云厂商的网关。整个过程是自动的、动态的，实现了高效的流量分发。

实现高效流量分发的关键组件

要搭建这样一个不依赖云厂商的系统，需要几个关键部分协同工作。第一部分是负载均衡器实现，如前面提到的MetalLB，它负责提供“负载均衡器”的抽象，并管理外部IP。第二部分是动态DNS控制器，如ExternalDNS，它监视Kubernetes的Ingress或Service资源，并与DNS服务商（可以是自建的如CoreDNS，也可以是外部服务如Cloudflare）的API通信，实时更新A记录或CNAME记录。第三部分是集群内的Ingress控制器，例如NGINX Ingress Controller或Traefik。它接收到达内部负载均衡器IP的HTTP/HTTPS流量，并根据域名和路径规则将流量分发给后端的正确Pod。这三个部分一起，形成了一个闭环：服务发布时，MetalLB分配IP，ExternalDNS更新域名指向此IP，用户流量到达后，Ingress控制器进行最终分发。这比传统方案更灵活，成本更低，且避免了供应商锁定。

带来的好处与需要注意的地方

采用这种新方案，最直接的好处是降低了成本，特别是对于拥有大量服务的集群。其次，它提高了可移植性，无论是在公有云、私有云还是混合环境中，只要网络可达，方案都能工作，这使得多云和混合云策略更容易实施。此外，因为DNS更新和负载均衡配置都在Kubernetes控制平面内自动完成，所以对应用扩缩容和故障的反应更快，提升了系统的整体弹性。当然，这也有需要注意的地方。例如，自管理DNS和负载均衡器需要一定的运维知识，尤其是在处理BGP等网络协议时。在高安全要求的环境中，需要仔细配置网络策略，确保只有允许的流量能到达内部负载均衡器。而且，DNS缓存的存在意味着服务IP变更后，全球DNS生效会有延迟，在设计应用时需要考虑到这一点，例如通过设置较短的TTL来缓解。

引用来源：1. MetalLB官方项目文档与发布说明（https://metallb.universe.tf/）。2. ExternalDNS项目GitHub仓库与使用指南（https://github.com/kubernetes-sigs/external-dns）。3. Cloud Native Computing Foundation (CNCF) 关于Kubernetes负载均衡模式的讨论与博客文章。4. 开源项目OpenELB在GitHub上的发布日志（https://github.com/openelb/openelb/releases）。