[{"data":1,"prerenderedAt":354},["ShallowReactive",2],{"blog-ja-kubernetes-multi-tenancy-capsule-namespace-isolation":3,"blog-related-ja-kubernetes-multi-tenancy-capsule-namespace-isolation":304,"blog-ja-kubernetes-multi-tenancy-capsule-namespace-isolation-alt":292},{"id":4,"title":5,"author":6,"body":7,"date":286,"description":287,"extension":288,"image":289,"locale":290,"meta":291,"navigation":292,"path":293,"seo":294,"stem":295,"tags":296,"__hash__":303},"blog\u002Fblog\u002Fja\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation.md","「namespaceで区切ったつもり」が事故のもと。KubernetesマルチテナンシーをCapsuleが解決する仕組み","Kubo Team",{"type":8,"value":9,"toc":270},"minimark",[10,15,19,26,37,46,51,59,68,72,87,93,109,126,130,133,139,143,152,156,170,174,182,186,189,195,215,223,242,246,249,252],[11,12,14],"h2",{"id":13},"_1-namespaceは境界ではなく棚でしかない","1. namespaceは「境界」ではなく「棚」でしかない",[16,17,18],"p",{},"Kubernetesのマルチテナンシーを設計するとき、最初に思いつくのは「テナントごとにnamespaceを分ければいい」という発想だろう。実際、多くのチームがこの方法で複数の事業部やクライアントのワークロードを1つのクラスタに同居させている。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"namespace境界の比較図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection01.webp",[16,27,28,29,36],{},"しかし、",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fmulti-tenancy\u002F",[34],"nofollow","Kubernetes公式ドキュメント","は明確にこう釘を刺している。namespace分離モデルは「他の複数のKubernetesリソース、ネットワークプラグイン、およびセキュリティベストプラクティスの厳格な遵守を必要とする」と。つまりnamespaceそのものは、リソース名を分離し、RBACやNetworkPolicyを適用する「スコープ」を提供するだけであり、それらのポリシーを実際にテナントごとに正しく設定し続ける作業は、依然として運用者の手作業に委ねられている。",[16,38,39,40,45],{},"テナント数が5、10と増えていくと、この「手作業での一貫性維持」が破綻し始める。あるnamespaceにはNetworkPolicyを設定し忘れ、別のnamespaceにはResourceQuotaの上限が古い値のまま残っている、といったポリシードリフトが典型的に発生する。",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Fwww.sysdig.com\u002Fjp\u002Fblog\u002Fmulti-tenant-isolation-boundaries-kubernetes",[34],"Sysdigのブログ","も、コントロールプレーン\u002FAPI、ホスト、ネットワークという3つの分離境界それぞれで、RBACの最小権限設計やNetworkPolicyの明示的な適用が個別に必要であることを指摘している。",[47,48,50],"h3",{"id":49},"kubernetesマルチテナンシーはスペクトラムである","Kubernetesマルチテナンシーは「スペクトラム」である",[16,52,53,54,58],{},"Kubernetes公式ドキュメントは、マルチテナンシーを「ソフト」と「ハード」の二択ではなく、要件に応じて選べる隔離技術の",[55,56,57],"strong",{},"スペクトラム","として捉えるべきだと説明している。テナント間に一定の信頼関係がある社内の複数チームであればソフトな隔離で十分だが、信頼できない複数顧客を収容するSaaS的な用途では、より強い隔離（ハードマルチテナンシー）が必要になる。この前提を理解しないまま「namespaceを切っただけ」で満足してしまうことが、事故の温床になる。",[16,60,61,62,67],{},"このポリシー管理の手間は、マネージドKubernetesを選ぶ段階から見直せる部分でもある。",[30,63,66],{"href":64,"rel":65},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようにテナント管理を運用の前提として設計された基盤であれば、この後で紹介する仕組みを自前で組み立て直す必要がなくなる。",[11,69,71],{"id":70},"_2-capsuleという答え-tenant-crdで複数namespaceのグループを宣言する","2. Capsuleという答え — Tenant CRDで「複数namespaceのグループ」を宣言する",[16,73,74,75,80,81,86],{},"この課題に対して、CNCF Sandboxプロジェクトとして採択された",[30,76,79],{"href":77,"rel":78},"https:\u002F\u002Fgithub.com\u002Fprojectcapsule\u002Fcapsule",[34],"Capsule","は、明快な解決策を提示している。Capsuleは2022年12月13日にCNCF Sandboxレベルで受け入れられた（",[30,82,85],{"href":83,"rel":84},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fcapsule\u002F",[34],"CNCF Capsuleプロジェクトページ","）、Kubernetesクラスタに「マルチテナントかつポリシーベースの環境」を実装するOSSだ。",[16,88,89],{},[22,90],{"alt":91,"src":92},"Capsule Tenant CRDのアーキテクチャ図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection02.webp",[16,94,95,96,99,100,104,105,108],{},"Capsuleの中核は",[55,97,98],{},"Tenant","というカスタムリソース（CRD）だ。",[30,101,103],{"href":77,"rel":102},[34],"GitHubの公式リポジトリ","によれば、Tenant CRDは複数のnamespaceを「軽量な抽象化」の中に集約する。管理者はテナント単位でNetworkPolicy、Security Policy、ResourceQuota、LimitRange、RBAC設定を定義するだけでよく、それらは",[55,106,107],{},"そのテナントに属するすべてのnamespaceに自動的に継承される","。namespaceを1つ追加するたびにポリシーを再設定する必要がない設計だ。",[16,110,111,112,115,116,119,120,125],{},"さらに重要なのが「セルフサービス委譲」という発想だ。テナントに割り当てられた境界の中であれば、開発チームは",[55,113,114],{},"クラスタ管理者の介入なしに","namespaceの作成やアプリケーションのデプロイを自律的に行える。Capsuleは「upstreamのKubernetesのみを活用する、最小主義的なマイクロサービスベースのエコシステム」として設計されており（",[30,117,85],{"href":83,"rel":118},[34],"）、admission webhookとCRDだけで実現している点が特徴だ。クラスタ管理者はテナントの枠組みだけを設計し、日々のnamespace管理は各チームに委ねられる。これにより、運用負荷とガバナンスの両立が可能になる。",[30,121,124],{"href":122,"rel":123},"https:\u002F\u002Fzesty.co\u002Ffinops-glossary\u002Fcapsule-kubernetes\u002F",[34],"FinOps系メディアZestyの解説","でも、Capsuleは「複数のnamespaceをテナントと呼ばれる軽量な仮想クラスタにグループ化し、効率的で安全なワークロード分離を実現するオペレーター」と位置づけられており、クラスタ管理者権限を渡さずにテナント単位でポリシーを強制できる点が利点として挙げられている。",[11,127,129],{"id":128},"_3-ソフト分離とハード分離-vclusterhncとの違いを整理する","3. 「ソフト分離」と「ハード分離」— vCluster・HNCとの違いを整理する",[16,131,132],{},"Capsule以外にも、Kubernetesのマルチテナンシー課題に取り組むOSSは複数存在する。それぞれ「分離の強さ」と「運用コスト」のトレードオフが異なるため、整理しておきたい。",[16,134,135],{},[22,136],{"alt":137,"src":138},"Capsule・vCluster・HNCの比較図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection03.webp",[47,140,142],{"id":141},"capsule-ソフトマルチテナンシー","Capsule — ソフトマルチテナンシー",[16,144,145,146,151],{},"Capsuleはnamespaceとadmission webhookを軸にした「ソフト」な分離アプローチだ。",[30,147,150],{"href":148,"rel":149},"https:\u002F\u002Fwww.vcluster.com\u002Fblog\u002Fcomparing-multi-tenancy-options-in-kubernetes",[34],"vClusterの公式ブログ比較記事","は、namespace単位の多重テナンシーには「真のテナント分離が欠けており、ClusterRoleやPersistentVolumeといったグローバルに共有されるリソースが残る」という限界があると指摘した上で、Capsuleがこの弱点をポリシーの自動継承によって緩和していると位置づけている。同じAPIサーバー・同じコントロールプレーンを複数テナントで共有するため、リソースオーバーヘッドが小さいことがメリットだ。",[47,153,155],{"id":154},"vcluster-仮想コントロールプレーンによるハード分離","vCluster — 仮想コントロールプレーンによるハード分離",[16,157,158,159,163,164,169],{},"一方",[30,160,162],{"href":148,"rel":161},[34],"vCluster","は、テナントごとに専用の仮想コントロールプレーン（独自のAPIサーバー・controller-manager・scheduler）をホストクラスタの中に立てるアプローチを取る。ワークロードの実体はホストクラスタに同期されるが、テナントは自分専用のKubernetes APIを持つため、CRDやAPIバージョンの違いをテナントごとに許容できる。その代わり、コントロールプレーンを複数走らせる分、リソース消費と運用の複雑性は増す。金融機関や医療機関のようにテナントごとのデータ主権や完全な閉域運用が求められる場合は、",[30,165,168],{"href":166,"rel":167},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise","のようにAir-Gapped環境を前提にした基盤との組み合わせも選択肢になる。",[47,171,173],{"id":172},"hnc-namespaceの階層継承","HNC — namespaceの階層継承",[16,175,176,181],{},[30,177,180],{"href":178,"rel":179},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fhierarchical-namespaces",[34],"Hierarchical Namespace Controller（HNC）","は、namespaceに親子関係を持たせることで、RBACのRoleBindingやResourceQuotaを子namespaceへ自動伝播させる仕組みだ。通常はクラスタレベルの権限が必要なnamespace作成を、チームのnamespace配下に委譲できる点はCapsuleと似ている。ただし、vClusterのブログ比較でも指摘されている通り、ClusterRoleやPersistentVolumeのようなクラスタスコープのリソースは階層構造の外側にあり、依然としてグローバルな存在として残る。HNCはあくまで「namespace同士の構造化・管理ツール」であり、Capsuleのような包括的なテナント境界の強制までは踏み込んでいない。",[11,183,185],{"id":184},"_4-どのアプローチを選ぶべきか-判断基準","4. どのアプローチを選ぶべきか — 判断基準",[16,187,188],{},"3つのアプローチは「分離の強さ」と「運用コスト」という2軸で整理できる。",[16,190,191],{},[22,192],{"alt":193,"src":194},"分離の強さと運用コストの判断フローチャート","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection04.webp",[196,197,198,205,210],"ul",{},[199,200,201,204],"li",{},[55,202,203],{},"HNC",": 運用コストは最も低いが、クラスタスコープのリソースは分離できない。社内の同じ信頼レベルのチーム同士でnamespace管理を委譲したい場合に向く",[199,206,207,209],{},[55,208,79],{},": namespace分離の弱点をポリシー自動継承で補い、コストと分離のバランスが良い。信頼関係のある複数事業部・複数チームでのクラスタ共有に適する",[199,211,212,214],{},[55,213,162],{},": 最も強い分離（仮想コントロールプレーン単位）を提供するが、運用の複雑さとリソースオーバーヘッドが増える。信頼できない複数顧客を収容するSaaS的な用途や、テナントごとに異なるK8sバージョン・CRDが必要な場合に向く",[16,216,217,222],{},[30,218,221],{"href":219,"rel":220},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fbest-practices\u002Fenterprise-multitenancy?hl=ja",[34],"Google CloudのGKEマルチテナンシーのベストプラクティス","でも、テナントごとの専用namespace作成、NetworkPolicyによる通信制御、Admission Controlによるセキュリティ基準の強制、namespace単位のResourceQuota設定という組み合わせが基本形として推奨されている。つまりCapsuleが自動化している内容は、本来GKEのようなマネージドサービス上でも手動で組み立てなければならない構成要素そのものだ。",[16,224,225,226,229,230,235,236,241],{},"自前でこの構成をゼロから設計・運用するのは、決して小さくない工数がかかる。ここに、マネージドKubernetesの基盤機能としてテナント管理を組み込んでおく価値がある。",[30,227,66],{"href":64,"rel":228},[34],"は",[30,231,234],{"href":232,"rel":233},"https:\u002F\u002Fwww.rancher.com\u002F",[34],"Rancher","ベースの管理基盤を標準搭載しており、マルチクラスタ・マルチテナントの状態を可視化しながら運用できる。",[30,237,240],{"href":238,"rel":239},"https:\u002F\u002Fk3s.io\u002F",[34],"K3s","という軽量なKubernetesディストリビューションをベースにしているため、EKS\u002FAKSと比べてコスト効率も高い。テナントごとのポリシー管理を最初から仕組み化したいチームにとって、選択肢の一つになるはずだ。",[11,243,245],{"id":244},"_5-まとめ","5. まとめ",[16,247,248],{},"namespace分離は、Kubernetesマルチテナンシーの出発点ではあっても、終着点ではない。ポリシーをテナント単位でどう一貫して強制するかという設計問題を解決しない限り、テナント数が増えるたびに事故のリスクは積み上がっていく。",[16,250,251],{},"Capsuleは、既存のnamespaceモデルの上にTenant CRDという軽量な抽象化を重ね、NetworkPolicy・ResourceQuota・RBACの自動継承とセルフサービス委譲を実現する現実的な選択肢だ。より強い分離が必要ならvCluster、既存のnamespace構造を階層化したいだけならHNCという選択肢もある。それぞれのトレードオフを理解した上で、自分たちのクラスタに必要な「分離の強さ」を見極めることが、マルチテナント設計の第一歩になる。",[16,253,254,255,259,260,263,264,269],{},"複数の事業部やクライアントで1つのKubernetesクラスタを共有する構想があるなら、こうしたテナント分離の仕組みをゼロから構築するのではなく、マネージド基盤に任せるという選択肢も検討する価値がある。",[30,256,258],{"href":64,"rel":257},[34],"Kubo Cloud","や、より厳格なデータ主権が求められる環境向けの",[30,261,168],{"href":166,"rel":262},[34],"について、",[30,265,268],{"href":266,"rel":267},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から相談してみてほしい。",{"title":271,"searchDepth":272,"depth":272,"links":273},"",2,[274,278,279,284,285],{"id":13,"depth":272,"text":14,"children":275},[276],{"id":49,"depth":277,"text":50},3,{"id":70,"depth":272,"text":71},{"id":128,"depth":272,"text":129,"children":280},[281,282,283],{"id":141,"depth":277,"text":142},{"id":154,"depth":277,"text":155},{"id":172,"depth":277,"text":173},{"id":184,"depth":272,"text":185},{"id":244,"depth":272,"text":245},"2026-07-25","namespaceで環境を分けただけでは、ポリシーもリソース制限も自動では引き継がれない。Kubernetesマルチテナンシーの落とし穴と、Capsule・vCluster・HNCという3つの解決アプローチを実務目線で解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation",{"title":5,"description":287},"blog\u002Fja\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation",[297,298,299,300,301,302],"k3s","kubernetes","multi-tenancy","capsule","namespace","managed-kubernetes","PFqmDNQMQiHWjkTSEsqiE5LE4JGLsYbyg1biZ-wIpfw",[305,313,321,329,338,346],{"path":306,"title":307,"description":308,"date":309,"tags":310},"\u002Fblog\u002Fja\u002Fkubernetes-namespace-environment-cost-design","本番前に環境はいくつ必要か。namespace分離で請求書を膨らませないKubernetes環境設計","開発・テスト・ステージング・本番と環境を増やすほどKubernetesのクラウド費用は膨らむ。namespace分離とResourceQuota、本番専用クラスタのハイブリッド構成でコストと隔離性を両立するKubernetes環境設計を解説する。","2026-07-21",[298,297,301,311,302,312],"cost-optimization","resource-quota",{"path":314,"title":315,"description":316,"date":317,"tags":318},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[297,298,319,320,302],"kubevirt","networking",{"path":322,"title":323,"description":324,"date":325,"tags":326},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[297,298,327,328,302],"resource-management","capacity-planning",{"path":330,"title":331,"description":332,"date":333,"tags":334},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[298,297,335,336,337,302],"microservices","service-mesh","latency",{"path":339,"title":340,"description":341,"date":342,"tags":343},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[298,297,344,345,302],"ai-inference","cncf",{"path":347,"title":348,"description":349,"date":350,"tags":351},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[297,298,352,353,302],"edge-computing","hybrid-cluster",1786701432875]