K8s/Kubernetes：AWS 與 GCP 與 Azure
已發表: 2022-03-11Kubernetes（通常風格化為“K8s”）在多年前贏得了容器編排工具的戰鬥。 儘管如此，今天仍然有很多方法可以實現 Kubernetes 並使其與各種基礎設施和許多工具一起工作——其中一些工具比其他工具維護得更好。 不過，這方面最有趣的發展可能是頂級雲提供商已決定發布他們自己的託管 Kubernetes 版本：
- Microsoft Azure 提供 Azure Kubernetes 服務 (AKS)
- AWS 提供 Amazon Elastic Kubernetes Service (EKS)
- Google Cloud 提供 Google Kubernetes Engine (GKE)
從 DevOps 的角度來看，這些平台提供了什麼？ 他們是否兌現了他們的承諾？ 他們的創建時間和其他基準比較如何？ 他們與各自平台的集成情況如何，尤其是他們的 CLI 工具？ 維護和與他們合作是什麼感覺？ 下面，我們將深入探討這些問題以及更多內容。
注意：對於希望在繼續閱讀之前解釋 Kubernetes 集群概念的讀者，Dmitriy Kononov 提供了出色的介紹。
AKS 與 EKS 與 GKE：廣告功能
我們決定將每個託管 Kubernetes 版本可用的不同功能分組到孤島中：
- 全球概覽
- 聯網
- 可擴展性和性能
- 安全和監控
- 生態系統
- 價錢
注意：隨著雲提供商定期更新其產品，這些詳細信息可能會隨著時間而改變。
全球概覽
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 發布年份 | 2017 | 2018 | 2014 |
| 最新版本 | 1.15.11（默認）- 1.18.2（預覽版） | 1.16.8（默認） | 1.14.10（默認）- 1.16.9 |
| 特定組件 | oms 代理，隧道前沿 | aws-節點 | fluentd, fluentd-gcp-scaler, 事件導出器, l7-default-backend |
| Kubernetes 控制平面升級 | 手動的 | 手動的 | 自動（默認）或手動 |
| 工人升級 | 手動的 | 是（使用託管節點組很容易） | 是：自動和手動，可以微調 |
| 服務水平協議 | 99.95% 有可用區，99.9% 沒有 | EKS（主節點）為 99.9%，EC2（節點）為 99.99% | 99.95% 區域內，99.5% 區域內 |
| 原生 Knative 支持 | 不 | 不 | 否（但原生 Istio 安裝） |
| Kubernetes 控制平面價格 | 自由 | 0.10 美元/小時 | 0.10 美元/小時 |
Kubernetes 本身就是 Google 的項目，因此他們在 2014 年率先提出託管版本是有道理的。
在這裡比較的三者中，Azure 緊隨其後的是 AKS，並且已經有一段時間需要改進：如果您還記得幾年前用於在 Azure 上配置 Kubernetes 的 acs-engine，您會欣賞微軟在替換它方面所做的努力， aks引擎。
AWS 是最後一個推出自己的版本 EKS 的公司，因此它有時會在功能方面顯得落後，但他們正在迎頭趕上。
當然，在定價方面，事情總是在變化，谷歌決定以 0.10 美元/小時的價格加入 AWS，自 2020 年 6 月起生效。Azure 是這裡的局外人，免費提供 AKS 服務，但目前尚不清楚如何可能會持續很長時間。
另一個主要區別在於集群的升級功能。 最自動化的升級在 GKE 中，默認情況下它們是打開的。 但是，AKS 與 EKS 在這裡彼此相似，因為兩者都需要手動請求才能升級主節點或工作節點。
聯網
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 網絡策略 | 是：Azure 網絡策略或 Calico | 需要安裝印花布 | 是：通過 Calico 原生 |
| 負載均衡 | 基本或標準 SKU 負載均衡器 | 經典和網絡負載均衡器 | 容器原生負載均衡器 |
| 服務網格 | 沒有開箱即用 | AWS App Mesh（基於 Envoy） | Istio（開箱即用，但測試版） |
| DNS 支持 | CoreDNS 自定義 | VPC 內的 CoreDNS + Route53 | CoreDNS + 谷歌云 DNS |
在網絡方面，這三個雲提供商彼此非常接近。 例如，它們都允許客戶使用 Calico 實施網絡策略。 關於負載均衡，它們都實現了與自己的負載均衡器資源的集成，並讓工程師可以選擇使用什麼。
這裡發現的主要區別是基於服務網格的附加值。 AKS 不支持任何開箱即用的服務網格（儘管工程師可以手動安裝 Istio）。 AWS 開發了自己的服務網格，稱為 App Mesh。 最後，谷歌發布了自己與 Istio 的集成（儘管仍處於測試階段），客戶可以在創建集群時直接添加。
最佳選擇：GKE
可擴展性和性能
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 裸機節點 | 不 | 是的 | 不 |
| 每個集群的最大節點數 | 1,000 | 1,000 | 5,000 |
| 高可用性集群 | 不 | 是的控制計劃，跨 AZ 的工作人員手動 | 是，通過區域集群，複製主節點和工作節點 |
| 自動縮放 | 是，通過集群自動擴縮器 | 是，通過集群自動擴縮器 | 是，通過集群自動擴縮器 |
| 垂直 Pod 自動縮放器 | 不 | 是的 | 是的 |
| 節點池 | 是的 | 是的 | 是的 |
| GPU 節點 | 是的 | 是的 | 是的 |
| 本地 | 通過 Azure ARC（測試版）提供 | 不 | 通過 Anthos GKE 進行 GKE On-Prem |
在 GKE 與 AKS 與 EKS 的性能和可擴展性方面，GKE 似乎領先。 事實上，它支持最大數量的節點 (5,000)，並提供有關如何正確擴展集群的大量文檔。 高可用性的所有功能都可用並且易於微調。 更重要的是，GKE 最近發布了 Anthos，這是一個圍繞 GKE 及其功能創建生態系統的項目； 借助 Anthos，您可以在本地部署 GKE。
不過，AWS 確實有一個關鍵優勢：它是唯一允許裸機節點運行 Kubernetes 集群的優勢。
截至 2020 年 6 月，AKS 缺乏主服務器的高可用性，這是需要考慮的一個重要方面。 但是，與往常一樣，這種情況很快就會改變。
最佳選擇：GKE
安全和監控
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 應用機密加密 | 不 | 是的，可以通過 AWS KMS | 是的，可以通過 Cloud KMS |
| 遵守 | HIPAA、SOC、ISO、PCI DSS | HIPAA、SOC、ISO、PCI DSS | HIPAA、SOC、ISO、PCI DSS |
| RBAC | 是的 | 是的，並且與 IAM 緊密集成 | 是的 |
| 監控 | Azure Monitor 容器運行狀況功能 | 連接到 Cloudwatch 的 Kubernetes 控制平面監控，節點的 Container Insights Metrics | Kubernetes Engine 監控和與 Prometheus 的集成 |
在合規性方面，所有三個雲提供商都是等效的。 但是，在安全性方面，EKS 和 GKE 通過其嵌入式密鑰管理服務提供了另一層安全性。
在監控方面，Azure 和 Google Cloud 圍繞 Kubernetes 提供了自己的監控生態系統。 值得注意的是，來自 Google 的那個最近更新為使用專為 Kubernetes 設計的 Kubernetes Engine Monitoring。
Azure 提供了自己的容器監控系統，該系統最初是為基本的非 Kubernetes 容器生態系統而設計的。 截至 2020 年 6 月，他們以預覽模式添加了對某些 Kubernetes 特定指標和資源（集群運行狀況、部署）的監控。
AWS 直接在 Cloudwatch 中為控制平面提供輕量級監控。 要監控工作人員，您可以使用通過可以安裝在集群中的特定 CloudWatch 代理提供的 Kubernetes Container Insights Metrics。
最佳選擇：GKE
生態系統
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 市場 | Azure 市場（但沒有明確的 AKS 集成） | AWS Marketplace（250 多個應用程序） | 谷歌市場（90 多個應用程序） |
| 基礎架構即代碼 (IaC) 支持 | 地形模塊 Ansible 模塊 | 地形模塊 Ansible 模塊 | 地形模塊 Ansible 模塊 |
| 文檔 | 弱但完整而強大的社區（2,000 多個 Stack Overflow 帖子） | 不是很徹底但很強大的社區（1,500+ Stack Overflow 帖子） | 廣泛的官方文檔和非常強大的社區（4,000+ Stack Overflow 帖子） |
| CLI 支持 | 完全的 | 完整，加上特殊的單獨工具eksctl （如下所述） | 完全的 |
在生態系統方面，這三個提供商具有不同的優勢和資產。 AKS 現在圍繞其平台擁有非常完整的文檔，並且在 Stack Overflow 上的帖子方面排名第二。 EKS 在 Stack Overflow 上的帖子數量最少，但受益於 AWS Marketplace 的優勢。 GKE 作為最古老的平台，在 Stack Overflow 上擁有最多的帖子，在其市場上擁有相當數量的應用程序，但也擁有最全面的文檔。
最佳選擇：GKE 和 EKS
價錢
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 免費使用上限 | 價值 170 美元 | 不符合免費套餐的條件 | 價值 300 美元 |
| Kubernetes 控制平面成本 | 自由 | 0.10 美元/小時 | 0.10 美元/小時（2020 年 6 月） |
| 降價（Spot 實例/搶占式節點） | 是的 | 是的 | 是的 |
| 一個月的示例價格 | 342 美元 3 個 D2 節點 | 300 美元 3 個 t3.large 節點 | 190 美元 3 個 n1-standard-2 節點 |
就整體價格而言，即使 GKE 為任何集群實施 0.10 美元/小時的價格點，它仍然是迄今為止最便宜的雲。 這要歸功於谷歌特有的東西——持續使用折扣，只要按需資源的每月使用量達到某個最低限度，就會應用這些折扣。
需要注意的是，示例價格行沒有考慮到雲提供商可以收取的 Kubernetes 集群的流量。
AWS 不允許使用他們的免費套餐來測試 EKS 集群的原因是 EKS 需要比 tX.micro 層更大的機器，而且 EKS 每小時定價不在免費套餐中。
儘管如此，使用每個雲提供商的現貨/可搶占節點以適當的負載測試這些託管 Kubernetes 選項中的任何一個仍然是經濟的——這種策略很容易在最終價格上節省 80% 到 90%。 （當然，不建議在此類機器上運行有狀態的生產負載！）
廣告功能和 Google 的優勢
在線查看不同的廣告功能時，託管 Kubernetes 版本上市的時間與功能數量之間似乎存在相關性。 如前所述，谷歌一直是 Kubernetes 項目的發起者，這似乎是一個不可否認的優勢，從而與自己的雲平台更好、更強地集成。
但是AKS和EKS隨著它們的成熟也不容小覷； 兩者都可以利用其獨特的功能。 例如，AWS 是唯一擁有裸機節點集成的公司，並且在其市場上擁有最多的應用程序。
既然每個 Kubernetes 產品的廣告功能已經很清楚了，讓我們通過一些動手測試來進行更深入的研究。
Kubernetes：AWS 與 GCP 與 Azure 的實踐
廣告是一回事，但在服務生產負載方面，不同平台如何比較？ 作為一名云工程師，我知道在執行基礎設施即代碼時需要多長時間來生成和關閉集群的重要性。 但我也想探索每個 CLI 的可能性，並評論每個雲提供商如何輕鬆（或不）生成集群。
集群創建用戶體驗
AKS
在 AKS 上，生成集群類似於在 AWS 中創建實例。 只需找到 AKS 菜單並瀏覽一系列不同的菜單。 一旦驗證了配置，就可以創建集群，這個過程分為兩步。 這非常簡單，工程師可以使用默認設置輕鬆快速地啟動集群。
EKS
在 EKS 與 AKS 上，集群創建肯定更複雜。 首先，默認情況下，AWS 需要先訪問 IAM，以便為 Kubernetes 控制平面創建一個新角色並將工程師分配給它。 還需要注意的是，這個集群創建不包括節點的創建，所以當我平均測量 11 分鐘時，這只是用於創建主節點。 節點組創建是管理員的另一個步驟，再次需要一個具有三個必要策略的工作人員角色，這些策略要通過 IAM 控制面板製定。
GKE
對我來說，手動創建集群的體驗在 GKE 上是最愉快的。 在 Google Cloud Console 中找到 Kubernetes Engine 後，點擊創建集群。 不同類別的設置出現在左側的菜單中。 Google 將使用易於修改的默認節點池預先填充新集群。 最後但同樣重要的是，GKE 具有最快的集群生成時間，這將我們帶到了下一張表。
是時候產生一個集群了
| 服務方面 | AKS | EKS | GKE |
|---|---|---|---|
| 尺寸 | 3 個節點 (Ds2-v2)，每個節點有 2 個 vCPU，7 GB RAM | 3 個節點 t3.large | 3 個節點 n1-standard-2 |
| 時間 (m:ss) | 完整集群的平均 5:45 | 主節點 11:06 加上節點組 2:40（全集群總共 13:46） | 完整集群的平均 2:42 |
我在同一地區（AKS 的法蘭克福和西歐）進行了這些測試，以消除這種差異對產卵時間的可能影響。 我還嘗試為集群的節點選擇相同大小：三個節點，每個節點有兩個 vCPU 和七或八 GB 內存，這是在 Kubernetes 上運行小負載並開始試驗的標準大小。 我創建了每個集群三次以計算平均值。
在這些測試中，GKE 始終保持領先，生成時間始終低於三分鐘。
Kubernetes：AWS 與 GCP 與 Azure CLI 概述
並非所有 CLI 都是一樣的，但在這種情況下，所有三個 CLI 實際上都是更大 CLI 的模塊。 使用每個雲提供商的 CLI 工具鏈啟動和運行是什麼感覺？
AKS CLI（通過az ）
安裝az tooling 和 AKS 模塊（通過az aks install-cli ）後，工程師需要授權 CLI 與項目的 Azure 帳戶進行通信。 這是通過簡單的az aks get-credentials --resource-group myResourceGroup --name myAKSCluster獲取憑據以更新本地 kubeconfig 文件的問題。
同樣，要創建集群： az aks create --resource-group myResourceGroup --name myAKSCluster
EKS CLI（通過aws或eksctl ）
在 AWS 上，我們找到了一種不同的方法——有兩種不同的官方 CLI 工具來管理 EKS 集群。 與往常一樣， aws可以連接到 AWS 資源，尤其是集群。 可以通過以下方式將憑證獲取到本地 kubeconfig： aws eks update-kubeconfig --name cluster-test 。
但是，工程師也可以使用由 Weaveworks 開發並用 Go 編寫的eksctl來輕鬆創建和管理 EKS 集群。 EKS 為雲工程師提供的一個主要好處是，他們可以將其與 YAML 配置文件結合以創建基礎架構即代碼 (IaC)，因為它與 CloudFormation 一起使用。 在將 EKS 集群集成到 AWS 上的大型基礎設施中時，這絕對是一項需要考慮的資產。
通過eksctl創建集群就像eksctl create cluster一樣簡單，不需要其他參數。
GKE CLI（通過gcloud ）
對於 GKE，步驟非常相似：安裝gcloud ，然後通過gcloud init進行身份驗證。 來自那裡的可能性：工程師可以創建、刪除、描述、獲取憑據、調整大小、更新或升級集群，或列出集群。
使用gcloud創建集群的語法很簡單： gcloud container clusters create myGCloudCluster --num-nodes=1
AKS 與 EKS 與 GKE：試駕結果
在實踐中，我們可以看到 GKE 無疑是啟動基本集群的最快方式，無論是在控制台簡單性還是集群生成時間方面。 UX 方面，集群旁邊有連接按鈕，這也使得連接到集群最直接。
在 CLI 工具方面，三個雲提供商實現了類似的功能； 但是，我們可以強調 Weaveworks 為 EKS 提供的額外工具。 eksctl是您在現有 AWS 基礎設施之上實施基礎設施即代碼並將其他服務與 EKS 相結合的完美工具。
託管 Kubernetes 產品向前發展：AWS 與 GCP 與 Azure
對於那些剛開始接觸 Kubernetes 的人來說，我的首選實現是 GKE，因為它是最直接的。 它易於設置，具有簡單快速的生成 UX，並且很好地集成到了 Google Cloud Platform 生態系統中。
儘管 AWS 是最後一個加入競爭的，但它具有一些不可否認的優勢，例如裸機節點以及它與擁有最大份額的提供商集成的簡單事實。
最後，AKS 自創建以來取得了長足的進步。 工具和功能的平等可能不會花很長時間，同時在過程中留有創新空間。 與任何託管 Kubernetes 產品一樣，對於那些已經在父平台上的產品，集成將是一個賣點。
一旦一個團隊選擇了 Kubernetes 雲提供商，看看其他團隊的經驗，尤其是失敗的經驗可能會很有趣。 這些事後分析反映了現實世界的案例——始終是開發自己的尖端最佳實踐的良好起點。 我期待您的評論！