【本気で学ぶKubernetes】それでもKubernetesを使わないという選択

はじめに

こんにちは！

本記事は「本気で学ぶKubernetes」シリーズの第25回、そして最終回です。このシリーズでは、Kubernetesの基礎から実践まで、段階的に学んできました。

このシリーズは、第1回から順に読むことで体系的に学べる構成にしています。
まだご覧になっていない方は、ぜひ最初からご覧ください！

Kubernetesとは？クラスタ構成の全体像をつかむ

これまで24回にわたって、Kubernetesの基本構造、実務での使いどころ、GKE、GitOps、Workload Identity、SRE観点での責任分界と信頼性設計まで扱ってきました。

そして最終回のテーマは、少し逆説的な内容になりますがあえて「Kubernetesを使わない判断」について考えていきたいと思います。

この記事は人間がKubernetesの公式ドキュメントを読み漁りながら、人間の手で書いていますのでご安心ください!

TL;DR

忙しい方のために要点だけ図示しておきます！

Kubernetesについておさらい

Kubernetesは単なるコンテナ実行環境ではなく、非常に強力かつ多機能なコンテナオーケストレーションのプラットフォームです。

高い自由度があるため、基本的にはどんなアプリケーションでも動作させることができますし、マイクロサービスやStatefulなアプリケーション、バッチ処理など、様々なワークロードの複雑な構成にも対応できます。

大手サービスでも使用実績があるように、スケーラブルな実行基盤として大規模なトラフィックにも耐えられる強さも兼ね備えています。

過去の記事で紹介しているのでぜひご覧ください！
Kubernetesとは？クラスタ構成の全体像をつかむ

DeploymentやService、HPA、Probeといった抽象的なリソースの理解や運用設計が必要ですし、障害が起きたときにどんな対応をしていくのか、Requests/Limitsやノード管理といったリソース・コスト管理なども全て行なっていく必要があります。

規模にもよりますが、Google Cloudでコンテナを利用したマイクロサービス構成でシステムを開発する際はCloud Runを使うという選択肢もあります。

出典: Kubernetes公式ドキュメント - What is Kubernetes?

Cloud RunとGKE

Google Cloudでコンテナを動かす選択肢として、GKE（Kubernetes）以外にCloud Runというサービスがあります。

Cloud Runはコンテナイメージをデプロイするだけで動くサーバーレスな実行環境で、HTTPリクエストを受けるアプリケーションを簡単に公開できます。

その実態としてCloud RunはKubernetesにてコンテナをサーバレスで稼働するための「Knative」を活用したコンテナプラットフォームであります。
つまり裏側ではKubernetesとKnativeで動作する環境ですが、利用者がその存在をほとんど意識することなくアプリケーションの実行環境だけを使えるように提供してくれているサービスといえますね！

出典: Cloud Run公式ドキュメント

Knativeについて

KnativeはKubernetes上に構築された抽象化レイヤーです。

主な機能としてKnative ServingとKnative Eventingがあります。

• Serving
  • サーバーレスなコンテナ実行環境で、リクエストがないときは自動的にスケールダウンしてゼロになり、リクエストが来たら自動的にスケールアップします。
• Eventing
  • イベント駆動アーキテクチャを実現する仕組みで、Pub/Subのようなメッセージングを簡単に実装できます。

新規開発だとほとんどないと思いますが、Knativeを自分でGKEクラスタにインストールすればGKE上でCloud Run的な体験もできるとは思います。

実は、Cloud RunはこのKnativeをベースにしたマネージドサービスです。
つまりCloud Runを使うということは、KnativeをGoogle Cloudが完全に管理してくれている環境を使うということともいえますね。

出典: Knative公式ドキュメント

Kubernetesを選ぶべきケース

マイクロサービスアーキテクチャで複数のコンポーネントが連携するようなシステムや、WebサーバーとWorkerプロセスとキャッシュサーバーを同期させながら動くような構成では、Kubernetesの柔軟性が活きてきます。

その他にも例えばWebSocketで長時間接続を保持するようなサービスは、Kubernetesで安定稼働させるのが適しています。

データベースやセッション管理のように状態を保持する必要があるアプリケーションも、StatefulSetを使えば対応できます。（GKEを使う場合はクラウドネイティブに寄せることが多いとは思います。）

GitOpsやPlatform Engineering前提の運用を考えている場合はKubernetesは相性が良いと思います。

インフラやアプリケーション要件について細かい制御が必要なとき、Kubernetesは強いです。

Cloud Runを選ぶべきケース

一方、Cloud Runはコンテナを利用したアプリケーションを動かすためのマネージドサービスです。

HTTP APIやEvent駆動のアプリケーションは、Cloud Runと相性が良く、特にRESTful APIを提供するバックエンドやPub/SubやCloud Storageのイベントをトリガーに動作させたいアプリケーションに向いています。

利用しないときは稼働させるインスタンスの数を減らすためコスト効率が良いサービスとなっています。
この都合でセッションや内部に情報を持たないステートレスなアプリケーションやリクエストごとに独立して処理できるようなワークロードに最適です。

Cloud Runのタイムアウトは最大60分になっていますが、大抵のWebサービスであればそこまで意識する必要はないと思います。それ以上かかるような処理は別サービスにオフロードしたり、キュー管理するべきですしね。

Cloud Runはコンテナアプリを動かしたいが、インフラ要件について細かく制御したり運用したくない場合の最適解です。

GKEとの比較

項目	Cloud Run	GKE Autopilot	GKE Standard
運用負荷	ほぼゼロ	低（ノード管理不要）	高（全て自分で管理）
制御の自由度	低い	中程度	高い
ノード管理	不要（意識しない）	不要（Google Cloudが管理）	必要（自分で管理）
スケーリング	自動（0〜N、リクエスト駆動）	自動（Pod/Node）	手動または自動設定が必要
タイムアウト	最大60分	制限なし	制限なし
ネットワーク制御	限定的	Kubernetes標準機能	Kubernetes全機能
ステート管理	基本不可（外部ストレージ利用）	StatefulSet利用可	StatefulSet利用可
コスト	従量課金（リクエスト数・実行時間）	Pod単位の課金	Node + Pod課金

Cloud Runは、コンテナイメージをデプロイするだけすみますし、スケーリングもHTTPS設定も全て自動で行われます。
ただしその分Cloud Runには制約も多く、リクエストのタイムアウトは最大60分ですし、Kubernetesのような細かいネットワーク制御やStatefulな処理は基本的にできません。

どちらが優れているという話ではなく、システムの要件と運用体制に応じて使い分けるべきです。

Kubernetesを使わない判断

このシリーズではKubernetesの基礎から全ての機能、運用まで触れてくる中でコンテナ運用をするための有力な選択肢の1つであることが伝わったかなと思っています。

Kubernetesでの開発はいくつかのハードルがあると考えます。

• 初期導入と学習コスト
• 運用コスト
• 引き継ぎと属人化
• 開発体験

日頃からKubernetesでの開発を行なっている組織ならともかく、請負や新規事業開発などで使用するとなると上記が大きな障害になってきます。
抽象的な概念が多いため学習コストがかなりかかりますし、開発・運用するとなったときに体制維持が課題になります。

正直これが多数の企業で踏み込みきれない要因なのかなと思っています。

Google Cloudの同じコンテナサービスでもCloud Runはお手軽に使えますし、少し規模の大きいマイクロサービスアーキテクチャも組もうと思えば全然作れます。

Cloud Runを使うからと言ってGKEと比べて信頼性が劣るということもないかな思います。

実際の判断フロー

実際にどう判断すればいいかざっくりと整理してみました。もちろんまだまだ確認すべき要件はありますので一例です。

1. HTTPリクエストで完結するか？

   • No（TCP/UDP通信、常駐プロセスが必要） → GKE Autopilot をまず検討
   • Yes → 次へ

2. GKE Standard 必須要件があるか？

   • 以下に当てはまる場合
     • 常時大量のアクセスがあり、リソースを詰め込んでコストを最適化したい
     • 特定のGPU（A100等）やカーネルパラメータ（sysctl）の変更が必要
     • ノード単位でのエージェント導入（DaemonSet）が必須
   • Yes → GKE Standard へ
   • No → 次へ

3. 複雑なネットワーク制御が必要か？

   • Pod間通信、固定IPの複雑なルーティング、特定のVPC構成が必要な場合
   • Yes → GKE Autopilot へ
   • No → 次へ

4. Kubernetes専任の運用チームがいるか？

   • Yes（自由度と拡張性を確保したい） → GKE Autopilot
   • No（アプリ開発者がインフラも兼任する） → Cloud Run

多くのWebアプリケーション開発（API/Web）においては、特殊要件がない限りCloud Run が最もコストパフォーマンスと開発効率に優れた選択肢となると思います。

シリーズを通して

Qiitaのアドカレを利用して25日間にわたって、Kubernetesを基礎から実践まで学んできました。

「Kubernetesとは何か」から始まり、Pod、Deployment、Serviceといった基本リソース、GKEでの実践、GitOps、Workload Identity、そしてSRE視点での責任分界と信頼性設計まで扱ってきました。

このシリーズを通して、最終的に伝えたかったのは次の一点です。

「技術は使うために学ぶが、使わない判断をするためにも学ぶ」

Google CloudにはCompute Engineをはじめ様々なコンピューティングサービスがありますが、技術選定の幅を広げるという意味でもKubernetes（特にGKE）は学習する価値があります。

技術選定のゴールは、技術を使うことではなく「ビジネス価値を届ける」ことにあります。そのために最適な技術を選ぶのがエンジニアの仕事です。

私もシリーズを通してKubernetesを学んだからこそ、とりあえずCloud Runでつくるといった一辺倒な考えじゃなくて「このプロジェクトにはKubernetesが適切だ」と言った判断をできるようにしていきたいと思います。

このシリーズが、皆さんのKubernetes学習の一助になれば幸いです。