目录
•概述
•什么是 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 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 了,敬请期待吧!
最近新装的ingress感觉比配置一个nginx还复杂,80正常443就找不到,一代版本一代神,代代版本代代坑