2023.03.01

2022最新！ Google Kubernetes Engine （GKE）の最新情報をあらゆる観点から一挙にご紹介

Cloud
GKE
Gateway

本記事は、2022年4月21日に開催された Google の公式イベント「 Google Cloud ML サミット」において、 Google Cloud カスタマーエンジニアの篠原一徳氏が講演された「 Google Kubernetes Engine 最新情報」のレポート記事となります。

一般的に、複数のコンテナを管理するためには Kubernetes と呼ばれるオーケストレーションツールが使用されます。今回は Google が提供する Kubernetes のマネージドサービスである Google Kubernetes Engine （GKE）について、最新情報を交えながら詳しくご紹介します。

なお、本記事内で使用している画像に関しては、 Google Cloud ML サミット「 Google Kubernetes Engine 最新情報」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

Google Kubernetes Engine （GKE）とは？

概要

はじめに、 Google Kubernetes Engine （以下 GKE と記載）の概要をおさらいしておきましょう。 GKE は Google Cloud （GCP）上で提供されている Kubernetes のマネージドサービスです。マスターノードは GKE が管理を行うため、ユーザー側は管理の必要がありません。

なお、 Kubernetes とは、複数のコンテナを管理するためのオーケストレーションツールです。 Google の全てのサービスはコンテナ上で稼働しており、毎週20億以上ものコンテナがデプロイされています。また、ノードとはネットワークに接続されている機器を意味しており、マスターノードはノードの中でも特別な役割を与えられているノードのことです。

過去、 Google は大規模な環境で運用を行うツールとして Borg というオーケストレーションツールを開発しました。そして、何年にも渡って Borg を使用してきた経験やノウハウを活かし、 OSS として公開されたのが Kubernetes です。

GKE はコンソールを利用してクラスターを容易に構築でき、負荷に応じたノードの自動スケーリングも可能となっています。また、 Google Cloud （GCP）のサービスアカウントと連携して権限を制御するなど、セキュリティを強化するための機能も多く実装されています。

さらに、 GKE には「 GKE Standard 」と「 GKE Autopilot 」という2つのモードが存在し、 GKE Autopilot を使えばノード管理を Google に任せることができるため、自社の工数を大きく削減することが可能です。

加えて、ロードバランサーとの連携によるネットワークトラフィックの負荷分散やロギング・モニタリングなど、利用企業にとって嬉しいポイントが数多く存在します。

このように GKEは、自社の構築や運用の負荷を軽減しながら、 Kubernetes 環境としてクラウド上で利用できるコンテナのプラットフォームとなっています。 Google Cloud （GCP）の各種機能とも容易に連携でき、様々なことを実現できる点も GKE が人気を集めている理由の一つと言えるでしょう。

Kubernetes に関心のある方は以下の記事がオススメです。

Kubernetes とは？概要、機能、メリット、活用事例まで徹底解説！

アーキテクチャ

以下、 GKE のアーキテクチャを図で示します。

GKE の構成自体は Kubernetes の基本的な構成と変わりません。ただし、コントロールプレーンは Google が管理するため、 Google のプロジェクトとして配置されますが、ノードに関してはユーザーのプロジェクトで動作します。

GKE におけるクラスタの作成や更新、削除は Google Cloud （GCP）の CLI や GUI を通じて行います。その一方で、 Kubernetes としてクラスタを使う場合には、 kubectl コマンドを使って Kubernetes の API サーバーにアクセスする形になります。

Gateway 関連のアップデート

Gateway とは、サービスを外部公開する際に用いられるものであり、 ingress に代わる新しい API リソースです。

以下、 GKE の Gateway 関連のアップデートをご紹介します。

Service capacity

現在、 Gateway はpreviewで提供されていますが、この Gateway に Service capacity という新しい機能が追加されました。これは Pod 単位の RPS （ Request Per Second ：秒間のリクエスト数）を Kubernetes の Service リソースに設定することで、 Traffic-based load balancing や Traffic-based autoscaling を実現するものです。

Traffic-based load balancing

Traffic-based load balancing を活用すれば、 Service capacity で指定した Pod 単位の RPS をもとにロードバランシングを行うことができます。

上図左側の Multi region の構成では、 us-west1 と europe-west1 の2つのリージョンに GKE クラスタが存在しており、どちらのクラスタにも2つの Pod が含まれています。そして、 us-west1 では 1 Pod あたり 8 RPS の設定がされており、 europe-west1 は 1 Pod あたり 10 RPS となっています。

各クラスタに2つの Pod が存在するため、 us-west1 は 16 RPS のキャパシティを持っており、 europe-west1 は 20 RPS のキャパシティを持っている、ということになります。仮に EU クライアントから 30 RPS のトラフィックが流れてきた場合、 europe-west1 に 20 RPS 、残りの 10 RPS は us-west1 という形で負荷分散が行われます。

Traffic-based autoscaling

Traffic-based autoscaling を活用することで、実際のトラフィック流量とサービスのキャパシティをベースとして、 Pod の水平スケーリングを行うことができます。

上図右側では 1 Pod あたり 7 RPS としており、この状態で左側に記載のある HorizontalPodAutoscaler の設定をすると、例えばクライアントから 10 RPS のリクエストが来た場合、 HorizontalPodAutoscaler はレプリカの数を2つにスケールさせます。

ここでは 1 Pod あたりのキャパシティが 7 RPS となっているため、このトラフィックを捌くためには最低でも2つの Pod が必要になる、という考え方です。

運用系機能のアップデート

次に GKE の運用系機能のアップデートをご紹介します。

Backup for GKE

Backup for GKE は GKE 上のワークロードのバックアップやリストアを行う機能です。例えば、 Kubernetes リソースや GCE Persistent Disk（PD）の Volume snapshot など、 Stateful なワークロードを対象としています。

Kubernetes リソースは kube-apiserver から取得出来る情報であり、 Backup for GKE では Config backup と呼ばれています。また、 GCE Persistent Disk（PD）の Volume snapshot は PVC に対応した PD の snapshot であり、 Backup for GKE では Volume backup と呼ばれています。

以下、 Backup for GKE のアーキテクチャを図で示します。

Backup for GKE の利用シナリオとしては、

Disaster Recovery 対応
CI/CD のパイプライン
ワークロードのクローン
クラスタアップグレード時のバックアップ

など、幅広い用途が考えられます。

また、バックアップやリストアのスコープは以下の通りに選択可能です。

クラスタ全体のバックアップ / クラスタ全体のリストア
クラスタ全体のバックアップ / 部分的なリストア
Namespace 単位のバックアップ / リストア
アプリケーション単位のバックアップ / リストア

GKE のバージョニング

次に GKE のバージョニングについてご説明します。

GKE では、コントロールプレーンやノードのバージョンをそれぞれ分けて管理しており、コントロールプレーンは自動でアップグレードされます。そのため、ユーザーが無効化することはできません。

そして、各バージョンは以下の通り、3つのコンポーネントで構成されています。

また、 GKE にはリリースチャンネルという仕組みがあり、これはバージョニングとアップグレードを行う際のベストプラクティスを提供するものです。リリースチャンネルにクラスタを登録すると、コントロールプレーンとノードのアップグレードが自動的に行われます。

Maintenance Exclusion の強化

Maintenance Exclusion は日本語で「メンテナンス除外」と呼ばれており、 GKE クラスタのアップグレードを一定期間ストップする機能です。この Maintenance Exclusion は従来から存在していましたが、最近新しく Scope という設定が導入されました。

これにより、従来は30日までしか指定できなかった停止期間を最大180日（半年）に設定するなど、より柔軟な運用が可能になりました。

以下、 Maintenance Exclusion を 180 日以上設定する例です。 Maitenance Exclusion 設定時点から 180日を超えた設定はできませんが、 EoL の範囲内であれば再度180日後に Maintenance Exclusion を設定可能です。

Cluster notification

Cluster notification は任意の Pub/Sub トピックに対して、アップグレードやセキュリティに関する通知メッセージを送信できる機能です。新バージョンが利用可能になった時やアップグレードが開始される時など、様々なタイミングで通知メッセージを飛ばすことが可能です。

その他のアップデート

最後に GKE のその他のアップデートをご紹介します。

Image Streaming

Image Streaming はコンテナイメージを Pull する際に、イメージのデータをストリーミングすることで自動スケーリングの高速化や Pod 起動の高速化などを実現できる機能です。

例えば、機械学習の学習済みモデルを含むコンテナイメージなど、イメージサイズが大きく、起動時間に時間を要する場合に有効な機能だと言えます。実際、アプリケーションの起動時間が3倍改善された、という事例もあります。

以下、　Image Streaming の仕組みを図で示します。

Spot VM / Pod

Spot VM / Pod はお得に利用できる VM の一つであり、プリエンプティブル VM と違って24時間の稼働時間制限がありません。また、 Spot VM を GKE Standard のノードとして利用できることに加えて、 Autopilot モードの場合は Spot Pod として割安な価格で使うことが可能です。

Identity Service for GKE

GKE で kubectl を使って運用する際、ほとんどのケースでは Google アカウントを利用しますが、他のプラットフォームでの運用や既存プロバイダでの認証を行いたい場合は Identity Service for GKE が有効な機能になります。

Google Groups for RBAC

Google Groups for RBAC を活用することで、 Google グループのメンバーへ一括で GKE の RBAC 権限を割り当てることが可能になります。また、ユーザーアカウント個別の権限管理をせずに、プロジェクトメンバーの入退職時の処理などをシンプルに運用できる点も大きな魅力です。

GKE に関する Q&A

Q.Gateway は今後 Ingress に置き換わるものになりますか？

A.はい。 Ingress よりも Gateway の方ができることが多いですし、後発の API ということもあって今後利用が広まっていくと想定されます。

Q.Istio ベースの ASM と Gateway はどのように使い分ければ良いですか？

A.ASM に内包されている Istio Ingress Gateway というサービスメッシュの入り口にあたる Gateway と今回ご紹介した Gateway との使い分け、という前提で回答します。

今回ご紹介した Gateway は GKE クラスタの外側の話になりますが、 Istio Ingress Gateway はサービスメッシュの入り口に置かれるものであるため GKE クラスタの内側にあるイメージになります。つまり、ゲートウェイとして配置されているポイントが異なるので、状況に合わせて使い分けを行う必要があります。