service暴露端口的方式与代理的方式
Service 對(duì)外暴露與應(yīng)用
文章目錄
- Service 對(duì)外暴露與應(yīng)用
- 1 service介紹
- 2 Service的類型
- 3 service暴露端口的方式
- 4 service代理方式
- 5 實(shí)例
1 service介紹
- Service可以看作是一組提供相同服務(wù)的Pod對(duì)外的訪問(wèn)接口。借助- Service，應(yīng)用可以方便地實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡。
- service默認(rèn)只支持4層負(fù)載均衡能力，沒(méi)有7層功能。（可以通過(guò)Ingress實(shí)現(xiàn)）
2 Service的類型
- ClusterIP：默認(rèn)值，k8s系統(tǒng)給service自動(dòng)分配的虛擬IP，只能在集群內(nèi)部訪問(wèn)。
- NodePort：將Service通過(guò)指定的Node上的端口暴露給外部，訪問(wèn)任意一個(gè) NodeIP:nodePort都將路由到ClusterIP。
- LoadBalancer：在 NodePort 的基礎(chǔ)上，借助 cloud provider 創(chuàng)建一個(gè)外部的負(fù)載均 衡器，并將請(qǐng)求轉(zhuǎn)發(fā)到 :NodePort，此模式只能在云服務(wù)器上使用。
- ExternalName：將服務(wù)通過(guò) DNS CNAME 記錄方式轉(zhuǎn)發(fā)到指定的域名（通過(guò) spec.externlName 設(shè)定）。
3 service暴露端口的方式
方式1：clusterIP
- 此類型會(huì)提供一個(gè)集群內(nèi)部的虛擬IP（與pod不在同一網(wǎng)段），以供集群內(nèi)部的pod之間通信使用。clusterIP也是kubernetes service的默認(rèn)類型
主要需要以下幾個(gè)組件的協(xié)同工作 - apiservice：在創(chuàng)建service時(shí)，apiserver接收到請(qǐng)求以后將數(shù)據(jù)存儲(chǔ)到etcd中。
- kube-proxy：k8s的每個(gè)節(jié)點(diǎn)中都有該進(jìn)程，負(fù)責(zé)實(shí)現(xiàn)service功能，這個(gè)進(jìn)程負(fù)責(zé)感知service，pod的變化，并將變化的信息寫(xiě)入本地的iptables中
- iptables:使用NAT等技術(shù)獎(jiǎng)virtuallp的流量轉(zhuǎn)至endpoint中
方式2：NodePort
- NodePort模式除了使用cluster ip外，也將service的port映射到每個(gè)node的一個(gè)指定內(nèi)部的port上，映射的每個(gè)node的內(nèi)部port都一樣。為每個(gè)節(jié)點(diǎn)暴露一個(gè)端口，通過(guò)nodeIP+nodeport可以訪問(wèn)你這個(gè)服務(wù)，同時(shí)服務(wù)依然會(huì)有cluster類型的ip+port。內(nèi)部通過(guò)clusterip方式訪問(wèn)，外部通過(guò)nodeport方式訪問(wèn)
方式3：loadbalancer
- loadbalancer在nodeport基礎(chǔ)上，k8s可以請(qǐng)求底層云平臺(tái)創(chuàng)建一個(gè)負(fù)載均衡器，將每個(gè)node作為后端，進(jìn)行服務(wù)分發(fā)，該模式需要底層云平臺(tái)（例如GCE）支持
方式4：lngress
- lngress，是一種http方式的路由轉(zhuǎn)發(fā)機(jī)制由lngress controller和http代理服務(wù)器組合而成，lngress controller實(shí)例監(jiān)控kubernetes api，實(shí)時(shí)更新http代理服務(wù)器的轉(zhuǎn)發(fā)規(guī)則。http代理服務(wù)器有GCE load-balancer、haproxy、nginx等開(kāi)源方案
? service是一個(gè)抽象概念，定義了一個(gè)服務(wù)的多個(gè)pod邏輯合集和訪問(wèn)pod的策略，一般把service稱為微服務(wù).舉個(gè)例子一個(gè)a服務(wù)運(yùn)行3個(gè)pod，b服務(wù)怎么訪問(wèn)a服務(wù)的pod，pod的ip都不是持久化的重啟之后就會(huì)有變化。這時(shí)候b服務(wù)可以訪問(wèn)跟a服務(wù)綁定的service，service信息是固定的提前告訴b就行了，service通過(guò)Label Selector跟a服務(wù)的pod綁定,無(wú)論a的pod如何變化對(duì)b來(lái)說(shuō)都是透明的.
4 service代理方式
userspace代理模式
-
這種模式，kube-proxy 會(huì)監(jiān)視 Kubernetes master 對(duì) Service 對(duì)象和 Endpoints 對(duì)象的添加和移除。 對(duì)每一個(gè) Service，它會(huì)在本地 Node 上打開(kāi)一個(gè)端口（隨機(jī)選擇）。 任何鏈接到“代理端口”的請(qǐng)求，都會(huì)被代理到 Service 的backend Pods 中的某個(gè)上面（如 Endpoints 所報(bào)告的同樣）。 使用哪一個(gè) backend Pod，是 kube-proxy 基于 SessionAffinity 來(lái)肯定的。網(wǎng)絡(luò)
-
最后，它配置 iptables 規(guī)則，捕獲到達(dá)該 Service 的 clusterIP（是虛擬 IP）和 Port 的請(qǐng)求，并重定向到代理端口，代理端口再代理請(qǐng)求到 backend Pod。
-
默認(rèn)狀況下，userspace模式下的kube-proxy經(jīng)過(guò)循環(huán)算法選擇后端。
-
默認(rèn)的策略是，經(jīng)過(guò) round-robin 算法來(lái)選擇 backend Pod。
iptables 代理模式
-
這種模式，kube-proxy 會(huì)監(jiān)視 Kubernetes 控制節(jié)點(diǎn)對(duì) Service 對(duì)象和 Endpoints 對(duì)象的添加和移除。 對(duì)每一個(gè) Service，它會(huì)配置 iptables 規(guī)則，從而捕獲到達(dá)該 Service 的 clusterIP 和端口的請(qǐng)求，進(jìn)而將請(qǐng)求重定向到 Service 的一組 backend 中的某個(gè)上面。對(duì)于每一個(gè) Endpoints 對(duì)象，它也會(huì)配置 iptables 規(guī)則，這個(gè)規(guī)則會(huì)選擇一個(gè) backend 組合。
-
默認(rèn)的策略是，kube-proxy 在 iptables 模式下隨機(jī)選擇一個(gè) backend。
-
使用 iptables 處理流量具備較低的系統(tǒng)開(kāi)銷，由于流量由 Linux netfilter 處理，而無(wú)需在用戶空間和內(nèi)核空間之間切換。 這種方法也可能更可靠。
-
若是 kube-proxy 在 iptables模式下運(yùn)行，而且所選的第一個(gè) Pod 沒(méi)有響應(yīng)，則鏈接失敗。 這與userspace模式不一樣：在這種狀況下，kube-proxy 將檢測(cè)到與第一個(gè) Pod 的鏈接已失敗，并會(huì)自動(dòng)使用其余后端 Pod 重試。
-
咱們可使用 Pod readiness 探測(cè)器 驗(yàn)證后端 Pod 是否能夠正常工做，以便 iptables 模式下的 kube-proxy 僅看到測(cè)試正常的后端。這樣作意味著能夠避免將流量經(jīng)過(guò) kube-proxy 發(fā)送到已知已失敗的Pod。
IPVS 代理模式
-
在 ipvs 模式下，kube-proxy監(jiān)視Kubernetes服務(wù)(Service)和端點(diǎn)(Endpoints)，調(diào)用 netlink 接口相應(yīng)地建立 IPVS 規(guī)則， 并按期將 IPVS 規(guī)則與 Kubernetes服務(wù)(Service)和端點(diǎn)(Endpoints)同步。該控制循環(huán)可確保 IPVS 狀態(tài)與所需狀態(tài)匹配。訪問(wèn)服務(wù)(Service)時(shí)，IPVS 將流量定向到后端Pod之一。
-
IPVS代理模式基于相似于 iptables 模式的 netfilter 掛鉤函數(shù)，可是使用哈希表做為基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，而且在內(nèi)核空間中工做。 這意味著，與 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通訊的延遲要短，而且在同步代理規(guī)則時(shí)具備更好的性能。與其余代理模式相比，IPVS 模式還支持更高的網(wǎng)絡(luò)流量吞吐量。
-
IPVS提供了更多選項(xiàng)來(lái)平衡后端Pod的流量。分別是：
- rr: round-robin
- lc: least connection (smallest number of open connections)
- dh: destination hashing
- sh: source hashing
- sed: shortest expected delay
- nq: never queue
注意：要在 IPVS 模式下運(yùn)行 kube-proxy，必須在啟動(dòng) kube-proxy 以前使 IPVS Linux 在節(jié)點(diǎn)上可用。 當(dāng) kube-proxy 以 IPVS 代理模式啟動(dòng)時(shí)，它將驗(yàn)證 IPVS 內(nèi)核模塊是否可用。 若是未檢測(cè)到 IPVS 內(nèi)核模塊，則 kube-proxy 將退回到以 iptables 代理模式運(yùn)行。
5 實(shí)例
- 1、創(chuàng)建一個(gè)deployment副本數(shù)3，然后滾動(dòng)更新鏡像版本，并記錄這個(gè)更新記錄，最后再回滾到上一個(gè)版本
滾動(dòng)更新
格式：kubectl set image deployment.apps/{deployment名稱} {鏡像名稱}:={鏡像名稱}:{版本} [root@master mainfest]# kubectl set image deploy/test test=caiaoc/httpd:v1.0 deployment.apps/test image updated[root@master mainfest]# kubectl get pod //正在升級(jí)中(藍(lán)綠部署) NAME READY STATUS RESTARTS AGE test1-7697c79b78-f9zjf 0/1 ContainerCreating 0 14s test-9635b7736-4k75s 1/1 Running 0 4m26s test-9635b7736-hzq27 1/1 Running 0 4m26s test-9635b7736-p3k54 1/1 Running 0 4m26s [root@master mainfest]# kubectl get pod //已經(jīng)升級(jí)完成 NAME READY STATUS RESTARTS AGE test1-7697c79b78-5rn9f 1/1 Running 0 2m12s test1-7697c79b78-9fs4n 1/1 Running 0 67s test1-7697c79b78-wb95c 1/1 Running 0 68s回滾
//查看上線記錄 [root@master mainfest]# kubectl rollout history deploy test deployment.apps/test REVISION CHANGE-CAUSE 1 <none> 2 <none>[root@master mainfest]# kubectl rollout history deploy test --revision=2 //查看某一條上線記錄 deployment.apps/test with revision #2 Pod Template:Labels: app=testpod-template-hash=84644f7fbbContainers:test1Image: caiaoc/httpd:v1.0Port: <none>Host Port: <none>Environment: <none>Mounts: <none>Volumes: <none>//回滾到上一個(gè)版本 [root@master mainfest]# kubectl rollout undo deploy test deployment.apps/test1 rolled back [root@master mainfest]# kubectl rollout history deployment test deployment.apps/test REVISION CHANGE-CAUSE 2 <none> 3 <none>- 2.給一個(gè)應(yīng)用擴(kuò)容副本數(shù)為3
- 3、創(chuàng)建一個(gè)pod，其中運(yùn)行著nginx、redis、memcached 3個(gè)容器
- 4 給一個(gè)pod創(chuàng)建service，并可以通過(guò)ClusterIP/NodePort訪問(wèn)
- 5 創(chuàng)建deployment和service，使用busybox容器nslooup解析service
總結(jié)
以上是生活随笔為你收集整理的service暴露端口的方式与代理的方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： nokia x android 界面,诺
- 下一篇： SpringBoot时区配置