kubernets kube-proxy原理分析

kube-proxy

service是一組pod的服務抽象,相當於一組pod的LB,負責將請求分發給對應的pod。service會爲這個LB提供一個IP,一般稱爲cluster IP。

kube-proxy的作用主要是負責service的實現,具體來說,就是實現了內部從pod到service和外部的從node port向service的訪問

cat nginx.yaml    部署該deploment 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: apigw-test1
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: test1
    spec:
      #hostNetwork: true
      containers:
      - name: apigw1
        image: apigw:696
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 2
            memory: 2Gi
          limits:
            cpu: 2
            memory: 2Gi


創建service

cat nginx-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: apigw-test1
  labels:
    app: test1
spec:
  type: NodePort
  selector:
    app: test1
  ports:
  - port: 6666
    targetPort: 80
    nodePort: 30066
    
kubectl create -f nginx-svc.yaml


前面創建了nginx的部署對象,那麼別人如何使用nginx這個服務呢?首先要確定的是,這個nginx服務,是給內部使用的,還是外部。如果是內部使用,那就可以不用設置服務的類型(默認爲ClusterIP),

否則,可以將服務類型設置爲NodePort,通過node的端口暴露出來給外部使用;或者是LoadBalancer,由雲服務商提供一個負載均衡直接掛在服務上。

這裏我們使用NodePort,暴露出30066端口給外部使用。如果不指定nodePort,那麼kubernetes會隨機生成一個


這裏我們用1個service+2個pod來舉例說明

wKiom1i34aehpgpyAAFc7UJEH7E421.png


wKiom1i34dLgVmXfAAGhwT15uBA861.png

port和nodePort都是service的端口,前者暴露給集羣內客戶訪問服務,後者暴露給集羣外客戶訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入後端pod的targetPod,從而到達pod上的容器內。



apigw-test1-2790435668-xkt56  ip:192.168.64.130/32

apigw-test1-2790435668-r69sr  ip:  192.168.83.197/32

wKiom1i34iyBE-ybAACTkI0u3zM181.png


整體流程圖如下

wKioL1i34mORjg4UAABtclsTOeA836.png

-A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-FOCF455PUHPZHEKG --mask 255.255.255.255 --rsource -j KUBE-SEP-FOCF455PUHPZHEKG

 

實現了會話保持

 

-A KUBE-SEP-FOCF455PUHPZHEKG -p tcp -m comment --comment "default/kubernetes:https" -m recent --set --name KUBE-SEP-FOCF455PUHPZHEKG --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 172.16.18.124:6443


關鍵點解釋:

KUBE-NODEPORTS   鏈跳轉到如下兩條鏈

1、KUBE-MARK-MASQ  --set-xmark 0x4000/0x4000  SANT

該鏈的作用主要是做數據標記,以及後續對這些標記的數據做SNAT

2、KUBE-SVC-4FIAYNHBEFBB6ATU  會跳轉到如下兩條鏈

2、1  KUBE-SEP-ZMVIR553ITG5JAPJ  (-m statistic --mode random --probability 0.50000000000)

該鏈主要兩個做個 一個SANT  一個DNAT,請參考上圖說明


2、2  KUBE-SEP-S6UNEDQPTOJETSJC  作用等同於2、1


 服務配置了session affinity,則會產生如下的規則  


wKiom1i34s_jRuqzAAGSs-sDJQ4324.png


-m recent --rcheck --seconds 10800 --reap 實現了會話保持

來自於default/kubernetes:https這個服務,流經KUBE-SVC-NPX46M4PTMTKRN6Y這個鏈的數據包會跳轉到自定義鏈KUBE-SEP-FOCF455PUHPZHEKG,且會在一段時間內保持session affinity,保持時間是10800

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章