小技巧-通过阿里云K8S Ingress Controller实现路由配置的动态更新

　　摘要： 本文主要描述了阿里云Kubernetes集群Ingress Controller如何通过动态更新的方式来极大地缓解转发平面Nginx频繁Reload带来的影响。

　　在Kubernetes集群中，Ingress作为集群内服务对外暴露的访问接入点，其几乎承载着集群内服务访问的所有流量。我们知道，Nginx Ingress Controller是Kubernetes社区很重要的一个子项目，其内部主要依托于高性能的负载均衡软件Nginx，将Kubernetes Ingress资源对象实时地自动化转换为Nginx配置规则来对外提供期望的授权访问入口。

　　当随着Kubernetes集群中部署的微服务越来越多，对外暴露的路由规则越来越复杂，服务后端Endpoint变化的越来越频繁，那么对应地都会引起Nginx Ingress Controller组件内Nginx配置文件的变化越来越频繁；而我们知道，任何一行Nginx配置的变化，都需要Reload Nginx才能生效，这在变化频率较低的场景下索性还能接受，但在高频率变化的场景下就会引起Nginx的频繁Reload。

　　而Nginx频繁Reload带来的问题，这已是一个老生常谈的话题了，其问题本质主要还是源于Nginx本身最初的架构设计模型：

　　一般在Linux服务器中，我们会配置使用Nginx的EPOLL多进程模式；当我们修改了Nginx配置文件后，需要通过

　　nginx -s reload

　　命令来重新热加载新的Nginx配置规则；

　　当Nginx Master进程接收到reload signal后，其会从指定路径重新加载新的Nginx配置文件内容，并校验配置规则的有效性，若检验为有效的配置文件，则会依据新的配置文件中的worker_processes值fork出指定数量的新的Nginx Worker进程，此时新fork出来的子进程完全继承了父进程的内存数据ngx_cycle（其包含了新的解析后的Nginx配置规则），同时将配置中的每一个Listen Socket FD注册到内核的EPOLL事件监听中，此时这些新的Nginx Worker进程可以接收处理来自客户端的请求；

　　同时Nginx Master进程会发送QUIT signal通知老的Nginx Worker进程平滑退出，当老的Nginx Worker进程接收到QTUI信号后，将其之前注册到EPOLL中的监听Event移除，至此不再接收处理新的客户端请求，并依据老配置文件中设置的worker_shutdown_timeout值来设置定时器，然后继续处理完已接收的客户端请求；若在worker_shutdown_timeout之前处理完已有的客户端请求，则自动退出，若未处理完，则被强制Kill退出，此时就会导致该客户端请求响应异常。

　　因此，对于在高频率变化的场景下，Nginx频繁Reload会带来较明显的请求访问问题：造成一定的QPS抖动和访问失败情况对于长连接服务会被频繁断掉造成大量的处于shutting down的Nginx Worker进程，进而引起内存膨胀

　　为缓解Nginx频繁Reload带来的影响，我们需要通过动态更新的方式来加载Nginx配置规则，即在不Fork新Nginx Worker进程的情况下来实时更新已加载到内存中的Nginx配置规则。

　　首先我们看下Nginx的配置文件样式，主要包含下面几部分配置章节：

　　# 1. main configuration

　　daemon off;

　　worker_processes 4;

　　events {

　　# 2. event configuration

　　multi_accept on;

　　worker_connections 1024;

　　use epoll;

　　}

　　http {

　　# 3. http main configuration

　　access_log /var/log/nginx/access.log;

　　error_log /var/log/nginx/error.log;

　　upstream {

　　# 4. upstream configuration

　　server 0.0.0.1;

　　}

　　server {

　　# 5. server configuration

　　server_name _ ;

　　listen 80 default_server;

　　location / {

　　# 6. location configuration

　　proxy_pass http://upstream_balancer;

　　}

　　}

　　而在Kubernetes集群中，一个Ingress资源对象主要被解析映射到Nginx的HTTP Main Block、Server Block、Upstream Block和Location Block等章节的配置规则上，因此我们可以将这几部分频繁变化的配置内容以Shared Memory的方式统一维持在内存中，同时在Ingress Controller内部暴露出管控端口，通过API的方式来实时管理Nginx路由规则配置：

　　当K8S Ingress Controller监控到集群内Ingress及相关联的资源发生变化时，均可通过Internal API将最新的Nginx配置规则推送到统一的共享内存配置中，而不用再通过Reload Nginx的方式来使新配置生效，至此当Nginx处理任何新接收的客户端请求时，都可以基于最新的共享内存中的配置进行规则匹配和路由转发；

　　1、目前阿里云容器服务Kubernetes集群中最新版本的Nginx Ingress Controller组件默认已开启Upstream的动态更新，同时支持应用服务的灰度发布和蓝绿发布功能，具体配置说明可参考这里；

　　我们可以通过如下命令来查看当前共享内存中的Nginx Upstream的配置列表：