NGINX Ingress Controller 设计原理
ingress controller 如何工作
这篇文档的目的是解释 nginx ingress 控制器是如何工作的，特别是 nginx 模型的构建以及为什么需要它。
Nginx 配置
nginx ingress 控制器目标是组织 nginx 配置文件， 当 nginx 的配置文件发生任何更改时都需要重新加载，当配置文件中upstream 的内容有变更时(例如 当部署的应用中的 endpoints 变更时)， nginx 的配置文件不会被重新加载，我们使用 ngx_http_lua_module 模块完成 endpoints 的变更，请继续往下看是如何操作的。
nginx 模型
通常来说，k8s 控制器利用同步循环模式去检查控制器中资源的变更或者更新，为了达到这个目的，我们需要使用来自集群中不同的对象来构建一个模型，特别是(没有顺序要求) ingresses、Services, Endpoints, Secrets, and Configmaps 来生成一份和时间点相关的配置文件用来反映集群的状态。为了从集群中获取对象，我们使用 Kubernetes Informers 特别是FilteredSharedInformer，Informers 允许通过回掉机制对每一个独立的资源对象在添加、删除、更新时做出相关的反映，不幸的是，没有一种方式能够知道 nginx 的配置文件中具体哪一处发生了变化，因此，当每次发生变更时，我们不得不重新构建一次完成的配置模型与当前正在运行的模型进行比较，如果新的模型和当前的相等，那就避免生成新的配置从而去触发 nginx 重载，除此之外，我们检查如果仅仅是 Endpoints 不一样， 我们发送一个 HTTP POST 到 lua 处理模块，它运行在 nginx server 内部，从而避免重新生成新的配置触发 nginx 重新加载，如果新的配置模型和正在运行的模型比较后不仅仅是 Endpoints 不一样，那么就基于新的配置模型生成配置文件替换正在运行的配置文件触发 nginx 重新加载，
利用模型一是为了避免不必要的 reload 发生再一个是为了检查配置的定义冲突。
nginx 的最终配置文件来源于 Go template， 利用新的模型作为模版的需要的变量。
构建 nginx 模型
构建模型是一个昂贵的操作，由于这个原因，使用同步循环是必须的，通过使用 work queue 可以避免变更丢失，同时去掉 sync.Mutex的使用，额外的在循环开始和循环结束时创建时间窗允许丢弃不必要的更新，很重要的一件事情是集群中的任何变更都会都过 informer 发送到控制器中，这也是使用 work queue 的一个原因。
构建模型步骤
- 通过CreationTimestamp 字段对 ingress 规则进行排序，比如 旧规则优先
- 如果在多个 ingress 中相同主机的的相同路径被定义，最后的定义生效
- 如果多个 ingress 包含了相同主机的相同 TLS 部分内容，最后的定义生效
- 如果多个 ingresses 定义的一个注解影响了 server 部分的配置，那么最后的定义生效
- 创建 nginx servers 的列表(每一个主机)
- 创建 nginx upstreams 列表
- 如果多个 ingresses 定义了同一个主机的不同路径，ingress controller 会降这些定义合并
- 注解会被应用到 ingress 中所有的路径
- 每一个 ingresses 可以定义不同的注解，这些注解不会被共享
什么时候需要 reload
以下列表描述了需要 reload 的场景
- 新的 ingress 资源被创建
- TLS section 添加到已经存在的 ingress 中
- 更改 ingress 的注解不仅仅影响到了 upstream 的配置，例如 load-balance 注解更改不需要执行 reload 操作
- 从 ingress 中添加或者移除路径
- 移除 Ingress, Service, Secret
- 一些缺失的对象从 ingress 中可以获得，比如 Service 或者 Secret
- Secret 被更新
避免 reload
某种情况下应该避免 reload， 特别是 endpoints 的变更， 比如 pod 的启动或者替换，完全删除重新加载超出了Ingress 控制器的范围。这将需要大量工作，并且在某些时候没有任何意义。 仅当 NGINX 更改了读取新配置的方式时，这才可以更改，基本上，新的更改不会替代工作进程
避免 reload 当 Endpoints 变更时
当每一次 endpoint 变更时，控制器能够从看得见的 services 中获取 endpoints，生成相关的后端对象，然后将这些对象发送到运行在 ngixn 内部的 lua 处理模块中， Lua 代码反过来将这些对象存储在共享内存区域， 每一次请求到来时 balancer_by_lua 会通过配置的负载均衡算法选择一个后端对象来处理，nginx 则关心其余的事情，这种方式避免了当 endpoint 变化时发生 reload，注意当 upstream 的注解发生变更时也会避免发生 reload。
在具有频繁部署应用程序的相对较大的群集中，此功能可以节省大量 Nginx 重载，否则会影响响应延迟，负载均衡质量（每次重载 Nginx 都会重置负载平衡状态）等等
vi设计http://www.maiqicn.com 办公资源网站大全https://www.wode007.com
避免错误配置导致中断
因为 ingress 制器使用同步循环工作模式，所以它将配置应用于所有匹配的对象。如果某些 Ingress 对象的配置损坏，例如nginx.ingress.kubernetes.io/configuration-snippet 批注中的语法错误，则生成的配置将变为无效，不会重新加载，因此没有 ingress 将会被考虑。
为了防止这种情况的发生，nginx 入口控制器选择性的暴漏一个 准入验证 Webhook 服务器，以确保传入的 ingress 对象的有效性。 Webhook 进来的 ingress 加入到 ingresses 列表中，生成配置并调用 nginx 以确保配置没有语法错误。
