一張關係圖讓你理解K8s中的概念，Pod、Service、Job等到底有啥關係

查看原文得到更好閱讀體驗。

剛開始接觸K8s的同窗可能都會以爲有必定的學習難度，撲面而來的各類概念究竟是什麼。好比，如何提供一個服務給別人，我是應該用Pod仍是用Deployment來運行個人應用等，在接下來的文章中，但願可以解答你的這些疑惑。

Kubernetes能夠看作雲原生時代的操做系統，統一管理下層的基礎設施，如計算資源、網絡資源、存儲資源等等。將集羣中存在的各類複雜關係抽象成各類API資源，以統一的方式暴露出各類接口，也便於將來的擴展以及開發團隊根據本身的須要定製。所以，咱們能夠看到在K8s中Docker僅僅是容器運行時的一個實現而已，只要遵照它的約定，其實是能夠替換爲適合的其餘容器技術的。基於這樣的設計思路，理清各類API對象的做用和關係就變得很重要了，只有理解了才能正確地使用K8s，接下來咱們就經過一張關係圖一點點的來講明。

經過Pod終結單容器的蠻荒時代

在接觸K8s以前，大多人首先要接觸到的就是Docker。咱們獲得一個容器的鏡像以後，要把應用運行起來最簡單的方式就是docker run的命令。然而在實際的生產環境中，不多僅靠一個單容器就可以知足。好比，一個Web前端的應用，可能還得依賴後端的一個容器服務；後端的容器可能須要數據庫服務；後端的服務須要多副本等等場景。在這些假想的場景中，比較真實的需求就是這些容器應用須要共享同一個網絡棧，同一個存儲卷等，還有它們的生命週期如何管理調度。這個時候，僅僅依靠容器沒法解決這個問題，咱們第一個選手Pod就閃亮登場了。

Pod 內共享配置

有了Pod以後，同一個Pod內的容器能夠共享不少信息，也可能須要讀取同一份配置。好比Pod內有兩個容器須要訪問同一個數據庫，那麼咱們能夠把相關的配置信息寫到ConfigMap裏。那若是還有一些比較敏感的信息的話，就須要放到Secret對象中，它實際上是一個保存在 Etcd 裏的鍵值對數據。這樣，你把 Credential 信息以 Secret 的方式存在 Etcd 裏，Kubernetes 就會在你指定的 Pod（好比，Web 應用的 Pod）啓動時，自動把 Secret 裏的數據以 Volume 的方式掛載到容器裏。

任務和定時任務

有了Pod以後，事情就變得更清晰了。在集羣內，咱們可能會有多種形式的要求。好比，咱們可能但願一個應用天天固定時間運行或者只容許運行一次，可能但願某個應用以守護進程的方式運行。在K8s裏，天然也有方案來解決這些問題。
首先來看定時任務的需求，假設個人系統內有一個全網信息排行榜展現，要求天天須要在凌晨0點的時候更新一次。這個需求在K8s裏就能夠用CronJob來搞定。而若是僅僅須要執行一次的任務，那就直接使用Job對象就能夠了。

默默工做的DaemonSet

再接下來，可能須要以守護進程的方式運行一個應用。好比，我想要在後臺進行日誌的收集。這個時候DaemonSet就派上了用場，它會保證在全部的目標節點上運行一個Pod的副本。在這期間，若是有新的Node加入到K8s集羣中的話，它也會自動完成調度，在新的機器上運行一個Pod副本。所以，前面說的監控、日誌等任務很適合用DaemonSet的方式執

Deployment管理Pod

說完DaemonSet，下一個重點Deployment來了。前面說過容器之間的關聯關係、共享資源等問題須要處理，從而引入了Pod。對於Pod，也是一樣的問題須要解決，只不太高了一個抽象層次罷了。由於面臨Pod的生命週期管理、調度、多副本等問題須要解決，聰明的設計者引入了Deployment。它能夠根據咱們的需求（好比經過標籤）將Pod調度到目標機器上，調度完成以後，它還會繼續幫咱們繼續監控容器是否在正確運行，一旦出現問題，會馬上告訴咱們Pod的運行不正常以及尋找可能的解決方案，好比目標節點不可用的時候它能夠快速地調度到別的機器上去。另外，若是須要對應用擴容提高響應能力的時候，經過Deployment能夠快速地進行擴展。

在實際的工做中，Deployment並非直接控制着Pod的，中間實際上還有一個ReplicaSet，可是在這裏爲了簡化理解過程，能夠先忽略。

提供容器服務

前面的內容主要是圍繞着Pod自身的運行調度管理，下面面臨的問題是解決如何將服務提供給第三方的問題。

• 對內提供服務

首先要解決的是將服務提供給同一個集羣內的其餘服務使用。可能剛入門的同窗會問爲何咱們不能直接使用Pod的IP呢？緣由是這樣，前面也說過Pod是會被管理調度的，可能被調度到不一樣的機器上，同時生命週期也可能會發生變化。這致使一個應用的IP可能會隨時發生變化，那麼直接使用Pod的IP天然是不合理的。
針對這個問題K8s提供了Service對象來解決。

可是，並非說Service就有一個固定的IP。並且，它和Pod IP還有很不同的地方。Pod的網絡是K8s在物理機上創建了一層Overlay Network實現的，並且在網卡上可以看到這個網絡的地址。可是Service是一個徹底虛擬的網絡層，並不會存在於任何網絡設備上。它經過修改集羣內部的路由規則，僅對集羣內部有效。Deploment建立好應用以後，再爲它生成一個Service對象。接下來就能夠經過Service的域名訪問到服務，形式是<Service Name>.<NameSpace>，好比你有爲Deployment的應用建立了一個名爲portal的Service在默認的命名空間，那麼集羣內想要經過Http訪問這個應用，就可使用http://portal.default。這個域名僅在集羣內有效，由於是內部的一個DNS負責解析。

• 對外提供服務

說完如何給內部提供服務之後，剩下的就是如何給外部提供服務了。在K8s裏把這個叫作Ingress，正如其名，它是集羣的入口。好比咱們的集羣Web應用想要讓用戶可以訪問，那必然要在Ingress入口上增長一條解析記錄。這一點，熟悉像Nginx的朋友應該比較容易理解，事實上Nginx Ingress也是K8s生態中的一個成員。

關於Ingress的使用，在以前我曾寫過一篇使用Traefik做爲Ingress的文章，咱們能夠經過Traefik實現爲須要暴露的服務提供負載均衡、自動簽發Https證書、限流等不少功能，若是有興趣能夠點擊查看。