kubernetes為我們提供了更方便管理容器的方式，大服務集群環境下不需要開發人員去關注底層的網絡層邏輯，就能創建出一個穩定的集群服務。

下圖說明了pod和service的關聯原理圖，且說明了服務之間通信數據轉發的原理

service和pod關聯原理圖

創建有副本的pod

當我們創建pod時，僅僅是創建了pod，要為其創建rc(ReplicationController)，他才會有固定的副本。

創建service

然后為其創建service，集群內部才能訪問該pod，使用 NodePort 或者 LoadBalancer 類型的 Service，外部網絡也可以訪問該pod；每個 service 會創建出來一個虛擬 ip，通過訪問 vip:port 就能獲取服務的內容(內部訪問，因為這是一個vip，外部無法訪問的)
創建service時，其配置文件中的selector:指定后端綁定的pod，

例如serviceA的

selector:
app：a
env：dev

podA

labels：
app：a
env：dev

podB

labels：
app：a
env：dev
那么我們的serviceA 就會綁定podA,podB，綁定的pod的ip會填寫到serviceA的endpoint中，內部訪問(vip：port方式訪問)serviceA，根據serviceA的vip：port直接訪問，serviceA會隨機的將服務轉發給后端的pod(podA，podB)已上實現是通過kube-proxy實現的，kube-proxy默認使用iptables模，實際中使用ipvs會更實用；

kube-proxy的模式

• userspace: client -> iptables -> kube-proxy -> backend pod(rr), iptables只是把虛ip轉換成kube-proxy的ip，通過kube-proxy自己維護的不同端口來輪詢轉發到后端的pod上。

• iptables: client -> iptables -> backend pod(random)，kube-proxy只是監聽master上service的創建，之后動態添加/刪除本機上的iptables規則

• ipvs: client -> ipvs ->backend pod, ipvs是一個內核模塊

在ipvs模式下，kube-proxy監聽API Server中service和endpoint的變化情況，調用netlink接口創建相應的ipvs規則，并定期將ipvs規則與Kubernetes服 Services和Endpoints同步。保證IPVS狀態。當訪問Services時，IPVS將流量定向到后端pod之一。

• ipvs 為大型集群提供了更好的可擴展性和性能

• ipvs 支持比 iptables 更復雜的負載均衡算法(最小負載、最少連接、加權等等)

• ipvs 支持服務器健康檢查和連接重試等功能

服務發現

在k8s中用了兩個方案讓服務使用方找到我們定義的Service：環境變量 和 DNS。

環境變量
每當有service被創建出來之后，各個node(宿主機)上的kubelet，就會把service name加到自己宿主機的環境變量中，供所有Pod使用。環境變量的命名規則是

{SERVICE_NAME}_SERVICE_HOST,

${SERVICE_NAME}SERVICE_PORT，其中SERVICE_NAME是新serviceName的大寫形式，serviceName中的橫杠-會被替換成下劃線.
使用環境變量有一個隱含的創建順序，即服務使用方在通過環境變量訪問一個service的時候，這個service必須已經存在了。
使用env命令可以看到pod內部有很多kubernetes內部組件的環境變量

DNS
這是官方不推薦的做法，推薦用來跟k8s的外部服務進行交互。

總結

以上是生活随笔為你收集整理的service能去调另外一个service吗_kubernetes的service和pod是如何关联的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。