作者林育新，騰訊雲容器產品工程師。目前主要負責騰訊雲TKE的控制檯的相關研發工作。

### 概述

在開源社群當中，Kubernetes 的 Ingress Controller 的實現有多種方式，Nginx Ingress 只是其中的一種實現方式，當然也是目前社群中使用量最大的一種 Ingress Controller 的實現方式，其不僅功能強大，而且效能極高。本文主要介紹如何使用騰訊雲容器服務實現多種方式進行 Nginx Ingress 的部署，並會簡單介紹各種方式的實現原理以及優缺點和適用場景。

### Nginx Ingress 是什麼

Nginx Ingress 是 Kubernetes 的一種物件，透過`nginx-ingress-controller` 將使用者宣告的 `nginx-ingress` 轉化成 nginx 的轉發規則。其核心解決的問題是流量的轉發和東西向的負載均衡。
主要的工作原理是`nginx-ingress-controller`監聽`api-server`的變化（Kubernetes Informers），透過 watch Kubernetes 的 Ingress、Service、Endpoint、Secret、ConfigMap 等物件變化，更改 Nginx 例項的配置，進行流量轉發。

![img](https://main.qcloudimg.com/raw/64b05ad1cc98509c7b906a80dd5ca1b2.png)

目前社群中，針對於 Nginx Ingress 主要有如下的兩種實現方式

- [Kubernetes 開源社群的實現](https://github.com/kubernetes/ingress-nginx)
- [Nginx 官方的實現](https://github.com/nginxinc/kubernetes-ingress)

### 為什麼需要 Nginx Ingress

開源社群當中，對 `Ingress Controller` 的實現方式有多種，每一種 Controller 都有其適用的場景以及各自的優缺點，為什麼推薦使用 `nginx-ingress-controller`？下面我們來探討一下，如果不使用 `nginx-ingress-controller` 會給業務帶來什麼困擾

這裡以騰訊雲容器服務控制檯（以下簡稱 `TKE`）預設推薦的 `ingress controller` 為例子，存在如下的一些問題：

1. CLB 型別的 Ingress 能力無法滿足現有業務的需求，如無法共享同一個外網入口，支援預設預設轉發後端等
2. 原有業務已使用了 `nginx-inrgess`，並且運維已習慣於配置 `nginx.conf`，不希望做過多的改變

使用 `nginx-ingress-controller`，能夠很好地解決以上的問題。

### 需要什麼前提條件

#### 部署 nginx-ingress-operator

##### 元件部署安裝

進入騰訊雲容器服務控制檯當中，選擇需要部署 `Nginx Ingress` 的叢集，進入叢集-元件管理當中，部署安裝 `Nginx Ingess` 元件，如下圖：

![img](https://main.qcloudimg.com/raw/fa9d173c97de07124fa3d46c7fd14cb0.jpg)

##### 元件安裝並且正常執行

![img](https://main.qcloudimg.com/raw/2ba6d87a61ea28a0ee9eee92bfc1d57d.jpg)

### 部署方案

TKE 提供了多種對於`nginx-ingress-controller`的部署方案以及接入 LB 的方式，適配不同的業務場景需求，以下會對不同的方案進行介紹。

#### nginx-ingress-controller 部署方案

##### 方案一： DaemonSet + 節點池

![img](https://main.qcloudimg.com/raw/217e17c24988adbd643cec9b7af2a56c.png)

Nginx 作為關鍵的流量接入閘道器，是至關重要的元件，不建議將 Nginx 與其他業務部署在相同的節點內，可以透過節點池設定汙點的方式，進行部署。關於節點池的相關說明，可以檢視[**騰訊雲容器服務節點池概述**](https://cloud.tencent.com/document/product/457/43719)。

![img](https://main.qcloudimg.com/raw/7e7474b653fde408ad82779ebcbe4c88.png)

使用此部署方案，應該注意如下幾個事項：

- 提前準備好部署 `nginx-ingress-controller` 的節點池，同時設定節點池的汙點 `Taint` 和 `Label`，防止其他 Pod 排程到該節點池。

- 確保已成功部署安裝好 `nginx-ingress-operator` 元件，部署方式參考上方指引

- 進入元件詳情，建立

```
  nginx-ingress-controller
  ```

例項（單一叢集內可同時存在多個例項）

- 部署方式選擇 `指定節點池DaemonSet部署`
  - 設定容忍汙點
  - 設定 Request/Limit，其中 Request 需設定比節點池的機型配置小（節點本身有資源預留，避免例項因資源不足而不可用），Limit 可不設定
  - 其他引數根據業務需要進行設定即可

##### 方案二：Deployment + HPA

![img](https://main.qcloudimg.com/raw/5147b2ffbbf056bb1ef468780a3c4669.png)

使用 Deployment + HPA 的方案進行部署，您可以根據業務需要配置汙點和容忍，將 Nginx 和業務 Pod 進行分散部署。搭配 HPA，設定 CPU/記憶體等指標進行彈性伸縮。

![img](https://main.qcloudimg.com/raw/1a116084438c010e471fddf3868903e7.png)

使用此部署方案，應該注意如下幾個事項：

- 在叢集中設定即將部署 `nginx-ingress-controller` 的節點的 Label

- 確保已成功部署安裝好 `nginx-ingress-operator` 元件，部署方式參考上方指引。

- 進入元件詳情，建立

```
  nginx-ingress-controller
  ```

例項（單一叢集內可同時存在多個例項）

- 部署方式選擇 `自定義Deployment+HPA部署`
  - 設定 HPA 觸發策略
  - 設定 Request/Limit
  - 設定節點排程策略，推薦 `nginx-ingress-controller` 獨佔節點，避免其他業務資源侵佔而導致不可用
  - 其他引數根據業務需要進行設定即可

#### Nginx 前端接入 LB 的部署方式

上文介紹了在 TKE 的叢集當中部署 `nginx-ingress-operator` 和 `nginx-ingress-controller` 的使用流程和部署方案建議，完成以上步驟，僅僅是在叢集內部署了 Nginx 的相關元件，但要接收外部的流量，還需要配置，還需要配置 nginx 的前端 LB。當前 TKE 已完成對 Nginx Ingress 的產品化支援，可以根據業務需要選擇以下部署模式之一。

##### 方案一：VPC-CNI 模式叢集使用 CLB 直通 Nginx 的 Service（推薦）

> 前置條件（滿足其一即可）：
>
> 1. 叢集自身網路外掛為 `VPC-CNI`
> 2. 叢集自身網路外掛為 `Global Router`，並已開啟 `VPC-CNI` 的支援（兩種模式混用）

我們以節點池部署的負載示例
![img](https://main.qcloudimg.com/raw/d74dd402599c1a44e7c18bdb3c1868a1.png)
當前方案效能好，所有的 Pod 都使用的彈性網路卡，彈性網路卡的 Pod 是支援 CLB 直綁 Pod 的，可以繞過 NodePort，並且不需要手動維護 CLB，支援自動擴縮容，是最理想的方案。

##### 方案二：Global Router 模式叢集使用普通 LoadBalancer 模式的 Service

當前 TKE 對於 LoadBalancer 型別的 Service 預設的實現是基於 NodePort，CLB 會繫結各節點的 NodePort 作為後端的 RS，將流量轉發到節點的 NodePort，然後節點再透過 Iptables 或 IPVS 將請求路由到 Service 對應的後端 Pod（指 Nginx Ingress Controller 的 Pod）。

您的叢集如果不支援 `VPC-CNI` 的網路模式，可以透過常規的 `LoadBalancer` 訪問方式的 Service 接入流量。
這是在 TKE 上部署 Nginx Ingress 最簡單的方式，流量會經過一層 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 造成較大的壓力。

##### 方案三：使用 HostNetwork + LB

方案二雖然是最簡單的部署方式，但是流量會經過一層 NodePort，且可能存在如上所描述的問題，我們可以讓 Nginx Ingress 使用 HostNetwork，CLB 直接繫結節點 IP + 埠(80,443)。由於使用 HostNetwork，`nginx ingress` 的 Pod 就不能被排程到同一個節點當中，避免埠監聽衝突。
由於 TKE 尚未對此方案進行產品化，可以透過提前規劃，選擇部分節點，專門用於部署 `nginx-ingress-controller`，為節點打上 `Label`，然後以 DaemonSet 的方式部署在這些節點上（即 `nginx-ingress-controller` 的部署方案一）。

### 如何整合監控

TKE 透過整合 騰訊雲容器團隊的高效能雲原生監控服務（傳送門：https://console.cloud.tencent.com/tke2/prometheus ），也可在以前釋出的文章《如何用 Prometheus 監控十萬 container 的 Kubernetes 叢集》中瞭解 Prometheus，Kvass 和怎麼利用 kvass 為基礎的 Prometheus 叢集化技術。

#### 繫結監控例項

![img](https://main.qcloudimg.com/raw/c842ad8b487e00c477106882882dec04.png)

#### 檢視監控資料

![img](https://main.qcloudimg.com/raw/7ee8023101e01887ec1e593264156721.png)

### 如何採集和消費日誌

TKE 透過整合 騰訊雲日誌服務 CLS，提供了全套完整的產品化能力，實現 `nginx-ingress-controller` 的日誌採集和消費能力，但需要注意如下幾個事項：

1. 前置要求：確保當前叢集已開啟日誌採集功能
2. 在 `nginx-ingress-controller` 例項中，配置日誌採集的相關選項。

![img](https://main.qcloudimg.com/raw/1fd82b21bb415fd9df3a23492eb65d4f.png)

### 總結

本文梳理瞭如何使用騰訊雲容器服務控制檯玩轉 Nginx Ingress，主要介紹了控制檯上的對於 `nginx-ingress-controller` 的兩種部署方式以及建議，以及前端接入 LB 的三種方式，除了在 TKE 上進行 Nginx Ingress 的一鍵部署，TKE 還提供叢集所部署的 `nginx-ingress-controller` 日誌和監控的相關能力的產品化支援。對於想要在 TKE 上使用 Nginx Ingress，本文是一個很好的參考和指引。

使用騰訊雲容器服務玩轉 Nginx Ingress

相關文章