十分鐘瞭解Kubernetes

##何爲Kubernetes? 最簡單的一句話來歸納Kubernetes。 它就是一套成熟的商用服務編排解決方案。Kubernetes定位在Saas層，重點解決了微服務大規模部署時的服務編排問題。

##Kubernetes組件介紹 瞭解Kubernetes都是從Pod開始的。 Pod是Kubernetes最小的調度單元，因此組件介紹就從Pod開始。Pod是一組容器的集合，這些容器共享IPC，Network和UTS，也就是這些容器相互之間能夠共享進程信息，網絡信息和主機信息。這一組容器相互之間能夠經過Localhost互訪。

Kubernetes其它組件都是圍繞着Pod來工做的。

Pod有時也稱爲實例(或者服務實例)。 當咱們說一個服務存在2個實例時，也就是說這個服務有兩個Pod。

在Kubernetes中能夠單首創建Pod，單獨管理Pod。 但這卻沒法體現出服務編排的優點，例如須要資源利用率動態伸縮，或者對外部提供網絡訪問。 這時Kubernetes就又提供了一些管理Pod的組件。 這些組件適用於不一樣的場景，但本質都是在管理Pod。

如下先介紹DaemonSet、ReplicaSet、StatefulSet和Job這四個組件。

DaemonSet用來保證在集羣中每一個計算節點中都運行指定的Pod。 這個組件一般用來運行監控類和數據採集類的Pod，像定時採集節點資源信息，採集節點容器日誌等等。

ReplicaSet，有時簡稱RS。和它相對應的有RC(新版本中已經剔除了)。此組件用來維護Pod狀態，時刻讓集羣中Pod的狀態知足用戶所指望的狀態。 例如用戶指望運行4組Pod，當集羣中Pod數量大於4或者小於4時，都會動態縮容或擴容來知足4組Pod這樣的狀態。

StatefulSet，專爲解決有狀態應用而推出的組件。 DaemonSet和ReplicaSet都是無狀態的，也就是Pod的啓停和網絡信息都是無序的。 而StatefulSet則會保證Pod的啓停順序和網絡信息與以前是保持一致的。

Job，顧名思義，是運行做業的組件。 使用Job組件會保證Pod至少執行成功一次。 添加這四個組件以後，上面的圖就變成了下面的樣子:

在上面四個組件裏面，ReplicaSet是使用最多的組件，90%的Pod的建立、銷燬都是經過RS來完成的。 但RS在使用上仍是有點不方便，例如Pod p1如今要修改Container A的鏡像版本。 那麼就須要在建立一份新RS，而後經過新RS來建立新的Pod p2。 等p2建立完成以後，在返回來銷燬p1。 這個時候就會同時存在RS1和RS2，當變動很頻繁時，RS的管理就會變成瓶頸。 因此Kubernetes增長了Deployment來管理ReplicaSet， 請注意Deployment是直接管理ReplicaSet的，而ReplicaSet則直接管理Pod。 因此Deployment是間接管理Pod。

經過Deployment，用戶能夠聲明最新的Pod狀態，例如新鏡像版本，新的環境變量，新的數量等等這些狀態信息。 Deployment會經過動態建立和銷燬ReplicaSet來知足用戶所指望的狀態，用戶不須要關心中間過程如何實現(聲明式API就是好)。

所以上面的圖就變成了下面的樣子:

和Deployment相似，Kubernetes也提供了CronJob來動態管理Job，其實就是定時做業。 所以就很少說了。在上圖中再添加一個CronJob。

說到如今，管理Pod基本就聊完了。 此時建立的Pod會有如下特色：

• 每一個Pod都是內網IP。
• Pod銷燬/建立會產生新IP。

那麼如何訪問這些Pod呢？ 訪問分兩類，集羣內訪問和集羣外訪問。 但不管是集羣內訪問仍是集羣外訪問，Pod的變動都不該該對調用方產生干擾。 所以對於調用方來講Pod的IP必需要固定下來。 而Service就應運而生，用來解決這個問題。

Kubernetes能夠爲一組Pod建立一個單獨的Service，這個Service擁有固定的IP，並會將網絡請求轉發到相對應的這組Pod上。通俗來講，Service就是4層LB。 好吧，上面的圖在添加點東西：

Service產生的基本都是內網IP(也能夠產生其它網段IP，但不在極簡史討論範疇)，而且是4層LB。若是要對集羣外開放網絡請求，就須要使用Kubernetes提供的Ingress組件。

Ingress是7層LB，而使用最多的是Nginx Ingress。 這個時候再添加點東西：

從大面上說，幾個大組件都齊了。 下面再說Pod持久化和參數配置的問題。

Pod持久化就須要掛載Volume，經過將數據寫入指定Volume的方式來完成持久化。Kubernetes爲Volume提供了多種實現方式，大致分爲兩類：臨時掛載和永久掛載。第三次請注意： 臨時掛載指的是卷隨着Pod的生命週期而存在，當Pod被刪除時掛載的Volume也會隨之消失。而永久掛載則是真的永久保存。

臨時掛載有EmptyDir和HostPath兩種方式。 永久掛載稱之爲PresistentVolume(PV)。PV是與Pod徹底無關的一種資源，當Pod有持久化需求時，就須要向PV申請所須要的資源，這種資源稱之爲PersistentVolumeClaim(PVC)。

簡單理解，PV就是存儲池，PVC就是向存儲池中申請存儲資源。 在Pod中添加所申請的PVC，Pod產生的數據就能夠寫入到存儲池中了。 上面的圖再增長點東西:

極簡史就剩下最後一部分了：配置文件。 配置文件指的是Kubernetes支持Pod建立時，將指定的配置文件以文件或者環境變量的形式添加到Pod中。在Kubernetes中這類配置文件稱之爲configmap。 既然是配置文件，就免不了會涉及到口令，放入配置文件就很不安全。 Kubernetes爲這類需求單獨提供了secret，其實就是特殊的configmap。 爲啥是特殊，其實就是將口令作了Base64編碼，連加密都不是。。 因此最後這張圖就變成了這樣：

到這裏，極簡史就算聊完了。 Kubernetes裏面的概念不少也很晦澀，做爲入門無法徹底說清，有些地方就淺入淺出了。

實踐出真知，大力出奇跡。 要想掌握好K8s，除了多學，多練，多填坑。好像真沒有其它好途徑。

因此這篇文章就當拋磚引玉，權當業餘交流了。

原文出處：https://www.cnblogs.com/vikings-blog/p/11101159.html