Kubernetes 系列第一篇: Kubernetes 介紹和名詞解釋

1. Kubernetes 簡(jiǎn)介

1.1. 什么是 Kubernetes

kubernetes 簡(jiǎn)稱 k8s(因?yàn)閗和s之間有8個(gè)字母), 是 Google 旗下的開源容器編排平臺(tái), k8s 的誕生深受 Google 內(nèi)部容器編排系統(tǒng) Borg 的影響, k8s 實(shí)現(xiàn)了如下功能

自動(dòng)裝箱

建構(gòu)于容器之上, 基于資源依賴及其他約束條件自動(dòng)完成容器部署

自我修復(fù)

支持容器故障后自動(dòng)重啟、節(jié)點(diǎn)故障后重新調(diào)度容器, 以及節(jié)點(diǎn)健康狀態(tài)檢查失敗后關(guān)閉容器并重新創(chuàng)建等自我修復(fù)機(jī)制

水平擴(kuò)展

支持通過命令或 UI 手動(dòng)水平擴(kuò)展, 以及基于 CPU 等資源負(fù)載率的自動(dòng)水平擴(kuò)展機(jī)制

服務(wù)發(fā)現(xiàn)和負(fù)載均衡

k8s 通過 CoreDNS 附件為系統(tǒng)內(nèi)置了服務(wù)發(fā)現(xiàn)功能, 為每個(gè) Service 配置 DNS 名稱, 并允許集群內(nèi)的客戶端直接使用此名稱發(fā)出訪問請(qǐng)求, Service 通過 iptables 或 ipvs 內(nèi)建負(fù)載均衡機(jī)制

自動(dòng)發(fā)布和回滾

k8s 支持灰度更新應(yīng)用程序或其配置信息, 在更新過程中 k8s 將會(huì)監(jiān)控更新過程中應(yīng)用程序的健康狀態(tài), 以確保 k8s 不會(huì)在同一時(shí)刻殺掉所有實(shí)例, 而此過程中一旦有故障發(fā)生, 將會(huì)立即自動(dòng)執(zhí)行回滾操作

秘鑰和配置管理

k8s 的 ConfigMap 實(shí)現(xiàn)了配置數(shù)據(jù)與 Docker 鏡像解耦, 需要時(shí)僅對(duì)配置做出變更而無須重新構(gòu)建 Docker 鏡像, 這為應(yīng)用開發(fā)和部署帶來極大的靈活性
對(duì)于應(yīng)用所依賴的一些敏感數(shù)據(jù), 如用戶名和密碼、令牌、密鑰等信息, k8s 提供了 Secret 對(duì)象為其解耦, 既便利了應(yīng)用的快速開發(fā)和交付, 又提供了一定程度上的安全保障

存儲(chǔ)編排

k8s 支持 Pod 對(duì)象按需自動(dòng)掛載不同類型的存儲(chǔ)系統(tǒng), 包括節(jié)點(diǎn)本地存儲(chǔ)、公有云服務(wù)商云存儲(chǔ), 以及網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)(NFS, Ceph, GlusterFS 等)

2. 節(jié)點(diǎn)和組件

一般情況下一個(gè) k8s 集群由多個(gè)工作節(jié)點(diǎn)(worker node)和一個(gè)集群控制節(jié)點(diǎn)(master)以及一個(gè)集群狀態(tài)存儲(chǔ)系統(tǒng)(etcd)組成

2.1. Master 節(jié)點(diǎn)

Master 是集群的網(wǎng)關(guān)和中樞, 負(fù)責(zé)集群的管理工作, 諸如為用戶和客戶端暴露API, 跟蹤其他服務(wù)器的健康狀況、以最優(yōu)方式調(diào)度工作負(fù)載, 以及編排其他組件之間的通信等任務(wù), 它是用戶或客戶端與集群之間的核心聯(lián)絡(luò)點(diǎn)
單個(gè) Master 節(jié)點(diǎn)即可完成其所有的功能, 但出于冗余及負(fù)載均衡等目的, 生產(chǎn)環(huán)境中通常需要部署多個(gè) master 節(jié)點(diǎn)
Master 節(jié)點(diǎn)主要由 apiserver、controller-manager 和 scheduler 三個(gè)組件以及一個(gè)用于存儲(chǔ)集群狀態(tài)的 etcd 存儲(chǔ)服務(wù)組成

2.2. Node 節(jié)點(diǎn)

Node 是 k8s 集群的工作節(jié)點(diǎn)(Worker), 并接收來自 Master 的指令并根據(jù)指令完成響應(yīng)操作, 如創(chuàng)建或銷毀 Pod 對(duì)象、調(diào)整網(wǎng)絡(luò)規(guī)則等操作
Master 節(jié)點(diǎn)主要由 kubelet、kube-proxy 和容器引擎(docker 是最為常見的容器引擎) 組成

2.3. Master 組件

集群網(wǎng)關(guān)(API Server)

k8s 集群的網(wǎng)關(guān)接口, 負(fù)責(zé)解析客戶端的請(qǐng)求

集群狀態(tài)存儲(chǔ)(etcd)

存放 k8s 持久化數(shù)據(jù), 提供監(jiān)聽(watch)機(jī)制, 用于監(jiān)聽和推送變更
在 k8s 集群系統(tǒng)中, etcd 中的鍵值發(fā)生變化時(shí)會(huì)通知到 API Server, 并由其通過 watchAPI 向客戶端輸出?；?watch 機(jī)制 k8s 集群的各組件實(shí)現(xiàn)了高效協(xié)同

調(diào)度器(Scheduler)

在用戶發(fā)出創(chuàng)建 Pod 請(qǐng)求時(shí), Scheduler 根據(jù)各 Node 資源情況, 以及容器所需要的資源做出調(diào)度決定這個(gè) Pod 將在那個(gè) Node 上創(chuàng)建

控制器管理器(ControllerManager)

檢查控制器是否處于健康狀態(tài)

2.4. Node 組件

kubelet

負(fù)責(zé)和 Master 節(jié)點(diǎn)進(jìn)行通信, 接收 Master 調(diào)度過來的任務(wù), 檢查節(jié)點(diǎn)上的 Pod 是否處于健康狀態(tài)

容器引擎

負(fù)責(zé)運(yùn)行容器, 目前最為流行的容器引擎為 Docker, k8s 目前支持 Rtk 和 Docker 兩種容器引擎

kube-proxy

根據(jù) Service 資源對(duì)象生 iptables 或 ipvs 規(guī)則, 從而將用戶請(qǐng)求轉(zhuǎn)發(fā)到指定的 Pod 中

3. k8s 術(shù)語

3.1. Pod

k8s 并不直接調(diào)度容器, 而是使用一個(gè)抽象的資源對(duì)象來封裝一個(gè)或者多個(gè)容器, 這個(gè)抽象對(duì)象被稱為 Pod, 它也是 k8s 最小的調(diào)度單元
同一 Pod 中的容器共享網(wǎng)絡(luò)名稱空間和存儲(chǔ)資源, 這些容器可經(jīng)由本地回環(huán)節(jié)口lo直接通信, 但彼此之間又在 Mount、User 以及 PID 等名稱空間上保持隔離
盡管 Pod 中可以包含多個(gè)容器, 但是作為最小調(diào)度單元, 它應(yīng)該盡可能地保持小, 即通常只應(yīng)該包含一個(gè)主容器, 以及其他必要的輔助型容器(sidecar)

3.2. 資源標(biāo)簽

標(biāo)簽(Label)是將資源進(jìn)行分類的標(biāo)識(shí)符, 資源標(biāo)簽其實(shí)就是一個(gè)鍵值型(key/values)數(shù)據(jù)
標(biāo)簽是在指定對(duì)象上辨識(shí)性的屬性, 這些屬性僅對(duì)用戶存在特定的意義, 對(duì) k8s 集群來說意義并不大
標(biāo)簽可以在對(duì)象創(chuàng)建時(shí)附加在其上, 并能夠在創(chuàng)建后的任意時(shí)間進(jìn)行添加和修改。一個(gè)對(duì)象可以擁有多個(gè)標(biāo)簽, 一個(gè)標(biāo)簽也可以附加在多個(gè)對(duì)象上

3.3. 標(biāo)簽選擇器

標(biāo)簽選擇器(Selector)全稱為Label Selector它是一種根據(jù) Label 來過濾符合條件的資源對(duì)象的機(jī)制
例如, 將附有標(biāo)簽role: backend的所有 Pod 對(duì)象挑選出來歸為一組就是標(biāo)簽選擇器的一種應(yīng)用
用戶通常使用標(biāo)簽對(duì)資源對(duì)象進(jìn)行分類, 而后使用標(biāo)簽選擇器挑選出它們, 對(duì)他們進(jìn)行批量操作

3.4. Pod 控制器

通常情況下用戶不會(huì)直接去部署和管理 Pod 對(duì)象, 而是要借助于另一類抽象控制器(Controller)對(duì)其進(jìn)行管理
k8s 內(nèi)置了大量的控制器用于管理 Pod 對(duì)象, 常見的控制器如下

ReplicationController   K8s 早期使用的控制器
ReplicaSet              副本集, 一般不直接使用此管理器而是使用 Deployment 管理器
Deployment              管理無狀態(tài)應(yīng)用
StatefulSet             管理有狀態(tài)應(yīng)用
Job                     運(yùn)行作業(yè)
Cronjob                 運(yùn)行周期性作業(yè)
DaemonSet               在每個(gè) Node 上都運(yùn)行一個(gè)副本, 而不是在隨機(jī)節(jié)點(diǎn)上運(yùn)行

3.5. 服務(wù)資源(service)

Service 是建立在一組 Pod 對(duì)象之上的資源抽象, 它通過標(biāo)簽選擇器(Label Selector)選定一組 Pod 對(duì)象, 并為這組 Pod 對(duì)象定義一個(gè)統(tǒng)一的固定訪問入口(通常是一個(gè)IP 地址), 若 k8s 集群存在 DNS 附件, 它就會(huì)在 Service 創(chuàng)建時(shí)為其自動(dòng)配置一個(gè)DNS 名稱以便客戶端進(jìn)行服務(wù)發(fā)現(xiàn)
到達(dá) Service IP 的請(qǐng)求將被負(fù)載均衡至其后的各個(gè) Pod 對(duì)象之上, 因此 Service 從本質(zhì)上來講是一個(gè)四層代理服務(wù)

3.6. 存儲(chǔ)卷(volume)

存儲(chǔ)卷(Volume)是獨(dú)立于容器文件系統(tǒng)之外的存儲(chǔ)空間, 常用于擴(kuò)展容器的存儲(chǔ)空間并為它提供持久存儲(chǔ)能力
k8s 集群上的存儲(chǔ)卷大體可分為臨時(shí)卷、本地卷和網(wǎng)絡(luò)卷
臨時(shí)卷和本地卷都位于 Node 本地, 一旦 Pod 被調(diào)度至其他 Node, 此種類型的存儲(chǔ)卷將無法被訪問到, 因此臨時(shí)卷和本地卷通常用于數(shù)據(jù)緩存, 持久化的數(shù)據(jù)則需要放置于持久卷(persistent volume)之上

3.7. Name 和 Namespace

Name 是 k8s 集群中資源對(duì)象的標(biāo)識(shí)符, 它們的作用域通常是名稱空間(Namespace)在同一個(gè)名稱空間中, 同一類型資源、對(duì)象的名稱必須具有唯一性
名稱空間通常用于實(shí)現(xiàn)用戶或項(xiàng)目的資源隔離, 從而形成邏輯分組, 默認(rèn)的名稱空間為 default

3.8. Annotation(注解)

Annotation(注解)是一種附加在對(duì)象之上的鍵值類型的數(shù)據(jù), 它擁比 Label 有更大的數(shù)據(jù)容量
Annotation 常用于將各種非標(biāo)識(shí)型數(shù)據(jù)附加到對(duì)象上, 但它不能用于標(biāo)識(shí)和選擇對(duì)象, 通常也不會(huì)被 k8s 直接使用, 其主要目的是方便用戶的閱讀及查找等

3.9. Ingress

k8s 將 Pod 對(duì)象和外部網(wǎng)絡(luò)環(huán)境進(jìn)行了隔離, Pod 和 Service 等對(duì)象間的通信都使用其內(nèi)部專用地址進(jìn)行, 如若需要開放某些 Pod 對(duì)象提供給外部用戶訪問, 則需要為其請(qǐng)求流量打開一個(gè)通往 k8s 集群內(nèi)部的通道, 除了 service 之外, Ingress 也是這類通道的實(shí)現(xiàn)方式之一

3.10. Pause 容器

在每個(gè) Pod 中都運(yùn)行著一個(gè)特殊的容器, 即 Pause 容器, 而其他容器則為用戶定義的容器, 這些用戶定義的容器共享 Pause 容器的網(wǎng)絡(luò)棧和 Volume 掛載卷, 因此它們之間的通信和數(shù)據(jù)交換更為高效; 在程序設(shè)計(jì)時(shí)我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進(jìn)程放入同一個(gè) Pod 中

4. 核心附件

k8s 通過一組被稱為附件的組件提供更加豐富的功能, 附件通常由第三方提供, 為 k8s 提供特定的功能, 且通常以 Pod 的方式運(yùn)行在 k8s 集群之上

4.1. k8s 常見附件

• CoreDNS 為 k8s 集群提供 DNS 服務(wù)
• Kubernetes Dashboard 為 k8s 集群提供 Web UI 界面
• Heapster k8s 集群監(jiān)控, 目前已逐步被 Prometheus 代替
• Ingress Controller k8s 網(wǎng)絡(luò)的另一種實(shí)現(xiàn)方式, 為 k8s 提供區(qū)別于 service 的網(wǎng)絡(luò)模型

5. k8s 網(wǎng)絡(luò)

k8s 網(wǎng)絡(luò)中主要有 4 種網(wǎng)絡(luò)通信類型

5.1. 網(wǎng)絡(luò)通信類型

同一 Pod 內(nèi)的容器之間互相通信

同一 Pod 之間的容器共享網(wǎng)絡(luò)名稱空間, 通過 lo 接口進(jìn)行通信

Pod 與 Pod 之間的通信

Pod 網(wǎng)絡(luò)由 k8s 網(wǎng)絡(luò)插件實(shí)現(xiàn), 執(zhí)行插件都遵循 CNI 協(xié)議, 主流的網(wǎng)絡(luò)插件有 flannel、calico、canel 等, 這些網(wǎng)絡(luò)插件會(huì)為所有的 Pod 對(duì)象配置至少一個(gè)特點(diǎn)的地址, 即 Pod IP, Pod IP 實(shí)際存在于網(wǎng)卡之上

Pod 和 Service 之間的通信

Service 由 k8s 集群指定, 默認(rèn)使用的 10.96.0.0/12 網(wǎng)段, 一般情況下每一組 Pod 都至少有一個(gè) Service, 這一組 Pod 之間通過 Service 進(jìn)行網(wǎng)絡(luò)通信
Pod 通過標(biāo)簽選擇器和 Service 創(chuàng)建關(guān)聯(lián)關(guān)系, Service 地址不存在于任何網(wǎng)絡(luò)接口之上, 它是由 kube-proxy 借助 iptables 或者 ipvs 創(chuàng)建的 NET 規(guī)則

集群外部流量和 Service 之間的通信

k8s 對(duì)外暴露一個(gè)訪問地址, 當(dāng)用戶訪問時(shí)先到達(dá)這個(gè)唯一訪問接口, 在通過 iptables 或者 ipvs 規(guī)則轉(zhuǎn)發(fā)到指定 Service, Service 在將其轉(zhuǎn)發(fā)的特定的 Pod 之上