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

1. Kubernetes 簡介

1.1. 什麼是 Kubernetes

kubernetes 簡稱 k8s(由於k和s之間有8個字母), 是 Google 旗下的開源容器編排平臺, k8s 的誕生深受 Google 內部容器編排系統 Borg 的影響, k8s 實現了以下功能

自動裝箱

建構於容器之上, 基於資源依賴及其餘約束條件自動完成容器部署

自我修復

支持容器故障後自動重啓、節點故障後從新調度容器, 以及節點健康狀態檢查失敗後關閉容器並從新建立等自我修復機制

水平擴展

支持經過命令或 UI 手動水平擴展, 以及基於 CPU 等資源負載率的自動水平擴展機制

服務發現和負載均衡

k8s 經過 CoreDNS 附件爲系統內置了服務發現功能, 爲每一個 Service 配置 DNS 名稱, 並容許集羣內的客戶端直接使用此名稱發出訪問請求, Service 經過 iptables 或 ipvs 內建負載均衡機制

自動發佈和回滾

k8s 支持灰度更新應用程序或其配置信息, 在更新過程當中 k8s 將會監控更新過程當中應用程序的健康狀態, 以確保 k8s 不會在同一時刻殺掉全部實例, 而此過程當中一旦有故障發生, 將會當即自動執行回滾操做

祕鑰和配置管理

k8s 的 ConfigMap 實現了配置數據與 Docker 鏡像解耦, 須要時僅對配置作出變動而無須從新構建 Docker 鏡像, 這爲應用開發和部署帶來極大的靈活性
對於應用所依賴的一些敏感數據, 如用戶名和密碼、令牌、密鑰等信息, k8s 提供了 Secret 對象爲其解耦, 既便利了應用的快速開發和交付, 又提供了必定程度上的安全保障

存儲編排

k8s 支持 Pod 對象按需自動掛載不一樣類型的存儲系統, 包括節點本地存儲、公有云服務商雲存儲, 以及網絡存儲系統(NFS, Ceph, GlusterFS 等)

2. 節點和組件

通常狀況下一個 k8s 集羣由多個工做節點(worker node)和一個集羣控制節點(master)以及一個集羣狀態存儲系統(etcd)組成

2.1. Master 節點

Master 是集羣的網關和中樞, 負責集羣的管理工做, 諸如爲用戶和客戶端暴露API, 跟蹤其餘服務器的健康情況、以最優方式調度工做負載, 以及編排其餘組件之間的通訊等任務, 它是用戶或客戶端與集羣之間的核心聯絡點
單個 Master 節點便可完成其全部的功能, 但出於冗餘及負載均衡等目的, 生產環境中一般須要部署多個 master 節點
Master 節點主要由 apiserver、controller-manager 和 scheduler 三個組件以及一個用於存儲集羣狀態的 etcd 存儲服務組成

2.2. Node 節點

Node 是 k8s 集羣的工做節點(Worker), 並接收來自 Master 的指令並根據指令完成響應操做, 如建立或銷燬 Pod 對象、調整網絡規則等操做
Master 節點主要由 kubelet、kube-proxy 和容器引擎(docker 是最爲常見的容器引擎) 組成

2.3. Master 組件

集羣網關(API Server)

k8s 集羣的網關接口, 負責解析客戶端的請求

集羣狀態存儲(etcd)

存放 k8s 持久化數據, 提供監聽(watch)機制, 用於監聽和推送變動
在 k8s 集羣系統中, etcd 中的鍵值發生變化時會通知到 API Server, 並由其經過 watchAPI 向客戶端輸出。基於 watch 機制 k8s 集羣的各組件實現了高效協同

調度器(Scheduler)

在用戶發出建立 Pod 請求時, Scheduler 根據各 Node 資源狀況, 以及容器所須要的資源作出調度決定這個 Pod 將在那個 Node 上建立

控制器管理器(ControllerManager)

檢查控制器是否處於健康狀態

2.4. Node 組件

kubelet

負責和 Master 節點進行通訊, 接收 Master 調度過來的任務, 檢查節點上的 Pod 是否處於健康狀態

容器引擎

負責運行容器, 目前最爲流行的容器引擎爲 Docker, k8s 目前支持 Rtk 和 Docker 兩種容器引擎

kube-proxy

根據 Service 資源對象生 iptables 或 ipvs 規則, 從而將用戶請求轉發到指定的 Pod 中

3. k8s 術語

3.1. Pod

k8s 並不直接調度容器, 而是使用一個抽象的資源對象來封裝一個或者多個容器, 這個抽象對象被稱爲 Pod, 它也是 k8s 最小的調度單元
同一 Pod 中的容器共享網絡名稱空間和存儲資源, 這些容器可經由本地迴環節口lo直接通訊, 但彼此之間又在 Mount、User 以及 PID 等名稱空間上保持隔離
儘管 Pod 中能夠包含多個容器, 可是做爲最小調度單元, 它應該儘量地保持小, 即一般只應該包含一個主容器, 以及其餘必要的輔助型容器(sidecar)

3.2. 資源標籤

標籤(Label)是將資源進行分類的標識符, 資源標籤其實就是一個鍵值型(key/values)數據
標籤是在指定對象上辨識性的屬性, 這些屬性僅對用戶存在特定的意義, 對 k8s 集羣來講意義並不大
標籤能夠在對象建立時附加在其上, 並可以在建立後的任意時間進行添加和修改。一個對象能夠擁有多個標籤, 一個標籤也能夠附加在多個對象上

3.3. 標籤選擇器

標籤選擇器(Selector)全稱爲Label Selector它是一種根據 Label 來過濾符合條件的資源對象的機制
例如, 將附有標籤role: backend的全部 Pod 對象挑選出來歸爲一組就是標籤選擇器的一種應用
用戶一般使用標籤對資源對象進行分類, 然後使用標籤選擇器挑選出它們, 對他們進行批量操做

3.4. Pod 控制器

一般狀況下用戶不會直接去部署和管理 Pod 對象, 而是要藉助於另外一類抽象控制器(Controller)對其進行管理
k8s 內置了大量的控制器用於管理 Pod 對象, 常見的控制器以下

ReplicationController   K8s 早期使用的控制器
ReplicaSet              副本集, 通常不直接使用此管理器而是使用 Deployment 管理器
Deployment              管理無狀態應用
StatefulSet             管理有狀態應用
Job                     運行做業
Cronjob                 運行週期性做業
DaemonSet               在每一個 Node 上都運行一個副本, 而不是在隨機節點上運行

3.5. 服務資源(service)

Service 是創建在一組 Pod 對象之上的資源抽象, 它經過標籤選擇器(Label Selector)選定一組 Pod 對象, 併爲這組 Pod 對象定義一個統一的固定訪問入口(一般是一個IP 地址), 若 k8s 集羣存在 DNS 附件, 它就會在 Service 建立時爲其自動配置一個DNS 名稱以便客戶端進行服務發現
到達 Service IP 的請求將被負載均衡至其後的各個 Pod 對象之上, 所以 Service 從本質上來說是一個四層代理服務

3.6. 存儲卷(volume)

存儲卷(Volume)是獨立於容器文件系統以外的存儲空間, 經常使用於擴展容器的存儲空間併爲它提供持久存儲能力
k8s 集羣上的存儲卷大致可分爲臨時卷、本地卷和網絡卷
臨時卷和本地卷都位於 Node 本地, 一旦 Pod 被調度至其餘 Node, 此種類型的存儲卷將沒法被訪問到, 所以臨時卷和本地卷一般用於數據緩存, 持久化的數據則須要放置於持久卷(persistent volume)之上

3.7. Name 和 Namespace

Name 是 k8s 集羣中資源對象的標識符, 它們的做用域一般是名稱空間(Namespace)在同一個名稱空間中, 同一類型資源、對象的名稱必須具備惟一性
名稱空間一般用於實現用戶或項目的資源隔離, 從而造成邏輯分組, 默認的名稱空間爲 default

3.8. Annotation(註解)

Annotation(註解)是一種附加在對象之上的鍵值類型的數據, 它擁比 Label 有更大的數據容量
Annotation 經常使用於將各類非標識型數據附加到對象上, 但它不能用於標識和選擇對象, 一般也不會被 k8s 直接使用, 其主要目的是方便用戶的閱讀及查找等

3.9. Ingress

k8s 將 Pod 對象和外部網絡環境進行了隔離, Pod 和 Service 等對象間的通訊都使用其內部專用地址進行, 如若須要開放某些 Pod 對象提供給外部用戶訪問, 則須要爲其請求流量打開一個通往 k8s 集羣內部的通道, 除了 service 以外, Ingress 也是這類通道的實現方式之一

3.10. Pause 容器

在每一個 Pod 中都運行着一個特殊的容器, 即 Pause 容器, 而其餘容器則爲用戶定義的容器, 這些用戶定義的容器共享 Pause 容器的網絡棧和 Volume 掛載卷, 所以它們之間的通訊和數據交換更爲高效; 在程序設計時咱們能夠充分利用這一特性將一組密切相關的服務進程放入同一個 Pod 中

4. 核心附件

k8s 經過一組被稱爲附件的組件提供更加豐富的功能, 附件一般由第三方提供, 爲 k8s 提供特定的功能, 且一般以 Pod 的方式運行在 k8s 集羣之上

4.1. k8s 常見附件

• CoreDNS 爲 k8s 集羣提供 DNS 服務
• Kubernetes Dashboard 爲 k8s 集羣提供 Web UI 界面
• Heapster k8s 集羣監控, 目前已逐步被 Prometheus 代替
• Ingress Controller k8s 網絡的另外一種實現方式, 爲 k8s 提供區別於 service 的網絡模型

5. k8s 網絡

k8s 網絡中主要有 4 種網絡通訊類型

5.1. 網絡通訊類型

同一 Pod 內的容器之間互相通訊

同一 Pod 之間的容器共享網絡名稱空間, 經過 lo 接口進行通訊

Pod 與 Pod 之間的通訊

Pod 網絡由 k8s 網絡插件實現, 執行插件都遵循 CNI 協議, 主流的網絡插件有 flannel、calico、canel 等, 這些網絡插件會爲全部的 Pod 對象配置至少一個特色的地址, 即 Pod IP, Pod IP 實際存在於網卡之上

Pod 和 Service 之間的通訊

Service 由 k8s 集羣指定, 默認使用的 10.96.0.0/12 網段, 通常狀況下每一組 Pod 都至少有一個 Service, 這一組 Pod 之間經過 Service 進行網絡通訊
Pod 經過標籤選擇器和 Service 建立關聯關係, Service 地址不存在於任何網絡接口之上, 它是由 kube-proxy 藉助 iptables 或者 ipvs 建立的 NET 規則

集羣外部流量和 Service 之間的通訊

k8s 對外暴露一個訪問地址, 當用戶訪問時先到達這個惟一訪問接口, 在經過 iptables 或者 ipvs 規則轉發到指定 Service, Service 在將其轉發的特定的 Pod 之上