Kubernetes（多くの場合、定型化された「K8s」）がコンテナオーケストレーションツールの戦いに勝利しました 数年前 。それでも、今日でもKubernetesを実装し、さまざまなインフラストラクチャや多くのツールで動作させる方法はたくさんあります。その中には、他のツールよりもメンテナンスが優れているものもあります。ただし、おそらくその面で最も興味深い開発は、トップクラウドプロバイダーが独自のマネージドKubernetesバージョンをリリースすることを決定したことです。
DevOpsの観点から、これらのプラットフォームは何を提供しますか？彼らは約束を果たしていますか？それらの作成時間と他のベンチマークはどのように比較されますか？それぞれのプラットフォーム、特にCLIツールとどの程度統合されていますか？彼らを維持し、一緒に仕事をするのはどうですか？以下では、これらの質問などについて詳しく説明します。
注：読み進める前にKubernetesクラスターの概念を説明したい読者のために、DmitriyKononovは 優れた紹介 。
管理対象ごとに利用可能なさまざまな機能をグループ化することにしました 知事 サイロへのバージョン：
注：これらの詳細は、クラウドプロバイダーが定期的に製品を更新するため、時間の経過とともに変更される可能性があります。
| サービス側面 | AKS | EX | 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コントロールプレーンのアップグレード | ハンドブック | ハンドブック | 自動（デフォルト）または手動 |
| ワーカーのアップグレード | ハンドブック | はい（管理対象ノードグループで簡単） | はい：自動および手動で、微調整が可能 |
| レタス | アベイラビリティーゾーンありで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 | EX | GKE |
|---|---|---|---|
| ネットワークポリシー | はい：AzureネットワークポリシーまたはCalico | Calicoをインストールする必要があります | はい：Calico経由のネイティブ |
| 負荷分散 | 基本または標準のSKUロードバランサー | クラシックおよびネットワークロードバランサー | コンテナネイティブロードバランサー |
| サービスメッシュ | 箱から出してすぐ | AWSアプリメッシュ（Envoyに基づく） | Istio（箱から出して、ただしベータ版） |
| DNSサポート | CoreDNSのカスタマイズ | VPC内のCoreDNS + Route53 | CoreDNS + Google Cloud DNS |
ネットワーク側では、3つのクラウドプロバイダーは互いに非常に接近しています。これらはすべて、顧客がCalicoを使用してネットワークポリシーを実装できるようにします。負荷分散に関しては、すべてが独自のロードバランサーリソースとの統合を実装し、エンジニアが何を使用するかを選択できるようにします。
ここで見られる主な違いは、サービスメッシュの付加価値に基づいています。 AKSは、すぐに使用できるサービスメッシュをサポートしていません（ただし、エンジニアは手動でIstioをインストールできます）。 AWSは、AppMeshと呼ばれる独自のサービスメッシュを開発しました。最後に、GoogleはIstioとの独自の統合をリリースしました（まだベータ版ですが）。これは、顧客がクラスターの作成時に直接追加できるものです。
SQLサーバーをOracleに移行する
最善の策：GKE
| サービス側面 | AKS | EX | GKE |
|---|---|---|---|
| ベアメタルノード | 番号 | はい | 番号 |
| クラスターあたりの最大ノード数 | 1,000 | 1,000 | 5,000 |
| 高可用性クラスター | 番号 | 制御計画についてははい、労働者のためのAZ全体のマニュアル | はい、リージョナルクラスターを介して、マスターとワーカーがレプリケートされます |
| 自動スケーリング | はい、クラスターオートスケーラー経由 | はい、クラスターオートスケーラー経由 | はい、クラスターオートスケーラー経由 |
| 垂直ポッドオートスケーラー | 番号 | はい | はい |
| Node Pools | はい | はい | はい |
| GPUノード | はい | はい | はい |
| オンプレミス | Azure ARC（ベータ版）経由で利用可能 | 番号 | AnthosGKEを介したGKEオンプレミス |
GKE対AKS対EKSのパフォーマンスとスケーラビリティに関しては、GKEが先行しているようです。実際、最大数のノード（5,000）をサポートし、クラスターを適切にスケーリングする方法に関する広範なドキュメントを提供します。高可用性のためのすべての機能が利用可能であり、微調整が簡単です。さらに、GKEは最近、GKEとその機能の周りにエコシステムを作成するプロジェクトであるAnthosをリリースしました。 Anthosを使用すると、GKEをオンプレミスにデプロイできます。
ただし、AWSには重要な利点があります。ベアメタルノードでKubernetesクラスターを実行できるのはAWSだけです。
2020年6月の時点で、AKSはマスターの高可用性を欠いています。これは、考慮すべき重要な側面です。しかし、いつものように、それはすぐに変わる可能性があります。
最善の策：GKE
| サービス側面 | AKS | EX | 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 | Kubernetesエンジンの監視とPrometheusとの統合 |
コンプライアンスに関しては、3つのクラウドプロバイダーはすべて同等です。ただし、セキュリティの観点から、EKSとGKEは、組み込みのキー管理サービスでセキュリティの別の層を提供します。
モニタリングに関しては、AzureとGoogle Cloudは、Kubernetesの周りに独自のモニタリングエコシステムを提供します。 Googleの1つが最近更新され、Kubernetes専用に設計されたKubernetes EngineMonitoringを使用するようになったことは注目に値します。
Azureは、元々は基本的な非Kubernetesコンテナエコシステム用に作成された独自のコンテナ監視システムを提供します。 2020年6月の時点で、プレビューモードで、Kubernetes固有の指標とリソース（クラスターの状態、デプロイ）のモニタリングが追加されました。
AWSは、Cloudwatchで直接コントロールプレーンの軽量モニタリングを提供します。ワーカーをモニタリングするには、クラスターにインストールできる特定のCloudWatchエージェントを介して提供されるKubernetes Container InsightsMetricsを使用できます。
最善の策：GKE
| サービス側面 | AKS | EX | GKE |
|---|---|---|---|
| 市場 | Azure Marketplace（ただし、明確なAKS統合はありません） | AWSマーケットプレイス（250以上のアプリ） | Google Marketplace（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 | EX | 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％節約できます。 （もちろん、そのようなマシンでステートフルプロダクションロードを実行することはお勧めしません！）
オンラインで宣伝されているさまざまな機能を見ると、マネージドKubernetesバージョンが市場に出回っている期間と機能の数には相関関係があるようです。前述のように、GoogleがKubernetesプロジェクトのイニシエーターであったことは否定できない利点のようであり、その結果、独自のクラウドプラットフォームとの統合がより良く、より強力になります。
どこで学ぶことができますかc
しかし、AKSとEKSは、成熟するにつれて過小評価されるべきではありません。どちらも独自の機能を利用できます。たとえば、AWSはベアメタルノード統合を備えた唯一のAWSであり、市場で最も多くのアプリケーションを誇っています。
各Kubernetesオファリングのアドバタイズされた機能が明確になったので、いくつかのハンズオンテストでさらに深く掘り下げてみましょう。
広告は1つのことですが、本番環境の負荷に対応する場合、さまざまなプラットフォームをどのように比較しますか？クラウドエンジニアとして、Infrastructure-as-Codeを適用する場合、クラスターの生成と停止にかかる時間の重要性を知っています。しかし、各CLIの可能性を探り、各クラウドプロバイダーがクラスターを生成するのがいかに簡単であるか（またはそうでないか）についてもコメントしたいと思いました。
AKSでは、クラスターの生成はAWSでのインスタンスの作成に似ています。 AKSメニューを見つけて、さまざまなメニューを順番に確認してください。構成が検証されると、クラスターを作成できます。これは2段階のプロセスです。非常に簡単で、エンジニアはデフォルト設定でクラスターを簡単かつ迅速に起動できます。
クラスターの作成は、EKSとAKSでは間違いなく複雑です。まず、デフォルトでは、AWSは、Kubernetesコントロールプレーンの新しいロールを作成してエンジニアを割り当てるために、最初にIAMにアクセスする必要があります。このクラスターの作成にはノードの作成が含まれていないことにも注意することが重要です。したがって、平均11分を測定した場合、これはマスターの作成のみに使用されます。ノードグループの作成は、管理者にとってもう1つのステップであり、IAMコントロールパネルを介して作成する必要のある3つのポリシーを持つワーカーのロールが必要です。
私にとって、クラスターを手動で作成する経験は、GKEで最も快適です。 Google CloudConsoleでKubernetesEngineを見つけたら、クリックしてクラスターを作成します。左側のメニューには、さまざまなカテゴリの設定が表示されます。 Googleは、簡単に変更可能なデフォルトノードプールを新しいクラスターに事前入力します。最後になりましたが、GKEはクラスターの生成時間が最も速く、次の表に進みます。
| サービス側面 | AKS | EX | 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の場合はフランクフルトと西ヨーロッパ）でこれらのテストを実行して、産卵時間に対するこの違いの影響を排除しました。また、クラスターのノードに同じサイズを選択しようとしました。3つのノードにそれぞれ2つのvCPUと7GBまたは8GBのメモリがあり、Kubernetesで小さな負荷を実行して実験を開始するための標準サイズです。各クラスターを3回作成して、平均を計算しました。
これらのテストでは、GKEは常に3分未満の産卵時間ではるかに進んでいました。
すべてのCLIが同じように作成されるわけではありませんが、この場合、3つのCLIはすべて実際にはより大きなCLIのモジュールです。各クラウドプロバイダーの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
awsまたはeksctl経由）AWSでは、異なるアプローチがあります。EKSクラスターを管理するための2つの異なる公式CLIツールがあります。いつものように、aws AWSリソース、特にクラスターに接続できます。ローカルkubeconfigへの資格情報の取得は、aws eks update-kubeconfig --name cluster-testを介して実行できます。
ただし、エンジニアは、Weaveworksによって開発されGoで記述されたeksctlを使用して、EKSクラスターを簡単に作成および管理することもできます。 EKSがクラウドエンジニアにもたらす大きなメリットは、CloudFormationと連携しているため、YAML構成ファイルと組み合わせてInfrastructure-as-Code（IaC）を作成できることです。 EKSクラスターをAWSのより大きなインフラストラクチャに統合する際に考慮することは間違いなく資産です。
eksctlを介してクラスターを作成するeksctl create clusterと同じくらい簡単で、他のパラメータは必要ありません。
gcloud）GKEの場合、手順は非常に似ています。gcloudをインストールしてから、gcloud initを介して認証します。そこからの可能性：エンジニアは、クラスターの作成、削除、説明、資格情報の取得、サイズ変更、更新、アップグレード、またはクラスターの一覧表示を行うことができます。
gcloudでクラスターを作成するための構文簡単です：gcloud container clusters create myGCloudCluster --num-nodes=1
実際には、コンソールの単純さとクラスターの生成時間の両方の観点から、GKEが基本的なクラスターを起動するのに確かに最速であることがわかります。 UXに関しては、クラスターの横に接続ボタンがあり、クラスターへの接続も最も簡単です。
CLIツールに関しては、3つのクラウドプロバイダーが同様の機能を実装しています。ただし、Weaveworks forEKSが提供する追加のツールに重点を置くことはできます。 eksctlは、他のサービスをEKSと組み合わせて、既存のAWSインフラストラクチャの上にInfrastructure-as-Codeを実装するのに最適なツールです。
Kubernetesの世界で始めたばかりの人にとって、私にとって頼りになる実装はGKEです。これは、最も簡単だからです。セットアップは簡単で、スポーン用のシンプルで高速なUXを備えており、Google CloudPlatformエコシステムに十分に統合されています。
AWSはレースに最後に参加しましたが、ベアメタルノードや最大のマインドシェアを持つプロバイダーと統合されているという単純な事実など、いくつかの否定できない利点があります。
最後に、AKSはその創設以来大きな進歩を遂げました。ツールと機能の同等性は、おそらく長くはかからないでしょうが、その一方で、革新の過程に余地を残しています。また、他のマネージドKubernetesオファリングと同様に、すでに親プラットフォームを使用している場合は、統合がセールスポイントになります。
C ++またはCを学ぶ
チームがKubernetesクラウドプロバイダーを選択したら、他のチームの経験、特に失敗を調べることは興味深いかもしれません。 これらの事後 これは実際の事例を反映したものであり、常に独自の最先端のベストプラクティスを開発するための良い出発点です。以下のコメントをお待ちしております！
コンテナーオーケストレーションは、実行中のコンテナーを中心に展開するすべてのリソース（構成、リソース、スケーリング、監視、ネットワーキング、およびツール）の管理と抽象化です。 Kubernetesは、業界で最も広く採用されているコンテナオーケストレーションツールの1つです。
サーバー上で実行されているコンテナーのフリートを効率的に管理および編成できるようにするには、コンテナーのオーケストレーションが必要です。コンテナオーケストレーションを使用すると、スケーラブルで復元力があり、強力なコンテナ中心のシステムを構築して、あらゆるアプリケーションをデプロイできます。
Kubernetesでコンテナオーケストレーションを使用する利点は、サーバーの上に抽象化レイヤーを提供してコンテナを実行できることです。 Kubernetesを使用すると、構成とリソースを効率的に管理し、必要に応じてインフラストラクチャを簡単に拡張できます。
Kubernetesは、GoogleプロジェクトであるBorgに基づいて開発されたオープンソースツールです。これは、サーバー上に抽象化レイヤーを作成して、コンテナーのスケーリング、監視、リソース使用量、ネットワーキング、および構成を簡単に管理できるようにする、実稼働グレードのコンテナーオーケストレーションツールです。
