我們?yōu)槭裁床挥肒ubernetes？
當(dāng)今，Kubernetes 已經(jīng)成為容器編排領(lǐng)域的領(lǐng)導(dǎo)者。但是在 Coinbase 公司，卻沒有使用 Kubernetes。這是為什么？運(yùn)行 Kubernetes 會(huì)產(chǎn)生哪些問題？
本文要點(diǎn)：容器編排平臺(tái)是一項(xiàng)復(fù)雜而令人驚嘆的技術(shù)，它可以幫助一些企業(yè)和團(tuán)隊(duì)解決一系列的問題。然而，我們經(jīng)常忽略的是，容器技術(shù)還帶來了一系列的挑戰(zhàn)，企業(yè)只有克服這些挑戰(zhàn)才能避免失敗。
https://github.com/hjacobs/kubernetes-failure-stories
1. 歷史
在討論現(xiàn)狀之前，讓我們先了解下時(shí)至今日這項(xiàng)技術(shù)的發(fā)展歷程。
- 1980 年代：chroot
- 1990 年代：jail
- 2000 年代（早期)：jail > FreeBSD
- 2000 年代（中期）：cgroups
- 2000 年代（后期）：LXC（Linux 容器)
- 2010 年代（早期）：Docker
- 2010 年代（后期）：Kubernetes
如果想進(jìn)一步了解其歷史，請(qǐng)查閱 Enterprise Docker 第七章。
https://www.oreilly.com/library/view/enterprise-docker/9781491994986/
讓我們從 10 年前說起，那時(shí)還沒有現(xiàn)如今大家都知道的容器。那個(gè)時(shí)候，我們沒有 / 不使用 docker、rkt 或任何其他主流的容器封裝器 / 服務(wù)。為了將應(yīng)用程序從源代碼打包為生產(chǎn)部署，大多數(shù)大型公司都在構(gòu)建內(nèi)部系統(tǒng)。工程師在他們機(jī)器上運(yùn)行的東西通常不是在生產(chǎn)環(huán)境中運(yùn)行的東西，或者即使是在生產(chǎn)環(huán)境中運(yùn)行的東西，也通常是以一種深度定制化而且非常復(fù)雜的方式一次性構(gòu)建 / 打包的。
使用內(nèi)部系統(tǒng)打包和部署應(yīng)用程序需要一個(gè)大型運(yùn)營團(tuán)隊(duì)。通常，該團(tuán)隊(duì)隸屬于負(fù)責(zé)管理打包 / 構(gòu)建流程、部署和部署后工作的平臺(tái)或基礎(chǔ)設(shè)施組織。這些角色的職責(zé)通常以操作型工作為主，包括主機(jī)故障排除、診斷 OS 補(bǔ)丁 / 升級(jí)中的特定依賴問題等。部署后的工作包括容量規(guī)劃、訂購更多服務(wù)器、上架 / 安裝以及升級(jí)上面的軟件，幾乎不涉及自動(dòng)編排。
幸運(yùn)的話，有一些常規(guī)過程可以用來構(gòu)建一個(gè)“黃金鏡像”（想想 Hashicorp 的 Packer。這個(gè)鏡像有詳細(xì)的文檔，甚至可能被編碼，并由 Hudson（在 Jenkins 之前）這樣的持續(xù)集成系統(tǒng)運(yùn)行。這些鏡像可以手動(dòng)或借助某些配置管理工具自動(dòng)分發(fā)到你的系統(tǒng)中，然后以某種順序啟動(dòng)（比如用 Parallel SSH 或類似的方式）。
https://www.packer.io/
https://en.wikipedia.org/wiki/Hudson_(software)
在過去的十年里，一切都變了。我們不再使用龐大的單體應(yīng)用程序，而是將服務(wù)分解為許多離散的、低耦合的部件。我們從必須構(gòu)建 / 擁有自己的計(jì)算，轉(zhuǎn)為擁有托管服務(wù)或公有云服務(wù)，而這個(gè)過程只需點(diǎn)擊幾下鼠標(biāo)和一張信用卡。我們從垂直擴(kuò)展應(yīng)用程序，轉(zhuǎn)為重構(gòu)它們實(shí)現(xiàn)水平擴(kuò)展。所有這一切都是同時(shí)發(fā)生的，社會(huì)也發(fā)生了變化：每個(gè)人的口袋里都有手機(jī)，網(wǎng)絡(luò)速度在提高，全球范圍內(nèi)的網(wǎng)絡(luò)延時(shí)在下降，從預(yù)約遛狗者到商品化的視頻會(huì)議，一切都在網(wǎng)上進(jìn)行。
2009 年，AWS 提供的服務(wù)還相當(dāng)有限。AWS 的 EC2 服務(wù) 2008 年才完成 beta 測(cè)試并開始提供 SLA。相比之下，GCP 直到 2013 年才正式推出計(jì)算服務(wù)。
2. 為什么企業(yè)會(huì)選擇容器化他們的應(yīng)用程序？
企業(yè)選擇容器化他們的應(yīng)用程序，是為了以快速、安全、可靠的方式提高工程輸出 / 開發(fā)人員的生產(chǎn)力。容器化是不同于構(gòu)建鏡像的另一個(gè)選項(xiàng)，盡管有時(shí)可以將容器構(gòu)建到鏡像中，但這超出了本文的范圍參見這里。
https://thenewstack.io/bakery-foundation-container-images-microservices/
容器使工程師在本地開發(fā)、測(cè)試和運(yùn)行應(yīng)用程序的方式與在其他環(huán)境（過渡環(huán)境和生產(chǎn)環(huán)境）中運(yùn)行的方式相同或類似。容器允許描述依賴綁定關(guān)系，可以是顯式的，也可以是隱式的（操作系統(tǒng)總是包含服務(wù)所依賴的包 $foo）。容器允許更小的服務(wù)封裝和資源定義（使用 X CPU 和 Y GB 內(nèi)存）。容器讓你可以考慮水平伸縮應(yīng)用程序，而不是垂直伸縮應(yīng)用程序，從而實(shí)現(xiàn)更健壯的架構(gòu)。
其中一些觀點(diǎn)可能還需要進(jìn)一步地討論。為了推動(dòng)對(duì)話，這些觀點(diǎn)都有點(diǎn)過于大膽和發(fā)散，因?yàn)檫@并不是在討論容器化或服務(wù)化（service-ification）的利弊（例如，將單個(gè)應(yīng)用程序拆分為許多更小的獨(dú)立運(yùn)行的服務(wù)）。
3. 虛擬化呢？
虛擬化的概念是指能夠在一個(gè) OS 虛擬化系統(tǒng)] 上運(yùn)行多個(gè)容器。容器只能看到授權(quán)給它的設(shè)備 / 資源。在 AWS 這樣的托管計(jì)算平臺(tái)上，你實(shí)際上是運(yùn)行在一個(gè)管理程序之下，它管理運(yùn)行你的操作系統(tǒng)和容器的 VM。
簡圖
虛擬化使當(dāng)今的容器世界成為可能。如果沒有虛擬化能力，那么現(xiàn)在是不可能使硬件資源在容器中運(yùn)行多個(gè)應(yīng)用程序的。
4. 容器編排平臺(tái)（Mesos、Kubernetes、Docker Swarm）有什么問題需要解決？
容器編排平臺(tái)解決以下幾類問題：
- 托管 / 標(biāo)準(zhǔn)化部署工具（部署）；
- 根據(jù)一些定義好的啟發(fā)式規(guī)則擴(kuò)展應(yīng)用程序（橫向擴(kuò)展）；
- 當(dāng)出現(xiàn)故障時(shí)重新調(diào)度 / 移動(dòng)容器（自愈）。
有些平臺(tái)可能聲稱他們有其他特性，如存儲(chǔ)編排、秘密 / 配置管理和自動(dòng)裝箱。但實(shí)際上，如果要把它們應(yīng)用于大規(guī)模安裝，就需要大量的投資，要么是在分支 / 定制方面，要么是在集成與分離方面。
例如，大多數(shù)運(yùn)行大型容器編排平臺(tái)的人都無法使用其內(nèi)置的秘密或配置管理。這些原語通常不是為幾十個(gè)團(tuán)隊(duì)中的幾百名工程師設(shè)計(jì)或構(gòu)建的，而且通常不包括能夠讓他們穩(wěn)健地管理、擁有和操作應(yīng)用程序所需的控件。對(duì)于提供更強(qiáng)保證和控制（更不用說擴(kuò)展）的系統(tǒng)，人們通常會(huì)把秘密管理和配置管理分開。
類似地，對(duì)于服務(wù)發(fā)現(xiàn)和負(fù)載均衡，將其分離出來并運(yùn)行 Overlay 或抽象控制平面是很常見的。人們經(jīng)常會(huì)部署 Istio 為 Kubernetes 處理這個(gè)問題。管理和運(yùn)行 Istio 并不是一項(xiàng)簡單的任務(wù)，許多現(xiàn)代化集群宕機(jī)都是由對(duì)這個(gè)控制平面 / 服務(wù)網(wǎng)格的錯(cuò)誤配置以及對(duì)其細(xì)節(jié)缺乏理解造成的。
5. 我們用什么作為容器編排平臺(tái)？
我們的容器編排平臺(tái)是 Odin + AWS ASG（自動(dòng)伸縮組）。當(dāng)你在 Codeflow（我們用于部署的內(nèi)部 UI）上點(diǎn)擊 Deploy 時(shí)，Odin 將通過 Codeflow 的 API 調(diào)用被激活。Odin 啟動(dòng)一個(gè) Step Function 并開始部署應(yīng)用程序。AWS 上會(huì)新啟動(dòng)一個(gè) VM 并將其加載到新的 ASG 中，軟件都是從各種內(nèi)部位置獲取的，負(fù)載均衡器開始對(duì)這些新實(shí)例進(jìn)行健康檢查，最終，流量以藍(lán) / 綠方式切換到負(fù)載均衡器后面新 ASG 中的新主機(jī)上。
https://github.com/coinbase/odin
https://blog.coinbase.com/scaling-developer-productivity-d23ce491f869
我們的容器編排平臺(tái)非常簡單。我們啟用了與 Kubernetes 相同的關(guān)鍵特性：Codeflow 中有一個(gè) Deploy + Rollback 按鈕，基于一些定義好的啟發(fā)式規(guī)則（我們支持自定義 AWS 指標(biāo)或標(biāo)準(zhǔn) CPU 指標(biāo)）進(jìn)行伸縮，并能在 ASG 中的 VM 宕掉或變得不健康時(shí)重新調(diào)度 / 移動(dòng)容器。
為了處理秘密和配置管理，我們構(gòu)建了一個(gè)動(dòng)態(tài)配置服務(wù)，它為所有內(nèi)部客戶提供庫，第 95 百分位延遲為 6ms。它后臺(tái)基于 DynamoDB，每分鐘可以為成百上千個(gè)同步和異步方法請(qǐng)求提供服務(wù)。
為了處理服務(wù)發(fā)現(xiàn)和負(fù)載平衡，我們使用了 Route53（DNS）、ALB（應(yīng)用程序負(fù)載均衡器）和 gRPC 客戶端負(fù)載均衡（可以是原生的，也可以通過 Envoy）。我們預(yù)計(jì)今年晚些時(shí)候還會(huì)開展進(jìn)一步的工作。
6. 我們?yōu)槭裁床皇褂?Kubernetes？
運(yùn)行 Kubernetes 不能解決任何客戶（工程）問題。相反，運(yùn)行 Kubernetes 實(shí)際上會(huì)產(chǎn)生一系列新的問題。
我們就需要組建一支全職的計(jì)算團(tuán)隊(duì)。盡管隨著發(fā)展，我們可能會(huì)這樣做，但運(yùn)行 Kubernetes 的話，我們立即就需要這樣做，這樣才能集中精力構(gòu)建數(shù)十個(gè)集群（可能每個(gè)團(tuán)隊(duì) / 組織都是分開的），開始研究 / 構(gòu)建封裝 / 膠水工具，開始構(gòu)建抽象控制平面 / 服務(wù)網(wǎng)格，等等。
保護(hù) Kubernetes 安全不是一項(xiàng)輕松簡單或易于理解的操作。為了使我們能夠擁有 / 運(yùn)營 Kubernetes，我們整個(gè)平臺(tái)中使用的工具和控件（Odin、ASG、Step Deployer——以及它們依賴的東西）都要有。構(gòu)建相同的原語，提供與目前相同的安全級(jí)別，對(duì)于（未來的）計(jì)算團(tuán)隊(duì)和我們的安全團(tuán)隊(duì)來說都是一項(xiàng)非常大的投資。
托管的 Kubernetes（AWS 的 EKS、谷歌的 GKE）還處于起步階段，擁有 / 運(yùn)營 Kubernetes 的大多數(shù)挑戰(zhàn)都尚未解決（如果有什么問題的話，就更困難了）。在 AWS，為了運(yùn)行 EKS，他們正在擴(kuò)充支持 / 運(yùn)營團(tuán)隊(duì)，而在谷歌，GKE 中斷數(shù)小時(shí)的情況并不少見（參見這里。你只是把一些運(yùn)營問題和挑戰(zhàn)轉(zhuǎn)移給了另一個(gè)運(yùn)營團(tuán)隊(duì)（而可見性大幅降低了）。
集群升級(jí)和管理要比我們現(xiàn)在所做的操作多很多。合理運(yùn)行 Kubernetes 的唯一方法是讓團(tuán)隊(duì) / 組織擁有自己的集群（類似于讓他們有自己的 AWS 帳戶或 GCP 項(xiàng)目）。即使有了 Istio 和相關(guān)工具，升級(jí)集群和修補(bǔ)漏洞也不是一件容易的事。通常，你必須構(gòu)建 / 運(yùn)行一個(gè)輔助集群，將所有的應(yīng)用程序故障轉(zhuǎn)移，然后在升級(jí)后進(jìn)行故障恢復(fù)。目前，這個(gè)原語還沒有構(gòu)建到任何抽象中。雖然托管集群（GKE）中可能提供了，但它并不總是像你預(yù)期的那樣工作，并且啟動(dòng)后回滾通常也沒有得到很好的處理。
如今，我們沒有這個(gè)負(fù)擔(dān)。我們運(yùn)行在一個(gè)堅(jiān)固的操作系統(tǒng)上，幾乎沒什么依賴。我們的 AMI 上線是從開發(fā)開始，然后經(jīng)過數(shù)周的測(cè)試再繼續(xù)。如果需要回滾，只需要簡單地更改一行代碼就可以實(shí)現(xiàn)。平均而言，我們每個(gè)月花在與這個(gè)領(lǐng)域密切相關(guān)的任何事情上的時(shí)間都不到 5 小時(shí)。
7. Kubernetes 安全保護(hù)
讓我們看一下，在一個(gè)保存了超過 80 億美元加密資產(chǎn)的企業(yè)中，運(yùn)行 Kubernetes 并保證其安全的復(fù)雜性。
https://blog.coinbase.com/our-focus-on-the-institutional-space-5c8e87332268
組件
保證 Kubernetes 集群安全的基礎(chǔ)知識(shí)眾所周知，但是如果需要對(duì)其中的每一項(xiàng)都做深入的研究，復(fù)雜性就來了。保護(hù)所有系統(tǒng)組件（etcd、kubelet）、API 服務(wù)器和任何抽象 /Overlay（Istio）的安全，就有許多東西需要理解、測(cè)試和保護(hù)。考慮到攻擊面增加，必須要深入研究命名空間、seccomp、SELinux、cgroups 等。Kubernetes 非常大，它有自己的 CIS 基準(zhǔn)測(cè)試和 InSpec 套件（謝天謝地）。
https://www.cisecurity.org/benchmark/kubernetes/
https://github.com/dev-sec/cis-kubernetes-benchmark
漏洞
下面是一個(gè)簡短的列表，可以作為漏洞研究的起點(diǎn)：
CVE-2019–5736（8.6 高）：使攻擊者可以改寫主機(jī)的二進(jìn)制文件 runc（從而獲得主機(jī) root 訪問權(quán)限）。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736
CVE-2019–11246（6.5 中）：如果容器中的二進(jìn)制文件 tar 存在惡意代碼，它就可以運(yùn)行任何代碼并輸出意料之外的不良后果。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11246
CVE-2019–11253（7.5 高） ：使授權(quán)用戶可以發(fā)送惡意 YAML 或 JSON 載荷，導(dǎo)致 API 服務(wù)器占用過多的 CPU 或內(nèi)存，可能會(huì)導(dǎo)致崩潰或服務(wù)不可用。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11253
概述
Kubernetes 是一個(gè)功能強(qiáng)大的 PaaS 工具包，具有許多安全相關(guān)的選項(xiàng)，可以支持各種部署場(chǎng)景。當(dāng)它成為大家普遍認(rèn)可的 PaaS 選項(xiàng)時(shí)，從安全的角度來看，這是非常有價(jià)值的，因?yàn)檫@些安全選項(xiàng)中的大多數(shù)都可以抽象出來，并且必須配備輔助系統(tǒng)以支持其使用。
從根本上說，Kubernetes 是為工作負(fù)載編排而設(shè)計(jì)的——信任并不是 Kubernetes 中封裝或部件產(chǎn)生的原因；多租戶的目的是為了打包，而不是為了支持拓展權(quán)限邊界。它提供了幾個(gè)層，你可以選擇在其中為不同的可執(zhí)行性設(shè)置適當(dāng)?shù)倪吔?。其中一些邊界是?nèi)置的，而其他邊界只是用于集成其他工具來輔助管理的集成點(diǎn)。下面是用于隔離工作負(fù)載的一些原語，有的 Kube 提供了，有的沒有提供。
控制平面（AWS 賬號(hào) / GCP 項(xiàng)目）
Kubernetes 集群的操作是在提供給它們的服務(wù)和網(wǎng)絡(luò)中進(jìn)行的，自然地，就會(huì)與 AWS/GCP 控制平面進(jìn)行一些交互，比如配置 Ingress 負(fù)載均衡器、訪問存儲(chǔ)在 KMS 中的秘密等。隨著時(shí)間的推移，團(tuán)隊(duì)會(huì)發(fā)展壯大，擁有獨(dú)立的帳戶、項(xiàng)目并進(jìn)一步的隔離。一個(gè)單獨(dú)的 AWS 帳戶或 GCP 項(xiàng)目是實(shí)現(xiàn)完全 IAM 分割（segmentation）的主要原語。
另一方面，Kubernetes 集群需要在一個(gè) AWS 帳戶內(nèi)操作（即使與其他地方的集群聯(lián)合）。這限制了分割選項(xiàng)和靈活性。我們可以為每個(gè)團(tuán)隊(duì)或服務(wù)提供一個(gè)集群，但我們就無法利用 Kubernetes 的許多好處了，并且會(huì)帶來新的管理問題，比如對(duì)所有這些集群進(jìn)行元編排。
集群 & 節(jié)點(diǎn) &Pod& 容器
集群
集群主（API）服務(wù)器是一個(gè)次控制平面（AWS 控制平面之外），我們也需要做好安全防護(hù)。服務(wù)帳戶和訪問范圍（容器可以假定要訪問集群內(nèi)外的資源）與 AWS 的 IAM 一樣復(fù)雜，并且需要嚴(yán)格地相互映射，以便中時(shí)斷不會(huì)影響 AWS 控制平面。
節(jié)點(diǎn)
底層節(jié)點(diǎn)的操作系統(tǒng)必須像我們現(xiàn)在所做的那樣進(jìn)行維護(hù)。事實(shí)上，我們的操作系統(tǒng)與谷歌用于 GKE 的基本操作系統(tǒng)非常相似。雖然將我們的操作系統(tǒng)轉(zhuǎn)到 Kubernetes 不必做任何修改，但我們也不會(huì)得到任何東西。
Pod
在集群中創(chuàng)建 Pod，以及定義它們創(chuàng)建時(shí)必須滿足哪些標(biāo)準(zhǔn)的規(guī)則，都是通過 PodSecurityPolicy 完成的，它的運(yùn)作方式類似于 Salus 和我們現(xiàn)在使用的一致性管理工具。要實(shí)現(xiàn)干凈利落的集成，我們將需要做大量的集成工作，并投資于附加的開源依賴項(xiàng)。
https://github.com/coinbase/salus
Pod 通過網(wǎng)絡(luò)策略相互隔離，就像我們現(xiàn)在使用安全組和 / 或內(nèi)部服務(wù)框架所做的那樣。但在 Kubernetes 領(lǐng)域，Pod 相互通信所需的標(biāo)識(shí)、身份驗(yàn)證和授權(quán)涉及大量的支持技術(shù)，如用于節(jié)點(diǎn)級(jí)以下標(biāo)識(shí)格式和認(rèn)證的 SPIFFE&SPIRE，用于授權(quán)控制的 Envoy，Istio authN 和 Z 編排，OPA 授權(quán)策略。對(duì)于其中的每一項(xiàng)技術(shù)，要將其標(biāo)準(zhǔn)化并應(yīng)用到生產(chǎn)中都需要付出很大的努力。
容器
容器不是安全邊界，而是資源邊界。為了定義容器的安全邊界，需要深入研究自定義內(nèi)核命名空間、系統(tǒng)調(diào)用過濾、強(qiáng)制訪問控制框架和 / 或?yàn)槿萜髟O(shè)計(jì)的基于 VM 的隔離技術(shù)，如 gVisor。
https://github.com/google/gvisor
目前，我們?cè)谶@個(gè)領(lǐng)域的投入還不太多，因?yàn)槲覀冞€沒有采用多租戶的方式。如果我們轉(zhuǎn)向多租戶模型，我們將不得不立即進(jìn)行大量的投資，通過主機(jī) /VM 隔離技術(shù)保證類似分類的 Pod/ 容器在相同的節(jié)點(diǎn)上運(yùn)行，不會(huì)相互干擾。
8. 我們何時(shí)會(huì)運(yùn)行 Kubernetes？它在我們未來計(jì)劃中嗎？
當(dāng)更高級(jí)的容器編配平臺(tái)有重要的用例時(shí)，我們可能會(huì)首先查看問題聲明。如果該平臺(tái)很容易添加到我們現(xiàn)有的平臺(tái)上：我們可能會(huì)首先訪問它，然后從那里開始探索 / 了解。如果我們認(rèn)為擴(kuò)展 / 添加到我們的平臺(tái)上不合理，那么我們將訪問所有可能的選項(xiàng)——而不僅僅是 Kubernetes。更可能的情況是，我們會(huì)先了解 AWS 的托管服務(wù)，如 Fargate 和 ECS，然后再了解 Kubernetes。
如果提供 Kubernetes（或任何其他容器編配平臺(tái)）我們的工程師可以從中獲得顯著的收益時(shí)，我們才會(huì)研究提供它們?，F(xiàn)在，提供 Kubernetes 并沒有什么明顯的好處。如果 Kubernetes 提供了許多我們現(xiàn)在沒有的新特性，償清了技術(shù)債務(wù)，或者我們的客戶需要它們可以提供的新功能，而我們?cè)诳深A(yù)見的將來都無法提供，這種情況就可能會(huì)改變。如果妨礙其進(jìn)入我們當(dāng)前平臺(tái)的因素發(fā)生了顯著的變化，并且它有了明顯的獨(dú)特之處，那么我們也會(huì)研究提供一個(gè)不同的平臺(tái)。
如果 / 當(dāng)我們現(xiàn)有的平臺(tái)達(dá)到了極限，由于缺少客戶需要的特性而負(fù)擔(dān)太重或者可以預(yù)見將會(huì)負(fù)擔(dān)太重，而擴(kuò)展我們平臺(tái)的工作又過于繁重，或者中斷太多違反我們的 SLA，那么我們可能會(huì)重新審視不同的容器編排平臺(tái)。
如果 / 當(dāng)我們失去了主要上游依賴方（如 AWS 或 ASG）的支持，我們也會(huì)考慮其他選項(xiàng)。
這是我們可能會(huì)選擇研究另一個(gè)容器編排平臺(tái)的幾個(gè)理由。目前，我們還沒有構(gòu)建、擁有、運(yùn)營 Kubernetes 的計(jì)劃。
Kubernetes 不是解決了像再平衡 / 自愈、自動(dòng)擴(kuò)展和服務(wù)發(fā)現(xiàn)等多方面的問題嗎？我們現(xiàn)在是如何解決這些問題的？
在規(guī)模較小時(shí)，Kubernetes 解決了這些問題中的大部分，而且也不是很麻煩。在規(guī)模較大時(shí)，就需要更多的思考和膠水代碼，并在幾乎所有的東西上增加封裝器 / 安全保護(hù)，以使其能夠安全可靠地工作。通常，如前所述，人們傾向于添加 Istio 這樣的服務(wù)網(wǎng)格來支持更高級(jí)的特性 / 需求。
目前，我們是這樣解決的：
- 借助 Odin 和 ASG 實(shí)現(xiàn)再平衡 / 自愈；
- 借助 DNS 和 Envoy 實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)。
Kubernetes 有存儲(chǔ)編排，我們目前還沒有，我們應(yīng)該有嗎？
現(xiàn)在，Coinbase 有兩個(gè)主要的有狀態(tài)應(yīng)用程序——區(qū)塊鏈節(jié)點(diǎn)和交易引擎，它們可能是存儲(chǔ)編排等特性的潛在用例。對(duì)于前者（區(qū)塊鏈節(jié)點(diǎn)），存儲(chǔ)的使用定制化程度很高，我們構(gòu)建了一個(gè)自定義的部署器，為它們提供所需的特性。對(duì)于后者（交易引擎），我們依賴可靠性（SRE）團(tuán)隊(duì)為他們的一些特定挑戰(zhàn)提供支持。
雖然 Kubernetes 內(nèi)置的存儲(chǔ)編排對(duì)于區(qū)塊鏈節(jié)點(diǎn)和交易引擎來說都是一個(gè)很好的起點(diǎn)，但是我們?cè)诘讓蛹夹g(shù)中遇到的很多問題仍然存在。
9. 如果 Kubernetes 不是容器編排平臺(tái)的未來，那么什么才是？
對(duì)于部分應(yīng)用程序，我們將探索并遷移到更高級(jí)的抽象服務(wù)。我們將探討把 Fargate 和 ECS 作為這方面的候選者。目前的首要原因是利用率和成本的增加——這兩者都不是很以客戶為中心。我們可以選擇再等等，到我們有更多以客戶為中心的理由時(shí)才實(shí)施。
以客戶為中心的潛在問題可能是部署時(shí)間、部署模式（除了金絲雀之外）、比目前更復(fù)雜的服務(wù)網(wǎng)格需求，或者在現(xiàn)有的工具中構(gòu)建不可能 / 不合理但可以添加到 Fargate 或 ECS 的特定改進(jìn) / 特性。這些是一些潛在的以客戶為中心的問題，這些問題可能會(huì)有，但目前還不知道或沒有發(fā)現(xiàn)。
在理想情況下，向另一種底層容器技術(shù)的轉(zhuǎn)移是不可見的，因?yàn)榕c它們交互的工具不會(huì)從根本上改變。遷移到不同的平臺(tái)可能會(huì)揭示出關(guān)于現(xiàn)有系統(tǒng)隱藏的或未知的期望。如何在過渡環(huán)境和生產(chǎn)環(huán)境部署和調(diào)試服務(wù)仍然是抽象的，但是可能提供了一些現(xiàn)在沒有的特性。
10. 我 / 我們討厭 Kubernetes 嗎？它是一個(gè)失敗的容器平臺(tái)嗎？
不。盡管存在挑戰(zhàn)，但它是一個(gè)了不起的工具。Kubernetes 已經(jīng)將我們的行業(yè)推向了一個(gè)越來越積極的方向。隨著 Kubernetes 進(jìn)入 v1 版本，Knative、Fargate 和 Cloud Run 的開發(fā)正在不斷提高抽象級(jí)別，并解決管理 Kubernetes 的潛在挑戰(zhàn)。未來是光明的。隨著這些潛在的挑戰(zhàn)得到解決，許多現(xiàn)存的問題未來可能會(huì)得到緩解。
