原文連結：https://www.nextplatform.com/2018/07/17/when-does-kubernetes-become-invisible-and-ubiquitous/

譯者：趙晨·沃趣科技

一項技術成熟的標誌不僅僅在於它有多流行，還在於它有多不起眼並且易於使用。比如，沒有人會去思考牆上的插座，除非你恰好需要給你的手機充電但又一個都找不到，這只是我們日常生活中所用到的大量技術的一個例子而已。

自從Google受到它內部叢集和容器管理系統Borg以及Omega的啟發，在四年多之前率先開源了Kubernetes容器控制器之後，我們就一直在打賭它會在公有云和私有云的容器管理上一統天下。具有諷刺意味的是，當初負責Google基礎架構管理的人並不是很情願將這樣的智慧財產權公開，但是開源信徒們正確地預測到，將Kubernetes貢獻給世界之後，Google將會從開源社群得到巨大的信譽，並且有利於創造一個和Google類似的容器化私有云環境，也可能將Goolge的模式傳播給競爭對手的雲產品，同時也能幫助其擴張自身的雲平臺。

可以肯定地說，掌舵Kubernetes以及相關監控工具Prometheus的雲原生計算基金會（CNCF），已經完成了Google及其成員所安排的工作，就是將Kubernetes轉變成一個由橫跨各種平臺、供應商和客戶的生態系統所支撐的工具，這也是為什麼幾個月前它在CNCF的狀態從孵化變成了畢業，一種正式通過的禮儀，同時也有了很多重量級的生產環境使用者。但Kubernetes依然只是一個半成品，還遠未達到像Linux核心及其周圍作業系統元件在過去25年中所做到的那種“隱形”狀態（實際上可能只花了15年就達到了那個層次）。隨著最近Kubernetes容器編排系統1.11版本的官宣，我們不禁陷入了沉思，Kubernetes到底何時才會消於無形卻又無處不在。

社群無疑是非常強大的。下面的資料雖然有點舊，但是也體現了2016年11月到2017年10月之間，GitHub上2800萬用戶的8500萬個軟體專案的活躍程度排名：

這是一個氣泡圖，Y軸繪製了每個專案的issues以及pull requests的數量，X軸則繪製了專案成員所完成的提交數量，氣泡本身則顯示了社群的相對大小。這個大小其實是每個專案中作者數量的平方根，Linux核心在當時以2843個作者居首，緊隨其後的是Kubernetes的2380個和Docker的1346個。

Kubernetes很明智地將容器的執行格式“割讓”給了Docker，並且在幾年前就和曾經擁有rkt格式的CoreOS握手言和，再加上由於大家都已經認可Docker就是容器的格式，很顯然也認可了Kubernetes將會成為管理由容器組成的那些複雜Pod的方法，這些Pod實際上包含並體現了現代微服務應用，甚至是一些傳統的巨石型應用。

西方經濟體中的公有云三巨頭——亞馬遜AWS，微軟Azure和Google雲平臺——都支援Kubernetes，而OpenStack和CloudStack開源雲控制器也都有方法來執行Kubernetes。正如我們已經討論過的，VMware提供了很多種不同的方法來交付Kubernetes容器服務（鑑於它的企業客戶群保守的天性，或許太多了）。今年早些時候，RedHat收購了CoreOS，現在它有了自己的基於CoreOS Tectonic和OpenShift工具集的Kubernetes軟體棧。Docker也已經不可避免地將Kubernetes作為它自己企業級軟體棧中Swarm容器控制器的一個替代品。在中國，百度為了它的PaddlePaddle機器學習框架，也在其雲上擁抱Kubernetes，並且已經有了基於Kubernetes的雲容器引擎。阿里巴巴有云容器服務，騰訊則有Kubectl容器引擎。Windows Server也將在2019年初支援原生的Kubernetes。

這其實影響了企業中的許多根基（原文：This covers a lot of bases in the enterprise），現在世界上大多數人都能夠按照Google想要的方式來編排容器——當然，還有社群的意見。Google通過Kubernetes將Borg開放（也確實讓它成為了多使用者模式並且更好用）的行為是一個開明自利的完美案例。現如今，理論上講，將業務負載從本地資料中心或者競爭對手的公有云上轉移到Google雲平臺上將會簡單很多。當然，反過來也一樣。如果客戶對Google雲平臺不滿意，他們也可以輕鬆地將他們的容器化應用從上面轉移回到其競爭對手那裡或者本地的伺服器上。對於如何吸引客戶並將他們留在自己的雲平臺上，Google完全掌握了主動權，這似乎是個相當不錯的激勵。

一種技術想要達到那種無處不在的形態，必須在其消於無形之前與其他的技術很好地整合在一起。反之亦然。他們總是齊頭並進。但很明顯，有一個巨大的開發者社群和一個巨大的平臺生態系統都已經擁抱了Kubernetes，現在我們就看看到底Kubernetes會被如何接受並且是否能像我們猜想得那樣變得無處不在。

我們之前與Josh Berkus進行了一次有關Kubernetes 1.11版本的對話，他是在Red Hat工作的Kubernetes社群管理員並且主導了這次更新，我們還聊了一點關於Kubernetes的潛能。結果我們得知，為了讓Kubernetes更好地適應大範圍的使用，底層的大量工作已經完成——當然還有更多的工作有待完成。

在這一點上，Kubernetes 1.11版本是個不錯的案例。Berkus說在這個版本中新增或改進的25個核心功能當中，有7個是面向使用者的功能——即使用者能實實在在看到和感受到——而另外18個則是Kubernetes內部的一些重構——使用者看不到但同樣也會從中受益。

“我們還難以弄清楚何時會將Kubernetes當做一個成熟的產品來看待，因為一些像這樣的重構工作還很繁重，”Berkus告訴The Next Platform，提及了其中一項關於和公有云對接的重構任務，它會在接下來的幾個版本中持續進行。“在最早的Kubernetes 1.0版本中，與雲的整合功能在核心程式碼中。所以，一個像Digital Ocean這樣新的雲服務供應商想要提供Kubernetes服務，他們必須拿到被Kubernetes認可的補丁才能讓他們的所有功能都正常工作。這顯然很糟糕，也沒人認為這是一件好事。我們的雲服務供應商團隊一直在努力將雲服務供應商的整合工作轉變為一種定義清晰且相較而言功能經得起驗證的API。在Kubernetes中，實際上我們已經移除了第一個雲平臺，那就是OpenStack，他們本來就要徹底重構自己的雲服務供應商程式碼而且自願成為第一批從Kubernetes核心程式碼中移除並完全使用API的人。有一堆這樣的事情需要我們去做。我們需要將雲供應商們移出並讓他們使用雲API，也需要將所有的儲存供應商轉移到雲端儲存介面（CSI）API上去，還需要移動容器執行的所有東西，確保它正在使用容器執行的API而不是背後的通道。按照程式碼的數量，這是當下Kubernetes專案中最主要的工作。所以，當我們將所有的東西都轉變成API的時候，也就是Kubernetes變得成熟並且你們也不會期待任何激進改變的那個時間節點。”

這個時刻的到來可能還要好幾年時間，Berkus也同意，因為當API推出之後，它們的缺陷也會暴露出來——正如所有程式碼被創造出來時一樣——它們將不得不緩慢且謹慎的迭代，從而不會破壞相容性。考慮到那個讓Kubernetes可以部署（儘管不成熟）的1.0版本剛剛走過第三個年頭，從四年前Google將程式碼轉儲到GithHub開始，發展速度已經很快了。Google的那份程式碼的確讓自己佔據了主動——那是一個用Go語言開發的簡化版Borg，比起原版只適用於Google內部的特殊場景來說，它變得更加通用。Google不僅有效地“外包”了一部分可以讓這個Borg的衍生品跨平臺移植的工作，同時還讓社群的合作伙伴們踴躍地參與到這部分工作中來。

這才讓我們接受了Kubernetes。沒有人確切地知道，它一直是一個開源軟體棧。大部分參與到雲端計算技術中的公司，不管是在本地資料中心還是在公有云上，都在通過某種方式使用Kubernetes，但是對於那些一般的公司，它們在數量上仍然佔了80%左右（粗略猜測）並且可能在計算資源上的開銷（也就是直接購買硬體的開銷）佔據了市場的一半，這些公司還沒有到那一步。但是他們也正在慢慢接受Kubernetes了。

Kubernetes 1.11版本有一些可以讓其更容易被接受的功能特性。一個自家的KubeDNS服務系統專案正在轉換成為一個CNCF專案——CoreDNS規範，另外Berkus還說有一套更好的規範得到了社群更廣泛的支援。1.11這個升級版本也支援Kubelets動態配置（通過一個配置檔案或者一份ConfigMap），它是執行在一個容器叢集中的所有系統上的Kubernetes守護程序；過去，管理員不得不進入Kubernetes中修改啟動引數，然後再重啟系統。自定義資源定義（CRDs）已經做了改進，可以更輕鬆地建立將Kubernetes叢集視為一個系統的應用程式，它們不用直接深入到容器的粒度（這正是Borg的天才之處）。這些CRDs是Kubernetes得以擴充套件的主要方式，再加上允許Kubernetes深入到叢集中並且控制虛擬機器管理程式（Hypervisors）以及虛擬機器的KubeVirt元件，這也只是其中一個例子。這個版本也包含了任務優先順序和搶佔功能，這意味著Kubernetes可以接受一項高優先順序的任務並且立刻執行，即使這意味著要將其他應用中斷，延後執行。最後一個重大變化是核心IPVS負載均衡工具，它能在叢集上自動平衡Kubernetes服務所承受的負載。