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