共計 3158 個字符，預計需要花費 8 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關容器服務 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 間直接通過彈性網卡通信?？梢岳斫鉃椋航o每個 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 的其中一個子網 id8. 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。
上述就是丸趣 TV 小編為大家分享的容器服務 TKE 上服務暴露的幾種方式有哪些了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
