大約兩年前，我們決定放棄在 EC2 平臺中基于 Ansible 配置管理工具部署應(yīng)用程序，并轉(zhuǎn)向容器化和 Kubernetes 技術(shù)棧，使用 Kubernetes 進行應(yīng)用程序編排?，F(xiàn)在我們已將大部分基礎(chǔ)架構(gòu)遷移到 Kubernetes。這是一項艱巨的任務(wù)，也有它自己的挑戰(zhàn)——從遷移進行之時運行混合基礎(chǔ)設(shè)施的技術(shù)挑戰(zhàn)，再到用全新的操作范式培訓(xùn)整個團隊等等，不一而足。
在這篇文章中，我們將回顧我們的經(jīng)驗，并分享我們從這一過程中學(xué)到的東西，以幫助你做出更好的決定，增加你成功的機會。
遷移到 Kubernetes 的原因
無服務(wù)器技術(shù)和容器技術(shù)都很好，如果您要開始一項新業(yè)務(wù)并從頭開始構(gòu)建所有應(yīng)用，請務(wù)必使用容器來部署應(yīng)用程序。如果你擁有足夠帶寬（或可能不具備，請繼續(xù)閱讀），并擁有配置和操作 Kubernetes 以及將應(yīng)用部署到 Kubernetes 的技術(shù)能力，請使用 Kubernetes 來編排你的容器化應(yīng)用程序。
即使您在 EKS、GKE 或 AKS 之類的托管平臺上使用 Kubernetes，在其上正確部署和操作應(yīng)用程序也具有一定的學(xué)習(xí)曲線。您的開發(fā)團隊應(yīng)該應(yīng)對挑戰(zhàn)。只有您的團隊遵循 DevOps 理念，才能帶來很多好處。如果您所處的情況是，由系統(tǒng)管理團隊為其他團隊開發(fā)的應(yīng)用程序編寫部署清單，那么從 DevOps 的角度來看，我個人認為 Kubernetes 能夠帶來的好處較小。當然，選擇 Kubernetes 可以為您帶來許多其他好處，例如更低的成本、更快的實驗、更快的自動縮放、彈性等。
如果你已經(jīng)在云平臺虛擬機或其他 PaaS 平臺上部署應(yīng)用，那么你真的要考慮從現(xiàn)有的基礎(chǔ)設(shè)施遷移到 Kubernetes 嗎？你確信 Kubernetes 是解決你的問題的唯一途徑嗎？你必須清楚你的動機，因為將現(xiàn)有的基礎(chǔ)設(shè)施遷移到 Kubernetes 是一項艱巨的任務(wù)。
我們在這方面犯了一些錯誤。我們遷移到 Kubernetes 的主要原因是為了建立一個持續(xù)集成的基礎(chǔ)架構(gòu)，該基礎(chǔ)架構(gòu)可以幫助我們快速重構(gòu)微服務(wù)。這些年來，這些微服務(wù)在架構(gòu)方面逐漸積累了很多問題，因而需要重構(gòu)。大多數(shù)新功能都需要修改多個代碼庫，因此，同時開發(fā)和測試所有這些微服務(wù)的工作會拖累我們的速度。我們認為有必要為每個開發(fā)人員和每個變更提供一個集成環(huán)境，以幫助加快開發(fā)和測試周期，而無需協(xié)調(diào)誰來獲得“共享預(yù)發(fā)布環(huán)境”。
我們的持續(xù)集成流水線之一，可為所有微服務(wù)提供新的集成環(huán)境并運行自動化測試
我們現(xiàn)在做得很好。今天我們可以在 8 分鐘內(nèi)在 Kubernetes 上的集成環(huán)境中部署 21 個微服務(wù)。任何開發(fā)人員都可以使用我們自己開發(fā)的工具來執(zhí)行此操作。我們還為這 21 個微服務(wù)中的任何一個創(chuàng)建的拉取請求都提供了這個環(huán)境的子集。整個測試周期（提供環(huán)境和運行測試）需要不到 12 分鐘的時間。這可能感覺很長，但它可以防止我們在當前混亂的架構(gòu)中交付糟糕的更改。
持續(xù)集成流水線執(zhí)行報告
Kubernetes 的遷移方式
我們花了將近一年半的時間讓這一復(fù)雜的持續(xù)集成流水線穩(wěn)定運行，我們構(gòu)建了額外工具，創(chuàng)建遙測工具并重新配置了每個應(yīng)用程序的部署方法。為了開發(fā)和生產(chǎn)環(huán)境的一致性，我們也必須將所有這些微服務(wù)部署到生產(chǎn)環(huán)境中，否則基礎(chǔ)設(shè)施和部署應(yīng)用之間的偏離將使應(yīng)用程序難以為開發(fā)人員所理解，并將使開發(fā)人員的運維成為一場噩夢。
我們對這個話題有復(fù)雜的感覺?；仡欉^去，我們認為我們解決持續(xù)集成的方式使問題變得更糟了，因為將所有微服務(wù)推向生產(chǎn)環(huán)境（為了開發(fā) / 生產(chǎn)環(huán)境一致性）的復(fù)雜性使得實現(xiàn)更快的持續(xù)集成構(gòu)建這一目標變得更加復(fù)雜和困難。在使用 Kubernetes 之前，我們使用 Ansible 和 Hashicorp Consul 以及 Vault 來提供基礎(chǔ)設(shè)施、配置管理和部署。它們是緩慢的嗎? 當然是。但我們認為，我們本可以在 Consul 中引入服務(wù)發(fā)現(xiàn)，并對 Ansible 部署進行一些優(yōu)化，這樣我們可以在相當短的時間內(nèi)接近我們的目標。
我們應(yīng)該遷移到 Kubernetes 嗎？答案當然是肯定的。使用 Kubernetes 有幾個好處，包括服務(wù)發(fā)現(xiàn)、更好的成本管理、彈性、治理、云基礎(chǔ)設(shè)施的基礎(chǔ)設(shè)施抽象等等。我們今天也獲得了所有這些好處。但這并不是我們開始時的主要目標，而且實現(xiàn)這些的過程中所產(chǎn)生的壓力和痛苦也許是不必要的。
對我們來說，一個重要的教訓(xùn)是，我們本可以選擇一條不同的、阻力較小的道路來采用 Kubernetes。我們只是把 Kubernetes 作為唯一的解決方案，我們甚至沒有評估其他選擇。
我們將在這篇文章中看到，將應(yīng)用遷移到 Kubernetes 并在其上操作與將應(yīng)用部署在云平臺虛擬機或裸機上是不同的。對于您的云工程師和開發(fā)團隊來說，這會有一個學(xué)習(xí)曲線。讓您的團隊學(xué)習(xí)這些技術(shù)可能是值得的。但問題是，你現(xiàn)在需要這么做嗎？你必須盡量清楚的回答這一問題。
開箱即用的 Kubernetes 還遠遠不夠
很多人錯誤的認為 Kubernetes 是一種 PaaS 解決方案，事實并非如此，Kubernetes 是一個用于構(gòu)建 PaaS 解決方案的平臺。OpenShift 就是這樣一個例子。
對幾乎所有人來說，開箱即用的 Kubernetes 都遠遠不夠。Kubernetes 平臺是一個學(xué)習(xí)和探索的好地方。但是您很可能需要更多基礎(chǔ)設(shè)施組件，并將它們很好地結(jié)合在一起作為應(yīng)用程序的解決方案，以使其對開發(fā)人員更有意義。通常，這一套帶有額外基礎(chǔ)設(shè)施組件和策略的 Kubernetes 被稱為內(nèi)部 Kubernetes 平臺。這是一個非常有用的使用范例，有幾種方法可以擴展 Kubernetes。
指標、日志、服務(wù)發(fā)現(xiàn)、分布式追蹤、配置和 secret 管理、持續(xù)集成 / 持續(xù)部署、本地開發(fā)體驗、根據(jù)自定義指標自動擴展都是需要關(guān)注和做出決策的問題。這些只是我們指出的一部分事情。肯定還有更多的決策需要制定，有更多的基礎(chǔ)設(shè)施需要建立。一個重要的領(lǐng)域是你的開發(fā)人員將如何使用 Kubernetes 資源和清單文件，這篇文章的后面會有更多這方面的內(nèi)容。
以下是我們的一些決策及其理由。
指標
我們最后選擇使用 Prometheus。現(xiàn)在 Prometheus 幾乎是一個事實上的指標基礎(chǔ)設(shè)施。CNCF 和 Kubernetes 對它非常友好。它在 Grafana 生態(tài)系統(tǒng)中工作得很好，我們很喜歡 Grafana！唯一的問題是我們以前使用 InfluxDB。我們已經(jīng)決定拋棄 InfluxDB，并全力轉(zhuǎn)向 Prometheus。
日志
對我們來說，日志一直是一個大問題。我們已經(jīng)努力使用 ELK 構(gòu)建了一個穩(wěn)定的日志平臺。我們發(fā)現(xiàn) ELK 有很多我們團隊用不到的功能，而這些功能是有代價的。同時，我們認為使用 Elasticsearch 處理日志是一個昂貴的解決方案，因而也有潛在的風(fēng)險。我們最后決定使用 Grafana 的 Loki。它很簡單，而且具有我們團隊所需的必要功能。這是非常符合成本效益的。但最重要的是，由于它的查詢語言非常類似于 PromQL，所以它具有優(yōu)越的用戶體驗。而且，它對 Grafana 非常友好，這樣就可以在一個用戶界面中集成指標監(jiān)控和日志記錄。
這是一個 Grafana 儀表盤的例子，它可以同時可視化指標和相應(yīng)的日志
配置和 Secret 管理
你會發(fā)現(xiàn)大多 Kubernetes 項目都使用了 configmap 和 secret 對象。我們意識到 configmap 和 secret 可以作為起點，但卻不足以滿足我們的應(yīng)用場景。對現(xiàn)有服務(wù)使用 configmap 有一定代價。Configmap 可以通過某種方式裝載到 pods 中，使用該方法配置環(huán)境變量是最常見的方式。如果您有大量的遺留微服務(wù)從配置管理工具（如 Puppet、Chef 或 Ansible）提供的文件中讀取配置，那么您將不得不在所有代碼庫中重做配置處理，讓 configmap 從環(huán)境變量中讀取配置。我們沒有找到足夠的理由去做這件事。另外，配置或 secret 的更改意味著您必須重新部署應(yīng)用使其生效。這將需要使用額外的 kubectl 命令來完成。
為了避免這一切，我們決定使用 Consul、Vault 和 Consul 模板進行配置管理?，F(xiàn)在我們將 Consul 模板作為初始化容器（init container）運行，并計劃將其作為 pod 中的旁路（side car）容器，以便它能夠監(jiān)聽 Consul 中的配置更改，從 Vault 刷新過期的 secret，并優(yōu)雅地重新加載應(yīng)用程序進程。
持續(xù)集成和持續(xù)部署
在遷移到 Kubernetes 之前，我們使用的是 Jenkins。遷移到 Kubernetes 后，我們決定繼續(xù)使用 Jenkins。到目前為止，我們的經(jīng)驗是 Jenkins 并不是使用云原生基礎(chǔ)設(shè)施的最佳解決方案。我們發(fā)現(xiàn)為了實現(xiàn)目標，我們需要使用 Python、Bash、Docker 和腳本化或聲明式 Jenkins 流水線做了很多探究工作。構(gòu)建和維護這些工具和流水線一開始十分困難。我們現(xiàn)在正在探索使用 Tekton 和 Argo Workflows 作為我們新的 CI/CD 平臺。您可以在 CI/CD 工具箱中探索更多選項，如 Jenkins X、Screwdriver、Keptn 等。
部署經(jīng)驗
在部署工作流程中有許多使用 Kubernetes 的方法。我們主要將其歸結(jié)為兩種選擇，分別是 Telepresence.io 和 Skaffold。Skaffold 能夠監(jiān)視您的本地更改，并將它們持續(xù)部署到 Kubernetes 集群中。而 Telepresence 則允許您在本地運行服務(wù)，同時在 Kubernetes 集群中設(shè)置透明的網(wǎng)絡(luò)代理，這樣您的本地服務(wù)就可以與 Kubernetes 中的其他服務(wù)通信，就像它部署在集群中一樣。選擇哪種工具是個人的意見和喜好問題。確定使用某一種工具很困難，我們現(xiàn)在主要在嘗試使用 Telepresence，但 Skaffold 可能成為我們更好的工具，我們沒有放棄這種可能性。只有時間能證明我們最終使用哪個工具，又或者兩者都用。此外也還有其他的解決方案，例如 Draft 就是一個值得關(guān)注的選項。
分布式追蹤
我們目前還沒有做分布式跟蹤。不過，我們計劃很快在這個領(lǐng)域進行投入。就像日志記錄一樣，我們希望在 Grafana 的指標和日志記錄旁添加分布式跟蹤，從而為我們的開發(fā)團隊提供一個更集中的可觀測性體驗。
應(yīng)用打包、部署和相關(guān)工具
Kubernetes 中很重要的一個方面是考慮開發(fā)人員如何與集群交互并部署他們的工作負載。我們想讓事情保持簡單并易于擴展。我們正在嘗試使用 Kustomize、Skaffold 以及一些自主開發(fā)的 CRD 來作為開發(fā)人員部署和管理應(yīng)用程序的工具。盡管如此，任何團隊都可以自由地使用他們想要使用的任何工具來與集群交互，只要這些工具是開源的并建立在開放標準之上。
操作 Kubernetes 集群并不容易
我們主要使用 AWS 的新加坡區(qū)域。當我們開始使用 Kubernetes 時，在新加坡區(qū)域還不能使用 EKS 服務(wù)。因此，我們必須使用 kops 在 EC2 上建立自己的 Kubernetes 集群。
配置一個基礎(chǔ)的集群可能并不困難。我們在一周內(nèi)就建立起了第一個集群，而大多數(shù)問題發(fā)生在我們開始部署工作負載時。從調(diào)整集群自動伸縮器（autoscaler）到在正確的時間配置資源，再到正確配置網(wǎng)絡(luò)以實現(xiàn)所需的性能，你都必須自己研究和配置。在大多數(shù)情況下，默認配置在生產(chǎn)環(huán)境中大部分時候都不能正常工作（或者至少在那時無法在我們的場景中正常工作）。
我們的學(xué)習(xí)到的是，操作 Kubernetes 是很復(fù)雜的。它有很多活動部件。而學(xué)習(xí)如何操作 Kubernetes 很可能不是你業(yè)務(wù)的核心。盡可能多地將這些工作卸載給云服務(wù)提供商 (EKS、GKE、AKS)。你自己做這些事并不會帶來價值。
考慮升級
即使您使用的是托管服務(wù)，Kubernetes 也非常復(fù)雜，升級也不會一帆風(fēng)順。
即使在使用托管的 Kubernetes 服務(wù)時，也要盡早進行基礎(chǔ)設(shè)施即代碼的設(shè)置，以使災(zāi)難恢復(fù)和升級過程在未來相對不那么痛苦，并且能夠在災(zāi)難發(fā)生時快速恢復(fù)。
如果你愿意，你可以試著使用 GitOps。如果你不能做到這一點，那么將手動步驟減少到最低限度是一個很好的開始。我們結(jié)合使用 eksctl、terraform 和我們的集群配置清單（包括平臺服務(wù)清單）來建立我們所稱的“Grofers Kubernetes 平臺”。為了使設(shè)置和部署過程更簡單和可重復(fù)，我們構(gòu)建了一個自動化流水線來設(shè)置新的集群并將更改部署到現(xiàn)有的集群。
資源需求和限制
在開始遷移之后，我們發(fā)現(xiàn)由于不正確的配置，集群中出現(xiàn)了許多性能和功能問題。為了解決這些問題，我們添加了很多資源請求和限制，以消除可能導(dǎo)致性能下降的資源約束。
最初的觀察結(jié)果之一是由于節(jié)點的內(nèi)存限制而導(dǎo)致的 pod 驅(qū)逐。其原因是與資源請求相比，資源限制過高。隨著流量的激增，內(nèi)存消耗的增加可能導(dǎo)致節(jié)點上的內(nèi)存耗盡，并進一步導(dǎo)致 pod 被驅(qū)逐。
我們學(xué)習(xí)到應(yīng)該保持資源請求足夠高但不太高，這樣在低流量時我們會浪費一些資源。同時保持資源限制相對接近資源請求，以便為峰值流量留出一些喘息的空間，而不會由于節(jié)點的內(nèi)存壓力而導(dǎo)致 pod 被驅(qū)逐。限制與請求的距離有多近取決于你的流量模式。
這不適用于非生產(chǎn)環(huán)境（如開發(fā)、預(yù)發(fā)布和持續(xù)集成），因為這些環(huán)境不會出現(xiàn)任何流量高峰。理論上，如果將容器的 CPU 請求設(shè)置為零并設(shè)置足夠高的 CPU 限制，就可以運行無限個容器。如果您的容器開始使用大量的 CPU，它們將被限制性能。您也可以對內(nèi)存請求和限制執(zhí)行同樣的操作。然而，應(yīng)用達到內(nèi)存限制后的情形與 CPU 不同。如果您使用的內(nèi)存超過了設(shè)置的限制，那么您的容器會因為內(nèi)存耗盡（OOM）而被殺死并重新啟動。如果內(nèi)存限制異常高 (比方說超過節(jié)點的容量)，則可以繼續(xù)使用內(nèi)存，但最終當節(jié)點用完可用內(nèi)存時，調(diào)度器將開始驅(qū)逐 pod。
在非生產(chǎn)環(huán)境中，我們通過保持極低的資源請求和極高的資源限制來盡可能安全地分配資源。這種情況下的限制因素是內(nèi)存，也就是說，無論內(nèi)存請求有多低，內(nèi)存限制有多高，pod 驅(qū)逐都由調(diào)度在節(jié)點上的所有容器所使用的內(nèi)存總和所決定。
安全與治理
Kubernetes 旨在讓開發(fā)者使用云平臺，使他們更加獨立，并推動 DevOps 文化。向開發(fā)人員開放平臺、減少云工程團隊（或系統(tǒng)管理員）的干預(yù)以及使開發(fā)團隊獨立應(yīng)該是重要目標之一。
有時這種獨立性會帶來嚴重的風(fēng)險。例如，在 EKS 中使用 LoadBalancer 類型的 service 會在缺省情況下提供面向公共網(wǎng)絡(luò)的 ELB，而添加某個注釋將確保提供內(nèi)部 ELB。我們在剛開始在這個問題上犯了一些錯誤。
我們使用 Open Policy Agent 來降低各種安全風(fēng)險，以及與成本、安全和技術(shù)債務(wù)相關(guān)的風(fēng)險。
部署 Open Policy Agent 來構(gòu)建正確的控制器有助于自動化整個變更管理過程，并為我們的開發(fā)人員正確構(gòu)建安全的網(wǎng)絡(luò)。使用 Open Policy Agent，我們可以像前面提到的那樣設(shè)置限制——除非有正確的注釋，否則限制服務(wù)對象的創(chuàng)建，這樣開發(fā)人員就不會意外地創(chuàng)建公共的 ELB。
成本
我們在遷移后看到了巨大的成本效益。然而，并不是所有的好處都立竿見影。
注意：我們正在整合一個關(guān)于我們最近成本優(yōu)化計劃的更詳細的帖子，請關(guān)注我們的 Lambda。
更好的資源利用能力
這是最明顯的一個好處。我們今天的基礎(chǔ)設(shè)施所提供的計算、內(nèi)存和存儲比以前少得多。除了由于更好的容器或進程包裝而獲得更高的資源利用率之外，我們還能夠比以前更好地利用共享服務(wù)，如可觀察性（指標、日志）組件。
然而，在遷移過程中我們浪費了大量的資源。由于我們無法很快優(yōu)化我們的自我管理 Kubernetes 集群，我們遇到了大量的性能問題。我們?yōu)槲覀兊?pod 請求大量資源以作為緩沖，這更像是提供一種保證，以減少停機和由于缺乏計算或內(nèi)存資源所導(dǎo)致的性能問題。
由較高的資源緩沖而導(dǎo)致的高基礎(chǔ)設(shè)施成本是一個大問題。使用 Kubernetes 本應(yīng)讓我們獲得較高的資源利用率，但我們并沒有真的獲得這種好處。在遷移到 EKS 之后，它帶來的穩(wěn)定性幫助我們變得更加自信，這幫助我們采取必要的步驟來糾正資源請求，并大幅降低資源浪費。
Spot
在 Kubernetes 中使用 spot 實例要比在普通虛擬機中容易得多。使用虛擬機，您可以自己管理 spot 實例，這可能比較復(fù)雜，如需要確保應(yīng)用程序的正常運行時間或使用像 SpotInst 這樣的服務(wù)。這同樣適用于 Kubernetes，但是 Kubernetes 帶來的較高資源利用效率可以為您保留足夠的空間來做緩沖，這樣即使集群中的一些實例中斷，運行于其上的容器也可以快速地在其他地方重新調(diào)度。有幾個選項可以有效地管理 spot 中斷。
Spot 實例幫助我們節(jié)省了大量資金。今天，我們的整個預(yù)發(fā)布 Kubernetes 集群運行在 spot 實例上，99% 的生產(chǎn) Kubernetes 集群由保留實例、節(jié)約計劃和 spot 實例覆蓋。
對我們來說，優(yōu)化的下一步是如何在 spot 實例上運行整個生產(chǎn)集群。
ELB 整合
我們使用 Ingress 來整合我們的預(yù)發(fā)布環(huán)境中的 ELB，這大幅降低了 ELBs 的固定成本。為了避免這造成生產(chǎn)環(huán)境和部署環(huán)境代碼的差異，我們決定實現(xiàn)一個 controller，該 controller 將 LoadBalancer 類型服務(wù)更改為 NodePort 類型服務(wù)，同時在我們的預(yù)發(fā)布集群中創(chuàng)建一個 ingress 對象。
遷移到 Nginx ingress 對我們來說相對簡單，因為我們采用了控制器方法，所以不需要做太多更改。如果我們在生產(chǎn)環(huán)境中也使用 ingress，更改則會更少。在生產(chǎn)環(huán)境使用 ingress 不是一個簡單的改變。如要正確的為生產(chǎn)環(huán)境配置 ingress，就必須考慮周詳，還需要從安全性和 API 管理的角度來考慮。這是我們打算在不久的將來開展工作的一個領(lǐng)域。
增加跨 AZ 數(shù)據(jù)傳輸
雖然我們在基礎(chǔ)設(shè)施方面節(jié)省了大量開支，但在基礎(chǔ)設(shè)施的另一個領(lǐng)域，即跨 AZ 數(shù)據(jù)傳輸方面，我們的成本卻在增加。
Pod 可以被調(diào)度到任何節(jié)點上。即使您控制了 pod 在集群中的調(diào)度方式，也沒有簡單的方法來控制服務(wù)如何發(fā)現(xiàn)彼此（即一個服務(wù)的 pod 與同一 AZ 中的另一個服務(wù)的 pod 通信），以減少跨 AZ 的數(shù)據(jù)傳輸。
經(jīng)過大量的研究和與其他公司的同行的交談，我們了解到可以通過引入一個服務(wù)網(wǎng)格來控制從一個 pod 路由到目的地 pod 的流量來實現(xiàn)這一功能。操作服務(wù)網(wǎng)格很復(fù)雜，我們還沒有準備好為了節(jié)省跨 AZ 數(shù)據(jù)傳輸?shù)某杀径约撼袚@一復(fù)雜性。
CRDs、Operators 和 Controllers：簡化運維和更完整的體驗
每個組織都有自己的工作流程和運營挑戰(zhàn)，我們也不例外。
在對 Kubernetes 的兩年探索中，我們了解到 Kubernetes 很棒，但如果你使用它的 controllers、operators 和 CRDs 等功能來簡化日常操作，并為開發(fā)者提供更完整的體驗，那就更好了。
我們已經(jīng)開始開發(fā)一系列 controllers 和 CRDs。例如，LoadBalancer 類型 service 到 ingress 的轉(zhuǎn)換是一個 controller 操作。類似地，每當部署新服務(wù)時，我們使用 controller 在 DNS 中自動創(chuàng)建 CNAME 記錄。我們有另外的 5 個獨立用例，他們依賴我們的內(nèi)部 controller 來簡化日常操作和減少苦活累活。
我們還建立了一些 CRD。其中一種被廣泛用于在 Grafana 上生成監(jiān)視面板，它聲明式地指定監(jiān)視面板應(yīng)該由什么構(gòu)成。這使得開發(fā)人員可以在他們的應(yīng)用代碼庫旁配置他們的監(jiān)控面板，并使用相同的命令（kubectl apply -f .）部署一切內(nèi)容。
我們正在看到 controller 和 CRD 的大量好處。隨著我們與云計算供應(yīng)商 AWS 緊密合作以簡化集群基礎(chǔ)設(shè)施操作，我們將自己解放出來，更多地專注于構(gòu)建“Grofers Kubernetes 平臺”，該平臺被設(shè)計為盡力以最好的方式支持我們的開發(fā)團隊。
原文鏈接
https://lambda.grofers.com/learnings-from-two-years-of-kubernetes-in-production-b0ec21aa2814
