kubernetes基礎(chǔ)概念解析
?1?、pod 概念
1、自主式POD的基礎(chǔ)概念
- Pause 網(wǎng)絡(luò)棧共享：首先我們要定義一個(gè) POD，就會(huì)先啟動(dòng)第一個(gè)容器，只要運(yùn)行一個(gè)POD這個(gè)容器就會(huì)被啟動(dòng)、這個(gè)容器叫PAUSE（只要是有POD這個(gè)容器就會(huì)被啟動(dòng)）、這個(gè)容器啟動(dòng)成功之后我假設(shè)在這個(gè)POD里啟動(dòng)了兩個(gè)容器，也就是說一個(gè)POD里會(huì)被封裝多個(gè)容器。然后這兩個(gè)容器會(huì)共用pause的網(wǎng)絡(luò)棧，也就是說這兩個(gè)容器就沒有他的獨(dú)立地址了，他們都是共同使用pause的地址、共用他的存儲(chǔ)卷、但是這兩個(gè)容器之間進(jìn)程不隔離（也就意味著、這里一個(gè)容器運(yùn)行的是php-fpm一個(gè)容器運(yùn)行的是nginx，如果這里nginx想要反向代理fpm的話只需要寫locahost9000（這個(gè)是php服務(wù)的9000端口）即可，原因是這兩個(gè)容器都是共享的pause的網(wǎng)絡(luò)棧、也就是在同一個(gè)pod里容器之間的端口不能沖突的。）
- Pause 存儲(chǔ)卷共享：假如這個(gè)pod會(huì)掛在一個(gè)存儲(chǔ)上，同理這兩個(gè)容器（php-fpm、nginx）都會(huì)共享pause的存儲(chǔ)。因?yàn)樗麄儍蓚€(gè)分別都需要共享html的內(nèi)容。也就意味著在同一個(gè)pod里及共享網(wǎng)絡(luò)又共享存儲(chǔ)卷。
2、控制器管理的POD的基礎(chǔ)概念
Replication Controller（簡稱RC）& ReplicaSet（簡稱RS） & Deployment 這是三種管理器類型、因?yàn)檫@三種有一定的重合性所以放在一起講。
Replication Controller：用來確保容器應(yīng)用的副本數(shù)始終保持在用戶定義的副本數(shù)，即如果有容器異常退出，會(huì)自動(dòng)創(chuàng)建新的 Pod 來替代；而如果異常多出來的容器也會(huì)自動(dòng)回收。在新版本的 Kubernetes中建議使用 ReplicaSet（在K8s新版本中官方拋棄RC采用的都是RS） 來取代ReplicationControlle（RC）
ReplicaSet 跟 ReplicationController 沒有本質(zhì)的不同，只是名字不一樣，并且 ReplicaSet 支持集合式的selector（選擇器）
雖然 ReplicaSet 可以獨(dú)立使用，但一般還是建議使用 Deployment（調(diào)度） 來自動(dòng)管理 ReplicaSet ，這樣就無需擔(dān)心跟其他機(jī)制的不兼容問題（比如 ReplicaSet不支持 rolling-update（滾動(dòng)更新） 但Deployment （調(diào)度） 支持）
Deployment（調(diào)度）原理
deployment 為 pod 和 replicaset 提供一個(gè)聲明式定義（declarative）方法，用來代替以前的replication controller 來方便管理應(yīng)用。典型的應(yīng)用場(chǎng)景包括：
- 定義 deployment 來創(chuàng)建 pod 和 replicaset
- 滾動(dòng)升級(jí)和回滾應(yīng)用
- 擴(kuò)容和縮容
- 暫停和繼續(xù) deploymentDeployment
在創(chuàng)建出來以后呢會(huì)去創(chuàng)建一個(gè)RS，也就意味這RS不是我們自己定義得，而是deployment定義得，deployment再去負(fù)責(zé)創(chuàng)建我們對(duì)應(yīng)的pod。比如上圖創(chuàng)建了三個(gè)pod，如果有一天我們讓deployment把鏡像的V1版更新成V2版本。他會(huì)新建一個(gè)RS（這里比如是RS-1）然后我們就將RS的V1滾動(dòng)更新到RS-1的V2版已到達(dá)滾動(dòng)更新的狀態(tài)，并且還可以回滾，所謂的回滾就是當(dāng)發(fā)現(xiàn)更新到V2版本有一定的小BUG我們可以支持回滾，只見我們的rolling-update（滾動(dòng)更新）就會(huì)回到RS新建一個(gè)老舊版本的V1然后把RS-1的V2刪了以此類推，原因是deployment再滾動(dòng)更新之后這個(gè)RS并不會(huì)被刪除而是被停用，當(dāng)我們開始回滾的時(shí)候就會(huì)將老舊版本的RS開始啟用，然后逐漸達(dá)到deployment（調(diào)度器）想要達(dá)到的預(yù)期狀態(tài)。以上是deployment的原理，deployment需要去創(chuàng)建RS達(dá)到創(chuàng)建pod的能力
HPA（水平制度擴(kuò)展）
Horizontal Pod Autoscaling 僅適用于僅適用于 Deployment 和 ReplicaSet，在 V1 版本中僅支持根據(jù)Pod的 CPU 利用率擴(kuò)縮容，在 vlalpha版本中，支持根據(jù)內(nèi)存和用戶自定義的 metric（公制的）擴(kuò)縮容。
我現(xiàn)在運(yùn)行了一個(gè)RS-1，RS-1下面管理兩個(gè)pod，然后我再定義一個(gè)HPA，這個(gè)HPA定義是基于這個(gè)RS-1來定義的，當(dāng)我們的CPU大于80的時(shí)候就進(jìn)行擴(kuò)展，擴(kuò)展的最大值是10個(gè)最小值是兩個(gè)，也就以為這HPA會(huì)去監(jiān)控這些POD的資源利用率，當(dāng)CPU達(dá)到80的時(shí)候HPA就會(huì)去新建出來新的pod直到達(dá)到他HPA的最大值10個(gè)，也就是cpu只有在大于或等于80的時(shí)候HPA才會(huì)去創(chuàng)建pod，如果不滿足這個(gè)條件就不會(huì)再進(jìn)行創(chuàng)建。一旦利用率變低之后這里的pod就會(huì)被回收。但是最小只能刪到2因?yàn)檫@里定義了最小個(gè)數(shù)為2，所以HPA就會(huì)達(dá)成一個(gè)水平制度擴(kuò)展的目的。
StatefullSet 解決有狀態(tài)服務(wù)的問題
StatefulSet 是為了解決有狀態(tài)服務(wù)的問題（對(duì)應(yīng) Deployments 和 ReplicaSets 是為無狀態(tài)服務(wù)而設(shè)），其應(yīng)用場(chǎng)景包括：
- 穩(wěn)定的持久化存儲(chǔ)（就是pod在死亡以后再去調(diào)度一個(gè)新的pod回來的時(shí)候里面的數(shù)據(jù)也不能丟失），即 Pod重新調(diào)度后還是能訪問到相同的持久化數(shù)據(jù)，基于 PVC來實(shí)現(xiàn)來實(shí)現(xiàn)。
- 穩(wěn)定的網(wǎng)絡(luò)標(biāo)志，即 Pod 重新調(diào)度后其 PodName（pod名稱）和 HostName（主機(jī)名稱）不變，基于 Headless Service（即沒有 Cluster IP 的 Service）來實(shí)現(xiàn)。這是防止在集群里面定義了一個(gè)pod名稱去調(diào)用，結(jié)果出現(xiàn)了一個(gè)新的pod頂替以后名字變了需要重新寫入這是不需要的，因?yàn)樗麜?huì)實(shí)時(shí)的穩(wěn)定這個(gè)網(wǎng)絡(luò)表示
- 有序部署，有序擴(kuò)展，有序部署會(huì)分為擴(kuò)展和回收階段，所以稱為有序部署和有序擴(kuò)展。即 Pod是有順序的，在部署或者擴(kuò)展的時(shí)候要依據(jù)定義的順序依次進(jìn)行（即從 0 到 N-1，在下一個(gè) Pod運(yùn)行之前所有Pod 必須都是Running（運(yùn)行）和 Ready（準(zhǔn)備）狀態(tài)），基于 init containers 來實(shí)現(xiàn)
- 有序收縮，有序刪除（即從 N-1 到 0）
daemonset（守護(hù)進(jìn)程）
DaemonSet 確保全部（或者一些） Node 上運(yùn)行一個(gè) Pod 的副本。當(dāng)有 Node 加入集群時(shí)，也會(huì)為他們新增一個(gè) Pod 。當(dāng)有 Node 從集群移除時(shí)，這些 Pod 也會(huì)被回收。刪除 DaemonSet 將會(huì)刪除它創(chuàng)建的所有 Pod使用 DaemonSet 的一些典型用法：
- 運(yùn)行集群存儲(chǔ) daemon ，例如在每個(gè) Node 上運(yùn)行 glusterd 、ceph 。
- 在每個(gè) Node 上運(yùn)行日志收集 daemon ，例如 fluentd 、logstash 。
- 在每個(gè) Node 上運(yùn)行監(jiān)控 daemon ，例如 Prometheus Node Exporter
Job （工作），Cronjob（定時(shí)任務(wù)）
Job 負(fù)責(zé)批處理任務(wù)，即僅執(zhí)行一次的任務(wù)，它保證批處理任務(wù)的一個(gè)或多個(gè) Pod 成功結(jié)束Cron Job 管理基于時(shí)間的 Job ，即：
- 在給定時(shí)間點(diǎn)只運(yùn)行一次
- 周期性地在給定時(shí)間點(diǎn)運(yùn)行
Cron job：簡單來說就是可以在特定的時(shí)間重復(fù)執(zhí)行。
服務(wù)發(fā)現(xiàn)
所謂的服務(wù)發(fā)現(xiàn)就是我們的客戶端想要去訪問我們的一組pod，并且被訪問的pod必須要有相關(guān)性，因?yàn)橹挥惺怯邢嚓P(guān)性才會(huì)被我的service收集到。并且service去收集我們的pod是通過我們的標(biāo)簽去選擇到的。選擇到以后這個(gè)service會(huì)有自己的ip和端口，這時(shí)候我們的客戶端（client）就可以去訪問service的IP加端口。而間接的訪問到所對(duì)應(yīng)的pod，并且這里是有一個(gè)RR（輪詢）的算法存在的。
pod 與 pod 之間的通訊方案
上圖解析：
就是我們的 apache 加我們的 fpm 模塊。然后前面是一些緩存服務(wù)器 squid（緩存服務(wù)）。最后面就是我們的MySQL，而 squid（緩存服務(wù)）前面肯定是需要一個(gè)負(fù)載服務(wù)器的這里我就用 LVS。
也就意味這首先我們要構(gòu)建一個(gè) apache 加入到 fpm 的結(jié)構(gòu)集群，然后在構(gòu)建 mysql 集群正在構(gòu)建squid 集群。假如我們想把這個(gè)結(jié)構(gòu)放在我們的 k8s 集群中運(yùn)行的話。
MySQL 需要運(yùn)行成一個(gè) pod ，mysql 封裝成一個(gè) pod 之后呢我們還有 apache+fpm ，并且apache+fpm 這三個(gè)都是類似的所以我們可以在 deployment（調(diào)度器）上面去創(chuàng)建。Deployment 會(huì)指定 apache+fpm 的副本數(shù)目為三個(gè)副本。這樣就會(huì)有三個(gè)不同的 apache+fpm 的 pod 存在了。
然后在往上我們會(huì)發(fā)現(xiàn)有三個(gè) squid（緩存服務(wù)），這三個(gè) squid（緩存服務(wù)）我們也可以交個(gè)控制器去控制。然后 LVS 就可以靠他本身的功能將這個(gè)集群負(fù)載了。
而我們?cè)?php-fpm 和 squid 的中間再加一層 service - php-fpm。這個(gè) service - php-fpm 會(huì)綁定 phpfpm 的標(biāo)簽選擇進(jìn)行綁定，那 squid 想要進(jìn)行反向代理的設(shè)置的話就不需要寫這三個(gè) php-fpm pod 所對(duì)應(yīng)的IP地址了。而是寫的 service - php-fpm 的IP地址，因?yàn)?php-fpm 這三個(gè) pod 如果死掉的話就會(huì)從新生成ip地址，而間接都就要修改 squid 反向代理的配置，以避免不必要的問題。這樣的話 squid 只要將 IP 指定在我們的 service - php-fpm上面即可并且 php-fpm 是三個(gè) pod ，MySQL 也是 pod 他們之間會(huì)出現(xiàn)一定的關(guān)聯(lián)，比如我們將mysql部署在StatefullSet 里面這時(shí) mysql pod 的名稱就不會(huì)變，那我們可以通過他的名稱去固定在我們對(duì)應(yīng) pod 上，因?yàn)镵8S 內(nèi)部是一個(gè)扁平化的網(wǎng)絡(luò)，所以容器之間是可以互相訪問的所以我們的 php-fpm 里面寫 mysql 的信息是沒有問題的，對(duì)于這三臺(tái) squid 來說用戶想要訪問，我可以在創(chuàng)一個(gè) service - squid 與我們的 squid 進(jìn)行綁定，通過去判斷我們的 squid 的相關(guān)一些標(biāo)簽進(jìn)行確定。
這樣的話我們只需要將我們的 service-squid 暴露在外面即可，service 其中有一種暴露模式叫做我們的nodeport 。這樣我們就可以將這個(gè)集群部署在K8S集群中了。這個(gè)集群也是我們的pod與pod之間的通訊方案。
網(wǎng)絡(luò)的通訊方式
網(wǎng)絡(luò)通訊模式
Kubernetes 的網(wǎng)絡(luò)模型假定了所有 Pod 都在一個(gè)可以直接連通的扁平的網(wǎng)絡(luò)空間中（在 K8S 中所謂的扁平化網(wǎng)絡(luò)空間就是所有的 pod 都可以通過對(duì)方的ip“直接達(dá)到”就是 pod 認(rèn)為他自己是直接到達(dá)的，其實(shí)底層有一堆的轉(zhuǎn)換機(jī)制存在），這在 GCE （Google Compute Engine 谷歌的云服務(wù)）里面是現(xiàn)成的網(wǎng)絡(luò)模型，在 Kubernetes中假定這個(gè)網(wǎng)絡(luò)已經(jīng)存在（也就意味了如果我們想在自己的集群中去構(gòu)建K8S的話就先要去解決扁平化的網(wǎng)絡(luò)空間）。
而在私有云里搭建 Kubernetes 集群，就不能假定這個(gè)網(wǎng)絡(luò)已經(jīng)存在了。我們需要自己實(shí)現(xiàn)這個(gè)網(wǎng)絡(luò)假設(shè)，將不同節(jié)點(diǎn)上的 Docker 容器之間的互相訪問先打通，然后運(yùn)行 Kubernetes
同一個(gè) pod 內(nèi)的容器之間通訊
同一個(gè) Pod 內(nèi)的多個(gè)容器之間：lo （回環(huán)網(wǎng)卡）
各 Pod 之間的通訊：Overlay Network（重疊網(wǎng)絡(luò)）
Pod 與 Service 之間的通訊：通過各節(jié)點(diǎn)的 Iptables（防火墻）規(guī)則的轉(zhuǎn)換去實(shí)現(xiàn)。在K8S新版已經(jīng)加入了LVS的轉(zhuǎn)發(fā)機(jī)制并且轉(zhuǎn)發(fā)上線會(huì)更高。
網(wǎng)絡(luò)解決方案 Kubernetes + Flannel -1
Flannel 是 CoreOS 團(tuán)隊(duì)針對(duì) Kubernetes 設(shè)計(jì)的一個(gè)網(wǎng)絡(luò)規(guī)劃服務(wù)，簡單來說，它的功能是讓集群中的不同節(jié)點(diǎn)主機(jī)創(chuàng)建的 Docker 容器都具有全集群唯一的虛擬 IP 地址。而且它還能在這些 IP 地址之間建立一個(gè)覆蓋網(wǎng)絡(luò)（ Overlay Network ），通過這個(gè)覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動(dòng)地傳遞到目標(biāo)容器內(nèi)
上面加粗的這句話提取出來的概念就是，不同機(jī)器這里指的是物理機(jī)，上面運(yùn)行的docker。這里面的容器他們之間的IP不能一致。
Flanneld的網(wǎng)絡(luò)的通訊方案原理（同主機(jī)和不同主機(jī)通訊）
這里畫了兩臺(tái)大主機(jī)、一個(gè)是192.168.66.11/24一個(gè)是192.168.66.12/24然后在這兩臺(tái)主機(jī)中運(yùn)行了4 個(gè)pod，然后在192.168.66.11這個(gè)主機(jī)中運(yùn)行的是web app2和web app1的兩個(gè)pod。然后在192.168.66.12這個(gè)主機(jī)中運(yùn)行的是web app3和backend（前端組件）。然后所有的瀏覽訪問到backend上，backend經(jīng)過自己的網(wǎng)關(guān)去處理，把什么樣的請(qǐng)求分配在什么樣的服務(wù)上。
那也就意味著當(dāng)backend想要去跟web app2或者是web app2想要跟backend通訊的時(shí)候就需要涉及到跨主機(jī)了，以及web app3跟本機(jī)的backend兩個(gè)不同pod之間通訊的話他們是同主機(jī)的，是怎么來解決通訊的問題的。那我們下面來詳細(xì)解析一下。
首先在我們的node服務(wù)器上我們會(huì)去安裝一個(gè)叫flanneld的守護(hù)進(jìn)程，這個(gè)flanneld的進(jìn)程呢會(huì)監(jiān)聽一個(gè)端口，這個(gè)端口就是用于后期轉(zhuǎn)發(fā)數(shù)據(jù)包以及接收數(shù)據(jù)包的這么一個(gè)服務(wù)端口。這個(gè)flanneld進(jìn)程一旦啟動(dòng)之后會(huì)開啟一個(gè)網(wǎng)橋叫 flannel0 這個(gè)網(wǎng)橋 flannel0 就是專門去收集 docker0 轉(zhuǎn)發(fā)出來的數(shù)據(jù)報(bào)文。然后這個(gè) docker0 會(huì)分配自己的 IP 到對(duì)應(yīng)的 POD 上，如果是我們同一臺(tái)主機(jī)上的兩個(gè) pod 之間的訪問的話走的其實(shí)是 docker0 的網(wǎng)橋，因?yàn)榇蠹叶际窃谕粋€(gè)網(wǎng)橋下面的兩個(gè)不同的子網(wǎng)而已。也就是在真實(shí)服務(wù)器的主機(jī)內(nèi)核已經(jīng)完成了這次數(shù)據(jù)報(bào)文的轉(zhuǎn)換。
怎么跨主機(jī)還能通過對(duì)方的 IP 直接到達(dá)：
到達(dá)流程：首先我們的 web app2 pod 想要把數(shù)據(jù)包發(fā)送到 backend ，這時(shí)候 web app2 的數(shù)據(jù)包源地址寫自己的 10.1.15.2/24 目標(biāo)要寫 backend 的 10.1.20.3/24 。由于不是在同一臺(tái)主機(jī)所以 webapp2 先發(fā)送到他的網(wǎng)關(guān)也就是 docker0 的 IP 10.1.15.1/24，而 docker0 上會(huì)有對(duì)應(yīng)的函數(shù)把這個(gè)數(shù)據(jù)包抓到我們的 flannel0 并且在flannel0 上會(huì)有一堆的路由表記錄。這個(gè)路由表記錄是從我們的 etcd 里面獲取到的，寫入到我們當(dāng)前的主機(jī)判斷路由到底到那臺(tái)機(jī)器。
到了 flannel0 之后因?yàn)?flannel0 是flanneld 開啟這么一個(gè)網(wǎng)橋所以這個(gè)數(shù)據(jù)包會(huì)到flanneld，到了 flanneld 以后會(huì)對(duì)這個(gè)數(shù)據(jù)報(bào)文進(jìn)行封裝也就是上圖的封裝部分。有這么一個(gè)結(jié)構(gòu)mac是mac部分，然后到我們的下一層也就是第三層，第三層內(nèi)容寫的是源地址為192.168.66.11目標(biāo)寫的是192.168.66.12 。接著下一層封裝的是UDP的數(shù)據(jù)報(bào)文，也就意味著 flanneld 使用的是UDP的數(shù)據(jù)報(bào)文去轉(zhuǎn)發(fā)這些數(shù)據(jù)包因?yàn)楦欤吘乖谕粋€(gè)局域網(wǎng)內(nèi)部。
在下一層有封裝了一層新的三層信息源是10.1.15.2目標(biāo)是10.1.20.3封裝到這一層以后外面就封裝了一個(gè) payload 實(shí)體。在被轉(zhuǎn)發(fā)到192.168.66.12的這個(gè)主機(jī)上。原因是我們的三層寫了目標(biāo)地址是192.168.66.12所以這個(gè)數(shù)據(jù)報(bào)文是能夠到這里的，并且也是對(duì)應(yīng)的這里的flanneld的端口所以這個(gè)數(shù)據(jù)包會(huì)被192.168.66.12主機(jī)的 flanneld 所截獲。Flanneld截獲以后會(huì)進(jìn)行拆封，因?yàn)?92.168.66.12主機(jī)的 flanneld 他知道這是干嘛的，拆封完了之后會(huì)轉(zhuǎn)發(fā)到192.168.66.12主機(jī)的 flannel0（10.1.20.0）然后再轉(zhuǎn)發(fā)到docker0（10.1.20.1）。然后在轉(zhuǎn)發(fā)給 192.168.66.12主機(jī)上的 backend pod。這樣的話就能是實(shí)現(xiàn)我們的跨主機(jī)的扁平化網(wǎng)絡(luò)。
以上就是整個(gè)flanneld的網(wǎng)絡(luò)的通訊方案
Flannel與ETCD之間有哪些關(guān)聯(lián)
ETCD 之 Flannel 提供說明：
- 存儲(chǔ)管理 Flannel 可分配的 IP 地址段資源，也就意味著 flannel 在啟動(dòng)之后會(huì)向 etcd 去插入可以被分配的網(wǎng)段，并且把那個(gè)網(wǎng)段分配到那臺(tái)機(jī)器 etcd 都會(huì)記錄著，防止以增的網(wǎng)段在被 flannel 利用分配給其他的 node 節(jié)點(diǎn)。以避免IP沖突
- 監(jiān)控 ETCD 中每個(gè) Pod 的實(shí)際地址，并在內(nèi)存中建立維護(hù) Pod 節(jié)點(diǎn)路由表。
也就是說 ETCD 在我們的K8S集群中，是非常重要的，所以想要進(jìn)行高可用的話 ETCD 一定是我們最先高可用的一個(gè)組件。
不同情況下網(wǎng)絡(luò)通信方式
同一個(gè) Pod 內(nèi)部通訊：同一個(gè) Pod 共享同一個(gè)網(wǎng)絡(luò)命名空間，共享同一個(gè) Linux協(xié)議棧所以都是使用的 lo 的回環(huán)網(wǎng)卡進(jìn)行通訊的
Pod1 至 Pod2
> Pod1 與 Pod2 不在同一臺(tái)主機(jī)， Pod 的地址是與 docker0 在同一個(gè)網(wǎng)段的，但 docker0 網(wǎng) 段與宿主機(jī)網(wǎng)卡是兩個(gè)完全不同的 IP 網(wǎng)段，并且不同 Node 之間的通信只能通過宿主機(jī)的物理網(wǎng)卡進(jìn)行。將 Pod 的 IP 和所在 Node 的 IP 關(guān)聯(lián)起來，通過這個(gè)關(guān)聯(lián)讓 Pod 可以互相訪問
> Pod1 與 Pod2 在同一臺(tái)機(jī)器，由 Docker0 網(wǎng)橋直接轉(zhuǎn)發(fā)請(qǐng)求至 Pod2 ，不需要經(jīng)過 Flannel Pod 至 Service 的網(wǎng)絡(luò)：目前基于性能考慮，全部為 iptables或LVS 維護(hù)和轉(zhuǎn)發(fā)
Pod 到外網(wǎng)：?Pod 向外網(wǎng)發(fā)送請(qǐng)求，查找路由表 , 轉(zhuǎn)發(fā)數(shù)據(jù)包到宿主機(jī)的網(wǎng)卡，宿主網(wǎng)卡完成路由選擇后， iptables 執(zhí)行 Masquerade 動(dòng)作 ，把源 IP 更改為宿主網(wǎng)卡的 IP ，然后向外網(wǎng)服務(wù)器發(fā)送請(qǐng)求，也就意味著如果 pod 里面的容器想上網(wǎng)也就是通過 masquerade 的動(dòng)態(tài)轉(zhuǎn)換去完成所謂的上網(wǎng)行為
外網(wǎng)訪問 Pod ：Service ，外網(wǎng)想要訪問pod就要借助到我們service的node pod方式才能進(jìn)行所謂的訪問的K8S集群內(nèi)部，因?yàn)樗m然是一個(gè)扁平化的網(wǎng)絡(luò)，但可別忘了這個(gè)扁平化的網(wǎng)絡(luò)是一個(gè)私有網(wǎng)絡(luò)并不能在跟物理機(jī)相鄰的網(wǎng)絡(luò)內(nèi)訪問到他所以要借助到我們的node pod進(jìn)行映射。
以上就是我們的不同網(wǎng)絡(luò)的通訊機(jī)制。
組件通訊示意圖
在我們得K8S里有三層網(wǎng)絡(luò)，第一叫做節(jié)點(diǎn)網(wǎng)絡(luò)；第二叫做 pod 網(wǎng)絡(luò)；第三叫 service 網(wǎng)絡(luò)。需要注意的是真實(shí)得物理網(wǎng)絡(luò)只有一個(gè)就是節(jié)點(diǎn)網(wǎng)絡(luò)。也就意味著我們?cè)跇?gòu)建服務(wù)器得時(shí)候只需要一張網(wǎng)卡就可以實(shí)現(xiàn)。Pod 和service 網(wǎng)絡(luò)都是虛擬網(wǎng)絡(luò)，這里我們都可以把它理解為是一個(gè)內(nèi)部網(wǎng)絡(luò)。所有的 pod都會(huì)在這個(gè)扁平化的網(wǎng)絡(luò)中進(jìn)行通訊。那如果像訪問 service 得話需要在 service 這么一個(gè)網(wǎng)絡(luò)中進(jìn)行訪問，service 再去跟后端的 pod 進(jìn)行所謂通訊得通過 iptables 得或者是通過LVS得轉(zhuǎn)換去達(dá)到通訊。
需要本篇文檔的同學(xué)直接掃描下方二維碼獲取網(wǎng)盤鏈接
