Nginx Ingress on TKE 部署最佳实践

目录

•概述

•什么是 Nginx Ingress ?

•有哪些部署方案 ?

◾方案一：Deployment + LB

◾方案二：Daemonset+ HostNetwork + LB

◾方案三：Deployment + LB 直通 Pod

•如何选型？

•如何支持内网 Ingress ?

•如何复用已有 LB ?

•Nginx Ingress 公网带宽有多大？

•如何创建 Ingress ?

•如何监控？

•总结

•参考资料

概述

开源的 Ingress Controller 的实现使用量最大的莫过于 Nginx Ingress 了，功能强大且性能极高。Nginx Ingress 有多种部署方式，本文将介绍 Nginx Ingress 在 TKE 上的一些部署方案，这几种方案的原理、各自优缺点以及一些选型和使用上的建议。

什么是Nginx Ingress？

在介绍如何部署 Nginx Ingress 之前，我们先简单了解下什么是 Nginx Ingress。

Nginx Ingress 是 Kubernetes (www.alauda.cn )Ingress 的一种实现，它通过 watch Kubernetes 集群的 Ingress 资源，将 Ingress 规则转换成 Nginx 的配置，然后让 Nginx 来进行 7 层的流量转发:

实际 Nginx Ingress 有两种实现：

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

2.https://github.com/nginxinc/kubernetes-ingress

第一种是 Kubernetes 开源社区的实现，第二种是 Nginx 官方的实现，我们通常用的是 Kubernetes 社区的实现，这也是本文所关注的重点。

有哪些部署方案？

那么如何在 TKE 上部署 Nginx Ingress 呢？主要有三种方案，下面分别介绍下这几种方案及其部署方法。

方案一：Deployment + LB

在 TKE 上部署 Nginx Ingress 最简单的方式就是将 Nginx Ingress Controller 以 Deployment 的方式部署，并且为其创建 LoadBalancer 类型的 Service(可以是自动创建 CLB 也可以是绑定已有 CLB)，这样就可以让 CLB 接收外部流量，然后转发到 Nginx Ingress 内部：

当前 TKE 上 LoadBalancer 类型的 Service 默认实现是基于 NodePort，CLB 会绑定各节点的 NodePort 作为后端 rs，将流量转发到节点的 NodePort，然后节点上再通过 Iptables 或 IPVS 将请求路由到 Service 对应的后端 Pod，这里的 Pod 就是 Nginx Ingress Controller 的 Pod。后续如果有节点的增删，CLB 也会自动更新节点 NodePort 的绑定。

这是最简单的一种方式，可以直接通过下面命令安装:

kubectl create ns nginx-ingress

kubectl apply -f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/nginx-ingress/nginx-ingress-deployment.yaml -n nginx-ingress

方案二：Daemonset + HostNetwork + LB

方案一虽然简单，但是流量会经过一层 NodePort，会多一层转发。这种方式有一些缺点：

1.转发路径较长，流量到了 NodePort 还会再经过 Kubernetes 内部负载均衡，通过 Iptables 或 IPVS 转发到 Nginx，会增加一点网络耗时。

2.经过 NodePort 必然发生 SNAT，如果流量过于集中容易导致源端口耗尽或者 conntrack 插入冲突导致丢包，引发部分流量异常。

3.每个节点的 NodePort 也充当一个负载均衡器，CLB 如果绑定大量节点的 NodePort，负载均衡的状态就分散在每个节点上，容易导致全局负载不均。

4.CLB 会对 NodePort 进行健康探测，探测包最终会被转发到 Nginx Ingress 的 Pod，如果 CLB 绑定的节点多，Nginx Ingress 的 Pod 少，会导致探测包对 Nginx Ingress 造成较大的压力。

我们可以让 Nginx Ingress 使用 hostNetwork，CLB 直接绑节点 IP + 端口(80,443)， 这样就不用走 NodePort；由于使用 hostNetwork，Nginx Ingress 的 pod 就不能被调度到同一节点避免端口监听冲突。通常做法是提前规划好，选取部分节点作为边缘节点，专门用于部署 Nginx Ingress，为这些节点打上 label，然后 Nginx Ingress 以 DaemonSet 方式部署在这些节点上。下面是架构图：

安装步骤：

1.将规划好的用于部署 Nginx Ingress 的节点打上 label: kubectl label node 10.0.0.3 nginx-ingress=true(注意替换节点名称)。

2.将 Nginx Ingress 部署在这些节点上:

kubectl create ns nginx-ingress

kubectl apply -f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/nginx-ingress/nginx-ingress-daemonset-hostnetwork.yaml -n nginx-ingress

3.手动创建 CLB，创建 80 和 443 端口的 TCP 监听器，分别绑定部署了 Nginx Ingress 的这些节点的 80 和 443 端口。

方案三：Deployment + LB 直通 Pod

方案二虽然相比方案一有一些优势，但同时也引入了手动维护 CLB 和 Nginx Ingress 节点的运维成本，需要提前规划好 Nginx Ingress 的节点，增删 Nginx Ingress 节点时需要手动在 CLB 控制台绑定和解绑节点，也无法支持自动扩缩容。如果你的网络模式是 VPC-CNI，那么所有的 Pod 都使用的弹性网卡，弹性网卡的 Pod 是支持 CLB 直接绑 Pod 的，可以绕过 NodePort，并且不用手动管理 CLB，支持自动扩缩容:

如果你的网络模式是 Global Router(大多集群都是这种模式)，你可以为集群开启 VPC-CNI 的支持，即两种网络模式混用，在集群信息页可打开：

确保集群支持 VPC-CNI 之后，可以使用下面命令安装 Nginx Ingress:

kubectl create ns nginx-ingress

kubectl apply -f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/nginx-ingress/nginx-ingress-deployment-eni.yaml -n nginx-ingress

如何选型？

前面介绍了 Nginx Ingress 在 TKE 上部署的三种方案，也说了各种方案的优缺点，这里做一个简单汇总下，给出一些选型建议：

1.方案一较为简单通用，但在大规模和高并发场景可能有一点性能问题。如果对性能要求不那么严格，可以考虑使用这种方案。

2.方案二使用 hostNetwork 性能好，但需要手动维护 CLB 和 Nginx Ingress 节点，也无法实现自动扩缩容，通常不太建议用这种方案。

方案三性能好，而且不需要手动维护 CLB，是最理想的方案。它需要集群支持 VPC-CNI，如果你的集群本身用的 VPC-CNI 网络插件，或者用的 Global Router 网络插件并开启了 VPC-CNI 的支持(两种模式混用)，那么建议直接使用这种方案。

如何支持内网Ingress？

方案二由于是手动管理 CLB，自行创建 CLB 时可以选择用公网还是内网；方案一和方案三默认会创建公网 CLB，如果要用内网，可以改下部署 YAML，给 nginx-ingress-controller 这个 Service 加一个 key 为 service.kubernetes.io/qcloud-loadbalancer-internal-subnetid，value 为内网 CLB 所被创建的子网 id 的 annotation，示例:

apiVersion: v1

kind: Service

metadata:  

annotations:   

service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxx # value 替换为集群所在 vpc 的其中一个子网 id 

labels:    

app: nginx-ingress    

component: controller

name: nginx-ingress-controller

如何复用已有LB？

方案一和方案三默认会自动创建新的 CLB，Ingress 的流量入口地址取决于新创建出来的 CLB 的 IP 地址。如果业务对入口地址有依赖，比如配置了 DNS 解析到之前的 CLB IP，不希望切换 IP；或者想使用包年包月的 CLB (默认创建是按量计费)，那么也可以让 Nginx Ingress 绑定已有的 CLB。

操作方法同样也是修改下部署 yaml，给 nginx-ingress-controller 这个 Service 加一个 key 为 service.kubernetes.io/tke-existed-lbid，value 为 CLB ID 的 annotation，示例:

apiVersion: v1

kind: Service

metadata: 

annotations:    

service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx # value 替换为 CLB 的 ID 

labels:    

app: nginx-ingress   

component: controller 

name: nginx-ingress-controller

Nginx Ingress 公网带宽有多大？

有同学可能会问：我的 Nginx Ingress 的公网带宽到底有多大？能否支撑住我服务的并发量？

这里需要普及一下，腾讯云账号有带宽上移和非带宽上移两种类型：

1.非带宽上移，是指带宽在云主机(CVM)上管理。

2.带宽上移，是指带宽上移到了 CLB 或 IP 上管理。

具体来讲，如果你的账号是非带宽上移类型，Nginx Ingress 使用公网 CLB，那么 Nginx Ingress 的公网带宽是 CLB 所绑定的 TKE 节点的带宽之和；如果使用方案三，CLB 直通 Pod，也就是 CLB 不是直接绑的 TKE 节点，而是弹性网卡，那么此时 Nginx Ingress 的公网带宽是所有 Nginx Ingress Controller Pod 被调度到的节点上的带宽之和。

如果你的账号是带宽上移类型就简单了，Nginx Ingress 的带宽就等于你所购买的 CLB 的带宽，默认是 10Mbps (按量计费)，你可以按需调整下。

由于历史遗留原因，以前注册的账号大多是非带宽上移类型，参考 区分腾讯云账户类型[3] 文档来区分自己账号的类型。

如何创建Ingress？

目前还没有完成对 Nginx Ingress 的产品化支持，所以如果是在 TKE 上自行了部署 Nginx Ingress，想要使用 Nginx Ingress 来管理 Ingress，目前是无法通过在 TKE 控制台(网页) 上进行操作的，只有通过 YAML 的方式来创建，并且需要给每个 Ingress 都指定 Ingress Class 的 annotation，示例:

apiVersion: networking.k8s.io/v1beta1

kind: Ingress

metadata:  

name: test-ingress  

annotations:  

kubernetes.io/ingress.class: nginx # 这里是重点

spec: 

rules:  

- host: *   

http:    

paths:  

- path: /       

backend:          

serviceName: nginx-v1         

servicePort: 80

如何监控？

通过上面的方法安装的 Nginx Ingress，已经暴露了 metrics 端口，可以被 Prometheus 采集。如果集群内安装了 prometheus-operator，可以使用下面的 ServiceMonitor 来采集 Nginx Ingress 的监控数据:

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:  

name: nginx-ingress-controller 

namespace: nginx-ingress 

labels:    

app: nginx-ingress   

component: controller

spec:  endpoints:

- port: metrics  

interval: 10s 

namespaceSelector:   

matchNames:    

- nginx-ingress  

- selector:    

- matchLabels:     

-  app: nginx-ingress      

- component: controller

这里也给个原生 Prometheus 配置的示例:

- job_name: nginx-ingress   

scrape_interval: 5s     

kubernetes_sd_configs:    

- role: endpoints   

 namespaces:       

names:         

- nginx-ingress    

relabel_configs:     

- action: keep       

source_labels:      

- __meta_kubernetes_service_label_app     

- __meta_kubernetes_service_label_component      

regex: nginx-ingress;controller     

- action: keep       

source_labels:      

- __meta_kubernetes_endpoint_port_name      

regex: metrics

有了数据后，我们再给 grafana 配置一下面板来展示数据，Nginx Ingress 社区提供了面板：https://github.com/kubernetes/ ... oards

我们直接复制 json 导入到 grafana 即可导入面板。其中，nginx.json 是展示 Nginx Ingress 各种常规监控的面板：

request-handling-performance.json 是展示 Nginx Ingress 性能方面的监控面板：

总结

本文梳理了 Nginx Ingress 在 TKE 上部署的三种方案以及许多实用的建议，对于想要在 TKE 上使用 Nginx Ingress 的同学是一个很好的参考。由于 Nginx Ingress 的使用需求量较大，我们也正在做 Nginx Ingress 的产品化支持， 可以实现一键部署，集成日志和监控能力，并且会对其进行性能优化。相信在不久的将来，我们就能够在 TKE 上更简单高效的使用 Nginx Ingress 了，敬请期待吧！