容器服務 TKE 上服務暴露的幾種方式

預備知識

1. K8S 上 Service 類型

• ClusterIP

經過集羣的內部 IP 暴露服務，選擇該值，服務只可以在集羣內部能夠訪問，這也是默認的 ServiceType。

• NodePort

經過每一個 Node 上的 IP 和靜態端口（NodePort）暴露服務。 NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動建立。 經過請求 : ，能夠從集羣的外部訪問一個 NodePort 服務。

• LoadBalancer

使用雲提供商的負載局衡器，能夠向外部暴露服務。 外部的負載均衡器能夠路由到 NodePort 服務和 ClusterIP 服務。

• ExternalName

經過返回 CNAME 和它的值，能夠將服務映射到 externalName 字段的內容（例如， foo.bar.example.com）。 沒有任何類型代理被建立。本文暫不討論這種類型。

參考文檔：https://cloud.tencent.com/document/product/457/45487

平臺相關基礎知識

騰訊雲容器服務（Tencent Kubernetes Engine ，TKE）基於原生 Kubernetes 提供以容器爲核心的、高度可擴展的高性能容器管理服務，徹底兼容原生 Kubernetes API ，同時擴展了騰訊雲的雲硬盤、負載均衡等 kubernetes 插件，爲容器化的應用提供高效部署、資源調度、服務發現和動態伸縮等一系列完整功能，解決用戶開發、測試及運維過程的環境一致性問題，提升了大規模容器集羣管理的便捷性，幫助用戶下降成本，提升效率。

2. TKE 上四層網絡流量暴露方式

TKE 上默認使用 service-controller 來管理 CLB 上四層監聽器和規則。這種方式， CLB 後端綁定每一個節點的 NodePort，CLB 接收外界流量，轉發到其中一個節點的 NodePort 上，再經過 Kubernetes 內部的負載均衡，使用 iptables 或 ipvs 轉發到 Pod。

請求細節過程：

• 請求流量進入負載均衡
• 請求被負載均衡轉發到某一個節點的 NodePort
• KubeProxy 未來自 NodePort 的流量進行 NAT 轉發，目的地址是隨機的一個 Pod
• 請求進入容器網絡，並根據 Pod 地址轉發到對應節點
• 請求來到 Pod 所屬節點，轉發到 Pod

實現結果以下圖：

參考文檔：https://cloud.tencent.com/document/product/457/45487

3. TKE 上七層網絡流量暴露方式

TKE 上默認使用 l7-lb-controller 做爲 Ingress 控制器，它會管理 CLB 上七層監聽器和規則。實現原理和請求細節同四層實現，可是在 CLB 層面會根據域名和 URL 來轉發到不一樣的後端 service，同時能夠進行 SSL 卸載。

實現細節：

使用 TKE 默認自帶的 Ingress，會爲每一個 Ingress 資源建立一個 CLB 以及 80，443 的 7 層監聽器規則(HTTP/HTTPS)，併爲 Ingress 每一個 location 綁定對應 TKE 各個節點某個相同的 NodePort 做爲 rs (每一個 location 對應一個 Service，每一個 Service 都經過各個節點的某個相同 NodePort 暴露流量)，CLB 根據請求匹配 location 轉發到相應的 rs (即 NodePort)，流量到了 NodePort 後會再通過 K8S 的 iptables 或 ipvs 轉發給對應的後端 Pod。

實現結果以下圖：

4. TKE 上的 VPC-CNI

TKE 一般用的 Global Router 網絡模式（網橋方案），還有一種是 VPC-CNI（彈性網卡方案）。VPC-CNI 是 TKE 上一種新的網絡模式，爲每一個 Pod 分配一個 ENI 彈性網卡的 EIP，Pod 間直接經過彈性網卡通訊。能夠理解爲：給每一個 Pod 分配了一個內網 IP。

優勢：每一個 Pod 均可以有內網 IP

缺點：須要分配一個單獨的空閒子網

參考文檔：https://cloud.tencent.com/document/product/457/41636

5. TKE 上 CLB 直通 Pod

TKE 的 CLB 默認綁定的都是 node 的 IP 和端口，在使用了 VPC-CNI 給 Pod 提供獨立內網 IP 以後，CLB 能夠直接綁定 Pod。

請求細節過程：

• 請求流量進入負載均衡
• 請求被負載均衡轉發到某一個 Pod 的 ENI 彈性網卡

參考文檔：https://cloud.tencent.com/document/product/457/41897

參考文檔：https://mp.weixin.qq.com/s/fJtlm5Qjm2BfzekC4RegCQ

實現結果以下圖，注意圖中的 ENI 彈性網卡和 Pod 的實際端口80：

6. TKE 使用已有負載均衡器

先建立 CLB

在 service 的 annotations 添加：

service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx

參考文檔：https://cloud.tencent.com/document/product/457/45491

7. TKE 使用內網負載均衡器

能夠經過指定使用已有內網負載均衡器實現。

也能夠經過如下方式動態建立：

在 service 的 annotations 添加：

service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxx # value 替換爲集羣所在 vpc 的其中一個子網 id

8. TKE 部署 Nginx Ingress

當 TKE 的默認 Ingress 實現（CLB 的7層規則）沒法知足業務需求時，能夠額外部署 Nginx Ingress（通常都用不上）

參考文檔：https://cloud.tencent.com/document/product/457/47293

實際業務場景的最佳實踐

1. 對集羣內暴露流量

【優先】四層協議：

• 【推薦】使用 ClusterIP 類型的 Service，並經過集羣內域名訪問
• 【可選】使用公網 CLB 的四層規則
• 【不推薦】使用內網 CLB 的四層規則

七層協議：

• 【推薦】使用 ClusterIP 類型的 Service，並經過集羣內域名訪問，降級爲四層協議
• 【可選】使用公網 CLB 的七層規則
• 【不推薦】使用內網 CLB 的七層規則

在集羣內使用內網 CLB 須要注意迴環問題，故不推薦集羣內使用內網 CLB。

2. 對集羣外暴露流量

建議生產環境均使用已有 CLB，即先手動建立 CLB，再在相關 Service 或 Ingress 指定 CLB 的 id。

TKE 默認控制器在 Service 使用以下配置：

service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx

同時 CLB 開啓「啓用默認放通」，CLB 和 CVM 之間默認放通，則不用根據 NodePort 調整 CVM 上的安全組，以下圖：

【優先】七層協議：

• 【推薦】 TKE 自帶 Ingress（3. TKE 上七層網絡流量暴露方式）
• 【可選】 自行部署Nginx Ingress（8. TKE 部署 Nginx Ingress）

四層協議：

• 【推薦】TKE 自帶 LoadBalancer（2. TKE 上四層網絡流量暴露方式）

使用Istio：

Istio 有點相似於 Nginx Ingress，都是先 CLB 四層監聽器轉發到 NodePort，再經過 istio-ingressgateway 這個 service 定義的規則，轉發到 istio-ingressgateway-xx 這個 Pod，再轉發到集羣內其餘 Istio Sidecar。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！