本節開始學習 Service。
我們不應該期望 Kubernetes Pod 是健壯的,而是要假設 Pod 中的容器很可能因為各種原因發生故障而死掉。Deployment 等 controller 會通過動態創建和銷毀 Pod 來保證應用整體的健壯性。換句話說,Pod 是脆弱的,但應用是健壯的。
每個 Pod 都有自己的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時,新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題:
如果一組 Pod 對外提供服務(比如 HTTP),它們的 IP 很有可能發生變化,那么客戶端如何找到並訪問這個服務呢?
Kubernetes 給出的解決方案是 Service。
創建 Service
Kubernetes Service 從邏輯上代表了一組 Pod,具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP,而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP,Kubernetes 則負責建立和維護 Service 與 Pod 的映射關系。無論后端 Pod 如何變化,對客戶端不會有任何影響,因為 Service 沒有變。
來看個例子,創建下面的這個 Deployment:
我們啟動了三個 Pod,運行 httpd 鏡像,label 是 run: httpd
,Service 將會用這個 label 來挑選 Pod。
Pod 分配了各自的 IP,這些 IP 只能被 Kubernetes Cluster 中的容器和節點訪問。
接下來創建 Service,其配置文件如下:
① v1
是 Service 的 apiVersion
。
② 指明當前資源的類型為 Service
。
③ Service 的名字為 httpd-svc
。
④ selector
指明挑選那些 label 為 run: httpd
的 Pod 作為 Service 的后端。
⑤ 將 Service 的 8080 端口映射到 Pod 的 80 端口,使用 TCP 協議。
執行 kubectl apply
創建 Service httpd-svc
。
httpd-svc
分配到一個 CLUSTER-IP 10.99.229.179
。可以通過該 IP 訪問后端的 httpd Pod。
根據前面的端口映射,這里要使用 8080 端口。另外,除了我們創建的 httpd-svc
,還有一個 Service kubernetes
,Cluster 內部通過這個 Service 訪問 kubernetes API Server。
通過 kubectl describe
可以查看 httpd-svc
與 Pod 的對應關系。
Endpoints
羅列了三個 Pod 的 IP 和端口。我們知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?
答案是 iptables,我們下節討論。
書籍:
1.《每天5分鍾玩轉Docker容器技術》
https://item.jd.com/16936307278.html
2.《每天5分鍾玩轉OpenStack》
https://item.jd.com/12086376.html