kubernetes是Google的一個大規模容器管理技術的開源版本，可能大部分初學者是學習docker的過程中認識到kubernetes的，kubernetes確實也能很簡單的集成docker，但是，docker只是kubernetes支持的容器之一，并不是只有docker才能與kubernetes集成，只不過因為docker比較流行所以優先使用docker。

那么為什么會有這個kubernetes呢？這與第一句介紹有關：kubernetes是一個大規模容器管理技術的開源版本，也就是說kubernetes是為了管理大規模容器集群的技術，因為當容器多到一定程度后，手動一個個管理就比較麻煩了，耗時耗力，這時就有了眾多的容器管理解決方案，方便管理大量的容器，而kubernetes則是其中比較優秀的一個，所以使用者也就比較多了。

kubernetes中增加了很多新名詞、新概念，新手起初看的時候可能會頭暈，感覺亂，下面就來介紹一下kubernetes中的幾個重要概念。

首先是Pod，在kubernetes中，最小的管理單位是Pod而不是docker或其他容器的實例，一個Pod可以包含多個容器，而Pod則對這些容器進行統一管理。

在kubernetes集群中，各個Pod都擁有一個虛擬的IP，該IP會在Pod創建后由kubernetes隨機分配，這個IP外部無法直接訪問，而在kubernetes內部則是互通的，相當于一個虛擬局域網絡。

一個Pod如果想要對外提供服務，則需要開放端口（也可以通過其他方式解決，這是官方提供的方式），Pod的ClusterIP+端口號就組成了一個Endpoint，該Endpoint對外提供服務，而一個Pod可以開放多個端口，也就是可以對應多個Endpoint。如果想要該Endpoint可以對kubernetes集群外的客戶端提供服務，那只需要綁定一個本機端口即可。

在kubernetes中，直接編寫一個Pod配置文件并發布到kubernetes集群是允許的，但是這相比直接部署docker容器并沒有什么優勢，而kubernetes提供了一種更優優勢的方案，那就是通過Pod管理器去管理Pod，在較早的版本中使用的是ReplicationController（后稱RC），在新版本中則提供了Deployment，本文不對比兩種方案的優劣，只通過RC來介紹該方案的優勢。

使用RC你可以通過配置文件來完成對Pod數量的控制，只需要在RC文件中指明你需要10個某個Pod的實例，那么RC會自動幫你部署好10個指定Pod的實例，省去了一大筆部署時間，而當其中某個Pod掛掉后，如果是直接部署的Pod，那么就需要手動去重啟了，而且還不一定能實時監控到Pod的健康狀態，但是通過RC去部署Pod，當Pod掛掉后RC會自動重新部署一個Pod來保證Pod的總數不變。

在kubernetes內網中，調用一個服務可以通過Pod的clusterIP+port的方式調用，但是由于Pod的clusterIP是在Pod創建后隨機分配的，也就是無法提前得知Pod的clusterIP，同時Pod有可能被重建，當Pod被重建后IP也會隨之變化，這樣就造成一個問題，kubernetes也提供了使用環境變量的方法解決，也就是當Pod創建完后會加一條環境變量保存Pod的IP，其他服務調用方可以通過環境變量獲取該Pod的IP，進而調用服務，但是以上方式有一些明顯的缺點，需要寫死IP，但是當Pod重建后之前寫死的IP就會失效，如果通過環境變量獲取，那么由于Pod可能重建，所以需要每次使用都重新獲取，比較麻煩，所以kubernetes提供了Service的概念解決了該問題。

對于一個服務，可以寫一個Service統一對外提供服務，Service的IP是固定不變的，同時Service不僅解決了Pod的IP無法確定的問題，如果有多個Pod提供同一服務，那么通過Service還可以為這些Pod做負載均衡，Service會根據指定負載均衡策略去將請求分發到不同的Pod中。

有了Service就可以通過IP去調用服務了，但是Service的IP不容易記憶，那怎么辦？kubernetes同時還提供了一套完善的DNS服務，通過DNS服務，你可以通過Service的名稱調用到服務，而DNS服務則會將Service的名稱轉換為Service的IP。

在kubernetes中，一個Node對應一個主機或者一個虛擬機，Node是Pod的載體，所有Pod都在Node里邊部署。當擴展主機時，只需要增加一些配置，該主機就可以自動被kubernetes的master發現并配置為一個Node，供后續部署Pod使用，擴容起來十分的快。