其實操作到這裏，有必要深入的了解K8s的網絡運行機制和基本結構，否則當真的遇到問題的時候會比較郁悶。
首先，要理解K8s的用處其實是容器的編排和管理，最小組成其實不是容器，是pod，物理機或者虛擬機叫node，pod是基礎單元，pod裏可以有多個容器，也可以只有壹個容器，同壹個pod的容器彼此是***享網絡和主機配置的，換句話說，彼此是可以直接localhost通信的，類似於同壹臺機器上進行通信，所以這裏面是無所謂隔離和安全壹說，對外而言就是壹個環境，所以pod就是這個環境的業務實體。所以，第壹個問題來了，同壹個pod的不同容器可以位於不同的node上嗎？當然不行，必須在同壹個node上，因為***享主機和網絡。那麽怎麽才能知道壹個pod有多個容器？kubectl exec的時候是否可以指定需要運行的容器？當然可以，參考如下指令：
所以，這裏可以忽略容器的概念，單單考慮pod，畢竟pod才是k8s最小的調度單元。那pod和pod是怎麽通信的呢？
pod的通信離不開K8s的網絡模型：
flannel組建壹個大二層扁平網絡，pod的ip分配由flannel統壹分配，通訊過程也是走flannel的網橋。
每個node上面都會創建壹個flannel0虛擬網卡，用於跨node之間通訊。所以容器直接可以直接使用pod id進行通訊。
跨節點通訊時，發送端數據會從docker0路由到flannel0虛擬網卡，接收端數據會從flannel0路由到docker0。
如果Pod是壹組應用容器的集合，那Service是不是就沒有意義了，他的意義在於當應用服務需要做負載、需要做全生命周期的跟蹤和管理時就體現出來了，所以Service是壹個抽象的概念，它定義了Pod邏輯集合和訪問這些Pod的策略。
壹個非常常見的場景，當壹個Pod因為某種原因停止運行了，kubelet根據deployment的需求重新啟動壹個新的Pod來提供之前Pod的功能，但是flannel會給這個新的Pod分配壹個新的IP，這會帶來很大的Effort，應用服務的很多配置項都需要調整，如果有了Service呢，這就不是問題，看下Service的運行原理。
這張圖解釋了Service的運行機制，當Service A創建的時候，Service Controller和EndPoints Controller就會被觸發更新壹些資源，例如基於Service中配置的Pod的selector給每壹個Pod創建壹個EndPoint資源並存入etcd，kube-proxy還會更新iptables的chain規則生成基於Service的Cluster IP鏈路到對應Pod的鏈路規則，接下來集群內的壹個pod想訪問某個服務，直接cluster ip:port即可基於iptables的鏈路將請求發送到對應的Pod，這壹層有兩種挑選pod的算法，輪詢(Round Robin)和親和度匹配(Session Affinity)。當然，除了這種 iptabels的模式 ，還有壹種比較原始的方式就是 用戶態的轉發 ，Kube-Proxy 會為每個 Service 隨機監聽壹個端口 (Proxy Port)，並增加壹條 IPtables 規則。從客戶端到 ClusterIP:Port 的報文都會被重定向到 Proxy Port，Kube-Proxy 收到報文後，通過 Round Robin (輪詢) 或者 Session Affinity（會話親和力，即同壹 Client IP 都走同壹鏈路給同壹 Pod 服務）分發給對應的 Pod。
當然，新版本的k8s開始基於 ipvs來替換iptables 了，但是形式和iptables是類似的。
概念圖可以參看：
這是最原始的方式，參看下圖：
IPVS是 LVS 項目的壹部分，是壹款運行在 Linux Kernel 當中的 4 層負載均衡器，性能異常優秀。使用調優後的內核，可以輕松處理每秒 10 萬次以上的轉發請求。目前在中大型互聯網項目中，IPVS 被廣泛的用於承接網站入口處的流量。