原創 | k8s系列教程一：開篇

作者：潘吉祥

歡迎加入k8s學習系列教程，在接下來的系列文章，你將可以在較短的時間內達到入門k8s的效果。

k8s是什麼

Kubernetes(K8S)作爲Google在2014年發佈的一個開源項目，直到發展如今的地步，最大的原因離不開docker容器化的發展，而docker的如火如荼正是受益於微服務架構的推動。

因此k8s也是微服務架構發展的產物，那它到底是幹什麼的呢？

官方化的解釋：“Kubernetes是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，它的目標是讓部署容器化的應用簡單並且高效,並提供了應用部署，規劃，更新，維護的一種機制。”

去掉冗長的修飾定語“kubernetes（以下簡稱k8s）是一種管理容器的應用”，以前也聽人這樣說過：“就是統一管理docker的平臺”。

雖然這寫說法本質沒錯，但是對於初學者來說可能會顯得kubernetes作用不是那麼大，因爲這裏的管理隱形囊括的東西太多了，包括容器伸縮、部署回滾、存儲編排、自我修復、服務發現和負載均衡、權限管理等功能。

仔細觀察其實可以發現，最前面的定義可能是相對於k8s開發初衷而言的，隨着後續的發展，它所承擔的任務已經遠不止此了。拋開管理容器，k8s在功能上實現了微服務框架部分功能，因此，在這裏我以個人的理解來進行解釋：它是一個基於容器的微服務構建平臺。

K8s爲我們帶來什麼

Kubernetes作爲一個基於容器完備的微服務構建平臺（完善的集羣管理能力），可以在物理機或虛擬機的Kubernetes集羣上運行容器化應用，並提供一個以容器爲中心的基礎架構，滿足在生產環境中運行應用的一些常見需求：

多進程協同工作
應用實例擴容縮容
服務負載均衡
應用健康檢查
平滑版本更新
服務調度
認證授權管理
……

總之k8s能夠幫助我們更加方便快速地開發複雜的微服務系統；它的設計理念（pod）全面擁抱微服務，擁有優秀的動態服務調整能力；而就k8s平臺本身，基於master和worker的架構模式，也擁有極強的橫向擴展能力。

Springcloud VS k8s

上面解釋道k8s是一個基於容器的微服務構建平臺，那麼和我們當下火熱的springcloud有什麼區別或者說對比性呢？筆者對於springcloud也學習了一段時間，也蒐集參考了一些網上的資料，下面給出核心參考：

Springcloud和k8s都是微服務架構開發的工具，就流行度而言，目前springcloud成爲現在微服務開發的主流選擇，k8s處於相對輔助的位置。因爲springcloud的核心Netflix系列組件在開發之初docker還未出現。

就開發而言，springcloud的方式更早一些，雖然隨着servermash理論的廣泛傳播，對k8s這類管理平臺發展起到助推作用，但當下springcloud依然是該理論事實上的標杆。

從開發層級來說，springcloud將微服務問題的解決方案融合到了業務邏輯層面，有過相關學習或開發經驗的讀者應該知道，通常以Java代碼註解的形式嵌入主體代碼中。因此springcloud可以說是入侵性較強的，它散佈在開發的微服務代碼中。

而k8s則不同，k8s將解決方案抽離，從業務代碼層面下沉到容器軟件層面（如下圖所示），這樣來說，開發人員在開發階段只需關注業務實現即可，而不需要考慮微服務的衍生問題，甚至沒有感知，比如服務註冊和發現、負載均衡和高可用等。從而實現微服務架構中“微服務”和“架構”的分離，各司其職。

儘管這樣比較美好地說，但事實上k8s目前並不能完全取代springcloud，可取的選擇是二者共同使用，我們可以根據實際情況將服務的註冊發現、負載均衡、配置中心等使用k8s代替，其它方面依然沿用springcloud。

但是就發展而言，k8s相對是一個更好的微服務架構方案，尤其是隨着支持k8s相關servermash產品的出現，比如istio，它可以提供諸如服務接口調用、驗證授權、流量控制、服務跟蹤治理等相關功能，在更大程度上使得替代springcloud成爲可能。另外springcloud面向Java的短板也沒有迎合微服務的語言無關性，在筆者看來，被k8s取代只是時間問題。

需要說明的是，k8s是基於docker（或者說實現了容器類似標準的產品）的，因此，在學習系列教程之前，還請對docker有一定的瞭解。（也可以參考前幾期的docker入門哦）

我們在下期正式進入kubernetes的實戰學習！關注不迷路呦！