如何訪問Pod


本章看點:

  1. 理清Deployment,ReplicaSet和Pod的關系,以及三者之間的網絡關系,ip地址和端口號
  2. 通過Pod進入docker容器修改里面的內容
  3. 外部網絡訪問Pod里面的應用

一、通過 Service 訪問 Pod

我們不應該期望 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:

# 創建
[root@kube-node1 tmp]# kubectl run test-nginx --image=nginx --replicas=3

# 查看deployment
# kubectl get deployment  -o wide
NAME         READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES        SELECTOR
test-nginx   3/3     3            3           103m    test-nginx   nginx         run=test-nginx

# 查看replicaset
# kubectl get replicaset -o wide
NAME                    DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES        SELECTOR
test-nginx-5f44949cd4   3         3         3       102m    test-nginx   nginx         pod-template-hash=5f44949cd4,run=test-nginx

# 查看pod
[root@kube-node1 tmp]# kubectl get pods  -o wide
NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
test-nginx-5f44949cd4-f55pm   1/1     Running   0          103m    172.30.112.6   kube-node1   <none>           <none>
test-nginx-5f44949cd4-sdgxd   1/1     Running   0          103m    172.30.48.4    kube-node2   <none>           <none>
test-nginx-5f44949cd4-zxqsc   1/1     Running   0          103m    172.30.32.7    kube-node3   <none>           <none>

# 注意查看pod的名稱

流程如下:
用戶通過kubectl創建Deployment
Deployment創建ReplicaSet
ReplicaSet創建Pod

對象的命名方式是:子對象的名字=父對象名字+隨機字符串或數字

我們啟動了三個 Pod,運行 nginx鏡像,label 是 run: test-nginx,Service 將會用這個 label 來挑選 Pod。

Pod 分配了各自的 IP,這些 IP 只能被 Kubernetes Cluster 中的容器和節點訪問,而不能被客戶端訪問。

# 查看pod的label
# 第一種方法
[root@kube-node1 tmp]# kubectl get replicaset -o wide
NAME                    DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES        SELECTOR
test-nginx-5f44949cd4   3         3         3       102m    test-nginx   nginx         pod-template-hash=5f44949cd4,run=test-nginx

# 如下是第二種方法
[root@kube-node1 tmp]# kubectl describe pod test-nginx-5f44949cd4-f55pm
Labels:             pod-template-hash=5f44949cd4
                    run=test-nginx

# 修改三個pod里nignx的首頁信息
# 這三個pod就是docker啟動的三個容器,使用進入容器的方法進行修改,使用下面的命令獲得容器相關信息
[root@kube-node1 tmp]#docker ps | grep "test-nginx" 
62c6ba6410d9    nginx   "nginx -g 'daemon of…"   2 hours ago         Up 2 hours                              k8s_test-nginx_test-nginx-5f44949cd4-zxqsc_default_cf77a798-0437-11ea-8ea0-000c291d1820_0

# 然后進入該容器進行首頁內容修改
[root@kube-node1 tmp]# docker exec -it 62c6ba6410d9 /bin/bash
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# echo "192.168.75.112" > /usr/share/nginx/html/index.html 
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# cat index.html 
192.168.75.110
root@test-nginx-5f44949cd4-zxqsc:/usr/share/nginx/html# exit

# 因為這三個pod分布在三個node節點上,所以另外兩個pod也按照這個方法進行修改

接下來創建 Service,其配置文件如下:

apiVersion: v1
kind: Service
metadata:
 name: nginx-svc
spec:
#  type: NodePort
 ports:
   - port: 80
     targetPort: 80
     protocol: TCP
#     nodePort: 26055
 selector:
   run: test-nginx

① v1 是 Service 的 apiVersion。

② 指明當前資源的類型為 Service

③ Service 的名字為 nginx-svc。

④ selector 指明挑選那些 label 為 run: test-nginx的 Pod 作為 Service 的后端。

⑤ 將 Service 的 80 端口映射到 Pod 的 80 端口,使用 TCP 協議。

執行 kubectl apply 創建 Service hnginx-svc。

[root@kube-node1 tmp]# kubectl apply -f nginx-svc.yml 
service "nginx-svc" configured

[root@kube-node1 tmp]# kubectl get service             
NAME          TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
nginx-svc     ClusterIP   10.254.148.192   <none>      80/TCP        11s

nginx-svc 分配到一個 CLUSTER-IP 10.254.148.192(service ip)。可以通過該 IP 訪問后端的 nginx Pod

根據前面的端口映射,這里要使用 80 端口。另外,除了創建的nginx-svc,還有一個 Service kubernetes,Cluster 內部通過這個 Service 訪問 kubernetes API Server。

也可以通過 kubectl describe 可以查看 nginx-svc與 Pod 的對應關系。

[root@kube-node1 tmp]# kubectl describe service nginx-svc
Name:              nginx-svc
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"nginx-svc","namespace":"default"},"spec":{"ports":[{"port":80,"pr...
Selector:          run=test-nginx
Type:              ClusterIP
IP:                10.254.148.192
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         172.30.112.6:80,172.30.32.7:80,172.30.48.4:80
Session Affinity:  None
Events:            <none>

可以看到nginx-svc服務端點將三個pod的ip地址都包含在內了,因此才可以通過訪問service的ip訪問到集群的后端節點。

在其他節點上嘗試訪問service:

# 可以看到是輪詢的方式進行訪問響應的
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.112
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.110
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.111

Endpoints 羅列了三個 Pod 的 IP 和端口。我們知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?

答案是 iptables

二、Service IP 原理

這個看看理解就行,不做深入研究

Service Cluster IP 是一個虛擬 IP,是由 Kubernetes 節點上的 iptables 規則管理的。

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

這條規則的含義是:

如果 Cluster 內的 Pod要訪問 httpd-svc,跳轉到規則 KUBE-SVC-RL3JAE4GN7VOGDGP

KUBE-SVC-RL3JAE4GN7VOGDGP 規則如下:

[root@node2 /]# iptables-save   | grep KUBE-SVC-RL3JAE4GN7VOGDGP-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-INLCIAMUGTXA7N36
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-R64ZBQQHUU433KVL
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -j KUBE-SEP-PV62YIJXJGRFPHFZ
  1. 1/2的概率跳轉到規則 KUBE-SEP-PV62YIJXJGRFPHFZ
  2. 1/2 的概率(剩下 2/3 的一半)跳轉到規則KUBE-SEP-R64ZBQQHUU433KVL

上面兩個跳轉的規則如下:

[root@node2 /]# iptables-save   | grep  KUBE-SEP-PV62YIJXJGRFPHFZ
:KUBE-SEP-PV62YIJXJGRFPHFZ - [0:0]
-A KUBE-SEP-PV62YIJXJGRFPHFZ -s 172.20.135.28/32 -m comment --comment "default/httpd-svc:" -j KUBE-MARK-MASQ
-A KUBE-SEP-PV62YIJXJGRFPHFZ -p tcp -m comment --comment "default/httpd-svc:" -m tcp -j DNAT --to-destination 172.20.135.28:80
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment --comment "default/httpd-svc:" -j KUBE-SEP-PV62YIJXJGRFPHFZ

即將請求分別轉發到后端的兩個 Pod。通過上面的分析,我們得到如下結論:

iptables 將訪問 Service 的流量轉發到后端 Pod,而且使用類似輪詢的負載均衡策略

另外需要補充一點:Cluster 的每一個節點都配置了相同的 iptables 規則,這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。

iptables規則相當於路標,給我們指引但不會直接給出目的地。

三、DNS 訪問 Service

這個看看理解就行,不做深入研究

在 Cluster 中,除了可以通過 Cluster IP 訪問 Service,Kubernetes 還提供了更為方便的 DNS 訪問。

DNS組件

kubeadm 部署時會默認安裝 kube-dns 組件。

 

coredns 是一個 DNS 服務器。每當有新的 Service 被創建,coredns 會添加該 Service 的 DNS  記錄。Cluster 中的 Pod 可以通過 <SERVICE_NAME>.<NAMESPACE_NAME> 訪問  Service。

比如可以用 httpd-svc.default 訪問 Service httpd-svc。

kubectl run busybox --rm -ti --image=[reg.yunwei.edu/learn/busybox:latest](http://reg.yunwei.edu/learn/busybox:latest) /bin/sh

wget httpd-svc:8080

四、外網訪問 Service

外網如何訪問 Service?

除了 Cluster 內部可以訪問 Service,很多情況我們也希望應用的 Service 能夠暴露給 Cluster 外部。Kubernetes 提供了多種類型的 Service,默認是 ClusterIP。

ClusterIP

Service 通過 Cluster 內部的 IP 對外提供服務,只有 Cluster 內的節點和 Pod 可訪問,這是默認的 Service 類型,前面實驗中的 Service 都是 ClusterIP。

NodePort

Service 通過 Cluster 節點的靜態端口對外提供服務。Cluster 外部可以通過 : 訪問 Service。

LoadBalancer

**Service 利用 cloud provider 特有的 load balancer 對外提供服務,cloud provider 負責將 load balancer 的流量導向 Service。**目前支持的 cloud provider 有 GCP、AWS、Azur 等。

下面我們來實踐 NodePort,Service nginx-svc 的配置文件修改如下:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      nodePort: 26055
  selector:
    run: test-nginx

添加 type: NodePort,重新創建 nginx-svc。查看service狀態

  

[root@kube-node1 tmp]# kubectl apply -f httpd-svc.yml 
[root@kube-node1 tmp]# kubectl get service
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
nginx-svc     NodePort    10.254.148.192   <none>        80:30001/TCP   27m

Kubernetes 依然會為 nginx-svc 分配一個 ClusterIP,不同的是:

  1. EXTERNAL-IP 為 none,表示可通過 Cluster 每個節點自身的 IP 訪問 Service。
  2. PORT(S) 為 80:30001。80 是 ClusterIP 監聽的端口,30001則是節點上監聽的端口。Kubernetes 會從 30000-32767 中分配一個可用的端口,每個節點都會監聽此端口並將請求轉發給 Service。

下面測試 NodePort 是否正常工作。

通過三個節點 IP + 30001端口都能夠訪問 nginx-svc。

NodePort 默認是的隨機選擇,不過我們可以用 nodePort 指定某個特定端口。

現在配置文件中就有三個 Port 了:

nodePort 是節點上監聽的端口。(意思是在其他節點上訪問 三個node節點ip:nodepoint

# 外放用戶訪問          
λ curl 192.168.75.110:30001 
192.168.75.111              
                                      
λ curl 192.168.75.111:30001 
192.168.75.111              
                                       
λ curl 192.168.75.112:30001 
192.168.75.111              

port 是 ClusterIP 上監聽的端口。

[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.110
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.111
[root@kube-node3 ~]# curl 10.254.148.192:80
192.168.75.112
[root@kube-node3 ~]# curl 10.254.148.192:80

targetPort 是 Pod 監聽的端口。

#pod端口也就是運行在node節點上的pod群
[root@kube-node1 tmp]# curl 172.30.112.6:80
192.168.75.110
[root@kube-node1 tmp]# curl 172.30.32.7:80
192.168.75.112
[root@kube-node1 tmp]# curl 172.30.48.4:80
192.168.75.111


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM