基本工作過程
Kubernetes 的核心工作過程:
- 資源對象:Node、Pod、Service、Replication Controller 等都可以看作一種資源對象
- 操作:通過使用 kubectl 工具,執行增刪改查
- 存儲:對象的目標狀態(預設狀態),保存在 etcd 中持久化儲存;
- 自動控制:跟蹤、對比 etcd 中存儲的目標狀態與資源的當前狀態,對差異資源糾偏,自動控制集群狀態。
Kubernetes 實際是:高度自動化的資源控制系統,將其管理的一切抽象為資源對象,大到服務器 Node 節點,小到服務實例 Pod。
Kubernetes 的資源控制是一種聲明+引擎的理念:
- 聲明:對某種資源,聲明他的目標狀態
- 自動:Kubernetes 自動化資源控制系統,會一直努力將該資源對象維持在目標狀態。
架構(物理+邏輯)
Kubernetes 集群,是主從架構:
- Master:管理節點,集群的控制和調度
- Node:工作節點,執行具體的業務容器
下述幾個組件,都是獨立的進程,每個進程都是 Go 語言編寫,實際部署 Kubernetes 集群,就是部署這些程序。
- Master節點:
- kube-apiserver
- kube-controller-manager
- kube-scheduler
- Node節點:
- kubelet
- kube-proxy
具體,2 種角色的節點,需要運行的進程和職責不同,詳細描述如下。
Master 管理節點:管理整個 Kubernetes 集群,接收外部命令,維護集群狀態。
- apiserver: Kubernetes API Server
- 集群控制的入口
- 資源的增刪改查,持久化存儲到 etcd
- kubectl 直接與 API Server 交互,默認端口 6443。
- etcd: 一個高可用的 key-value 存儲系統
- 作用:存儲資源的狀態
- 支持 Restful 的API。
- 默認監聽 2379 和 2380 端口(2379提供服務,2380用於集群節點通信)(疑問:集群節點,是說 etcd 的集群? Master 集群?)
- scheduler: 負責將 pod 資源調度到合適的 node 上。
- 調度算法:根據 node 節點的性能、負載、數據位置等,進行調度。
- 默認監聽 10251 端口。
- controller-manager: 所有資源的自動化控制中心
- 每個資源,都對應有一個控制器(疑問:作用是什麼?)
- controller manager 管理這些控制器
- controller manager 是自動化的循環控制器
- Kubernetes 的核心控制守護進程,默認監聽10252端口。(疑問:為什麼有監聽段口感?)
補充說明:
scheduler和controller-manager都是通過apiserver從etcd中獲取各種資源的狀態,進行相應的調度和控制操作。
Node 節點:Master 節點,將任務調度到 Node 節點,以 docker 方式運行;當 Node 節點宕機時,Master 會自動將 Node 上的任務調度到其他 Node 上。
- kubelet: 本節點Pod的生命週期管理,定期向Master上報本節點及Pod的基本信息
- Kubelet是在每個Node節點上運行agent
- 負責維護和管理所有容器:從 apiserver 接收 Pod 的創建請求,啟動和停止Pod
- Kubelet不會管理不是由Kubernetes創建的容器
- 定期向Master上報信息,如操作系統、Docker版本、CPU、內存、pod 運行狀態等信息
- kube-proxy:集群中 Service 的通信以及負載均衡
- 功能:服務發現、反向代理。
- 反向代理:支持TCP和UDP連接轉發,默認基於Round Robin算法將客戶端流量轉發到與service對應的一組後端pod。
- 服務發現:使用 etcd 的 watch 機制,監控集群中service和endpoint對象數據的動態變化,並且維護一個service到endpoint的映射關係。(本質是:路由關係)
- 實現方式:存在兩種實現方式,userspace 和 iptables。
- userspace:在用戶空間,通過kuber-proxy實現負載均衡的代理服務,是最初的實現方案,較穩定、效率不高;
- iptables:在內核空間,是純採用iptables來實現LB,是Kubernetes目前默認的方式;
- runtime:一般使用 docker 容器,也支持其他的容器。
集群的高可用
Kubernetes 集群,在生產環境,必須實現高可用:
- 實現Master節點及其核心組件的高可用;
- 如果Master節點出現問題的話,那整個集群就失去了控制;
具體的 HA 示意圖:
上述方式可以用作 HA,但仍未成熟,據瞭解,未來會更新升級 HA 的功能.
具體工作原理:
- etcd 集群:部署了3個Master節點,每個Master節點的etcd組成集群
- 入口集群:3個Master節點上的APIServer的前面放一個負載均衡器,工作節點和客戶端通過這個負載均衡和APIServer進行通信
- pod-master保證僅是主master可用,scheduler、controller-manager 在集群中多個實例只有一個工作,其他為備用
轉自:http://ningg.top/kubernetes-series-03-architecture/
閱讀更多 咔咔侃技術 的文章