目錄
Kubernetes概述
K8S 是什么
為什么要用 K8S
K8S 的特性
Kubernetes 集群架構(gòu)與組件
核心組件
Master 組件
Node 組件?
?編輯
Kubernetes 核心概念
常見的K8S按照部署方式
Kubernetes概述
K8S 是什么
K8S 的全稱為 Kubernetes,Kubernetes 是一個(gè)可移植、可擴(kuò)展的開源平臺(tái),用于管理容器化的工作負(fù)載和服務(wù),可促進(jìn)聲明式配置和自動(dòng)化。 Kubernetes 擁有一個(gè)龐大且快速增長的生態(tài),其服務(wù)、支持和工具的使用范圍相當(dāng)廣泛。?Google 在 2014 年開源了 Kubernetes 項(xiàng)目。 Kubernetes 建立在?Google 大規(guī)模運(yùn)行生產(chǎn)工作負(fù)載十幾年經(jīng)驗(yàn)的基礎(chǔ)上, 結(jié)合了Google 大規(guī)模運(yùn)行生產(chǎn)工作負(fù)載十幾年經(jīng)驗(yàn)社區(qū)中最優(yōu)秀的想法和實(shí)踐。
作用:
用于自動(dòng)部署、擴(kuò)展和管理“容器化(containerized)應(yīng)用程序”的開源系統(tǒng)。
可以理解成 K8S 是負(fù)責(zé)自動(dòng)化運(yùn)維管理多個(gè)容器化程序(比如 Docker)的集群,是一個(gè)生態(tài)極其豐富的容器編排框架工具。
由來:
K8S由google的Borg系統(tǒng)(博格系統(tǒng),google內(nèi)部使用的大規(guī)模容器編排工具)作為原型,后經(jīng)GO語言延用Borg的思路重寫并捐獻(xiàn)給CNCF基金會(huì)開源。
含義:
詞根源于希臘語的 舵手、飛行員
官網(wǎng):
https://kubernetes.io
GitHub:
https://github.com/kubernetes/kubernetes
為什么要用 K8S
試想下傳統(tǒng)的后端部署辦法:把程序包(包括可執(zhí)行二進(jìn)制文件、配置文件等)放到服務(wù)器上,接著運(yùn)行啟動(dòng)腳本把程序跑起來,同時(shí)啟動(dòng)守護(hù)腳本定期檢查程序運(yùn)行狀態(tài)、必要的話重新拉起程序。
設(shè)想一下,如果服務(wù)的請(qǐng)求量上來,已部署的服務(wù)響應(yīng)不過來怎么辦?傳統(tǒng)的做法往往是,如果請(qǐng)求量、內(nèi)存、CPU超過閾值做了告警,運(yùn)維人員馬上再加幾臺(tái)服務(wù)器,部署好服務(wù)之后,接入負(fù)載均衡來分擔(dān)已有服務(wù)的壓力。
這樣問題就出現(xiàn)了:從監(jiān)控告警到部署服務(wù),中間需要人力介入!那么,有沒有辦法自動(dòng)完成服務(wù)的部署、更新、卸載和擴(kuò)容、縮容呢?
而這就是 K8S 要做的事情:自動(dòng)化運(yùn)維管理容器化(Docker)程序。
Kubernetes 提供了一個(gè)可彈性運(yùn)行分布式系統(tǒng)的框架。 Kubernetes?可以滿足擴(kuò)展要求、故障轉(zhuǎn)移、提供部署模式等。 例如,Kubernetes 可以輕松管理系統(tǒng)的 Canary (金絲雀) 部署。
K8S 的目標(biāo)是讓部署容器化應(yīng)用簡單高效。
K8S 解決了裸跑Docker 的若干痛點(diǎn):
●單機(jī)使用,無法有效集群
●隨著容器數(shù)量的上升,管理成本攀升
●沒有有效的容災(zāi)、自愈機(jī)制
●沒有預(yù)設(shè)編排模板,無法實(shí)現(xiàn)快速、大規(guī)模容器調(diào)度
●沒有統(tǒng)一的配置管理中心工具
●沒有容器生命周期的管理工具
●沒有圖形化運(yùn)維管理工具
K8S是Google開源的容器集群管理系統(tǒng),在Docker等容器技術(shù)的基礎(chǔ)上,為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)伸縮等一系列完整功能,提高了大規(guī)模容器集群管理的便捷性。 其主要功能如下:
●使用 Docker 等容器技術(shù)對(duì)應(yīng)用程序包裝(package)、實(shí)例化(instantiate)、運(yùn)行(run)。
●以集群的方式運(yùn)行、管理跨機(jī)器的容器。
●解決 Docker 跨機(jī)器容器之間的通訊問題。
●K8S 的自我修復(fù)機(jī)制使得容器集群總是運(yùn)行在用戶期望的狀態(tài)。
K8S 的特性
●彈性伸縮
使用命令、UI或者基于CPU使用情況自動(dòng)快速擴(kuò)容和縮容應(yīng)用程序?qū)嵗WC應(yīng)用業(yè)務(wù)高峰并發(fā)時(shí)的高可用性;業(yè)務(wù)低峰時(shí)回收資源,以最小成本運(yùn)行服務(wù)。
●自我修復(fù)
在節(jié)點(diǎn)故障時(shí)重新啟動(dòng)失敗的容器,替換和重新部署,保證預(yù)期的副本數(shù)量;殺死健康檢査失敗的容器,并且在未準(zhǔn)備好之前不會(huì)處理客戶端請(qǐng)求,確保線上服務(wù)不中斷。
●服務(wù)發(fā)現(xiàn)和負(fù)載均衡
K8S為多個(gè)容器提供一個(gè)統(tǒng)一訪問入口(內(nèi)部IP地址和一個(gè)DNS名稱),并且負(fù)載均衡關(guān)聯(lián)的所有容器,使得用戶無需考慮容器IP問題。
●自動(dòng)發(fā)布(默認(rèn)滾動(dòng)發(fā)布模式)和回滾
K8S采用滾動(dòng)更新策略更新應(yīng)用,一次更新一個(gè)或者部分Pod,而不是同時(shí)刪除所有Pod,如果更新過程中出現(xiàn)問題,將回滾更改,確保升級(jí)不影響業(yè)務(wù)。
●集中化配置管理和密鑰管理
管理機(jī)密數(shù)據(jù)和應(yīng)用程序配置,而不需要把敏感數(shù)據(jù)暴露在鏡像里,提高敏感數(shù)據(jù)安全性。并可以將一些常用的配置存儲(chǔ)在K8S中,方便應(yīng)用程序使用。
●存儲(chǔ)編排,支持外掛存儲(chǔ)并對(duì)外掛存儲(chǔ)資源進(jìn)行編排
掛載外部存儲(chǔ)系統(tǒng),無論是來自本地存儲(chǔ),公有云(如AWS),還是網(wǎng)絡(luò)存儲(chǔ)(如NFS、Glusterfs、Ceph)都作為集群資源的一部分使用,極大提高存儲(chǔ)使用靈活性。
●任務(wù)批處理運(yùn)行
提供一次性任務(wù),定時(shí)任務(wù);滿足批量數(shù)據(jù)處理和分析的場(chǎng)景。
Kubernetes 集群架構(gòu)與組件
K8S 是屬于主從設(shè)備模型(Master-Slave 架構(gòu)),即有 Master 節(jié)點(diǎn)負(fù)責(zé)集群的調(diào)度、管理和運(yùn)維,Slave 節(jié)點(diǎn)是集群中的運(yùn)算工作負(fù)載節(jié)點(diǎn)。
在 K8S 中,主節(jié)點(diǎn)一般被稱為 Master 節(jié)點(diǎn),而從節(jié)點(diǎn)則被稱為 Worker Node 節(jié)點(diǎn),每個(gè) Node 都會(huì)被 Master 分配一些工作負(fù)載。
Master 組件可以在群集中的任何計(jì)算機(jī)上運(yùn)行,但建議 Master 節(jié)點(diǎn)占據(jù)一個(gè)獨(dú)立的服務(wù)器。因?yàn)?Master 是整個(gè)集群的大腦,如果 Master 所在節(jié)點(diǎn)宕機(jī)或不可用,那么所有的控制命令都將失效。除了 Master,在 K8S 集群中的其他機(jī)器被稱為 Worker Node 節(jié)點(diǎn),當(dāng)某個(gè) Node 宕機(jī)時(shí),其上的工作負(fù)載會(huì)被 Master 自動(dòng)轉(zhuǎn)移到其他節(jié)點(diǎn)上去。
核心組件
Master 組件
●Kube-apiserver
用于暴露 Kubernetes API,任何資源請(qǐng)求或調(diào)用操作都是通過 kube-apiserver 提供的接口進(jìn)行。以 HTTP Restful API 提供接口服務(wù),所有對(duì)象資源的增刪改查和監(jiān)聽操作都交給 API Server 處理后再提交給 Etcd 存儲(chǔ)。
可以理解成 API Server 是 K8S 的請(qǐng)求入口服務(wù)。API Server 負(fù)責(zé)接收 K8S 所有請(qǐng)求(來自 UI 界面或者 CLI 命令行工具), 然后根據(jù)用戶的具體請(qǐng)求,去通知其他組件干活??梢哉f API Server 是 K8S 集群架構(gòu)的大腦。
●Kube-controller-manager
運(yùn)行管理控制器,是 K8S 集群中處理常規(guī)任務(wù)的后臺(tái)線程,是 K8S 集群里所有資源對(duì)象的自動(dòng)化控制中心。
在 K8S 集群中,一個(gè)資源對(duì)應(yīng)一個(gè)控制器,而 Controller manager 就是負(fù)責(zé)管理這些控制器的。
由一系列控制器組成,通過 API Server 監(jiān)控整個(gè)集群的狀態(tài),并確保集群處于預(yù)期的工作狀態(tài),比如當(dāng)某個(gè) Node 意外宕機(jī)時(shí),Controller Manager 會(huì)及時(shí)發(fā)現(xiàn)并執(zhí)行自動(dòng)化修復(fù)流程,確保集群始終處于預(yù)期的工作狀態(tài)。
這些控制器主要包括:
?Node Controller(節(jié)點(diǎn)控制器):負(fù)責(zé)在節(jié)點(diǎn)出現(xiàn)故障時(shí)發(fā)現(xiàn)和響應(yīng)。
?Replication Controller(副本控制器):負(fù)責(zé)保證集群中一個(gè) RC(資源對(duì)象 Replication Controller)所關(guān)聯(lián)的 Pod 副本數(shù)始終保持預(yù)設(shè)值。可以理解成確保集群中有且僅有 N 個(gè) Pod 實(shí)例,N 是 RC 中定義的 Pod 副本數(shù)量。
?Endpoints Controller(端點(diǎn)控制器):填充端點(diǎn)對(duì)象(即連接 Services 和 Pods),負(fù)責(zé)監(jiān)聽 Service 和對(duì)應(yīng)的 Pod 副本的變化。 可以理解端點(diǎn)是一個(gè)服務(wù)暴露出來的訪問點(diǎn),如果需要訪問一個(gè)服務(wù),則必須知道它的 endpoint。
?Service Account & Token Controllers(服務(wù)帳戶和令牌控制器):為新的命名空間創(chuàng)建默認(rèn)帳戶和 API 訪問令牌。
?ResourceQuota Controller(資源配額控制器):確保指定的資源對(duì)象在任何時(shí)候都不會(huì)超量占用系統(tǒng)物理資源。
?Namespace Controller(命名空間控制器):管理 namespace 的生命周期。
?Service Controller(服務(wù)控制器):屬于 K8S 集群與外部的云平臺(tái)之間的一個(gè)接口控制器。
●Kube-scheduler
是負(fù)責(zé)資源調(diào)度的進(jìn)程,根據(jù)調(diào)度算法為新創(chuàng)建的 Pod 選擇一個(gè)合適的 Node 節(jié)點(diǎn)。
可以理解成 K8S 所有 Node 節(jié)點(diǎn)的調(diào)度器。當(dāng)用戶要部署服務(wù)時(shí),Scheduler 會(huì)根據(jù)調(diào)度算法選擇最合適的 Node 節(jié)點(diǎn)來部署 Pod。
?預(yù)選策略(predicate)
?優(yōu)選策略(priorities)
API Server 接收到請(qǐng)求創(chuàng)建一批 Pod ,API Server 會(huì)讓 Controller-manager 按照所預(yù)設(shè)的模板去創(chuàng)建 Pod,Controller-manager 會(huì)通過 API Server 去找 Scheduler 為新創(chuàng)建的 Pod 選擇最適合的 Node 節(jié)點(diǎn)。比如運(yùn)行這個(gè) Pod 需要 2C4G 的資源,Scheduler 會(huì)通過預(yù)選策略過濾掉不滿足策略的 Node 節(jié)點(diǎn)。Node 節(jié)點(diǎn)中還剩多少資源是通過匯報(bào)給 API Server 存儲(chǔ)在 etcd 里,API Server 會(huì)調(diào)用一個(gè)方法找到 etcd 里所有 Node 節(jié)點(diǎn)的剩余資源,再對(duì)比 Pod 所需要的資源,如果某個(gè) Node 節(jié)點(diǎn)的資源不足或者不滿足 預(yù)選策略的條件則無法通過預(yù)選。預(yù)選階段篩選出的節(jié)點(diǎn),在優(yōu)選階段會(huì)根據(jù)優(yōu)先策略為通過預(yù)選的 Node 節(jié)點(diǎn)進(jìn)行打分排名, 選擇得分最高的 Node。例如,資源越富裕、負(fù)載越小的 Node 可能具有越高的排名。
●etcd
K8S 的存儲(chǔ)服務(wù)。etcd 是分布式鍵值存儲(chǔ)系統(tǒng),存儲(chǔ)了 K8S 的關(guān)鍵配置和用戶配置,K8S 中僅 API Server 才具備讀寫權(quán)限,其他組件必須通過 API Server 的接口才能讀寫數(shù)據(jù)。
Node 組件?
●Kubelet
Node 節(jié)點(diǎn)的監(jiān)視器,以及與 Master 節(jié)點(diǎn)的通訊器。Kubelet 是 Master 節(jié)點(diǎn)安插在 Node 節(jié)點(diǎn)上的“眼線”,它會(huì)定時(shí)向 API Server 匯報(bào)自己 Node 節(jié)點(diǎn)上運(yùn)行的服務(wù)的狀態(tài),并接受來自 Master 節(jié)點(diǎn)的指示采取調(diào)整措施。
從 Master 節(jié)點(diǎn)獲取自己節(jié)點(diǎn)上 Pod 的期望狀態(tài)(比如運(yùn)行什么容器、運(yùn)行的副本數(shù)量、網(wǎng)絡(luò)或者存儲(chǔ)如何配置等), 直接跟容器引擎交互實(shí)現(xiàn)容器的生命周期管理,如果自己節(jié)點(diǎn)上 Pod 的狀態(tài)與期望狀態(tài)不一致,則調(diào)用對(duì)應(yīng)的容器平臺(tái)接口(即 docker 的接口)達(dá)到這個(gè)狀態(tài)。
管理鏡像和容器的清理工作,保證節(jié)點(diǎn)上鏡像不會(huì)占滿磁盤空間,退出的容器不會(huì)占用太多資源。
總結(jié):
在 Kubernetes 集群中,在每個(gè) Node(又稱 Worker Node)上都會(huì)啟動(dòng)一個(gè) kubelet 服務(wù)進(jìn)程。該進(jìn)程用于處理 Master 下發(fā)到本節(jié)點(diǎn)的任務(wù),管理 Pod 及 Pod 中的容器。每個(gè) kubelet 進(jìn)程都會(huì)在 API Server 上注冊(cè)節(jié)點(diǎn)自身的信息,定期向 Master 匯報(bào)節(jié)點(diǎn)資源的使用情況,并通過 cAdvisor 監(jiān)控容器和節(jié)點(diǎn)資源。
●Kube-Proxy
在每個(gè) Node 節(jié)點(diǎn)上實(shí)現(xiàn) Pod 網(wǎng)絡(luò)代理,是 Kubernetes Service 資源的載體,負(fù)責(zé)維護(hù)網(wǎng)絡(luò)規(guī)則和四層負(fù)載均衡工作。 負(fù)責(zé)寫入規(guī)則至iptables、ipvs實(shí)現(xiàn)服務(wù)映射訪問的。
Kube-Proxy 本身不是直接給 Pod 提供網(wǎng)絡(luò),Pod 的網(wǎng)絡(luò)是由 Kubelet 提供的,Kube-Proxy 實(shí)際上維護(hù)的是虛擬的 Pod 集群網(wǎng)絡(luò)。
Kube-apiserver 通過監(jiān)控 Kube-Proxy 進(jìn)行對(duì) Kubernetes Service 的更新和端點(diǎn)的維護(hù)。
在 K8S 集群中微服務(wù)的負(fù)載均衡是由 Kube-proxy 實(shí)現(xiàn)的。Kube-proxy 是 K8S 集群內(nèi)部的負(fù)載均衡器。它是一個(gè)分布式代理服務(wù)器,在 K8S 的每個(gè)節(jié)點(diǎn)上都會(huì)運(yùn)行一個(gè) Kube-proxy 組件。
●docker 或 rocket
容器引擎,運(yùn)行容器,負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理工作。
Kubernetes 核心概念
Kubernetes 包含多種類型的資源對(duì)象:Pod、Label、Service、Replication Controller 等。
所有的資源對(duì)象都可以通過 Kubernetes 提供的 kubectl 工具進(jìn)行增、刪、改、查等操作,并將其保存在 etcd 中持久化存儲(chǔ)。
Kubernets其實(shí)是一個(gè)高度自動(dòng)化的資源控制系統(tǒng),通過跟蹤對(duì)比etcd存儲(chǔ)里保存的資源期望狀態(tài)與當(dāng)前環(huán)境中的實(shí)際資源狀態(tài)的差異,來實(shí)現(xiàn)自動(dòng)控制和自動(dòng)糾錯(cuò)等高級(jí)功能。
●Pod
Pod是 Kubernetes 創(chuàng)建或部署的最小/最簡單的基本單位,一個(gè) Pod 代表集群上正在運(yùn)行的一個(gè)進(jìn)程。
可以把 Pod 理解成豌豆莢,而同一 Pod 內(nèi)的每個(gè)容器是一顆顆豌豆。
一個(gè) Pod 由一個(gè)或多個(gè)容器組成,Pod 中容器共享網(wǎng)絡(luò)、存儲(chǔ)和計(jì)算資源,在同一臺(tái) Docker 主機(jī)上運(yùn)行。
一個(gè) Pod 里可以運(yùn)行多個(gè)容器,又叫邊車模式(SideCar)。而在生產(chǎn)環(huán)境中一般都是單個(gè)容器或者具有強(qiáng)關(guān)聯(lián)互補(bǔ)的多個(gè)容器組成一個(gè) Pod。
同一個(gè) Pod 之間的容器可以通過 localhost 互相訪問,并且可以掛載 Pod 內(nèi)所有的數(shù)據(jù)卷;但是不同的 Pod 之間的容器不能用 localhost 訪問,也不能掛載其他 Pod 的數(shù)據(jù)卷。
●Pod 控制器
Pod 控制器是 Pod 啟動(dòng)的一種模版,用來保證在K8S里啟動(dòng)的 Pod 應(yīng)始終按照用戶的預(yù)期運(yùn)行(副本數(shù)、生命周期、健康狀態(tài)檢查等)。
K8S 內(nèi)提供了眾多的 Pod 控制器,常用的有以下幾種:
?Deployment:無狀態(tài)應(yīng)用部署。Deployment 的作用是管理和控制 Pod 和 ReplicaSet,管控它們運(yùn)行在用戶期望的狀態(tài)中。
?Replicaset:確保預(yù)期的 Pod 副本數(shù)量。ReplicaSet 的作用就是管理和控制 Pod,管控他們好好干活。但是,ReplicaSet 受控于 Deployment。
可以理解成 Deployment 就是總包工頭,主要負(fù)責(zé)監(jiān)督底下的工人 Pod 干活,確保每時(shí)每刻有用戶要求數(shù)量的 Pod 在工作。如果一旦發(fā)現(xiàn)某個(gè)工人 Pod 不行了,就趕緊新拉一個(gè) Pod 過來替換它。而ReplicaSet 就是總包工頭手下的小包工頭。
從 K8S 使用者角度來看,用戶會(huì)直接操作 Deployment 部署服務(wù),而當(dāng) Deployment 被部署的時(shí)候,K8S 會(huì)自動(dòng)生成要求的 ReplicaSet 和 Pod。用戶只需要關(guān)心 Deployment 而不操心 ReplicaSet。
資源對(duì)象 Replication Controller 是 ReplicaSet 的前身,官方推薦用 Deployment 取代 Replication Controller 來部署服務(wù)。
?Daemonset:確保所有節(jié)點(diǎn)運(yùn)行同一類 Pod,保證每個(gè)節(jié)點(diǎn)上都有一個(gè)此類 Pod 運(yùn)行,通常用于實(shí)現(xiàn)系統(tǒng)級(jí)后臺(tái)任務(wù)。
?Statefulset:有狀態(tài)應(yīng)用部署
?Job:一次性任務(wù)。根據(jù)用戶的設(shè)置,Job 管理的 Pod 把任務(wù)成功完成就自動(dòng)退出了。
?Cronjob:周期性計(jì)劃性任務(wù)
●Label
標(biāo)簽,是 K8S 特色的管理方式,便于分類管理資源對(duì)象。
Label 可以附加到各種資源對(duì)象上,例如 Node、Pod、Service、RC 等,用于關(guān)聯(lián)對(duì)象、查詢和篩選。
一個(gè) Label 是一個(gè) key-value 的鍵值對(duì),其中 key 與 value 由用戶自己指定。
一個(gè)資源對(duì)象可以定義任意數(shù)量的Label,同一個(gè)Label 也可以被添加到任意數(shù)量的資源對(duì)象中,也可以在對(duì)象創(chuàng)建后動(dòng)態(tài)添加或者刪除。
可以通過給指定的資源對(duì)象捆綁一個(gè)或多個(gè)不同的 Label,來實(shí)現(xiàn)多維度的資源分組管理功能。
與 Label 類似的,還有 Annotation(注釋)。
區(qū)別在于有效的標(biāo)簽值必須為63個(gè)字符或更少,并且必須為空或以字母數(shù)字字符([a-z0-9A-Z])開頭和結(jié)尾,中間可以包含橫杠(-)、下劃線(_)、點(diǎn)(.)和字母或數(shù)字。注釋值則沒有字符長度限制。
●Label 選擇器(Label selector)
給某個(gè)資源對(duì)象定義一個(gè) Label,就相當(dāng)于給它打了一個(gè)標(biāo)簽;隨后可以通過標(biāo)簽選擇器(Label selector)查詢和篩選擁有某些 Label 的資源對(duì)象。
標(biāo)簽選擇器目前有兩種:基于等值關(guān)系(等于、不等于)和基于集合關(guān)系(屬于、不屬于、存在)。
●Service
在K8S的集群里,雖然每個(gè)Pod會(huì)被分配一個(gè)單獨(dú)的IP地址,但由于Pod是有生命周期的(它們可以被創(chuàng)建,而且銷毀之后不會(huì)再啟動(dòng)),隨時(shí)可能會(huì)因?yàn)闃I(yè)務(wù)的變更,導(dǎo)致這個(gè) IP 地址也會(huì)隨著 Pod 的銷毀而消失。
Service 就是用來解決這個(gè)問題的核心概念。
K8S 中的 Service 并不是我們常說的“服務(wù)”的含義,而更像是網(wǎng)關(guān)層,可以看作一組提供相同服務(wù)的Pod的對(duì)外訪問接口、流量均衡器。
Service 作用于哪些 Pod 是通過標(biāo)簽選擇器來定義的。
在 K8S 集群中,Service 可以看作一組提供相同服務(wù)的 Pod 的對(duì)外訪問接口??蛻舳诵枰L問的服務(wù)就是 Service 對(duì)象。每個(gè) Service 都有一個(gè)固定的虛擬 ip(這個(gè) ip 也被稱為 Cluster IP),自動(dòng)并且動(dòng)態(tài)地綁定后端的 Pod,所有的網(wǎng)絡(luò)請(qǐng)求直接訪問 Service 的虛擬 ip,Service 會(huì)自動(dòng)向后端做轉(zhuǎn)發(fā)。
Service 除了提供穩(wěn)定的對(duì)外訪問方式之外,還能起到負(fù)載均衡(Load Balance)的功能,自動(dòng)把請(qǐng)求流量分布到后端所有的服務(wù)上,Service 可以做到對(duì)客戶透明地進(jìn)行水平擴(kuò)展(scale)。
而實(shí)現(xiàn) service 這一功能的關(guān)鍵,就是 kube-proxy。kube-proxy 運(yùn)行在每個(gè)節(jié)點(diǎn)上,監(jiān)聽 API Server 中服務(wù)對(duì)象的變化, 可通過以下三種流量調(diào)度模式: userspace(廢棄)、iptables(瀕臨廢棄)、ipvs(推薦,性能最好)來實(shí)現(xiàn)網(wǎng)絡(luò)的轉(zhuǎn)發(fā)。
Service 是 K8S 服務(wù)的核心,屏蔽了服務(wù)細(xì)節(jié),統(tǒng)一對(duì)外暴露服務(wù)接口,真正做到了“微服務(wù)”。比如我們的一個(gè)服務(wù) A,部署了 3 個(gè)副本,也就是 3 個(gè) Pod; 對(duì)于用戶來說,只需要關(guān)注一個(gè) Service 的入口就可以,而不需要操心究竟應(yīng)該請(qǐng)求哪一個(gè) Pod。
優(yōu)勢(shì)非常明顯:一方面外部用戶不需要感知因?yàn)?Pod 上服務(wù)的意外崩潰、K8S 重新拉起 Pod 而造成的 IP 變更, 外部用戶也不需要感知因升級(jí)、變更服務(wù)帶來的 Pod 替換而造成的 IP 變化。
●Ingress
Service 主要負(fù)責(zé) K8S 集群內(nèi)部的網(wǎng)絡(luò)拓?fù)?,那么集群外部怎么訪問集群內(nèi)部呢?這個(gè)時(shí)候就需要 Ingress 了。Ingress 是整個(gè) K8S 集群的接入層,負(fù)責(zé)集群內(nèi)外通訊。
Ingress 是 K8S 集群里工作在 OSI 網(wǎng)絡(luò)參考模型下,第7層的應(yīng)用,對(duì)外暴露的接囗,典型的訪問方式是 http/https。
Service 只能進(jìn)行第四層的流量調(diào)度,表現(xiàn)形式是 ip+port。Ingress 則可以調(diào)度不同業(yè)務(wù)域、不同URL訪問路徑的業(yè)務(wù)流量。
比如:客戶端請(qǐng)求 http://www.kgc.com:port ?---> Ingress ---> Service ---> Pod
●Name
由于 K8S 內(nèi)部,使用 “資源” 來定義每一種邏輯概念(功能),所以每種 “資源”,都應(yīng)該有自己的 “名稱”。
“資源” 有 api 版本(apiversion)、類別(kind)、元數(shù)據(jù)(metadata)、定義清單(spec)、狀態(tài)(status)等配置信息。
“名稱” 通常定義在 “資源” 的 “元數(shù)據(jù)” 信息里。在同一個(gè) namespace 空間中必須是唯一的。
●Namespace
隨著項(xiàng)目增多、人員增加、集群規(guī)模的擴(kuò)大,需要一種能夠邏輯上隔離 K8S 內(nèi)各種 “資源” 的方法,這就是 Namespace。
Namespace 是為了把一個(gè) K8S 集群劃分為若干個(gè)資源不可共享的虛擬集群組而誕生的。
不同 Namespace 內(nèi)的 “資源” 名稱可以相同,相同 Namespace 內(nèi)的同種 “資源”,“名稱” 不能相同。
合理的使用 K8S 的 Namespace,可以使得集群管理員能夠更好的對(duì)交付到 K8S 里的服務(wù)進(jìn)行分類管理和瀏覽。
K8S 里默認(rèn)存在的 Namespace 有:default、kube-system、kube-public 等。
查詢 K8S 里特定 “資源” 要帶上相應(yīng)的 Namespace。
常見的K8S按照部署方式
●Minikube
Minikube是一個(gè)工具,可以在本地快速運(yùn)行一個(gè)單節(jié)點(diǎn)微型K8S,僅用于學(xué)習(xí)、預(yù)覽K8S的一些特性使用。
部署地址:https://kubernetes.io/docs/setup/minikube
●Kubeadmin
Kubeadmin也是一個(gè)工具,提供kubeadm init和kubeadm join,用于快速部署K8S集群,相對(duì)簡單。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
●二進(jìn)制安裝部署
生產(chǎn)首選,從官方下載發(fā)行版的二進(jìn)制包,手動(dòng)部署每個(gè)組件和自簽TLS證書,組成K8S集群,新手推薦。
https://github.com/kubernetes/kubernetes/releases文章來源:http://www.zghlxwxcb.cn/news/detail-713837.html
小結(jié):Kubeadm降低部署門檻,但屏蔽了很多細(xì)節(jié),遇到問題很難排查。如果想更容易可控,推薦使用二進(jìn)制包部署Kubernetes集群,雖然手動(dòng)部署麻煩點(diǎn),期間可以學(xué)習(xí)很多工作原理,也利于后期維護(hù)。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-713837.html
到了這里,關(guān)于Kubernetes 概述以及Kubernetes 集群架構(gòu)與組件的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!