IngressController 高可用方案

流量从入口到 Ingress Controller Pod 存在如下几种方式:

  • Type 为 LoadBalancer 的时候,通过 externalIPs。
  • Type 为 LoadBalancer 的时候,通过云厂商的 LB 来负载均衡,并且支持自动分配公网 IP。通过 LoadBalancer 暴露的每个服务都会获得一个公网 IP,缺点是需要额外收费,且自己在云上搭建的 Kubernetes 无法使用。
  • 不创建 Service,Pod 直接用 HOSTPORT,与 hostNetwork 功能类似,如果代理的四层服务,如 mysql,需要修改 Pod 的 template 来滚动更新,让 Nginx Bind 的四层端口能映射到宿主机上。
  • Type 为 NodePort,流量通过它负载进来,但是不在 Ingress Controller Pod 所在的 Node 上,会从这个 Node 上的 kube-proxy 转发到 Ingress Controller 的 Pod 上。

综上所述,不创建 Service 的效率最高,负载四层的时候也不用修改 Pod 的 template。在 hostNetwork 模式下,Pod 会继承宿主机的网络协议,继承宿主机的 DNS,导致 Service 的请求直接走宿主机上的公网 DNS 服务器,而不是集群内部的 DNS 服务器,需要将 Pod 的 dnsPolicy 设置为 ClusterFirstWithHostNet 即可解决。

高可用的部署方式一般有两种:

  • DS + nodeSelector
  • Deploy(设置 repicas)+ nodeSelector + Pod 反亲和性
  • 线下使用 VIP 飘在存活的 Ingress Controller Pod 的宿主机上,云上使用 SLB 代替 VIP,有条件直接上硬件负载均衡,例如 F5 等。
  • Nginx ingress 不创建 Service 的时候,会一直报 warning 告警日志,对机器是一直没必要的额外负载,可以随便创建一个同名 Service,不带 标签选择器和 ClusterIP 为 null 即可。
  • 关于域名请求,如果部署在公司局域网,内部有 DNS Server 的话,域名解析到 Ingress Controller 的宿主机 IP,或者 VIP、LB 的 IP,否则需要修改每个人电脑的 /etc/hosts 文件。如果没有 DNS Server 的可以运行一个 external-dns,它的上游 DNS 是公网的 DNS 服务器,局域网内电脑的 DNS Server 指向它即可,云上的话把域名请求解析到对应的 IP 即可。
-------------本文结束感谢您的阅读-------------