一文看懂 Kubernetes 服務發現： Service

時間 2020-12-09

標籤 node web docker 後端 centos api bash 網絡 session app 欄目 HTML 简体版

原文原文鏈接

Service 簡介

K8s 中提供微服務的實體是 Pod，Pod 在建立時 docker engine 會爲 pod 分配 ip，「外部」流量經過訪問該 ip 獲取微服務。可是，Pod 的狀態是不穩定的，它容易被銷燬，重建，一旦重建， Pod 的 ip 將改變，那麼繼續訪問原來 ip 是不現實的。針對這個問題 K8s 引入 services 這一 kind，它提供相似負載均衡的做用。與 Pod 不一樣 service 在建立時 K8s 會爲其分配一固定 ip，叫作 ClusterIP。外部流量訪問 ClusterIP 便可實現對 Pods 的訪問。

進一步的，經過如下示意圖說明 service 的工做原理：

如圖所示，service 定義了微服務的入口地址，它經過標籤選擇器匹配到須要轉發流量的 pod，將外部來的流量這裏是 frontend pod 來的流量引入到 Pod 中。

建立 Service

根據上節分析，這裏咱們經過配置 yaml 文件來建立 service，首先建立 service 須要「引流」的 Pods：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web_server
  template:
    metadata:
      labels:
        app: web_server
    spec:
      containers:
      - name: httpd-demo
        image: httpd

分別介紹上面參數：

apiVersion: 建立資源的 api 版本，這裏是 apps/v1。
kind: 建立的資源類型爲 Deployment。
metadata.name: 建立的 Deployment 名字。
replicas: 資源 Deployment 包括三個 Pods 副本。
matchLabels: 匹配到對應的 Pod 標籤。
labels: 副本 Pod 的標籤。
containers: Pod 內的 container，它是實際提供微服務的單元。

上面咱們建立了三個副本，且標籤爲 app:web_server，RC(replicationController) 經過 matchLabels 和建立的三個副本關聯。

繼續建立 service：

apiVersion: v1
kind: Service
metadata:
  name: httpd-svc
spec:
  selector:
    app: web_server
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80

建立名爲 httpd-svc 的 service，標籤選擇器將 service 的標籤 app:web_server 和對應的 pods 關聯。service 「對外」(對外實際上仍是在集羣內)開放的端口爲 8080，它將映射到 Pods 中的 80 端口。

Deployment，service 建立好後，咱們構建了以下的測試場景：

## 建立 Deployment
$ kubectl apply -f deployment-test.yaml
deployment.apps/bootcamp-deployment created
$ kubectl get deployments.apps
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
bootcamp-deployment   3/3     3            3           2m5s
$ kubectl get replicasets.apps
NAME                            DESIRED   CURRENT   READY   AGE
bootcamp-deployment-f94bcd74c   3         3         3       2m16s
$ kubectl get pods -o wide
NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
bootcamp-deployment-f94bcd74c-k4mrc   1/1     Running   0          3m17s   172.18.0.5   minikube   <none>           <none>
bootcamp-deployment-f94bcd74c-q2x6c   1/1     Running   0          3m17s   172.18.0.6   minikube   <none>           <none>
bootcamp-deployment-f94bcd74c-wwcqx   1/1     Running   0          3m17s   172.18.0.4   minikube   <none>           <none>
 
## 建立 Service
$ kubectl get services
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
httpd-svc    ClusterIP   10.108.52.85   <none>        8080/TCP   41s
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP    10m
 
## frontend pod
$ kubectl run kubernetes-bootcamp --image=docker.io/jocatalin/kubernetes-bootcamp:v1 --port=8080 --labels="app=bootcamp"
deployment.apps/kubernetes-bootcamp created
$ kubectl get pods -o wide
NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
bootcamp-deployment-f94bcd74c-k4mrc   1/1     Running   0          6m53s   172.18.0.5   minikube   <none>           <none>
bootcamp-deployment-f94bcd74c-q2x6c   1/1     Running   0          6m53s   172.18.0.6   minikube   <none>           <none>
bootcamp-deployment-f94bcd74c-wwcqx   1/1     Running   0          6m53s   172.18.0.4   minikube   <none>           <none>
kubernetes-bootcamp-9966c6d5-qpr9w    1/1     Running   0          14s     172.18.0.7   minikube   <none>           <none>

開始訪問 Service：

## cluster node 訪問
$ curl 172.18.0.5:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1
 
$ curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1
$ curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1
$ curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1

## frontend pod 訪問
$ kubectl exec -it kubernetes-bootcamp-9966c6d5-qpr9w /bin/bash
root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 172.18.0.5:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1
 
root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1
root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1
root@kubernetes-bootcamp-9966c6d5-qpr9w:/# curl 10.108.52.85:8080
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1

能夠看出，訪問 service 便是訪問與 service 關聯的 pod。這裏未指定 service 的負載分發策略，它有兩種策略 RoundRobin 和 SessionAffinity。默認策略爲 roundRobin 輪詢，即輪詢將請求轉發到後端各個 Pod。service 的 spec.sessionAffinity 字段可修改訪問策略，當值爲 ClientIP(默認爲空) 即表示將同一個客戶端的訪問請求轉發到同一個後端 Pod。

集羣外部訪問 Service

service 是 K8s 中的概念，它分配的 ip 是邏輯的，沒有實體的 ip。因此在 K8s 集羣外沒法訪問 service 的 ip，K8s 提供了 NodePort 和 LoadBalancer 兩種方式實現集羣外訪問 Service。這裏因實驗環境限制只介紹 NodePort 方式。

建立類型爲 NodePort 的 service：

## 命令行建立 service, 也可經過 yaml 文件建立
$ kubectl expose deployment/bootcamp-deployment --type="NodePort" --port 8080
service/bootcamp-deployment exposed
 
$ kubectl get service
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
bootcamp-deployment   NodePort    10.107.172.165   <none>        8080:32150/TCP   5s
httpd-svc             ClusterIP   10.108.52.85     <none>        8080/TCP         36m
kubernetes            ClusterIP   10.96.0.1        <none>        443/TCP          46m
 
$ kubectl describe service bootcamp-deployment
Name:                     bootcamp-deployment
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=web_server
Type:                     NodePort
IP:                       10.107.172.165
Port:                     <unset>  8080/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  32150/TCP
Endpoints:                172.18.0.4:8080,172.18.0.5:8080,172.18.0.6:8080
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

能夠看出，K8s 將 Service 的 8080 端口和 node 上的 32150 端口關聯，而且 node 上的 32150 端口被 (kube-proxy) 監聽：

$ netstat -antp | grep 32150
tcp6       0      0 :::32150                :::*                    LISTEN      4651/kube-proxy
 
$ ps aux | grep 4651 | grep -v grep
root      4651  0.0  1.2 140108 31048 ?  Ssl  07:15   0:01 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=minikube

外部訪問 NodePort Service 的 ClusterIP + Port，便可訪問到對應的 Pod：

$ curl 172.17.0.72:32150
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1
$ curl 172.17.0.72:32150
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-k4mrc | v=1

Service 的底層實現

探究 service 的底層實現就不得不提到 K8s 的核心組件 kube-proxy，它是一個位於 kube-system namespace 的 Pod，其核心功能是將到 service 的訪問請求轉發到後端 Pods：

$ kubectl get pods --namespace=kube-system | grep kube-proxy
kube-proxy-gk8zm                   1/1     Running   0          37s

kube-proxy 的工做流程大體爲，查詢和監聽 API server 的 services 和 Endpoints 變化，若是有變化則修改本機的 iptables。

kube-proxy 在 iptables 中自定義了 KUBE-SERVICES, KUBE-NODEPORTS，KUBE-POSTROUTING，KUBE-MARK-MASQ 和 KUBE-MARK-DROP 五個鏈，其中 KUBE-SERVICES 鏈用來添加流量路由規則。每一個鏈的做用分別爲：

KUBE-SERVICES：操做跳轉規則的主要鏈。
KUBE-NODEPORTS：經過 nodeport 訪問的流量通過的鏈。
KUBE-POSTROUTING：post 路由通過的鏈。
KUBE-MARK-MASQ：對符合條件的 package set MARK0x4000，有此標記的數據包會在 KUBE-POSTROUTING 鏈中作 MASQUERADE。
KUBE-MARK-DROP：對未能匹配到跳轉規則的package set mark 0x8000，有該標記的包會在 filter 表中被 drop 掉。

查看路由表，以類型爲 ClusterIP 的 service 爲例：

-A KUBE-SERVICES -d 10.108.52.85/32 -p tcp -m comment --comment "default/httpd-svc: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-RL3JAE4GN7VOGDGP

鏈 KUBE-SERVICES 的規則爲訪問目的地址 10.108.52.85，端口爲 8080 的數據包都被轉發到規則 KUBE-SVC-RL3JAE4GN7VOGDGP：

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-NGIJJXQTL6LQACUG
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KSASEUT37GIWYDZK
-A KUBE-SVC-RL3JAE4GN7VOGDGP -j KUBE-SEP-TTP6SZ4CLZYRFEZJ

規則 RL3JAE4GN7VOGDGP 有三條，三條規則分別是數據包隨機 1/3 的機率發到規則 KUBE-SEP-NGIJJXQTL6LQACUG，KSASEUT37GIWYDZK 和 KUBE-SEP-TTP6SZ4CLZYRFEZJ。再看這三條定義的是什麼規則：

-A KUBE-SEP-NGIJJXQTL6LQACUG -s 172.18.0.4/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-NGIJJXQTL6LQACUG -p tcp -m tcp -j DNAT --to-destination172.18.0.4:8080

三條規則都是相似的，以規則 NGIJJXQTL6LQACUG 爲例，其定義了兩條規則。第一條，若是發往 ClusterIP 的源 ip 地址是 172.18.0.4 則進入到鏈 KUBE-MARK-MASQ。第二條，若是是「外部」協議爲 tcp 的數據包進入該規則，則作目的 NAT 轉換，將目的地址轉換爲 Pod 的地址 172.18.0.4:8080。

繼續，查看類型爲 NodePort 的 service：

-A KUBE-SERVICES -d 10.107.172.165/32 -p tcp -m comment --comment "default/bootcamp-deployment: cluster IP" -m tcp --dport 8080 -j KUBE-SVC-7BU2JDGBFZPRVB5H

路由表中定義，集羣外部訪問 10.107.172.165 端口爲 8080 的地址的流量將跳轉到規則 KUBE-SVC-7BU2JDGBFZPRVB5H：

-A KUBE-SVC-7BU2JDGBFZPRVB5H -m statistic --mode random --probability0.33333333349 -j KUBE-SEP-JRC46L5OEHUJ3JOG
-A KUBE-SVC-7BU2JDGBFZPRVB5H -m statistic --mode random --probability0.50000000000 -j KUBE-SEP-RVACF472KUDH2WI5
-A KUBE-SVC-7BU2JDGBFZPRVB5H -j KUBE-SEP-NHLSGKWGDK2BACCW

相似的，規則 KUBE-SVC-7BU2JDGBFZPRVB5H 分別是數據包隨機 1/3 的機率發到規則 KUBE-SEP-JRC46L5OEHUJ3JOG，KUBE-SEP-RVACF472KUDH2WI5 和 KUBE-SEP-NHLSGKWGDK2BACCW。查看規則 KUBE-SEP-JRC46L5OEHUJ3JOG 定義：

-A KUBE-SEP-JRC46L5OEHUJ3JOG -s 172.18.0.4/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-JRC46L5OEHUJ3JOG -p tcp -m tcp -j DNAT --to-destination 172.18.0.4:8080

它有兩條規則，重點是第二條，當外部協議爲 tcp 的數據包到達該規則，則作目的 NAT 將數據包直接發到目的地址 172.18.0.4:8080。

Service 與 Endpoints

細心的讀者會發如今 service 的 describe 內容中有個 Endpoints 參數，它描述的是 service 所映射的後端 pod 的地址，以下所示：

$ kubectl describe service httpd-svc
Name:              httpd-svc
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"httpd-svc","namespace":"default"},"spec":{"ports":[{"port":8080,"...
Selector:          app=web_server
Type:              ClusterIP
IP:                10.108.52.85
Port:              <unset>  8080/TCP
TargetPort:        8080/TCP
Endpoints:         172.18.0.4:8080,172.18.0.5:8080,172.18.0.6:8080
Session Affinity:  None
Events:            <none>

selector 在匹配到對應的後端 pod 後，service 會更新 Endpoints 爲後端 pod 的地址。這裏咱們能夠構造這樣一種場景，service 不經過 selector 選擇後端 pod，而是直接將它與 Endpoints 作關聯：

建立 Endpoints:

apiVersion: v1
kind: Endpoints
metadata:
  name: httpd-svc-endpoints
subsets:
  - addresses:
    - ip: 1.2.3.4
    ports:
    - port: 80

建立 service：

apiVersion: v1
kind: Service
metadata:
  name: httpd-svc-endpoints
spec:
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
 
[centos@k8s-master-node-1 test]$ kubectl describe services httpd-svc-endpoints
Name:              httpd-svc-endpoints
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.102.65.186
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         1.2.3.4:80
Session Affinity:  None
Events:            <none>

建立完畢，能夠看到 service 的 Endpoints 更新爲提早建立好的 Endpoints，且 selector 爲 none。相應的，kube-proxy 會在路由表中創建 service 到 Endpoints 的規則。

除了不指定 selector，建立 service 時也能夠不指定 ClusterIP (ClusterIP: None)，不指定 ClusterIP 的 service 稱爲 Headless service，使用該 service 便是去中心化，外部流量直接獲取到後端 pod 的 Endpoints，而後自行選擇該訪問哪一個 pod。

Service 與 DNS

除了直接訪問 service ClusterIP 訪問後端 pod 外，還能夠經過 service 名，對於 NodePort 類型的 service 也可經過集羣 node 名訪問 pod。K8s 中實現名稱解析和 ip 對應的核心組件是 coredns：

$ curl minikube:32150
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-q2x6c | v=1
$ curl minikube:32150
Hello Kubernetes bootcamp! | Running on: bootcamp-deployment-f94bcd74c-wwcqx | v=1
 
$ kubectl get pods --namespace=kube-system -o wide | grep dns
coredns-6955765f44-rb828           1/1     Running   0          24m  172.18.0.3    minikube   <none>           <none>
coredns-6955765f44-rm4pv           1/1     Running   0          24m  172.18.0.2    minikube   <none>           <none>

集羣內部訪問 pod 的流量路徑大體爲流量訪問 service，經過 coredns 解析該 service 對應的 ClusterIP，繼續訪問 ClusterIP，當請求到達宿主機網絡後 kube-proxy 會對請求作攔截，根據路由表規則將請求轉發到後端 pod 實現服務發現和流量轉發。集羣外部訪問 pod 的流量路徑大體相似。

關於 Kubernetes 服務發現 service 就介紹到這裏，想繼續深刻了解，推薦看這篇博文。