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

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

01 kubernetes是什么？

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

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

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

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

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

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

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

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

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

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

     這些任務(wù)之間的關(guān)系有很多類型，例如，一個(gè)web應(yīng)用和MySQL數(shù)據(jù)庫(kù)之間的關(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ù)都可以通過(guò)鏡像的方式，封裝在不同的容器中，它們之間不相互干涉，擁有各自的資源配置，也可以被集群調(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)系，但是未來(lái)可能出現(xiàn)更多類型的任務(wù)之間的聯(lián)系，這種簡(jiǎn)單的處理依賴關(guān)系的能力，一定會(huì)遇到瓶頸。

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

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

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

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

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

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

    說(shuō)這么多，主要是為了表達(dá)Kubernetes 項(xiàng)目并沒(méi)有像其他項(xiàng)目那樣，為每一個(gè)管理功能創(chuàng)建一個(gè)指令，然后在項(xiàng)目中實(shí)現(xiàn)其中的邏輯。
    相比之下，在 Kubernetes 項(xiàng)目中，我們所推崇的使用方法是：
1、首先，通過(guò)一個(gè)“編排對(duì)象”，比如 Pod、Job、CronJob 等，來(lái)描述你試圖管理的應(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)文章！

最新評(píng)論