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

目錄

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

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

01 kubernetes是什么？

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

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

    對于云廠(chǎng)商來(lái)說(shuō)，如果能夠將用戶(hù)提交上來(lái)的docker鏡像運行在自己平臺的容器環(huán)境中，并很好的管理起來(lái)，那么這個(gè)云平臺就有了商業(yè)價(jià)值。事實(shí)上，也確實(shí)是這么實(shí)現的。

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

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

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

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

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

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

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

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

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

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

02 kubernetes和Compost+Swarm之間的區別

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

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

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

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

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

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

03 一點(diǎn)總結    

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

    具體的內容，我們后續慢慢分析。。。

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

   今天的內容就先到這里了。 

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