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

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

01 kubernetes是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03 一點總結(jié)    

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

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

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

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

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