Kubernetes架構(gòu)

Kubernets核心組件

• API Server
• Controller Manager
• Scheduler
• Kubelet
• Kube-Proxy
• Etcd

Kubernetes API Server原理解析

總體來看，Kubernetes API Server的核心功能是提供Kubernetes各類資源對象（如Pod畴博、RC冀续、Service等）的增、刪弥臼、改、查及Watch等HTTP Rest接口，成為集群內(nèi)各個(gè)功能模塊之間數(shù)據(jù)交互和通信的中心樞紐胰苏，是整個(gè)系統(tǒng)的數(shù)據(jù)總線和數(shù)據(jù)中心。除此之外醇疼，它還有以下一些功能特性硕并。
（1）是集群管理的API入口。
（2）是資源配額控制的入口秧荆。
（3）提供了完備的集群安全機(jī)制倔毙。

API Server架構(gòu)

Controller Manager原理解析

Controller Manager內(nèi)部包含ReplicationController、Node Controller乙濒、ResourceQuotaController陕赃、Namespace Controller、ServiceAccountController颁股、Token Controller么库、Service Controller及Endpoint Controller這8種Controller，每種Controller都負(fù)責(zé)一種特定資源的控制流程甘有，而Controller Manager正是這些Controller的核心管理者诉儒。

Controller Manager架構(gòu)圖如下

Scheduler原理解析

Kubernetes Scheduler在整個(gè)系統(tǒng)中承擔(dān)了“承上啟下”的重要功能，“承上”是指它負(fù)責(zé)接收Controller Manager創(chuàng)建的新Pod亏掀，為其安排一個(gè)落腳的“家”——目標(biāo)Node忱反；“啟下”是指安置工作完成后，目標(biāo)Node上的kubelet服務(wù)進(jìn)程接管后繼工作滤愕，負(fù)責(zé)Pod生命周期中的“下半生”温算。
具體來說，Kubernetes Scheduler的作用是將待調(diào)度的Pod（API新創(chuàng)建的Pod间影、Controller Manager為補(bǔ)足副本而創(chuàng)建的Pod等）按照特定的調(diào)度算法和調(diào)度策略綁定（Binding）到集群中某個(gè)合適的Node上米者，并將綁定信息寫入etcd中。在整個(gè)調(diào)度過程中涉及三個(gè)對象，分別是待調(diào)度Pod列表蔓搞、可用Node列表胰丁，以及調(diào)度算法和策略。簡單地說喂分，就是通過調(diào)度算法調(diào)度為待調(diào)度Pod列表中的每個(gè)Pod從Node列表中選擇一個(gè)最適合的Node锦庸。
隨后，目標(biāo)節(jié)點(diǎn)上的kubelet通過API Server監(jiān)聽到KubernetesScheduler產(chǎn)生的Pod綁定事件蒲祈，然后獲取對應(yīng)的Pod清單甘萧，下載Image鏡像并啟動(dòng)容器。
完整的流程圖如下：

Kubelet運(yùn)行機(jī)制解析

在Kubernetes集群中梆掸，在每個(gè)Node（又稱Minion）上都會(huì)啟動(dòng)一個(gè)kubelet服務(wù)進(jìn)程扬卷。該進(jìn)程用于處理Master下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理Pod及Pod中的容器酸钦。每個(gè)kubelet進(jìn)程都會(huì)在APIServer上注冊節(jié)點(diǎn)自身的信息怪得，定期向Master匯報(bào)節(jié)點(diǎn)資源的使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點(diǎn)資源卑硫。

Kube-proxy運(yùn)行機(jī)制解析

起初徒恋，kube-proxy進(jìn)程是一個(gè)真實(shí)的TCP/UDP代理，類似HAProxy欢伏，負(fù)責(zé)從Service到Pod的訪問流量的轉(zhuǎn)發(fā)入挣，這種模式被稱為userspace（用戶空間代理）模式。當(dāng)某個(gè)Pod以Cluster IP方式訪問某個(gè)Service的時(shí)候硝拧，這個(gè)流量會(huì)被Pod所在本機(jī)的iptables轉(zhuǎn)發(fā)到本機(jī)的kube-proxy進(jìn)程径筏，然后由kube-proxy建立起到后端Pod的TCP/UDP連接，隨后將請求轉(zhuǎn)發(fā)到某個(gè)后端Pod上障陶，并在這個(gè)過程中實(shí)現(xiàn)負(fù)載均衡功能匠璧。

Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認(rèn)模式咸这。iptables模式下的kube-proxy不再起到Proxy的作用夷恍，其核心功能：通過API Server的Watch接口實(shí)時(shí)跟蹤Service與Endpoint的變更信息，并更新對應(yīng)的iptables規(guī)則媳维，Client的請求流量則通過iptables的NAT機(jī)制“直接路由”到目標(biāo)Pod酿雪。

Kubernetes從1.8版本開始引入第3代的IPVS（IP Virtual Server）模式。IPVS在Kubernetes 1.11中升級為GA穩(wěn)定版侄刽。iptables與IPVS雖然都是基于Netfilter實(shí)現(xiàn)的指黎，但因?yàn)槎ㄎ徊煌哂兄举|(zhì)的差別：iptables是為防火墻而設(shè)計(jì)的州丹；IPVS則專門用于高性能負(fù)載均衡醋安，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（Hash表）杂彭，允許幾乎無限的規(guī)模擴(kuò)張，因此被kube-proxy采納為第三代模式吓揪。

參考資料

Kubernetes權(quán)威指南：從Docker到Kubernetes實(shí)踐全接觸（第4版）龔正等