[[420872]]

這兩年，Kubernetes 擊敗了 Swarm 和 Mesos，幾乎成為容器編排的事實標準，BAT、滴滴、京東、頭條等大廠，都爭相把容器和 K8S 項目作為技術重心。

為什么在眾多容器平臺中，Kubernetes能夠脫穎而出，是因為Kubernetes的接口和概念設計是完全站在應用角度而非運維角度的。

如果站在傳統運維人員的角度看 Kubernetes，會覺得他是個奇葩所在，容器還沒創建出來，概念先來一大堆，文檔先讀一大把，編排文件也復雜，組件也多，讓很多人望而卻步。

但是如果開發人員的角度，尤其是從微服務應用的架構的角度來看Kubernetes，則會發現，他對于微服務的運行生命周期和相應的資源管控，做了非常好的抽象。

如圖中所示，和虛擬機運行傳統應用，只需要創建出資源來，并且保證網絡暢通即可的方式不同，微服務的運行，需要完成左面的一系列工具鏈。

為什么要使用這些工具鏈，以及如何使用這些工具鏈，請參考我的另外兩篇文章以業務為核心的云原生體系建設和從1到2000個微服務，史上最落地的實踐云原生25個步驟。

你會發現，Kubernetes都有相應的工具鏈可以匹配。

微服務設計重要的一點就是區分無狀態和有狀態，在 K8S 中，無狀態對應 deployment，有狀態對應 StatefulSet。

deployment 主要通過副本數，解決橫向擴展的問題。

而 StatefulSet 通過一致的網絡 ID，一致的存儲，順序的升級，擴展，回滾等機制，保證有狀態應用，很好地利用自己的高可用機制。因為大多數集群的高可用機制，都是可以容忍一個節點暫時掛掉的，但是不能容忍大多數節點同時掛掉。而且高可用機制雖然可以保證一個節點掛掉后回來，有一定的修復機制，但是需要知道剛才掛掉的到底是哪個節點，StatefulSet 的機制可以讓容器里面的腳本有足夠的信息，處理這些情況，實現哪怕是有狀態，也能盡快修復。

微服務少不了服務發現，除了應用層可以使用 SpringCloud 或者 Dubbo 進行服務發現，在容器平臺層當然是用 Service了，可以實現負載均衡，自修復，自動關聯。

服務編排，本來 K8S 就是編排的標準，可以將 yml 文件放到代碼倉庫中進行管理，而通過 deployment 的副本數，可以實現彈性伸縮。

對于配置中心，K8S 提供了 configMap，可以在容器啟動的時候，將配置注入到環境變量或者 Volume 里面。但是唯一的缺點是，注入到環境變量中的配置不能動態改變了，好在 Volume 里面的可以，只要容器中的進程有 reload 機制，就可以實現配置的動態下發了。

統一日志中心，監控中心，APM往往需要在 Node 上部署 Agent，來對日志和指標進行收集，當然每個 Node 上都有，daemonset 的設計，使得更容易實現。

Kubernetes本身能力比較弱的就是服務的治理能力，這一點 Service Mesh，可以實現更加精細化的服務治理，進行熔斷，路由，降級等策略。Service Mesh 的實現往往通過 sidecar 的方式，攔截服務的流量，進行治理。這也得力于 Pod 的理念，一個 Pod 可以有多個容器，如果當初的設計沒有 Pod，直接啟動的就是容器，會非常的不方便。

所以，掌握容器技術成為很多公司招聘時的重要選項。

這兩年，跟朋友探討 K8S落地時，也有一些問題被反復提及，比如：

• 為什么容器里只能跑“一個進程”?
• 之前一直用的某個 JVM 參數，在容器里怎么不好使了?
• 為什么 Kubernetes 不能固定 IP 地址?容器網絡連不通，該如何 Debug?
• K8S 中 StatefulSet 和 Operator 到底什么區別?PV 和 PVC 又該怎么用?

這些問題的答案和原理并不復雜，但很難一兩句話解釋清楚。因為容器技術涉及操作系統、網絡、存儲、調度、分布式原理等方方面面的知識，是個名副其實的全棧技術。

而其技術體系里那些“牽一發而動全身”的主線，比如 Linux 進程模型對容器本身的重要意義，“控制器”模式對整個 K8S 項目提綱挈領的作用等等，不會詳細展現在 Docker 或 Kubernetes 官方文檔中，但偏偏就是它們，才是掌握容器技術體系的精髓所在。