了解什么是容器編排？
容器編排就是有關(guān)管理容器生命周期的全部工作，特別是在大型動態(tài)環(huán)境中。 軟件團(tuán)隊(duì)使用容器編排來控制和自動化許多任務(wù)：
調(diào)配和部署容器
容器的冗余和可用性
擴(kuò)展或刪除容器以在主機(jī)基礎(chǔ)結(jié)構(gòu)中平均分配應(yīng)用程序負(fù)載
如果主機(jī)中的資源不足或主機(jī)死亡，則將容器從一個主機(jī)移至另一主機(jī)
容器之間的資源分配
在外部容器中運(yùn)行的服務(wù)的外部暴露
容器之間服務(wù)發(fā)現(xiàn)的負(fù)載平衡
容器和主機(jī)的健康監(jiān)控
與運(yùn)行它的容器有關(guān)的應(yīng)用程序配置
Kubernetes
- Kubernetes是一個開源系統(tǒng)，用于跨多個主機(jī)管理容器化的應(yīng)用程序，提供了用于部署，維護(hù)和擴(kuò)展應(yīng)用程序的基本機(jī)制
- Kubernetes建立在Google十年半的經(jīng)驗(yàn)之上，使用稱為Borg的系統(tǒng)大規(guī)模運(yùn)行生產(chǎn)工作負(fù)載，并結(jié)合了社區(qū)中的最佳創(chuàng)意和實(shí)踐
Kubernetes集群
?運(yùn)行中的Kubernetes集群包含節(jié)點(diǎn)代理（kubelet）和集群控制平面（AKA主節(jié)點(diǎn)），集群狀態(tài)由分布式存儲系統(tǒng)（etcd）支持
Kubernetes主要由以下幾個核心組件組成：
Master 組件
etcd 保存了整個集群的狀態(tài)；
kube-apiserver 提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機(jī)制；
kube-controller-manager 負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測、自動擴(kuò)展、滾動更新等；
kube-scheduler 負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；
Node 組件
kubelet 負(fù)責(zé)維護(hù)容器的生命周期，同時也負(fù)責(zé)Volume（CSI）和網(wǎng)絡(luò)（CNI）的管理；
kube-proxy 負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；
Container runtime 負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI）；
除了核心組件，還有一些推薦的插件，其中有的已經(jīng)成為CNCF中的托管項(xiàng)目：
Addons
CoreDNS 負(fù)責(zé)為整個集群提供DNS服務(wù)
Ingress Controller為服務(wù)提供外網(wǎng)入口
Prometheus提供資源監(jiān)控
Dashboard提供GUI
Federation提供跨可用區(qū)的集群
Kubernetes Master
Kube-Master 的工作流程圖
Kubecfg 將特定的請求發(fā)送給 Kubernetes Client（比如：創(chuàng)建 Pod 的請求）。
Kubernetes Client 將請求發(fā)送給 API Server。
API Server 會根據(jù)請求的類型選擇用何種 REST API 對請求作出處理（比如：創(chuàng)建 Pod 時 Storage 類型是 Pods 時，其對應(yīng)的就是 REST Storage API）。
REST Storage API 會對請求作相應(yīng)的處理并將處理的結(jié)果存入高可用鍵值存儲系統(tǒng) Etcd 中。
在 API Server 響應(yīng) Kubecfg 的請求后，Scheduler 會根據(jù) Kubernetes Client 獲取的集群中運(yùn)行 Pod 及 Minion / Node 信息將未分發(fā)的 Pod 分發(fā)到可用的 Minion / Node 節(jié)點(diǎn)上。
API Server 「資源操作入口」
API Server 提供了資源對象的唯一操作入口，其它所有組件都必須通過它提供的 API 來操作資源數(shù)據(jù)。只有 API Server 會與存儲通信，其它模塊都必須通過 API Server 訪問集群狀態(tài)。
API Server 作為 Kubernetes 系統(tǒng)的入口，封裝了核心對象的增刪改查操作。API Server 以 RESTFul 接口方式提供給外部客戶和內(nèi)部組件調(diào)用，API Server 再對相關(guān)的資源數(shù)據(jù)（全量查詢 + 變化監(jiān)聽）進(jìn)行操作，以達(dá)到實(shí)時完成相關(guān)的業(yè)務(wù)功能。
以 API Server 為 Kubernetes 入口的設(shè)計主要有以下好處：1. 保證了集群狀態(tài)訪問的安全。2. API Server 隔離了集群狀態(tài)訪問和后端存儲實(shí)現(xiàn)，這樣 API Server 狀態(tài)訪問的方式不會因?yàn)楹蠖舜鎯夹g(shù) Etcd 的改變而改變，讓后端存儲方式選擇更加靈活，方便了整個架構(gòu)的擴(kuò)展。
Controller Manager 「內(nèi)部管理控制中心」
Controller Manager 用于實(shí)現(xiàn) Kubernetes 集群故障檢測和恢復(fù)的自動化工作。Controller Manager 主要負(fù)責(zé)執(zhí)行以下各種控制器：
Replication Controller Replication Controller 的作用主要是定期關(guān)聯(lián) Replication Controller (RC) 和 Pod，以保證集群中一個 RC (一種資源對象) 所關(guān)聯(lián)的 Pod 副本數(shù)始終保持為與預(yù)設(shè)值一致。
Node Controller Kubelet 在啟動時會通過 API Server 注冊自身的節(jié)點(diǎn)信息，并定時向 API Server 匯報狀態(tài)信息。API Server 在接收到信息后將信息更新到 Etcd 中。 Node Controller 通過 API Server 實(shí)時獲取 Node 的相關(guān)信息，實(shí)現(xiàn)管理和監(jiān)控集群中的各個 Node 節(jié)點(diǎn)的相關(guān)控制功能。
ResourceQuota Controller 資源配額管理控制器用于確保指定的資源對象在任何時候都不會超量占用系統(tǒng)上物理資源。
Namespace Controller 用戶通過 API Server 可以創(chuàng)建新的 Namespace 并保存在 Etcd 中，Namespace Controller 定時通過 API Server 讀取這些 Namespace 信息來操作 Namespace。 比如：Namespace 被 API 標(biāo)記為優(yōu)雅刪除，則將該 Namespace 狀態(tài)設(shè)置為 Terminating 并保存到 Etcd 中。同時 Namespace Controller 刪除該 Namespace 下的 ServiceAccount、RC、Pod 等資源對象。
Service Account Controller Service Account Controller (服務(wù)賬號控制器)，主要在命名空間內(nèi)管理 ServiceAccount，以保證名為 default 的 ServiceAccount 在每個命名空間中存在。
Token Controller Token Controller（令牌控制器）作為 Controller Manager 的一部分，主要用作：監(jiān)聽 serviceAccount 的創(chuàng)建和刪除動作以及監(jiān)聽 secret 的添加、刪除動作。
Service Controller Service Controller 是屬于 Kubernetes 集群與外部平臺之間的一個接口控制器，Service Controller 主要用作監(jiān)聽 Service 的變化。 比如：創(chuàng)建的是一個 LoadBalancer 類型的 Service，Service Controller 則要確保外部的云平臺上對該 Service 對應(yīng)的 LoadBalancer 實(shí)例被創(chuàng)建、刪除以及相應(yīng)的路由轉(zhuǎn)發(fā)表被更新。
Endpoint Controller Endpoints 表示了一個 Service 對應(yīng)的所有 Pod 副本的訪問地址，而 Endpoints Controller 是負(fù)責(zé)生成和維護(hù)所有 Endpoints 對象的控制器。 Endpoint Controller 負(fù)責(zé)監(jiān)聽 Service 和對應(yīng)的 Pod 副本的變化。定期關(guān)聯(lián) Service 和 Pod (關(guān)聯(lián)信息由 Endpoint 對象維護(hù))，以保證 Service 到 Pod 的映射總是最新的。
Scheduler「集群分發(fā)調(diào)度器」
Scheduler 主要用于收集和分析當(dāng)前 Kubernetes 集群中所有 Minion / Node 節(jié)點(diǎn)的資源 (包括內(nèi)存、CPU 等) 負(fù)載情況，然后依據(jù)資源占用情況分發(fā)新建的 Pod 到 Kubernetes 集群中可用的節(jié)點(diǎn)。
Scheduler 會實(shí)時監(jiān)測 Kubernetes 集群中未分發(fā)和已分發(fā)的所有運(yùn)行的 Pod。
Scheduler 會實(shí)時監(jiān)測 Minion / Node 節(jié)點(diǎn)信息，由于會頻繁查找 Minion/Node 節(jié)點(diǎn)，Scheduler 同時會緩存一份最新的信息在本地。
Scheduler 在分發(fā) Pod 到指定的 Minion / Node 節(jié)點(diǎn)后，會把 Pod 相關(guān)的信息 Binding 寫回 API Server，以方便其它組件使用。
Kube-Node「服務(wù)節(jié)點(diǎn)」
Kubelet 「節(jié)點(diǎn)上的 Pod 管家」
負(fù)責(zé) Node 節(jié)點(diǎn)上 Pod 的創(chuàng)建、修改、監(jiān)控、刪除等全生命周期的管理。
定時上報本地 Node 的狀態(tài)信息給 API Server。Kubelet 是 Master API Server 和 Minion / Node 之間的橋梁，接收 Master API Server 分配給它的 Commands 和 Work。
Kubelet 通過 Kube ApiServer 間接與 Etcd 集群交互來讀取集群配置信息。
Kubelet 在 Node 上做的主要工作具體如下：1. 設(shè)置容器的環(huán)境變量、給容器綁定 Volume、給容器綁定 Port、根據(jù)指定的 Pod 運(yùn)行一個單一容器、給指定的 Pod 創(chuàng)建 Network 容器。2. 同步 Pod 的狀態(tài)，從 cAdvisor 獲取 Container Info、 Pod Info、 Root Info、 Machine info。3. 在容器中運(yùn)行命令、殺死容器、刪除 Pod 的所有容器。
Proxy「負(fù)載均衡、路由轉(zhuǎn)發(fā)」
Proxy 是為了解決外部網(wǎng)絡(luò)能夠訪問集群中容器提供的應(yīng)用服務(wù)而設(shè)計的，Proxy 運(yùn)行在每個 Minion / Node 上。
Proxy 提供 TCP / UDP 兩種 Sockets 連接方式 。每創(chuàng)建一個 Service，Proxy 就會從 Etcd 獲取 Services 和 Endpoints 的配置信息（也可以從 File 獲取），然后根據(jù)其配置信息在 Minion / Node 上啟動一個 Proxy 的進(jìn)程并監(jiān)聽相應(yīng)的服務(wù)端口。當(dāng)外部請求發(fā)生時，Proxy 會根據(jù) Load Balancer 將請求分發(fā)到后端正確的容器處理。
Proxy 不但解決了同一宿主機(jī)相同服務(wù)端口沖突的問題，還提供了 Service 轉(zhuǎn)發(fā)服務(wù)端口對外提供服務(wù)的能力。
Proxy 后端使用隨機(jī)、輪循等負(fù)載均衡算法進(jìn)行調(diào)度。
Kubectl 「集群管理命令行工具集」
- Kubectl 是 Kubernetes 的 客戶端的工具。 通過 Kubectl 命令對 API Server 進(jìn)行操作，API Server 響應(yīng)并返回對應(yīng)的命令結(jié)果，從而達(dá)到對 Kubernetes 集群的管理。
Kubernetes Network
客戶端訪問 ——> service1 ——> Pod1 ——> service2 ——>Pod2
所有的Pod之前的訪問都是由其service來代理的，當(dāng)Pod間知道相應(yīng)的Pod的IP后，就會直接進(jìn)行通信，可以理解為DNS的作用。
Kubernetes的關(guān)鍵概念
? Pod - 一組容器
? 標(biāo)簽 - 用于識別Pods的標(biāo)簽
? Kubelet - 容器代理
? kube-proxy - Pod的負(fù)載平衡器
? etcd - 元數(shù)據(jù)服務(wù)
? cAdvisor - 容器顧問提供者資源使用/性能統(tǒng)計
? Replication Controller - 管理Pod的復(fù)制
? Scheduler- 調(diào)度工作節(jié)點(diǎn)中的Pod
? API Server - Kubernetes API服務(wù)器
什么是Pod？
一組或多個容器，這些容器始終位于同一位置并共同調(diào)度，并共享上下文
Pod中的容器共享相同的IP地址，端口，主機(jī)名和存儲
像虛擬機(jī)一樣建模
每個容器表示一個進(jìn)程
在同一Pod中的容器緊密耦合
Pods被安排在Nodes節(jié)點(diǎn)中
Kubernetes的基本部署單位
同一個Pod內(nèi)的容器使用IPC相互通信；
容器可以通過本地主機(jī)找到彼此；
每個容器都繼承Pod的名稱
每個Pod在扁平的共享網(wǎng)絡(luò)空間中都有一個IP地址
Volumes卷由Pod中的容器共享
Pod用例
內(nèi)容管理系統(tǒng)，文件和數(shù)據(jù)加載器，本地緩存管理器等。
日志和檢查點(diǎn)備份，壓縮，循環(huán)，快照等。
數(shù)據(jù)更改監(jiān)視程序，日志尾部，日志記錄和監(jiān)視適配器，事件 出版商等
代理，網(wǎng)橋和適配器
控制器，管理器，配置器和更新器
Replication Controller
確保一個Pod或同類Pods始終處于可用狀態(tài)
始終保持所需的Pods數(shù)量
如果有過多的Pod，它們會被殺死
新Pods失敗，被刪除或終止時將啟動它們
創(chuàng)建至少一個Replication Controller以確保Pod始終可用
創(chuàng)建Replication Controller和容器通過標(biāo)簽關(guān)聯(lián)
Controller
管理Pod | 復(fù)制集
處理復(fù)制和推出 | 部署
提供自我修復(fù)功能 | 守護(hù)程序集
使用個Pod模板制作真實(shí)的Pods | 工作
Service
Kubernetes Pods不是永久的，待面世停止運(yùn)轉(zhuǎn)后，是不能再次夠恢復(fù)使用的
Controllers專用于動態(tài)創(chuàng)建和銷毀Pods（例如，在放大或縮小或滾動更新時）
雖然每個POD都有自己的IP地址，但這些IP地址不能長期穩(wěn)定
這會導(dǎo)致一個問題：如果kubernetes集群中的一些pod（我們稱之為后端）為其他pod（我們稱之為前端）提供功能，那么這些前端如何發(fā)現(xiàn)并跟蹤該集群中的哪些后端？
Kubernetes Service是一種抽象概念，它定義了Pod的邏輯集和訪問它們的策略-有時稱為微服務(wù)
Service 所針對的Pod集（通常）由標(biāo)簽選擇器確定
對于Kubernetes原生應(yīng)用程序，Kubernetes提供了一個簡單的Endpoints API，只要Service中的Pod集發(fā)生更改，該API就會更新
對于非本機(jī)應(yīng)用程序，Kubernetes提供了基于虛擬IP的服務(wù)橋，該橋可重定向到后端Pod
Labels & Selectors
與Kubernetes對象關(guān)聯(lián)的鍵/值對
用于組織和選擇對象的子集
在創(chuàng)建時附加到對象，但可以隨時修改
標(biāo)簽是將一個API對象與另一個API對象關(guān)聯(lián)的必要粘合劑
Replication Controller ->Pods
Service -> Pods
Pods->Nodes
Service
定義一組邏輯pod的抽象，這些邏輯pod通過訪問策略綁定他們
通過內(nèi)部和外部端點(diǎn)公開Service
務(wù)還可以通過Virtual-IP-Bridge指向非Kubernetes端點(diǎn)
支持TCP和UDP
與kube-proxy的接口以操作iptables
Service可以在集群內(nèi)部或外部公開
Service作為靜態(tài)API對象
虛擬但靜態(tài)IP
無需發(fā)現(xiàn)Service
一群一起工作的Pods
按選擇器分組
定義訪問策略
“負(fù)載平衡”或“無頭”
獲得穩(wěn)定的虛擬IP和端口
有時稱為服務(wù)門戶
也是一個dns名稱
VIP由Kube代理管理
監(jiān)視所有Service
當(dāng)后端發(fā)生變化時更新iptables
對于非本地應(yīng)用程序隱藏復(fù)雜度理想的選擇
kube-proxy
在每個節(jié)點(diǎn)上運(yùn)行-代理udp和tcp-不理解http-提供負(fù)載平衡-僅用于訪問Service
kubernetes網(wǎng)絡(luò)代理在每個節(jié)點(diǎn)上運(yùn)行
這反映了每個節(jié)點(diǎn)上kubernetes api中定義的Service，可以跨一組后端執(zhí)行簡單的tcp、udp流轉(zhuǎn)發(fā)或循環(huán)tcp、udp轉(zhuǎn)發(fā)。
Service群集IP和端口當(dāng)前通過Docker Link兼容的環(huán)境變量找到，這些環(huán)境變量指定Service代理打開的端口
有一個可選的插件為這些群集IP提供群集DNS
用戶必須使用APIServer API創(chuàng)建Service以配置代理
Proxy-mode: userspace
- 對于每個Service，它都會在本地節(jié)點(diǎn)上打開一個端口（隨機(jī)選擇）
- 與此“代理端口”的任何連接都將代理到Service的后端Pod之一
Proxy-mode: iptables
- 為每個Service安裝iptables規(guī)則，以捕獲到Service的clusterIP（虛擬）和端口的流量，并將該流量重定向到Service的后端集之一
- 為每個Endpoints對象安裝iptables規(guī)則，該規(guī)則選擇一個后端Pod
Discovering services
kubernetes支持查找Service的兩種主要模式-環(huán)境變量和dns
環(huán)境變量
當(dāng)pod在節(jié)點(diǎn)上運(yùn)行時，kubelet為每個活Service務(wù)添加一組環(huán)境變量。它同時支持docker links兼容變量和更簡單的{SVCNAME}SERVICE_HOST和{SVCNAME}SERVICE_PORT變量，其中Service名稱為大寫，破折號轉(zhuǎn)換為下劃線。
DNS
一個可選的（盡管強(qiáng)烈建議）群集附加組件是DNS服務(wù)器
DNS服務(wù)器監(jiān)視Kubernetes API以獲取新Service，并為每個Service創(chuàng)建一組DNS記錄
如果在整個集群中啟用了dns，那么所有pod都應(yīng)該能夠自動執(zhí)行Service的名稱解析
Ingress
- 通常，Service和pod只有ips可以通過集群網(wǎng)絡(luò)路由。所有最終到達(dá)邊緣路由器的流量要么被丟棄，要么被轉(zhuǎn)發(fā)到其他地方
- Ingress 是允許入站連接訪問集群Service的規(guī)則集合
- Ingress——基于URL的路由
- Ingress是允許入站連接訪問集群Service的規(guī)則集合
Overlay network concept
kubernetes Object
kubernetes對象是kubernetes系統(tǒng)中的持久性實(shí)體
kubernetes使用這些實(shí)體來表示集群的狀態(tài)
具體來說，他們可以描述：
哪些docker化應(yīng)用程序正在運(yùn)行（以及在哪些節(jié)點(diǎn)上運(yùn)行）
這些應(yīng)用程序可用的資源
有關(guān)這些應(yīng)用程序行為的策略，如重啟策略、升級和容錯
kubernetes對象是一個“意圖記錄”-創(chuàng)建對象后，kubernetes系統(tǒng)將不斷工作以確保對象存在
通過創(chuàng)建一個對象，您可以有效地告訴kubernetes系統(tǒng)您希望集群的工作負(fù)載是什么樣的；這是集群的期望狀態(tài)
要使用kubernetes對象，無論是創(chuàng)建、修改還是刪除它們，都需要使用kubernetes api
例如，當(dāng)您使用kubectl命令行界面時，cli會為您進(jìn)行必要的kubernetes api調(diào)用；您也可以在自己的程序中直接使用kubernetes api
Object 規(guī)格和狀態(tài)
每個Kubernetes對象都包含兩個嵌套的對象字段，用于控制對象的配置：對象規(guī)格和對象狀態(tài)
您必須提供的規(guī)范描述了對象的所需狀態(tài)-希望對象具有的特征
狀態(tài)描述對象的實(shí)際狀態(tài)，并由Kubernetes系統(tǒng)提供和更新。
在任何給定時間，Kubernetes控制平面都會主動管理對象的實(shí)際狀態(tài)以匹配您提供的所需狀態(tài)
描述Kubernetes對象
在Kubernetes中創(chuàng)建對象時，必須提供描述其所需狀態(tài)的對象規(guī)范，以及有關(guān)該對象的一些基本信息（例如名稱）
當(dāng)您使用Kubernetes API創(chuàng)建對象（直接或通過kubectl）時，該API請求必須在請求正文中以JSON形式包含該信息
通常，您會在.yaml文件中將信息提供給kubectl。 發(fā)出API請求時，kubectl將信息轉(zhuǎn)換為JSON
K8s主要由Master,Node組成
Client -> Master(API Server)
Registry: Docker Hub,gcr.io,quay.io
測試環(huán)境：
1 Master
3 Nodes
kubeadm:
Master,Node
CentOS:kubeadm,kubelet
