本節內容提綱：
- Namespace
- Pod
- Controller
- Deployment
- Job
- Service
- ConfigMap
圖1：Kubernetes之log
一、Namespace
Namespace是對一組資源和對象的抽象集合，是將集群資源劃分為多個用途(通過 resource quota)的方法。例如：將系統內部的對象劃分為不同的項目組或用戶組。常見的pods, services, replication controllers和deployments等都是屬於某一個namespace的（默認是default）。不同 Namespace 裡的資源是完全隔離的。Kubernetes 默認創建了兩個 Namespace，分別是default和kube-system。
圖2：namespace
二、Pod
Pod是Kubernetes 的最小工作單元。每個Pod包含一個或多個容器。Pod 中的容器會作為一個整體被Master調度到一個Node上運行。所有的容器都是在pod中被管理，一個或多個容器放在pod裡作為一個管理單元。由一個叫“Pause”的根容器，加上一個或多個用戶自定義的容器組成。
圖3:Pod結構
三、Controller
負責集群內的Node、Pod副本、服務端點（Endpoint）、命名空間（Namespace）、服務賬號（ServiceAccount）、資源定額（ResourceQuota）的管理，當某個Node意外宕機時，Controller Manager會及時發現並執行自動化修復流程，確保集群始終處於預期的工作狀態。Kubernetes 提供了多種以下 Controller：Replication Controller（副本控制器）、Node Controller、ResourceQuota Controller、Namespace Controller、Endpoint Controller和Service Controller等。
四、Deployment
Kubernetes提供了一種更加簡單的更新RC和Pod的機制，叫做Deployment。通過在Deployment中描述你所期望的集群狀態，Deployment Controller會將現在的集群狀態在一個可控的速度下逐步更新成你所期望的集群狀態。Deployment主要職責同樣是為了保證pod的數量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。
五、Job
用於調配pod對象運行一次性任務，容器中的進程在正常運行結束後不會對其進行重啟，而是將pod對象置於completed狀態。若容器中的進程因錯誤而終止，則需要依據配置確定重啟與否，未運行完成的pod對象因其所在的節點故障而意外終止後會被重新調度。從程序的運行形態上來區分，我們可以將Pod分為兩類：長時運行服務（jboss、mysql等）和一次性任務（數據計算、測試）。RC創建的Pod都是長時運行的服務，而Job創建的Pod都是一次性任務。
六、Service
Kubernetes中的核心要素Service提供了一套簡化的服務代理和發現機制，天然適應微服務架構。Kubernetes分配給Service的固定IP是一個虛擬IP，並不是一個真實的IP，在外部是無法尋址的。真實的系統實現上，Kubernetes是通過Kube-proxy組件來實現的虛擬IP路由及轉發。所以在之前集群部署的環節上，我們在每個Node上均部署了Proxy這個組件，從而實現了Kubernetes層級的虛擬轉發網絡。從而實現Service代理外部服務、Service內部負載均衡以及發佈Service等功能。
七、ConfigMap
很多生產環境中的應用程序配置較為複雜，可能需要多個config文件、命令行參數和環境變量的組合。並且，這些配置信息應該從應用程序鏡像中解耦出來，以保證鏡像的可移植性以及配置信息不被洩露。社區引入ConfigMap這個API資源來滿足這一需求。ConfigMap包含了一系列的鍵值對，用於存儲被Pod或者系統組件（如controller）訪問的信息。這與secret的設計理念有異曲同工之妙，它們的主要區別在於ConfigMap通常不用於存儲敏感信息，而只存儲簡單的文本信息。
閱讀更多 DoDo在線 的文章
