《代碼英雄》第一季（5）：容器競賽

本文是《代碼英雄》系列播客第一季（5）：容器競賽的音頻腳本。

容器的興起為開發者們打開了一道新的大門，它簡化了在機器與機器之間傳遞項目的成本。隨著它變得廣受歡迎，一場大戰也悄悄拉開帷幕。這場戰鬥的獎品是容器編排的控制權，參賽者包括這個行業最快最強的玩家。

容器是開源運動中最重要的一項突破之一。在這一集里，特邀嘉賓 Kelsey Hightower、Laura Frank 和 Clayton Coleman 將告訴我們容器如何為未來添磚加瓦，以及編排技術為何如此重要。

Saron Yitbarek：

你有看過賽馬嗎？賽馬們排成一行，蹄子刨著腳下的土壤。你可以想像出這麼一副畫面。比賽即將開始，在這些競爭者中脫穎而出的將是優勝者。

00:00:30：

不同的是，比賽的不是馬。而是科技世界的諸侯。那麼是什麼讓比賽如此重要？是怎樣的珍貴的獎勵，才會讓這些參賽者們排著隊，迫不及待地想要得到它? 這是一場贏家將掌握容器編排技術規則的競賽，而且勝利者只有一個。重要的是，不同於其他的比賽，贏得這場比賽，你不僅僅會成為今天的冠軍，更有可能在來持續領先。

00:01:30:

我是 Saron Yitbarek，這裡是代碼英雄，一款紅帽公司原創的博客。

第五集，容器競賽。上一集我們見證了 DevOps 的崛起，以及一組新工具如何影響了其他人對開發者這一概念的看法。在這一集欄目中，我們會追溯容器技術崛起的歷史，講述容器技術如何通過擁有支持全新工作的可能性，來進一步擴展開發者這一角色的概念。然後我們會一起見證容器標準化是如何為容器編排奠定比賽基礎的。

00:01:30：

這是一場嚴肅的比賽，也是一場全球性的比賽，吸引了行業里最快，最強大的選手。他們都準備好了為衝刺終點線而奮力一搏。準備好了嗎? 比賽開始了！

現在，隨著這些「賽馬」離開起點，也許我們應該弄清楚為什麼這場比賽如此重要。誰會關心容器呢？好吧，算我一個。但是實際上，一開始我也並不知道容器是什麼。以下我將講述一個小故事 —— 我是如何醒悟容器之美的。

00:02:00：

不久之前，我還在為我網站寫代碼，然後有天我讓我的朋友 Nadia 過來實現一些新的功能。我在保持代碼乾爽和可讀性方面做得很好，當然，代碼也經過了很好的測試。所以再加入一個新的網站開發者也不是一件難事。對嗎？如果你也這樣以為，那就錯了。這是一個非常繁瑣的過程，特別是當我們跑規範化測試時，這個問題尤為明顯。

00:02:30：

代碼運行正常，但我們不能在兩台電腦上同時通過所有測試。我們有很奇怪的電腦時區設置問題，而且她的 Ruby on Rails 版本跟我的不同。就是一個很經典的問題：「我的電腦上可以代碼運行」，「可是在我的電腦上就是不行」。我只好對代碼做一些修改，直到它在我這裡正常運行，但當我把它發送給 Nadia 時，程序又會崩潰。

00:03:00：

我很清楚，我和 Nadia 所碰到的這些問題，對於所有的開發者來說都或多或少經歷過，甚至他們把這種經歷當作玩笑來講。有時候，我只能把這個當做是在我工作時必須要忍受的一部分。我沒有意識到的是，這個問題有個最終解決辦法。想像有一種方式可以降低人與人之間的隔閡；想像有一種方法可以讓我們在開發中使用任意喜歡的工具，並且在傳遞工作成果時毫無阻礙；想像一下有一種辦法，無論有多少人同時進行一個項目的開發，不管這些人散布在世界何地，都可以讓項目從開發到測試，再到生產環境，保持連貫性。如果在我浪費好幾周，用最笨的方式傳遞工作成果前就想到了容器該多好。

00:03:30 - Liz Rice：

一個容器實際上就是一個進程。

Saron Yitbarek：

Liz Rice 是 Aqua Security 的一名技術佈道師。她描述了為何容器會如此實用。事實上容器把一切打包到了一個整潔、並且可以遷移的包中。

00:04:00 - Liz Rice：

這就像任何其他的進程一樣，不同的是容器的世界非常小。比如，如果你啟動一個容器，進程會被授予它自己的根目錄。然後它認為自己在查看的是整台計算機的根目錄，但實際上它只是在查看這個文件系統很小的一個子集。

00:04:30 - Saron Yitbarek：

通過打包一個可執行文件及其所有的依賴，容器可以在任何筆記本或者雲中的虛擬機上運行。帶著它自己的執行文件、庫和依賴。所有的一切都包含在了容器中。所以，這就是容器神奇之處，容器在每個環境中的運行都會完全一樣。這也就意味著開發者可以輕鬆地分享並協作應用開發，而不用擔心計算機之間相互不兼容這個老問題。

00:05:00：

舉一個類比的例子希望能夠幫助你理解。你有聽說過 藍圍裙 Blue Apron 這個服務嗎？該服務提供你做飯所需的一切，包括精心按照菜譜卡片搭配好的，所有做飯需要的原料。好的，想像一下如果藍圍裙所能帶給你的不僅僅只是還沒有處理過的食材，而是一整個廚房，有煤氣灶，還有你所需要的全部餐具，一切你需要的都會裝到小盒子里，放在門階上。這就是一個容器。在我提到的那種情況下，容器技術就可以很好地解決 Nadia 加入進來時所碰到的問題，簡單到像使用藍圍裙服務做一頓晚餐一樣。虛擬機同樣也可以提供一個預裝好的環境。但要解釋這個，我們就不得不拋棄藍圍裙這個比喻，讓我們來看一看具體的細節。

00:05:30 - Liz Rice：

許多人都認為容器是某種輕量級的虛擬化技術、輕量級的虛擬機，事實上並不是。容器與虛擬機有很大不同。虛擬機有獨屬於自己的一整個操作系統，相比起來容器是共享操作系統的。一個計算機上的所有容器共享同一個操作系統的。

00:06:00 - Saron Yitbarek：

最後一點，容器和虛擬機可以並肩工作。容器不能替代虛擬機。虛擬化技術仍然可以提高過時系統的效率，並且對於伺服器整合非常關鍵。但容器技術的興起也為我們打開了新的大門。不妨這樣想，如果我們全部依靠虛擬機的話，運行所有模擬伺服器將產生大量的額外負擔。

00:06:30：

一台虛擬機的大小至少是以 G 為單位的，然而一個容器可能也就只有 20 M 左右。一台虛擬機可能會需要若干分鐘來啟動，如果我嘗試用它部署一個網頁應用的話，這可不是一個好消息。很長時間以來，人們都期盼一個輕量級的、更快速的完整機器虛擬化替代方案出現。

00:00:07：

回顧一下歷史，1979 年就出現了容器的原型。Unix V7 的開發者們設計了一種根系統調用，使環境中只包括特定的程序。該突破為我們現在看到的容器技術指明了道路。另一個巨大的進展來源於 2008 年的 Linux 容器技術。現在，我們有了操作系統級的虛擬化技術。

00:07:30：

我們終於可以在一個單獨的 Linux 內核上運行多個容器，而無需使用完整的虛擬機。這也就意味著程序對於基礎架構的需求逐漸減少，但不是每一個人都能立馬看到容器技術的潛力。

Laura Frank：

容器化真的是前所未有的、嶄新的一個天才般的想法。

Saron Yitbarek：

Laura Frank 是 CloudBees 的技術總監。

00:08:00 - Laura Frank：

只有少部分人了解容器技術的來龍去脈，並可以運用它。不過相信隨著時間的推移越來越多的人會接觸到容器化的概念，隨著越來越多的人開始使用這項技術，並且這些知識通過工程團隊和工程組織，通過社區進行傳播，就會變得更容易獲得。

Saron Yitbarek：

因為和我們之前提到的與虛擬機的相似性，Laura 認為，因為我們之前提到的容器技術與虛擬機的相似性，容器的潛力被低估了。

00:08:30 - Laura Frank：

我在回想我的職業生涯，那是我還只是個普通的日常技術人員。如果你不是一個系統管理員或者 Linux 資深用戶的話，容器還是一個你剛剛了解到的全新概念。我把它理解為使用一台虛擬機模式類似的東西，我可以去建立一個可以用完即棄的環境，而且這個環境完全獨立，清理之後不留痕迹。

Saron Yitbarek：

容器除了能保持系統整潔之外，其實還大有可為。容器將會革新整個行業，並且隨著開源項目和社區的興起，在不久之後，容器標準化的充分實施將變為可能。

00:09:00 - Scott McCarty：

整個界面已經變得非常簡單。

Saron Yitbarek：

Scott McCarty 是紅帽的一名資深的容器策略顧問。他稱得上是這個行業的資深人士，他在容器出現前，甚至是虛擬機出現前，就在做這方面的工作了。

00:09:30 - Scott McCarty：

在互聯網 1.0 時代，我在一家線上零售商工作，我們有上千台實體機，我們用不同的方式，在所有這些不同的伺服器上一遍又一遍地安裝相同的軟體。我們嘗試了所有的方法。當你從原始的操作系統遷移到虛擬機，然後再到 Linux 容器、Solaris 容器，同樣的問題一再出現，你仍然不得不在不同的虛擬機，或者類似操作系統實例的結構體之間管理配置。

Saron Yitbarek：

一旦容器變的規範化，一切都將改變。

00:10:00 - Scott McCarty：

比如，有了很多非常標準化的方式可以去處理現在這些打包好的應用，我認為容器技術的出現，從根本上改變了一切。它使得那些應用非常容易使用，而且容器還不會對系統本身造成損害，同時相比虛擬機更加小巧快捷。

00:10:30 - Saron Yitbarek：

藉助 Linux 容器帶來的進步，這些新的開源項目和社區使得開發者們可以更好地攜手合作。很多我們對於後端的焦慮都被一掃而光。突然間，容器和由它促進的微服務變得十分有吸引力。一旦一種共同的容器語言出現了，障礙就消失了，與此同時容器技術改變了我們的工作方式，也改變了我們學習新技術的步伐。

00:11:00：

還記得之前我和同事 Nadia 遇到的反覆出現的問題嗎？「在我這代碼能跑」的場景？在容器的世界，這個問題將不復存在。相比於我們之前使用的標準的操作系統，開發者社區見證了容器是如何變得更加快速，成本低廉，並且容易使用的 —— 比傳統操作系統更加容易。容器技術被採納的速度十分驚人。但是要記得：容器標準的出現僅僅是容器編排這場競賽的熱身。

賽馬們已經整齊排列好，隨著信號槍一聲令下，它們為了這場比賽的冠軍而拼盡全力。競爭的不是容器本身，而是我們部署和管理容器所使用的工具。

00:11:30：

我是 Saron Yitbarek，這裡是代碼英雄。在這場標準容器編排競賽中，哪位會勝出成為管理所有容器的平台呢？起初有兩位競爭者處於領先地位。

00:12:00：

由 Apache 駕馭的 Swarm，和 Docker 駕馭的 Mesos。但是等等，怎麼？現在出現了一匹黑馬改變了這個格局，那就是谷歌。Linux 設立了雲原生計算基金會（CNCF），隨後 CNCF 推動了谷歌開源的編排引擎 Kubernetes。

00:12:30：

現在，相比 Kubernetes，Mesos 和 Swarm 已經搶佔了先機，對嗎？它們得到了 Apache 和 Docker 的支持，已經入場了一段時間了。但是 Kubernetes 有其他的「賽馬」所不具備的優勢。Clayton Coleman 會告訴我們這個秘密是什麼。Clayton 是紅帽負責 Kubernetes 和 OpenShift 的一名架構師。

00:13:00 - Clayton Coleman：

在 Kubernetes 誕生之初，谷歌就在項目的開放上做的很好，它降低了項目的貢獻和參與的難度。谷歌極其關注讓開發者和運維人員能更加容易地開展工作。有這樣一個強烈的關注點，就是要做一個能讓大多數開發者和運維的生活更輕鬆的東西。我覺得 Kubernetes 和圍繞著Kubernetes 的社區找到了一個足夠好的方式，讓大部分人參與進來，他們讓 Kubernetes 具有足夠的可擴展性，還可以解決一些極端的用例。

Saron Yitbarek：

在早期，來自於紅帽、CoreOS 和谷歌的工程師們都參與到了 Kubernetes 的開發中。隨著 Kubernetes 開發到 1.0，不管是初創公司還是大公司都參與其中，一起構建和完善它。關鍵的是，所有這些增長從來都不是只歸功於谷歌或者任何一方。

00:13:30 - Clayton Coleman：

在這個例子中，我喜歡以 Linux 打比方。Linux 並不是始於 Linus 開始編寫內核，然後告訴所有人，在用戶空間如何寫 GCC，如何去建立 NGINX 或者 Apache。相反，內核團隊專註於建立一個高效的操作系統內核，並與其他諸如 GNU 項目的開源社區合作，並且將可以在其他 Unix 系統上工作的工具引入 Linux。

00:14:00：

因此，我們如今所使用的許多工具，都不是 Linux 核心團隊交付的。

但是 Linux 作為一個整體，相比於其內核涵蓋的範圍要寬泛得多，而且我認為這種模式的優勢是 Kubernetes 取得現在成就所不可或缺的。當我們建立社區並且專註於 Kubernetes 範圍時，我們可以試圖從「Kubernetes 內核」的角度來考慮它，這是分散式集群操作系統的內核。

00:14:30 - Saron Yitbarek：

Kubernetes 證明了自己在開源世界中建立社區的能力，令人難以置信。正如我們在操作系統之戰中談到的 Linux 崛起一樣，現如今這場關於容器的戰爭中，獲勝者往往懂得如何藉助社區力量。事實上，儘管谷歌可能開創了 Kubernetes，但目前它屬於每一位開發者，並由雲原生計算基金會（CNCF）管理。

00:15:00：

在 GitHub 上，Kubernetes 有大約 3 萬的星標數，而 Swarm 和 Mesos 只有數千，這已經很能說明問題了。這就是由社區所生，為社區所用的技術。

我想了解谷歌的態度，一個如此龐大並且以效益為導向的大公司，是怎麼做到如此擅長跟其他開發者合作的呢？我找到了很適合回答這個問題的人 —— Kelsey Hightower，他是谷歌負責容器技術支持的技術專家。

00:15:30：

想想谷歌的地位：它在分散式系統領域具備豐富的經驗，還運行著分布在世界各地的許許多多的伺服器，因此它開發的 Kubernetes 似乎有著很大的優勢，並且有信心一定能在這場容器競賽中勝出。那麼，當你想到 Kubernetes 和開源時，你是如何看待這種關係的？

00:16:00 - Kelsey Hightower：

我想當談到基礎架構工具，甚至編程語言時，大家沒有什麼選擇 —— 你不可能用個專有工具，即使它很棒。如果它不是開源的，大多數人可能甚至都不會想去了解。而且我認為這也是大多數人會採用像 Kubernetes 這樣的基礎架構工具的原因，你可能會對自己說：「好吧，我們就要堅持使用這個版本四、五年，也可能我們需要根據自己的一些獨特需求來對其進行修改。」

00:16:30：

一旦走到這一步，就很難說服企業接受，「嘿，每台伺服器使用程序的價格是 200 美元，而且你看不到源代碼，所以有需要的話也必須等我們來修改」。

那樣的日子一去不復返了，所以我不確定是否真的可以在沒有開源的情況下建立基礎架構。開源的另一個意味是擁有一個與項目緊密聯合的社區，所以我認為 Kubernetes 一開始就鎖定了勝利。

Saron Yitbarek：

讓我們回到這場容器競賽。在這裡不僅僅有你提到的 Kubernetes，還有 Docker 的 Swarm Apache 的 Mesos……

00:17:00 - Kelsey Hightower：

所以，我想當人們談論容器競賽時，我不確定競爭是否發生在我們和 Mesos、Docker 使用者之間。我認為，真正的競爭發生在爭取目前沒有使用容器的潛在用戶身上。是的，你還在使用原生 Bash 腳本，你迷茫著，不知道自己該歸屬何方。這些尚未選擇編排工具和平台之人的市場，比起已選擇了 Mesos 或 Swarm 的一方，要多得多。

00:17:30：

這就是容器戰爭存在並將繼續的原因，真正的關鍵點在於如何幫助最終用戶。Mesos、Kubernetes 或 Docker Swarm 是否會成為尋求更好解決方案的人們的首選？這一切都還懸而未決（SIG 譯註：現在已經塵埃落定，Kubernetes 取得了全勝），但我會告訴你，像我一樣，在這個領域工作的工程師來說，如果你不考慮市場營銷和供應商，我會使用這個短語「不同的公司，相同的團隊。」

00:18:00：

我們為彼此開發了許多工具，最終以某種方式出現在其他產品中。沒錯吧？好主意就是好主意。沒有理由說，「哦，這是 Mesos 的人正在做的事情，那就忽略吧」，這有點愚蠢。所以從技術和社區的角度來看，我們的想法需要交流。同時也需要競爭來迫使我們來進行獨立思考，然後最棒的點子就會浮出水面，接著我們再選擇採用哪種方式來正確滿足用戶的需要。

00:18:30：

因此，就這場競賽而言，仍處於初期階段，而且這個事情本身不會帶來利潤。明白我的意思嗎？我們不是直接向任何人銷售這個產品，這更像是一個平台之間的遊戲，對所有人開放，然後用戶會選擇滿足他們需求的那個，這就是我認為 Kubernetes 在社區方面做得很好的地方，真正開放，真正能解決實際問題。

Saron Yitbarek：

聽起來很棒啊。我喜歡這個想法：在同一個球隊踢球，而不要管球隊是在什麼地方。你對於容器和編排工具，還有 Kbubernetes 的未來有什麼展望嗎？

00:19:00 - Kelsey Hightower：

是的，我在 KubeCon 上做了一次主題演講。所有這些工具都很棒，它們就像是樂高積木，我們有 Kubernetes，你可以選擇一種產品用於安全，選擇另一種產品用於網路，但最終，作為開發人員而言，你所想要的只是檢查你的代碼，並希望你的代碼可以某種方式以呈現在客戶面前。而我認為 Kubernetes 還有容器都會作為底層技術或者成為類似 Serverless 這種技術的基礎平台。

00:19:30：

這是我的代碼片段，已經打包完畢了。所有的平台都會把你的代碼片段，用容器包裝起來，然後幫你運行，但是不需要向你公開所有這些過程。因此，在未來，我認為隨著 Kubernetes 變得普及，容器的應用場景將從大大小小的供應商或個人，提升到雲供應商，因為這些事情往往需要專業知識和軟體投資。容器將會遍布各個角落，但同時也就此隱藏起來。它會隨著應用場景的擴展而漸漸隱形。

00:20:00 - Saron Yitbarek：

Kelsey Hightower 是 Google 的員工開發人員。在 2017 年秋天，Docker 宣布支持 Kubernetes。他們並不是說就放棄 Swarm 了，只是決定與容器編排競賽的明顯贏家和解。

00:20:30：

並不只有它一方，Azure 和 AWS 都宣布了對 Kubernetes 的支持。與此同時，像 OpenShift 這樣的 Kubernetes 發行版仍在不斷發展。我們得到的是一個可以擴展，支持新的用例的 Kubernetes 內核，這些用例包括微服務或持續集成項目。

00:21:00 - Clayton Coleman：

這個生態系統在類似 Linux 的模式下能得到最好的發展，而且我認為我們正朝著這條道路邁進。因此，就像所有優秀的開源項目一樣，相對於單打獨鬥，讓每個人都能夠參與進來構建更好的東西，那就算是成功了。

00:21:30 - Saron Yitbarek:

所有這一切都在快速發生著，畢竟，這是一場競賽，而這正是我們期望能從開源中獲得的東西。在我們才剛剛理解什麼是容器時，第一輪幾乎就結束了，

這是來自 Red Hat 的 Scott McCarty。

Scott McCarty：

回想一下兩年前，容器鏡像格式還是一個巨大的戰場，然後回到六個月至一年前，容器編排就成為了下一個巨大的戰場。緊接著，如果你看看 2017 年的 KubeCon 及前幾周，幾乎每個主要供應商都宣布支持 Kubernetes。因此，很明顯 Kubernetes 在這一方面上獲勝了。

00:22:00 - Saron Yitbarek：

這章關於容器戰爭的故事即將結束。就像容器技術的開始一樣迅速。

Scott McCarty：

因此，Kubernetes 已經成為標準，其美妙之處是，現在的應用定義已經變得標準化了。因此，任何人都可以在這些 YAML 文件中使用 Kubernetes 對象並定義應用，這就是我們共同所追求的事情。事實上，對於容器技術足夠處理處理大型擴展系統這件事，我已經期待了 20 年。

00:22:30 - Saron Yitbarek：

Kubernetes 的成功看起來板上釘釘，但即使競賽塵埃落定，我們仍然面臨更大的一些問題。容器是否會成為未來幾年的默認選擇？是否會促使更多的雲原生開發？這些轉變將促生哪些工具和服務上？以下是我們目前所知道的。

00:23:00：

社區將通過 CNCF 繼續改進 Kubernetes，並作為它最重要的使命之一，我們將建立一套全新的容器技術。

容器已經催生了大量新的基礎設施，伴隨而來的是全新的服務的需求。舉個例子讓你感受下容器的整合程度和發展速度，僅 Netflix 每周就運行超過一百萬個容器。毫不誇張得說，容器是未來的構件。

00:23:30：

這一整季的欄目中，我們一直在追蹤開源運動的演變。首先看到 Linux 如何主導戰場，以及開源理念是如何改變商業、工作流程和每日使用的工具。容器真的是開源運動中最重要的里程碑之一。它們具有很好的遷移性、輕量、易於擴展。

00:24:00：

容器技術很好地體現了開源的優勢，開源項目自然而然也推動了容器技術的發展。這是一個全新的世界，我們不用再擔心從不同計算機或者雲間的遷移產生的隔閡。

00:24:30：

容器的標準化比任何人預測的都要快。接下來的一集，我們將轉向另一場懸而未決的戰爭。這場雲間戰爭史無前例地催生者行業重量級人物。微軟、阿里巴巴、谷歌和亞馬遜四家雲供應商的摩擦正在升溫，隨之而來的將是一場暴風驟雨。我們將會追隨它們激發的閃電，和廣受歡迎的幾位代碼英雄一起探討雲間戰爭。

00:25:00：

《代碼英雄》是紅帽公司推出的原創播客欄目。想要了解更多關於本期節目和以往節目的信息，請訪問 redhat.com/commandlineheroes 。在那裡，你還可以註冊我們的新聞資訊。想免費獲得新劇集的自動推送，請務必訂閱該節目。

只要在蘋果播客、Spotify、Google Play、CastBox 中搜索 「Command Line Heroes」，或者通過其他方式收聽，並點擊訂閱，這樣你就能在第一時間知道最新劇集。我是 Saron Yitbarek。感謝您的收聽，編程不止。

什麼是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特別興趣小組 Special Interest Group ，LCTT SIG 是針對特定領域、特定內容的翻譯小組，翻譯組成員將遵循 LCTT 流程和規範，參與翻譯，並獲得相應的獎勵。LCRH SIG 是 LCTT 聯合紅帽（Red Hat）發起的 SIG，當前專註任務是《代碼英雄》系列播客的腳本漢化，已有數十位貢獻者加入。敬請每周三、周五期待經過我們精心翻譯、校對和發布的譯文。

歡迎加入 LCRH SIG 一同參與貢獻，並領取紅帽（Red Hat）和我們聯合頒發的專屬貢獻者證書。

via: https://www.redhat.com/en/command-line-heroes/season-1/the-containers-derby

作者：Red Hat 選題：bestony 譯者：lujun9972 校對：acyanbird

本文由 LCRH 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive