--- title: Pets on Kubernetes ― RWOボリュームで「飼う」ステートフルアプリ設計の現実解 tags: #events #platform-engineering #kubernetes #azure #oci author: [Takeshi Yaegashi](https://docswell.com/user/yaegashi) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/5EGL1344JL.jpg?width=480 description: 2026/05/14(木) クラウドネイティブ会議 https://kaigi.cloudnativedays.jp/sessions/3030 published: May 14, 26 canonical: https://docswell.com/s/yaegashi/K6N72L-cnk2026 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/5EGL1344JL.jpg) クラウドネイティブ会議 Pets on Kubernetes ― RWOボリュームで「飼う」ステートフルアプリ設計の現実解 株式会社バンダイナムコスタジオ 八重樫 剛史 Takeshi Yaegashi 2026/05/14 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/4JQYD5GR7P.jpg) 自己紹介 • 名前: 八重樫 剛史 Takeshi Yaegashi • 組織: 株式会社バンダイナムコスタジオ (BNS) • 部署: テックスタジオ 第２グループ 共通基盤開発部 インフラテック課 • 肩書: テクニカルディレクター • 社内開発者向けのクラウドサービス導入推進 プラットフォームエンジニアリングのプロジェクトに従事 • Microsoft MVP for Microsoft Azure (2023-2025) https://mvp.microsoft.com/ja-jp/PublicProfile/5005134 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/K74WZ95QE1.jpg) アジェンダ • 出発点: Linux VM + Docker Compose によるサービス運用の課題 • Kompox の紹介: compose.yml を K8s に持ち込むオーケストレーションツール • Pets on Kubernetes: RWO Disk を境界にした設計パターンと可用性目標 • クラウドの現実: AKS・OKE・Disk Attach Limit の比較と Provider Driver • 展望: Pets 向け PaaS への道筋 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/LJ1YRKWLEG.jpg) 出発点: Linux 仮想マシン + Docker Compose によるサービス運用 • クラウドの多数の Linux 仮想マシン上で Docker Compose で記述した様々なサービスが稼働 • フロントを Traefik リバースプロキシとしてバックエンドのサービスコンテナに接続 • 非常に安定して動作しているが、仮想マシンのメンテナンスがつらいので K8s などでクラウドネイティブ化したい 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/GJWG1D6Q72.jpg) 仮想マシンの運用のつらさの分析と解決策 • 仮想マシンのメンテナンス • OS更新・再起動・脆弱性対応 • SSHログインによる設定変更・ログ確認・手動作業 • アプリとインフラの運用 • アプリの作成・更新・停止・削除のライフサイクル管理 • アプリの負荷に応じた仮想マシンの追加・削除、配置変更、Traefik設定、証明書管理 • ステートフルデータの運用 • ディスク、バックアップ、スナップショット、復元 • 仮想マシン障害時の復旧手順がサービスごとに異なる • 解決策 = Kubernetes + α • コンテナ実行を Kubernetes に寄せ、共通のコントロールプレーン API で管理する • ただし Compose の開発者体験と、Kubernetes がカバーしないクラウドリソース運用を補う +α が必要 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/4EZLPGY373.jpg) Kompox の紹介 https://github.com/kompox/kompox • Kubernetes をターゲットにした Docker Compose 準拠のオーケストレーションツール • ひとつの compose.yml がローカルでもクラウドの Kubernetes でもシームレスに動く • マネージド Kubernetes・ディスク・スナップショットのライフサイクル管理 • マルチクラウド対応 (予定): AKS, OKE, EKS, GKE, K3s • 現在は v1 (CLI) の POC 段階 • Kompox CLI (kompoxops) がクラウドと K8s の API を直接操作する • KOM (Kompox Ops Manifest) で Workspace / Provider / Cluster / App を YAML 定義 • v2 (PaaS) では責務を CRD・Operator に委譲し、Kubernetes ネイティブな Pets 向け PaaS に進化する予定 • 先行プロジェクト Kompose [1] をリスペクト • compose-go[2] を活用した Docker Compose → Kubernetes Manifest 変換ツール • Kompose は変換だけのツールだが、Kompox はクラウド各社の Kubernetes クラスタや ブロックデバイスボリュームなどのクラウドネイティブリソースの運用にも対応する • 開発の経緯は Kompox Stories [3] で紹介しています [1] https://kompose.io [2] https://github.com/compose-spec/compose-go [3] https://docs.kompox.dev/edge/ja/stories/ 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/Y76WMYDZ7V.jpg) Kompox: 基本構造 • Docker Compose: compose.yml → ローカル環境で開発・テスト • Kompox CLI (kompoxops): compose.yml → Kubernetes Manifest に変換してクラスタにデプロイ kompoxapp.yml → Disks/Snapshots などのクラウドネイティブリソースをデプロイ 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/G75MZG3974.jpg) Kompox: compose.yml と docker compose の利用例 • 開発者は compose.yml を書き docker compose を使ってローカル環境で Gitea [1] を動かす --services: gitea: volumes: image: docker.gitea.com/gitea:1.26.1 environment: アプリの永続化データ - USER_UID=1000 GitリポジトリやDBの場所を指定 - USER_GID=1000 env_file: - compose-gitea.env ports: volumes: - ./data/gitea:/data アプリの公開ポート番号を指定 ports: - "3000:3000" postgres: image: postgres:17 env_file: - compose-postgres.env volumes: - ./data/postgres:/var/lib/postgresql/data $ docker compose up -d [+] Running 3/3 ✔ Network aks-e2e-gitea_default ✔ Container aks-e2e-gitea-postgres-1 ✔ Container aks-e2e-gitea-gitea-1 Created Started Started 0.1s 0.3s 0.3d $ xdg-open http://127.0.0.1:3000 [1] https://about.gitea.com 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/9J29RYZ5ER.jpg) Kompox: kompoxapp.yml と Kompox CLI (kompoxops) の利用例 • 開発者は kompoxapp.yml を書いて ingress, deployment, volumes などのクラウド仕様を指定する --apiVersion: ops.kompox.dev/v1alpha1 kind: App metadata: name: gitea annotations: ops.kompox.dev/id: /ws/aks-e2e-gitea-20260513-184627/prv/aks1/cls/cluster1/app/gitea spec: compose: file:compose.yml ingress: ingress: certResolver: staging アプリの公開DNS名と rules: 接続先のPodポート番号を指定 - name: main port: 3000 hosts: [gitea.custom.exp.kompox.dev] deployment: deployment: zone: "1" アプリを配置するAZを指定 volumes: - name: default size: 10Gi volumes: options: 永続化データ保存リソースを指定 sku: PremiumV2_LRS "." の bind mount で参照可能 $ kompoxops app deploy --update-dns --bootstrap-disks 2026/05/13 22:53:10 INFO CMD runId=0tezzkm6fipl args="[kompoxops app deploy --update-dns --bootstrap-disks]" 2026/05/13 22:53:10 INFO CMD:app.deploy/S runId=0tezzkm6fipl resourceId=/ws/aks-e2e-gitea-20260513-184627/prv/aks1/cls/cluster1/app/gitea 2026/05/13 22:53:10 INFO bootstrap disks before deploy runId=0tezzkm6fipl resourceId=/ws/aks-e2e-gitea-20260513-184627/prv/aks1/cls/cluster1/ ... $ xdg-open https://gitea.custom.exp.kompox.dev 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/DEY4DGR6JM.jpg) Kompox: KOM (Kompox Ops Manifest) によるインフラ定義例 • インフラ管理者は KOM で Kubernetes クラスタを定義して事前にデプロイしておく • 将来的に Kompox PaaS に発展することを見越して Kubernetes CRD として扱えるように KOM を定めている • kind: Workspace (名前空間) / Provider (クラウド・リージョン) / Cluster (クラスタ・イングレス) / App (アプリ) --apiVersion: ops.kompox.dev/v1alpha1 kind: Workspace metadata: name: aks-e2e-gitea-20260513-184627 annotations: ops.kompox.dev/id: /ws/aks-e2e-gitea-20260513-184627 spec: {} --apiVersion: ops.kompox.dev/v1alpha1 kind: Provider metadata: name: aks1 annotations: ops.kompox.dev/id: /ws/aks-e2e-gitea-20260513-184627/prv/aks1 spec: driver: aks settings: AZURE_AUTH_METHOD: azure_cli AZURE_SUBSCRIPTION_ID: 9473abf6-f25e-420e-b3f2-128c1c7b46f2 AZURE_LOCATION: eastus $ kompoxops cluster provision $ kompoxops cluster install [1] https://docs.kompox.dev/edge/ja/examples/ --apiVersion: ops.kompox.dev/v1alpha1 kind: Cluster metadata: name: cluster1 annotations: ops.kompox.dev/id: /ws/aks-e2e-gitea-20260513-184627/prv/aks1/cls/cluster1 spec: existing: false ingress: certEmail: yaegashi@live.jp certResolver: staging domain: cluster1.aks1.exp.kompox.dev certificates: - name: l0wdevtls-cluster source: https://l0wdevtls-jpe-prd1.vault.azure.net/secrets/cluster1-aks1-exp-kompox-dev - name: l0wdevtls-custom source: https://l0wdevtls-jpe-prd1.vault.azure.net/secrets/custom-exp-kompox-dev settings: AZURE_AKS_SYSTEM_VM_SIZE: Standard_D2ds_v4 AZURE_AKS_SYSTEM_VM_DISK_TYPE: Ephemeral AZURE_AKS_SYSTEM_VM_DISK_SIZE_GB: 64 AZURE_AKS_SYSTEM_VM_PRIORITY: Regular AZURE_AKS_SYSTEM_VM_ZONES: AZURE_AKS_USER_VM_SIZE: Standard_D2ds_v4 AZURE_AKS_USER_VM_DISK_TYPE: Ephemeral AZURE_AKS_USER_VM_DISK_SIZE_GB: 64 AZURE_AKS_USER_VM_PRIORITY: Regular AZURE_AKS_USER_VM_ZONES: 1 AZURE_AKS_DNS_ZONE_RESOURCE_IDS: /subscriptions/73a004ad-64a0-4fd7-9d40-ed50b937582e/resour AZURE_AKS_CONTAINER_REGISTRY_RESOURCE_IDS: /subscriptions/73a004ad-64a0-4fd7-9d40-ed50b9375 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/VJNY6GX178.jpg) Pets vs Cattle — Kubernetes の理想と現実 • “Pets vs Cattle” は、クラウド時代のインフラ運用を説明するために広まった比喩 [1] • Kubernetes のセオリーは、アプリを Cattle として扱うこと • 壊れたら直すのではなく、捨てて作り直す • 特定の個体に依存しないことで、自動化・標準化・スケールアウトが可能になる • しかし現実には、Cattle にできない Pets アプリが残る • 名前があり、状態があり、失うと困るデータが特定のホストに強く結びついている • 冒頭の Linux VM + Docker Compose 運用は、ホストが Pets になっている例 • 本日のテーマ: Cattle にできない Pets アプリを Kubernetes でどう安全に引き受けるか [1] https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/YE9PLW8YJ3.jpg) ステートフル vs ステートレス — 問題は「状態を外に逃がせるか」 • ワークロード (Kubernetes用語) によるアプリの分類 • Cattle アプリ = ステートレスワークロードのみで構成される • Pets アプリ = ステートフルワークロードが含まれる • ステートフルアプリ ≠ ステートフルワークロード • アプリのステートを Pod のライフサイクルから外部に切り離せるならステートレスワークロードだけにできる • ステートフルアプリからステートフルワークロードを外部に逃がせるか？ • データーベース → マネージド DB に逃がせる • 低性能でよいファイルシステム → オブジェクトストレージや RWX ボリュームに逃がせる • 高性能なローカルファイルシステムが必要な場合 → RWO ボリュームが残り、ステートを外部に逃がせない • 次の問題: RWO ボリュームは、どこで扱えるのか？ 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/GE8DXN8KED.jpg) RWO vs RWX — Kubernetes で引き受ける最後のステート • RWX (ReadWriteMany): 外部化しやすいファイル共有 (NAS) • 複数 Node から同時接続でき Pod のライフサイクルから切り離せる • 便利だが、性能・用途に制約がある • RWO (ReadWriteOnce): 外部化しにくいブロックデバイス • 単一 Node からのみ接続でき Pod のライフサイクルと密結合しやすい • 高性能だが、Node / AZ / Pod 配置の制約を受ける • RWO が不要な Cattle アプリなら、簡便なコンテナ PaaS で運用しやすい • 簡便 PaaS の例: Azure Container Apps、 Amazon ECS/Fargate、Google Cloud Run • ただし多くの簡便 PaaS は RWO ブロックデバイスをアプリのライフサイクルと一体で管理する用途には制約がある • RWO が残る Pets アプリは、Kubernetes で引き受ける設計が現実解になりやすい • Pets アプリの例: Git / SVN / P4 リポジトリ、CI/CD、自動ビルド、開発者作業環境・レガシーアプリ • RWO は Pets アプリをクラウドネイティブ化する上での最大の難所といえる • Kompox はこの難所をアプリのライフサイクルごと抱え込むツール 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/LELM8PRP7R.jpg) Pets on Kubernetes — RWO をアプリ境界として引き受ける • 1 App = 1 RWO Disk • RWO Disk をアプリの本体とみなす • Backup / Restore / Migration を同じ境界で管理する • Pod はシングルレプリカ前提となる • RWO の難所は Kompox が抱え込む • Node / AZ / Disk Attach の制約を運用対象にする • クラウド間の差異を Kompox Provider Driver で吸収する • Compose の開発者体験を維持する • compose.yml を開発者向け API として扱う • ローカルでは compose.yml を docker compose でデプロイ • クラウドでは kompoxapp.yml を加えて Kompox CLI で Kubernetes にデプロイ 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/4JMY64R2JW.jpg) Pets on Kubernetes — 「Kubernetes + α」の役割分担 • Kubernetes-managed: Kubernetes 自身が担う領域（Pod のスケジューリングやサービスルーティングなど） • Kompox-managed: Kompox が担う領域（RWO Disk・Snapshot のライフサイクル管理） 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/PJR9PWR579.jpg) Pets on Kubernetes — Kubernetes の能力をあえて使わない • Kubernetes はワークロードを「Cattle」として扱うための能力を備えている • Kompox はそれを使わず、ワークロードを「Pets」として扱うために能力を活用する → Kubernetes をプログラマブルな VM マネージャーとして使う Kubernetes の代表的な能力 Kompox の方針 宣言的な構成管理 使う ヘルスチェックと自動再起動 使う API による運用自動化 使う 水平スケーリング (HPA/VPA) 使わない → 各ワークロードはシングルレプリカで固定 マルチレプリカによる高可用性 使わない → フェイルオーバー用のスタンバイレプリカも置かない ローリングアップデート 使えない → シングルレプリカではゼロダウンタイムデプロイは原理的に不可能 ステートレス設計への誘導 従わない → 状態を外部サービスに委譲せずRWO Disk内でローカルに保持する 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/PEXQ3PRXJX.jpg) Pets on Kubernetes — シングルレプリカ前提の可用性目標設定 • シングルレプリカで、アプリのステートを外部に逃さず永続データを RWO Disk に閉じ込める • RWO Disk・Snapshot を中心に可用性指標の目標値を設定できる 指標 (条件) 目標値 説明 RPO (Node障害) 0 RWO Disk はクラウド側で保全されるため Node が停止してもデータ消失はない ファイルシステムや DB は再起動後に安全なチェックポイントに復元可能 RPO (AZ障害) 直近 Snapshot AZ 障害で別 AZ へマイグレーションする場合、 復旧地点は RWO Disk から最後に取得したクロス AZ Snapshotに依存する RTO (計画メンテナンス) 数十秒〜数分 Node ドレイン・RWO Disk 再アタッチ・Pod 再起動を含む計画的なサービス停止 RTO (Node障害→自動復旧) 10分〜20分 障害検出 + RWO Disk 強制デタッチ・再アタッチ + Pod 再起動 Kubernetes のデフォルト挙動で概ね自動復旧する RTO (AZ障害) 30分〜数時間 直近 Snapshot からの RWO Disk 復元と別 AZ へのマイグレーションが必要 RWO Disk のサイズと Kompox 自動化機能の成熟度に依存 SLO 99.9% 単一 VM + Premium SSD の Azure SLA と同等の水準 年間ダウンタイム予算 8.75 時間で、年数回の計画外障害を許容する SLA 99.0% 年間ダウンタイム予算 87.5 時間は社内向けサービスとして許容される水準 17 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/3EK9YDR9ED.jpg) AKS (Azure) で RWO Disk を「飼う」現実 — 可用性とコストのトレードオフ • Azure では AZ 障害時の RPO は Azure Disk の冗長性 (LRS/ZRS) で変わる • Azure Disk: Premium SSD と Premium SSD v2 の比較 • Premium SSD v2 は容量・IOPS・スループットを個別に設定でき、必要な性能だけを調達できる • Premium SSD は Premium SSD v2 ほどの柔軟性はないが ZRS Disk として扱うことができる • AKS での RWO Disk SKU 選択は可用性とコストのトレードオフ • ZRS + Premium SSD → 最も高可用だがコスト大 • LRS + Premium SSD v2 → 最もコストパフォーマンスに優れるが AZ 障害 RPO は Snapshot に依存 比較項目 LRS (ローカル冗長) ZRS (ゾーン冗長) 利用可能 AZ 同一 AZ のノードのみ利用可能 すべての AZ のノードから利用可能 AZ 障害 RPO 直近 Snapshot 0 AZ 障害 RTO Snapshot 復元 ＋ AZマイグレーション (30 分〜数時間) Disk 再アタッチのみ (10〜20 分) コスト 安い 1.5 〜 2 倍 書き込みレイテンシ 低い 高い 18 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/L73W9R8975.jpg) OKE (OCI) で見える別解 — ネットワークコストの構造的な優位性 • Kompox の OKE ドライバはまだ実装中だが、すでに見えているクラウド差異がある • OCI はネットワーク関連コストが構造的に低く、Pets アプリではこの差が効いてくる • Kompox は Traefik を標準デプロイし TLS/証明書管理をクラスタ内で担うため、前段は L4 LB (Network LB) で足りる • Gitea のようにサイトごとの専用 SSH ポート(TCP) が必要なサービスでは NLB が無料であることが直接的なコスト削減になる • 継続的な下り配信 (CI 成果物の配布、リポジトリの clone/fetch 等) を行うサービスでは、エグレス 10 TB 無料枠が大きい • ストレージの特性も異なる • OCI Block Volume は AD (Availability Domain) 内で冗長化されるが、Azure の ZRS に相当するクロス AD 冗長オプションはない → つまり OKE では AZ 障害 RPO は常に直近 Snapshot まで巻き戻る前提になる • 一方、性能チューニング (VPU/GB による IOPS 調整) は Azure の Premium SSD v2 と同様に柔軟 項目 Azure OCI パブリック IP 有料 (Static IP: 〜$3.65/月) 無料 (Ephemeral or Reserved IP) L4 ロードバランサ 有料 (LB Standard: 〜$18/月 + rules) 無料 (Network LB) L7 ロードバランサ 有料 (App Gateway) 有料 (Flexible LB: base + bandwidth) データ帯域 （エグレス） 100 GB/月 無料、以降 〜$0.087/GB 10 TB/月 無料、以降 〜$0.0085/GB 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/87DKGYM8JG.jpg) 1 App = 1 RWO Disk — 収容密度を決めるのは Disk Attach Limit • 1 App = 1 RWO Disk の帰結 • 1 つのアプリが 1 台の Disk を占有するため、 1 Node にホストできるアプリ数は CPU / Memory ではなく Disk Attach Limit で上限が決まるケースが多い • つまり収容密度は「Node の vCPU 数」ではなく「Node に接続できる Disk の台数」に支配される • AKS Dsv7/Dasv7 世代 (Azure Boost) について • 従来と比較して Disk Attach Limit が大幅に増加し、小さい VM サイズでも多くのアプリをホスト可能になった • ただし使用可能なリージョン・キャパシティは限られており、K8s の異種 Node Pools 間の Pod スケジューリングが役に立つ vCPU AKS Dsv5/Dasv5 AKS Dsv7/Dasv7 EKS [1] GKE [2] OKE 2 4 10 32 8 32 4 8 12 32 16 32 8 16 26 32 32 32 16 32 48 32 64 32 32 32 64 32 128 32 [1] EKS: Dedicated limit 世代(m7i/c7i/m8g 等)の値。medium〜12xlarge は一律 32。旧 Nitro(t3/m5/c5 等)は NIC・Instance Storeと共有のため実効25 [2] GKE: Gen4(C4 等)の値。Gen1〜3(N2/C3 等)は PDCSI ドライバが一律 127 を報告 20 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/VJPK36RWE8.jpg) Kompox Provider Driver — クラウド差異を運用契約として吸収する • クラウドごとに RWO Disk とネットワークの最適解は異なる • Disk の冗長性モデル、スナップショットの扱い、Disk Attach Limit の決まり方 • L4/L7 ロードバランサ・パブリック IP アドレス・エグレス課金の構造 • この差異をアプリ開発者に意識させるのは現実的ではない • アプリは同じでも、クラウドごとに設計判断が変わってしまう • compose.yml という共通 API を守れなくなる • Kompox は Provider Driver でこの差異を引き受ける • 開発者は同じ compose.yml / kompoxapp.yml を使い続けられる • プラットフォーム側が「そのクラウドで成立する実装」 を選択する • Kompox が抽象化するのは Kubernetes ではない • Kubernetes の API を隠すのではなくクラウドごとの制約を踏まえた「運用契約」を抽象化する • その結果として、同じ Pets アプリをどのクラウドでも、同じ手順で、同じ前提条件で 運用できる 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/2EVV43R9EQ.jpg) Platform Engineering — compose.yml を開発者向け API とする • Kompox が開発者に求める定義は compose.yml だけ • ローカルでもクラウドでも、同じ compose.yml を起点にアプリを定義する • 開発者が意識するのは、どのコンテナが、どのデータを持ち、どのポートで動くか、だけでよい • クラウド固有の要素は kompoxapp.yml が引き受ける • ingress / RWO Disk / 配置 AZ など • アプリは変えずに、実行環境だけを切り替える • インフラ構成と運用責務は KOM で分離する • アプリが共有するクラスタ・リージョン・認証・証明書などは事前定義（ページ10） • アプリ開発者はインフラ構造を知らなくてよい • つまり compose.yml は単なる Compose ファイルではない • Cattle になれない Pets アプリを どこでも・同じ手順で・同じ運用契約で 実行するための Pets 向け PaaS の開発者向け API になり得る 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/57GL13M4EL.jpg) Platform Engineering — Kompox v1 (CLI) から v2 (PaaS) への進化 • 現在の Kompox は v1 (CLI) の POC 段階 • Kubernetes 上で実運用できることを最優先した設計 • Kubernetes CRD・Operator はまだ使っていない • KOM (Kompox Ops Manifest) はすでに存在し Kompox CLI (kompoxops) がすべてを解釈・実行する • KOM は Workspace / Provider / Cluster / App を YAML として定義 • Kompox CLI が KOM を読み取り、クラウドと K8s の API を直接操作し、アプリとインフラのライフサイクルを実行時に統合 • これは “未完成” ではなく、将来を先取りした実装 • KOM は将来そのまま CRD に移行できる粒度で設計している • v1 (CLI) では Kompox CLI がその Operator・Controller の役割を担っている状態 • v2 (PaaS) では 責務を Kubernetes 側へ段階的に委譲し Kubernetes ネイティブな PaaS に進化する • 重要なのは、API 境界と運用モデルはすでに確定していること • compose.yml → 開発者向け API • kompoxapp.yml → クラウド差異の吸収 • KOM → 運用と責務の分離 • この構造は v1 (CLI) でも v2 (PaaS) でも変わらない 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/4EQYD5RRJP.jpg) Kompox ロードマップ — v1 (CLI / POC) → v2 (PaaS) • 現在地: Kompox は v1 (CLI ベースの POC) 段階、実運用を前提に、KOM・Compose API・AKS Driver の基本実装が完了 • 直近: OKE Provider Driver の実装 、マルチクラウド差異吸収モデルの検証 • 中期: AZ 障害時の自動マイグレーション対応、RTO (AZ 障害) 短縮を目指す • 長期: KOM の CRD・Operator 化、マルチテナントを前提とした Pets 向け PaaS への進化 フェーズ 内容 状態 v1 コア CLI kompoxops によるコア機能の実装 ✅ 基本実装完了 v1 KOM Kompox Ops Manifest フォーマットの定義と実装 ✅ 基本実装完了 v1 AKS AKS をリファレンスとする Provider Driver ✅ 基本実装完了 v1 OKE OKE Provider Driver の実装 🔧 次の実装対象 v1 EKS/GKE/K3s 各クラウドの Provider Driver を順次対応 📋 計画中 v1 自動復旧 AZ 障害時の自動マイグレーションによる RTO 短縮 📋 計画中 v2 CRD/Operator Kompox リソースの K8s ネイティブ管理 📋 構想 v2 PaaS RBAC・ビリング・マルチテナント 📋 構想 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/KJ4WZ98Q71.jpg) 今日お伝えしたかったこと（Takeaways） • Cattle にできない Pets アプリでも、Kubernetes で「飼う」選択肢がある • すべてをステートレスにできないアプリは、今後も残り続ける • RWO Disk を前提にした設計を、避けるのではなく引き受ける • RWO Disk をアプリ境界として捉えると、設計と運用が整理できる • 1 App = 1 RWO Disk • Backup / Restore / Migration / 可用性の単位が揃う • RTO > 0 を受け入れたうえで、現実的な SLO を契約できる • Kubernetes の能力を「全部使わない」ことが、現実解になる場合がある • マルチレプリカや水平スケーリングだけが正解ではない • Kubernetes を プログラマブルな VM マネージャー として使う設計もある • この設計を広げる鍵は、API と Platform abstraction にある • compose.yml を開発者向け API とする • クラウド差異と運用責務はプラットフォーム側が引き受ける • Pets アプリを どこでも・同じ手順で・同じ運用契約 で動かせるようにする 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/LE1YRK2L7G.jpg) Thank You!! 26