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