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

一、簡介

• 服務：一種為一組功能相同的 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 字段