一、組件說明
谷歌borg架構圖：
主要由兩部分組成：BorgMaster和Borglet。BorgMaster負責請求和分發，我們可以理解爲大腦，真正做處理和工作的是Borglet。爲了防止BorgMaster由於單節點故障，從圖中我們可以看到有五個副本（這個數目是有講究的，集羣節點數目最好是3、5、7、9等等；如果節點數目爲4，通過投票機制選擇主節點時，會出現投票結果爲2：2，這個時候可能無法選出主節點）。
scheduler將請求如borgcfg、command-line tools、web browsers寫入Paxos（谷歌的一個鍵值對數據庫），接着Borglet會實時地監聽Paxos，當發現有自己要處理的數據時，就會去進行處理。
k8s架構圖：
從此架構圖中可以看出，這裏的scheduler負責介紹任務，選擇合適的節點進行分配任務，將任務交給api server，api server再將請求寫入etcd；replication controller負責容器管理，維護副本的數目在期望值，如我想讓這個容器運行幾個副本就是由它控制的，當運行的容器副本數不符合期望值了，它就會創建對應的Pod或添加Pod；api server是主服務器中除scheduler和replication controller後的最後一個組件了，它是一切服務的訪問入口，爲了減輕api server的壓力，scheduler和replication controller可以在本地生成一定的緩存，不用每次都去訪問api server。
api server在接收到請求後，就會去操作etcd（類似borg架構圖中的Paxos）。etcd的官方將它定位成一個可信賴（天生支持集羣化，像mysql則需要藉助中間件）的分佈式鍵值存儲服務，它能夠爲整個分佈式集羣存儲一些關鍵數據，協助分佈式集羣的正常運轉，存儲k8s集羣所有重要信息。推薦在k8s中使用Etcd v3，v2版本已在k8s v1.11中棄用。v2會將所有的數據都寫入內存中；v3版本會引入本地卷的持久化場所，也就意味着關機後不會造成數據的損壞，可以從本地磁盤恢復。
以上是對k8s架構圖上半部分master節點的介紹，接下來認識下半部分的node節點。node節點有kubelet、kube proxy、container（如docker或者其他容器）。
kubelet會跟docker進行交互，操作docker去創建對應的容器，也就是kubelet會維持Pod的生命週期；kube proxy負責寫入規則至IPTABLES、IPVS，實現服務映射訪問，即實現Pod與Pod之間的訪問、包括負載均衡，默認kube proxy去操作firewall實現Pod的映射。
二、基本概念
1、Pod概念
ReplicationController&ReplicatSet&Deployment
ReplicationController用來確保容器應用的副本數始終保持在用戶定義的副本數，即如果有容器一場退出，會自動創建Pod來代替；而如果異常多出來的容器也會自動回收。在新版本的Kubernetes中建議使用ReplicatSet來取代ReplicationController。
ReplicatSet跟ReplicationController沒有本質的不同，只是名字不一樣，並且ReplicatSet支持集合式的selector。
雖然ReplicatSet可以獨立使用，但一般還是建議使用Deployment來自動管理ReplicatSet，這樣就無需擔心跟其他機制的不兼容問題（比如ReplicatSet不支持rolling-update但Deployment支持）。
StatefulSet
StatefulSet是爲了解決有狀態服務的問題（對應Deployment和ReplicatSet是爲無狀態服務而設計），其應用場景包括：
（1）穩定的持久化存儲，即Pod重新調度後還是能訪問到相同的持久化數據，基於PVC來實現；
（2）穩定的網絡標誌，即Pod重新調度後PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現；
（3）有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現；
（4）有序收縮，有序刪除（即從0到N-1）。
DaemonSet
DaemonSet確保全部（或者一些）Node上運行一個Pod副本。當有Node加入集羣時，也會爲他們新增一個Pod。當有Node從集羣移除時，這些Pod也會被回收。刪除DaemonSet將會刪除所有它創建的Pod。
使用DaemonSet的一些典型用法：
（1）運行集羣存儲daemon，例如在每個Node上運行glusterd、ceph；
（2）在每個Node上運行日誌收集daemon，例如fluentd、logstash；
（3）在每個Node上運行監控daemon，例如Prometheus Node Exported。
Job&Cron Job
Job負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。
Cron Job管理基於時間的Job，即：
（1）在給定時間點只執行一次；（2）週期性地在給定時間點運行。
2、網絡通訊模式
不同情況下網絡通信方式
同一個Pod內部通訊：同一個Pod共享同一個網絡命名空間，共享同一個Linux協議棧。
Pod1至Pod2
>Pod1與Pod2不在同一臺主機，Pod的地址是與docker0在同一個網段的，但docker0網段與宿主機網卡是兩個完全不同的IP網段，並且不同Node之間的通信只能通過宿主機的物理網卡進行。將Pod的IP和所在Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問。
Pod1與Pod2在同一臺機器，由Docker0網橋直接轉發請求至Pod2，不需要經過Flannel。
Pod至Service的網絡：目前基於性能考慮，全部爲iptables維護和轉發。
Pod至外網：Pod向外網發送請求，查找路由表，轉發數據包到宿主機的網卡，宿主機網卡完成路由選擇後，iptables執行Masquerade，把源IP更改爲宿主網卡的IP，然後向外網服務器發送請求。
組件通訊示意圖
在k8s中有三層網絡：節點網絡、Pod網絡和Service網絡。真實的物理網絡只有一個，即節點網絡。也就意味着我們在構建服務器的時候只需要一張網卡就可以實現。Pod網絡和Service網絡都是虛擬網絡，我們可以理解爲內網。