一、Kubernetes 是 Google 團隊發起並維護的基於 Docker 的開源容器叢集管理系統，它不僅支援常見的雲平臺，而且支援內部資料中心。
建於 Docker 之上的 Kubernetes 可以構建一個容器的排程服務，其目的是讓使用者透過 Kubernetes 叢集來進行雲端容器叢集的管理，而無需使用者進行復雜的設定工作。系統會自動選取合適的工作節點來執行具體的容器叢集排程處理工作。其核心概念是 Container Pod。一個 Pod 由一組工作於同一物理工作節點的容器構成。這些組容器擁有相同的網路名稱空間、IP以及儲存配額，也可以根據實際情況對每一個 Pod 進行埠對映。此外，Kubernetes 工作節點會由主系統進行管理，節點包含了能夠執行 Docker 容器所用到的服務。
二、架構模型為master/nodes(work)
可以理解master為蜂后，nodes為工蜂(幹活的)
- master為叢集唯一入口，需要做高可用。
- 每一個node節點都提供一部分計算能力和儲存能力。(執行容器的節點)
請求過程：
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叢集，如下。
喜歡我寫的東西的朋友可以關注一下我的公眾號,上面有我的學習資源以及一些其他福利。：Devops部落
