一、Kubernetes 是 Google 團隊發起並維護的基於 Docker 的開源容器集羣管理系統，它不僅支持常見的雲平臺，而且支持內部數據中心。
建於 Docker 之上的 Kubernetes 可以構建一個容器的調度服務，其目的是讓用戶透過 Kubernetes 集羣來進行雲端容器集羣的管理，而無需用戶進行復雜的設置工作。系統會自動選取合適的工作節點來執行具體的容器集羣調度處理工作。其核心概念是 Container Pod。一個 Pod 由一組工作於同一物理工作節點的容器構成。這些組容器擁有相同的網絡命名空間、IP以及存儲配額，也可以根據實際情況對每一個 Pod 進行端口映射。此外，Kubernetes 工作節點會由主系統進行管理，節點包含了能夠運行 Docker 容器所用到的服務。
二、架構模型爲master/nodes(work)
可以理解master爲蜂后，nodes爲工蜂(幹活的)
- master爲集羣唯一入口，需要做高可用。
- 每一個node節點都提供一部分計算能力和存儲能力。(運行容器的節點)
![細緻解析：kubernets整體架構]()
請求過程：
1 客戶端請求(創建啓動容器)首先發往master，master當中有一個調度器，會去分析各node節點的資源狀態.
2 找一個最佳適配運行用戶所請求的容器的節點，並把它調度上去，由這個node的docker或是其他容器引擎來負責把這個容器啓動起來。
3 啓動容器時檢查本地是否有鏡像，如果沒有需要從鏡像倉庫中pull來啓動(鏡像倉庫可以是雲上的，也可以是自檢的私有倉庫，也可以以容器運行在node節點上)。
三、Master集羣組件
- API Server 接收並處理用戶請求
- Scheduler 調度容器創建的請求
### 兩級調度
#### 第一步：先做預選
1. 評估各node有幾個是符合需求的
#### 第二部：再做優選
2. 再從符合需求中的幾個選出最優的(優選算法)
> 負責觀測每一個node之上總共可用的計算和存儲資源，並根據用戶所請求創建的容器所需要的資源量來評估-
controller-manager 確保已創建的容器處於健康狀態
控制器管理器是確保控制器健康的，控制器是用來確保容器健康的。
- label selector 可以通過控制器給pod打標籤，之後控制器可以根據tag來識別出pod
創建pod時可以給pod直接打上一個標籤，然後讓控制器通過標籤的值來識別出pod來
四、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上
- 自主式Pod
自我管理，創建後仍然要提交給apiserver，由apiserver將其調度至指定的node的節點，由node啓動此pod，如果一個pod中的容器出現故障，需要重啓容器，需要又kubelet來完成。但是，如果節點故障了，該容器就消失了。無法實現全局進行調度。
- 控制管理的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地址和主機名.
五、k8s網絡模型
- pod網絡。各pod運行在同一個網絡，pod的網絡地址是真實的地址，存在於它的網絡名稱空間當中。
- service網絡（集羣網絡）。service地址不是真的地址，存在於iptables中或者ipvs規則中。
- 節點網絡 。
六、k8s通信分類
- 同一pod內的多個容器間：lo網絡
- 各pod之間通信。(overlay network，疊加網絡)
各pod之間直接通信，無論pod運行在哪個節點之上，各pod的地址是不應該也絕對不可以相同。
- 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規則上。
七、etcd k8s的存儲
Etcd是Kubernetes集羣中的一個十分重要的組件，用於保存集羣所有的網絡配置和對象的狀態信息。
存儲集羣的所有變化信息以及網絡配置，非常重要，所以需要做高可用。
八、k8s集羣組成要件
如圖所示，每一個服務都有一個service，用來調度請求流量。如果其中的某個服務中的pod宕機了，pod控制器會自動創建一個新的pod並加入到該服務中。不同的pod的控制器通過pod標籤來管理其所屬的pod。當然k8s集羣內部也是需要主機名來表示不同的主機的，提供dns服務的也是通過pod，同樣的它也有一個service，也有一個pod控制器來管着的dns的pod。
總結。
畫了個圖總結一下整個的k8s集羣，如下。