Nginx Ingress on TKE 部署最佳實踐

概述

開源的 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 部署方案

那么如何在 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-ingresskubectl 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-ingresskubectl 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-ingresskubectl 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 節點，也無法實作自動擴縮容，通常不太建議用這種方案，
3. 方案三性能好，而且不需要手動維護 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 (按量計費)，你可以按需調整下，

由于歷史遺留原因，以前注冊的賬號大多是非帶寬上移型別，參考檔案 區分騰訊云賬戶型別 來區分自己賬號的型別，

如何創建 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/ingress-nginx/tree/master/deploy/grafana/dashboards

我們直接復制 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 了，敬請期待吧！

參考資料

1. TKE Service YAML 示例: https://cloud.tencent.com/document/product/457/45489#yaml-.E7.A4.BA.E4.BE.8B
2. TKE Service 使用已有 CLB: https://cloud.tencent.com/document/product/457/45491
3. 區分騰訊云賬戶型別: https://cloud.tencent.com/document/product/684/39903
   【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
   

標籤：其他

上一篇：揭秘！containerd 鏡像檔案丟失問題，竟是鏡像生成惹得禍

下一篇：圖解 K8s 核心概念和術語