7個選擇Kubernetes作為你的Docker編排工具的理由

zhiwei 發(fā)布于2019-07-01 16:22 / 1799人閱讀

摘要：如果你正在尋找一種部署容器到你的任一環(huán)境中的方法，給你至少個選擇它的理由。允許你運行，以及成功完成一定數(shù)量的。通過驗證我們完成的，上述的情況確認不會發(fā)生。每個就是幾個小時的問題，而且由擁有者優(yōu)先化。

對于Docker編制框架來說，Kubernetes 是最強的競爭者之一，這在版本1.2之后更是如此。如果你正在尋找一種部署 Docker 容器到你的任一環(huán)境中的方法，Kubernetes給你至少7個選擇它的理由。

Deployments

在K8S1.1中默認設(shè)置中，Deployments是alpha版。在1.2中，當你開啟一個新的集群的時候，Deployments功能開啟beta版，被認為是穩(wěn)定的，并且可以運行。
為什么在K8S1.1中部署程序顯得有些乏味 (點擊這里閱讀更多信息：點擊)，在這里我就不贅述具體細節(jié)了，這里的要點是:

你得自己計算每個部署的唯一值，然后把它放到Replication-Controller定義文件。

首次創(chuàng)建以及更新已經(jīng)存在的一個Replication-Controller，你得有不同的進程。

在你能夠通過滾動更新配置一個新的版本后，你得在系統(tǒng)里找一個存在的Replication-Controller。

Deployments開始逐漸取代Replication-Controller/ Rolling-Update程序。Deployments是聲明性的，這一點很厲害：就是你不必告訴集群要做什么，你只要聲明你想要什么功能，然后集群就會調(diào)度所有需要的東西來將它自己呈現(xiàn)出理想狀態(tài)。不需要你自己計算唯一值，要更新的時候也不再需要自己去尋找存在的配置。

官方介紹指南使用kubectl create創(chuàng)建部署，使用kubectl apply更新部署。但從我的個人經(jīng)驗來看，你可以在上述兩個案例中應(yīng)用，這就意味著你創(chuàng)建和更新的時候不再需要不同程序。

最后一個很棒的部署功能就是支持回滾。K8S1.1中的回滾功能已經(jīng)通過重新部署舊Replication-Controller完成。在K8S1.2中，當你創(chuàng)建一個配置的時候，你可以使用記錄Flag。這樣的話，在你需要的任何時候，都會允許你回滾一個配置到目前的版本。

支持多可用性區(qū)域

K8S1.2版本之前，K8S最大的缺點之一就是，它缺乏在不同AZs上對延展程序的支持。這就意味著你的集群只存活在單個的AZ上，萬一這個AZ出什么故障，你會失去你整個的集群。要handle這些故障的唯一辦法就是管理多個集群，但是這么做的開銷是在無法負擔。

K8S1.2帶來了Multi-AZ的全力支持。你可以很容易在任何AZ生成節(jié)點，調(diào)度器能充分意識到不同節(jié)點調(diào)度你的pods。

雖然在這領(lǐng)域這是一個顯著的改進，但是Multi-AZ支持并不適用于K8S及其組件。你的集群仍然存在于一個AZ，如果這個AZ停機你會陷入一種古怪的狀態(tài)：集群功能齊全但集群不會，這就意味著不能handle部署操作等等。

K8S1.2帶來完全支持Multi-AZ的功能。你可以輕松的在任意AZ上復(fù)活，而且調(diào)度器調(diào)度你的pods到不同的節(jié)點上的時候?qū)Υ耸橇私獾摹?/p>

這個領(lǐng)域中，這是一個了不起的改進，因為支持Multi-AZ 不僅應(yīng)用于K8S master和它的組件。你的Master在單個的AZ上面也是運行的，如果AZ出了故障，你將會陷入一個不好的狀態(tài)：集群全都會起作用，但是master卻不會，這就意味著想配置這樣的操作處理不了。

ConfigMaps & secrets 作為環(huán)境變量

K8S1.1有一個通過Secrets存儲配置內(nèi)置選項。但是仍然推薦使用Secrets來存儲敏感數(shù)據(jù)，ConfigMap允許通過更加直接方便的方式來允許我們存儲不敏感數(shù)據(jù)配置。

K8S1.2中一個很棒的調(diào)整就是，Secrets和ConfigMap不僅可以作為數(shù)據(jù)卷（K8S1.1中的唯一選擇）使用，而且對于你的定義文件來說，還可以作為環(huán)境變量。比加載數(shù)據(jù)卷和在應(yīng)用程序上讀取文件更加方便，就是為了獲取一個簡單的配置項目。

Daemon-Sets

擁有一個K8S集群有時讓我們忘記我們有集群中還有節(jié)點。我們創(chuàng)建容器，但是大多數(shù)時候我們甚至不知道他們跑在哪個節(jié)點上。

雖然也有那么幾次當我們需要處理一些與節(jié)點相關(guān)的任務(wù)的時候是知道的。一個例子就是，一個應(yīng)用程序從節(jié)點收集語句，然后傳送他們到一些度量服務(wù)器。另一個例子就是，從所有運行在節(jié)點上的容器那里收集所有日志，然后發(fā)送到我們的登錄系統(tǒng)。這些例子中，我們需要單個的容器在運行每個節(jié)點。

K8S1.1僅僅只是提供給我們靜態(tài)pods來完成這個目的。為了定義一個靜態(tài)pod，我們可能不得不在每個節(jié)點上的特定文件夾下用pod定義。這顯然很不方便因為：

如果我們想要添加靜態(tài)pods，我們就不得不警告在集群上運行的每個節(jié)點。

靜態(tài)pods在本地被kubelet管理，所以我們無法查詢API，也無法對他們進行任何別的操作。

K8S1.2介紹了 Daemon-Sets，它會提供給我們一個更加方便的方式在每個節(jié)點上運行一個pod。Daemon-Sets里面的pods是可視的，就好像系統(tǒng)里的其他pod一樣。你可以刪除一個Daemon-Set，然后通過API創(chuàng)建你想要的Daemon-Sets。不需要改變節(jié)點上的文件了。

集群大小和性能

集群大小對于一個公司來說是一個很重要的問題，它有著決定核心基礎(chǔ)設(shè)施的權(quán)利。我們此刻永遠也不會知道我們會在一年后規(guī)模變得多大，但是我們需要百分之百確定的是，我們現(xiàn)在選擇的工具以后不會限制我們。

官方新發(fā)布的1.2版本每個集群支持1000個節(jié)點，同時支持30000個pod同時運行。

然而這些數(shù)字可能是好的也可能是壞的（取決于你的主觀意愿），查看團隊運行到了什么進程是鼓舞人心的，1.2相比1.1發(fā)布版已經(jīng)有了一個X10的縮放改善。

期待在1.3上看到一個更高的數(shù)字。

Jobs

Jobs允許你運行pods，以及成功完成一定數(shù)量的pods。在K8S1.1中，我們可以創(chuàng)建裸pods（沒有Replication-Controller），但是這些pods根本不能保證完成。例如，運行有pod的節(jié)點在執(zhí)行過程中重啟，pod就不會在另一個節(jié)點被重啟。通過驗證我們完成的job，上述的情況確認不會發(fā)生。

雖然這不是一個改變世界的功能，但是絕對是一個有用的功能！

項目進程

除了上文描述的功能和改進，你很容易覺察到1.1版本后的巨大進步。每個issue就是幾個小時的問題，而且由擁有者優(yōu)先化。等待良久的功能即將實現(xiàn)。越來越多的貢獻者正在加入這個大派對，通過提交代碼幫助改善這個項目，擴大以及討論這些issue。這大概就是我最喜歡使用的OSS項目之一了。