Ingress-nginx 源码分析

对于像我这样的 k8s 萌新来说，ingress-nginx 项目有着很重要的意义。从学习 k8s 的角度来讲，它功能简练，代码量相对较少，很适合我们通过它来侧面理解 k8s 中的一些概念。话不多说这就开始我们本次的分享。

本文以 nginx-0.21.0 tag 作为分析对象。

思路

首先，单就项目名称 ingress-nginx 可以看出是利用 nginx 来实现的 ingress controller。

相信 nginx 大家都很熟悉。想要在 nginx 配置一个服务，可以修改 nginx 的配置文件然后 reload 一下让 nginx 配置生效就可以了。

那么可以再深入一步，如果想把 k8s 中 ingress 对应的服务暴露出去应该怎么办？思路也很清晰，只需要把 ingress 中的配置信息转换成 nginx 的配置文件并 reload 一下 nginx 就可以了。

有了最初的思路以后，就需要通过文档或代码来验证自己的思路，来看看 ingress-nginx 是不是这么做的。

我们从 ingress-nginx的设计文档入手。其中 how it works 章节在文档开头概括性的总结了其整体思路。

The goal of this Ingress controller is the assembly of a configuration file (nginx.conf)

可以看出，ingress controller 的主要目标就是我们之前讲的操作 nginx 的配置文件。

关键功能逻辑

<img src="https://img.haomeiwen.com/i7239104/b24748599e94a939.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" width="500" align=center />
有了整体的思路作为中心思想，接下来我们可以抓住几个主要的功能点来分析。

集群 api 访问

想要实现这个集群配置转换到 ingress 的过程，我们必须保证程序与集群能够通过 api 通信。k8s 文档中官方提到了在集群内部访问集群推荐方式。这里简单啰嗦一下逻辑：想要访问集群可以先配置一个 serviceaccount（下面简称 sa） 账户，然后配置一下将它纳入 k8s 的权限管理体系，Pod 运行时这个 sa 的配置默认会被挂载到一个预定义目录下面，我们可以使用 client-go 中的 InClusterConfig 函数直接拿到 sa 对应的配置，全程无需手动构造。

// file: k8s.io/client-go/tools/clientcmd/client_config.go
func BuildConfigFromFlags(masterUrl, kubeconfigPath string) (*restclient.Config, error) {
    if kubeconfigPath == "" && masterUrl == "" {
        kubeconfig, err := restclient.InClusterConfig()
        if err == nil {
            return kubeconfig, nil
        }
    }
    return NewNonInteractiveDeferredLoadingClientConfig().ClientConfig()
}

从这段 client-go 的代码我们可以看出，如果在集群内部运行，我们只要配置好 sa 就可以了。不需要指定具体参数。而在集群外部运行的话需要传入额外的参数来配置。

回到 ingress-nginx中来，在 controller 启动流程中有这样一段代码：

// file: k8s.io/ingress-nginx/cmd/nginx/main.go
func createApiserverClient(apiserverHost, kubeConfig string) (*kubernetes.Clientset, error) {
    //前面讲到的获取 k8s api 的相关配
    cfg, err := clientcmd.BuildConfigFromFlags(apiserverHost, kubeConfig)
    //...
    client, err := kubernetes.NewForConfig(cfg)

    defaultRetry := wait.Backoff{
        Steps:    10,
        Duration: 1 * time.Second,
        Factor:   1.5,
        Jitter:   0.1,
    }

    //...
    err = wait.ExponentialBackoff(defaultRetry, func() (bool, error) {
        v, err = client.Discovery().ServerVersion()

        if err == nil {
            return true, nil
        }

        //...
        return false, nil
    })

    //...
}

函数开始先获取到用于与集群 api 交互的相关配置，然后尝试创建 client，并验证其是否连通，如果没有连通则开始重试逻辑。

Backoff 结构体配置了重试操作的具体行为，简单理解为：一共重试 Steps 次，第一次的间隔时间为 Duration ，每重试一次间隔时间乘上 Factor，真实的间隔时间是在 1 ~ ( 1 + Jitter ) 倍数内波动。

监听集群信息变化

controller 中会监听以下资源的增删改操作：

• Ingress (网络出口)
• Endpoint（Service 和 Pod 的映射关系）
• Service
• Secret
• ConfigMap

其中集群的事件何时触发交由 client-go 管理。

// internal/ingress/controller/store/store.go
func New(...) Storer {

    //...

    ingEventHandler := cache.ResourceEventHandlerFuncs{
        AddFunc: func(obj interface{}) {
            //...
            updateCh.In() <- Event{
                Type: CreateEvent,
                Obj:  obj,
            }
        },
        DeleteFunc: func(obj interface{}) {
            //...
            updateCh.In() <- Event{
                Type: DeleteEvent,
                Obj:  obj,
            }
        },
        UpdateFunc: func(old, cur interface{}) {
            //...

            updateCh.In() <- Event{
                Type: UpdateEvent,
                Obj:  cur,
            }
        },
    }

    //...

    store.informers.Ingress.AddEventHandler(ingEventHandler)
    //...
}

实际代码中包含很多的样板代码，这里单独针对 Ingress 做分析，其他资源以此类推。中心思想就是拿到对应资源的 Informer，然后注册事件监听函数，在监听函数中，我们主要就是过滤出我们想要处理的事件然后将其投放进配置同步队列。

当事件进入配置同步队列以后执行配置同步逻辑：

//internal/ingress/controller/controller.go
func (n *NGINXController) syncIngress(interface{}) error {
    //...
    pcfg := &ingress.Configuration{...}
    //...
    if !n.IsDynamicConfigurationEnough(pcfg) {
        //...
        err := n.OnUpdate(*pcfg) // 需要reload的配置
        //...
    }
    //...
    err := wait.ExponentialBackoff(retry, func() (bool, error) {
        err := configureDynamically(pcfg, n.cfg.ListenPorts.Status, n.cfg.DynamicCertificatesEnabled)//不需要reload的配置
        //...
    })

    //...
}

这里会把配置大致分为动态配置和静态配置两大类，下节会讲配置生效的具体逻辑。

nginx reload 逻辑

nginx 在同步配置后是否 reload 的核心依据就是是否需要修改 nginx 的 conf 文件。

在 ingress-nginx 中网络出口由一个通用的配置模板来完成配置。而 balancer 的部分则是由运行在 nginx 里面的 Lua handler 负责。所以 endpoints 可以直接注册在 Lua 侧而不用写在 nginx 的 conf 配置文件中。这样就避免了由于实例数量变化导致的频繁 reload。

Lua handler 为每个请求找到其对应的 endpoints 实现从而实现负载均衡

配置同步的逻辑大致分两种情况：

• 同步动态配置（不用 reload nginx）
  • Endpoints 状态更新
• 同步静态配置（需要 reload nginx）
  • Service，Ingress，Secret 增加与删除
  • 添加 TLS 配置
  • ingress path 的增加和删除
  • ingress 与 Service，Secret 关联
  • Secret 更新
  • 修改 annotations 后导致前面所述的状态变化

无论同步哪种配置均会与原配置对比，只有在配置修改时才会同步配置。

具体行为在 文档中有描述

nginx 进程保活机制

前面对总的运行流程做了梳理，这节主要讲一下在 ingress-nginx 里面是如何保证 nginx 进程持续运行的。

首先是用程序构建 nginx 的启动命令：

//internal/ingress/controller/util.go
func nginxExecCommand(args ...string) *exec.Cmd {
    ngx := os.Getenv("NGINX_BINARY")
    //...

    cmdArgs = append(cmdArgs, ngx, "-c", cfgPath)
    cmdArgs = append(cmdArgs, args...)

    return exec.Command("authbind", cmdArgs...)
}

除了在启动流程时触发了 nginx 运行以外还在运行的主循环中增加了一个 case 来完成保活逻辑：

//internal/ingress/controller/nginx.go
for {
        select {
        case err := <-n.ngxErrCh:
            //...
            if process.IsRespawnIfRequired(err) {
                //...
                cmd = nginxExecCommand()
                cmd.SysProcAttr = &syscall.SysProcAttr{}
                n.start(cmd)
            }
        case event := <-n.updateCh.Out():
            //...
        case <-n.stopCh:
            break
        }
    }

这样就可以在 nginx 异常退出时再将其重新拉起来。

总结

通过对 ingress-nginx 源码的梳理，我们不仅掌握了 ingress-nginx 本身的一些关键点，也学会了如何设计一款与 k8s 交互的。
应用。

参考资源

ingress-nginx 文档

shida_csdn 博客