Kubernetes 實戰——發現應用（Service）

LB477發表於2021-06-17

一、簡介

  • 服務：一種為一組功能相同的 Pod 提供單一不變的接入點的資源。服務 IP 和埠不會改變
  • 對服務的連線會被路由到提供該服務的任意一個 Pod 上（負載均衡）
  • 服務通過標籤選擇器判斷哪些 Pod 屬於服務

WHY Service

  • Pod 需要對叢集內部其他 Pod 或叢集外部客戶端 HTTP 請求作出響應
  • Pod 生命週期短，隨時啟動或關閉。K8s 在 Pod 啟動前為其分配 IP 地址，因此客戶端不能提前知道 Pod 的 IP 地址
  • 多個 Pod 可能提供相同的服務，因此需要單一的 IP 地址訪問

1. 建立服務

kubectl expose ...

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  selector:  # 該服務管理 app=kubia 的 Pod
    app: kubia
  ports:
  - port: 80  # 服務暴露埠
    targetPort: 8080  # 服務將連線轉發到的容器埠

測試

# 該服務叢集 IP 為 10.111.249.153，只能在叢集內部訪問
$ kubectl get svc
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubia          ClusterIP   10.111.249.153  <none>        80/TCP    2d16h

# 1. 在 K8s 節點 curl
$ curl 10.111.249.153
You've hit kubia-5fje3
# 2. 在執行的 Pod 容器中傳送 curl 命令（`--`表示 kubectl 命令的結束，後跟 Pod 內部執行的指令）
$ kubectl exec kubia-7nog1 -- curl -s http://10.111.249.153
You've hit kubia-gzwli

(1) 服務會話親和性

讓同一個 client IP 的請求轉發到同一個 Pod

spec:
  sessionAffinity: ClientIP  # 預設 None（僅支援這兩種）

服務會話親和性不能基於 Cookie

K8s 服務不是在 HTTP 層面上工作。服務處理 TCP 和 UDP 包，並不關心其中的荷載內容。而 cookie 是 HTTP 協議的一部分，服務並不知道它們

會話親和性和 Web 瀏覽器

瀏覽器使用 keep-alive 連線，通過單個連線傳送所有請求，而 curl 每次開啟一個新連線。服務在連線級別工作，因此當首次與服務連線時會隨機，但屬於該連線的所有網路資料包全部傳送到單個 Pod（即使服務會話親和性設定為 None），直到連線關閉

(2) 服務暴露多個埠

spec:
  ports:
  - name: http  # 多個埠的服務必須指定埠名字
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443

(3) 使用命名的埠（推薦）

kind: Pod
spec:
  containers:
  - name: kubia
    ports:
    - name: http  # 埠 8080 被命名為 http
      containerPort: 8080
    - name: https
      containerPort: 8443

kind: Service
spec:
  ports:
  - name: http
    port: 80
    targetPort: http  # 對映到容器中被稱為 http 的埠
  - name: https
    port: 443
    targetPort: https

2. 服務發現

Pod 獲取服務 IP 和埠

(1) 通過環境變數發現服務

Pod 啟動時，K8s 會初始化一系列環境變數指向現存的服務。若服務早於 Pod 建立，Pod 程式便可根據環境變數獲取服務資訊

規則：如名為backend-database的服務會生成BACKEND_DATABASE_SERVICE_HOST和BACKEND_DATABASE_SERVICE_PORT兩個環境變數

$ kubectl exec kubia-3inly env
KUBIA_SERVICE_HOST=10.111.249.153
KUBIA_SERVICE_PORT=80
...

(2) 通過 DNS 發現服務

kube-system 下的 kube-dns Pod 執行 DNS 服務，叢集中的其他 Pod 都被配置成使用其作為 dns（K8s 通過修改每個容器的 /etc/resolve.conf 實現）。因此，執行在 Pod 上的程式 DNS 查詢都會被 K8s 自身的 DNS 伺服器響應，該伺服器知道系統中執行的所有服務

Pod 是否使用內部的 DNS 伺服器是根據 Pod 中 spec.dnsPolicy 決定

$ kubectl get svc -n kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   3d20h
$ kubectl exec kubia-3inly -- cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
...

每個服務從內部 DNS 伺服器中獲得一個 DNS 條目，客戶端 Pod 在知道服務名稱的情況下可通過 FQDN（全限定域名）來訪問。格式為：<服務名稱>.<服務名稱空間>.svc.cluster.local。其中svc.cluster.local是在所有叢集本地服務名稱中使用的可配置叢集域字尾

客戶端仍需知道服務的埠號。服務可直接使用標準埠號（如 HTTP 的 80 埠或 Postgres 的 5432 埠）或從環境變數中獲取埠號

$ kubectl exec -it kubia-3inly bash
root@kubia-3inly:/# curl kubia.default.svc.cluster.local
You've hit kubia-3inly
# 若兩個 Pod 在同一個名稱空間，可直接使用服務名稱
root@kubia-3inly:/# curl kubia
You've hit kubia-5asi2
# 服務的叢集 IP 為虛擬 IP，且只有與服務埠結合時才有意義
root@kubia-3inly:/# ping kubia
6 packets transmitted, 0 packets received, 100% packet loss

二、連線叢集外部的服務

服務將請求重定向到外部 IP 和埠

1. 服務 Endpoint

  • 服務並不是和 Pod 直接相連，而是通過 Endpoint 資源：暴露一個服務的 IP 地址和埠的列表
  • 服務的 Pod 選擇器僅用來構建 IP 和埠列表，儲存在 Endpoint 資源中。當客戶端連線到服務時，服務代理會選擇一個 IP 進行重定向
$ kubectl get endpoints kubia
NAME       ENDPOINTS                                          AGE
kubia      10.108.1.4:8080,10.108.2.5:8080,10.108.2.6:8080    2h

2. 手動配置服務的 Endpoint

建立不包含 Pod 選擇器的服務將不會建立 Endpoint 資源，此時需要手動建立 Endpoint

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:  # 沒有指定 Pod 選擇器
  ports:
  - port: 80

apiVersion: v1
kind: Endpoints
metadata:
  name: external-service  # Endpoint 名稱需和服務名稱匹配
subsets:
  - addresses:  # 服務將連線重定向到 Endpoint 的 IP 地址
    - ip: 11.11.11.11
    - ip: 22.22.22.22
    ports:  # Endpoint 的目標埠
    - port: 80

3. 為外部服務建立別名

通過 FQDN（完全限定域名）訪問外部服務

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName  # 建立一個具有別名的外部服務的服務
  externalName: someapi.somecompany.com  # 實際服務的全限定名
  ports:
  - port: 80

Pod 通過external-service.default.svc.cluster.local訪問外部服務

ExternalName 服務僅在 DNS 級別實施，為服務建立了簡單的 CNAME DNS 記錄。因此連線到服務的客戶端將直接連線到外部服務，完全繞過服務代理。因此該型別服務不會獲得叢集 IP

CNAME 記錄指向完全限定的域名而不是數字 IP 地址

三、將服務暴露給外部客戶端

  • 將服務型別設定為 NodePort：每個叢集節點開啟一個埠，並將在該埠上收到的流量重定向到該服務
  • 將服務型別設定為 LoadBalance：NodePort 型別的一種擴充套件。服務通過一個專用的負載均衡器來訪問，客戶端通過負載均衡器的 IP 連線到服務
  • 建立一個 Ingress 資源：通過一個 IP 地址公開多個服務。執行在 HTTP 層（網路協議第七層，而服務執行在第四層）

1. 使用 NodePort 型別的服務

apiVersion: v1
kind: Service
metadata:
  name: kubia-nodeport
spec:
  type: NodePort  # 預設 ClusterIP
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30123  # 叢集節點埠（不指定則隨機）
  selector:
    app: kubia

可通過<node-ips>:30123或<cluster-ip>:80訪問

2. 使用 LoadBalancer 型別的服務

  • 負載均衡器擁有獨一無二的可公開訪問的 IP 地址，並將連線重定向到服務（節點無需關閉防火牆）
  • 若 K8s 在不支援 LoadBalancer 服務的環境中執行，則不會呼叫負載均衡器，此時服務仍表現為 NodePort 服務
spec:
  type: LoadBalancer

可通過<external-ip>:80訪問

3. 瞭解外部連線的特性

網路跳數

當訪問到某個節點的埠，服務隨機轉發 Pod，此時 Pod 可能不在此節點上，這就需要額外的網路跳轉。可將服務配置為僅將外部連線重定向到接收該連線的節點上的 Pod 來阻止跳轉：

spec:
  externalTrafficPolicy: Local

缺點：

  • 若無本地 Pod 存在，連線將掛起
  • 會導致 Pod 的負載分佈不均衡

客戶端 IP 不會被記錄

當通過節點埠接收到連線時，會對資料包進行 SNAT（源網路地址轉換），因此資料包的源 IP 將發生更改

Local 外部流量策略會保留客戶端 IP，因為接收連線的節點和 Pod 所在節點沒有額外跳躍（不執行 SNAT）

四、通過 Ingress 暴露服務

  • 每個 LoadBalancer 服務都需要自己的負載均衡器以及獨有的公有 IP，而 Ingress 只需一個公網 IP 便可為多個服務提供訪問
  • 客戶端傳送 HTTP 請求時，Ingress 會根據請求的主機名和路徑決定請求轉發到的服務
  • Ingress 在網路棧（HTTP）的應用層，可以提供一些服務不能實現的功能。如基於 cookie 的會話親和性
  • 只有 Ingress 控制器在叢集中執行，Ingress 資源才能正常工作。不同的 K8s 環境使用不同的控制器實現，但有些不提供預設控制器

1. 建立 Ingress 資源

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  # 接收所有請求主機 kubia.example.com 的 HTTP 請求，轉發到 kubia-nodeport 的 80 埠
  - host: kubia.example.com  # must be a DNS name, not an IP address
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

$ kubectl get ingress
NAME    CLASS    HOSTS               ADDRESS          PORTS   AGE
kubia   <none>   kubia.example.com   192.168.99.100   80      14s
# 要將域名解析為 Ingress 控制器的 IP
$ vi /etc/hosts
192.168.99.100 kubia.example.com
$ curl http://kubia.example.com
You've hit kubia-5asi2

2. Ingress 工作原理

  • 客戶端首先對 kubia.example.com 執行 DNS 查詢，DNS 伺服器（或本地作業系統）返回 Ingress 控制器的 IP
  • 客戶端向 Ingress 控制器傳送 HTTP 請求，並在 Host 頭中指定 kubia.example.com
  • 控制器從該頭部確定客戶端嘗試訪問哪個服務，通過與服務關聯的 EndPoint 檢視 Pod IP，並將請求轉發給其中一個 Pod

3. 暴露多個服務

將不同的服務對映到不同主機的不同路徑

需要將兩個域名都指向 Ingress 控制器的 IP 地址，通過 Host 頭判斷

spec:
  rules:
  - host: kubia.example.com
    http:
      paths:
      - path: /kubia
        backend:
          serviceName: kubia
          servicePort: 80
      - path: /foo
        backend:
          serviceName: foo
          servicePort: 80
  - host: bar.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: bar
          servicePort: 80

4. 處理 TLS 傳輸

  • Ingress 轉發 HTTPS 流量
  • 當客戶端建立到 Ingress 控制器的 TLS 連線時，客戶端和 Ingress 控制器之間的通訊是加密的，而控制器和後端 Pod 之間的通訊不是
kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key

kind: Ingress
spec:
  tls:  # tls 配置
  - hosts:  # 接收主機的 tls 連線
    - kubia.example.com
    serviceName: tls-secret  # 私鑰和證照

五、就緒探針

  • Pod 啟動時可能需要載入配置或資料，此時不要將請求轉發到這些 Pod，直到準備就緒
  • 就緒探針被定期呼叫（預設 10s/次），來確定 Pod 是否可以接收客戶端請求
  • 啟動容器時，可配置一個等待時間，等待後執行第一次就緒檢查，之後週期性呼叫就緒探針
  • 若 Pod 未準備就緒，則從服務中刪除該 Pod，就緒後再新增 Pod
  • 只要刪除容器，K8s 就會從所有服務中移除該容器，此時無需用就緒探針

型別

  • Exec 探針：由程式的退出狀態碼確定
  • HTTP GET 探針：向容器傳送請求，由響應狀態碼確定
  • TCP socket 探針：開啟一個 TCP 連線到容器的指定埠，由連線是否建立來確定

對比

  • 存活探針通過重啟異常容器來保持 Pod 正常工作
  • 就緒探針確保只有準備好的 Pod 才能接收請求

新增就緒探針

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia
        readinessProbe:
          exec:
            command: ["ls", "/var/ready"]
        ports:
        - containerPort: 8080

$ kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
kubia-5csgl   0/1     Running   0          2m5s
kubia-qj7gz   0/1     Running   0          2m5s
$ kubectl exec kubia-5csgl -- touch /var/ready
$ kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
kubia-5csgl   1/1     Running   0          3m43s
kubia-qj7gz   0/1     Running   0          3m43s

六、headless 服務

建立 headless 服務

apiVersion: v1
kind: Service
metadata:
  name: kubia-headless
spec:
  clusterIP: None  # headless
  selector:
    app: kubia
  ports:
  - port: 80
    targetPort: 8080

執行 DNS 查詢

# 建立可支援 DNS 查詢的 Pod
$ kubectl run dnsutils --image=tutum/dnsutils --command -- sleep infinity
pod/dnsutils created
# headless 服務返回的是（就緒的）Pod IP
$ kubectl exec dnsutils nslookup kubia-headless
...
Name:	kubia-headless.default.svc.cluster.local
Address: 10.42.0.20
Name:	kubia-headless.default.svc.cluster.local
Address: 10.42.0.19
# 常規服務返回的是 Cluster IP
$ kubectl exec dnsutils nslookup kubia
...
Name:	kubia.default.svc.cluster.local
Address: 10.43.99.228
  • 客戶端也可通過 headless 服務的 DNS 名稱直接連線到 Pod
  • headless 服務通過 DNS 輪詢機制提供 Pod 的負載均衡，而非服務代理
  • 可通過 DNS 查詢機制查詢未準備好的 Pod：使用 publishNotReadyAddresses 欄位

相關文章