如何在容器服務TKE上使用LB直通Pod，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

十載的歙縣網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網站的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整歙縣建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“歙縣網站設計”,“歙縣網站推廣”以來，每個客戶項目都認真落實執(zhí)行。

什么是 LB 直通 Pod ?

Kubernetes 官方提供了 NodePort 類型的 Service，即給所有節(jié)點開一個相同端口用于暴露這個 Service，大多云上 LoadBalancer 類型 Service 的傳統(tǒng)實現(xiàn)也都基于 NodePort，即 LB 后端綁各節(jié)點的 NodePort，LB 接收外界流量，轉發(fā)到其中一個節(jié)點的 NodePort 上，再通過 Kubernetes 內部的負載均衡，使用 iptables 或 ipvs 轉發(fā)到 Pod:

TKE 默認的 LoadBalancer 類型 Service 與默認的 Ingress 也都是這樣實現(xiàn)的，但目前也支持了 LB 直通 Pod 的方式，即 LB 后端直接綁 Pod IP+Port，不綁節(jié)點的 NodePort:

為什么需要 LB 直通 Pod ?

LB 直接綁 NodePort 來實現(xiàn)云上的 Ingress 或 LoadBalancer 類型 Service 是最簡單通用的方法，那為什么有了這種實現(xiàn)還不夠，還要搞個 LB 直通 Pod 的模式？

首先，我們分析下傳統(tǒng) NodePort 實現(xiàn)方式存在的一些問題：

1. 流量從 LB 轉發(fā)到 NodePort 之后還需要進行 SNAT，再轉發(fā)到 Pod，會帶來一些額外的性能損耗。

2. 如果流量過于集中到某幾個 NodePort 時(比如使用 nodeSelector 部署網關到固定幾臺節(jié)點上)，可能導致源端口耗盡，或者 conntrack 插入沖突。

3. NodePort 本身也充當負載均衡器，LB 綁定過多節(jié)點 NodePort 可能導致負載均衡狀態(tài)過于分散，導致全局負載不均。

如果使用 LB 直通 Pod 的方式，以上問題都將消失，并且還有一些其它好處：

1. 由于沒有 SNAT，獲取源 IP 不再需要 externalTrafficPolicy: Local 。

2. 實現(xiàn)會話保持更簡單，只需要讓 CLB 開啟會話保持即可，不需要設置 Service 的 sessionAffinity。

所以使用 LB 直通 Pod 的場景通常有:

1. 在四層獲取客戶端真實源 IP，但又不希望通過使用 externalTrafficPolicy: Local 的方式。

2. 希望進一步提升網絡性能。

3. 讓會話保持更容易。

4. 解決全局連接調度的負載不均。

需要什么前提條件 ?

使用 LB 直通 Pod，需要滿足以下前提條件：

1. Kubernetes集群版本需要高于 1.12，因為 LB 直綁 Pod，檢查 Pod 是否 Ready，除了看 Pod 是否 Running、是否通過 readinessProbe 外， 還需要看 LB 對 Pod 的健康探測是否通過，這依賴于 ReadinessGate 特性，該特性在 Kubernetes 1.12 才開始支持。

2. 集群網絡模式必須開啟VPC-CNI彈性網卡模式，因為目前 LB 直通 Pod 的實現(xiàn)是基于彈性網卡的，普通的網絡模式暫時不支持，這個在未來將會支持。

怎么用 ?

由于目前 LB 直通 Pod 依賴 VPC-CNI，需要保證 Pod 使用了彈性網卡:

1. 如果集群創(chuàng)建時選擇的是 VPC-CNI 網絡插件，那么創(chuàng)建的 Pod 默認就使用了彈性網卡。

2. 如果集群創(chuàng)建時選擇的是 Global Router 網絡插件，后來開啟了 VPC-CNI 支持，即兩種模式混用，創(chuàng)建的 Pod 默認不使用彈性網卡，需要使用 yaml 創(chuàng)建工作負載，為 Pod 指定 tke.cloud.tencent.com/networks: tke-route-eni 這個 annotation 來聲明使用彈性網卡，并且為其中一個容器加上 tke.cloud.tencent.com/eni-ip: "1" 這樣的 requests 與 limits，示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment-eni
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        tke.cloud.tencent.com/networks: tke-route-eni
      labels:
        app: nginx
    spec:
      containers:
        - image: nginx
          name: nginx
          resources:
            requests:
              tke.cloud.tencent.com/eni-ip: "1"
            limits:
              tke.cloud.tencent.com/eni-ip: "1"

當你用 LoadBalancer 的 Service 暴露服務時，需要聲明使用直連模式：

1. 如果通過控制臺創(chuàng)建 Service，可以勾選 采用負載均衡直連Pod模式:

2. 如果通過 yaml 創(chuàng)建 Service，需要為 Service 加上 service.cloud.tencent.com/direct-access: "true" 的 annotation:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.cloud.tencent.com/direct-access: "true"
  labels:
    app: nginx
  name: nginx-service-eni
spec:
  externalTrafficPolicy: Cluster
  ports:
  - name: 80-80-no
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

當使用 Ingress 暴露服務時，同樣也需要聲明使用直連模式:

1. 如果通過控制臺創(chuàng)建 Ingress，可以勾選 采用負載均衡直連Pod模式:

2. 如果通過 yaml 創(chuàng)建 Ingress，需要為 Ingress 加上 ingress.cloud.tencent.com/direct-access: "true" 的 annotation:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.cloud.tencent.com/direct-access: "true"
    kubernetes.io/ingress.class: qcloud
  name: test-ingress
  namespace: default
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
        path: /

關于如何在容器服務TKE上使用LB直通Pod問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。