Nginx Ingress 控制器工作机制

Ingress controller 的目标是构造配置文件（nginx.conf）。这个需求的主要含义是在配置文件有任何变更后都需要重新加载 NGINX。不过需要特别注意的是，在只有 upstream 配置变更的时候我们不需要重新加载 Nginx（即当你部署你的应用时 Endpoints 变更）。我们使用 lua-nginx-module 达到这个目的。请通过 下面的内容 来学习我们如何做到这一点。

通常，一个 Kubernetes 控制器采用 synchronization loop pattern 来检查控制器中所需的状态是否已更新或者需要变更。为了达到这个目的，我们需要使用集群的不同对象来构建模型，特别是（无特殊顺序）Ingresses，Services，Endpoints，Secrets，以及 Configmaps 来生成反映集群状态的时间点配置文件。

为了从集群获取这些对象，我们使用 Kubernetes Informers ，特别是 FilteredSharedInformer 。当一个新的对象添加、修改或者移除的时候，informers 允许通过 callbacks 针对单个变更进行响应。不幸的是，没有办法知道一个特定的变更是否会影响最终的配置文件。因此在每次变更时，我们都必须基于集群的状态重新构建一个新模型，并将其和当前的模型进行比较。如果新模型等于当前模型，那么我们就可以避免生成新的 NGINX 配置并触发重新加载。相反的，我们只通过 Endpoints 检查不同。如果这样我们使用 HTTP POST 请求一个新的 Endpoints 列表发送给运行在 Nginx 中的 Lua 程序并且避免重新生成一个新的 NGINX 配置以及触发重新加载。如果运行的模型和当前的差异不仅仅是 Endpoints，我们则基于新的模型创建一个新的 NGINX 配置文件，替代当前的模型并触发一次重新加载。

该模型的用途之一是状态没有变化时避免不必要的重新加载，并检测定义中的冲突。

生成 NGINX 配置的最终画像是从一个 Go template，针对这个模板所需要的变量通过新的模型输入。

建立模型是一项成本比较高的操作，基于这个原因，使用同步循环是必须的。通过使用 work queue，可以不丢失变更并通过 sync.Mutex 移除来强制执行一次同步循环，此外还可以在同步循环的开始和结束之间创建一个时间窗口，从而允许我们摒弃不必要的更新。重要的是要理解，集群中的任何变更都会生成事件，然后 informer 会发送给控制器，这也是使用 work queue 的原因之一。

建立模型的操作方式：

• 通过 CreationTimestamp 字段对 Ingress 规则排序，即最早创建的规则优先
• 如果相同 host 的相同路径被多个 Ingress 定义，那么最早创建的规则优先
• 如果多个 Ingress 包含相同 host 的 TLS 部分，那么最早创建的规则优先
• 如果多个 Ingresses 定义了一个 annotation 影响到 Server block 配置，那么最早创建的规则优先
• 创建一个 NGINX Servers 列表（每个主机名）
• 创建一个 NGINX Upstreams 列表
• 如果多个 Ingresses 定义了同一个 host 的不同路径，ingress 控制器会合并这些定义
• Annotations 被应用于这个 Ingress 的所有路径
• 多个 Ingresses 可以定义不同的 annotations。这些定义不会在 Ingresses 之间共享

接下来的场景描述什么时候需要重新加载：

• 新的 Ingress 资源创建
• 添加 TLS 部分到现有的 Ingress
• 变更 Ingress annotations 并不仅仅影响 upstream 配置。对于实例 load-balance annotation 不需要重新加载
• Ingress 的路径被添加/移除
• 一个 Ingress，Service、Secret 被移除
• 一些 Ingress 缺少引用的对象可用时，如 Service 或者 Secret
• 一个 Secret 被更新

在某些情况下，有可能避免重新加载，尤其是在 endpoints 发送变化的时候，如 pod 启动或者被替换时。完全移除重新加载这超过了 Ingress 控制器的范围。这将需要大量的工作，并且有时没有任何意义。仅当 NGINX 变更了读取新配置的方式时，这才可以变更，基本上，新的变更不会替代工作进程。