騰訊云服務器用什么做網(wǎng)站企業(yè)培訓課程視頻
目錄
1. K8S概述
1.1 K8S是什么
1.2 作用
1.3 由來
1.4 含義
1.5 相關(guān)網(wǎng)站
2. 為什么要用K8S
3. K8S解決的問題
4. K8S的特性
5. Kubernetes集群架構(gòu)與組件
6. 核心組件
6.1 Master組件
6.1.1 Kube-apiserver
6.1.2 Kube-controller-manager
6.1.3 kube-scheduler
6.1.4 配置存儲中心
6.2 Node組件
6.2.1 Kubelet
6.2.2 Kube-Proxy
6.2.3 docker或rocket
7. Kubernetes核心概念
7.1 Pod
7.2 Pod控制器
7.3 Label
7.4 Label選擇器(Label selector)
7.5 Service
7.6 Ingress
7.7 Name
7.8 Namespace
8. kubernetes的工作流程
1. K8S概述
1.1 K8S是什么
K8S的全稱為Kubernetes(K12345678S
1.2 作用
用于自動部署、擴展和管理“容器化(containerized)應用程序”的開源系統(tǒng)??梢岳斫獬蒏8S是負責自動化運維管理多個容器化程序(比如Docker)的集群,是一個生態(tài)極其豐富的容器編排框架工具。
1.3 由來
K8S由google的Borg系統(tǒng)(博格系統(tǒng),google內(nèi)部使用的大規(guī)模容器編排工具)作為延用,后經(jīng)GO語言延用Borg的思路重寫并捐獻給 CNCF基金會 開源。
1.4 含義
詞根源于希臘語的舵手、飛行員
1.5 相關(guān)網(wǎng)站
官網(wǎng): https://kubernetes.io GitHub: GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management
2. 為什么要用K8S
試想下傳統(tǒng)的后端部署辦法:把程序包(包括可執(zhí)行二進制文件、配置文件等)放到服務器上,接著運行啟動腳本把程序跑起來,同時啟動守護腳本定期檢查程序運行狀態(tài)、必要的話重新拉起程序。 設(shè)想一下,如果服務的請求量上來,已部署的服務響應不過來怎么辦?傳統(tǒng)的做法往往是,如果請求量、內(nèi)存、CPU超過閾值做了告警,運維人員馬上再加幾臺服務器,部署好服務之后,接入負載均衡來分擔已有服務的壓力。 這樣問題就出現(xiàn)了:從監(jiān)控告警到部署服務,中間需要人力介入!那么,有沒有案發(fā)自動完成服務的部署、更新、卸載和擴容、縮容呢? 而這就是K8S要做的事情:自動化運維管理容器化(Docker)程序。 K8S的目標是讓部署容器化應用簡單高效。
3. K8S解決的問題
K8S解決了裸跑Docker的若干痛點:
● 單機使用,無法有效集群
● 隨著容器數(shù)量的上升,管理成本攀升
● 沒有有效的容災、自愈機制
● 沒有預設(shè)編排模板,無法實現(xiàn)快速、大規(guī)模容器調(diào)度
● 沒有統(tǒng)一的配置管理中心工具
● 沒有容器生命周期的管理工具
● 沒有圖形化運維管理工具
K8S提供了容器編排,資源調(diào)度,彈性伸縮,部署管理,服務發(fā)現(xiàn)等一系列功能。
4. K8S的特性
● 彈性伸縮 使用命令、UI或者基于CPU使用情況自動快速擴容和縮容應用程序?qū)嵗?#xff0c;保證應用業(yè)務高峰并發(fā)時的高可用性;業(yè)務低峰時回收資源,以最小成本運行服務。
● 自我修復 在節(jié)點故障時重新啟動失敗的容器,替換和重新部署,保證預期的副本數(shù)量;殺死健康檢查失敗的容器,并且在未準備好之前不會處理客戶端請求,確保線上服務不中斷
● 自動發(fā)布(默認滾動發(fā)布模式)和回滾 K8S采用滾動更新策略更新應用,一次更新一個Pod,而不是同時刪除所有Pod,如果更新過程中出現(xiàn)問題,將回滾更改,確保升級不影響業(yè)務。
● 集中化配置管理和密鑰管理 管理機密數(shù)據(jù)和應用程序配置,而不需要把敏感數(shù)據(jù)暴露在鏡像里,提高敏感數(shù)據(jù)安全性。并可以將一些常用的配置存儲在K8S中,方便應用程序使用。
● 存儲編排,支持外掛存儲并對外掛存儲資源進行編排 掛載外部存儲系統(tǒng),無論是來自本地存儲,公有云(如AWS),還是網(wǎng)絡(luò)存儲(如NFS、GlusterFS、Ceph)都作為集群資源的一部分使用,極大提高存儲使用靈活性。
● 任務批處理運行 提供一次性任務,定時任務;滿足批量數(shù)據(jù)處理和分析的場景
5. Kubernetes集群架構(gòu)與組件
K8S是屬于主從設(shè)備模型(Master-Slave架構(gòu)),即有Master節(jié)點負責集群的調(diào)度、管理和運維,Slave節(jié)點是集群中的運算工作負載節(jié)點。 在K8S中,主節(jié)點一般被稱為Master節(jié)點,而從節(jié)點則被稱為Worker Node節(jié)點,每個Node都會被Master所在節(jié)點宕機或不可用,那么所有的控制命令都將失效。除了Master,在K8S集群中的其他機器被稱為Worker Node節(jié)點,當某個Node宕機時,其上的工作負載會被Master自動轉(zhuǎn)移到其他節(jié)點上去。
6. 核心組件
6.1 Master組件
6.1.1 Kube-apiserver
用于暴露kubernetes API,任何資源請求或調(diào)用操作都是通過kube-apiserver提供的接口進行。以HTTP Restful API提供接口服務,所有對象資源的增刪改查和監(jiān)聽操作都交給API Server處理后再提交給Etcd存儲。 可以理解成API Server是K8S的請求入口服務。API Server負責接收K8S所有請求(來自UI界面或者CLI命令行工具),然后根據(jù)用戶的具體請求,去通知其他組件干活。可以說API Server是K8S集群架構(gòu)的大腦。
6.1.2 Kube-controller-manager
運行管理控制,是K8S集群中處理常規(guī)任務的后臺線程,是K8S集群里所有資源對象的自動化控制中心。 在K8S集群中,一個資源對應一個控制器,而Controller manager就是負責管理這些控制器的。 由一系列控制器組成,通過API Server監(jiān)控整個集群的狀態(tài),并確保集群處于預期的工作狀態(tài),比如當某個Node意外宕機時,Controller Manager會及時發(fā)現(xiàn)并執(zhí)行自動化修復流程,確保集群始終處于預期的工作狀態(tài)。
控制器 | 說明 |
---|---|
Node Controller(節(jié)點控制器) | 負責在節(jié)點出現(xiàn)故障時發(fā)現(xiàn)和響應 |
Replication Controller(副本控制器) | 負責保證集群中一個RC(資源對象Replication Controller)所關(guān)聯(lián)的Pod副本數(shù)始終保持預設(shè)值??梢岳斫獬纱_保集群中有且僅有N個Pod實例,N是RC中定義的Pod副本數(shù)量 |
Endpoints Controller(端點控制器) | 填充端點對象(即連接Services和Pods),負責監(jiān)聽Service和對應的Pod副本的變化??梢岳斫舛它c是一個服務暴露出來的訪問點,如果需要訪問一個服務暴露出來的訪問點,如果需要訪問一個服務,則必須知道它的endpoint |
Service Account & Token Controllers(服務賬戶和令牌控制器) | 為新的命名空間創(chuàng)建默認賬戶和API訪問令牌 |
ResourceQuota Controller(資源配額控制器) | 確保指定的資源對象在任何時候都不會超量占用系統(tǒng)物理資源 |
Namespace Controller(命名空間控制器) | 管理namespace的聲明周期 |
Service Controller(服務控制器) | 屬于K8S集群與外部的云平臺之間的一個接口控制器 |
6.1.3 kube-scheduler
是負責資源調(diào)度的進程,根據(jù)調(diào)度算法為新創(chuàng)建的Pod選擇一份合適的Node節(jié)點。 可以理解成K8S所有Node節(jié)點的調(diào)度器。當用于要部署服務時,Scheduler會根據(jù)調(diào)度算法選擇最合適的Node節(jié)點來部署Pod。
● 預算策略(predicate)
● 優(yōu)選策略(priorities) API Server接收到請求創(chuàng)建一批Pod,API Server會讓Controller-manager按照所預設(shè)的模板去創(chuàng)建Pod,Controller-manager會通過API Server去找Scheduler為新創(chuàng)建的Pod選擇最適合的Node節(jié)點。比如運行這個Pod需要2C4G的資源,Schedular會通過預算策略在所有Node節(jié)點中挑選最優(yōu)的。Node節(jié)點中還剩多少資源是通過匯報給API Server存儲在etcd里,API Server會調(diào)用一個方法找到etcd里所有Node節(jié)點的剩余資源,再對比Pod所需要的資源,在所有Node節(jié)點中查找哪些Node節(jié)點符合要求。如果都符合,預算策略就交給優(yōu)選策略處理,優(yōu)選策略再通過CPU的負載、內(nèi)存的剩余量等因素選擇最合適的Node節(jié)點,并把Pod調(diào)度到這個Node節(jié)點上運行。
6.1.4 配置存儲中心
● etcd K8S的存儲服務。etcd分布式鍵值存儲系統(tǒng),存儲了K8S的關(guān)鍵配置和用戶配置,K8S中僅API Server才具備讀寫權(quán)限,其他組件必須通過API Server的接口才能讀寫數(shù)據(jù)。
6.2 Node組件
6.2.1 Kubelet
Node節(jié)點的監(jiān)視器,以及與Master節(jié)點的通訊器。Kubelet是Master節(jié)點安插在Node節(jié)點上的“眼線”,它會定時向API Server匯報自己Node節(jié)點上運行的服務的狀態(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)用對應的容器平臺接口(即docker的接口)達到這個狀態(tài)。 管理鏡像和容器的清理工作,保證節(jié)點上鏡像不會占滿磁盤空間,退出的容器不會占用太多資源。 PS:Kubelet真是個苦逼老父親,又當?shù)之攱?#xff0c;一把屎一把尿把這些容器拉扯大,還要給它們養(yǎng)老送終。。。。
6.2.2 Kube-Proxy
在每個Node節(jié)點上實現(xiàn)Pod網(wǎng)絡(luò)代理,是Kuberbetes Service資源的載體,負責維護網(wǎng)絡(luò)規(guī)劃和四層負載均衡工作。負責寫入規(guī)則至iptables、ipvs實現(xiàn)服務映射訪問的。 Kube-Proxy本身不是直接給Pod提供網(wǎng)絡(luò),Pod的網(wǎng)絡(luò)是由Kubelet提供的,Kube-Proxy實際上維護的是虛擬的Pod集群網(wǎng)絡(luò)。 Kube-apiserver通過監(jiān)控Kube-Proxy進行對Kubernets Service的更新和端點的維護。 在K8S集群中微服務的負載均衡是由Kube-Proxy是K8S集群內(nèi)部的負載均衡器。它是一個分布式代理服務器,在K8S的每個節(jié)點上都會運行一個Kube-proxy。
6.2.3 docker或rocket
容器引擎,運行容器,負責本機的容器創(chuàng)建和管理工作。
7. Kubernetes核心概念
Kubernetes包含多種類型的資源對象:Pod、Lable、Service、Replication Controller等。 所有的資源對象都可以通過Kubernetes提供的Kubectl工具進行增刪改查等操作,并將其保存在etcd中持久化存儲。Kubernetes其實是一個高度自動化的資源控制系統(tǒng),通過跟蹤對比etcd存儲里的資源期望狀態(tài)與當前環(huán)境中的實際資源狀態(tài)的差異,來實現(xiàn)自動控制和自動糾錯等高級功能。
7.1 Pod
Pod是Kuberntes創(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ù)卷。
7.2 Pod控制器
Pod控制器是Pod啟動的一種模板,用來保證在K8S里啟動的Pod應始終按照用戶的預期運行(副本數(shù)、生命周期、健康狀態(tài)檢查等)。 K8S內(nèi)提供了眾多的Pod控制器,常用的有以下幾種:
● Deployment:無狀態(tài)應用部署。Deployment的作用就是管理和控制Pod和ReplicaSet,管控它們運行在用戶期望的狀態(tài)中。
● Replicaset:確保預期的Pod副本數(shù)量。ReplicaSet的作用就是管理和控制Pod,管控他們好好干活。但是,ReplicaSet受控于Deployment。
可以理解成Deployment就是總包工頭,主要負責監(jiān)督底下的工人Pod干活,確保每時每刻有用戶要求數(shù)量的Pod在工作。如果一旦發(fā)現(xiàn)某個工人Pod不行了,就趕緊新拉一個Pod過來替換它。而ReplicaSet就是總包工頭手下的小包工頭。
從K8S使用者角度來看,用戶會直接操作Deployment部署服務,而當Deployment被部署的時候,K8S會自動生成要求的ReplicaSet和Pod。用戶只需要關(guān)心Deployment而不操心ReplicaSet。 資源對象Replication Controller是ReplicaSet的前身,官方推薦用Deployment取代Replication Controller來部署服務。
● Daemonset:確保所有節(jié)點運行同一類Pod,保證每個節(jié)點上都有一個此類Pod運行,通常用于實現(xiàn)系統(tǒng)級后臺任務。
● Statefulset:有狀態(tài)應用部署
● Job:一次性任務。根據(jù)用戶的設(shè)置,Job管理的Pod把任務成功完成就自動退出了。
● Cronjob:周期性計劃性任務
7.3 Label
標簽,是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ū)別在于有效的標簽值必須為63個字符或更少,并且必須為空或以字母數(shù)字字符([a-z0-9A-Z])開頭和結(jié)尾,中間可以包含橫杠(-)、下劃線(_)、點(.)和字母或數(shù)字。注釋值則沒有字符長度限制。
7.4 Label選擇器(Label selector)
給某個資源對象定義一個Label,就相當于給它打了一個標簽;隨后可以通過標簽選擇器(Label selector)查詢和篩選擁有某些Label的資源對象。 標簽選擇器目前有兩種:基于等值關(guān)系(等于、不等于)和基于集合關(guān)系(屬于、不屬于、存在)。
7.5 Service
在K8S的集群里,雖然每個Pod會被分配一個單獨的IP地址,但由于Pod是有生命周期的(它們可以被創(chuàng)建,而且銷毀之后不會再啟動),隨時可能會因為業(yè)務的變更,導致這個IP地址也會隨著Pod的銷毀而消失。 Service就是用來解決這個問題的核心概念。
K8S中的Service并不是我們常說的“服務”的含義,而更像是網(wǎng)關(guān)層,可以看做一組提供相同服務的Pod的對外訪問機接口、流量均衡器。
Service作用于哪些Pod是通過標簽選擇器來定義的。
在K8S集群中,Service可以看做一組提供相同服務的Pod的對外訪問接口??蛻舳诵枰L問的服務就是Service對象。每個Service都有一個固定的虛擬IP(這個IP也被稱為Cluster IP),自動并且動態(tài)地綁定后端的Pod,所有的網(wǎng)絡(luò)請求直接訪問Service的虛擬IP,Service會自動向后端做轉(zhuǎn)發(fā)。
Service除了提供穩(wěn)定的對外訪問方式之外,還能起到負載均衡(Load Balance)的功能,自動把請求流量分不到后端所有的服務上,Service可以做到對客戶透明地進行水平擴展(scale)。 而實現(xiàn)service這一功能的關(guān)鍵,就是kube-proxy。kube-proxy運行在每個節(jié)點上,監(jiān)聽API Server中服務對象的變化,可通過以下三種流量調(diào)度模式:userspace(廢棄)、iptables(瀕臨廢棄)、ipvs(推薦,性能最好)來實現(xiàn)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)。
Service是K8S服務的核心,屏蔽了服務細節(jié),統(tǒng)一對外暴露服務接口,真正做到了“微服務”。比如我們的一個服務A,部署了3個副本,也就是3個Pod;對于用戶來說,只需要關(guān)注一個Service的入口就可以,而不需要操心究竟也應該請求哪一個Pod。
優(yōu)勢非常明顯:一方面外部用戶不需要感知因為Pod上服務的意外崩潰、K8S重新拉起Pod而造成的IP變更,外部用戶也不需要感知因升級、變更服務帶來的Pod替換而造成的IP變化。
7.6 Ingress
Service主要負責K8S集群內(nèi)部的網(wǎng)絡(luò)拓撲,那么集群外部怎么訪問集群內(nèi)部呢?這個時候就需要Ingress了。Ingress是整個K8S集群的接入層,負責集群內(nèi)外通訊。
Ingress是K8S集群里工作在OSI網(wǎng)絡(luò)參考模型下,第7層的應用,對外暴露的接口,典型的訪問方式是http/https。
Service只能進行第四層的流量調(diào)度,表現(xiàn)形式是ip+port。Ingress則可以調(diào)度不同業(yè)務域、不同URL訪問路徑的業(yè)務流量。
比如:客戶端請求http://www.test.com:port --> Ingress --> Service --> Pod
7.7 Name
由于K8S內(nèi)部,使用“資源”來定義每一種邏輯概念(功能),所以每種“資源”,都應該有自己的“名稱”。 “資源”有api版本(apiversion)、類別(kind)、元數(shù)據(jù)(metadata)、定義清單(spec)、狀態(tài)(status)等配置信息。
“名稱”通常定義在“資源”的“元數(shù)據(jù)”信息里。在同一個namespace空間中必須是唯一的。
7.8 Namespace
隨著項目增多、人員增加、集群規(guī)模的擴大,需要一種能夠邏輯上隔離K8S內(nèi)各種“資源”的方法,這就是Namespace。
Namespace是為了把一個K8S集群劃分為若干個資源不可共享的虛擬集群組而誕生的。
不同Namespace內(nèi)的“資源”名稱可以相同,相同Namespace內(nèi)的各種“資源”,“名稱”不能相同。 合理的使用K8S的Namespace,可以使得集群管理員能夠更好的對交付到K8S里的服務進行分類管理和瀏覽。 K8S里默認存在的Namespace有:default、kube-system、kube-public等。
查詢K8S里特定“資源”要帶上相應的Namespace。
8. kubernetes的工作流程
k8s有兩種模塊,master 模塊和worker-node 模塊。
master 節(jié)點包括apiserver、scheduler、controller-manager以及ETCD(可獨立部署);node節(jié)點包括 kubelet、kube-proxy、容器引擎(docker/rocket等) 用戶通過客戶端發(fā)送請求給集群的唯一入口 API Server API
Server 先將用戶的請求信息寫入到 etcd存儲中。再去找Controller manager 創(chuàng)建對應的pod Controller Manager通過API Server 去讀取etcd 里的用戶請求信息,根據(jù)請求去創(chuàng)建預設(shè)的模板(如什么鏡像,多少實例,健康檢查等),將模板寫入到etcd中,在根據(jù)模板創(chuàng)建pod Controller Manager 通過 API Server 去找到Scheduler調(diào)度pod,為新創(chuàng)建的Pod選擇node節(jié)點 Scheduler 通過API Server 再etcd 存儲中讀取node節(jié)點的資源信息(信息由kubele發(fā)送到master的),通過預算策略和優(yōu)選策略,從node節(jié)點中挑選最優(yōu)的,并把pod調(diào)度到這個節(jié)點運行。 預算策略:將所有node節(jié)點的剩余資源和pod所需的資源對比,找出符合pod資源需求的node節(jié)點 優(yōu)選策略:預算策略篩選后的node節(jié)點被交給優(yōu)選策略。通過cpu負載,內(nèi)存剩余等因素,找出最合適的node節(jié)點。把pod調(diào)度到這個節(jié)點運行 Scheduler 確定了調(diào)度的節(jié)點后,通過API Server 去找到對應node節(jié)點上的kublet,由kublet 調(diào)動容器引擎創(chuàng)建pod kublet 不僅和容器引擎交互,實現(xiàn)容器的生命周期管理。還監(jiān)控node節(jié)點上的資源信息,pod狀態(tài)。將這些匯報給API Server 存儲到etcd中。 kube-proxy創(chuàng)建網(wǎng)絡(luò)規(guī)則,制定轉(zhuǎn)發(fā)規(guī)則。創(chuàng)建service作為負載均衡的訪問入口(cluster-ip、nodeport等),把用戶的請求通過負載均衡轉(zhuǎn)發(fā)到關(guān)聯(lián)的pod上,從而發(fā)布pod里的業(yè)務