15、K8s实战：KubernetesIngressNginx的架构和工作原理-程序员快看-教程，程序员编程资料站

一、前言

在Kubernetes部署的服务POD只有内部空间的IP，把服务暴露出去可以通过vendor LB、NodePort等方法，这些方法的路由、权限等配置能力不足，整体的灵活性和可管理性不能满足复杂的服务对外暴露的需求；为此，Kubernetes提出的Ingress的概念可以继承原有的Cluster Service的概念，并且提供强大的配置和管理能力。

Kubernetes支持的Ingress控制器的具体情况可以参见如下页面：

https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

转载自https://blog.csdn.net/cloudvtech

二、Ingress Nginx的架构

2.1 需要解决的问题

Ingress是用户将部署在Kubernetes上的业务对外进行标准化服务暴露的需求描述，而Ingress Nginx是Kubernetes Ingress概念的一个标准实现，需要解决的问题是将用户配置的Ingress转化成Nginx的配置文件并进行动态管理。Ingress Nginx的具体项目信息可以在这里看到：

https://github.com/kubernetes/ingress-nginx

2.2 整体架构

Ingress Nginx解决方案由如下模块组成：

Ingress控制器(Nginx Proxy、选主、控制器逻辑)
业务定义的Ingress对象
后端service和POD endpoints

Kubernetes Ingress架构

Ingress在部署的时候可以功过部署多个replica提供HA，多个replica通过选主程序确定一个leader；之后leader controller读取Kubernetes定义的所有Ingress以及对应的后端Service以及Endpoints，通过分析集群的这些输入信息生产一个反应系统当前运行状态的model；controller使用这个model生成Nginx的配置文件，最后realod Nginx来使这些配置生效；后续Ingress Nginx可以通过域名和路径将外部用户请求proxy到内部的endpoints上面去。

2.3 控制面流程

Ingress在部署之后，最重要的任务就是根据集群关键元素的状态生成Nginx的配置文件，然后进行动态管理：

Ingress Nginx配置管理

在Ingress Ngixn的架构里面，控制面最关键的一个数据结构是Nginx model。当前，通过获取Ingress、Service、Endpoints、Secrets、Configmaps等Kubernetes Object，进行分析，得出一个反应当前系统运行状态的model；这个model由controller loop进行状态比较，比较之后生成Nginx的配置文件。

Controller在分析对比model的状态的时候：

如果model没有变化，则不进行任何Nginx操作
如果model变化的只有service的endpoints，则将endpoints变化交给Lua Handler进行处理，而不需要生成新的Nginx配置文件并reload Nginx
如果存在endpoints之外的变化，则需要生成新的Nginx配置文件并且reload Nginx

mode的如下一些变化会导致Nginx reload：

有新建的Ingress
已有的Ingress中添加了TLS部分
导致不止Upstream配置变化的Ingress annotation的更新
Ingress中添加或者删除一个path
删除Ingress、Service或者Secret
一些出错的Service或者Secret之类状态变正常了
更新Secret

新生成的配置文件存在在Configmap里面，然后被各个Nginx POD引用。在生成配置的时候，会参考如下的一些基本规则和操作：

按照Ingress规则的时间戳，先处理时间戳较早的规则
如果多个Ingress定义来一样的host和path，则使用时间戳较早的规则
如果多个Ingress包含同样host的TLS配置，则使用时间戳较早的规则
如果多个Ingress包含影响Server block的annotation，则使用时间戳较早的规则
构建Nginx Server列表
构建NGINX Upstreams列表
如果多个Ingress定义来同一个host的不同path，这些path定义会被合并
Annotations对Ingress里面的所有path生效
不同的Ingress可以定义不同的annotation并且不相互干扰

2.3 数据面流程

在Ingress Nginx部署的时候，会部署多个POD实例，然后Ingress Nginx还会部署一个NodePort Service，最后将部分部署了Ingress Nginx的node挂载到Vendor的LB上面，作为接入层。

在公有云Kubernetes部署的服务需要通过一系列的中间路径最终对外提供服务，从最外层一直到最末端的路径如下：

在上述路径中，需要具体说明的关键点如下：

external ELB承载DNS域名并且进行HTTPS卸载
Kong用于根据域名或者路径进行路由后端选择或者实施访问限制，Kong的路由目的可能是部署在ECS上的服务，也有可能是部署在Kubernetes上的服务
Kubernetes集群部署了内部和外部两个ELB，分别对应内部和外部服务，外部ELB接受Kong转过来的外部请求，内部ELB接受来自内部VM或者POD的请求
POD如果请求部署在Kubernetes的服务，可以选择使用内部域名，也可以选择使用Kubernetes的cluster service；但是对于某些使用gRPC协议的服务，使用ingress nginx或者cluster service都无法进行很好的负载均衡，需要自行制定服务发现和负载均衡
所有外部的请求域名类似于xxx.test.com，而内部请求的域名则类似于internal-xxx.test.com
Kubernetes的ELB挂载nodes ig的worker节点，这些节点都部署了ingress nginx daemonset，用于接入对于集群中服务的访问请求
使用ingress或者cluster service方式访问POD中的服务，不可避免存在跨worker节点的traffic relay

转载自https://blog.csdn.net/cloudvtech

2.4 Nginx是如何连接后端的

在配置Ingress的时候，我们只配置了后端服务的cluser service的名字，之后Nginx进行请求转发的时候，并不是直接连接cluser service的IP。因为在此之际，controller会根据cluser service的名字找到对应的所有endpoints，然后Nginx会直接向这些endpoints POD转发请求，更具体的信息可以在这里找到：https://github.com/kubernetes-retired/contrib/issues/1140

这样的做主要原因还是在于直接连接后端POD可以给予ingress更及时的响应能力和更完善的proxy功能支持，增强Ingress的掌控能力，这个文章《Ingress Controller: Forget about the service 》也进行了详尽的分析。

2.5 Ingress Nginx Controller是如何做HA的

在Ingress Controller启动的时候，会通过configmap “ingress-controller-leader-nginx”进行选主，leader controller会lock这个configmap：

kubectl logs -n ingress-nginx nginx-ingress-controller-2nqlg | grep leader

I0424 08:29:13.641151 8 leaderelection.go:242] attempting to acquire leader lease ingress-nginx/ingress-controller-leader-nginx...

I0424 08:29:14.295593 8 leaderelection.go:252] successfully acquired lease ingress-nginx/ingress-controller-leader-nginx

I0424 08:29:14.295656 8 status.go:86] new leader elected: nginx-ingress-controller-2nqlg

在configmap被leader lock之后，configmap里面会记录如下信息：

{
  "kind": "ConfigMap",
  "apiVersion": "v1",
  "metadata": {
    "name": "ingress-controller-leader-nginx",
    "namespace": "ingress-nginx",
    "selfLink": "/api/v1/namespaces/ingress-nginx/configmaps/ingress-controller-leader-nginx",
    "uid": "da159fb2-789f-11ea-b093-fa163e23cb69",
    "resourceVersion": "9658136",
    "creationTimestamp": "2020-04-07T07:17:34Z",
    "annotations": {
      "control-plane.alpha.kubernetes.io/leader": "{"holderIdentity":"nginx-ingress-controller-2nqlg","leaseDurationSeconds":30,"acquireTime":"2020-04-09T08:52:01Z","renewTime":"2020-05-08T03:14:47Z","leaderTransitions":7}",
      "kubectl.kubernetes.io/last-applied-configuration": "{"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{"control-plane.alpha.kubernetes.io/leader":"{"holderIdentity":"nginx-ingress-controller-456xc","leaseDurationSeconds":30,"acquireTime":"2019-08-30T10:02:16Z","renewTime":"2020-04-03T12:55:37Z","leaderTransitions":4}"},"creationTimestamp":"2019-08-22T01:57:18Z","name":"ingress-controller-leader-nginx","namespace":"ingress-nginx"}}n"
    }
  }
}

转载自https://blog.csdn.net/cloudvtech