Kubernetes Ingress 原理

阅读本文前提条件：理解 k8s Service 的大致原理；会照猫画虎地使用 Ingress。

原理概述

Service 可以供内部程序使用，若不在路由设备上配置相应规则，外部节点无法访问 Service 的 IP 或某 Pod 的 IP。

一个比较容易想到的办法是：既然 Pod 可以访问集群内的 Service，那就让几个 Pod 监听几个宿主机的端口，让这些 Pod 把流量转发到集群里面去。

具体来说：挑几个节点（记为 A、B、C），通过 nodeSelector 在这些节点上运行一个 DaemonSet，该 DaemonSet 的 Pod 配置 hostPort 字段绑定宿主机端口（例如 80）。

这样一来，外部程序访问 A、B、C 的 80 端口时，Pod 中运行的程序（如 nginx、HAProxy）就可以根据某种规则把流量转发给特定 Service。

其实，这已经是 Ingress 的原理了。

Ingress 也是 k8s 的一个 API 对象，但 IngressController 不是。IngressController 的存在形式可以是 Deployment 或 DaemonSet，也可以是某个 Operator 所控制的一组 Pod，总之是若干持续运行的 Pod。通常来说，Pod 中会运行一个有反向代理功能的程序（如 nginx）的容器，再运行一个容器（记为 c1）监视 Ingress 的变化，当 Ingress 改变时修改方向代理程序的配置文件。以 nginx 为例，c1 感知到 Ingress 变化后，修改 nginx.conf 并重启 nginx。当然了，如果反向代理程序原生支持监视 Ingress 并热更新自己的配置，那就不用 c1 了。

一般来说，小集群情形，可以将 IngressController 部署为 DaemonSet 并运行在所有节点上。

大集群情形，可以将 IngressController 部署为 DaemonSet，并通过污点、容忍、nodeSelector 让 IngressController 独占一些节点。

将 IngressController 部署为 Deployment 不太多见，因为 Pod 的停靠点不好控制。

Ingress 与 NodePort 类型的 Service 的区别

为简便，记 np-svc 为 NodePort 类型的 Service。

np-svc 只能转发 L4 流量，Ingress 可以转发 L7，如果自定义类似于 Ingress 的 CRD 并开发相应的 IngressController，还可以转发自定义协议的流量。

np-svc 会让所有的节点监听端口，Ingress 可以规划、选择节点。