如何通過(guò)Service 訪問Pod，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

創(chuàng)新互聯(lián)公司擁有網(wǎng)站維護(hù)技術(shù)和項(xiàng)目管理團(tuán)隊(duì)，建立的售前、實(shí)施和售后服務(wù)體系，為客戶提供定制化的網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、網(wǎng)站維護(hù)、簡(jiǎn)陽(yáng)服務(wù)器托管解決方案。為客戶網(wǎng)站安全和日常運(yùn)維提供整體管家式外包優(yōu)質(zhì)服務(wù)。我們的網(wǎng)站維護(hù)服務(wù)覆蓋集團(tuán)企業(yè)、上市公司、外企網(wǎng)站、商城網(wǎng)站定制開發(fā)、政府網(wǎng)站等各類型客戶群體，為全球上1000家企業(yè)提供全方位網(wǎng)站維護(hù)、服務(wù)器維護(hù)解決方案。

我們不應(yīng)該期望 Kubernetes Pod 是健壯的，而是要假設(shè) Pod 中的容器很可能因?yàn)楦鞣N原因發(fā)生故障而死掉。Deployment 等 controller 會(huì)通過(guò)動(dòng)態(tài)創(chuàng)建和銷毀 Pod 來(lái)保證應(yīng)用整體的健壯性。換句話說(shuō)，Pod 是脆弱的，但應(yīng)用是健壯的。

每個(gè) Pod 都有自己的 IP 地址。當(dāng) controller 用新 Pod 替代發(fā)生故障的 Pod 時(shí)，新 Pod 會(huì)分配到新的 IP 地址。這樣就產(chǎn)生了一個(gè)問題：

如果一組 Pod 對(duì)外提供服務(wù)（比如 HTTP），它們的 IP 很有可能發(fā)生變化，那么客戶端如何找到并訪問這個(gè)服務(wù)呢？

Kubernetes 給出的解決方案是 Service。

創(chuàng)建 Service

Kubernetes Service 從邏輯上代表了一組 Pod，具體是哪些 Pod 則是由 label 來(lái)挑選。Service 有自己 IP，而且這個(gè) IP 是不變的。客戶端只需要訪問 Service 的 IP，Kubernetes 則負(fù)責(zé)建立和維護(hù) Service 與 Pod 的映射關(guān)系。無(wú)論后端 Pod 如何變化，對(duì)客戶端不會(huì)有任何影響，因?yàn)?Service 沒有變。

來(lái)看個(gè)例子，創(chuàng)建下面的這個(gè) Deployment：

我們啟動(dòng)了三個(gè) Pod，運(yùn)行 httpd 鏡像，label 是 run: httpd，Service 將會(huì)用這個(gè) label 來(lái)挑選 Pod。

接下來(lái)創(chuàng)建 Service，其配置文件如下：

httpd-svc 分配到一個(gè) CLUSTER-IP 10.99.229.179?？梢酝ㄟ^(guò)該 IP 訪問后端的 httpd Pod。

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

關(guān)于如何通過(guò)Service 訪問Pod問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。