2023 年の GKE の進化を振り返る
Google Cloud Champion Innovators Advent Calendar 2023 の 4 日目の記事です。
今年も GKE (Google Kubernetes Engine) には多くのアップデートがありました。
網羅的にアップデート情報を把握したい場合は GKE のリリースノート を見て頂ければと思いますが、定期的なバージョンアップデートの情報なども含むため、それなりのボリュームになっています。
そこで、この記事では「最近の GKE を追っていないので直近どのようなアップデートがあったのかざっくり把握したい」という方向けに、今年の GKE の主なアップデートを振り返り、自身の利用経験・知見と併せてご紹介したいと思います。
ちなみに、個人的なベストアップデートは「複数のノードプールの変更操作が並行して実行可能になったこと」です。
なお、GKE Standard / Autopilot のどちらか一方にのみ関連するアップデートについては、(Standard) または (Autopilot) という表記で運用モードを明記しています。
GKE Enterprise の登場から、従来の GKE を（運用モードとは関係なく） GKE Standard エディションと呼ぶようになったことでエディションと運用モードを誤解されるケースがありますが、この記事では特に明記しない限りエディションに関係なく利用可能なアップデートとお考えください。
ストレージ関連
(Standard) ローカル NVMe SSD がエフェメラルストレージとして利用可能に (2023/1)
NVMe を使ったローカル SSD を GKE ノードにプロビジョニングし、ワークロードのエフェメラルストレージとして利用できるようになりました。
永続化する必要のない中間ファイルの作成・読み取りなどを行う際にパフォーマンスの向上が期待できます。
ローカル SSD をアタッチする場合、GKE ノードに N1 や N2 といった第 1/2 世代のマシンシリーズを利用予定であれば、クラスタ作成時にオプションが必要となる点に注意しましょう（C3 のように第 3 世代のマシンシリーズの場合はオプション指定不要）。
また、デフォルトのマシンタイプである e2-medium はそもそも対応していない点にも注意です。
https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/local-ssd
GKE 向けのマネージド Cloud Storage FUSE CSI ドライバが登場 (2023/5)
マネージド Cloud Storage FUSE CSI ドライバを用いて、Cloud Storage バケットをファイル システムとしてマウントできるようになりました。
エフェメラルストレージとして Cloud Storage バケットを指定するか、Cloud Storage バケットを参照する PersistentVolume リソースを作成することで利用可能となります。
5 月の時点ではプレビュー機能として登場していましたが、現在は GA しています。
GKE における Hyperdisk の利用が GA に (2023/6)
Persistent Disk の選択肢として Hyperdisk Throughput ボリュームと Hyperdisk Extreme ボリュームが加わり、いずれも GA で利用可能になりました。
Hyperdisk Throughput は Autopilot, Standard のどちらでも利用可能、更に高い IOPS を求めるワークロード用に用意された Hyperdisk Extreme は GKE Standard でのみ利用可能となっています。
一時ファイルへの頻繁な読み書きのあるワークロードなどでは Persistent Disk の IOPS が性能のボトルネックになることもあるため、こうしたケースに対する有力な選択肢が増えたのは嬉しいですね。
https://cloud.google.com/kubernetes-engine/docs/concepts/hyperdisk
スケーリング関連
(Autopilot) GKE Autopilot に Balanced コンピューティングクラスが登場 (2023/1)
2022 年後半から Autopilot ではワークロードの特性に応じてコンピューティングクラスを選択するということが可能になっていましたが、その選択肢に Balanced というクラスが追加されました。
Scale-Out のコンピューティングクラスには適さない、比較的少数で大きめのワークロードを実行する場合などに利用機会があるのではと思います。
デフォルトの 汎用（General-purpose）ではバースト可能な E2 マシンシリーズが利用されるため、急速に負荷の上昇するワークロードなどでは性能が安定しないケースがありましたが、Balanced ではクラスタ内のノードに 最小 CPU プラットフォーム の条件を満たすノードだけを割り当てる、といったことが可能になり、高負荷なワークロードに適したノードをある程度選択的に利用する事ができるようになりました。
https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-compute-classes
(Standard) クラスタオートスケーラーがスケールダウン時に複数ノードの Pod を同時並行で Drain 可能に (2023/3)
クラスタオートスケーラーがスケールダウンを判断してノードを終了させる際、複数のノードで同時並行的に Pod の Drain を行うことができるようになり、従来よりも素早く目標のサイズへスケールダウンできるようになりました。
一見地味なアップデートですが、ノードの増減が頻繁に起きる環境ではノードプールの調整待ちの時間が短くなり、コスト面でもメリットのあるアップデートでした。
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler
(Autopilot) DaemonSet 利用時のノードサイズの自動最適化が登場 (2023/11)
Autopilot はノードの運用管理が不要にも関わらず DaemonSet が利用できるのですが、デプロイ順序を調整したり、事前に DaemonoSet に高めの PriorityClass を設定しておくなど、適切に全ノードにデプロイするためにはちょっとしたテクニックが必要となっていました。
これは、従来、DaemonSet を追加またはサイズ変更した場合、クラスタに追加済みのノードが必要リソースに足りない状況であっても既存ノードの再調整を行うことがなかったためです。
今回のアップデートでは、Autopilot がすべての DaemonSet のリソース要求に適合しないノードを自動検出し、要求に適合できるより大きなノードに自動移行できるようになりました。
ネットワーク関連
Cloud DNS for GKE でスタブドメイン等が利用可能に (2023/1)
GKE では従来、DNS プロバイダとして kube-dns が利用されてきましたが、その代替として最近は Cloud DNS for GKE が登場しています。
有効化すると、Pod や Service の DNS レコードが Cloud DNS に 自動的に登録され、クラスタ内の名前解決などを Cloud DNS によって処理することが可能になります。
このアップデートでは、Cloud DNS for GKE において IPv6 (シングル/デュアルスタック)や、スタブドメイン、アップストリームネームサーバとしての利用が可能になりました。
スタブドメイン等の利用により名前解決のリクエストを転送する場合は、以下の 2 点に注意しましょう。
Cloud DNS for GKE を利用する場合、kube-dns ConfigMap に設定した
stubDomainsとupstreamNameserversに基づくカスタム DNS 構成は、クラスタ内のノードと Pod の両方に適用されます。kube-dns を利用する場合は Pod にのみ適用されるため、ノードの名前解決の挙動に違いがあります。Cloud DNS for GKE を利用する場合、名前解決リクエストの転送元 IP アドレスは Cloud DNS のサービスが持つ IP アドレス範囲のいずれかとなります。一方、kube-dns を利用している場合は（VPC ネイティブクラスタであれば）Pod の IP アドレスが転送元となります。IP アドレス制限などの制約によって名前解決リクエストのソース IP アドレスが VPC の GKE ノード用 IP アドレス範囲でなければならない場合などには注意が必要です。
https://cloud.google.com/kubernetes-engine/docs/how-to/cloud-dns
バックエンドサービスベースの外部ネットワーク ロードバランサの GKE での利用が GA に (2023/3)
外部パススルーネットワークロードバランサ (External Regional L4 LB) を作成する際に、バックエンドサービスベースの構成が選択可能になりました。
従来のターゲットプールベースの外部パススルーネットワークロードバランサと比較すると、TCP, UDP 以外のプロトコルのトラフィックを負荷分散したり、コネクションドレイン が利用できるようになったりします。
https://cloud.google.com/load-balancing/docs/network#architecture
GKE Gateway Controller がグローバル外部 HTTP(S) ロード バランサで利用可能に (2023/4)
GKE Gateway Controller が External Global L7 LB でも利用可能なったことで、本格的に Kubernetes Gateway API に基づくロールベースのロードバランサ作成・運用が可能になりました（一応、Internal L7 LB は 2022/11 頃に先行して利用可能になっていました）。
従来の GKE Ingress Controller はユーザの各クラスタのコントロールプレーンに展開されていましたが、GKE Gateway Controller はユーザのクラスタやプロジェクトに依存せず、GKE クラスタの Kubernetes Gateway API へのリクエストに応じて適切なリソースを割り当て・管理するという、より抽象化された API サービスのようなアーキテクチャとなっています。
このアップデートのあとも、直近 1 年をかけて様々な GatewayClass のサポートが発表され、現在では複数のクラスタをバックエンドに持つマルチクラスタゲートウェイなども GA となっています。
GKE で利用可能な GatewayClass リソースについては こちら にまとまっています。
https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api#gateway_controller
(Standard) Pod 用のセカンダリ IP アドレス範囲を追加可能に (2023/5)
従来、ひとつのクラスタに対する Pod 用の IP アドレス範囲は連続するひとつのアドレス範囲を指定する必要があり、クラスタの作成後にアドレス範囲を変更・追加することはできませんでした。
このアップデートの登場により、既存のクラスタで Pod 用のセカンダリ IP アドレス範囲に不足が生じた場合に後から IP アドレス範囲を追加する、といった対応が可能になりました。
クラスタの IP アドレス設計の前提が変わるため、今後はより自由度の高い設計が行えそうですね。
https://cloud.google.com/kubernetes-engine/docs/how-to/multi-pod-cidr
1.27 以降の GKE で Konnectivity サービスが利用されるように (2023/5)
VPC ピアリングベースで構成されている限定公開クラスタは、GKE 1.27 以降、kube-apiserver からノードへのトラフィックに Konnectivity サービスを経由するようになりました。
Konnectivity サービスの仕組みや、GKE における仕様などについては以前調査して記事を書いていますのでご興味あればご参照ください。
https://polar3130.hatenablog.com/entry/2023/05/26/173000
GKE で FQDN ベースの Network Policy が利用可能に (2023/6)
FQDN (および正規表現) を使った下り方向 (クラスタ内のワークロードからクラスタ外へ) のネットワーク ポリシーが利用できるようになりました。
Cilium ベースのネットワーク制御の仕組みである Dataplane V2 を有効化した GKE で利用可能となっています。
FQDN Network Policy の仕様や、実機検証の様子について以前記事を書いていますのでご興味あればご参照ください。
https://polar3130.hatenablog.com/entry/2023/06/29/085200
(Standard) Pod のマルチネットワークサポートが登場 (2023/8)
こちらのアップデートにより、GKE 上で展開される Pod に複数のネットワークインタフェースをアタッチできるようになりました。
この機能は、GKE Dataplane V2 で使用されている eBPF の技術をもとに実装されています。
どうしても複数のネットワークに所属しなければならないワークロードがある、といったケースに答えられる選択肢ができたのは喜ばしいですね。
ネットワーク構成が複雑化するため、それこそ可視化ツールの恩恵に預かれると良いのですが、(現状はプレビューの機能ゆえか) モニタリング関連で紹介しているマネージド Hubble (GKE Dataplane V2 のオブザーバビリティ機能のひとつ) と併用できない点に注意が必要です。
この機能を利用することでクラスタやノードのスケーリングに関しては各種制限が追加されるため、利用を検討する場合は制限事項にもよく目を通しておくことをおすすめします。
https://cloud.google.com/kubernetes-engine/docs/how-to/setup-multinetwork-support-for-pods
モニタリング関連
(Standard) Managed Service for Prometheus が新規 Standard クラスタにおいてデフォルトで有効に (2023/6)
Managed Service for Prometheus が GKE 1.27 以降の新規 Standard クラスタにおいてデフォルトで有効化される仕様になりました。
GKE の新機能ではよくあることですが、既存ワークロードへの影響を最小限に留めるためか、既存クラスタを過去のバージョンからアップグレードして該当バージョンに引き上げた場合にはこうした機能は有効化されないことが多いです（今回もそうですね）。
既存クラスタで Managed Service for Prometheus を後から有効にしたい場合は明示的に有効化する必要があります。
https://cloud.google.com/stackdriver/docs/managed-prometheus/setup-managed#enable-mgdcoll-gke
GKE Dataplane V2 のオブザーバビリティ機能が利用可能に
GKE Dataplane V2 のメトリクス収集と、可視化ツールである Hubble の利用が可能になりました。
Hubble は Cilium と eBPF に基づくネットワークモニタリングと可視化のためのオープンソースツールで、Kubernetes クラスタ内の Hubble フローイベントと呼ばれるワークロード間の通信イベントをカウントし、相互に通信している Pod を特定・可視化するといった事が可能になっています。
オープンソースの Hubble プロジェクトはまだ GA (バージョン 1.0) には到達していないものの、現在活発に開発が進められており、個人的に今後の進展に注目しています。
https://cloud.google.com/kubernetes-engine/docs/concepts/about-dpv2-observability
https://github.com/cilium/hubble
(Autopilot) Autopilot で Kubernetes コントロールプレーンのログとメトリクスが収集可能に (2023/7)
Autopilot でも Kubernetes API Server, Scheduler, Controller Manager によって生成されたログとメトリクスを Cloud Logging と Cloud Monitoring にエクスポートできるようになりました。
トラブルシューティングの際にコントロールプレーンのログやメトリクスが解析の助けになることがあるため、Autopilot にも是非欲しいと思っていた嬉しいアップデートでした。
https://cloud.google.com/kubernetes-engine/docs/how-to/configure-metrics#control-plane-metrics
https://cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs
セキュリティ関連
(Autopilot) Autopilot で CAP_NET_ADMIN が利用可能に (2023/6)
GKE Autopilot で CAP_NET_ADMIN の Linux Capability が利用可能になりました。 これにより、NET_ADMIN の権限を必要とする Istio や LinkerD などのサービスメッシュをユーザが Autopilot のクラスタに展開可能になりました。
余談ですが、Autopilot では Standard と比べてノードの管理がマネージドになっているぶん、セキュリティ機能の利用に制限（Standard との差分）があります。
Autopilot のセキュリティ機能の利用可否や制限については以下の公式ドキュメントにまとまっており、各種セキュリティ機能の利用可否などで迷った場合にはよくお世話になっています。
GKE Security Posture ダッシュボードが Cloud コンソールに登場 (2023/7)
GKE 関連のセキュリティ強化に役立つ、GKE Security Posture ダッシュボードという機能が新たに GA しました。
何故か GKE のリリースノートには載っていないアップデートなのですが、GKE クラスタとクラスタ上に展開されたワークロード構成を自動的にスキャンし、様々な観点で評価結果をダッシュボードに可視化してくれる機能となっています。
GA 直後の頃に実際に操作して使い勝手などをレポートした記事を書いていますので、ご興味があればこちらもご参照ください。
https://polar3130.hatenablog.com/entry/2023/07/04/180900
ML 関連
(Autopilot) Autopilot で GPU ワークロードの利用が GA に (2023/1)
今年最初の GKE のアップデートとして、Autopilot で GPU ワークロードの利用が GA となりました。
Pod のマニフェストに nodeSelector で cloud.google.com/gke-accelerator ラベルに必要な GPU タイプを指定することで、そのリクエストに応じた GPU ノードを Autopilot がプロビジョニングしてくれます。
Autopilot なので Pod 単位の課金がイメージされますが、リクエストした GPU タイプによっては、ノードにアタッチされたローカル SSD のコストが固定料金で発生する点に注意です（現状、NVIDIA A100 80GB のみが課金対象で、NVIDIA A100 40GB ではこの課金が発生しないようです）。
https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-gpus
(Standard) TPU ノードが利用可能に (2023/8)
GKE Standard で TPU が利用可能になり、TPU ノードで実行されているコンテナから出力されたログの収集や、TPU の使用状況に関するメトリクスの収集にも対応するようになりました。
その後のアップデートで 2023 年 11 月には Cloud TPU v5e マシンタイプも利用可能となっています。
デフォルトでは、TPU ノードに google.com/tpu の taint が設定されるため、TPU を利用しない Pod がスケジュールされないようになっています。
そのため、システム系 Pod を展開するために別途 TPU ノード以外のノードプールを用意しておく必要がある点に注意しましょう。
https://cloud.google.com/kubernetes-engine/docs/concepts/tpus
アップグレード関連
フリートまたはスコープによる、クラスタアップグレードの順序制御が可能に (2023/8)
Anthos やそれを包含する新しいエディションである GKE Enterprise など、フリートの概念で複数の GKE クラスタをグルーピングしている状況下において、フリートまたはスコープの単位でクラスタアップグレードのロールアウトの順序制御が行えるようになりました。
例えば、開発用のクラスタが含まれるフリートのクラスタをアップグレードしてから本番用のクラスタが含まれるフリートのアップグレードが行われるように定義することで、各クラスタが自動アップグレードを有効にしている場合でも必ず開発環境のクラスタを先にアップグレードする、といったことが可能になりました。
なお、このロールアウトの順序制御によって各クラスタのアップグレードを行った際、各クラスタのアップグレード後のバージョンが一致するのはマイナーバージョンの粒度までとなります。
各種セキュリティパッチ等のリリースによってパッチバージョンや GKE としてのリリースチャネルに設定されるデフォルトのリビジョンは随時変更されるため、全クラスタのロールアウト後にリビジョンの粒度では各クラスタのバージョンが一致しない点を理解して使用する必要があります。
https://cloud.google.com/kubernetes-engine/docs/concepts/about-rollout-sequencing
(Standard) 任意のクラスタにおいて、複数のノードプールの変更操作が並行して実行可能に (2023/8)
複数ノードプールの同時アップグレードや、ノードプールのアップグレード中に別のノードプールのサイズを変更するといった並行操作が可能になりました。
従来、ノードの追加やアップグレードなど、ノードプールの変更操作を行う場合、同時にはクラスタ内のいずれかひとつのノードプールのみでしか行うことができませんでしたが、このアップデートによって複数のノードプールを抱えるクラスタで柔軟な運用が行えるようになりました。
実際に複数のノードプールを同時に操作した時の様子や、使用上の制約等について調査した内容を以前記事にしていますので、ご興味があればこちらもご参照ください。
https://polar3130.hatenablog.com/entry/2023/08/31/200000
クラスタのルート CA の自動ローテーションポリシが導入される (2023/9)
GKE のクラスタルート CA は 5 年が有効期限 となっているため、CA の有効期限が切れる前にローテーションを行う必要があります（実質的にクラスタの再作成）。
そのため、特定のクラスタを継続的にアップグレードし続けて運用している場合などでは、5 年を目処に手動でローテーションの作業が必要となります。
今回新たに導入された自動化ポリシーでは、ルート CA の有効期限が切れるまで 30 日を切ると、GKE が自動的にこのローテーションを試みます。
この自動ローテーションはクラスタに設定しているメンテナンス除外の設定を無視して実行されます。
ローテーションはノードや Pod の再作成、クラスタ API の一時停止などを伴うため、(公式ドキュメントにも記載されていますが) 最終手段となるこの自動化ポリシーに頼るのではなく、事前にユーザが手動で計画的にローテーションを行うようにしましょう。
https://cloud.google.com/kubernetes-engine/docs/how-to/credential-rotation
その他
GKE 1.26 以降で cgroup v2 がコンテナリソース管理のデフォルトに (2023/1)
他のアップデートと比べて少し低レイヤの話になりますが、Linux カーネルのリソース制御の仕組みである cgroup のバージョンが上がり、1.26 以降のバージョンで作成された新しいノードプールは cgroup v2 がデフォルトで利用されるようになりました。
cgroup v2 詳しくは下記の Kubernetes 公式ドキュメントや、技術評論社さんの記事をご覧頂くと良いかと思います。
Kubernetes としては v1.25 以降で cgroup v2 の利用が Stable となっており、メモリ QoS のように cgroup v2 でなければ利用できない機能もあります。
https://kubernetes.io/docs/concepts/architecture/cgroups/
https://gihyo.jp/admin/serial/01/linux_containers/0045
Kubernetes のイメージレジストリが k8s.gcr.io から registry.k8s.io に変更 (2023/3)
オープンソースの Kubernetes のアップデートではありますが、GKE ユーザにも影響を受けたアップデートで、GKE のリリースノートにも当時掲載されていました。
エンタープライズではアクセス可能なレジストリが制限されているケースも少なくないと思いますので、こうしたアップストリームの変更も追いかけておくとインシデントを未然に防ぐことにつながるかと思います。
https://kubernetes.io/blog/2023/03/10/image-registry-redirect/
GKE Enterprise の登場 (2023/8)
今年の GKE で特に大々的にアナウンスされたリリースとしては、Google Cloud Next '23 で登場したこちらの GKE Enterprise が挙げられるのではないでしょうか。
マルチクラスタ構成で役立つ Ingress や、クラスタのマルチテナント利用に適したチーム管理機能など、大規模に GKE を利用するエンタープライズユーザ向けの機能を持つ GKE となっています。
私個人としては Anthos のリブランディングに近いイメージを持っています。
GKE Enterprise が登場した背景や、目指している世界観、提供される主な機能などについては、下記のウェビナーで紹介されていますのでこちらも併せてご確認頂くと良いかと思います。
各エディションの持つ機能の違いについては、公式ドキュメントの こちら を参照ください。
ちなみに、GKE にエディションのような概念が設けられたのはこれが初めてではありません。
かつて Next '19 ではエンタープライズ向けの GKE として GKE Advanced が発表されており、このときにも従来の GKE を GKE Standard と呼称していました。
その後、GKE Advanced は Next '18 で先に発表されていた Cloud Services Platform とともに、Anthos に統合され、今回はその Anthos が GKE Enterprise の中に包含された、というような経緯と理解しています。
おわりに
2023 年の GKE の進化をざっと振り返ってみました。
なお、それぞれのアップデートは利用可能となる GKE のバージョンが決まっていますので、アップデートされた機能の利用を検討する際は最低利用可能バージョンを公式ドキュメントでご確認ください。
紹介しきれなかったアップデートもたくさんありますので、気になった方はぜひ GKE のリリースノートも覗いてみて頂くと良いかと思います。
来年はどのようなアップデートがあるのか、今から楽しみです。
