7個選擇Kubernetes作為你的Docker編排工具的理由
對于Docker編制框架來說，Kubernetes 是最強的競爭者之一，這在版本1.2之后更是如此。如果你正在尋找一種部署 Docker 容器到你的任一環境中的方法，Kubernetes給你至少7個選擇它的理由。
Deployments
在K8S1.1中默認設置中，Deployments是alpha版。在1.2中，當你開啟一個新的集群的時候，Deployments功能開啟beta版，被認為是穩定的，并且可以運行。
為什么在K8S1.1中部署程序顯得有些乏味 (點擊這里閱讀更多信息： 點擊 )，在這里我就不贅述具體細節了，這里的要點是:
-
你得自己計算每個部署的唯一值，然后把它放到Replication-Controller定義文件。
-
首次創建以及更新已經存在的一個Replication-Controller，你得有不同的進程。
-
在你能夠通過滾動更新配置一個新的版本后，你得在系統里找一個存在的Replication-Controller。
Deployments開始逐漸取代Replication-Controller/ Rolling-Update程序。Deployments是聲明性的，這一點很厲害：就是你不必告訴集群要做什么，你只要聲明你想要什么功能，然后集群就會調度所有需要的東西來將它自己呈現出理想狀態。不需要你自己計算唯一值，要更新的時候也不再需要自己去尋找存在的配置。
官方介紹指南使用kubectl create創建部署，使用kubectl apply更新部署。但從我的個人經驗來看，你可以在上述兩個案例中應用，這就意味著你創建和更新的時候不再需要不同程序。
最后一個很棒的部署功能就是支持回滾。K8S1.1中的回滾功能已經通過重新部署舊Replication-Controller完成。在K8S1.2中，當你創建一個配置的時候，你可以使用記錄Flag。這樣的話，在你需要的任何時候，都會允許你回滾一個配置到目前的版本。
支持多可用性區域
K8S1.2版本之前，K8S最大的缺點之一就是，它缺乏在不同AZs上對延展程序的支持。這就意味著你的集群只存活在單個的AZ上，萬一這個AZ出什么故障，你會失去你整個的集群。要handle這些故障的唯一辦法就是管理多個集群，但是這么做的開銷是在無法負擔。
K8S1.2帶來了Multi-AZ的全力支持。你可以很容易在任何AZ生成節點，調度器能充分意識到不同節點調度你的pods。
雖然在這領域這是一個顯著的改進，但是Multi-AZ支持并不適用于K8S及其組件。你的集群仍然存在于一個AZ，如果這個AZ停機你會陷入一種古怪的狀態：集群功能齊全但集群不會，這就意味著不能handle部署操作等等。
K8S1.2帶來完全支持Multi-AZ的功能。你可以輕松的在任意AZ上復活，而且調度器調度你的pods到不同的節點上的時候對此是了解的。
這個領域中，這是一個了不起的改進，因為支持Multi-AZ 不僅應用于K8S master和它的組件。你的Master在單個的AZ上面也是運行的，如果AZ出了故障，你將會陷入一個不好的狀態：集群全都會起作用，但是master卻不會，這就意味著想配置這樣的操作處理不了。
ConfigMaps & secrets 作為環境變量
K8S1.1有一個通過Secrets存儲配置內置選項。但是仍然推薦使用Secrets來存儲敏感數據，ConfigMap允許通過更加直接方便的方式來允許我們存儲不敏感數據配置。
K8S1.2中一個很棒的調整就是，Secrets和ConfigMap不僅可以作為數據卷（K8S1.1中的唯一選擇）使用，而且對于你的定義文件來說，還可以作為環境變量。比加載數據卷和在應用程序上讀取文件更加方便，就是為了獲取一個簡單的配置項目。
Daemon-Sets
擁有一個K8S集群有時讓我們忘記我們有集群中還有節點。我們創建容器，但是大多數時候我們甚至不知道他們跑在哪個節點上。
雖然也有那么幾次當我們需要處理一些與節點相關的任務的時候是知道的。一個例子就是，一個應用程序從節點收集語句，然后傳送他們到一些度量服務器。另一個例子就是，從所有運行在節點上的容器那里收集所有日志，然后發送到我們的登錄系統。這些例子中，我們需要單個的容器在運行每個節點。
K8S1.1僅僅只是提供給我們靜態pods來完成這個目的。為了定義一個靜態pod，我們可能不得不在每個節點上的特定文件夾下用pod定義。這顯然很不方便因為：
-
如果我們想要添加靜態pods，我們就不得不警告在集群上運行的每個節點。
-
靜態pods在本地被kubelet管理，所以我們無法查詢API，也無法對他們進行任何別的操作。
K8S1.2介紹了 Daemon-Sets，它會提供給我們一個更加方便的方式在每個節點上運行一個pod。Daemon-Sets里面的pods是可視的，就好像系統里的其他pod一樣。你可以刪除一個Daemon-Set，然后通過API創建你想要的Daemon-Sets。不需要改變節點上的文件了。
集群大小和性能
集群大小對于一個公司來說是一個很重要的問題，它有著決定核心基礎設施的權利。我們此刻永遠也不會知道我們會在一年后規模變得多大，但是我們需要百分之百確定的是，我們現在選擇的工具以后不會限制我們。
官方新發布的1.2版本每個集群支持1000個節點，同時支持30000個pod同時運行。
然而這些數字可能是好的也可能是壞的（取決于你的主觀意愿），查看團隊運行到了什么進程是鼓舞人心的，1.2相比1.1發布版已經有了一個X10的縮放改善。
期待在1.3上看到一個更高的數字。
Jobs
Jobs允許你運行pods，以及成功完成一定數量的pods。在K8S1.1中，我們可以創建裸pods（沒有Replication-Controller），但是這些pods根本不能保證完成。例如，運行有pod的節點在執行過程中重啟，pod就不會在另一個節點被重啟。通過驗證我們完成的job，上述的情況確認不會發生。
雖然這不是一個改變世界的功能，但是絕對是一個有用的功能！
項目進程
除了上文描述的功能和改進，你很容易覺察到1.1版本后的巨大進步。每個issue就是幾個小時的問題，而且由擁有者優先化。等待良久的功能即將實現。越來越多的貢獻者正在加入這個大派對，通過提交代碼幫助改善這個項目，擴大以及討論這些issue。這大概就是我最喜歡使用的OSS項目之一了。