面向公网Web应用的Kubernetes DNS与Ingress Controller配置及高可用问题

嘿，针对你提到的Ingress和Ingress Controller的部署疑问，我来结合你的集群环境一步步拆解：

问题1：单节点Ingress Controller是否会让前端Service的负载均衡失效？多节点部署是否是最佳实践？ #

• 单节点Ingress Controller不影响前端Service的内部负载均衡：
  你得明白，前端Service的负载均衡是作用于Pod层面的——Ingress Controller本质是作为一个客户端，向前端Service发起请求，Service会通过kube-proxy的iptables/ipvs规则，把请求均匀转发到两个前端Pod上。哪怕Ingress Controller只在worker1上跑，它每次发的请求还是会被Service分配到不同的Pod，所以前端Service的负载均衡功能完全没失效，只是Ingress Controller本身成了单点故障点。
• 多节点部署Ingress Controller是高可用的最佳实践：
  推荐用DaemonSet来部署Ingress Controller，让每个Worker节点都运行一个实例（可以通过污点/容忍度排除不需要的节点）。这样一来，不管哪个Worker节点故障，其他节点上的Ingress Controller都能继续处理流量，从根源上避免单点问题。如果不想每个节点都跑，也可以用Deployment多副本+节点亲和性，把实例分布到不同的Worker节点上，同样能实现冗余。

问题2：Ingress Controller节点故障后的DNS问题，以及无共享IP的高可用方案 #

节点故障后的DNS更新问题 #

如果你的Ingress Controller是用Deployment部署的，故障后被调度到其他节点，入口IP确实会变，这时候手动更新DNS肯定不现实。解决这个问题有几种思路，不一定需要感知K8s的DNS服务器：

1. 用DaemonSet+DNS轮询：
   既然你的三个Worker节点都有公网IP和DNS记录，那可以用DaemonSet在每个Worker节点部署Ingress Controller，然后把www.domain.tld设置为多条A记录，指向worker1、worker2、worker3的公网IP。这样DNS会做轮询，当某个节点故障，客户端会自动尝试其他IP，无需手动更新DNS。
2. 用虚拟IP漂移（裸金属推荐MetalLB）：
   如果你不想用DNS轮询，可以部署MetalLB（一个裸金属K8s的LoadBalancer实现），把Ingress Controller的Service类型设为LoadBalancer。MetalLB会分配一个虚拟的公网IP，这个IP会绑定到运行Ingress Controller的节点上，当节点故障时自动漂移到其他可用节点。你只需要把www.domain.tld的CNAME指向这个虚拟IP的DNS记录（或者直接设A记录），就不用管节点IP的变化了。
3. 云环境用外部LoadBalancer：
   要是你的集群在云厂商上，直接把Ingress Controller的Service设为LoadBalancer，云厂商会自动创建一个外部LB，把流量转发到所有Ingress Controller实例。这时候www.domain.tld只需要指向LB的域名即可，完全不用关心后端节点的变化。

无共享IP的高可用最佳方案 #

DNS轮询就是一种非常成熟的无共享IP方案，配合DaemonSet部署的Ingress Controller，每个节点都有独立的公网IP，DNS返回所有IP，客户端会自动进行故障转移。另外，你也可以结合HTTP层面的健康检查（比如Ingress Controller自带的健康端点），让DNS服务器自动剔除不可用的IP（不过这需要你的DNS服务器支持健康检查，比如PowerDNS或者某些云厂商的DNS服务）。

内容的提问来源于stack exchange，提问作者Jens Kohl