Kubernetes已經迅速成為在雲中部署和管理軟體的新的標準。儘管KUbernetes實力強勁，Kubernetes的學習曲線卻相對而言更陡峭。對於一個初學者，想要從官方檔案[1]中深入瞭解Kubernetes會非常困難。Kubernetes由很多不同的部分組成，因此很難說清楚哪些是和你的需求有關。這篇部落格將會嘗試提供一個Kubernetes的簡化檢視，並且嘗試對重要的元件進行High-level的描述，以及它們是如何在一起工作的。
Node是Kubernetes中硬體的最小單元。它代表叢集當中的一個單臺主機。在大部分的生產系統中，Node既可以是你資料中心中的一個物理主機也可以是託管在雲平臺（如Google Cloud Platform）中的虛擬主機。當然你也不必限制於這些當中，從理論上講，你可以將任何東西作為Node，比如一個智慧手錶，或者樹莓派。
把主機抽象成一個Node可以允許我們定義一個抽象層。從而可以不用擔心單個主機的獨立特性，我們可以簡單的將每一個主機視為一組可以利用的CPU和RAM資源。這樣Kubernetes叢集中的任何一個主機都是可以替換的。
雖然在單個節點上處理任務也是可行的，但這並不是Kubernetes的風格。一般來說，你應該考慮整個叢集的狀態，而不是其中的某一個節點。
在Kubernetes中，將所有Node的資源集中在一起，從而形成了一臺更加強大的“伺服器”。 當你將你的應用部署到叢集當中時，它可以自動的為你選擇工作Node。如果有新的Node加入或者被移除，叢集會自動將應用轉移。對於應用程式或者程式員而言，程式碼到底執行在哪一個節點上顯得並不重要。
這種類似於hivemind的系統可能讓你聯想到星際迷航中的Brog[2]，當然並不是隻有你一個人會這麼想，“Borg”也正是一個Google內部專案的名字，而Kubernetes正是在此專案基礎上構建的。
由於在Kubernetes當中並不保證應用程式執行在叢集中的特定節點上，因此資料不能直接儲存到主機的檔案系統上。如果應用程式把資料儲存到檔案系統中，而應用又被排程到其它節點上，那應用就無法找到想要的資料檔案。因此對於傳統的在每個節點上的本地儲存應該被視為應用程式的臨時快取，而不應該在本地儲存任何需要持久化的資料。
為了儲存資料，Kubernetes使用持久捲（Persistent Volumes）。儘管叢集中所有節點的CPU和RAM都是有叢集進行集中管理的，但是持久化檔案儲存並不是。相反，可以將本地或者雲儲存連結到叢集當中。可以理解為將一個外部的硬碟插入到了叢集這個“伺服器”中。持久捲提供了一個檔案系統，這個檔案系統可以掛在到叢集當中，而不需要關聯任何特定的節點。
執行在Kubernetes中的應用程式需要使用Linux containers進行打包。容器是一個廣泛接受的標準，這裡也已經有很多的已構建的映象可以直接部署到Kubernetes當中。
容器化允許你建立一個包含Linux執行環境的獨立空間。任何應用程式以及其依賴都可以被打包到一個檔案中，並且在網際網路上共享。任何人都可以下載容器並且透過極少的配置就可以將其部署到基礎設施上。建立容器的過程也可以透過程式設計來實現，從而可以形成一個強大的CI/CD流水線。
雖然我們可以將多個應用程式打包到一個容器當中，但是對於你而言，最好還是盡可能保持一個容器中只包含一個單獨的行程。相比於在一個容器包含多個行程而言，將這些行程拆分到不同的容器當中，可以讓每個容器更加內聚，並且更易於更新和部署。同時在出問題時也更容易定位。
不同於你過去使用過的其它系統，Kubernetes並不直接執行容器，取而代之的是使用了一個high-level的抽象來包裝一個或者多個容器，這個抽象被稱為Pod[3]。在Pod中的任何容器都共享了容器名稱空間以及本地網路。因此在Pod的容器直接可以非常方便的進行通訊，就好像它們是執行在同一個機器上一樣，同時彼此之間又保持隔離。
Pod同時也是Kubernetes中的最小排程單元。 如果你的應用程式設計非常受歡迎，單個Pod無法處理這樣的負載。Kubernetes可以在必要時建立並部署一個新的副本。即使在非高負載的情況下，在生成環境中執行多個Pod的副本可以有效的均衡負載並且避免故障的發生。
Pod中可以包含多個容器，但是你還是應該盡可能的限制一下。因為Pod是作為一個最小單元，整體進行伸縮。這可能導致資源的浪費以及更多的費用開銷。為了避免這種問題。Pod應該盡可能的保持“小”，通常指應該包含一個主行程，以及與其緊密合作的輔助容器（這些輔助容器通常被稱為Sidecar）。
雖然Pod是Kubernetes中的一個最小單元，但是通常我們並不在叢集中直接部署一個Pod。相反，Pod通常應該被另外一個抽象Deployment[4]進行管理。
一個Deployment最主要的目的是用來宣告需要有多少Pod的副本執行。當Deployment部署到叢集之後，它會自動執行指定數量的Pods，並且對這些Pod進行監控，如果有Pod的副本死掉了，Deployment會自動建立新的實體。
使用Deployment後就不需要手動去管理Pods，你只需要宣告應用期望的狀態，Deployment會自動幫你管理應用。
使用上面的這些概念，你可以建立一個叢集，並且在叢集中透過Deployment來部署和管理Pod。 這裡還有最後一個問題需要解決：如何允許外部流量進入到你的應用程式。
預設情況下，Kubernetes將Pods和外部網路環境進行了隔離。 如果你想要與執行在Pod中的服務進行通訊，那你必須要開啟一個用於通訊的通道，這個通道就是Ingress。
有許多方式可以將Ingress新增到你的叢集當中。最普遍的方式是使用Ingress Controller或者負載均衡器。如果選擇這兩種方式已經超出了本文的範圍，但是你必須意識到，在你嘗試使用Kubernetes之前，你需要處理Ingress入口。
上面的部分介紹的是一個簡化了的Kubernetes版本，但是應該可以給你在開始實驗前必要的一些基礎知識了。你已經瞭解了該系統的各個部分，現在你需要的是使用Kubernetes來部署一個真正的應用程式。 官方的Kubernetes教程[5]是一個很好的開始。
為了在本地試驗Kubernetes，Minikube可以幫助你在本地建立一個虛擬的叢集。而如果你已經開始準備在雲服務中嘗試Kubernetes。 Google Kubenetes Engine包含了一系列的教程[6]可以幫助你快速入門。
如果你是剛開始接觸容器或者Web基礎設施這個領域，我建議你可以先瞭解應用12要素[7]。12要素中描述了當你在設計執行在類似於Kubernetes這樣的平臺上的應用程式時的最佳實踐，這些都是需要時刻記住的東西。
-
https://kubernetes.io/docs/concepts/
-
http://memory-alpha.wikia.com/wiki/Borg
-
https://kubernetes.io/docs/concepts/workloads/pods/pod/
-
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
-
https://kubernetes.io/docs/tutorials/kubernetes-basics/
-
https://cloud.google.com/kubernetes-engine/docs/tutorials/
-
https://12factor.net/
原文連結：https://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16
本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
