Kubernetesが本当に必要になるとき

Kubernetesは難しい問題をうまく解決します。多数のコンテナ化されたワークロードをマシンのプールにスケジューリングし、稼働させ続け、周辺のあらゆるものに統一されたAPIを提供することです。そして、コンテナをどこで動かすかという問いに対する既定の答えになりました。Kubernetesが解決する問題を抱えていないシステムにとっても、です。

私たちの立場は、Kubernetesの採用は理由を明示した判断であるべきだ、というものです。少数のステートレスなサービスであれば、マネージドコンテナサービスが、はるかに小さな運用範囲で同じ結果をもたらします。Kubernetesが正しい選択になるのは、ワークロードまたは組織が、Kubernetesにしか提供できないものを必要とするときです。

EKS、GKE、AKSといったマネージドサービスは、コントロールプレーンを運用してくれます。しかし残りの作業がなくなるわけではありません。本番クラスターはコンポーネントの集合体であり、誰かがそれを選定し、設定し、アップグレードし、デバッグしなければなりません。

クラスターの利用料が大きな費目になることはまれです。大きなコストは、プラットフォームを最新に保ち、レイヤーをまたぐ障害を診断するために必要なエンジニアの注意力です。たとえば、ノードのconntrack上限が原因でPodがDNSを解決できない、PodDisruptionBudgetがドレインを妨げてデプロイが止まる、といった障害です。

アプリケーションチームも負担します。requestsとlimits、プローブ、ロールアウト戦略、そしてマニフェストがどのようにして稼働中のPodになるのかを理解する必要があります。liveness probeの設定を誤れば、負荷がかかった健全なサービスが再起動されます。リソースのrequestsがなければ、一つのワークロードが隣のワークロードのリソースを食い尽くします。妥当なデフォルトを提供するプラットフォームチームがいなければ、その知識をすべてのチームが持たなければなりません。

システムが少数のステートレスなHTTPサービスといくつかのバックグラウンドワーカーで構成されているなら、マネージドコンテナプラットフォームで要件を満たせます。Amazon ECS on Fargateは管理すべきノードなしにコンテナを実行し、IAM、ロードバランサー、CloudWatchと直接統合されます。Google Cloud Runは、リクエスト駆動のコンテナをゼロまでスケールインし、再び立ち上げます。Azureでは、Azure Container AppsとApp Serviceが同じ役割を担います。

これらのサービスは、ローリングデプロイ、オートスケーリング、ヘルスチェック、シークレットの注入、プライベートネットワークを提供します。提供されないのは拡張性です。カスタムコントローラーは使えず、スケジューリングの制御は限られ、ネットワークモデルも狭くなります。大半の業務アプリケーションでは、この制限が制約になることはありません。デプロイの単位はコンテナイメージのままなので、後からKubernetesへ移行する場合も、変わるのはデプロイ定義とパイプラインであり、書き直しにはなりません。

次の項目のうち複数が当てはまる場合、Kubernetesを採用する根拠は強くなります。

データベースやブローカーをKubernetes上で動かすことは、StatefulSetと成熟したオペレーターによって可能であり、専門知識を持つチームや可搬性の要件があるチームにとっては妥当な選択です。ただしその場合、バックアップ、フェイルオーバー、ストレージ性能、アップグレードのリスクを、クラスターを運用するのと同じチームが負うことになります。マネージドデータベースやマネージドKafkaサービスで要件を満たせるなら、私たちはそちらを選び、クラスターはステートレスなコンピュートのために使います。

選択は二者択一ではありません。GKE AutopilotとEKS Auto Modeは、Kubernetes APIを保ったままノード管理を不要にします。データプレーンを所有せずにエコシステムを使いたいチームに適しています。コンピュート単位あたりのコストは高くなり、一部の低レベルな設定が制限されますが、たいていは妥当な交換です。

可搬性は、Kubernetesを早期に採用する理由としてよく挙げられます。これは部分的には正しいと言えます。マニフェストには可搬性がありますが、アイデンティティ、ロードバランシング、ストレージクラス、マネージドデータサービスは、どのプラットフォームでもプロバイダー固有です。設定を環境変数に置き、ビジネスロジックからプロバイダーSDKを呼び出していないコンテナ化アプリケーションであれば、判断を先送りできるだけの可搬性を備えています。

私たちはワークロードとチームから出発します。現在のサービス数と2年以内に現実的に見込まれるサービス数、よりシンプルなプラットフォームにはないスケジューリング機能を必要とするサービスの有無、そしてアップグレードと午前3時のインシデントを誰が担うのか、を確認します。最後の問いに説得力のある答えがないなら、技術的な魅力にかかわらず、よりシンプルなプラットフォームを選ぶのが責任ある判断です。

逆の誤りもあります。シンプルなプラットフォームでは手狭になったチームが、その周りに独自のスケジューラー、サービスディスカバリ、デプロイツールを作って対処すれば、Kubernetesを粗悪な形で再発明したことになります。回避策が積み重なり始めたら、独自のプラットフォームを保守するより、標準的なプラットフォームを採用するほうが安く済みます。