編輯：阿冒

設計：沐由

全社會、全民邁向數字化的當下，1億月活（MAU）的App已不鮮見，不要說一些我們日常離不開的軟件，哪怕是像知乎這樣的知識平臺，也已經做到了月活過億。

(相關資料圖)

即便如此，在這些明星App中卻少有App能夠承受每秒100萬次以上的查詢——不過凡事總有例外，Skyscanner是一款可搜索超過1000家航空公司上百萬條航路的應用，一旦臨近假期，Skyscanner的每秒查詢量會迅速飆升到每秒百萬級的巨大體量。

你看不到的是，Skyscanner會在最短時間內迅速調動1000臺服務器+3W多個pods，為全球客戶的查詢提供支持，幫助你在最短時間內找到最快捷、最便宜的機票……

你也一定不會相信，所有這一切龐大資源從容調度的背后，Skyscanner居然只配置了區(qū)區(qū)6名維護工程師。究竟是公司BOSS太摳門，還是說隊伍中暗藏了掃地僧一樣的大神？

來自開源社區(qū)的明星技術

其實，Skyscanner的秘密說來很簡單：Kubernetes。作為一種用于管理云平臺上容器化應用的開源技術，Kubernetes為現(xiàn)代化應用的規(guī)劃、部署、更新和維護帶來了革命性的新機制。

興許是為了方便起見，國內技術圈的大佬們將Kubernetes簡稱為K8s，8代表了被省略的8個字母ubernete——如此神奇的腦回路令人百思不解，不過這并不妨礙K8s的風行。

此前的模式下，應用的部署一般通過插件或腳本來安裝進行，表面上無需專業(yè)技術人員介入，但是卻導致應用與操作系統(tǒng)綁定，而且很難進行應用的升級/回滾等操作。

K8s的強大在于，容器的啟動速度極快、占用資源極少、部署速度極快，打包更方面，帶來了更好的開發(fā)體驗，讓微服務變得愈發(fā)簡單，而且應用的監(jiān)控與管理也變得前所未有的高效……

以上，當然只是K8s的鳳毛麟角而已，更多益處本文也不作贅述。如果K8s帶來的只有美好，那自然再也美滿不過，然而事物的兩面性存在于任何事物之上，K8s亦不能例外。

事實上，盡管在企業(yè)的業(yè)務創(chuàng)新與管理方面，buff疊滿的K8s令人無限期待，不過就算是那些頗具技術實力的企業(yè)，在面臨自建容器集群時也必然會頭皮發(fā)麻。

作為來自開源社區(qū)的明星技術，K8s的背后是成千上萬的代碼提交者和貢獻者，以及超過1000+的廠商，勢必就造成了諸多的發(fā)行版本，而且社區(qū)自身也大約會每隔三個月就發(fā)布一個次要版本。

即便是做好版本管理，并建立了容器集群之后，企業(yè)仍舊有大量的技術工作要做：兼容性測試、安全驗證、網絡適配等等，以及與系統(tǒng)對接之類的“業(yè)務工作”，不一而足。

沒錯，我們也能列舉出關于K8s的大量DeBuff，不過這并非是本文的目標，我們只是想說明，企業(yè)熱切希望利用K8s為在自身目標帶來有效的提升，但是他們在“核心業(yè)務”之外要做的工作，實在是有點太多，而且難以把控。

這樣看來，我們本節(jié)開始給出的答案就有些不嚴謹，甚至是不正確了，因此我們要為之加上一個前提，即Skyscanner仰仗的神器并不是普通的K8s，而是Amazon EKS（Elastic Kubernetes Service）。

讓容器操作與管理得心應手

Amazon EKS是亞馬遜云科技的一項托管服務，提供高度可用、可擴展且安全的Kubernetes服務。作為社區(qū)的積極參與者和貢獻者，Amazon EKS與上游Kubernetes保持100%兼容——這一點非常重要。

很多廠商往往對開源項目進行“魔改”，所謂的“魔改”，是通過一定程度上對于軟、硬件的修改，以使其在功能上得到加強或優(yōu)化，暫時達到或接近客戶的需求，雖然在當前的很多數字化項目中并非常態(tài)，但是卻不鮮見。

然而，“魔改”畢竟是違反了設計者原先的技術設想與體系架構，必然會帶來穩(wěn)定性、安全性等一系列問題，并且很有可能導致不可預知的嚴重后果。

亞馬遜云科技不會做任何的“魔改”。也就是說，上游的Kubernetes是什么樣，亞馬遜云科技均會以云原生的形式，將之在云上進行嚴格的適配和移植，從而確?？蛻舻臉I(yè)務應用可以在其中完美地運行。

無論何時，Amazon EKS保證至少支持四個生產就緒版本的 Kubernetes。與此同時，Amazon EKS還提供了14個月的版本技術支持，明顯長于社區(qū)的9個月，這就意味著哪怕是社區(qū)不再支持的版本，照樣可以在Amazon EKS上得到支持。

Amazon EKS架構示意圖

對于像Kubernetes這樣的軟件來說，從開源社區(qū)走出來到進入到最終的生產環(huán)境，其實中間還有很長的一段路要走，包括跟云上的安全等能力進行結合，與其他組件的兼容性測試、網絡適配等過程，客戶往往需要做一大堆類似“重復造輪子”的工作。

Amazon EKS則不然，亞馬遜云科技的技術和服務隊伍已經幫助做了以上各類繁復和枯燥的工作。得益于此，客戶可以直接將他們的精力與資源全部投入到自己的容器業(yè)務上，輕松構建可靠、穩(wěn)定和安全的應用程序。

Amazon EKS帶來的不僅是高性能、可靠和安全的Kubernetes服務，它也使得Kubernetes的操作和管理變得前所未有的簡單起來。

比如，在令人望而卻步、頭皮發(fā)麻的集群管理方面，Amazon EKS提供了一鍵式的升級控制平面及數據平面的功能，讓以往復雜的操作簡單易用到極致，而且強大、安全。

按下現(xiàn)代化應用的“加速鍵”

隨著企業(yè)業(yè)務的互聯(lián)網化發(fā)展，大規(guī)模的容器業(yè)務應用已經成為不爭的事實。面對不斷變化的市場，企業(yè)需要與時俱進、推陳出新，永遠有大量的新業(yè)務準備上線。

然而，成百上千的POD啟動必然會帶來很多問題，譬如過度消耗系統(tǒng)資源、嚴重遲滯存儲性能等等……那么，Amazon EKS能夠帶來哪些顯著的提升呢？

在支撐大規(guī)模容器業(yè)務應用方面，Amazon EKS不止擁有高可用架構，還包括了彈性伸縮、共享服務平臺、成本可視化等優(yōu)勢。

以彈性伸縮為例，這里就不得不說到Amazon Karpenter了。作為新一代的Kubernetes自動擴容工具，Karpenter的表現(xiàn)令人驚嘆：它會動態(tài)選擇最適合的計算資源，自動添加或刪除所需的計算資源，進行高性能的規(guī)模測試，等等。

空口無憑，還是讓數字來說話。在Amazon EC2規(guī)格為c5.large的環(huán)境下，從0增加到100的擴容，Cluster Autoscaler需要超過4分鐘，Karpenter僅需2分鐘；從100減少到1的縮容，Cluster Autoscaler需要6分多鐘，而Karpenter僅需30秒。

隨著業(yè)務應用容器化程度不斷加深，越來越多客戶也在基于Amazon EKS構建共享服務平臺，旨在同時兼顧到安全的管控和開發(fā)的靈活性。微服務和容器化的大規(guī)模使用加速了業(yè)務應用迭代上線的速度，方便了開發(fā)人員，但是從運維的角度而言，也對其所需云資源的快速按需配置供給以及安全合規(guī)管控方面帶來了挑戰(zhàn)。

客戶通過在Amazon EKS上構建共享服務平臺，平衡了開發(fā)和運維的沖突。而共享服務平臺在本質上是運維事先定義好可用模板，其中包括數據庫、節(jié)點規(guī)模等，開發(fā)人員可以按需取用，真正做到讓運維與開發(fā)“相視一笑泯恩仇。

其實，以上的各種神奇均建立在IaaS（基礎設施即代碼）之上。由于這種代碼庫式，客戶只需要簡單的幾行代碼，甚至比擺積木還簡單，就可以快速部署起龐大而高效的基礎設施。

目前已經有數十萬客戶正在借助亞馬遜云科技Amazon EKS 平臺，交付和運行著數不勝數的現(xiàn)代化應用。在構建共享服務平臺方面，Amazon EKS提供了Blueprints解決方案，與常用的Kubernetes生態(tài)工具鏈集成，高度可擴展、可定制，滿足各種現(xiàn)代化應用的嚴苛要求。

在數字化的發(fā)展大潮中，越來越多的企業(yè)正在脫穎而出。得益于亞馬遜云科技提供的一系列服務，初創(chuàng)企業(yè)同樣可以基于最先進的基礎設施和更優(yōu)的成本控制，實現(xiàn)創(chuàng)業(yè)夢想。

關鍵詞：