您好,登錄后才能下訂單哦!
我們這里準(zhǔn)備三臺機(jī)器,一臺master,兩臺node,采用kubeadm的方式進(jìn)行安裝的,安裝過程大家可以參照我之前的博文。
IP | 角色 | 版本 |
---|---|---|
192.168.1.200 | master | kubeadm v1.13.0 |
192.168.1.201 | node01 | kubeadm v1.13.0 |
192.168.1.202 | node02 | kubeadm v1.13.0 |
我們不應(yīng)該期望 Kubernetes Pod 是健壯的,而是要假設(shè) Pod 中的容器很可能因?yàn)楦鞣N原因發(fā)生故障而死掉。Deployment 等 controller 會通過動態(tài)創(chuàng)建和銷毀 Pod 來保證應(yīng)用整體的健壯性。換句話說,Pod 是脆弱的,但應(yīng)用是健壯的。
每個 Pod 都有自己的 IP 地址。當(dāng) controller 用新 Pod 替代發(fā)生故障的 Pod 時,新 Pod 會分配到新的 IP 地址。這樣就產(chǎn)生了一個問題:
如果一組 Pod 對外提供服務(wù)(比如 HTTP),它們的 IP 很有可能發(fā)生變化,那么客戶端如何找到并訪問這個服務(wù)呢?
Kubernetes 給出的解決方案是 Service。
Kubernetes Service 從邏輯上代表了一組 Pod,具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP,而且這個 IP 是不變的??蛻舳酥恍枰L問 Service 的 IP,Kubernetes 則負(fù)責(zé)建立和維護(hù) Service 與 Pod 的映射關(guān)系。無論后端 Pod 如何變化,對客戶端不會有任何影響,因?yàn)?Service 沒有變。
創(chuàng)建文件mytest-deploy.yaml
文件,增加如下內(nèi)容:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mytest
spec:
replicas: 3
template:
metadata:
labels:
run: mytest
spec:
containers:
- name: mytest
image: wangzan18/mytest:v1
ports:
- containerPort: 80
創(chuàng)建我們的 Pod。
[root@master ~]# kubectl apply -f mytest-deploy.yaml
deployment.extensions/mytest created
[root@master ~]#
[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mytest-88d46bf99-cd4zk 1/1 Running 0 70s 10.244.2.2 node02 <none> <none>
mytest-88d46bf99-fsmcj 1/1 Running 0 70s 10.244.1.3 node01 <none> <none>
mytest-88d46bf99-ntd5n 1/1 Running 0 70s 10.244.1.2 node01 <none> <none>
Pod 分配了各自的 IP,這些 IP 只能被 Kubernetes Cluster 中的容器和節(jié)點(diǎn)訪問。
創(chuàng)建文件mytest-svc.yaml
,新增如下內(nèi)容:
apiVersion: v1
kind: Service
metadata:
name: mytest-svc
spec:
selector:
run: mytest
ports:
- port: 80
targetPort: 8080
創(chuàng)建service。
[root@master ~]# kubectl apply -f mytest-svc.yaml
service/mytest-svc created
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 33m
mytest-svc ClusterIP 10.100.77.149 <none> 80/TCP 8s
mytest-svc
分配到一個 CLUSTER-IP 10.100.77.149
??梢酝ㄟ^該 IP 訪問后端的 mytest Pod。
[root@master ~]# curl 10.100.77.149
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-ntd5n | v=1
通過 kubectl describe
可以查看 mytest-svc
與 Pod 的對應(yīng)關(guān)系。
[root@master ~]# kubectl describe svc mytest-svc
Name: mytest-svc
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"mytest-svc","namespace":"default"},"spec":{"ports":[{"port":80,"t...
Selector: run=mytest
Type: ClusterIP
IP: 10.100.77.149
Port: <unset> 80/TCP
TargetPort: 8080/TCP
Endpoints: 10.244.1.2:8080,10.244.1.3:8080,10.244.2.2:8080
Session Affinity: None
Events: <none>
Endpoints 羅列了三個 Pod 的 IP 和端口。我們知道 Pod 的 IP 是在容器中配置的,那么 Service 的 Cluster IP 又是配置在哪里的呢?CLUSTER-IP 又是如何映射到 Pod IP 的呢?
Service Cluster IP 是一個虛擬 IP,是由 Kubernetes 節(jié)點(diǎn)上的 iptables 規(guī)則管理的。
可以通過 iptables-save
命令打印出當(dāng)前節(jié)點(diǎn)的 iptables 規(guī)則,因?yàn)檩敵鲚^多,這里只截取與 httpd-svc
Cluster IP 10.100.77.149
相關(guān)的信息:
[root@master ~]# iptables-save |grep 10.100.77.149
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.77.149/32 -p tcp -m comment --comment "default/mytest-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-XKNZ3BN47GCYFIPJ
這兩條規(guī)則的含義是:
mytest-svc
,跳轉(zhuǎn)到規(guī)則 KUBE-SVC-XKNZ3BN47GCYFIPJ
。那我們查看一下KUBE-SVC-XKNZ3BN47GCYFIPJ
規(guī)則是什么,內(nèi)容如下:
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3
KUBE-SEP-6VUP2B3YLPPLYJJV
。KUBE-SEP-ENVKJLELDEHDNVGK
。KUBE-SEP-IZPSUB6K7QCCEPS3
。上面的三條規(guī)則內(nèi)容分別如下:
轉(zhuǎn)發(fā)到Pod 10.244.1.2。
-A KUBE-SEP-6VUP2B3YLPPLYJJV -s 10.244.1.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-6VUP2B3YLPPLYJJV -p tcp -m tcp -j DNAT --to-destination 10.244.1.2:8080
轉(zhuǎn)發(fā)到Pod 10.244.1.3。
-A KUBE-SEP-ENVKJLELDEHDNVGK -s 10.244.1.3/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-ENVKJLELDEHDNVGK -p tcp -m tcp -j DNAT --to-destination 10.244.1.3:8080
轉(zhuǎn)發(fā)到Pod 10.244.2.2。
-A KUBE-SEP-IZPSUB6K7QCCEPS3 -s 10.244.2.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-IZPSUB6K7QCCEPS3 -p tcp -m tcp -j DNAT --to-destination 10.244.2.2:8080
可以看到講請求分別轉(zhuǎn)發(fā)到了后端的三個 Pod。由此我們可以看出 iptables
將訪問 Service 的流量轉(zhuǎn)發(fā)到后端 Pod,而且使用類似輪詢的負(fù)載均衡策略。
Cluster 的每一個節(jié)點(diǎn)都配置了相同的 iptables 規(guī)則,這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。
默認(rèn)缺省使用的是iptables
,如果kube-proxy
使用ipvs
進(jìn)行轉(zhuǎn)發(fā)的話,需要我們開啟ipvs
,具體可以查看我之前的部署博文。
開啟ipvs
之后的規(guī)則如下,看起來更加直觀,建議大家啟用ipvs
。
[root@master ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.17.0.1:32501 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
TCP 192.168.1.200:32501 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
TCP 10.96.0.1:443 rr
-> 192.168.1.200:6443 Masq 1 0 0
TCP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
TCP 10.99.143.93:80 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
TCP 10.244.0.0:32501 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
TCP 10.244.0.1:32501 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
TCP 127.0.0.1:32501 rr
-> 10.244.1.4:8080 Masq 1 0 0
-> 10.244.1.5:8080 Masq 1 0 0
-> 10.244.2.4:8080 Masq 1 0 0
UDP 10.96.0.10:53 rr
-> 10.244.0.4:53 Masq 1 0 0
-> 10.244.0.5:53 Masq 1 0 0
在 Cluster 中,除了可以通過 Cluster IP 訪問 Service,Kubernetes 還提供了更為方便的 DNS 訪問。
kubeadm 部署時會默認(rèn)安裝 coredns 組件。
[root@master ~]# kubectl get deploy -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
coredns 2/2 2 2 84m
coredns
是一個 DNS 服務(wù)器。每當(dāng)有新的 Service 被創(chuàng)建,coredns
會添加該 Service 的 DNS 記錄。Cluster 中的 Pod 可以通過 <SERVICE_NAME>.<NAMESPACE_NAME>
訪問 Service。
比如可以用 mytest-svc.default
訪問 Service mytest-svc
。
[root@master ~]# kubectl run busybox --rm -it --image=busybox /bin/sh
If you don't see a command prompt, try pressing enter.
/ # wget mytest-svc.default
Connecting to mytest-svc.default (10.100.77.149:80)
index.html 100% |*********************************************************| 70 0:00:00 ETA
/ #
如上所示,我們在一個臨時的 busybox Pod 中驗(yàn)證了 DNS 的有效性。另外,由于這個 Pod 與 mytest-svc 同屬于 default namespace,可以省略 default 直接用 mytest-svc 訪問 Service。
除了 Cluster 內(nèi)部可以訪問 Service,很多情況我們也希望應(yīng)用的 Service 能夠暴露給 Cluster 外部。Kubernetes 提供了多種類型的 Service,默認(rèn)是 ClusterIP。
ClusterIP
Service 通過 Cluster 內(nèi)部的 IP 對外提供服務(wù),只有 Cluster 內(nèi)的節(jié)點(diǎn)和 Pod 可訪問,這是默認(rèn)的 Service 類型,前面實(shí)驗(yàn)中的 Service 都是 ClusterIP。
NodePort
Service 通過 Cluster 節(jié)點(diǎn)的靜態(tài)端口對外提供服務(wù)。Cluster 外部可以通過 <NodeIP>:<NodePort>
訪問 Service。
LoadBalancer
Service 利用 cloud provider 特有的 load balancer 對外提供服務(wù),cloud provider 負(fù)責(zé)將 load balancer 的流量導(dǎo)向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
下面我們來實(shí)踐 NodePort,Service mytest-svc.yaml
的配置文件修改如下:
apiVersion: v1
kind: Service
metadata:
name: mytest-svc
spec:
type: NodePort
selector:
run: mytest
ports:
- port: 80
targetPort: 8080
添加 type: NodePort,重新創(chuàng)建 mytest-svc。
[root@master ~]# kubectl apply -f mytest-svc.yaml
service/mytest-svc configured
[root@master ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 98m
mytest-svc NodePort 10.100.77.149 <none> 80:31298/TCP 65m
Kubernetes 依然會為 mytest-svc 分配一個 ClusterIP,不同的是:PORT(S) 為 80:31298
。80 是 ClusterIP 監(jiān)聽的端口,31298 則是節(jié)點(diǎn)上監(jiān)聽的端口,我們可以使用節(jié)點(diǎn)的 IP:PORT 訪問 Pod。Kubernetes 會從 30000-32767 中分配一個可用的端口,每個節(jié)點(diǎn)都會監(jiān)聽此端口并將請求轉(zhuǎn)發(fā)給 Service。
[root@master ~]# curl 192.168.1.200:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.201:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
[root@master ~]# curl 192.168.1.202:31298
Hello Kubernetes bootcamp! | Running on: mytest-88d46bf99-cd4zk | v=1
接下來我們深入探討一個問題:Kubernetes 是如何將 <NodeIP>:<NodePort>
映射到 Pod 的呢?
與 ClusterIP 一樣,也是借助了 iptables。與 ClusterIP 相比,每個節(jié)點(diǎn)的 iptables 中都增加了下面兩條規(guī)則:
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/mytest-svc:" -m tcp --dport 31298 -j KUBE-SVC-XKNZ3BN47GCYFIPJ
規(guī)則的含義是:訪問當(dāng)前節(jié)點(diǎn) 31298 端口的請求會應(yīng)用規(guī)則 KUBE-SVC-XKNZ3BN47GCYFIPJ
,內(nèi)容為:
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-6VUP2B3YLPPLYJJV
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ENVKJLELDEHDNVGK
-A KUBE-SVC-XKNZ3BN47GCYFIPJ -j KUBE-SEP-IZPSUB6K7QCCEPS3
其作用就是負(fù)載均衡到每一個 Pod。NodePort 默認(rèn)是的隨機(jī)選擇,不過我們可以用 nodePort
指定某個特定端口。
apiVersion: v1
kind: Service
metadata:
name: mytest-svc
spec:
type: NodePort
selector:
run: mytest
ports:
- port: 80
nodePort: 30000
targetPort: 8080
nodePort
是節(jié)點(diǎn)上監(jiān)聽的端口。port
是 ClusterIP 上監(jiān)聽的端口。targetPort
是 Pod 監(jiān)聽的端口。最終,Node 和 ClusterIP 在各自端口上接收到的請求都會通過 iptables 轉(zhuǎn)發(fā)到 Pod 的 targetPort
。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。