kubernetes實踐之五:網路模型
一:前言
Kubernetes從Docker預設的網路模型中獨立出來形成一套自己的網路模型。模型的基礎原則是:每個Pod都擁有一個獨立的IP地址,而且假定所有Pod都在一個可以直接連通的,扁平的網路空間中。同一個Pod內的容器可以透過localhost來連線對方的埠。
二:Docker網路模型
Docker使用Linux橋接,在宿主機上虛擬一個Docker網橋(docker0),Docker啟動一個容器時會根據Docker網橋的網段分配容器的IP,同時Docker網橋是每個容器的預設閘道器。因為在同一個宿主機內的容器都接入同一個網橋,這樣容器之間就能透過容器的IP直接通訊。
1. 網路名稱空間
為了支援網路協議棧的多個例項,Linux在網路棧中引入了網路名稱空間。這些獨立的協議棧被隔離到不同的名稱空間中。處於不同名稱空間的網路棧是完全隔離的。網路名稱空間內可以有自己獨立的路由表及獨立的Iptables/Netfilter設定來提供包轉發,NAT及IP包過濾等功能。
2. Veth
引入Veth裝置對是為了在不同的網路名稱空間之間進行通訊,利用它可以直接將兩個網路名稱空間連線起來。
3. Iptables/Netfilter
Netfilter是Linux作業系統核心層內部的一個資料包處理模組. Iptables是應用層的,其實質是一個定義規則的配置工具,而核心的資料包攔截和轉發是Netfiler。
Netfilter作用於網路層,資料包透過網路層會經過Netfilter的五個掛載點(Hook POINT):PRE_ROUTING、INPUT、OUTPUT、FORWARD、POST_ROUTING 任何一個資料包,只要經過本機,必將經過這五個掛載點的其中一個。
iptables的規則組成,又被稱為四表五鏈:
四張表:filter表(用於過濾)、nat表(用於地址轉換)、mangle表(修改資料包)、raw表(一般是為了不再讓iptables做資料包的連結跟蹤處理,跳過其他表,提高效能)
五個掛載點:PRE_ROUTING、INPUT、OUTPUT、FORWARD、POST_ROUTING
具體來說,就是iptables每一條允許/拒絕或轉發等規則必須選擇一個掛載點,關聯一張表。
檢視系統中已有的規則的方法如下:
iptables-save : 按照命令的方式列印Iptables的內容。
Iptables-vnL : 以另一種格式顯示Netfilter表的內容。
4. 網橋
網橋是一個二層網路裝置,可以解析收發的報文,讀取目標MAC地址的資訊,和自己記錄的MAC表結合來決策報文的轉發埠。
5. 路由
路由功能由IP層維護的一張路由表來實現。當主機收到資料包文時,它用此表來決策下來應該做什麼操作,當從網路側接收到資料包文時,IP層首先會檢查報文的IP地址是否與主機自身的地址相同。如果不同,並且主機配置了路由功能,那麼報文將被轉發,否則,報文將被放棄。
檢視LOCAL表的內容:
ip route show table local type local
路由表檢視:
Ip route list
6. 閘道器
閘道器(Gateway)就是一個網路連線到另一個網路的“關口”.按照不同的分類標準,閘道器也有很多種。TCP/IP協議裡的閘道器是最常用的.
閘道器實質上是一個網路通向其他網路的IP地址。比如有網路A和網路B,網路A的IP地址範圍為“192.168.1.1~192. 168.1.254”,子網掩碼為255.255.255.0;網路B的IP地址範圍為“192.168.2.1~192.168.2.254”,子網掩碼為255.255.255.0。在沒有路由器的情況下,兩個網路之間是不能進行TCP/IP通訊的,即使是兩個網路連線在同一臺交換機(或集線器)上,TCP/IP協議也會根據子網掩碼(255.255.255.0)判定兩個網路中的主機處在不同的網路裡。而要實現這兩個網路之間的通訊,則必須透過閘道器。
Docker網橋是宿主機虛擬出來的,並不是真實存在的網路裝置,外部網路是無法定址到的,這也意味著外部網路無法直接訪問到容器。如果容器希望能夠被外部網路訪問到,就需要透過對映容器埠到宿主機。 Docker run -p ****:****
實際上,埠對映透過在iptables的NAT表中新增相應的規則,所以我們將埠對映的方式成為NAT方式。
三:Kubernetes網路模型
1. 容器間通訊
Pod是容器的集合,Pod包含的容器都執行在同一個宿主機上,這些容器將擁有同樣的網路空間,容器之間能夠互相通訊,它們能夠在本地訪問其它容器的埠。
2. Pod間通訊
Kubernetes網路模型是一個扁平化的網路平面,在這個網路平面內,Pod作為一個網路單元同Kubernetes Node的網路處於同一層級。
同一個Kubernetes Node上的Pod/容器原生能通訊,但是Kubernetes Node之間的Pod/容器之間的通訊,需要對Docker進行增強。在容器叢集中建立一個覆蓋網路,聯通各個節點。
3. Service到Pod的通訊
Service 在Pod之間起到服務代理的作用,對外表現為一個單一訪問介面,將請求轉發給Pod,Service的網路轉發是Kubernetes實現服務編排的關鍵一環。
虛擬IP是10.254.248.68,埠80/TCP對應的Endpoints包含10.1.46.2:80,10.1.77.2:80;即當請求10.254.248.68:80時,會轉發到這些後端之一。
Kubernetes Proxy透過建立Iptables規則,直接重定向訪問Service虛擬IP的請求到Endpoints.而當Endpoints發生變化的時候,Kubernetes
Proxy會重新整理相關的Iptables規則。在Iptables模式下,Kubernetes Proxy只是負責監控Service和Endpoints,更新Iptables規則,報文的轉發依賴於Linux核心,預設的負載均衡策略是隨機方式。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28624388/viewspace-2151990/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- kubernetes實踐之四:Flannel網路外掛安裝
- kubernetes實踐之五:Node節點安裝
- kubernetes實踐之二十:網路原理
- Kubernetes 容器網路模型和典型實現模型
- Docker進階與實踐之五:Docker網路LibnetworkDocker
- 五種網路io模型模型
- Kubernetes容器雲的網際網路企業實踐
- kubernetes實踐之十一:EFK
- 【kubernetes】網路虛擬網路卡對veth pair、flannel網路模型實現原理AI模型
- ubuntu 16.04 下安裝kubernetes 1.6 之flannel網路模型Ubuntu模型
- 實施零信任網路訪問的五個最佳實踐
- kubernetes實踐之五十二:Helm
- kubernetes實踐之五十七:PodPreset
- kubernetes實踐之五十八:CronJob
- kubernetes實踐之十七:架構架構
- kubernetes實踐之十九:API概述API
- kubernetes實踐之六十:Cabin-Manage Kubernetes
- Kubernetes網路分析之Flannel
- 五種網路I/O模型詳解模型
- kubernetes實踐之五十九:NetworkPolicy
- kubernetes實踐之六十四:CoreDNSDNS
- kubernetes實踐之九:kube-dnsDNS
- kubernetes實踐之五十六:雲原生
- kubernetes實踐之四十二:StatefulSet
- 容器雲架構–瞭解 Kubernetes 網路模型架構模型
- kubernetes生產實踐之redis-clusterRedis
- GitOps實踐之kubernetes安裝argocdGitGo
- kubernetes實踐之六十二:Secret 使用
- kubernetes實踐之六十三:使用技巧
- kubernetes實踐之六十五:Service Mesh
- kubernetes實踐之八:TLS bootstrappingTLSbootAPP
- kubernetes實踐之十二:部署Traefik Ingress
- kubernetes實踐之十四:Service Account與Secret
- 從美圖容器優化實踐談Kubernetes網路方案設計優化
- rabbitmq 學習與實踐分享之網路分割槽MQ
- Macvlan 網路方案實踐Mac
- 深度學習(五)之原型網路深度學習原型
- 【虛擬化實戰】網路設計之五IPStorage