圖解 K8s 核心概念和術(shù)語

我第一次接觸容器編排調(diào)度工具是 Docker 自家的 Docker Swarm,主要解決當(dāng)時公司內(nèi)部業(yè)務(wù)項目部署繁瑣的問題鸥昏,我記得當(dāng)時項目實現(xiàn)容器化之后,花在項目部署運維的時間大大減少了涌韩,當(dāng)時覺得這玩意還挺新鮮的盆均,原來自動化運維可以這么玩。后面由于工作原因肩碟,很久沒碰過容器方面的知識了强窖。最近在公司的數(shù)據(jù)同步項目中,需要使用到分布式調(diào)度數(shù)據(jù)同步執(zhí)行單元削祈,目前使用的方案是將數(shù)據(jù)同步執(zhí)行單元打包成鏡像翅溺,使用 K8s 進行調(diào)度,正好趁這個機會了解一下 K8s髓抑,下面我就用圖解的形式將我所理解的 K8s 分享給大家咙崎。

K8s 三大核心功能

K8s 是一個輕便的和可擴展的開源平臺,用于管理容器化應(yīng)用和服務(wù)吨拍。通過 K8s 能夠進行應(yīng)用的自動化部署和擴縮容褪猛。

K8s 是比容器更上一層的架構(gòu),它可以支持多種容器技術(shù)羹饰,比如我們熟悉的 Docker伊滋,K8s 定位是一個容器調(diào)度工具,它主要具備以下三大核心能力:

1队秩、自動調(diào)度

k8s 將用戶部署提交的容器放到 k8s 集群的任意一個節(jié)點中笑旺,k8s 可以根據(jù)容器所需要的資源大小,以及節(jié)點的負載情況來決定容器放在哪個節(jié)點上面馍资。

image

2筒主、自動修復(fù)

當(dāng) k8s 的健康檢查機制發(fā)現(xiàn)某個節(jié)點出現(xiàn)問題,它會自動將該節(jié)點上的資源轉(zhuǎn)移到其它節(jié)點上面完成自動恢復(fù)鸟蟹。

image

3乌妙、橫向自動擴縮容

在 k8s 1.1+ 版本中,有一個功能叫 “ Horizontal Pod Autoscaler”建钥,簡稱 “HPA”藤韵,意思是 Pod自動擴容,它可以預(yù)先定義 Pod 的負載指標(biāo)锦针,當(dāng)達到預(yù)期設(shè)定的負載指標(biāo)后荠察,就會根據(jù)指標(biāo)自動觸發(fā)自動動態(tài)擴容/縮容行為置蜀。

1)橫向自動擴容

image

2)橫向自動縮容

image

節(jié)點

從上面的圖可以看出來,k8s 集群的節(jié)點有兩個角色悉盆,分別為 Master 節(jié)點和 Node 節(jié)點盯荤,整個 K8s 集群Master 和 Node 節(jié)點關(guān)系如下圖所示:

image

1、Master 節(jié)點

Master 節(jié)點也稱為控制節(jié)點焕盟,每個 k8s 集群都有一個 Master 節(jié)點負責(zé)整個集群的管理控制秋秤,我們上面介紹的 k8s 三大能力都是經(jīng)過 Master 節(jié)點發(fā)起的,Master 節(jié)點包含了以下幾個組件:

image
  • API Server:提供了 HTTP Rest 接口的服務(wù)進程脚翘,所有資源對象的增灼卢、刪、改来农、查等操作的唯一入口鞋真;
  • Controller Manager:k8s 集群所有資源對象的自動化控制中心;
  • Scheduler:k8s 集群所有資源對象自動化調(diào)度控制中心沃于;
  • ETCD:k8s 集群注冊服務(wù)發(fā)現(xiàn)中心涩咖,可以保存 k8s 集群中所有資源對象的數(shù)據(jù)。

2繁莹、Node

Node 節(jié)點的作用是承接 Master 分配的工作負載檩互,它主要有以下幾個關(guān)鍵組件:

image
  • kubelet:負責(zé) Pod 對應(yīng)容器的創(chuàng)建、啟停等操作咨演,與 Master 節(jié)點緊密協(xié)作闸昨;
  • kube-porxy:實現(xiàn) k8s 集群通信與負載均衡的組件。

從圖上可看出薄风,在 Node 節(jié)點上面饵较,還需要一個容器運行環(huán)境,如果使用 Docker 技術(shù)棧遭赂,則還需要在 Node 節(jié)點上面安裝 Docker Engine告抄,專門負責(zé)該節(jié)點容器管理工作。

Pod

Pod 是 k8s 最重要而且是最基本的一個資源對象嵌牺,它的結(jié)構(gòu)如下:

image

從以上 Pod 的結(jié)構(gòu)圖可以看出,它其實是容器的一個上層包裝結(jié)構(gòu)龄糊,這也就是為什么 K8s 可以支持多種容器類型的原因逆粹,基于這方面,我理解 k8s 的定位就是一個編排與調(diào)度工具炫惩,而容器只是它調(diào)度的一個資源對象而已僻弹。

Pod 可包含多個容器在里面,每個 Pod 至少會有一個 Pause 容器他嚷,其它用戶定義的容器都共享該 Pause 容器蹋绽,Pause 容器的主要作用是用于定義 Pod 的 ip 和 volume芭毙。

Pod 在 k8s 集群中的位置如下圖所示:

image

Label

Label 在 k8s 中是一個非常核心的概念,我們可以將 Label 指定到對應(yīng)的資源對象中卸耘,例如 Node退敦、Pod、Replica Set蚣抗、Service 等侈百,一個資源可以綁定任意個 Label,k8s 通過 Label 可實現(xiàn)多維度的資源分組管理翰铡,后續(xù)可通過 Label Selector 查詢和篩選擁有某些 Label 的資源對象钝域,例如創(chuàng)建一個 Pod,給定一個 Label锭魔,workerid=123例证,后續(xù)可通過 workerid=123 刪除擁有該標(biāo)簽的 Pod 資源。

image

Replica Set

Replica Set 目的是為了定義一個期望的場景迷捧,比如定義某種 Pod 的副本數(shù)量在任意時刻都處于 Peplica Set 期望的值织咧,假設(shè) Replica Set 定義 Pod 的副本數(shù)目為:replicas=2,當(dāng)該 Replica Set 提交給 Master 后党涕,Master 會定期巡檢該 Pod 在集群中的數(shù)目烦感,如果發(fā)現(xiàn)該 Pod 掛掉了一個,Master 就會嘗試依據(jù) Replica Set 設(shè)置的 Pod 模版創(chuàng)建 Pod膛堤,以維持 Pod 的數(shù)量與 Replica Set 預(yù)期的 Pod 數(shù)量相同手趣。

通過 Replica Set,k8s 集群實現(xiàn)了用戶應(yīng)用的高可用性肥荔,而且大大減少了運維工作量绿渣。因此生產(chǎn)環(huán)境一般用 Deployment 或者 Replica Set 去控制 Pod 的生命周期和期望值,而不是直接單獨創(chuàng)建 Pod燕耿。

image

類似 Replica Set 的還有 Deployment中符,它的內(nèi)部實現(xiàn)也是通過 Replica Set 實現(xiàn)的,可以說 Deployment 是 Replica Set 的升級版誉帅,它們之間的 yaml 配置文件格式大部分都相同淀散。

Service

Service 是 k8s 能夠?qū)崿F(xiàn)微服務(wù)集群的一個非常重要的概念,顧名思義蚜锨,k8s 的 Service 就是我們平時所提及的微服務(wù)架構(gòu)中的“微服務(wù)”档插,本文上面提及的 Pod、Replica Set 等都是為 Service 服務(wù)的資源亚再, 如下圖表示 Service郭膛、Pod、Replica Set 的關(guān)系:

image

從上圖可看出氛悬,Service 定義了一個服務(wù)訪問的入口则剃,客戶端通過這個入口即可訪問服務(wù)背后的應(yīng)用集群實例,而 Service 則是通過 Label Selector 實現(xiàn)關(guān)聯(lián)與對接的棍现,Replica Set 保證服務(wù)集群資源始終處于期望值调煎。

以上只是一個微服務(wù)轴咱,通常來說一個應(yīng)用項目會由多個不同業(yè)務(wù)能力而又彼此獨立的微服務(wù)組成,多個微服務(wù)間組成了一個強大而又高可用的應(yīng)用服務(wù)集群朴肺。

image

Namespace

Namespace 顧名思義是命名空間的意思,在 k8s 中主要用于實現(xiàn)資源隔離的目的戈稿,用戶可根據(jù)不同項目創(chuàng)建不同的 Namespace,通過 k8s 將資源分配到不同 Namespace 中鞍盗,即可實現(xiàn)不同項目的資源隔離:

image

作者簡介

作者張乘輝,擅長消息中間件技能般甲,負責(zé)公司百萬 TPS 級別 Kafka 集群的維護,作者維護的公號「后端進階」不定期分享 Kafka敷存、RocketMQ 系列不講概念直接真刀真槍的實戰(zhàn)總結(jié)以及細節(jié)上的源碼分析;同時作者也是阿里開源分布式事務(wù)框架 Seata Contributor锚烦,因此也會分享關(guān)于 Seata 的相關(guān)知識觅闽;當(dāng)然公號也會分享 WEB 相關(guān)知識比如 Spring 全家桶等。內(nèi)容不一定面面俱到涮俄,但一定讓你感受到作者對于技術(shù)的追求是認真的蛉拙!

公眾號:后端進階

技術(shù)博客:https://objcoding.com/

GitHub:https://github.com/objcoding/

公眾號「后端進階」,專注后端技術(shù)分享彻亲!
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末孕锄,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子苞尝,更是在濱河造成了極大的恐慌硫惕,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,968評論 6 482
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件野来,死亡現(xiàn)場離奇詭異,居然都是意外死亡踪旷,警方通過查閱死者的電腦和手機曼氛,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2 382
  • 文/潘曉璐 我一進店門豁辉,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人舀患,你說我怎么就攤上這事徽级。” “怎么了聊浅?”我有些...
    開封第一講書人閱讀 153,220評論 0 344
  • 文/不壞的土叔 我叫張陵餐抢,是天一觀的道長。 經(jīng)常有香客問我低匙,道長旷痕,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,416評論 1 279
  • 正文 為了忘掉前任顽冶,我火速辦了婚禮欺抗,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘强重。我一直安慰自己绞呈,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 64,425評論 5 374
  • 文/花漫 我一把揭開白布间景。 她就那樣靜靜地躺著佃声,像睡著了一般。 火紅的嫁衣襯著肌膚如雪倘要。 梳的紋絲不亂的頭發(fā)上圾亏,一...
    開封第一講書人閱讀 49,144評論 1 285
  • 那天,我揣著相機與錄音碗誉,去河邊找鬼召嘶。 笑死,一個胖子當(dāng)著我的面吹牛哮缺,可吹牛的內(nèi)容都是我干的弄跌。 我是一名探鬼主播,決...
    沈念sama閱讀 38,432評論 3 401
  • 文/蒼蘭香墨 我猛地睜開眼尝苇,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了糠溜?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,088評論 0 261
  • 序言:老撾萬榮一對情侶失蹤蜕着,失蹤者是張志新(化名)和其女友劉穎承匣,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體嘉抒,經(jīng)...
    沈念sama閱讀 43,586評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡些侍,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,028評論 2 325
  • 正文 我和宋清朗相戀三年政模,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片狈定。...
    茶點故事閱讀 38,137評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡纽什,死狀恐怖躲叼,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情让蕾,我是刑警寧澤,帶...
    沈念sama閱讀 33,783評論 4 324
  • 正文 年R本政府宣布探孝,位于F島的核電站顿颅,受9級特大地震影響足丢,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜绍些,卻給世界環(huán)境...
    茶點故事閱讀 39,343評論 3 307
  • 文/蒙蒙 一胸哥、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦氮帐、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至昂勒,卻和暖如春舟铜,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背谆刨。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1 262
  • 我被黑心中介騙來泰國打工痊夭, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人虹曙。 一個月前我還...
    沈念sama閱讀 45,595評論 2 355
  • 正文 我出身青樓番舆,卻偏偏與公主長得像,于是被迫代替她去往敵國和親疏哗。 傳聞我的和親對象是個殘疾皇子拴事,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,901評論 2 345