一、Kubernetes是什么
要說到Docker就不得不說說Kubernetes。當Docker容器在微服務的環境下數量一多，那么統一的，自動化的管理自然少不了。而Kubernetes就是一個這樣的工具，它不僅僅提供了健康檢查和自修復，還有自動擴容縮容，以及服務發現和負載均衡等等功能。總的來說它使我們對於大量的Docker容器管理更加的方便。
二、Kubernetes整體架構圖及對應功能分析
1、kubectl：這是相當於用戶客戶端一樣，也是我們較常使用的命令行工具，通過這個工具可以發起對應的請求到master節點中，當然自己開發的客戶端同樣可以通過HTTP協議發起對應的RESTAPI請求訪問APIServer。
2、Master：Master節點是整個Kubernetes的核心節點，主要職責是負責調度，即應用放在哪里運行，同樣為了高可用可運行多個Master。而Master中主要有APIServer，ControllerManager，Scheduler，Etcd，Kube-dns。對應的職責分別如下：
2.1、APIServer：提供了資源操作的唯一入口，注意其他節點是無法被外面請求操作的（不是說內部運行的容器無法被訪問，而是說無法通過發請求的方式直接操作Node），只有Master節點才能接受外面的請求進行操作Node節點，其中主要提供了認證、授權、訪問控制整個集群。而dashboard是提供了一個展示界面。
2.2、Scheduler：負責資源的調度，根據一定的調度策略，將對應Node上面的Pod運行起來。
2.3、ControllerManager：負責維護集群的狀態，比如故障檢測，擴縮容，滾動更新。在Pod運行起來，就由ControllerManager負責管理其狀態
2.4、ETCD：用於一致性存儲，保存pod，service等等的Kubernetes狀態。這里可以理解為MySQL在我們日常項目中的存儲作用，只要是用於存取Kubernetes中所有的持久化數據。
2.5、Kube-dns：DNS組件負責整個集群的DNS服務。使得內部Pod相互之間可通過名字訪問。有了這個功能就不需要寫繁瑣的IP地址，通過服務的名字即可訪問對方。
3、Node：理解為分支節點，主要作用在於提供Kubernetes運行時的環境，以及維護Pod。內部主要有Kubblet，kube-proxy，docker等
3.1、Kubblet：通過Master發送的請求到Node分支上的Kubblet，然后就由Kubblet負責維護當前節點上容器的生命周期，也負責維護當前節點的數據卷及網絡。
3.2、Kube-proxy：提供內部的服務發現和負載均衡。可以在圖上看見虛線框起來的三個框，可以認為這三個Pod算是一個服務，即service，而外部可通過Kube-proxy暴露的端口來進行統一的訪問。並且默認是使用輪詢的負載均衡策略來訪問。
三、Pod詳解
Pod作為Kubernetes的核心資源，這里單獨拿出來解釋。在Kubernetes集群中，Pod是所有業務類型的基礎，它是一個或多個容器的組合，也就是Pod內部可以有多個Docker容器存在，不是一個Pod代表一個容器，注意區分概念。在其中的這些容器共享存儲、網絡和命名空間，以及如何運行的規范。在Pod中，所有容器都被同一安排和調度，並運行在共享的上下文中。對於具體應用而言，Pod是它們的邏輯主機，Pod包含業務相關的多個應用容器。這些容器可以通過localhost發現彼此。每一個Pod有自己的一個IP地址。
1、Pod工作方式
在Kubernetes中一般不會直接創建一個獨立的Pod，這是因為Pod是臨時存在的一個實體。當直接創建一個獨立的Pod時，如果缺少資源或者所被調度到的Node失敗，則Pod會直接被刪除。這里需要注意的是，重起Pod和重起Pod中的容器不是一個概念，Pod自身不會運行，它只是容器所運行的一個環境。Pod本身沒有自愈能力，如果Pod所在的Node失敗，或者如果調度操作本身失敗，則Pod將會被刪除；同樣的，如果缺少資源，Pod也會失敗。Kubernetes使用高層次的抽象，即控制器來管理臨時的Pod。通過控制器能夠創建和管理多個Pod，並在集群范圍內處理副本、部署和提供自愈能力。
2、重啟策略
Pod既然內部運行着容器，那么免不了會因為異常等原因導致其終止退出，Pod支持三種重啟策略，需要在配置文件中通過restartPolicy字段設置重啟策略：
Always：只要退出就會重啟
OnFailure：只有在失敗退出（即exit code不等於0時），才會重啟
Never：只要退出就不再重啟
3、鏡像拉取策略
前一篇博客有講容器與鏡像的概念，在Kubernetes中運行容器時，需要為容器獲取鏡像。Pod中容器的鏡像有三個來源，即Docker公共鏡像倉庫、私有鏡像倉庫和本地鏡像。當在內網使用的Kubernetes場景下，就需要搭建和使用私有鏡像倉庫。Pod支持三種鏡像拉取策略，在配置文件中通過imagePullPolicy字段設置鏡像拉取策略：
Always：不管本地是否存在鏡像都會進行一次拉取
Never：不管本地是否存在鏡像都不會進行拉取
IfNotPresent：僅在本地鏡像不存在時，才會進行鏡像拉取
這里有需要注意的點：鏡像拉取策略的默認值IfNotPresent，但:lastest標簽的鏡像默認為Always。所以生產環境中避免使用:lastest標簽。還有就是拉取鏡像時docker會進行校驗，如果鏡像中的MD5碼沒有變，則不會拉取鏡像數據。
4、資源限制
Kubernetes通過cgroups來限制容器的CPU和內存等計算資源，在創建Pod時，可以為Pod中的每個容器設置資源請求(request)和資源限制(limit)，資源請求是容器需要的最小資源要求，資源限制為容器所能使用的資源上限。CPU的單位是核(core)，內存(Memory)的單位是字節(byte)。
5、終止Pod
在集群中，Pod代表運行的進程，但不再需要這些進程時，如何優雅的終止這些進程是非常重要的。當用戶請求刪除一個Pod時，Kubernetes將會發送一個終止信號給每個容器，一旦過了優雅期，就會發送kill信號，從而通過APIServer刪除Pod。通常默認的優雅退出時間為30s。緩慢關閉的Pod依然可以對外繼續服務，直到負載均衡器將其移除，當超過優雅的退出時間，在Pod中任何正在運行的進程都會被kill。
四、Pod的生命周期
1、Pending
Pod已經被Kubernetes系統接受，但是還有一個或者多個容器鏡像未被創建。這包括Pod正在被調度和從網絡上下載鏡像的時間。
2、Running
Pod已經被綁定到了一個Node，所有容器已經被創建，至少有一個容器在運行
3、Succeeded
在Pod中所有容器已經被成功停止，並且不再重啟
4、Failed
在Pod中所有容器已經被終止，並且至少有一個容器是非正常終止的，即容器以非零狀態退出或者被系統強行終止的。
5、Unknown
Pod在某些原因下不能被獲取。通常是網絡問題。
五、service圖
前面有說到Docker目前在微服務架構運行的很廣泛，而Kubernetes作為編排Docker容器的強大工具自然是我們的首選。而Kubernetes又是怎么和微服務結合起來的呢？
上面有說到Pod擁有自己的IP地址，實際上在Pod外面還包裹着一層Service，這個Service是邏輯存在的，在最上面的架構圖中就類似kube-proxy串在一起的三個Pod，而service的IP是由kube-proxy給我們提供。這就是與微服務之間能夠連起來了。其中同一個service的Pod應該是相同的，kube-proxy會自動給我們做負載均衡，默認使用輪詢。同樣與Docker不相同的是Pod之間是可以通過名字直接訪問的，Node同樣也是，這就為我們的服務調用提供了很便利的方式。
六、總結
Kubernetes是一個容器編排及其自動化管理的工具。隨着業務增長Docker容器越來越多，如果需要每一個自己手動管理，那么將會翻倍的增加我們的工作量。所以Kubernetes是我們在學習Docker中需要進階的知識。