雲原生技術kubernetes(K8S)簡介

Posted on by

    今天我們看看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