一、Kubernetes介紹

1、什么是Kubernetes？

用于自動部署、擴展和管理“容器化( containerized) 應(yīng)用程序”的開源系統(tǒng)

可以理解成K8S是負(fù)責(zé)自動化運維管理多個容器化程序(比如Docker)的集群，是–個生態(tài)極其豐富的容器編排框架工具

由來：

k8S由google的Borg系統(tǒng)(博格系統(tǒng)，google內(nèi)部使用的大規(guī)模容器編排工具)作為原型，后經(jīng)G0語言延用Borg的思路重寫并捐獻給CNCF基金會開源

含義：

詞根源于希臘語的舵手、飛行員

官網(wǎng):

https://kubernetes.io

GitHub: https://github.com/kubernetes/kubernetes

2、為什么要用K8S?

   試想下傳統(tǒng)的后端部署辦法:把程序包(包括可執(zhí)行二進制文件、配置文件等)放到服務(wù)器上，接著運行啟動腳本把程序跑起來，同時啟動守護腳本定期檢查程序運行狀態(tài)、必要的話重新拉起程序

設(shè)想一下，如果服務(wù)的請求量上來，已部署的服務(wù)響應(yīng)不過來怎么辦?傳統(tǒng)的做法往往是，如果請求量、內(nèi)存、CPU超過閾值做了告警，運維人員馬上再加幾臺服務(wù)器，部署好服務(wù)之后，接入負(fù)載均衡來分擔(dān)已有服務(wù)的壓力

這樣問題就出現(xiàn)了:從監(jiān)控告警到部署服務(wù)，中間需要人力介入! 那么，有沒有辦法自動完成服務(wù)的部署、更新、卸載和擴容、縮容呢?

而這就是K8S要做的事情: 自動化運維管理容器(Docker) 程序。K8s的目標(biāo)是讓部署容器化應(yīng)用簡單高效

K8S解決了裸跑Docker的若干痛點:

●單機使用，無法有效集群

●隨著容器數(shù)量的.上升，管理成本攀升

●沒有有效的容災(zāi)、自愈機制

●沒有預(yù)設(shè)編排模板，無法實現(xiàn)快速、大規(guī)模容器調(diào)度

●沒有統(tǒng)一 的配置管理中心工具

●沒有容器生命周期的管理工具

●沒有圖形化運維管理工具

k8s提供了容器編排，資源調(diào)度，彈性伸縮，部署管理，服務(wù)發(fā)現(xiàn)等一系列功能

3、k8s的特性

●彈性伸縮

使用命令、UI或者基于CPU使用情況自動快速擴容和縮容應(yīng)用程序?qū)嵗ＷC應(yīng)用業(yè)務(wù)高峰并發(fā)時的高可用性:業(yè)務(wù)低峰時回收資源，以最小成本運行服務(wù)

●自我修復(fù)

在節(jié)點故障時重新啟動失敗的容器，替換和重新部署，保證預(yù)期的副本數(shù)量:殺死健康檢查失敗的容器，并且在未準(zhǔn)備好之前不會處理客戶端請求,確保線上服務(wù)不中斷

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

K8s為多個容器提供一-個統(tǒng)一訪問入口(內(nèi)部IP地址和一個DNS名稱)，并且負(fù)載均衡關(guān)聯(lián)的所有容器，使得用戶無需考慮容器IP問題

●自動發(fā)布(默認(rèn)滾動發(fā)布模式)和回滾

K8S采用滾動更新策略更新應(yīng)用，一次更新一個Pod，而不是同時刪除所有Pod，如果更新過程中出現(xiàn)問題，將回滾更改，確保升級不受影響業(yè)務(wù)

●集中化配置管理和密鑰管理

管理機密數(shù)據(jù)和應(yīng)用程序配置，而不需要把敏感數(shù)據(jù)暴露在鏡像里，提高敏感數(shù)據(jù)安全性。并可以將一些常用的配置存儲在K8S中，方便應(yīng)用程序使用

●存儲編排，支持外掛存儲并對外掛存儲資源進行編排

掛載外部存儲系統(tǒng)，無論是來自本地存儲，公有云( 如AWS)，還是網(wǎng)絡(luò)存儲( 如NFS、Glusterfs、Ceph) 都作為集群資源的一部分使用， 極大提高存儲使用靈活性

●任務(wù)批處理運行

提供一次性任務(wù)，定時任務(wù):滿足批量數(shù)據(jù)處理和分析的場景

二、k8s集群架構(gòu)與組件

K8s是屬于主從設(shè)備模型(Master-Slave 架構(gòu))，即有Master 節(jié)點負(fù)責(zé)集群的調(diào)度、管理和運維，Slave 節(jié)點是集群中的運算工作負(fù)載節(jié)點

在K8S中，主節(jié)點一般被稱為Master 節(jié)點，而從節(jié)點則被稱為Worker Node 節(jié)點，每個Node 都會被Master 分配一些工作負(fù)載

Master組件可以在群集中的任何計算機上運行，但建議Master節(jié)點占據(jù)一個獨立的服務(wù)器

因為Master是整個集群的大腦，如果Master所在節(jié)點宕機或不可用，那么所有的控制命令都將失效

除了Master， 在K8s集群中的其他機器被稱為Worker Node節(jié)點，當(dāng)某個Node宕機時，其上的工作負(fù)載會被Master自動轉(zhuǎn)移到其他節(jié)點上去

1、Master組件

Master：集群控制管理節(jié)點，所有的命令都經(jīng)由master處理

●Kube-apiserver

用于暴露Kubernetes API，任何資源請求或調(diào)用操作都是通過kube-apiserver提供的接口進行。以HTTP Restful API

提供接口服務(wù)，所有對象資源的增刪改查和監(jiān)聽操作都交給API Server處理后再提交給Etcd存儲

可以理解成API Server 是K8S的請求入口服務(wù)。API Server 負(fù)責(zé)接收K8S所有請求(來自UI界面或者CLI命令行工具)，

然后根據(jù)用戶的具體請求，去通知其他組件干活?？梢哉fAPI Server 是K8S集群架構(gòu)的大腦

●Kube-controller-manager

運行管理控制器，是K8S 集群中處理常規(guī)任務(wù)的后臺線程，是K8S集群里所有資源對象的自動化控制中心。

在K8S集群中，一個資源對應(yīng)一個控制器，而Controller manager就是負(fù)責(zé)管理這些控制器的

由一系列控制器組成，通過APIServer監(jiān)控整個集群的狀態(tài)，并確保集群處于預(yù)期的工作狀態(tài)，比如當(dāng)某個Node意外宕機時，Controller Manager會及時發(fā)現(xiàn)并執(zhí)行自動化修復(fù)流程，確保集群始終處于預(yù)期的工作狀態(tài)

這些控制器主要包括:

●Node Controller(節(jié)點控制器):負(fù)責(zé)在節(jié)點出現(xiàn)故障時發(fā)現(xiàn)和響應(yīng)

●Replication Controller (副本控制器) :負(fù)責(zé)保證集群中一個RC (資源對 象Replication Controller) 所關(guān)聯(lián)的Pod

副本數(shù)始終保持預(yù)設(shè)值。可以理解成確保集群中有且僅有N個Pod實例，N是RC中定義的Pod副本數(shù)量

●Endpoints Controller (端點控制器) :填充端點對象 (即連接Services 和Pods) ，負(fù)責(zé)監(jiān)聽 Service 和對應(yīng)的Pod副本的變化

可以理解端點是一個服務(wù)暴露出來的訪問點，如果需要訪問一個服務(wù)，則必須知道它的endpoint

●Service Account & Token Controllers ( 服務(wù)帳戶和令牌控制器) :為新的命名空間創(chuàng)建默認(rèn)帳戶和API訪問令牌

●ResourceQuota Controller(資源配額控制器):確保指定的資源對象在任何時候都不會超量占用系統(tǒng)物理資源

●Namespace Controller ( 命名空間控制器) :管理namespace的生命周期

●Service Controller (服務(wù)控制器) :屬于K8S集群與外部的云平臺之間的一個接口控制器

●Kube-scheduler

是負(fù)責(zé)資源調(diào)度的進程，根據(jù)調(diào)度算法為新創(chuàng)建的Pod選擇-一個合適的Node節(jié)點

可以理解成K8S所有Node節(jié)點的調(diào)度器。當(dāng)用戶要部署服務(wù)時，Scheduler 會根據(jù)調(diào)度算法選擇最合適的Node 節(jié)點來部署Pod

●預(yù)算策略(predicate)

●優(yōu)選策略( priorities)

2、配置存儲中心——etcd

K8S的存儲服務(wù)

etcd 是分布式鍵值存儲系統(tǒng)，存儲了K8S 的關(guān)鍵配置和用戶配置，K8S中僅API Server 才具備讀寫權(quán)限，其他組件必須通過 API Server的接口才能讀寫數(shù)據(jù)。

3、Worker Node 組件

3.1 Node節(jié)點的工作流程：
Node節(jié)點可動態(tài)增加到kubernetes集群中，前提是這個節(jié)點已經(jīng)正確安裝、配置和啟動了上述的關(guān)鍵進程，默認(rèn)情況下，kubelet會向Master注冊自己，這也kubernetes推薦的Node管理方式。

一旦Node被納入集群管理范圍，kubelet會定時向Master匯報自身的情況，以及之前有哪些Pod在運行等，這樣Master可以獲知每個Node的資源使用情況，并實現(xiàn)高效均衡的資源調(diào)度策略。

如果Node沒有按時上報信息，則會被Master判斷為失聯(lián)，Node狀態(tài)會被標(biāo)記為Not Ready，隨后Master會觸發(fā)工作負(fù)載轉(zhuǎn)移流程。

●Kubelet
Node節(jié)點的監(jiān)視器，以及與Master節(jié)點的通訊器。Kubelet 是Master節(jié)點安插在Node節(jié)點上的“眼線”，它會定時向API Server匯報自己

Node節(jié)點上運行的服務(wù)的狀態(tài)，并接受來自Master節(jié)點的指示采取調(diào)整措施

從Master節(jié)點獲取自己節(jié)點上Pod的期望狀態(tài)(比如運行什么容器、運行的副本數(shù)量、網(wǎng)絡(luò)或者存儲如何配置等)，

直接跟容器引擎交互實現(xiàn)容器的生命周期管理，如果自己節(jié)點上Pod的狀態(tài)與期望狀態(tài)不一致，則調(diào)用對應(yīng)的容器平臺接口(即docker的接口)達到這個狀態(tài)

管理鏡像和容器的清理工作，保證節(jié)點上鏡像不會占滿磁盤空間，退出的容器不會占用太多資源

●Kube-Proxy
在每個Node節(jié)點上實現(xiàn)pod網(wǎng)絡(luò)代理，是Kubernetes Service 資源的載體，負(fù)責(zé)維護網(wǎng)絡(luò)規(guī)則和四層負(fù)載均衡工作。負(fù)責(zé)寫入規(guī)則至iptables、ipvs實現(xiàn)服務(wù)映射訪問的

Kube-Proxy本身不是直接給Pod 提供網(wǎng)絡(luò)，Pod的網(wǎng)絡(luò)是由Kubelet 提供的，Kube-Proxy 實際上維護的是虛擬的Pod集群網(wǎng)絡(luò)

Kube-apiserver通過監(jiān)控Kube-Proxy 進行對Kubernetes Service 的更新和端點的維護

在K8S集群中微服務(wù)的負(fù)載均衡是由Kube-proxy實現(xiàn)的。Kube-proxy是K8S集群內(nèi)部的負(fù)載均衡器。它是一個分布式代理服務(wù)器，在K8S的每個節(jié)點上都會運行一個Kube-proxy 組件

●docker engine（docker或rocket）
容器引擎，運行容器，負(fù)責(zé)本機的容器創(chuàng)建和管理工作

三、k8s核心概念

Kubernetes包含多種類型的資源對象: Pod、 Label、 Service、 Replication Controller 等

所有的資源對象都可以通過Kubernetes 提供的 kubectl工具進行增、刪、改、查等操作，并將其保存在etcd中持久化存儲

Kubernets其實是一個高度自動化的資源控制系統(tǒng)，通過跟蹤對比etcd存儲里保存的資源期望狀態(tài)與當(dāng)前環(huán)境中的實際資源狀態(tài)的差異，來實現(xiàn)自動控制和自動糾錯等高級功能

●Pod

Pod是Kubernetes 創(chuàng)建或部署的最小/最簡單的基本單位，一個Pod 代表集群上正在運行的一個進程

可以把Pod理解成豌豆莢，而同一Pod內(nèi)的每個容器是一顆顆豌豆

一個Pod由一個或多個容器組成，Pod中容器共享網(wǎng)絡(luò)、存儲和計算資源，在同一臺Docker主機上運行

一個Pod里可以運行多個容器，又叫邊車模式(sideCara) 模式。而在生產(chǎn)環(huán)境中一般都是單個容器或者具有強關(guān)聯(lián)互補的多個容器組成一個Pod

同一個Pod之間的容器可以通過localhost 互相訪問，并且可以掛載Pod內(nèi)所有的數(shù)據(jù)卷;但是不同的Pod之間的容器不能用localhost訪問，也不能掛載其他Pod的數(shù)據(jù)卷

●Pod 控制器(五大控制器)

Pod控制器是Pod啟動的一種模版，用來保證在K8S里啟動的Pod 應(yīng)始終按照用戶的預(yù)期運行(副本數(shù)、生命周期、健康狀態(tài)檢查等)

K8S內(nèi)提供了眾多的Pod 控制器，常用的有以下幾種:

●Deployment：無狀態(tài)應(yīng)用部署。Deployment 的作用是管理和控制Pod和Replicaset， 管控它們運行在用戶期望的狀態(tài)中

●Replicaset: 確保預(yù)期的Pod副本數(shù)量。Replicaset 的作用就是管理和控制Pod，管控他們好好干活。 但是，Replicaset 受控于Deployment

可以理解成Deployment 就是總包工頭，主要負(fù)責(zé)監(jiān)督底下的工人Pod干活，確保每時每刻有用戶要求數(shù)量的Pod在工作。

如果一旦發(fā)現(xiàn)某個工人Pod不行了，就趕緊新拉一個Pod過來替換它。而ReplicaSet 就是總包工頭手下的小包工頭

從K8S使用者角度來看，用戶會直接操作Deployment 部署服務(wù)，而當(dāng)Deployment 被部署的時候，K8S 會自動生成要求的ReplicaSet 和Pod。

用戶只需要關(guān)心Deployment 而不操心ReplicaSet

資源對象Replication Controller是ReplicaSet 的前身，官方推薦用Deployment 取代Replication Controller來部署服務(wù)

●Daemonset: 確保所有節(jié)點運行同一類Pod，保證每個節(jié)點上都有一個此類Pod運行，通常用于實現(xiàn)系統(tǒng)級后臺任務(wù)

●Statefulset:有狀態(tài)應(yīng)用部署

●Job: 一次性任務(wù)。根據(jù)用戶的設(shè)置，Job管理的Pod把任務(wù)成功完成就自動退出了

●Cronjob: 周期性計劃性任務(wù)

●Label

標(biāo)簽，是K8S特色的管理方式，便于分類管理資源對象

Label可以附加到各種資源對象上，例如Node、Pod、Service、 RC等，用于關(guān)聯(lián)對象、查詢和篩選。

一個Label是一個key-value 的鍵值對，其中key 與value 由用戶自己指定

一個資源對象可以定義任意數(shù)量的Label，同一個Label也可以被添加到任意數(shù)量的資源對象中，也可以在對象創(chuàng)建后動態(tài)添加或者刪除

可以通過給指定的資源對象捆綁一個或多個不同的Label，來實現(xiàn)多維度的資源分組管理功能

與Label 類似的，還有Annotation (注釋)

區(qū)別在于有效的標(biāo)簽值必須為63個字符或更少，并且必須為空或以字母數(shù)字字符([a-z0-9A-Z]) 開頭和結(jié)尾，中間可以包含橫杠(-)、下劃線(_)、點(.)和字母或數(shù)字。注釋值則沒有字符長度限制

●Label選擇器(Label selector )

給某個資源對象定義一個Label， 就相當(dāng)于給它打了一個標(biāo)簽;隨后可以通過標(biāo)簽選擇器(Label selector) 查詢和篩選擁有某些Label的資源對象

標(biāo)簽選擇器目前有兩種:基于等值關(guān)系(等于、不等于)和基于集合關(guān)系(屬于、不屬于、存在)

●Service

在K8S的集群里，雖然每個Pod會被分配一個單獨的IP地址，但由于Pod是有生命周期的(它們可以被創(chuàng)建，而且銷毀之后不會再啟動)，隨時可能會因為業(yè)務(wù)的變更，導(dǎo)致這個IP地址也會隨著Pod 的銷毀而消失，Service就是用來解決這個問題的核心概念。

K8S中的Service 并不是我們常說的“服務(wù)”的含義，而更像是網(wǎng)關(guān)層，可以看作一組提供相同服務(wù)的Pod的對外訪問接口、流量均衡器，Service作用于哪些Pod 是通過標(biāo)簽選擇器來定義的。

在K8S集群中，Service 可以看作一組提供相同服務(wù)的Pod 的對外訪問接口?？蛻舳诵枰L問的服務(wù)就是Service 對象。

每個Service都有一個固定的虛擬ip (這個ip也被稱為Cluster IP) ，自動并且動態(tài)地綁定后端的Pod, 所有的網(wǎng)絡(luò)請求直接訪問Service 的虛擬ip，Service會自動向后端做轉(zhuǎn)發(fā)

Service除了提供穩(wěn)定的對外訪問方式之外，還能起到負(fù)載均衡(Load Balance) 的功能，自動把請求流量分布到后端所有的服務(wù)上，service可以做到對客戶透明地進行水平擴展(scale)

而實現(xiàn)service 這一功能的關(guān)鍵， 就是kube-proxy。 kube -proxy運行在每個節(jié)點上，監(jiān)聽API Server中服務(wù)對象的變化，

可通過以下三種流量調(diào)度模式: userspace (廢棄)、iptables (瀕臨廢棄)、ipvs (推薦，性能最好)來實現(xiàn)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)。

Service是K8S服務(wù)的核心，屏蔽了服務(wù)細(xì)節(jié)，統(tǒng)一對外暴露服務(wù)接口， 真正做到了“微服務(wù)”。比如我們的一個服務(wù)A，部署了3

個副本，也就是3個Pod;對于用戶來說，只需要關(guān)注一個Service 的入口就可以，而不需要操心究競應(yīng)該請求哪一個Pod。

優(yōu)勢非常明顯:一方面外部用戶不需要感知因為Pod. 上服務(wù)的意外崩潰、 K8S 重新拉起Pod 而造成的IP變更，外部用戶也不需要感知因升級、變更服務(wù)帶來的Pod替換而造成的IP變化。

●Ingress

Service主要負(fù)責(zé)K8S 集群內(nèi)部的網(wǎng)絡(luò)拓?fù)?，那么集群外部怎么訪問集群內(nèi)部呢?這個時候就需要Ingress了。

Ingress是整個K8S集群的接入層，負(fù)責(zé)集群內(nèi)外通訊

Ingress是K8S 集群里工作在OSI網(wǎng)絡(luò)參考模型下，第7層的應(yīng)用，對外暴露的接口，典型的訪問方式是http/https

Service只能進行第四層的流量調(diào)度，表現(xiàn)形式是ip+port。Ingress則可以調(diào)度不同業(yè)務(wù)域、不同URL訪問路徑的業(yè)務(wù)流量。

比如:客戶端請求http://www.ly.com:port —> Ingress —> Service —> Pod

●Name

由于K8S內(nèi)部，使用“資源”來定義每一種邏輯概念(功能)，所以每種“資源”，都應(yīng)該有自己的“名稱”

“資源”有api版本(apiversion) 、類別(kind)、元數(shù)據(jù)(metadata) 、定義清單(spec)、狀態(tài)(status) 等配置信息

“名稱”通常定義在“資源”的“元數(shù)據(jù)”信息里。在同一個namespace 空間中必須是唯一的

●Namespace

隨著項目增多、人員增加、集群規(guī)模的擴大，需要一種能夠邏輯上隔離K8S 內(nèi)各種“資源"的方法，這就是Namespace

Namespace是為了把一個K8S集群劃分為若千個資源不可共享的虛擬集群組而誕生的

不同Namespace 內(nèi)的“資源”名稱可以相同，相同Namespace 內(nèi)的同種“資源”， “名稱”不能相同

合理的使用K8S的Namespace，可以使得集群管理員能夠更好的對交付到K8S里的服務(wù)進行分類管理和瀏覽

K8S里默認(rèn)存在的Namespace 有: default、 kube-system、 kube-public 等

查詢K8S 里特定“資源”要帶上相應(yīng)的Namespace

k8s的架構(gòu)以及工作流程

master節(jié)點：API server shceduler controller-manager

worker node 節(jié)點：kubelet kube-proxy docker engine

工作流程或者各個組件的功能：

1、用戶通過客戶端發(fā)送請求給API server,API Server 接收請求創(chuàng)建一批Pod，會存儲pod數(shù)據(jù)到etcd

2、Controller-manager 通過API Server 到etcd中讀取按照預(yù)設(shè)的模板去創(chuàng)建Pod,Controller-manager 又會通過API Server讓Scheduler為新創(chuàng)建的Pod 根據(jù)預(yù)算策略以及優(yōu)選策略，選擇最適合的Node 節(jié)點把pod調(diào)度過來

比如運行這個Pod需要2C 4G 的資源，Scheduler 會通過預(yù)算策略在所有Node’節(jié)點中挑選最優(yōu)的。Node 節(jié)點中還剩多少資源是通過匯報給API Server 存儲在etcd 里，API Server 會調(diào)用一個方法找到etcd里所有node節(jié)點的剩余資源，再對比pod所需要的資源，在所有node節(jié)點中查找哪些node節(jié)點符合要求
如果都符合，預(yù)算策略就交給優(yōu)選策略處理，優(yōu)選策略再通過CPU 的負(fù)載、內(nèi)存的剩余量等因素選擇最合適的Node節(jié)點，并把Pod調(diào)度到這個Node’節(jié)點上運行

3、scheduler通過Api server來讓Kubelet根據(jù)調(diào)度結(jié)果執(zhí)行Pod創(chuàng)建操作，并且對node節(jié)點進行監(jiān)視，會定時向api server匯報自己node節(jié)點運行的服務(wù)狀態(tài),并且存儲到etcd中

在這期間，Controller Manager同時會根據(jù)K8S的mainfiles文件執(zhí)行RC Pod的數(shù)量來保證指定的Pod副本數(shù)

4、在每個node上都會有一個kube-proxy，來實現(xiàn)pod的網(wǎng)絡(luò)代理，它是Kubernetes Service 資源的載體。在任何一個節(jié)點上訪問一個service的虛擬ip，都可以訪問到pod，提供cluster ip的訪問入口
所有Node上運行的Proxy進程通過APIServer查詢并監(jiān)聽service對象與其對應(yīng)的Endponts信息，建立一個軟件方式的負(fù)載均衡器來實現(xiàn)Service訪問到后端Pod的流量轉(zhuǎn)發(fā)功能文章來源地址http://www.zghlxwxcb.cn/news/detail-447644.html

到了這里，關(guān)于Kubernetes（K8S）的基礎(chǔ)概念的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！