雲原生技術kubernetes(K8S)簡介

    今天我們看看kubernetes技術的介紹,最近在極客時間上看張磊老師的深入kubernetes技術,講的非常好,有興趣的同學可以去收聽一下,對於理解kubernetes技術非常有幫助,這裡我會按照自己的進度,分享一下學習的筆記。

    今天站的角度比較高,概念性質的東西會多一點。

01 kubernetes是什麼?

    曾經我認為這個問題很好回答,直到不斷的去理解kubernetes,不斷的深入之後,我發現這個問題很難回答的全面。

     要想搞明白這個問題,首先你得知道容器是什麼?在前面的文章中,我們說過,容器是一個特殊的進程,實際上是由Namespace、Cgroup、以及rootfs三種技術構建出來的一種特殊的進程的隔離環境。 這個隔離環境最主要的目的,是要運行我們自己的應用程序。

    對於雲廠商來說,如果能夠將用戶提交上來的docker鏡像運行在自己平臺的容器環境中,並很好的管理起來,那麼這個雲平臺就有瞭商業價值。事實上,也確實是這麼實現的。

    然而,想要得到用戶的認可,絕不僅僅是支持一個容器、一個用戶的docker鏡像,更多的是支持無數開發者,龐大的容器集群,才能讓你的平臺得到雲原生整個生態的認可。基於這個現實情況,不難發現,誰能夠更好的組織、調度、編排、規范化管理容器集群,誰就能夠得到容器領域的青睞。

    這裡面,我標紅瞭2個詞語,分別是調度和編排,對這兩個詞語,有必要解釋一下:

調度:把一個容器,按照某種規則,放置在某個最佳節點上運行起來

編排:按照用戶的意願和整個系統的規則,完全自動化地處理好容器之間的各種關系

    在這樣的背景下面,docker公司原生的Compose+Swarm組合、以及google公司的kubernetes項目應運而生。為什麼kubernetes最終勝出?我們慢慢來看。

    Kubernetes項目的理論基礎要比工程實踐走得更靠前,kubernetes項目起源於Borg,一個Google公司基礎設施的核心系統,相比於其他的容器編排項目,它體現出瞭一系列的”先進性”和”完備性”,而這些特性,成為瞭kubernetes項目賴以生存的核心價值。

    kubernetes的問世,解決瞭容器的編排、調度和集群管理中的瓶頸,它解決瞭用戶一個痛點問題:我有一個應用程序的容器鏡像,請幫我在一個集群上將這個應用程序運行起來。然而,這並不足以讓它替代Compose+Swarm的架構,因為docker公司原生的Compose+Swarm架構也能夠解決容器的運行和基本的運維管理功能。

    kubernetes更有價值的地方在於,它從一開始,就不是圍繞docker這個特定的容器去設計的,它將docker僅僅看成是底層的一個容器實現,它著重解決的問題是:運行在大規模的任務之間,實際上存在著各種各樣的關系,這些關系的處理,才是任務編排和系統管理最困難的地方。

     這些任務之間的關系有很多類型,例如,一個web應用和MySQL數據庫之間的關系、一個負載proxy和後端服務之間的關系等等。

    傳統的虛擬機處理這種類型的任務,通常情況是將它們部署在一起,因為各個任務之間會有tcp或者http的請求發生。但是容器技術出現之後,各個任務都可以通過鏡像的方式,封裝在不同的容器中,它們之間不相互幹涉,擁有各自的資源配置,也可以被集群調度在不同的機器上。如下:

02 kubernetes和Compost+Swarm之間的區別

    這種任務之間的關系處理,也是kubernetes項目區別於Compost+Swarm架構最明顯的地方。

   以web應用和MySQL這兩個服務為例,在Compost+Swarm架構中,會為這兩個服務中間定義一個”link”,Docker項目會負責維護這個”link”。Docker會在這個web應用的容器中,將DB容器的IP、port以環境變量的方法給註入進去,供應用進程使用,當DB容器的連接信息發生變化的時候,更新環境變量。

    Compost+Swarm這種設計模式,可以比較好的支持web應用和MySQL的服務之間聯系,但是未來可能出現更多類型的任務之間的聯系,這種簡單的處理依賴關系的能力,一定會遇到瓶頸。

    Kubernetes 項目最主要的設計思想是:從更宏觀的角度,以統一的方式來定義任務之間的各種關系,並且為將來支持更多種類的關系留有餘地。

    例如,Kubernetes為容器之間的相互調用進行瞭分類,來區分哪些交互式頻繁的tcp交互,哪些交互僅僅是磁盤文件的交互等等。對於這些需要交互的任務,常規的做法是各種任務部署在同一臺機器上,通過Localhost進行通信,而Kubernetes引入Service的概念,讓兩個本來互相依賴的服務,甚至可以部署在不同的機器上。每一個Service的背後,都是若幹個Pod,Service的作用就是為Pod提供固定的代理入口,而Pod的分佈,完全是隨機的。

   這樣,對於 Web 應用的 Pod 來說,它需要關心的就是數據庫 Pod 的 Service 信息。不難想象,Service 後端真正代理的 Pod 的 IP 地址、端口等信息的自動更新、維護,則是 Kubernetes 項目的職責。

03 一點總結    

   今天我們從容器這個最基礎的概念出發,提出瞭k8s產生的背景,又通過web應用和MySQL服務之間的“緊密協作”關系,擴展到瞭 Pod,有瞭 Pod 之後,我們希望能一次啟動多個應用的實例,這樣就需要Deployment 這個 Pod 的多實例管理器(後面會講到);而有瞭這樣一組相同的 Pod 後,我們又需要通過一個固定的 IP 地址和端口以負載均衡的方式訪問它,於是就有瞭 Service,如果web應用訪問MySQL需要賬號密碼,我們又會引出Secret……最終,你會看到下面的一張圖:

    具體的內容,我們後續慢慢分析。。。

    說這麼多,主要是為瞭表達Kubernetes 項目並沒有像其他項目那樣,為每一個管理功能創建一個指令,然後在項目中實現其中的邏輯。
    相比之下,在 Kubernetes 項目中,我們所推崇的使用方法是:
1、首先,通過一個“編排對象”,比如 Pod、Job、CronJob 等,來描述你試圖管理的應用;
2、然後,再為它定義一些“服務對象”,比如 Service、Secret、Horizontal Pod Autoscaler(自
動水平擴展器)等。這些對象,會負責具體的平臺級功能。
這種使用方法,就是所謂的“聲明式 API”。這種 API 對應的“編排對象”和“服務對象”,都是Kubernetes 項目中的 API 對象(API Object)。
這就是 Kubernetes 最核心的設計理念。

   今天的內容就先到這裡瞭。 

以上就是雲原生技術kubernetes(K8S)簡介的詳細內容,更多關於雲原生技術 kubernetes(K8S)的資料請關註WalkonNet其它相關文章!

推薦閱讀:

    None Found