了解什么是容器編排？

容器編排就是有關(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）支持

image

image

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

image

Kube-Master 的工作流程圖

image

1. Kubecfg 將特定的請求發(fā)送給 Kubernetes Client（比如：創(chuàng)建 Pod 的請求）筑悴。

2. Kubernetes Client 將請求發(fā)送給 API Server们拙。

3. API Server 會根據(jù)請求的類型選擇用何種 REST API 對請求作出處理（比如：創(chuàng)建 Pod 時 Storage 類型是 Pods 時，其對應(yīng)的就是 REST Storage API）阁吝。

4. REST Storage API 會對請求作相應(yīng)的處理并將處理的結(jié)果存入高可用鍵值存儲系統(tǒng) Etcd 中砚婆。

5. 在 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è)計(jì)主要有以下好處：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í)行以下各種控制器：

image

• 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 匯報(bào)狀態(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)」

image

image

Kubelet 「節(jié)點(diǎn)上的 Pod 管家」

• 負(fù)責(zé) Node 節(jié)點(diǎn)上 Pod 的創(chuàng)建咆繁、修改讳推、監(jiān)控、刪除等全生命周期的管理玩般。

• 定時上報(bào)本地 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è)計(jì)的，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

image

客戶端訪問 ——> 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)計(jì)

? 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

image

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

image

• 一群一起工作的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

image

• 對于每個Service，它都會在本地節(jié)點(diǎn)上打開一個端口（隨機(jī)選擇）
• 與此“代理端口”的任何連接都將代理到Service的后端Pod之一

Proxy-mode: iptables

image

• 為每個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ī)則集合

image

• Ingress——基于URL的路由
• Ingress是允許入站連接訪問集群Service的規(guī)則集合

Overlay network concept

image

image

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