細緻解析：kubernets總體架構

1、Kubernetes 是 Google 團隊發起並維護的基於 Docker 的開源容器集羣管理系統，它不只支持常見的雲平臺，並且支持內部數據中心。

建於 Docker 之上的 Kubernetes 能夠構建一個容器的調度服務，其目的是讓用戶透過 Kubernetes 集羣來進行雲端容器集羣的管理，而無需用戶進行復雜的設置工做。系統會自動選取合適的工做節點來執行具體的容器集羣調度處理工做。其核心概念是 Container Pod。一個 Pod 由一組工做於同一物理工做節點的容器構成。這些組容器擁有相同的網絡命名空間、IP以及存儲配額，也能夠根據實際狀況對每個 Pod 進行端口映射。此外，Kubernetes 工做節點會由主系統進行管理，節點包含了可以運行 Docker 容器所用到的服務。

---

2、架構模型爲master/nodes(work)

能夠理解master爲蜂后，nodes爲工蜂(幹活的)

1. master爲集羣惟一入口，須要作高可用。
2. 每個node節點都提供一部分計算能力和存儲能力。(運行容器的節點)

   

請求過程：

1 客戶端請求(建立啓動容器)首先發往master，master當中有一個調度器，會去分析各node節點的資源狀態. 2 找一個最佳適配運行用戶所請求的容器的節點，並把它調度上去，由這個node的docker或是其餘容器引擎來負責把這個容器啓動起來。 3 啓動容器時檢查本地是否有鏡像，若是沒有須要從鏡像倉庫中pull來啓動(鏡像倉庫能夠是雲上的，也能夠是自檢的私有倉庫，也能夠以容器運行在node節點上)。

---

3、Master集羣組件

• API Server 接收並處理用戶請求
• Scheduler 調度容器建立的請求

### 兩級調度
#### 第一步：先作預選
1. 評估各node有幾個是符合需求的
#### 第二部：再作優選
2. 再從符合需求中的幾個選出最優的(優選算法)
> 負責觀測每個node之上總共可用的計算和存儲資源，並根據用戶所請求建立的容器所須要的資源量來評估
複製代碼

• controller-manager 確保已建立的容器處於健康狀態

控制器管理器是確保控制器健康的，控制器是用來確保容器健康的。

• label selector 能夠經過控制器給pod打標籤，以後控制器能夠根據tag來識別出pod

建立pod時能夠給pod直接打上一個標籤，而後讓控制器經過標籤的值來識別出pod來

---

4、Node集羣組件

• kubelet 與apiserver交互運行的，接收並處理master調度過來的各類任務。
• docker 運行pod中的容器

• 在K8s上運行的最小單元不是容器，而是pod
• kubernets並不直接調度容器，而是調度pod,pod是對容器的一層封裝。
• pod裏能夠有多個容器，他們共享同一網絡協議棧，存儲卷
• 通常一個pod只有一個容器

• kube-proxy 與apiserver進行通訊，每個pod發生變化，結果是須要保存到apiserver中，apiserver會生成一個通知事件，該事件能夠被任何關聯的組建所接收到， 管理service，service的建立及變更是依靠kube-proxy在iptables上建立出規則

Pod簡介

pod中的每個容器有本身的user，mnt，pid的名稱空間，而後他們共享pod的net,uts,ipc的名稱空間。 通常一個pod中只有一個容器，除非容器之間有特別特別緊密的關係須要放在同一pod中，若是一個pod放置了多個容器，一般有一個爲主容器，其餘容器來輔助主容器上的應用程序完成更多功能來實現。 建立pod時能夠給pod直接打上一個標籤，而後讓控制器經過標籤的值來識別出pod來

因爲pod爲kubernet集羣中的原子單元，是不可再分割的，一個pod中不管是一個容器仍是多個容器，當pod被master調度至某一node上時，這個pod中的全部容器都被調度到了一臺node上

1. 自主式Pod

自我管理，建立後仍然要提交給apiserver，由apiserver將其調度至指定的node的節點，由node啓動此pod，若是一個pod中的容器出現故障，須要重啓容器，須要又kubelet來完成。可是，若是節點故障了，該容器就消失了。沒法實現全局進行調度。

2. 控制管理的Pod

正是有控制器機制的引入使得pod成爲有生命週期的對象，然後由調度器將其調度至集羣中的某節點運行之後，有一些任務做爲守護進程運行爲pod或容器，要確保它們隨時處於運行狀態，一旦發生故障，要隨時重啓它或者替代它。

pod控制器種類

• Replication Controller
  • 多退少補，必須精確符合人定義的指望
  • 滾動更新（相似用戶無感知發佈）
  • 回滾
• ReplicaSet
• Deployment 只能管理無狀態應用
• StatefulSet 管理有狀態的應用
• DaemonSet 每一個node上運行一個副本，而不是隨意運行
• Job,Cronjob 運行做業或者週期性做業
  • 有些任務是臨時須要而運行，運行完之後結束，這種不須要一直處於運行狀態，能夠運行爲一個job
• HPA(HorizontalPodAutoscaler) 自動監控並系統負載分析添加或減小pod

  

---

服務發現功能

每從新生成一個pod都是一個全新的pod，好比ip地址和主機名以前的是不同的。 kubernets爲每一組提供同類服務的pod和它的客戶端之間添加了一箇中間層，這個中間層（service）是固定的，service再將客戶端請求端口代理至後端pod上(經過dnat規則 )，一旦其中一個pod宕機了，一個新的pod會當即被關聯上來(經過標籤選擇器，具備相同標籤的來關聯起來)，而後在動態探測新關聯的pod的ip地址和主機名，

---

5、k8s網絡模型

1. pod網絡。各pod運行在同一個網絡，pod的網絡地址是真實的地址，存在於它的網絡名稱空間當中。
2. service網絡（集羣網絡）。service地址不是真的地址，存在於iptables中或者ipvs規則中。
3. 節點網絡 。

---

6、k8s通訊分類

1. 同一pod內的多個容器間：lo網絡
2. 各pod之間通訊。(overlay network，疊加網絡)

各pod之間直接通訊，不管pod運行在哪一個節點之上，各pod的地址是不該該也絕對不能夠相同。

3. pod與servic之間通訊

service地址只不過是主機上的一條iptables規則中的地址，因此須要配置一下目標地址不是本身的指向網關。每一個主機上都應該有全部的service的地址規則。當pod試圖訪問service的地址時，首先將請求送給網關（通常爲docker0橋），而後docker0橋經過內核發現當前訪問的地址爲一條iptables或ipvs規則，而後將請求送達。

以前說過，當service後端的node節點宕機，pod的控制器經過標籤選擇器會自動建立一個新的pod並加入至該服務中，而node中的另外一個組件，kube-proxy 在此時會將service的變更存儲在master上的api server中，而後api server生成通知事件，又kube-porxy將iptables規則的變化反映至每個節點的iptables規則上。

7、etcd k8s的存儲

Etcd是Kubernetes集羣中的一個十分重要的組件，用於保存集羣全部的網絡配置和對象的狀態信息。

存儲集羣的全部變化信息以及網絡配置，很是重要，因此須要作高可用。

8、k8s集羣組成要件

如圖所示，每個服務都有一個service，用來調度請求流量。若是其中的某個服務中的pod宕機了，pod控制器會自動建立一個新的pod並加入到該服務中。不一樣的pod的控制器經過pod標籤來管理其所屬的pod。固然k8s集羣內部也是須要主機名來表示不一樣的主機的，提供dns服務的也是經過pod，一樣的它也有一個service，也有一個pod控制器來管着的dns的pod。

總結。

畫了個圖總結一下整個的k8s集羣，以下。

---

喜歡我寫的東西的朋友能夠關注一下個人公衆號,上面有個人學習資源以及一些其餘福利。：Devops部落