Kubernetes架構(gòu)

Kubernetes是當今最流行的開源容器管理平臺匕坯，來自Google Borg的開源版本牌借，2014年推出卖词。Kubernetes源于希臘語了赌，意為舵手墨榄，K8S是一個簡稱，因為首尾字母中間正好有8個字母勿她。

基于容器技術(shù)袄秩，Kubernetes可以方便的進行集群應(yīng)用的部署、擴容逢并、縮容之剧、自愈機制、服務(wù)發(fā)現(xiàn)砍聊、負載均衡背稼、日志、監(jiān)控等功能玻蝌，大大減少日常運維的工作量蟹肘。

總體概覽

從兩個維度來看k8s词疼。

k8sStructure.jpg

Kubernets所有的操作都可以通過Kubernetes API來進行，通過API來操作Kubernetes中的對象帘腹，包括Pod贰盗、Service、Volume阳欲、Namespace等等舵盈。Kubernetes的整體結(jié)構(gòu)如下圖所示：

k8sStructure.png

Master Node

Master 是 Cluster 的大腦，它的主要職責是調(diào)度球化，即決定將應(yīng)用放在哪里運行秽晚。

Master節(jié)點上面主要由四個模塊組成：APIServer、scheduler筒愚、controller manager爆惧、etcd。

APIServer 負責對外提供RESTful的Kubernetes API服務(wù)锨能，它是系統(tǒng)管理指令的統(tǒng)一入口，任何對資源進行增刪改查的操作都要交給APIServer處理后再提交給etcd芍耘。

scheduler 負責調(diào)度pod到合適的Node上址遇。

controller manager 負責維護集群的狀態(tài)，比如故障檢測斋竞、自動擴展倔约、滾動更新等。

etcd 保存了整個集群的狀態(tài)坝初。etcd是一個高可用的鍵/值存儲系統(tǒng)浸剩，Kubernetes使用它來存儲各個資源的狀態(tài)，從而實現(xiàn)了Restful的API鳄袍。

Worker Node

Worker Node 的職責是運行容器應(yīng)用绢要。

Node 可以是一個物理機也可以是虛擬機，每個節(jié)點上都運行了可以運行 Pods 的服務(wù)拗小。通過Master節(jié)點來進行管理重罪。

每個Node節(jié)點主要由三個模塊組成：kubelet、kube-proxy哀九、runtime剿配。

runtime 容器運行環(huán)境，負責鏡像管理以及Pod和容器的真正運行（CRI - Container Runtime Interface）阅束，Kubernetes支持docker（默認）和rkt等容器呼胚。

kube-proxy 該模塊實現(xiàn)了Kubernetes中的服務(wù)發(fā)現(xiàn)和反向代理功能。

• 服務(wù)發(fā)現(xiàn): 維護service到endpoint的映射關(guān)系
• 反向代理: 將客戶端流量轉(zhuǎn)發(fā)到與service對應(yīng)的一組后端pod

kubelet Node節(jié)點上的agent, 負責維護容器的生命周期息裸，同時也負責Volume（CVI - Container Volume Interface）和網(wǎng)絡(luò)（CNI - Container Network Interface）的管理

Pod & Controllers

1. Pod

Pod 思維導(dǎo)圖

pod.jpg

Pod 是Kubernetes中可以創(chuàng)建和部署的最小單位蝇更。Pod包含了應(yīng)用容器沪编、存儲資源、唯一的網(wǎng)絡(luò)IP地址以及容器運行的參數(shù)簿寂。Pod內(nèi)部的容器共享的網(wǎng)絡(luò)漾抬、存儲資源。Docker是Pod中最常用的容器運行環(huán)境常遂，但仍允許用戶使用其他的容器環(huán)境纳令。

Pod使用有兩種方式：

• 一個容器 container 一個Pod(常用)
• 一個Pod中運行多個容器 containers (這些容器聯(lián)系必須 非常緊密，而且需要 直接共享資源克胳。 web-db模式不行)

1.1 基本操作

創(chuàng)建kubectl create -f xxx.yaml

查詢kubectl get pod yourPodName

kubectl describe pod yourPodName

刪除kubectl delete pod yourPodName

更新kubectl replace /path/to/yourNewYaml.yaml

1.2 Pod與容器

在Docker中平绩，容器是最小的處理單元，增刪改查的對象是容器漠另，容器是一種虛擬化技術(shù)捏雌，容器之間是隔離的，隔離是基于Linux Namespace實現(xiàn)的笆搓。而在Kubernetes中性湿，Pod包含一個或者多個相關(guān)的容器，Pod可以認為是容器的一種延伸擴展满败，一個Pod也是一個隔離體肤频，而Pod內(nèi)部包含的一組容器又是共享的（包括PID、Network算墨、IPC宵荒、UTS）。除此之外净嘀，Pod中的容器可以訪問共同的數(shù)據(jù)卷來實現(xiàn)文件系統(tǒng)的共享报咳。

1.3 鏡像

在kubernetes中，鏡像的下載策略為：

Always：每次都下載最新的鏡像

Never：只使用本地鏡像挖藏，從不下載

IfNotPresent：只有當本地沒有的時候才下載鏡像

Pod被分配到Node之后會根據(jù)鏡像下載策略進行鏡像下載暑刃，可以根據(jù)自身集群的特點來決定采用何種下載策略。無論何種策略膜眠，都要確保Node上有正確的鏡像可用稍走。

1.4 其他設(shè)置

通過yaml文件，可以在Pod中設(shè)置：

啟動命令柴底，如：spec-->containers-->command婿脸；

環(huán)境變量，如：spec-->containers-->env-->name/value柄驻；

端口橋接狐树，如：spec-->containers-->ports-->containerPort/protocol/hostIP/hostPort（使用hostPort時需要注意端口沖突的問題，不過Kubernetes在調(diào)度Pod的時候會檢查宿主機端口是否沖突鸿脓，比如當兩個Pod均要求綁定宿主機的80端口抑钟，Kubernetes將會將這兩個Pod分別調(diào)度到不同的機器上）;

Host網(wǎng)絡(luò)涯曲，一些特殊場景下，容器必須要以host方式進行網(wǎng)絡(luò)設(shè)置（如接收物理機網(wǎng)絡(luò)才能夠接收到的組播流）在塔，在Pod中也支持host網(wǎng)絡(luò)的設(shè)置幻件，如：spec-->hostNetwork=true；

數(shù)據(jù)持久化蛔溃，如：spec-->containers-->volumeMounts-->mountPath;

重啟策略绰沥，當Pod中的容器終止退出后，重啟容器的策略贺待。這里的所謂Pod的重啟徽曲，實際上的做法是容器的重建，之前容器中的數(shù)據(jù)將會丟失麸塞，如果需要持久化數(shù)據(jù)秃臣，那么需要使用數(shù)據(jù)卷進行持久化設(shè)置。Pod支持三種重啟策略：Always（默認策略哪工，當容器終止退出后奥此，總是重啟容器）、OnFailure（當容器終止且異常退出時雁比，重啟）得院、Never（從不重啟）；

2. Controller

Kubernetes 通常不會直接創(chuàng)建 Pod章贞，而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性非洲，比如有幾個副本鸭限，在什么樣的 Node 上運行等。

為了滿足不同的業(yè)務(wù)場景两踏，Kubernetes 提供了多種 Controller败京，包括 Deployment、ReplicaSet梦染、DaemonSet赡麦、StatefuleSet、Job 等帕识。

2.1 Deployment

Deployment 是新一代用于 Pod 管理的對象泛粹，與 Replication Controller 相比，它提供了更加完善的功能肮疗，使用起來更加簡單方便晶姊。(常用) . 實際運行方式：deployment -> ReplicaSet -> pod

2.2 StatefulSet

StatefulSet 有狀態(tài)負載提供正確的控制器支持。（Mysql伪货，Kafka等）

2.3 DaemonSet

DaemonSet 一個Node節(jié)點運行一個pod们衙。（monitor, glustered, ceph, logstash, kube-proxy）

2.4 Job

工作類容器钾怔，一次性任務(wù)。通過Job運行一個容器蒙挑，當其任務(wù)執(zhí)行完以后宗侦，就自動退出，集群也不再重新將其喚醒忆蚀。

2.5 CronJob

執(zhí)行定時任務(wù)的控制器矾利。

2.6 ReplicationController

k8s舊版，通過它實現(xiàn)了 Pod 的多副本管理(現(xiàn)在不建議用)

2.7 ReplicaSet

ReplicaSet 是新版 ReplicationController蜓谋， 支持集合式的 selector梦皮。(很少直接使用)

ReplicaSet 實現(xiàn)了 Pod 的多副本管理。使用 Deployment 時會自動創(chuàng)建 ReplicaSet桃焕，也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個副本剑肯，我們通常不需要直接使用 ReplicaSet。

2.8 Garbage Collection

Kubernetes進行垃圾回收管理的控制器观堂，Kubernetes的垃圾回收由kubelet進行管理让网，每分鐘會查詢清理一次容器，每五分鐘查詢清理一次鏡像师痕。在kubelet剛啟動時并不會立即進行GC溃睹，即第一次進行容器回收為kubelet啟動一分鐘后，第一次進行鏡像回收為kubelet啟動五分鐘后胰坟。（了解一下）

3. Service

Kubernetes Service 定義了外界訪問一組特定 Pod 的方式因篇。Service 有自己的 IP 和端口，Service 為 Pod 提供了負載均衡笔横。

Kubernetes 運行容器（Pod）與訪問容器（Pod）這兩項任務(wù)分別由 Controller 和 Service 執(zhí)行竞滓。

客戶端只需要訪問 Service 的 IP，Kubernetes 則負責建立和維護 Service 與 Pod 的映射關(guān)系吹缔。無論后端 Pod 如何變化商佑，對客戶端不會有任何影響，因為 Service 沒有變厢塘。

3.1 服務(wù)的類型（type）：

• ClusterIP （默認）集群內(nèi)部使用

• NodePort 外部可以通過 <NodeIP>:<NodePort> 訪問 Service茶没。

• Loadbalancer 云平臺提供（AWS, Azure)

• Ingress 第三方插件。是一種HTTP方式的路由轉(zhuǎn)發(fā)機制晚碾，由Ingress Controller和HTTP代理服務(wù)器組合而成抓半。Ingress Controller實時監(jiān)控Kubernetes API，實時更新HTTP代理服務(wù)器的轉(zhuǎn)發(fā)規(guī)則格嘁。HTTP代理服務(wù)器有GCE Load-Balancer琅关、HaProxy、Nginx等開源方案。

3.2 Service代理外部服務(wù)

Service不僅可以代理Pod涣易，還可以代理任意其他后端画机，比如運行在Kubernetes外部Mysql、Oracle等新症。這是通過定義兩個同名的service和endPoints來實現(xiàn)的步氏。

3.3 Service內(nèi)部負載均衡

當Service的Endpoints包含多個IP的時候，及服務(wù)代理存在多個后端徒爹，將進行請求的負載均衡荚醒。默認的負載均衡策略是輪訓(xùn)或者隨機（有kube-proxy的模式?jīng)Q定）。同時隆嗅，Service上通過設(shè)置Service-->spec-->sessionAffinity=ClientIP界阁，來實現(xiàn)基于源IP地址的會話保持。

3.4 服務(wù)發(fā)現(xiàn)：

service可以將pod ip封裝起來胖喳，即使pod發(fā)生重建泡躯，依然可以通過service來訪問pod提供的服務(wù)，service還解決了負載均衡的問題. 運行在每個node上的kube-proxy進程其實就是一個智能的軟件負載均衡器丽焊，它負責把service的請求轉(zhuǎn)發(fā)到后端的某個pod實例较剃。

kube-dns可以解決Service的發(fā)現(xiàn)問題：即把服務(wù)名解析為cluster IP。 k8s將Service的名稱當做域名注冊到kube-dns中技健，通過Service的名稱就可以訪問其提供的服務(wù)

3.5 servicede 自發(fā)性機制

Kubernetes中有一個很重要的服務(wù)自發(fā)現(xiàn)特性写穴。一旦一個service被創(chuàng)建，該service的service IP和service port等信息都可以被注入到pod中供它們使用雌贱。Kubernetes主要支持兩種service發(fā)現(xiàn) 機制：環(huán)境變量和DNS啊送。

環(huán)境變量方式

Kubernetes創(chuàng)建Pod時會自動添加所有可用的service環(huán)境變量到該Pod中，如有需要．這些環(huán)境變量就被注入Pod內(nèi)的容器里欣孤。需要注意的是馋没，環(huán)境變量的注入只發(fā)送在Pod創(chuàng)建時，且不會被自動更新导街。這個特點暗含了service和訪問該service的Pod的創(chuàng)建時間的先后順序，即任何想要訪問service的pod都需要在service已經(jīng)存在后創(chuàng)建纤子，否則與service相關(guān)的環(huán)境變量就無法注入該Pod的容器中搬瑰，這樣先創(chuàng)建的容器就無法發(fā)現(xiàn)后創(chuàng)建的service。

DNS方式

Kubernetes集群現(xiàn)在支持增加一個可選的組件——DNS服務(wù)器控硼。這個DNS服務(wù)器使用Kubernetes的watchAPI泽论，不間斷的監(jiān)測新的service的創(chuàng)建并為每個service新建一個DNS記錄。如果DNS在整個集群范圍內(nèi)都可用卡乾，那么所有的Pod都能夠自動解析service的域名翼悴。

3.6 service目前存在的不足

Kubernetes使用iptables和kube-proxy解析service的人口地址，在中小規(guī)模的集群中運行良好，但是當service的數(shù)量超過一定規(guī)模時鹦赎，仍然有一些小問題谍椅。首當其沖的便是service環(huán)境變量泛濫，以及service與使用service的pod兩者創(chuàng)建時間先后的制約關(guān)系古话。目前來看雏吭，很多使用者在使用Kubernetes時往往會開發(fā)一套自己的Router組件來替代service，以便更好地掌控和定制這部分功能陪踩。

4. Volumes

容器中的文件系統(tǒng)是臨時的杖们，一旦容器重新啟動，所有運行時對文件的操作都會丟失肩狂。Kubernetes使用Volumes來解決這個問題摘完。不同于Docker自身的Volume，Kubernetes提供了Volume的生命周期管理傻谁，另外還提供了多種存儲形式的支持孝治。在Pod的spec中指定volume的類型以及掛載的位置。

Kubernetes支持的volume的類型：awsElasticBlockStore栅螟、azureDisk荆秦、azureFile、cephfs力图、configMap步绸、csi、downwardAPI吃媒、emptyDir瓤介、fc、local赘那、nfs刑桑。

實際使用中，存儲選擇優(yōu)先順序：

1. 云平臺提供的存儲募舟。如：AWS EBS, Azure Disk, Azure File祠斧，OpenStack Cinder
2. Block Device(SAN)。如：FC(Fibre Channel), RBD(Ceph Block Device), iSCSI, VsphereVolume
3. File Storage拱礁。如：glusterfs, cephfs, nfs
4. HostPath琢锋。 單機版用法

Add-ons

• kube-dns 負責為整個集群提供DNS服務(wù)
• Ingress Controller 為服務(wù)提供外網(wǎng)入口
• Heapster 提供資源監(jiān)控
• Dashboard 提供GUI
• Federation 提供跨可用區(qū)的集群
• Fluentd-elasticsearch 提供集群日志采集、存儲與查詢