Google Kubernetes Engine(GKE)を徹底解説

記事タイトルとURLをコピーする

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。


G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) でマネージドな Kubernetes クラスタを使用することができる Google Kubernetes Engine (GKE) を解説します。Amazon Elastic Kubernetes Service (EKS) や Azure Kubernetes Service (AKS)など、kubenetes をマネージドに提供するサービスは存在しますが GKE はそれらの中でもよい評判を耳にします。例えばマスターノードの料金が不要、起動が早いといった具合です。GKE は Google Cloud 採択の理由たりえるサービスのため、優先的に仕様を調査することにしました。

Google Kubernetes Engine とは

Google Kubernetes Engine (以下、GKE) は、Google Cloud のインフラストラクチャ上で、コンテナ化されたアプリケーションのデプロイ、運用管理を行うためのマネージドな Kubernetes クラスタを利用することができるサービスです。

GKE では、Google Cloud が提供するクラスタ管理機能により、Kubernetes クラスタの管理負荷を大幅に削減することができます。

なお当記事の内容は、Kubernetes の基本的な用語の理解を前提としています。Kubernetes の基本については以下の記事で解説しているので、こちらをご一読ください。

blog.g-gen.co.jp

GKE クラスタのアーキテクチャ

GKE クラスタを作成すると、コントロールプレーン (マスターノード)ノード (ワーカーノード) の 2 種類のコンポーネントが自動で構築されます。
これらのコンポーネントはそれぞれ Kubernetes のコントロールプレーン、ノードに対応しています。

GKE クラスタのアーキテクチャ

コントロールプレーン

GKE クラスタのコントロールプレーンは Google Cloud のマネージド VPC 内に作成され、ユーザに構築、運用の負荷は発生しません。
kube-apiserver プロセスによってクラスタの統合エンドポイントが提供され、Kubernetes API 経由でクラスタの操作を行います。

ノード

クラスタには、ワークロードを実行する 1 つ以上のノードが含まれます。
GKE クラスタでは、ノードは Compute Engine インスタンスによって構成され、クラスタ作成時に自動的に作成されます。
ノードでは自動修復機能がデフォルトで有効となっており、クラスタ内の各ノードのヘルスチェックが定期的に行われます。

ノードの運用管理に関するユーザ側の責任範囲については、後述の 運用モード によって異なります。

クラスタの運用モード (クラスタタイプ)

GKE では、Autopilot モードStandard モード という 2 種類の 運用モード で マネージド Kubernetes クラスタが提供され、それぞれクラスタに対する構成の柔軟性、ユーザが持つ権限、ユーザによる管理の範囲などが異なります。

GKE クラスタの運用モード

運用モードの詳細な比較については、ドキュメント に一覧表があるので、こちらをご一読ください。

Autopilot モード

GKE では、基本的に Autopilot モードの使用が推奨されています。

GKE クラスタを Autopilot モード で作成した場合、GKE のベストプラクティスと推奨事項を遵守した、本番環境ワークロード向けにあらかじめ最適化されたクラスタ構成が提供されます。

Autopilot モードを使用した場合、ワークロードが実行されるノードは Google Cloud によって管理され、必要に応じてスケーリング、修復、セキュリティパッチの適用などが自動的に行われます。

また、Autopilot モードでは、ワークロードが使用しているコンピューティングリソースに対してのみ料金が発生します。
ノードの未使用のコンピューティングリソースや OS 実行のコスト、実行中のワークロードに関係しないリソースの使用などの料金は発生しません。

Standard モード

Standard モードでは、コントロールプレーンのみ Google Cloud によって管理され、クラスタとノードの構成および管理についてはユーザが行います。
ユーザが管理する必要がある主な設定は次の通りです。

管理対象 内容
ノードプール 同様の構成設定をもつノードをグループ化して管理する。
セキュリティ Workload IdentityShielded GKE ノード など、GKE で利用することができるセキュリティ機能を手動で有効化/無効化する。
スケジューリング ビンパッキングなどを行い、未使用のリソースを最小限に抑えるようにワークロードを設計する。
スケーリング ノードのプロビジョニング、スケーリング設定を調整し、ノードが適切な範囲でスケーリングされるように設計する。
バージョン管理 GKE クラスタのバージョンや、自動アップグレードに関する設定を手動で行う。

また、Standard モードでは、ノード上で実行されているワークロードにかかわらず、各ノードのコンピューティングリソースに対して料金が発生します、
そのため、スケジューリング、スケーリングを上手く設計し、リソース消費を最小限に抑える必要があります。

先述したように、GKE では基本的には Autopilot モードの使用が推奨されていますが、以下のようなケースにおいて Standard モードを使用することになります。

  • クラスタ構成を詳細に制御する必要がある。
  • Autopilot モードの制約 を満たさないワークロードを実行する必要がある。

クラスタの可用性

GKE では、コントロールプレーンとノードの可用性について、3 種類の 可用性タイプ から選択します。
Autopilot モードでは、自動的に リージョンクラスタ として設定されます。

可用性タイプ コントロールプレーンの可用性 ノードの可用性
シングルゾーンクラスタ 1 つのゾーンで単一のコントロールプレーンが実行される。 すべてのノードがコントロールプレーンと同一ゾーンで実行される。
マルチゾーンクラスタ 1 つのゾーンで単一のコントロールプレーンが実行される。 リージョン内の複数のゾーンで各ノードが実行される。
リージョンクラスタ リージョン内の複数のゾーンでコントロールプレーンが実行される。 リージョン内の複数のゾーンで各ノードが実行される。

シングルおよびマルチゾーンクラスタでは、コントロールプレーンが動作するゾーンに障害があった場合や、コントロールプレーンのアップグレードなどがあった場合にワークロードが停止する可能性があります。
したがって、本番環境ワークロードの実行には、リージョンクラスタの使用が推奨されます。

ただし、リージョンクラスタでは構成の変更を行った際、変更がすべてのコントロールプレーンに反映される必要があるため、変更にかかる時間が長くなるという欠点があります。
可用性の重要度が比較的低く、また構成変更を柔軟に行う必要があるワークロードの実行では、シングルおよびマルチゾーンクラスタの使用も検討します。

また、コントロールプレーンの冗長化は料金に影響しませんが、例えばゾーンクラスタで 1 ノードで実行するようなワークロードをマルチゾーンクラスタやリージョンクラスタで構成すると、複数ゾーンにノードを冗長化するために、3 ノードぶん (ゾーンあたり 1 ノード) の料金が発生してしまいます。
ゾーンの異なるノード間で通信を行う場合にネットワーク料金が発生する ことにも注意する必要があります。

クラスタの可用性タイプはクラスタ作成後に変更することはできない ため、Standard モードで GKE を利用する場合、上記のトレードオフを考慮しつつ、慎重に選択する必要があります。

クラスタのネットワークモード

GKE では、Pod 間のトラフィックをルーティングする方法によって、VPC ネイティブクラスタルートベースクラスタ の 2 つの ネットワークモード が存在します。

基本的には VPC ネイティブクラスタの使用が推奨されており、Autopilot モードのクラスタでは VPC ネイティブクラスタが使用されるようになっています。
クラスタのネットワークモードについても、クラスタの作成後に変更することはできません。

VPC ネイティブクラスタ

VPC ネイティブクラスタでは、GKE クラスタに対して、ノードを作成する VPC ネットワークのサブネットを関連付けます。
クラスタの作成時に、以下の 3 つの IP アドレス範囲を設定します (重複不可)。

  • クラスタ内のすべてのノードに対して割り当てる、サブネットのプライマリ IP アドレス範囲
  • すべての Pod に使用される、サブネットのセカンダリ IP アドレス範囲
  • すべての Service ( Cluster IP ) に使用される、サブネットの別のセカンダリ IP アドレス範囲

このように、各リソースに対して VPC のサブネットを割り当てることで、Pod が VPC ピアリング接続や Cloud VPN で接続された他のネットワークに接続することができます。
また、ネットワークエンドポイントグループ ( NEG ) を使用した コンテナネイティブの負荷分散 やファイアウォールルール、共有 VPC など、VPC に紐付いた機能を利用することができます。

VPC ネイティブクラスタを使用する注意点としては、クラスタ内部で使用されるエイリアス IP 範囲と、VPC で既に使用している IP 範囲が重複しないようにネットワーク設計をする必要があります。

ルートベースクラスタ

ルートベースクラスタでは、クラスタに対して RFC 1918 ブロックから任意の IP アドレスを指定します。
ここで指定した IP アドレス範囲から、クラスタ内のノードごとに IP アドレス範囲が割り振られ、それが Pod と Service に対して使用されます。

Pod や Service に使用される IP アドレス範囲は、ノードが作成される VPC ネットワークとは別のネットワークとなる ため、ノードが存在する VPC に対して、ノード内ネットワークへのカスタムルートが自動で追加されます。
そのため、ノードのスケーリングによりルート数の上限値に達しないように設計する必要があります。

元々 GKE ではルートベースクラスタのみ作成することができました。
VPC ネイティブクラスタでは Pod が VPC に紐づくリソースとなることで得られるメリットが多いことから、現在はルートベースクラスタの利用は推奨されていません。

クラスタのスケーリング

Autopilot モードのクラスタでは、ワークロードで使用されるリソースを需要に応じて自動で確保しますが、Standard モードのクラスタの場合、ワークロードを実行する Pod が適切な数だけ展開できるように、クラスタに対してスケーリングの設定を行う必要があります。

ノードプールとは

ノードプール とは、 Standard モードのクラスタで使用する、クラスタ内で 同じ構成を持つノードのグループ です。

クラスタの作成時に、起動するノード数や、ノードが使用する OS イメージ、ローカル SSD 、CPU プラットフォーム、マシンタイプなどを設定し、ノードプールを作成します。
ノードプール内のノードはすべて同一の構成になり、ノードプール単位でスケーリングの設定をすることができます。

ノードプールは後から追加することもでき、例えば Spot VM を使用するノードプールなど、クラスタ内に別の構成のノードプールを混在させることができます。

ノードのスケーリング

GKE では、ワークロードの需要に基づいて、クラスタ内のノード数を自動でスケーリングすることができます。

スケーリングの種類 スケーリング対象 説明
クラスタオートスケーラー ノード ノードプールに対してノードの最大数と最小数を事前に設定しておくことで、ワークロードの需要に基づいて、適切なノード数になるようにスケーリングする。

スケーリングは実際のリソース使用率ではなく、ノードプール内のノードで実行されている Pod のリソースリクエスト数に基づいて行われる。
既存のノードに Pod を起動するだけのリソースがなければ新たにノードを追加し、ノードのリソースが余っている状態が続く場合はノードを削除する。
ノードの自動プロビジョニング ノードプール ワークロードの需要に基づき、ノードプールを追加/削除する。
CPU 、メモリなどのリソースリクエストに基づいてスケーリングが行われる。
クラスタ内の Pod の要件に合わせて、最適なノードを起動できるように設定されたノードプールが追加される。

Pod のスケーリング

ワークロードの CPU やメモリなどの リソース使用量、Kubernetes から報告される カスタム指標、Kubernetes 外部にあるアプリケーションのパフォーマンスに基づいた 外部指標 などを用いて、Pod の自動スケーリングを設定することができます。

スケーリングの種類 スケーリング対象 説明
水平 Pod 自動スケーリング Pod 数 指標に基づいて Pod の数を自動的に増減する。
垂直 Pod 自動スケーリング Pod のリソースリクエスト 指標に基づいて Pod に必要な CPU とメモリリソースを分析し、最適なリソース量を推奨値として算出する。
推奨値を使用した Pod を自動で起動するように設定することもできる。
多次元 Pod 自動スケーリング Pod の数
Pod のリソースリクエスト
2023 年 2 月現在プレビュー
水平 Pod 自動スケーリングと垂直 Pod 自動スケーリングを同時に実現することができる。

リソース使用量の指標で垂直 Pod 自動スケーリングと水平 Pod 自動スケーリングを併用すると、それぞれのオートスケーラーが需要の変化に対応するため、競合が発生します。
多次元 Pod 自動スケーリングでは、このようなオートスケーラーの競合を回避しながら、水平と垂直の両方向のスケーリングを実現することができます。

ストレージ

GKE クラスタでストレージを利用する場合、マネージドオプション として Google Cloud のストレージプロダクトを GKE クラスタの外部で使用するか、Kubernetes の ストレージ抽象化 によって、一部の Google Cloud ストレージプロダクトを Kubernetes リソースとして管理することができます。

マネージドオプション

Compute Engine などのコンピュートプロダクトで使用するときと同様に、Google Cloud のストレージプロダクトを作成し、GKE クラスタから接続することができます。
この場合、Kubernetes のライフサイクルとは関係なくリソースが作成されるため、クラスタの削除後もストレージとして利用していたリソースが残り続けます。

以下は、GKE から接続できるストレージプロダクトの抜粋となります。

ストレージの種類 対応するプロダクト
データベース Cloud SQL
Datastore
Cloud Spanner
オブジェクトストレージ Cloud Storage
ブロックストレージ Persistent Disk
コンテナイメージレジストリ Artifact Registry
Container Registry
ファイルサーバ Cloud Filestore

Kubernetes のストレージ抽象化

Kubernetes のストレージ抽象化では、Kubernetes のリソースである Volume および PersistentVolume リソースを使用し、ストレージリソースを Pod や Kubernetes のライフサイクルに組み込むことができます。

Volume で使用できる emptyDir では、Pod 内に読み書き可能の空のディレクトリが作成され、Pod の削除とともにディレクトリ内のデータも削除されます。

PersistentVolume では Google Cloud のプロダクトである Compute Engine の Persistent Disk や Filestore などを Kubernetes のリソースとして抽象化 して管理できます。
Kubernetes のライフサイクルでリソースが管理されるため、クラスタの削除後もデータを保持したい場合は、リソースのマニフェストで 再利用ポリシー を設定します。

バックアップ

Kubernetes ボリュームスナップショット

通常、GKE では Kubernetes リソースである PersistentVolume に Compute Engine の Persistent Disk が使用されます。

Kubernetes ボリュームスナップショット を使用することで、GKE クラスタ内の PersistestVolume リソース のスナップショットを取得することができます。

Backup for GKE

GKE のアドオンとして Backup for GKE を使用することで、GKE クラスタ全体をバックアップすることができます。
取得したバックアップからは、クラスタ全体を復元したり、クラスタ内の単一のワークロードのみロールバックしたりすることが可能です。

バックアップはスケジュール実行することができ、最小間隔は 10 分となっています。

セキュリティ

GKE クラスタの認証と認可

GKE では、Kubernetes のユーザアカウントは Google Cloud で管理されます。
Kubernetes ユーザアカウントには以下の 2 種類のいずれかが使用されます。

  • Google アカウント / グループ
  • Google Cloud サービスアカウント

プロダクトとしての GKE に対するプロジェクトレベルのアクセス制御は、他の Google Cloud プロダクト同様に IAM で行います。

クラスタレベルや Kubernetes 名前空間 (Namespace) レベルで Kubernetes リソースへのアクセス制御を行う場合は、Kubernetes のロールベースのアクセス制御 ( Kubernetes RBAC ) を使用します。
Kubernetes のリソースとして Role または ClusterRole を作成し、RoleBinding または ClusterRoleBinding リソースを使用してユーザアカウントにロールを割り当てます。

限定公開クラスタ

通常の GKE クラスタは、ノードに対してパブリック IP アドレスが付与されており、Nodeport を利用してワークロードを公開することで、外部からアクセスすることができます。
コントロールプレーンに対しては パブリックエンドポイント が提供されており、インターネットからクラスタに対する kubectl による管理操作を行うことができます。
コントロールプレーンに 承認済みネットワーク を設定し、パブリックエンドポイントに対するアクセス元 IP を制限することができます。

VPC ネイティブクラスタのみ、GKE クラスタを 限定公開クラスタ として構成することで、コントロールプレーンとノードをインターネット接続から分離することができます。
限定公開クラスタは、クラスタ作成時のみ設定することができます。

限定公開クラスタでは、ノードにはプライベート IP アドレスのみが付与されます。
コントロールプレーンが存在するマネージド VPC と、ノードが作成される VPC がピアリング接続され、コントロールプレーンとノード間のルーティングにプライベート IP アドレスが使用されます。
外部ネットワークからノード上のワークロードにアクセスする場合は、LoadBalancer や Ingress などの Service を作成し、ロードバランサを使用してワークロードを公開できるように設定します。

コントロールプレーンに対してはパブリックエンドポイントと プライベートエンドポイント が提供され、必要に応じてパブリックエンドポイントを無効化することができます。
プライベートエンドポイント経由で kubectl による管理操作を行う場合、VPC に作成した踏み台サーバから行うか、Cloud VPN または Cloud Interconnect を使用します。

限定公開クラスタに対するアクセスの例

Workload Identity

GKE クラスタ内の Pod から Google Cloud 内の他のリソースにアクセスする場合、クラスタに設定した IAM サービスアカウントの認証情報を使用することができますが、その場合、クラスタ内のすべての Pod が IAM サービスアカウントの認証情報を使用することができてしまいます。

GKE では、より安全な方法として Workload Identity の使用が推奨されます。 Workload Identity では、Kubernetes のリソースである ServiceAccount と IAM サービスアカウントを紐付ける ことで、その Kubernetes の ServiceAccount を使用する Pod だけが Google Cloud のリソースにアクセスすることができます。

クラスタのアップグレード

リリースチャンネル

Kubernetes では、セキュリティの更新や既知の問題の修正、新機能導入のため、頻繁にアップデートがリリースされています。
GKE では、クラスタを リリースチャンネル に登録することで、クラスタのアップグレードを自動で管理することができます。

リリースチャンネルは 3 種類あり、Kubernetes のアップデートが GKE クラスタにリリースされるまでの早さを制御することができます。

リリースチャンネル Kubernetes のアップデートから GKE にリリースされるまでの期間 備考
Rapid 数週間 GKE の SLA 対象外のため、検証環境での使用が推奨される。
Regular Rapid チャンネルのリリースから 2 ~ 3 ヶ月後 デフォルトの設定
Stable Regular チャンネルのリリースから 2 ~ 3 ヶ月後

特定のバージョンの Kubernetes を使用したい場合は、Standard モードのクラスタのみ、手動アップグレードが可能となっています。

アップグレードによるクラスタへの影響

マルチゾーンおよびゾーンクラスタを使用している場合、コントロールプレーンが冗長化されていないため、アップグレード中はコントロールプレーンに依存するクラスタの操作が不可能になります。

ノードについては、以下の アップグレード戦略 が使用されるため、実行中のワークロードが停止することなくアップグレードを実施できます。

アップグレード戦略 特徴
サージアップグレード ローリング方式を使用してノードをアップグレードする。
設定によってはワークロードが一時的に縮退運転となるが、コストを抑えてアップグレードを行うことができる。
Blue/Green アップグレード Blue/Green 方式を使用してノードをアップグレードする。
一時的にノードリソースが 2 倍になるためコストが高くなるが、迅速なロールバックが必要な場合はこちらを使用する。

モニタリング

GKE は Cloud Monitoring や Cloud Logging と統合されており、クラスタの作成時にデフォルトで有効化されます。

Cloud Monitoring では、Pod やノードにおける CPU 、メモリ、ストレージのリソース使用状況やネットワーク送受信量などの システム指標 が利用できるほか、オプションでコントロールプレーンに対するリクエスト数やリクエストのレイテンシ、スケジューラのレイテンシなどの コントロールプレーンの指標 を利用することができます。

Cloud Logging では、以下のログがデフォルトで収集されます。

ログの種類 説明
監査ログ コンソールや gcloud コマンド、SDK などを使用した、GKE クラスタの作成、削除、構成変更などの API 操作、管理アクションのログが収集される。
また、kubectl コマンドを使用した、コントロールプレーンに対する Kubernetes API 操作のログも収集される。
システムログ 自動で作成される Kubernetes のシステム用コンテナなど、ワークロードとは関係ないコンテナのログや、コンテナランタイムなどのコンテナ化されていない重要なサービスのログ、各ノードのシリアルポートの出力などが収集される。
アプリケーションログ ノードで実行しているワークロードで、STDOUT または STDERR に書き込まれたログが自動的に収集される。

また、Google Cloud Managed Service for Prometheus を使用することで、フルマネージドの Prometheus を使用して GKE クラスタで実行されるワークロードをモニタリングすることができます。

クラスタ設計時の考慮事項

ここまで解説してきたように、GKE を使用する際には様々な要素を考慮する必要があります。
クラスタ設計時に特に気をつけなければならない点としては、以下のようなクラスタ作成後に変更できない設定項目があります。

項目 検討内容
運用モード まずは構築・運用負荷の低い Autopilot モードを検討し、Autopilot モードでは達成できない要件がある場合に Standard モードを選択します。
可用性タイプ Autopilot モードの場合は自動的にリージョンクラスタとして構成されます。
Standard モードのクラスタを使用する場合は、当記事で解説したコントロールプレーンおよびノードの冗長化に伴うトレードオフを考慮します。
ネットワークモード Pod が VPC に紐づく多数の機能を利用することができる VPC ネイティブクラスタの利用が推奨されます。
VPC ネイティブクラスタでは Service や Pod が VPC で使用できる IP アドレスを消費するため、それが許容できない場合はルートベースクラスタを検討します。
限定公開クラスタ ネットワーク要件により、クラスタへのアクセスをプライベートネットワーク経由で行う必要がある場合は限定公開クラスタを使用します。

GKE Enterprise

GKE Enterprise は、マルチクラスタ管理機能を強化した GKE の上位エディションです。 Enterprise エディションとも呼ばれ、これに対して基本の GKE は Standard エディションと呼ばれます。

GKE Enterprise は、従来の Anthos の後継サービス(上位互換)です。GKE Enterprise では Anthos 同様に複数の GKE や Google Cloud 以外の Kubernetes クラスタを フリート と呼ばれる論理グループにまとめます。

また大規模なマルチクラスタの管理に役立つ以下のような機能が提供されます。

  • フリート全体で同じクラスタ構成、機能、セキュリティポリシーを自動的に構成するポリシー管理ツール
  • マルチクラスタ Ingress 、マネージドなサービスメッシュなどのマルチクラスタに対応したネットワーク管理機能
  • フリート全体で一貫した ID 管理機能
  • フリート内のクラスタやアプリケーションのモニタリング、トラブルシューティングを可能にするオブザーバビリティ機能
  • Teams 機能(クラスタを管理する単位 "Team" を提供)

これらの機能は Anthos で提供されているものですが、Anthos では独立したメニュー画面からこれらの機能にアクセスする必要がありました。GKE Enterprise では統合された UI で GKE と Anthos の管理操作を行うことができるようになっています。
GKE Enterprise はクラスタタイプ(Standard / Autopilot)を問わず使用することができます。

料金

GKE の利用料金は、クラスタ管理手数料 + 運用モードごとの利用料 で決まります。

クラスタ管理手数料

GKE では、運用モードや可用性タイプ、クラスタの規模に関係なく、1 クラスタあたり $0.10 / 時間 のクラスタ管理手数料が発生します ( 1 秒単位の課金 )。

シングルゾーンクラスタもしくは Autopilot モードのクラスタの場合、月額 $74.40 の無料枠 があり、請求先アカウントごとに提供されます。
クラスタが 1 つであれば、クラスタの管理手数料は無料枠ですべてカバーされます。

運用モードごとの利用料

Autopilot モード

Autopilot モードのクラスタでは、ノード上で実行中の Pod でリクエストされている CPU 、メモリ、エフェメラルストレージリソースに対して料金が発生します。
ノードの未使用のコンピューティングリソースや OS 実行のコスト、実行中のワークロードに関係しないリソースの使用などの料金は発生しません。

また、Spod Pod確約利用割引 を使用することで、料金を節約することができます。

以下は asia-northeast1 (東京) リージョンにおける Autopilot モードのクラスタの料金 (月額) です。

課金項目 通常料金 スポット Pod 料金 1 年間の確約利用割引 3 年間の確約利用割引
vCPU ( vCPU 数 / 月 ) $41.68 $12.48 $33.35 $22.93
メモリ ( GB / 月 ) $4.61 $1.38 $3.69 $2.54
エフェメラルストレージ ( GB / 月 ) $0.05 $0.05 $0.04 $0.03

Standard モード

Standard モードのクラスタでは、ノードを構成する Compute Engine インスタンスに対して料金が発生します。

例えば、asia-northeast1 (東京) リージョンにおいて、デフォルトのマシンタイプ e2-medium を使用した場合、ノード 1 つあたり $31.38 / 月 の課金が発生します。
Compute Engine 同様、1 年または 3 年の確約利用割引で料金を節約することも可能です。

Compute Engine の料金の詳細については、Compute Engine のドキュメント を参照してください。

Amazon EKS との違い

Amazon Elastic Kubernetes Service ( Amazon EKS ) は Amazon Web Service ( AWS ) が提供するマネージドな Kubernetes のプロダクトです。
Kubernetes はオープンソースのため、クラスタで使用できる Kubernetes の機能にほとんど差はありませんが、パブリッククラウドのプロダクトとしての差はいくつか存在します。

クラスタのアップグレードについて

自動アップグレードの提供有無

GKE では、リリースチャンネルを使用することで、Kubernetes のアップグレードを自動化することができ、また必要に応じて手動でアップグレードを実施することもできます。
GKE には、今後のアップグレードで非推奨となる API を検出でき、現在利用している Kubernetes API の中にアップグレードに伴って削除されるものがあった場合に、自動アップグレードを一時停止できる機能が提供されています。

それに対して、Amazon EKS は自動アップグレードに対応しておらず、コントロールプレーンとノードのアップグレードをそれぞれ実施する必要があります。

アップグレードのスケジュール

GKE と Amazon EKS とでは、Kubernetes の新しいバージョンがリリースされてから利用できるようになるまでの期間と、バージョンごとのサポート終了のタイミングが異なります。

最新のスケジュールについては以下のドキュメントを参照してください。

リリースまでのスケジュール

GKE のほうが、比較的短い期間で Kubernetes の新しいバージョンに対応する傾向があります。
Rapid のリリースチャンネルでは SLA が適用されないことには注意が必要ですが、早い段階から新バージョンの検証を行うことができます。

Kubernetes のバージョン Kubernetes のリリース日 GKE ( Rapid ) GKE (Regular) GKE ( Stable ) Amazon EKS
1.27 2023-04-11 2023-05-08 2023-06-14 2023-07-05 2023−05-24
1.26 2022-12-06 2023-01-13 2023-04-14 2023-06-14 2023-04-11
1.25 2022-08-23 2022-09-13 2023-12-08 2023-05-08 2023-02-22
1.24 2022-05-03 2022-06-13 2022-08-19 2022-11-30 2022-11-15
1.23 2021-12-14 2022-01-27 2022-04-29 2022-07-22 2022-08-11

サポート終了のスケジュール

Kubernetes の旧バージョンのサポート終了タイミングは、Amazon EKS のほうが比較的後になっています。
リリースのタイミングも勘案すると、Amazon EKS のほうがサポート期間が長いというわけではない点には注意が必要です。

Kubernetes のバージョン GKE Amazon EKS
1.27 2024-08-31 2024-07
1.26 2024-06-30 2024-06
1.25 2024-02-29 2024-05
1.24 2023-10-31 2024-01
1.23 2023-07-31 2023-10

Ingress で使用されるロードバランサについて

ワークロードに対する レイヤ 7 のトラフィックを負荷分散したい場合、Kubernetes の Ingress リソースを利用します。

Ingress リソースで使用されるロードバランサは、GKE では HTTP(S) Loadbalancer 、Amamzon EKS では Application Load Balancer ( ALB ) となっています。

AWS の ALB では、トラフィックのスパイクが予測される場合に、事前にロードバランサをスケーリングしておく Pre-warming (暖機運転) を行う必要があり、これは AWS のサポートに対してリクエストを送ることで実現できます。
これは、AWS 側で作業が発生するため、数日前には申請しておく必要があります。

それに対して、Google Cloud の HTTP(S) Loadbalancer は常にトラフィックのスパイクに対応できるようになっており、Pre-warming の必要がありません。
したがって、HTTP(S) LoadBalancer のほうが、予想外のスパイクに対応できる仕様になっています。

このように、Amazon EKS では、クラスタでワークロードのスケーリングが適切に行われていても、ロードバランサがボトルネックとなりトラフィックを処理しきれない可能性があります。

クラスタのモニタリングについて

リソースのモニタリングについて、GKE では、Cloud Monitoring との統合がデフォルトで有効となっていますが、Amazon EKS では Amazon CloudWatch の Container Insights を手動で設定するか、サードパーティツールを使用する必要があります。

クラスタの料金について

EKS では、GKE 同様に 1 クラスタあたり $0.10 / 時間 の料金が発生します。
GKE の場合、クラスタの可用性モードにもよりますが、無料枠によって 1 クラスタぶんの料金が相殺されるため、EKS よりも料金が安くなる傾向があります。

佐々木 駿太 (記事一覧)

G-gen最北端、北海道在住のクラウドソリューション部エンジニア

2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。

趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。