什麼是Kubernetes？科普文
【編者的話】這篇文章並不會深入的講解Kubernetes，作者主要講述了Kubernetes的歷史，它出現的原因，以及發展，文中有很多有趣的對答，通過一問一答更好的解釋了一項技術發展的歷程就是不斷解決問題的過程。
在過去幾年，整個行業逐漸轉向開發更小更專業的程式。
越來越多的企業把原先龐大穩定的巨型系統拆分成解耦的獨立的元件。 這個方向是正確的。
微型服務有以下幾個優點：
- 快速部署 －因為你可以快速的建立並且釋出一個小型服務
- 更容易迭代 － 因為可以獨立的為每個服務新增新功能
- 更加靈活 － 就算單個服務（元件）不能使用，其他的服務仍能正常執行。
從產品和開發的角度來說，微服務更完美
那麼這種文化轉變是怎樣影響基礎設施的呢？
管理大規模的基礎設施
當你只需要管理幾個應用程式時，一切都很簡單，你甚至可以用手指算出它們的個數，並且你有足夠的時間專注與應用的釋出和運維。 在大公司中，管理數百個應用雖然要求很高，但仍是可以做到的。
將會有幾個團隊專門用於開發，打包，以及釋出應用。
另一方面，開發微服務將會帶來新的挑戰。
對於每個應用，你可能會在重構的時候，將一個應用拆分成四個元件（服務），那麼你至少需要四倍的時間去開發，打包，釋出這些微服務。
我們常常看到，一個小型服務由多種元件構成，例如前端應用，後臺API，一個授權伺服器，一個管理應用程式等等。實際上，當你開發了多個微服務，並且這些服務相互互動，你將會看到你的基礎架構上部署了大量的元件（服務）。
事情變的越來越複雜。
你可能需要在計算資源上浪費很多錢。
大部分服務被部署到虛擬機器上，如Amazon EC2，Digital Ocean Droplets或Azure Virtual Machines。
每個虛擬機器都帶有一個作業系統，這個系統會佔用部分記憶體以及cpu資源。
當你在Digital Ocean上建立1GB記憶體和1個vCPU Droplet時，除去作業系統的開銷後，最終可以使用700MB記憶體和0.8 vCPU。
換句話說，每五個虛擬機器的作業系統的開銷加起來就是一個完整的虛擬機器。
你付了五個的錢，但只能使用四個。
即便是在物理機上，你也無法繞開它。你仍然需要用作業系統執行服務。
然而，作業系統上的浪費只是冰山一角。
你也浪費了大量的錢在資源利用上。
您可能已經意識到，當您將服務分解為更小的元件時，每個元件都會有不同的資源需求。 某些元件（如資料處理和資料探勘應用程式）是CPU密集型的。
其他的（例如一些實時應用程式的伺服器）相比於CPU，可能會使用更多的記憶體。
Amazon Web Services以及其他的雲服務提供商的確有一長串適用於各種場景的計算資源：通用的，CPU優化的，記憶體優化的，儲存優化的以及gpu計算的。
你需要為你的服務認真挑選合適的虛擬機器。理想情況下，這個虛擬機器可以滿足你的服務的記憶體消耗以及CPU使用。
您是否正在使用Java編寫的關鍵Web元件？也許您應該使用針對計算密集型工作負載優化的c5.4xlarge。越能滿足要求，你就能更好的利用資源。但實際上，這並不常見。
你應該使用c5.2xlarge還是c5.4xlarge？
下一級別（8個vCPU和16GB記憶體）是否更合適？
在80％的情況下選擇幾個足夠好的計算配置並將其用於所有元件要容易得多。
事實上，對於所有工作負載使用相同配置的虛擬機器又有什麼問題麼？
完全沒問題，只要你願意將每個元件包裝成2GB記憶體和vCPU計算容量。即便你的應用只需要1GB記憶體。
是的，你可以將來再優化。
但是老實說，這就像在開車時更換輪胎一樣 -- 非常危險。
你花了很多精力來調整系統最後意識到應用程式再次改變而你又得從頭開始。
最終，你會做一個明智的選擇：選擇小型，中型和大型配置檔案的虛擬機器，並將其用於所有工作負載。
你知道你必須忍受浪費數百兆位元組的RAM和大量的CPU週期。
其實很多公司都在做同樣的事情，忍受著類似的低效。
有些甚至只利用到分配資源的10％。
您在亞馬遜上的EC2例項中支付1000美元，您實際上只使用了100美元。
這聽起來不像是花費預算的最佳方式。
你應該把你花在不用的資源的錢拿回來。
但是為什麼每個服務的需求如此不同呢？！
有時候選擇合適的工具甚至會弊大於利
當開發人員可以自由地使用正確的工具時，他們通常會瘋狂。前端選擇Node.js,後臺API選用Spring Boot, 使用Flask和Celery來處理後臺作業，使用React.js來建立客戶端，你懂的。
整個基礎設施就像一個主題公園，數百個程式在不同的執行時執行。 為一項工作選用合適的技術的確帶來了更快的迭代速度，但是管理更多的程式語言也帶來了額外的負擔。
雖然你可以控制工具和程式語言的數量，但是實際上，這往往很困難。
兩個應用程式的共享相同的JVM執行時，但是它們可能依賴於兩組不同的依賴項和庫。
也許一個依靠ImageMagick來調整影象大小。
另一個依賴於諸如PhantomJS或ZeroMQ之類的二進位制檔案在其路徑中可用。
你需要把這些依賴與應用一起打包。
最終你可能需要處理數十種看上去相似的配置，但其實上各有不同。
你不能把基礎設施當做以後才處理的事情。
在開發應用程式時，你應該從一開始就考慮好依賴項並將它們打包。
理想情況下，您應該將執行元件所需的所有依賴歸檔為單個包。
不要在釋出前還在尋找缺失的依賴。
是的，說總是比做容易。
或許不。
從物流行業借鑑集裝箱的概念
資訊科技行業並不是唯一遇到這個問題的行業。
將貨物運往全球並且保證它們獨立運輸也十分困難。
想象你需要儲存上千個不同形狀大小的盒子。並且你需要額外注意如何打包這些貨物，避免它們在運送中丟失。
貨運公司想出一個很好的解決方案：集裝箱
貨運公司不運送單個貨物，而是運送集裝箱。
你想要安全的運送你的貨物麼？
只需要將它們放置於集裝箱中即可。
當集裝箱到目的地時，你保證能收到你所有的貨物。
你也可以將這一準則運用到你的應用上去。
你想安全的部署你的應用及其所有的依賴麼？
只需要將它們打包在Linux的容器之中即可
一個Linux容器就像是一個貨物的集裝箱，只是它包含的是所有的檔案，二進位制檔案，以及所有需要執行你的程式所需的庫。
這聽上去是不是很像虛擬機器?精簡版的虛擬機器
事實上，虛擬機器很像容器。
他們封裝了應用以及應用的所有依賴，就像容器一樣。
但是，虛擬機器啟動很慢，而且體積大浪費資源。
事實上，你需要事先分配一些固定的CPU和記憶體來執行你的程式。
虛擬機器必須模擬硬體，並附帶作業系統這個累贅。
而另一方面，Linux容器，僅僅只是在你主機上執行的程序
實際上，在同一個作業系統和伺服器上，您可以在執行數十個容器。
儘管他們執行在同一個機器上，容器裡的程序彼此並不可見。
在容器裡面執行的應用是完全隔離的，它無法區分虛擬機器與容器的區別。 That’s great news! 真是個好訊息!
Linux容器就像是虛擬機器，但是更加高效。
那麼這些容器是由什麼組成的呢？
Linux容器是一個獨立程序
它的神奇之處來自Linux核心中的兩個功能：控制組和名稱空間。
控制組是限制特定程序可以使用的CPU或記憶體的便捷方式。
例如，您可以說您的元件應該只使用2GB記憶體和四個CPU核心中的一個。
另一方面，名稱空間負責隔離程序並限制它可以看到的內容。
元件只能看到與其直接相關的網路資料包。
它將無法看到流經網路介面卡的所有網路資料包。
控制組和名稱空間是底層基元。
隨著時間的推移，開發人員建立了越來越多的抽象層，以便更容易地控制這些核心功能。
最初的抽象之一是LXC，但最佳示例是2013年釋出的Docker。
Docker不僅抽象了上述核心功能，而且使用起來也很容易。
執行Docker容器非常簡單：
docker run <my-container>
由於所有容器都實現了標準介面，因此您可以使用相同的命令執行其他任何容器：
docker run mysql
就可以執行Mysql資料庫
應用程式的可移植性以及建立和執行程序的標準介面，使變得容器越來越受歡迎。
容器超棒！
- 你節省了執行幾十個作業系統的錢:white_check_mark:
- 你將應用程式打包為行動式單元:white_check_mark:
- 你有大量的容器:x:
聽起來容器還沒有解決所有問題
你需要一種管理容器的方式。
管理大規模容器
當您有數百個（而不是數千個）容器時，您應該找到一種在同一伺服器上執行多個容器的方法。
而且你應該提前想好容器如何在多個伺服器上擴充套件。
因此，您可以跨多個節點分配負載，並防止單個故障可能導致整個服務崩潰。
跟蹤基礎架構中每個容器的部署位置聽起來很浪費時間。
也許有一種自動化方法？
如果您可以使用演算法來決定放置這些容器的位置，該怎麼辦？
也許聰明有效地打包容器可以以最大化伺服器密度？
甚至可以保留已部署容器及其主機的列表？
事實證明，有人正好油同樣的想法，並提出了一個解決方案。
Kubernetes: 強大的容器編排工具
Kubernetes最初由Google建立
谷歌當時正在使用一種類似於容器的技術，並且必須找到一種有效的方式來安排工作負載。
他們不想保留並手動更新一長串容器和伺服器列表。
因此，他們決定編寫一個可以自動分析資源利用率，安排和部署容器的平臺。
但這個平臺一開始是閉源的。
幾個Google員工決定將該平臺重寫為開源工具。
接下來就是我們所知的歷史。
那麼什麼是Kubernetes？
您可以將Kubernetes視為排程程式。
Kubernetes檢查您的基礎設施（物理機或雲，公共或私有）並檢測每臺機器的CPU和記憶體。
當您請求部署一個容器時，Kubernetes會識別容器的記憶體要求，並找到滿足您請求的最佳伺服器。
您無法決定部署應用程式的具體位置。
資料中心已經把這個步驟抽象出來。
換句話說，Kubernetes將使用您的基礎設施像玩俄羅斯方塊一樣玩轉容器。
Docker容器就是方塊;伺服器是板，Kubernetes就是玩家。
使用Kubernetes打包你的基礎設施，意味著花同樣的錢你能得到更多的計算資源。
於是你的總花費會因此而減少。
記得之前提到過說很多公司僅僅使用了被分配資源的10%麼？
Kubernetes將會拯救你。
別急，還有更多驚喜。
Kubernetes有一個通常被遺忘或被忽略的殺手級功能。
Kubernetes作為資料中心的API層
你在Kubernetes所做的一切都是你的一個API呼叫。
你需要部署一個容器嗎？有一個REST端點。
也許你想配置負載均衡器？不是問題。只需呼叫此API即可。
你想配置儲存嗎？請傳送POST請求到此URL。
你在Kubernetes所做的一切都是呼叫API。
你肯定會因此而感到興奮：
- 你可以建立以程式設計方式與API互動的指令碼和守護程式 API已版本化;
- 升級群集時，您可以繼續使用舊API並逐步遷移
- 你可以在任何雲提供商或資料中心安裝Kubernetes，您可以使用相同的API
你可以把Kubernetes當作是基礎架構之上的一層。
由於這層是通用的，可以安裝在任何地方，你可以隨意遷移。
亞馬遜網路服務太貴了？
沒問題。
您可以在Google Cloud Platform上安裝Kubernetes並把您的工作負載遷移過去。
或者也許你可以保留兩者，因為高可用性策略總是會派上用場。
但也許你不相信我。因為這件事聽上去太美好了以致於不真實。
讓我演示給你看。
使用Kubernetes節省您的雲賬單
Netlify是一個用於構建，部署和管理靜態網站的平臺。
它有自己的CI管道，因此你對程式碼庫中的程式碼進行更改時，您的網站都會重新構建。
Netlify成功遷移到Kubernetes，使用者數量增加了一倍，但成本仍維持不變。
這真是個好訊息！
想象一下，節省50％的Google Cloud Platform花銷！
但Netlify不是唯一的一個受益者。
Qbox - 一家專注於託管彈性搜尋的公司 - 設法每月在AWS賬單上再次節省50％！
在此過程中，他們還開源了他們在多雲運維方面的實踐。
如果你仍然不感興趣，你應該看看關於OpenAI的新聞。
OpenAI是一家非營利性研究公司，專注於人工智慧和機器學習。
他們寫了一個演算法來讓機器玩一個多人線上遊戲Dota，就像任何人類玩家一樣。
但他們做了一些額外的操作，他們訓練了一組機器一起玩。
他們使用Kubernetes在雲中擴充套件他們的機器學習模型。
想知道他們的叢集的細節？
128000個vCPU
那是大約16000臺MacBook Pro。
256 Nvidia Tesla P100
這是2100 Teraflops 16位浮點效能。
就像你執行525 PlayStation 4s一樣。
你能猜出每小時的費用嗎？
猜不到？
128000 vCPU僅為1280美元/小時，256個Nvidia P100僅為400美元。
考慮到贏得Dota錦標賽可以為您贏得數百萬美元的獎金，這並不是很多。
你還在等什麼？
準備好採用Kubernetes並節省您的雲賬單！
最後的筆記
Kubernetes和容器將繼續流行。
在谷歌，微軟，紅帽，Pivotal，甲骨文，IBM等公司的支援下，你很難相信它不會流行起來。
許多公司正在開始使用Kubernetes並加入這場革命。
不只是創業公司和中小企業，而是像銀行，金融機構和保險公司這樣的大公司都在押注容器，而Kubernetes則是未來。
甚至公司也將這項技術應用於物聯網和嵌入式系統。
現在還處於早期階段，社群仍需時間成熟，但你應該密切關注這個領域的創新。
原文連線：ofollow,noindex" target="_blank">什麼是Kubernetes？優化您的託管成本和效率
==============================================================================
譯者介紹
Grace，程式設計師，研究生畢業於SUNY at Stony Brook，目前供職於Linktime Cloud Company，對大資料技術以及資料視覺化技術感興趣。