K8s / Kubernetes：AWS vs. GCP vs. Azure
公開: 2022-03-11Kubernetes（多くの場合、定型化された「K8s」）は、数年前にコンテナーオーケストレーションツールの戦いに勝利しました。 それでも、今日でもKubernetesを実装し、さまざまなインフラストラクチャや多くのツールで動作させる方法はたくさんあります。その中には、他のツールよりも優れたメンテナンスが行われているものもあります。 ただし、おそらくその面で最も興味深い開発は、トップクラウドプロバイダーが独自のマネージドKubernetesバージョンをリリースすることを決定したことです。
- Microsoft Azureは、Azure Kubernetes Service（AKS）を提供します
- AWSはAmazonElasticKubernetes Service（EKS）を提供しています
- GoogleCloudはGoogleKubernetesEngine（GKE）を提供します
DevOpsの観点から、これらのプラットフォームは何を提供しますか？ 彼らは約束を果たしていますか？ それらの作成時間と他のベンチマークはどのように比較されますか？ それぞれのプラットフォーム、特にCLIツールとどの程度統合されていますか？ 彼らを維持し、一緒に働くのはどうですか？ 以下では、これらの質問などについて詳しく説明します。
注：読み進める前にKubernetesクラスターの概念を説明したい読者のために、DmitriyKononovが優れた紹介を提供します。
AKS vs. EKS vs. GKE：アドバタイズされた機能
管理対象のKubernetesバージョンごとに利用可能なさまざまな機能をサイロにグループ化することにしました。
- グローバル概要
- ネットワーキング
- スケーラビリティとパフォーマンス
- セキュリティと監視
- 生態系
- 価格設定
注：これらの詳細は、クラウドプロバイダーが定期的に製品を更新するため、時間の経過とともに変更される可能性があります。
グローバル概要
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| リリースされた年 | 2017年 | 2018年 | 2014年 |
| 最新バージョン | 1.15.11（デフォルト）-1.18.2（プレビュー） | 1.16.8（デフォルト） | 1.14.10（デフォルト）-1.16.9 |
| 特定のコンポーネント | oms-agent、tunnelfront | aws-node | fluentd、fluentd-gcp-scaler、event-exporter、l7-default-backend |
| Kubernetesコントロールプレーンのアップグレード | マニュアル | マニュアル | 自動（デフォルト）または手動 |
| ワーカーのアップグレード | マニュアル | はい（管理対象ノードグループで簡単） | はい：自動および手動で微調整が可能 |
| SLA | アベイラビリティーゾーンありで99.95％、アベイラビリティーゾーンなしで99.9％ | EKS（マスター）の場合は99.9パーセント、EC2（ノード）の場合は99.99パーセント | リージョン内で99.95パーセント、ゾーン内で99.5パーセント |
| ネイティブネイティブサポート | 番号 | 番号 | いいえ（ただし、ネイティブIstioインストール） |
| Kubernetesコントロールプレーンの価格 | 無料 | $0.10/時間 | $0.10/時間 |
Kubernetes自体はGoogleのプロジェクトであったため、2014年にホストバージョンを最初に提案したのは理にかなっています。
ここで比較されている3つのうち、AzureはAKSに次ぐものであり、改善する時間がありました。数年前にAzureでKubernetesをプロビジョニングするために使用されたacs-engineを覚えている場合は、Microsoftの置き換えへの取り組みに感謝します。 aks-engine。
AWSは、独自のバージョンであるEKSをロールアウトした最後のバージョンであったため、機能の面で遅れているように見えることがありますが、追いついてきています。
もちろん、価格設定に関しては、物事は常に変化しており、Googleは2020年6月から1時間あたり0.10ドルの価格でAWSに参加することを決定しました。AzureはAKSサービスを無料で提供することで、ここでは部外者ですが、その方法は不明です。それが続くかもしれない長い。
もう1つの主な違いは、クラスターのアップグレード機能にあります。 最も自動化されたアップグレードはGKEにあり、デフォルトでオンになっています。 ただし、AKSとEKSは、マスターノードまたはワーカーノードをアップグレードできるようにするために両方とも手動要求が必要であるという意味で、ここでは互いに似ています。
ネットワーキング
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| ネットワークポリシー | はい：AzureネットワークポリシーまたはCalico | Calicoをインストールする必要があります | はい：Calico経由のネイティブ |
| 負荷分散 | 基本または標準のSKUロードバランサー | クラシックおよびネットワークロードバランサー | コンテナネイティブロードバランサー |
| サービスメッシュ | 箱から出してすぐ | AWS App Mesh（Envoyに基づく） | Istio（箱から出して、ベータ版） |
| DNSサポート | CoreDNSのカスタマイズ | VPC内のCoreDNS+Route53 | CoreDNS + Google Cloud DNS |
ネットワーク側では、3つのクラウドプロバイダーは互いに非常に近接しています。 たとえば、これらはすべて、顧客がCalicoを使用してネットワークポリシーを実装できるようにします。 負荷分散に関しては、すべてが独自のロードバランサーリソースとの統合を実装し、エンジニアが何を使用するかを選択できるようにします。
ここで見られる主な違いは、サービスメッシュの付加価値に基づいています。 AKSは、すぐに使用できるサービスメッシュをサポートしていません（ただし、エンジニアは手動でIstioをインストールできます）。 AWSは、AppMeshと呼ばれる独自のサービスメッシュを開発しました。 最後に、GoogleはIstioとの独自の統合をリリースしました（まだベータ版ですが）。これは、顧客がクラスターの作成時に直接追加できるものです。
最善の策：GKE
スケーラビリティとパフォーマンス
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| ベアメタルノード | 番号 | はい | 番号 |
| クラスタあたりの最大ノード数 | 1,000 | 1,000 | 5,000 |
| 高可用性クラスター | 番号 | 制御計画についてははい、労働者のためにAZ全体で手動 | はい、リージョナルクラスターを介して、マスターとワーカーがレプリケートされます |
| 自動スケーリング | はい、クラスターオートスケーラー経由 | はい、クラスターオートスケーラー経由 | はい、クラスターオートスケーラー経由 |
| 垂直ポッドオートスケーラー | 番号 | はい | はい |
| ノードプール | はい | はい | はい |
| GPUノード | はい | はい | はい |
| オンプレミス | Azure ARC（ベータ版）経由で利用可能 | 番号 | AnthosGKE経由のGKEオンプレミス |
GKE対AKS対EKSのパフォーマンスとスケーラビリティに関しては、GKEが先行しているようです。 実際、最大数のノード（5,000）をサポートし、クラスターを適切にスケーリングする方法に関する広範なドキュメントを提供します。 高可用性のためのすべての機能が利用可能であり、微調整が簡単です。 さらに、GKEは最近、GKEとその機能の周りにエコシステムを作成するプロジェクトであるAnthosをリリースしました。 Anthosを使用すると、GKEをオンプレミスにデプロイできます。
ただし、AWSには重要な利点があります。ベアメタルノードでKubernetesクラスターを実行できるのはAWSだけです。
2020年6月の時点で、AKSはマスターの高可用性を欠いています。これは、考慮すべき重要な側面です。 しかし、いつものように、それはすぐに変わる可能性があります。
最善の策：GKE
セキュリティと監視
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| アプリの秘密の暗号化 | 番号 | はい、AWSKMS経由で可能 | はい、CloudKMS経由で可能 |
| コンプライアンス | HIPAA、SOC、ISO、PCI DSS | HIPAA、SOC、ISO、PCI DSS | HIPAA、SOC、ISO、PCI DSS |
| RBAC | はい | はい、IAMとの強力な統合 | はい |
| モニタリング | AzureMonitorコンテナーの正常性機能 | Cloudwatchに接続されたKubernetesコントロールプレーンモニタリング、ノードのContainer Insights Metrics | KubernetesEngineのモニタリングとPrometheusとの統合 |
コンプライアンスに関しては、3つのクラウドプロバイダーはすべて同等です。 ただし、セキュリティの観点から、EKSとGKEは、組み込みのキー管理サービスでセキュリティの別のレイヤーを提供します。
モニタリングに関しては、AzureとGoogle Cloudは、Kubernetesの周りに独自のモニタリングエコシステムを提供します。 Googleの1つが最近更新され、Kubernetes専用に設計されたKubernetesEngineMonitoringを使用するようになったことは注目に値します。
Azureは、元々は基本的な非Kubernetesコンテナエコシステム用に作成された独自のコンテナ監視システムを提供します。 2020年6月の時点で、プレビューモードで、Kubernetes固有のメトリックとリソース（クラスターヘルス、デプロイ）のモニタリングが追加されました。
AWSは、Cloudwatchで直接コントロールプレーンの軽量モニタリングを提供します。 ワーカーをモニタリングするには、クラスターにインストールできる特定のCloudWatchエージェントを介して提供されるKubernetesContainerInsightsメトリクスを使用できます。
最善の策：GKE
生態系
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| 市場 | Azure Marketplace（ただし、明確なAKS統合はありません） | AWSマーケットプレイス（250以上のアプリ） | Googleマーケットプレイス（90以上のアプリ） |
| Infrastructure-as-Code（IaC）サポート | Terraformモジュール Ansibleモジュール | Terraformモジュール Ansibleモジュール | Terraformモジュール Ansibleモジュール |
| ドキュメンテーション | 弱いが完全で強力なコミュニティ（2,000以上のStack Overflow投稿） | あまり徹底的ではありませんが、強力なコミュニティ（1,500以上のStack Overflow投稿） | 広範な公式ドキュメントと非常に強力なコミュニティ（4,000以上のStack Overflow投稿） |
| CLIサポート | 完了 | 完全な、および特別な個別のツールeksctl （以下で説明） | 完了 |
エコシステムに関しては、3つのプロバイダーは異なる強みと資産を持っています。 AKSは現在、そのプラットフォームに関する非常に完全なドキュメントを持っており、StackOverflowへの投稿に関しては2番目です。 EKSのStackOverflowへの投稿数は最も少ないですが、AWSMarketplaceの強みの恩恵を受けています。 最も古いプラットフォームであるGKEは、Stack Overflowに最も多くの投稿があり、市場にはかなりの数のアプリがありますが、最も包括的なドキュメントもあります。
おすすめの方法：GKEとEKS
価格設定
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| 無料使用上限 | 170ドル相当 | 無料利用はできません | 300ドル相当 |
| Kubernetesコントロールプレーンのコスト | 無料 | $0.10/時間 | $ 0.10 /時間（2020年6月） |
| 割引価格（スポットインスタンス/プリエンプティブルノード） | はい | はい | はい |
| 1か月の価格例 | 342ドル 3つのD2ノード | 300ドル 3t3。ラージノード | 190ドル 3n1-標準-2ノード |
全体的な価格に関しては、GKEが任意のクラスターに1時間あたり0.10ドルの価格を実装する動きを見せたとしても、それははるかに安価なクラウドのままです。 これは、Googleに固有の機能、つまり、オンデマンドリソースの月間使用量が特定の最小値に達するたびに適用される持続使用割引のおかげです。
価格の行の例では、クラウドプロバイダーが課金できるKubernetesクラスターへのトラフィックが考慮されていないことに注意してください。
AWSがEKSクラスターのテストに無料利用枠の使用を許可しない理由は、EKSがtX.micro階層よりも大きなマシンを必要とし、EKSの時間単位の料金が無料利用枠にないためです。
それでも、各クラウドプロバイダーのスポット/プリエンプティブノードを使用して、これらのマネージドKubernetesオプションのいずれかを適切な負荷でテストすることは経済的です。この戦術により、最終価格を80〜90％簡単に節約できます。 （もちろん、そのようなマシンでステートフルプロダクションロードを実行することはお勧めしません！）
宣伝されている機能とGoogleの利点
オンラインで宣伝されているさまざまな機能を見ると、マネージドKubernetesバージョンが市場に出回っている期間と機能の数には相関関係があるようです。 前述のように、GoogleがKubernetesプロジェクトのイニシエーターであったことは否定できない利点のようであり、その結果、独自のクラウドプラットフォームとの統合がより良く、より強力になります。
しかし、AKSとEKSは、成熟するにつれて過小評価されるべきではありません。 どちらも独自の機能を利用できます。 たとえば、ベアメタルノードを統合しているのはAWSだけであり、市場で最も多くのアプリケーションを誇っています。
各Kubernetesオファリングのアドバタイズされた機能が明確になったので、いくつかのハンズオンテストでさらに深く掘り下げてみましょう。
Kubernetes：AWS対GCP対Azureの実際
広告は1つのことですが、本番環境の負荷に対応する場合、さまざまなプラットフォームをどのように比較しますか？ クラウドエンジニアとして、Infrastructure-as-Codeを適用する際に、クラスターの生成と停止にかかる時間の重要性を知っています。 しかし、各CLIの可能性を探り、各クラウドプロバイダーがクラスターを生成するのがいかに簡単であるか（またはそうでないか）についてもコメントしたいと思いました。
クラスター作成のユーザーエクスペリエンス
AKS
AKSでは、クラスターの生成はAWSでのインスタンスの作成に似ています。 AKSメニューを見つけて、さまざまなメニューを順番に確認してください。 構成が検証されると、2段階のプロセスでクラスターを作成できます。 これは非常に簡単で、エンジニアはデフォルト設定でクラスターを簡単かつ迅速に起動できます。
EKS
クラスターの作成は、EKSとAKSでは間違いなく複雑です。 まず、デフォルトでは、AWSは最初にIAMにアクセスして、Kubernetesコントロールプレーンの新しいロールを作成し、エンジニアを割り当てる必要があります。 このクラスターの作成にはノードの作成が含まれていないことにも注意することが重要です。したがって、平均11分を測定した場合、これはマスターの作成のみを対象としています。 ノードグループの作成は、管理者にとってもう1つのステップであり、IAMコントロールパネルを介して作成する必要のある3つのポリシーを持つワーカーの役割が必要です。
GKE
私にとって、クラスターを手動で作成する経験は、GKEで最も快適です。 Google Cloud ConsoleでKubernetesエンジンを見つけたら、クリックしてクラスタを作成します。 左側のメニューには、さまざまなカテゴリの設定が表示されます。 Googleは、簡単に変更可能なデフォルトのノードプールを新しいクラスターに事前入力します。 最後になりましたが、GKEはクラスターの生成時間が最も速く、次の表に進みます。
クラスターをスポーンする時間
| サービス面 | AKS | EKS | GKE |
|---|---|---|---|
| サイズ | 3つのノード（Ds2-v2）、それぞれに2つのvCPU、7GBのRAMがあります | 3ノードt3.large | 3ノードn1-標準-2 |
| 時間（m：ss） | フルクラスターの平均5:45 | マスターの場合は11:06、ノードグループの場合は2:40（フルクラスターの場合は合計13:46） | フルクラスターの平均2:42 |
同じ地域（AKSの場合はフランクフルトと西ヨーロッパ）でこれらのテストを実行して、この違いが産卵時間に与える可能性のある影響を取り除きました。 また、クラスターのノードに同じサイズを選択しようとしました。それぞれ2つのvCPUと7GBまたは8GBのメモリを備えた3つのノードで、Kubernetesに小さな負荷をかけて実験を開始するための標準サイズです。 平均を計算するために、各クラスターを3回作成しました。
これらのテストでは、GKEは常に3分未満の産卵時間でずっと進んでいました。
Kubernetes：AWSとGCPとAzureCLIの概要
すべてのCLIが同じように作成されるわけではありませんが、この場合、3つのCLIはすべて実際にはより大きなCLIのモジュールです。 各クラウドプロバイダーのCLIツールチェーンを起動して実行するのはどのようなものですか？
AKS CLI（ az経由）
azツールをインストールしてから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では、異なるアプローチを見つけました。EKSクラスターを管理するための2つの異なる公式CLIツールがあります。 いつものように、 awsはAWSリソース、特にクラスターに接続できます。 ローカルのkubeconfigにクレデンシャルを取得するには、 aws eks update-kubeconfig --name cluster-testます。
ただし、エンジニアは、 eksctlによって開発されGoで記述されたeksctlを使用して、EKSクラスターを簡単に作成および管理することもできます。 EKSがクラウドエンジニアにもたらす大きなメリットは、CloudFormationと連携しているため、YAML構成ファイルと組み合わせてInfrastructure-as-Code（IaC）を作成できることです。 EKSクラスターをAWSのより大きなインフラストラクチャに統合する際に、これは間違いなく考慮すべき資産です。
eksctlを介したクラスターの作成は、 eksctl create clusterと同じくらい簡単で、他のパラメーターは必要ありません。
GKE CLI（ gcloud経由）
GKEの場合、手順は非常に似ていますgcloudをインストールしてから、 gcloud initを介して認証します。 そこからの可能性：エンジニアは、クラスターの作成、削除、説明、資格情報の取得、サイズ変更、更新、アップグレード、またはクラスターの一覧表示を行うことができます。
gcloudでクラスターを作成するための構文は簡単ですgcloud container clusters create myGCloudCluster --num-nodes=1
AKS vs. EKS vs. GKE：テストドライブの結果
実際には、コンソールの単純さとクラスターの生成時間の両方の観点から、GKEが基本クラスターを起動するのに確かに最速であることがわかります。 UXに関しては、クラスターの横に接続ボタンがあり、クラスターへの接続も最も簡単です。
CLIツールに関しては、3つのクラウドプロバイダーが同様の機能を実装しています。 ただし、WeaveworksforEKSが提供する追加のツールに重点を置くことはできます。 eksctlは、既存のAWSインフラストラクチャの上にinfrastructure-as-codeを実装し、他のサービスをEKSと組み合わせて実装するのに最適なツールです。
マネージドKubernetesオファリングの前進：AWS対GCP対Azure
Kubernetesの世界で始めたばかりの人にとって、私にとって頼りになる実装はGKEです。これは、最も簡単だからです。 セットアップは簡単で、スポーン用のシンプルで高速なUXを備えており、GoogleCloudPlatformエコシステムに十分に統合されています。
AWSはレースに最後に参加しましたが、ベアメタルノードや最大のマインドシェアを持つプロバイダーと統合されているという単純な事実など、いくつかの否定できない利点があります。
最後に、AKSはその作成以来大きな進歩を遂げました。 ツールと機能の同等性は、おそらく長くはかからないでしょうが、その一方で、革新の過程に余地を残しています。 また、マネージドKubernetesオファリングと同様に、すでに親プラットフォームを使用している場合は、統合がセールスポイントになります。
チームがKubernetesクラウドプロバイダーを選択したら、他のチームの経験、特に失敗を調べることは興味深いかもしれません。 これらの事後分析は、実際の事例を反映したものであり、常に独自の最先端のベストプラクティスを開発するための良い出発点です。 以下のコメントをお待ちしております！