本文是Kubernetes網絡系列的最后一部分，如果你還沒看過前面部分，我建議你先花點時間讀一下。
集群動力學

由于Kubernetes（更通用的說法是分布式系統）天生具有不斷變化的特性，因此它的Pod（以及Pod的IP）總是在改變。變化的原因可以是針對不可預測的Pod或節(jié)點崩潰而進行的滾動升級和擴展。這使得Pod IP不能直接用于通信。
我們看一下Kubernetes Service，它是一個虛擬IP，并伴隨著一組Pod IP作為Endpoint（通過標簽選擇器識別）。它們充當虛擬負載均衡器，其IP保持不變，而后端Pod IP可能會不斷變化。
Kubernetes Srvice對象的標簽選擇器
整個虛擬IP的實現實際上是一組iptables（最新版本可以選擇使用IPVS，但這是另一個討論）規(guī)則，由Kubernetes組件kube-proxy管理。 這個名字現在實際上是誤導性的。 它在v 1.0之前確實是一個代理，并且由于其實現是內核空間和用戶空間之間的不斷復制，它變得非常耗費資源并且速度較慢。 現在，它只是一個控制器，就像Kubernetes中的許多其它控制器一樣，它watch api server的endpoint的更改并相應地更新iptables規(guī)則。
有了這些iptables規(guī)則，每當數據包發(fā)往Service IP時，它就進行DNAT（DNAT=目標網絡地址轉換）操作，這意味著目標IP從Service IP更改為其中一個Endpoint - Pod IP - 由iptables隨機選擇。這可確保負載均勻分布在后端Pod中。
iptables DNAT
當這個DNAT發(fā)生時，這個信息存儲在conntrack中——它是Linux連接跟蹤表（存儲iptables已完成的5元組翻譯：protocol，srcIP，srcPort，dstIP，dstPort）。 這樣當請求回來時，它可以取消DNAT，這意味著將源IP從Pod IP更改為Service IP。 這樣，客戶端就不用關心后臺如何處理數據包流。
conntrack表中的5元組實例
因此通過使用Kubernetes Service，我們可以使用相同的端口而不會發(fā)生任何沖突（因為我們可以將端口重新映射到Endpoint）。 這使服務發(fā)現變得非常容易。 我們可以使用內部DNS并對服務主機名進行硬編碼。 我們甚至可以使用Kubernetes預設的服務主機和端口環(huán)境變量。
小建議：采取第二種方法，你可節(jié)省大量不必要的DNS調用！

出站流量

到目前為止我們討論的Kubernetes Service是在一個集群內工作。但是，在大多數實際情況中，應用程序需要訪問一些外部api /網站。
通常，節(jié)點可以同時具有私有IP和公共IP。對于互聯網訪問，這些公共和私有IP存在某種1：1的NAT，特別是在云環(huán)境中。
對于從節(jié)點到某些外部IP的普通通信，源IP從節(jié)點的專用IP更改為其出站數據包的公共IP，入站的響應數據包則剛好相反。但是，當Pod發(fā)出與外部IP的連接時，源IP是Pod IP，云提供商的NAT機制不知道該IP。因此它將丟棄具有除節(jié)點IP之外的源IP的數據包。
因此你可能也猜對了，我們將使用更多的iptables！這些規(guī)則也由kube-proxy添加，執(zhí)行SNAT（源網絡地址轉換），即IP MASQUERADE。它告訴內核使用此數據包發(fā)出的網絡接口的IP，代替源Pod IP。同時保留conntrack條目以進行反SNAT操作。

入站流量

到目前為止一切都很好。Pod可以互相交談，也可以訪問互聯網。但我們仍然缺少關鍵部分 - 為用戶請求流量提供服務。截至目前，有兩種主要方法可以做到這一點：
NodePort /云負載均衡器（L4 - IP和端口）
將服務類型設置為NodePort將會為服務分配范圍為30000-33000的nodePort。即使在特定節(jié)點上沒有運行Pod，此nodePort也會在每個節(jié)點上打開。此NodePort上的入站流量將再次使用iptables發(fā)送到其中一個Pod（該Pod甚至可能在其它節(jié)點上！）。
云環(huán)境中的LoadBalancer服務類型將在所有節(jié)點之前創(chuàng)建云負載均衡器（例如ELB），命中相同的nodePort。
Ingress（L7 - HTTP / TCP）
許多不同的工具，如Nginx，Traefik，HAProxy等，保留了http主機名/路徑和各自后端的映射。通常這是基于負載均衡器和nodePort的流量入口點，其優(yōu)點是我們可以有一個入口處理所有服務的入站流量，而不需要多個nodePort和負載均衡器。

網絡策略

可以把它想象為Pod的安全組/ ACL。 NetworkPolicy規(guī)則允許/拒絕跨Pod的流量。確切的實現取決于網絡層/CNI，但大多數只使用iptables。
目前為止就這樣了。 在前面的部分中，我們研究了Kubernetes網絡的基礎以及overlay網絡的工作原理。 現在我們知道Service抽象是如何在一個動態(tài)集群內起作用并使服務發(fā)現變得非常容易。我們還介紹了出站和入站流量的工作原理以及網絡策略如何對群集內的安全性起作用。
原文鏈接：https://itnext.io/an-illustrated-guide-to-kubernetes-networking-part-3-f35957784c8e
周末送福利，減肥神器

新的一年你選擇長肉肉肉肉肉還是漲知識呢？DockOne.io為了不讓小伙伴長肉肉，特意聯合機械工業(yè)出版社華章贈送6本《Kubernetes進階實戰(zhàn)》，快來領書吧。
領書的兩種姿勢：

點贊數最多，萬人迷的你趕緊留言并且請親朋好友為你點贊吧，截至時間1月7日14：00，贊點數最多的三位朋友將獲得本書；

最佳理由，留言讓小編知道想要本書的理由，理由充分感人的3位朋友可獲得本書，截至時間1月7日14：00。

本書有話說：

我，涵蓋Kubernetes架構、部署、核心/自定義資源、擴縮容、存儲卷、網絡插件與策略、安全、調度策略、監(jiān)控、日志等話題；

我，漸進式講解，手把手示范，大量實操案例，隨時動手驗證；

我，由馬哥教育CEO馬哥（馬永亮）打造，漸進式鋪陳，適合入門與進階。

沒有獲得的小伙伴，可以點擊下面鏈接當當購書哦！
基于Kubernetes的DevOps實踐培訓

基于Kubernetes的DevOps實踐培訓將于2019年1月18日在上海開課，3天時間帶你系統掌握Kubernetes。本次培訓包括：容器特性、鏡像、網絡；Kubernetes架構、核心組件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用對象、設計原則；Kubernetes的數據庫、運行時、網絡、插件已經落地經驗；微服務架構、組件、監(jiān)控方案等，點擊下方圖片查看詳情。

總結

以上是生活随笔為你收集整理的图解Kubernetes网络（周末福利！）的全部內容，希望文章能夠幫你解決所遇到的問題。

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