Kubernetes 容器編排
對於Docker編制框架來說，Kubernetes 是最強的競爭者之一，這在版本1.2之後更是如此。如果你正在尋找一種部署 Docker 容器到你的任一環境中的方法，Kubernetes給你至少7個選擇它的理由。
Deployments
在K8S1.1中預設設定中，Deployments是alpha版。在1.2中，當你開啟一個新的叢集的時候，Deployments功能開啟beta版，被認為是穩定的，並且可以執行。
為什麼在K8S1.1中部署程式顯得有些乏味 (點選這裡閱讀更多資訊：ofollow,noindex" target="_blank">點選 )，在這裡我就不贅述具體細節了，這裡的要點是:
-
你得自己計算每個部署的唯一值，然後把它放到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專案之一了。
本文轉自開源中國-Kubernetes 容器編排