目錄
- 01 kubernetes是什么？
- 02 kubernetes和Compost+Swarm之間的區別
- 03 一點總結
今天我們看看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)的資料請關注腳本之家其它相關文章！
