Ingress-nginx 源码分析-阿里云开发者社区

开发者社区> saberuster> 正文

Ingress-nginx 源码分析

简介: 对于像我这样的 k8s 萌新来说,ingress-nginx 项目有着很重要的意义。从学习 k8s 的角度来讲,它功能简练,代码量相对较少,很适合我们通过它来侧面理解 k8s 中的一些概念。
+关注继续查看

对于像我这样的 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 的配置文件。

关键功能逻辑

1240
有了整体的思路作为中心思想,接下来我们可以抓住几个主要的功能点来分析。

集群 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 博客

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Kubernetes Ingress 日志分析与监控的最佳实践
Ingress 主要提供 HTTP 层(7 层)路由功能,是目前 K8s 中 HTTP/HTTPS 服务的主流暴露方式。为简化广大用户对于 Ingress 日志分析与监控的门槛,阿里云容器服务和日志服务将 Ingress 日志打通,只需要应用一个 yaml 资源即可完成日志采集、分析、可视化等一整套 Ingress 日志方案的部署。
4976 0
使用Qt Creator作为Linux IDE,实现Nginx源码编译和断点调试(1)
使用Qt Creator作为Linux IDE,实现Nginx源码编译和断点调试
37 0
怎么设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程
8371 0
RestTemplate源码分析
RestTemplate是Spring提供的访问Rest服务的客户端,它简化了和http服务器的交互。 HTTP 协议特点是纯文本协议,其媒体类型MediaType可以为text/html、text/xml、application/json等,HTTP消息必须使用content-type进行自我描述,否则不能区分媒体类型。
3784 0
Java 读写锁 ReentrantReadWriteLock 源码分析
原文出处:https://javadoop.com/post/reentrant-read-write-lock 本文内容:读写锁 ReentrantReadWriteLock 的源码分析,基于 Java7/Java8。
814 0
Java集合类源码分析汇总
Java集合类基础:http://www.cnblogs.com/hzmark/archive/2012/12/17/CollectionBase.html ArrayList源码分析:http://www.
805 0
Ingress-nginx 源码分析
对于像我这样的 k8s 萌新来说,ingress-nginx 项目有着很重要的意义。从学习 k8s 的角度来讲,它功能简练,代码量相对较少,很适合我们通过它来侧面理解 k8s 中的一些概念。
2476 0
PostgreSQL · 特性分析 · 统计信息计算方法
一条SQL在PG中的执行过程是: ----> SQL输入 ----> 解析SQL,获取解析后的语法树 ----> 分析、重写语法树,获取查询树 ----> 根据重写、分析后的查询树计算各路径代价,从而选择一条成本最优的执行树 ----> 根据执行树进行执行 ----> 获取结果并返回
1577 0
+关注
1
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载