容器服務 TKE 上服務暴露的幾種方式
預備知識
1. K8S 上 Service 型別
- ClusterIP
通過叢集的內部 IP 暴露服務，選擇該值，服務只能夠在叢集內部可以訪問，這也是預設的 ServiceType。
- NodePort
通過每個 Node 上的 IP 和靜態埠（NodePort）暴露服務。 NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動建立。 通過請求
- 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。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！