なぜ Platform Engineering の土台に Kubernetes を選ぶのか

Transcript

1. なぜ Platform Engineering の 土台に Kubernetes を選ぶのか k8s祭り / 2026-06-16 3-shake / Reito Koike (Ray) Copyright © 3-shake, Inc. All Rights Reserved. 1
2. 自己紹介 Reito Koike (Ray / @r4ynode) 株式会社スリーシェイク / SRE 普段は Kubernetes 上で Platform Engineering を実践 今年の目標は腹筋を割ること 最近は趣味で StackChanを触り始めた Copyright © 3-shake, Inc. All Rights Reserved. 2
3. 今日の話 実務でも、イベントでも、本でも、PE はたいてい Kubernetes 前提だった。 なぜ Platform Engineering の土台に Kubernetes を選ぶのか でも私は、これを自分の言葉ではうまく説明できなかった。 今日は、土台に何を求め、それに Kubernetes がどう応えるかを解いていく。 Copyright © 3-shake, Inc. All Rights Reserved. 3
4. Kubernetes ってなんだっけ? よく「コンテナオーケストレーター」と呼ばれ、自己修復やスケーリングで有名。公式の定義はこう。 宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを 管理するための、ポータブルで拡張性のあるオープンソースのプラットフォーム。 出典: Kubernetes ドキュメント — コンセプト > 概要 中核の仕組みは1つ。あるべき状態 を API に書くと、コントローラが現実をそこへ 保ち続ける。 あるべき状態 YAML で宣⾔ 書く Kubernetes API reconcile 実際の状態 コンテナ・設定 Controller がずれを検知し、あるべき状態へ戻し続ける 書けば、保たれ続ける Copyright © 3-shake, Inc. All Rights Reserved. 4
5. PE の定義 CNCF Platforms Whitepaper は、次のように定義する。 Platform 製品やサービスの開発・デプロイ・運用・デリバリーを支援する、 能力・ドキュメント・ツールの集合体。 Platform Engineering その設計・構築・運用・進化のこと。 組織が内部のどこに・どう投資するかを学ぶ、継続的なプロセス。 出典: CNCF Platforms Whitepaper v1.0 — Glossary 要するに、社内開発者を顧客に、プラットフォームを一つの プロダクト として作り続ける営み。 なお、SaaS や PaaS のように、購入で済むならそれも選択肢。今日は内製する場合の話。 Copyright © 3-shake, Inc. All Rights Reserved. 5
6. Kubernetes is a platform for building platforms. Kelsey Hightower Kubernetes は、プラットフォームを作るためのプラットフォームである。 Copyright © 3-shake, Inc. All Rights Reserved.
7. Kubernetes を選ぶ理由は機能だけか? 機能の層 自己修復も、スケーリングも、コンテナを うまく動かす ための機能。 いまやどの土台も持っていて、ここで差はつかない。 PE の層 PE が土台に立つのは、その上に 開発者へ渡すプラットフォーム を作るため。 土台を使う側ではなく、自分たちのプロダクトに変える側。 本当の問い だから問うべきは、機能の良し悪しではない。土台に、何を求めるか。 Copyright © 3-shake, Inc. All Rights Reserved. 7
8. 土台に求めるもの PE が作るのは、開発者に渡すプラットフォーム。 これを作って 提供し続ける ために、土台へ求める性質が次の 2 つ。 標準化: どれも一貫した仕組みで扱える 拡張性: 欲しい抽象を、土台に組み込める 標準化 機能 A 機能 B 機能 C 扱う仕組みは、ひとつ 拡張性 ⾃分の抽象 組み込み 組み込み ⼟台 ⾜りない抽象は、⾃分で⾜す Copyright © 3-shake, Inc. All Rights Reserved. 8
9. Kubernetes ができること Kubernetes は、全体がひとつの宣言的 API。土台に求めた 標準化と拡張性 に、こう応える。 標準化: どのリソースも、一貫した仕組みで扱える（ kubectl / RBAC / admission / status ） 拡張性: CRD で、自分の抽象も同じリソースとして足せる Kubernetes API 組み込み ⾃作（CRD） Pod Deployment WebService Controller reconcile 宣⾔を監視し、あるべき状態に保つ kubectl RBAC admission status 組み込みにも、⾃作にも、⼀貫した扱い Copyright © 3-shake, Inc. All Rights Reserved. 9
10. PE に必要な能力は、ほぼ CRD で提供されている Graduated: 35, Incubating: 37, Sandbox: 152 = 224（2026/06/13時点） Capability (CNCF Whitepaper) 代表 OSS (CRD ベース) APIs for provisioning Kubernetes / Crossplane / KubeVela Delivery automation Argo CD / Flux Application observability Prometheus Operator Identity & secrets cert-manager / ESO Security Gatekeeper / Kyverno Infrastructure services Istio / Cilium どれも一貫して揃うから、組み合わせても状態や権限が分断しにくい。 出典: CNCF Platforms Whitepaper v1.0 — Capabilities of platforms Copyright © 3-shake, Inc. All Rights Reserved. 10
11. 結論: 土台に Kubernetes を選ぶ理由 土台そのものが、標準化され、拡張できる宣言的な API。 標準化 : どの能力も、一貫した扱いで揃う（kubectl / RBAC / admission / status） 拡張性 : 自分の抽象を、API のオブジェクトにできる（CRD） 他に考えられる利点 200を超えるOSSで、エコシステムが厚い 特定のベンダーに縛られず、移植性も残る Copyright © 3-shake, Inc. All Rights Reserved. 11
12. ECS でも、やれないか? ECS はコンテナを動かすには十分。自己修復も Fargate も AWS 統合もある。 では、差はどこにあるでしょう? 観点 ECS Kubernetes API（基盤） AWS API Kubernetes API 標準化（一貫した扱い） サービスごとにバラバラ どの能力も一貫して扱える 拡張性（自分の抽象） 土台の外側に作る（IaC） 土台に組み込む（CRD） 移植性 AWS 専用 どのクラウド / オンプレでも 運用コスト 軽い・AWS 任せ 重い（運用 / 学習 / チーム） ECS は、できあいのプラットフォームにアプリを載せる。 Kubernetes は、プラットフォームそのものを 拡張できる。 Copyright © 3-shake, Inc. All Rights Reserved. 12
13. K8s は重い。でもそれは、負荷を移し替える構造の裏返し 重いのは事実 (運用 / 学習 / Platform チームという固定費) 認知負荷は消えないが、多数のアプリチームから 1 つの Platform チームへ 移し替えられる 割に合うのは規模が 閾値を超えたとき。超えないなら、できあいの土台 K8s アプリチーム K8s アプリチーム K8s アプリチーム 各チームが K8s を抱える 移し替え アプリチーム アプリチーム アプリチーム golden path Platform チーム K8s 複雑さを引き受ける 1 つの Platform チームが引き受ける Copyright © 3-shake, Inc. All Rights Reserved. 13
14. Kubernetes is a platform for building platforms. Kelsey Hightower 土台に求めた 標準化と拡張性 を、Kubernetes は最初から備えている コンテナを動かす場所ではなく、その上にプラットフォームを 作る 場所 Copyright © 3-shake, Inc. All Rights Reserved.