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

這期內容當中小編將會給大家帶來有關容器服務TKE上服務暴露的幾種方式有哪些，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

預備知識

1. K8S 上 Service 類型

• ClusterIP

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

• NodePort

通過每個 Node 上的 IP 和靜態端口（NodePort）暴露服務。 NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動創建。 通過請求 <NodeIP>:<NodePort>，可以從集群的外部訪問一個 NodePort 服務。

• LoadBalancer

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

• ExternalName

通過返回 CNAME 和它的值，可以將服務映射到 externalName 字段的內容（例如， foo.bar.example.com）。 沒有任何類型代理被創建。

平臺相關基礎知識

騰訊云容器服務（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。

上述就是小編為大家分享的容器服務TKE上服務暴露的幾種方式有哪些了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。