主頁 > 知識(shí)庫 > 云原生技術(shù)kubernetes(K8S)簡(jiǎn)介

云原生技術(shù)kubernetes(K8S)簡(jiǎn)介

熱門標(biāo)簽:400電話辦理介紹信 10086外包用的什么外呼系統(tǒng) 上海申請(qǐng)高400開頭的電話 打400電話怎么辦理收費(fèi) 福州企業(yè)電銷機(jī)器人排名 河南防封號(hào)電銷機(jī)器人是什么 宿城區(qū)電話機(jī)器人找哪家 怎么找到?jīng)]有地圖標(biāo)注的店 麗江真人語音電話外呼系統(tǒng)

    今天我們看看kubernetes技術(shù)的介紹,最近在極客時(shí)間上看張磊老師的深入kubernetes技術(shù),講的非常好,有興趣的同學(xué)可以去收聽一下,對(duì)于理解kubernetes技術(shù)非常有幫助,這里我會(huì)按照自己的進(jìn)度,分享一下學(xué)習(xí)的筆記。

    今天站的角度比較高,概念性質(zhì)的東西會(huì)多一點(diǎn)。

01 kubernetes是什么?

    曾經(jīng)我認(rèn)為這個(gè)問題很好回答,直到不斷的去理解kubernetes,不斷的深入之后,我發(fā)現(xiàn)這個(gè)問題很難回答的全面。

     要想搞明白這個(gè)問題,首先你得知道容器是什么?在前面的文章中,我們說過,容器是一個(gè)特殊的進(jìn)程,實(shí)際上是由Namespace、Cgroup、以及rootfs三種技術(shù)構(gòu)建出來的一種特殊的進(jìn)程的隔離環(huán)境。 這個(gè)隔離環(huán)境最主要的目的,是要運(yùn)行我們自己的應(yīng)用程序。

    對(duì)于云廠商來說,如果能夠?qū)⒂脩籼峤簧蟻淼膁ocker鏡像運(yùn)行在自己平臺(tái)的容器環(huán)境中,并很好的管理起來,那么這個(gè)云平臺(tái)就有了商業(yè)價(jià)值。事實(shí)上,也確實(shí)是這么實(shí)現(xiàn)的。

    然而,想要得到用戶的認(rèn)可,絕不僅僅是支持一個(gè)容器、一個(gè)用戶的docker鏡像,更多的是支持無數(shù)開發(fā)者,龐大的容器集群,才能讓你的平臺(tái)得到云原生整個(gè)生態(tài)的認(rèn)可?;谶@個(gè)現(xiàn)實(shí)情況,不難發(fā)現(xiàn),誰能夠更好的組織、調(diào)度、編排、規(guī)范化管理容器集群,誰就能夠得到容器領(lǐng)域的青睞。

    這里面,我標(biāo)紅了2個(gè)詞語,分別是調(diào)度和編排,對(duì)這兩個(gè)詞語,有必要解釋一下:

調(diào)度:把一個(gè)容器,按照某種規(guī)則,放置在某個(gè)最佳節(jié)點(diǎn)上運(yùn)行起來

編排:按照用戶的意愿和整個(gè)系統(tǒng)的規(guī)則,完全自動(dòng)化地處理好容器之間的各種關(guān)系

    在這樣的背景下面,docker公司原生的Compose+Swarm組合、以及google公司的kubernetes項(xiàng)目應(yīng)運(yùn)而生。為什么kubernetes最終勝出?我們慢慢來看。

    Kubernetes項(xiàng)目的理論基礎(chǔ)要比工程實(shí)踐走得更靠前,kubernetes項(xiàng)目起源于Borg,一個(gè)Google公司基礎(chǔ)設(shè)施的核心系統(tǒng),相比于其他的容器編排項(xiàng)目,它體現(xiàn)出了一系列的"先進(jìn)性"和"完備性",而這些特性,成為了kubernetes項(xiàng)目賴以生存的核心價(jià)值。

    kubernetes的問世,解決了容器的編排、調(diào)度和集群管理中的瓶頸,它解決了用戶一個(gè)痛點(diǎn)問題:我有一個(gè)應(yīng)用程序的容器鏡像,請(qǐng)幫我在一個(gè)集群上將這個(gè)應(yīng)用程序運(yùn)行起來。然而,這并不足以讓它替代Compose+Swarm的架構(gòu),因?yàn)閐ocker公司原生的Compose+Swarm架構(gòu)也能夠解決容器的運(yùn)行和基本的運(yùn)維管理功能。

    kubernetes更有價(jià)值的地方在于,它從一開始,就不是圍繞docker這個(gè)特定的容器去設(shè)計(jì)的,它將docker僅僅看成是底層的一個(gè)容器實(shí)現(xiàn),它著重解決的問題是:運(yùn)行在大規(guī)模的任務(wù)之間,實(shí)際上存在著各種各樣的關(guān)系,這些關(guān)系的處理,才是任務(wù)編排和系統(tǒng)管理最困難的地方。

     這些任務(wù)之間的關(guān)系有很多類型,例如,一個(gè)web應(yīng)用和MySQL數(shù)據(jù)庫之間的關(guān)系、一個(gè)負(fù)載proxy和后端服務(wù)之間的關(guān)系等等。

    傳統(tǒng)的虛擬機(jī)處理這種類型的任務(wù),通常情況是將它們部署在一起,因?yàn)楦鱾€(gè)任務(wù)之間會(huì)有tcp或者h(yuǎn)ttp的請(qǐng)求發(fā)生。但是容器技術(shù)出現(xiàn)之后,各個(gè)任務(wù)都可以通過鏡像的方式,封裝在不同的容器中,它們之間不相互干涉,擁有各自的資源配置,也可以被集群調(diào)度在不同的機(jī)器上。如下:

02 kubernetes和Compost+Swarm之間的區(qū)別

    這種任務(wù)之間的關(guān)系處理,也是kubernetes項(xiàng)目區(qū)別于Compost+Swarm架構(gòu)最明顯的地方。

   以web應(yīng)用和MySQL這兩個(gè)服務(wù)為例,在Compost+Swarm架構(gòu)中,會(huì)為這兩個(gè)服務(wù)中間定義一個(gè)"link",Docker項(xiàng)目會(huì)負(fù)責(zé)維護(hù)這個(gè)"link"。Docker會(huì)在這個(gè)web應(yīng)用的容器中,將DB容器的IP、port以環(huán)境變量的方法給注入進(jìn)去,供應(yīng)用進(jìn)程使用,當(dāng)DB容器的連接信息發(fā)生變化的時(shí)候,更新環(huán)境變量。

    Compost+Swarm這種設(shè)計(jì)模式,可以比較好的支持web應(yīng)用和MySQL的服務(wù)之間聯(lián)系,但是未來可能出現(xiàn)更多類型的任務(wù)之間的聯(lián)系,這種簡(jiǎn)單的處理依賴關(guān)系的能力,一定會(huì)遇到瓶頸。

    Kubernetes 項(xiàng)目最主要的設(shè)計(jì)思想是:從更宏觀的角度,以統(tǒng)一的方式來定義任務(wù)之間的各種關(guān)系,并且為將來支持更多種類的關(guān)系留有余地。

    例如,Kubernetes為容器之間的相互調(diào)用進(jìn)行了分類,來區(qū)分哪些交互式頻繁的tcp交互,哪些交互僅僅是磁盤文件的交互等等。對(duì)于這些需要交互的任務(wù),常規(guī)的做法是各種任務(wù)部署在同一臺(tái)機(jī)器上,通過Localhost進(jìn)行通信,而Kubernetes引入Service的概念,讓兩個(gè)本來互相依賴的服務(wù),甚至可以部署在不同的機(jī)器上。每一個(gè)Service的背后,都是若干個(gè)Pod,Service的作用就是為Pod提供固定的代理入口,而Pod的分布,完全是隨機(jī)的。

   這樣,對(duì)于 Web 應(yīng)用的 Pod 來說,它需要關(guān)心的就是數(shù)據(jù)庫 Pod 的 Service 信息。不難想象,Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自動(dòng)更新、維護(hù),則是 Kubernetes 項(xiàng)目的職責(zé)。

03 一點(diǎn)總結(jié)    

   今天我們從容器這個(gè)最基礎(chǔ)的概念出發(fā),提出了k8s產(chǎn)生的背景,又通過web應(yīng)用和MySQL服務(wù)之間的“緊密協(xié)作”關(guān)系,擴(kuò)展到了 Pod,有了 Pod 之后,我們希望能一次啟動(dòng)多個(gè)應(yīng)用的實(shí)例,這樣就需要Deployment 這個(gè) Pod 的多實(shí)例管理器(后面會(huì)講到);而有了這樣一組相同的 Pod 后,我們又需要通過一個(gè)固定的 IP 地址和端口以負(fù)載均衡的方式訪問它,于是就有了 Service,如果web應(yīng)用訪問MySQL需要賬號(hào)密碼,我們又會(huì)引出Secret......最終,你會(huì)看到下面的一張圖:

    具體的內(nèi)容,我們后續(xù)慢慢分析。。。

    說這么多,主要是為了表達(dá)Kubernetes 項(xiàng)目并沒有像其他項(xiàng)目那樣,為每一個(gè)管理功能創(chuàng)建一個(gè)指令,然后在項(xiàng)目中實(shí)現(xiàn)其中的邏輯。
    相比之下,在 Kubernetes 項(xiàng)目中,我們所推崇的使用方法是:
1、首先,通過一個(gè)“編排對(duì)象”,比如 Pod、Job、CronJob 等,來描述你試圖管理的應(yīng)用;
2、然后,再為它定義一些“服務(wù)對(duì)象”,比如 Service、Secret、Horizontal Pod Autoscaler(自
動(dòng)水平擴(kuò)展器)等。這些對(duì)象,會(huì)負(fù)責(zé)具體的平臺(tái)級(jí)功能。
這種使用方法,就是所謂的“聲明式 API”。這種 API 對(duì)應(yīng)的“編排對(duì)象”和“服務(wù)對(duì)象”,都是Kubernetes 項(xiàng)目中的 API 對(duì)象(API Object)。
這就是 Kubernetes 最核心的設(shè)計(jì)理念。

   今天的內(nèi)容就先到這里了。 

以上就是云原生技術(shù)kubernetes(K8S)簡(jiǎn)介的詳細(xì)內(nèi)容,更多關(guān)于云原生技術(shù) kubernetes(K8S)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!

標(biāo)簽:遵義 面試通知 運(yùn)城 荊門 雞西 朝陽 隴南 連云港

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《云原生技術(shù)kubernetes(K8S)簡(jiǎn)介》,本文關(guān)鍵詞  云,原生,技術(shù),kubernetes,K8S,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《云原生技術(shù)kubernetes(K8S)簡(jiǎn)介》相關(guān)的同類信息!
  • 本頁收集關(guān)于云原生技術(shù)kubernetes(K8S)簡(jiǎn)介的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章