[{"data":1,"prerenderedAt":331},["ShallowReactive",2],{"blog-ja-k3s-opencost-onprem-gcp-default-pricing":3,"blog-related-ja-k3s-opencost-onprem-gcp-default-pricing":282,"blog-ja-k3s-opencost-onprem-gcp-default-pricing-alt":272},{"id":4,"title":5,"author":6,"body":7,"date":266,"description":267,"extension":268,"image":269,"locale":270,"meta":271,"navigation":272,"path":273,"seo":274,"stem":275,"tags":276,"__hash__":281},"blog\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing.md","K3sのオンプレ環境にOpenCostを入れたら、コストは最初からGCPの値段で計算されていた","Kubo Team",{"type":8,"value":9,"toc":259},"minimark",[10,15,23,26,37,41,47,61,70,74,80,88,97,104,108,114,127,211,214,227,230,255],[11,12,14],"h2",{"id":13},"_1-opencostを入れたのに出てきた数字が現実と合わない","1. OpenCostを入れたのに、出てきた数字が現実と合わない",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing\u002Fsection01.webp",[16,24,25],{},"K3sで組んだオンプレクラスタのコストを可視化しようと、CNCFサンドボックスプロジェクトの OpenCost を導入した。ダッシュボードには確かに数字が出てきたので、ひとまず安心した。ところが請求書や電気代と突き合わせてみると、まったく噛み合わない。ノード1台あたりの単価が、明らかに自社の実コストより高くも安くもない、どこかの「相場」で計算されているように見えた。",[16,27,28,29,36],{},"これは珍しいことではない。2024年に報じられた",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fwww.infoq.com\u002Fnews\u002F2024\u002F03\u002Fcncf-finops-kubernetes-overspend\u002F",[34],"nofollow","CNCFとFinOps Foundationによる調査","では、Kubernetes導入後に「コスト超過の主因」として可視性のギャップ（visibility gaps）を挙げた組織が40%にのぼり、実際にコスト削減まで運用できているFinOps成熟組織はわずか20%にとどまるという。オーバープロビジョニング(70%)と並んで、「見えていないこと」自体がコストを膨らませる要因になっている。OpenCostのようなツールを導入しても、設定を詰め切れていなければこの「見えていない」側に含まれてしまう。コスト可視化の設定そのものに工数がかかる状況は、マネージドなK8s基盤を選ぶかどうかの判断にも関わってくる。",[11,38,40],{"id":39},"_2-原因はデフォルト価格がgcp基準だったこと","2. 原因は「デフォルト価格がGCP基準」だったこと",[16,42,43],{},[19,44],{"alt":45,"src":46},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing\u002Fsection02.webp",[16,48,49,54,55,60],{},[30,50,53],{"href":51,"rel":52},"https:\u002F\u002Fopencost.io\u002Fdocs\u002Fconfiguration\u002Fon-prem\u002F",[34],"OpenCost 公式ドキュメント","によると、オンプレミス\u002Fベアメタル環境向けのデフォルト価格は「GCP us-central1 リージョンの料金」を基準に設定されている。具体的には CPU が1コア時間あたり約0.0316ドル、RAM が1GB時間あたり約0.0042ドルというのがデフォルト値だ。クラウド上で動いているなら、この仕組みは便利に働く。",[30,56,59],{"href":57,"rel":58},"https:\u002F\u002Fgithub.com\u002Fopencost\u002Fopencost",[34],"OpenCost のリポジトリ","でも説明されている通り、AWS・Azure・GCPそれぞれの請求APIと連携し、動的にオンデマンド価格を反映する設計になっているからだ。",[16,62,63,64,69],{},"問題は、オンプレ\u002Fベアメタル環境ではこの請求APIが存在しないことだ。OpenCostはハードウェアの減価償却費や電気代、ラック費用といった「自社固有のコスト構造」を自動で推測する手段を持たない。連携先のクラウドAPIがなければ、黙ってデフォルト値、つまりGCPの料金で計算を続ける。ダッシュボードはエラーも警告も出さず、ただ「それらしい数字」を表示し続けるため、気づかないまま運用してしまいやすい。",[30,65,68],{"href":66,"rel":67},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようにK3sをマネージドで提供する基盤では、そもそも利用者側がこの価格設定の前提を意識する必要がない。",[11,71,73],{"id":72},"_3-k3sだから余計に気づきにくい","3. K3sだから余計に気づきにくい",[16,75,76],{},[19,77],{"alt":78,"src":79},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing\u002Fsection03.webp",[16,81,82,87],{},[30,83,86],{"href":84,"rel":85},"https:\u002F\u002Fdocs.k3s.io\u002F",[34],"K3s は公式ドキュメント","で「軽量・単一バイナリ・100MB未満」の完全準拠Kubernetesディストリビューションと説明されている通り、エッジ・ホームラボ・IoT・オンプレ用途で選ばれることが多い。つまりK3sを選ぶ時点で「クラウドの請求APIが使えない環境」である確率がもともと高い。",[16,89,90,91,96],{},"一方でOpenCost自体は、",[30,92,95],{"href":93,"rel":94},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2022\u002F12\u002F06\u002Fopencost-a-new-cncf-sandbox-project-for-real-time-kubernetes-cost-monitoring\u002F",[34],"CNCF のブログ","が紹介している通り、特定のディストリビューションに依存しない「コスト測定の共通標準」を目指して設計されている。K3sかEKSかを意識せず同じように動く汎用性は長所だが、裏を返せば「K3sだから自動で正しい値にしてくれる」特別扱いは一切ない。マネージドK8s（EKS\u002FAKS\u002FGKE)ならクラウドAPI連携がほぼ自動で効くため気づきにくい問題が表面化しないが、K3sオンプレでは設定を怠ると最初から誤差を抱えたまま運用が始まってしまう。",[16,98,99,100,103],{},"Kuboのように、K3sベースでありながら料金体系があらかじめ固定されている",[30,101,68],{"href":66,"rel":102},[34],"のようなマネージドサービスであれば、この「価格設定を自分で追い込む手間」自体が発生しない。コストの予測性は、ツールの設定精度に依存しない形で担保される。",[11,105,107],{"id":106},"_4-正しいコストを出すにはカスタム価格を明示する","4. 正しいコストを出すには、カスタム価格を明示する",[16,109,110],{},[19,111],{"alt":112,"src":113},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing\u002Fsection04.webp",[16,115,116,117,121,122,126],{},"OpenCostは",[30,118,120],{"href":51,"rel":119},[34],"Helm Chart のカスタム価格設定","で、",[123,124,125],"code",{},"customPricing"," セクションに自社の実単価を明示できる。",[128,129,134],"pre",{"className":130,"code":131,"language":132,"meta":133,"style":133},"language-yaml shiki shiki-themes tokyo-night","opencost:\n  customPricing:\n    enabled: true\n    costModel:\n      CPU: 1.25\n      RAM: 0.50\n      storage: 0.25\n","yaml","",[123,135,136,149,157,170,178,189,200],{"__ignoreMap":133},[137,138,141,145],"span",{"class":139,"line":140},"line",1,[137,142,144],{"class":143},"s0U2E","opencost",[137,146,148],{"class":147},"sAklC",":\n",[137,150,152,155],{"class":139,"line":151},2,[137,153,154],{"class":143},"  customPricing",[137,156,148],{"class":147},[137,158,160,163,166],{"class":139,"line":159},3,[137,161,162],{"class":143},"    enabled",[137,164,165],{"class":147},":",[137,167,169],{"class":168},"sOJ5S"," true\n",[137,171,173,176],{"class":139,"line":172},4,[137,174,175],{"class":143},"    costModel",[137,177,148],{"class":147},[137,179,181,184,186],{"class":139,"line":180},5,[137,182,183],{"class":143},"      CPU",[137,185,165],{"class":147},[137,187,188],{"class":168}," 1.25\n",[137,190,192,195,197],{"class":139,"line":191},6,[137,193,194],{"class":143},"      RAM",[137,196,165],{"class":147},[137,198,199],{"class":168}," 0.50\n",[137,201,203,206,208],{"class":139,"line":202},7,[137,204,205],{"class":143},"      storage",[137,207,165],{"class":147},[137,209,210],{"class":168}," 0.25\n",[16,212,213],{},"ここで指定しなかった項目は、先述のGCPデフォルト値にフォールバックする点に注意が必要だ。サーバーの減価償却費、電気代、ラック・データセンター費用を按分して単価を出し、CPU・RAM・ストレージそれぞれに反映させて初めて、ダッシュボードの数字が意味を持つようになる。",[16,215,116,216,221,222,226],{},[30,217,220],{"href":218,"rel":219},"https:\u002F\u002Fwww.apptio.com\u002Fblog\u002Fhello-opencost\u002F",[34],"Adobe・AWS・Google・SUSEなど複数のクラウド\u002Fインフラベンダーが共同で立ち上げた","、特定ベンダーに依存しないコスト測定の標準を目指すプロジェクトだ。裏を返せば「ベンダー非依存であること」と「自社の実コストを自動で知っていること」は別問題であり、後者は利用者側が明示的に設定して初めて成立する。この設定作業をゼロにしたいなら、",[30,223,225],{"href":66,"rel":224},[34],"Kubo Cloud","のように月額固定でコストが最初から見えているマネージドK3sを選ぶという手もある（4vCPU\u002F8GB\u002F40GB×3ノード構成でEKSの約58%のコスト感）。",[11,228,229],{"id":229},"まとめ",[16,231,232,233,238,239,242,243,248,249,254],{},"コスト可視化ツールは、導入しただけでは「コストが分かった」ことにならない。そもそも",[30,234,237],{"href":235,"rel":236},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fconfiguration\u002Fmanage-resources-containers\u002F",[34],"Kubernetes公式ドキュメント","が定義するrequests\u002Flimitsの設計が曖昧なままでは、OpenCostがいくら正確な単価を持っていても配分の土台がぶれる。特にK3sのようなオンプレ・エッジ寄りの環境では、クラウドAPIに頼れない前提を踏まえてカスタム価格を自分で設定するところまでがセットだ。この手間を省きたいなら、最初から運用コストが固定・予測可能な基盤を選ぶという選択肢もある。",[30,240,68],{"href":66,"rel":241},[34],"はK3sベースのマネージドKubernetesとして、EKS\u002FAKS\u002FGKEよりも低いコストをあらかじめ提示しており、価格設定ツールの調整に時間をかける前に、まず",[30,244,247],{"href":245,"rel":246},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[34],"料金プラン","を比較してみる価値はあるはずだ。コスト可視化に悩んでいるなら、一度",[30,250,253],{"href":251,"rel":252},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から相談してみてほしい。",[256,257,258],"style",{},"html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sOJ5S, html code.shiki .sOJ5S{--shiki-default:#FF9E64}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":133,"searchDepth":151,"depth":151,"links":260},[261,262,263,264,265],{"id":13,"depth":151,"text":14},{"id":39,"depth":151,"text":40},{"id":72,"depth":151,"text":73},{"id":106,"depth":151,"text":107},{"id":229,"depth":151,"text":229},"2026-11-04","K3sのオンプレ・ベアメタル環境にOpenCostを導入しても、デフォルト設定のままではノードのCPU・RAMコストがGCP us-central1のクラウド料金で計算されてしまう。K3s環境で実際のハードウェアコストを正しく可視化するために必要なカスタム価格設定の手順と、見落としやすい理由を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing",{"title":5,"description":267},"blog\u002Fja\u002Fk3s-opencost-onprem-gcp-default-pricing",[277,278,144,279,280],"k3s","kubernetes","finops","cost-optimization","emBo80-8mkSWBBH6QSnRTKEVq1ORJiRXpGyoj91gzj0",[283,291,300,307,315,323],{"path":284,"title":285,"description":286,"date":287,"tags":288},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[277,278,280,289,290,279],"managed-kubernetes","aks",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fja\u002Fkarpenter-cluster-autoscaler-k3s-bare-metal-limitations","Karpenterは使えない。K3sオンプレでノードオートスケーリングを選ぶ前に知るべき制約","KarpenterとCluster Autoscalerの比較記事はAWS前提ばかりだ。K3s・オンプレ・ベアメタル環境でノードオートスケーリングを検討する前に知っておくべき制約と、現実的な選択肢を解説する。","2026-10-26",[277,278,297,298,299,280],"karpenter","cluster-autoscaler","node-provisioning",{"path":301,"title":302,"description":303,"date":304,"tags":305},"\u002Fblog\u002Fja\u002Faks-cost-optimization-fixed-cost-structure-k3s-comparison","AKSのコスト最適化を一通りやったのに、請求額はなぜ下げ止まるのか","AKSコスト最適化のノード右サイジングやSpot導入をやり切っても請求額が下げ止まるのは、LoadBalancer課金・監視アドオンという構造的な固定費があるため。K3s軽量アーキテクチャとのコスト構造比較で本当のボトルネックを解説する。","2026-09-07",[277,278,290,306,280,289],"azure",{"path":308,"title":309,"description":310,"date":311,"tags":312},"\u002Fblog\u002Fja\u002Fkubernetes-gpu-multitenancy-namespace-vs-dedicated-node","高価なGPUを独り占めさせるな。Kubernetesでアクセラレーターを分け合う設計に「唯一の正解」がない理由","KubernetesのGPUマルチテナント設計は namespace分離か専用ノードかの二択ではない。コストと分離レベルのトレードオフを解説し、ハイブリッド設計の考え方を紹介する。","2026-08-13",[277,278,313,280,314],"gpu-multitenancy","namespace-isolation",{"path":316,"title":317,"description":318,"date":319,"tags":320},"\u002Fblog\u002Fja\u002Fkubernetes-namespace-environment-cost-design","本番前に環境はいくつ必要か。namespace分離で請求書を膨らませないKubernetes環境設計","開発・テスト・ステージング・本番と環境を増やすほどKubernetesのクラウド費用は膨らむ。namespace分離とResourceQuota、本番専用クラスタのハイブリッド構成でコストと隔離性を両立するKubernetes環境設計を解説する。","2026-07-21",[278,277,321,280,289,322],"namespace","resource-quota",{"path":324,"title":325,"description":326,"date":327,"tags":328},"\u002Fblog\u002Fja\u002Fkubernetes-v136-k3s-managed-cost-reduction","マネージドKubernetesはもう高すぎる。K3s軽量化とv1.36セキュリティ強化で実現する『月額4万円台フルK8s運用』の現実味","Kubernetes v1.36「Haru」で強化されたUser Namespaces、セキュリティ機能をK3s軽量環境で活用する方法を解説。EKSより60%コスト削減を実現するマネージドK3s運用戦略と2026年のインフラ選定指針。","2026-05-28",[277,278,329,289,280,330],"kubernetes-v136","security",1793798694032]