摘要：原因解釋創(chuàng)建成功后，的將集群中的每個(gè)云主機(jī)節(jié)點(diǎn)作為自身的節(jié)點(diǎn)，端口為申明的值注意不是。如何獲取源對(duì)于需要明確知道客戶端來(lái)源地址的情況，我們需要顯示地將的設(shè)置成如下修改。重新部署服務(wù)后，再用瀏覽器訪問(wèn)，可以發(fā)現(xiàn)正確獲取了瀏覽器的訪問(wèn)。

ULB屬性修改的處理方法

如沒(méi)有實(shí)際需要，請(qǐng)避免修改ULB名稱及注釋

根據(jù)cloudprovider插件使用提醒，由UK8S cloudprovider創(chuàng)建的ULB不允許修改ULB名稱，如果您修改過(guò)ULB名稱，可以參考以下操作進(jìn)行關(guān)聯(lián)，避免影響線上業(yè)務(wù)。

操作方法

1. 修改UK8S集群中的service注釋，以下注釋僅限由UK8S創(chuàng)建的ULB添加。

# 增加ULB-id進(jìn)行關(guān)聯(lián)
service.beta.kubernetes.io/ucloud-load-balancer-id-provision:   

1. 升級(jí)UK8S集群cloudprovider插件至最新版本。

   UK8S cloudprovider插件在20.10.1版本后已經(jīng)默認(rèn)支持關(guān)聯(lián)ULB-id，避免用戶修改ULB名稱后影響cloudprovider重建ULB，升級(jí)文檔。

獲取真實(shí)客戶端IP

網(wǎng)絡(luò)編程中如何獲得對(duì)端IP

1. 如果是HTTP1.1協(xié)議，一般的反向代理或者負(fù)載均衡設(shè)備（如ULB7）支持X-Forwarded-For頭部字段，會(huì)在用戶的請(qǐng)求報(bào)文中加入類似X-Forwarded-For:114.248.238.236的頭部。Web應(yīng)用程序只需要解析該頭部即可獲得用戶真實(shí)IP。
2. 如果是TCP或UDP自定義協(xié)議，可以客戶端在協(xié)議字段里定義一個(gè)大端unsigned字段來(lái)保存自身IP，服務(wù)端把該字段解析出來(lái)然后調(diào)用inet_ntoa(3)等函數(shù)獲得ipv4點(diǎn)分字符串。
3. 如果2中協(xié)議不支持填寫自身IP，則服務(wù)端可以通過(guò)socket系統(tǒng)調(diào)用getpeername(2)來(lái)獲取對(duì)端地址。下文討論此方式。

Kubernetes Loadbalancer ULB4碰到的問(wèn)題

UK8S使用ULB4和ULB7來(lái)支持Loadbalancer類型的Service。對(duì)于ULB7，由于只支持HTTP協(xié)議且默認(rèn)支持X-Forwarded-For頭部，所以Web服務(wù)可以很容易獲取客戶端的真實(shí)IP。但對(duì)于使用ULB4接入的純四層協(xié)議的服務(wù)來(lái)說(shuō)，可能需要使用getpeername(2)來(lái)獲取客戶端真實(shí)IP。然而由于目前kube-proxy采用Iptables模式，后端pod內(nèi)的應(yīng)用程序的網(wǎng)絡(luò)庫(kù)調(diào)用getpeername(2)會(huì)無(wú)法獲得正確的IP地址。以下例子可以說(shuō)明問(wèn)題。

部署一個(gè)簡(jiǎn)單的webserver，通過(guò)Loadbalancer ULB4外網(wǎng)模式接入。

apiVersion: v1
kind: Service
metadata:
  name: ucloud-nginx
  labels:
    app: ucloud-nginx
  annotations:
    service.beta.kubernetes.io/ucloud-load-balancer-type: "outer"
    service.beta.kubernetes.io/ucloud-load-balancer-vserver-method: "source" 
spec:
  type: LoadBalancer
  ports:
    - protocol: "TCP"
      port: 80
      targetPort: 12345
  selector:
    app: ucloud-nginx

---
apiVersion: v1
kind: Pod
metadata:
  name: test-nginx
  labels:
    app: ucloud-nginx
spec:
  containers:
  - name: nginx
    image: uhub.service.ucloud.cn/wxyz/uk8s-helloworld:1.8
    ports:
     - containerPort: 12345

部署完畢后，Service狀態(tài)如下所示，可以通過(guò)EIP 117.50.3.206訪問(wèn)該服務(wù)。

# kubectl  get svc ucloud-nginx
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)        AGE
ucloud-nginx   LoadBalancer   172.17.179.247   117.50.3.206   80:43832/TCP   112s

服務(wù)本身的源碼非常簡(jiǎn)單，只返回客戶端地址，如下所示。

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "net/http/httputil"
)

func main() {
    log.Println("Server hello-world")
    http.HandleFunc("/" AppRouter)
    http.ListenAndServe(":12345" nil)
}

func AppRouter(w http.ResponseWriter r *http.Request) {
    dump _ := httputil.DumpRequest(r false)
    log.Printf("%q
" dump)
    io.WriteString(w fmt.Sprintf("Guest come from %v
" r.RemoteAddr))
    return
}

在外網(wǎng)通過(guò)瀏覽器訪問(wèn)該服務(wù)，如下所示。

結(jié)果顯示用戶的訪問(wèn)IP地址是一臺(tái)云主機(jī)的內(nèi)網(wǎng)IP地址，顯然不正確。

原因解釋

Loadbalancer創(chuàng)建成功后，ULB4的VServer將UK8S集群中的每個(gè)Node云主機(jī)節(jié)點(diǎn)作為自身的RS節(jié)點(diǎn)，RS端口為Service申明的Port值（注意不是NodePort）。ULB4將訪問(wèn)流量轉(zhuǎn)發(fā)到其中一個(gè)RS后，RS根據(jù)本機(jī)上kube-proxy生成的iptables規(guī)則將流量DNAT到后端Pod中，如下所示。

圖中ULB4先將流量轉(zhuǎn)發(fā)到Node1中，Node1中根據(jù)iptables DNAT規(guī)則，將流量轉(zhuǎn)發(fā)給Node2中的Pod。
需要注意的是，Node1將IP包轉(zhuǎn)發(fā)到Node2前，對(duì)這個(gè)包有一次SNAT操作。準(zhǔn)確地說(shuō)，是一次MASQUERADE操作，規(guī)則如下。

-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE

這條規(guī)則將源地址改成Node1的本機(jī)地址，即10.9.31.26。當(dāng)然，這個(gè) SNAT 操作只針對(duì)本Service轉(zhuǎn)發(fā)出來(lái)的包，否則普通的IP包也受到影響了，而判定IP包是否由本Service轉(zhuǎn)發(fā)出來(lái)的依據(jù)是改包上是有有個(gè)"0x4000"標(biāo)志，這個(gè)標(biāo)志則是在DNAT操作前打上去的。

由于IP請(qǐng)求包的源地址被修改，Pod內(nèi)的程序網(wǎng)絡(luò)庫(kù)通過(guò)getpeername(2)調(diào)用獲取到的對(duì)端地址是Node1的IP地址而不是客戶端真實(shí)的地址。

為什么需要對(duì)流出的包做SNAT操作呢？

原因比較簡(jiǎn)單。參考下圖，當(dāng)Node1上的Pod處理完請(qǐng)求后，需要發(fā)送響應(yīng)包，如果沒(méi)有SNAT操作，Pod收到的請(qǐng)求包源地址就是client的IP地址，這時(shí)候Pod會(huì)直接將響應(yīng)包發(fā)給client的IP地址，但對(duì)于client程序來(lái)說(shuō)，它明明沒(méi)有往PodIP發(fā)送請(qǐng)求包，卻收到來(lái)自Pod的IP包，這個(gè)包很可能會(huì)被client丟棄。而有了SNAT，Pod會(huì)將響應(yīng)包發(fā)給Node1，Node1再根據(jù)DNAT規(guī)則產(chǎn)生的conntrack記錄，將響應(yīng)包通過(guò)返回給client。

        client
          ^
           
           v 
            ulb4
              ^
               
               v 
   node 1 <--- node 2    
    | ^   SNAT
    | |   --->
    v |
 endpoint

如何獲取源IP？

對(duì)于Pod需要明確知道客戶端來(lái)源地址的情況，我們需要顯示地將Service的spec.externalTrafficPolicy設(shè)置成Local如下修改。

apiVersion: v1
kind: Service
metadata:
  name: ucloud-nginx
  labels:
    app: ucloud-nginx
  annotations:
    service.beta.kubernetes.io/ucloud-load-balancer-type: "outer"
    service.beta.kubernetes.io/ucloud-load-balancer-vserver-method: "source"
spec:
  type: LoadBalancer
  ports:
    - protocol: "TCP"
      port: 80
      targetPort: 12345
  selector:
    app: ucloud-nginx
  externalTrafficPolicy: Local 

重新部署服務(wù)后，再用瀏覽器訪問(wèn)，可以發(fā)現(xiàn)Pod正確獲取了瀏覽器的訪問(wèn)IP。

而這個(gè)機(jī)制的原理也很簡(jiǎn)單，當(dāng)設(shè)置了externalTrafficPolicy為L(zhǎng)ocal時(shí)，Node上的iptables規(guī)則會(huì)設(shè)置只將IP包轉(zhuǎn)發(fā)到在本機(jī)上運(yùn)行的Pod，如果本機(jī)上無(wú)對(duì)應(yīng)Pod在運(yùn)行，此包將被DROP。如下圖，這樣Pod可以直接使用client的源地址進(jìn)行回包而不需要SNAT操作。

      client
        ^
         
         v  
        ulb4
       ^ /   
      / /       VServer健康檢查失敗
     / v       X
   node 1     node 2
    ^ |
    | |
    | v
 endpoint

對(duì)于其他未運(yùn)行Service對(duì)應(yīng)Pod的Node節(jié)點(diǎn)來(lái)說(shuō)，ULB VServer對(duì)其健康檢查探測(cè)會(huì)因?yàn)閕ptables的DROP規(guī)則而失敗，這樣來(lái)自用戶的請(qǐng)求永遠(yuǎn)不會(huì)被發(fā)往這些節(jié)點(diǎn)上，可以確保這些請(qǐng)求都能被正確響應(yīng)。

實(shí)時(shí)文檔歡迎訪問(wèn)https://docs.ucloud.cn/uk8s/service/change_ulb_name