[{"data":1,"prerenderedAt":493},["ShallowReactive",2],{"blog-ja-k3s-hpa-containerresource-sidecar-utilization-dilution":3,"blog-related-ja-k3s-hpa-containerresource-sidecar-utilization-dilution":448,"blog-ja-k3s-hpa-containerresource-sidecar-utilization-dilution-alt":436},{"id":4,"title":5,"author":6,"body":7,"date":430,"description":431,"extension":432,"image":433,"locale":434,"meta":435,"navigation":436,"path":437,"seo":438,"stem":439,"tags":440,"__hash__":447},"blog\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution.md","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","Kubo Team",{"type":8,"value":9,"toc":423},"minimark",[10,15,23,31,47,56,60,66,75,84,92,96,102,119,128,340,352,361,365,371,380,392,399,403,406,419],[11,12,14],"h2",{"id":13},"_1-hpaの利用率はサイドカーの分まで含んで計算されている","1. HPAの「利用率」は、サイドカーの分まで含んで計算されている",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution\u002Fsection01.webp",[16,24,25,26,30],{},"KubernetesのHPA（HorizontalPodAutoscaler）を運用していて、「CPU使用率がしきい値を超えているはずなのにスケールしない」「逆に思ったより早くスケールアウトする」と感じたことはないだろうか。原因の多くは、HPAの標準的なResourceメトリクスがPod内の",[27,28,29],"strong",{},"全コンテナの使用量を合算","して利用率を計算している、という仕様そのものにある。",[16,32,33,34,38,39,46],{},"標準のResourceメトリクスは ",[35,36,37],"code",{},"sum(全コンテナの使用量) \u002F sum(全コンテナの要求値)"," で利用率を算出する（",[40,41,45],"a",{"href":42,"rel":43},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale\u002F",[44],"nofollow","Kubernetes公式ドキュメント","）。アプリケーションコンテナ1つだけなら問題にならないが、サービスメッシュのサイドカープロキシやログ収集エージェントなど、複数コンテナを1つのPodに同居させる構成が当たり前になった今、この合算方式は判断を狂わせる。",[16,48,49,50,55],{},"具体的な数値で見てみよう。APIコンテナが500m要求・350m使用、ログエージェントが200m要求・20m使用というPodがあるとする。Pod全体で見た利用率は370m ÷ 700m ≈ **52.9%**だが、アプリコンテナ単体の利用率は350m ÷ 500m = **70%**になる（",[40,51,54],{"href":52,"rel":53},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-08-01-sidecar-requests-scheduling-hpa-cost\u002Fview",[44],"oneuptime.comの解説","）。同じ負荷状況でも、見る対象によってスケーリング判断がまったく変わってしまうのだ。",[11,57,59],{"id":58},"_2-なぜ気づきにくいのか-サービスメッシュという見えない同居人","2. なぜ気づきにくいのか — サービスメッシュという\"見えない同居人\"",[16,61,62],{},[19,63],{"alt":64,"src":65},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution\u002Fsection02.webp",[16,67,68,69,74],{},"この問題が特に表面化しやすいのが、Istioなどのサービスメッシュを導入したタイミングだ。Istioの公式パフォーマンスドキュメントによれば、典型的な負荷条件下でサイドカープロキシ1つあたり約0.2 vCPU・60MBのメモリを消費する（",[40,70,73],{"href":71,"rel":72},"https:\u002F\u002Fistio.io\u002Flatest\u002Fdocs\u002Fops\u002Fdeployment\u002Fperformance-and-scalability\u002F",[44],"Istio公式ドキュメント","）。これ自体は小さな数字に見えるが、HPAのCPU利用率計算に混ざり込むことで、アプリコンテナの実際の負荷が見えにくくなる。",[16,76,77,78,83],{},"Google CloudのCloud Service Mesh運用ガイドでも、サイドカープロキシのリソース消費がHPAの計算に影響するため、リソースリクエスト\u002Fリミットを明示的に定義してリソース競合を防ぐことが推奨されている（",[40,79,82],{"href":80,"rel":81},"https:\u002F\u002Fdocs.cloud.google.com\u002Fservice-mesh\u002Fv1.26\u002Fdocs\u002Foperate-and-maintain\u002Fscalability-best-practices",[44],"Google Cloud公式ドキュメント","）。しかし多くのチームは、サービスメッシュを導入した後に「なぜかHPAの挙動が変わった」と気づくまで、この合算の影響に気づきにくい。ログ収集エージェントやセキュリティエージェントなど、サイドカーパターンを使う構成が増えるほど、この\"希薄化\"の影響は大きくなる。",[16,85,86,91],{},[40,87,90],{"href":88,"rel":89},"https:\u002F\u002Fkubo.hexabase.io\u002F",[44],"Kubo"," のようなK3sベースのマネージドKubernetesでも、Prometheus + Grafanaを標準搭載した構成でサービスメッシュやログ収集スタックを組み合わせる運用は珍しくない。標準のHPA仕様を正しく理解しておくことは、こうした構成での本番運用において避けて通れない。",[11,93,95],{"id":94},"_3-containerresourceメトリクスで対象コンテナだけを見る","3. ContainerResourceメトリクスで「対象コンテナだけ」を見る",[16,97,98],{},[19,99],{"alt":100,"src":101},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution\u002Fsection03.webp",[16,103,104,105,108,109,112,113,118],{},"この\"希薄化\"問題に対する公式な解決策が、",[35,106,107],{},"ContainerResource"," タイプのメトリクスだ。Kubernetesのこの機能は、Pod全体ではなく",[27,110,111],{},"特定のコンテナのリソース使用量だけ","を対象にHPAのスケーリング判定を行える（",[40,114,117],{"href":115,"rel":116},"https:\u002F\u002Fwww.kubernetes.dev\u002Fresources\u002Fkeps\u002F1610\u002F",[44],"KEP-1610: Container Resource based Autoscaling","）。",[16,120,121,122,127],{},"このKEPの提案背景には、まさに「サイドカーコンテナはメインアプリの負荷と相関しないリソース消費をする」という課題が明記されている。機能としてはKubernetes 1.20でalpha導入され、1.27でbeta化、そして**1.30でStable（GA）**に到達した（",[40,123,126],{"href":124,"rel":125},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2023\u002F05\u002F02\u002Fhpa-container-resource-metric\u002F",[44],"Kubernetes公式ブログ","）。設定は次のように、対象コンテナ名を明示するだけでよい。",[129,130,135],"pre",{"className":131,"code":132,"language":133,"meta":134,"style":134},"language-yaml shiki shiki-themes tokyo-night","apiVersion: autoscaling\u002Fv2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: app-hpa\nspec:\n  scaleTargetRef:\n    apiVersion: apps\u002Fv1\n    kind: Deployment\n    name: my-app\n  minReplicas: 2\n  maxReplicas: 10\n  metrics:\n  - type: ContainerResource\n    containerResource:\n      container: app-container\n      target:\n        type: Utilization\n        averageUtilization: 70\n      name: cpu\n","yaml","",[35,136,137,154,165,174,185,193,201,212,223,234,246,257,265,280,288,299,307,318,329],{"__ignoreMap":134},[138,139,142,146,150],"span",{"class":140,"line":141},"line",1,[138,143,145],{"class":144},"s0U2E","apiVersion",[138,147,149],{"class":148},"sAklC",":",[138,151,153],{"class":152},"sPY7s"," autoscaling\u002Fv2\n",[138,155,157,160,162],{"class":140,"line":156},2,[138,158,159],{"class":144},"kind",[138,161,149],{"class":148},[138,163,164],{"class":152}," HorizontalPodAutoscaler\n",[138,166,168,171],{"class":140,"line":167},3,[138,169,170],{"class":144},"metadata",[138,172,173],{"class":148},":\n",[138,175,177,180,182],{"class":140,"line":176},4,[138,178,179],{"class":144},"  name",[138,181,149],{"class":148},[138,183,184],{"class":152}," app-hpa\n",[138,186,188,191],{"class":140,"line":187},5,[138,189,190],{"class":144},"spec",[138,192,173],{"class":148},[138,194,196,199],{"class":140,"line":195},6,[138,197,198],{"class":144},"  scaleTargetRef",[138,200,173],{"class":148},[138,202,204,207,209],{"class":140,"line":203},7,[138,205,206],{"class":144},"    apiVersion",[138,208,149],{"class":148},[138,210,211],{"class":152}," apps\u002Fv1\n",[138,213,215,218,220],{"class":140,"line":214},8,[138,216,217],{"class":144},"    kind",[138,219,149],{"class":148},[138,221,222],{"class":152}," Deployment\n",[138,224,226,229,231],{"class":140,"line":225},9,[138,227,228],{"class":144},"    name",[138,230,149],{"class":148},[138,232,233],{"class":152}," my-app\n",[138,235,237,240,242],{"class":140,"line":236},10,[138,238,239],{"class":144},"  minReplicas",[138,241,149],{"class":148},[138,243,245],{"class":244},"sOJ5S"," 2\n",[138,247,249,252,254],{"class":140,"line":248},11,[138,250,251],{"class":144},"  maxReplicas",[138,253,149],{"class":148},[138,255,256],{"class":244}," 10\n",[138,258,260,263],{"class":140,"line":259},12,[138,261,262],{"class":144},"  metrics",[138,264,173],{"class":148},[138,266,268,272,275,277],{"class":140,"line":267},13,[138,269,271],{"class":270},"sgJMe","  -",[138,273,274],{"class":144}," type",[138,276,149],{"class":148},[138,278,279],{"class":152}," ContainerResource\n",[138,281,283,286],{"class":140,"line":282},14,[138,284,285],{"class":144},"    containerResource",[138,287,173],{"class":148},[138,289,291,294,296],{"class":140,"line":290},15,[138,292,293],{"class":144},"      container",[138,295,149],{"class":148},[138,297,298],{"class":152}," app-container\n",[138,300,302,305],{"class":140,"line":301},16,[138,303,304],{"class":144},"      target",[138,306,173],{"class":148},[138,308,310,313,315],{"class":140,"line":309},17,[138,311,312],{"class":144},"        type",[138,314,149],{"class":148},[138,316,317],{"class":152}," Utilization\n",[138,319,321,324,326],{"class":140,"line":320},18,[138,322,323],{"class":144},"        averageUtilization",[138,325,149],{"class":148},[138,327,328],{"class":244}," 70\n",[138,330,332,335,337],{"class":140,"line":331},19,[138,333,334],{"class":144},"      name",[138,336,149],{"class":148},[138,338,339],{"class":152}," cpu\n",[16,341,342,343,346,347,118],{},"実務上、注意すべき点が1つある。対象コンテナに resource request が設定されていないと、そのPodの利用率は「undefined」となりHPAが動作しない。また、コンテナ名を変更する際はロールアウト前にHPA定義を更新しておく必要がある（",[40,344,45],{"href":42,"rel":345},[44],"）。この更新を忘れると、サイレントにHPAが機能しなくなるため見落としやすい落とし穴だ。DoiTのブログでも同様の設定例が紹介されており、前提条件としてKubernetes 1.27以上とMetrics Serverの導入が必要だと説明されている（",[40,348,351],{"href":349,"rel":350},"https:\u002F\u002Fwww.doit.com\u002Fblog\u002Fkubernetes-fine-grained-horizontal-pod-autoscaling-with-container-resource-metrics",[44],"DoiT Cloud Intelligence",[16,353,354,355,360],{},"いずれの方式でも、HPAはMetrics Serverが提供するMetrics APIを通じてリソース使用量を取得している（",[40,356,359],{"href":357,"rel":358},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fdebug\u002Fdebug-cluster\u002Fresource-metrics-pipeline\u002F",[44],"Kubernetesのresource metrics pipeline解説","）。ContainerResourceメトリクスはこのパイプラインの上で、集計の粒度をPod単位からコンテナ単位に変えているにすぎない。追加のエージェントやツールは不要で、既存のMetrics Serverがあればそのまま使える。",[11,362,364],{"id":363},"_4-k3skuboでの考え方-標準kubernetesの機能なのでそのまま使える","4. K3s\u002FKuboでの考え方 — 標準Kubernetesの機能なのでそのまま使える",[16,366,367],{},[19,368],{"alt":369,"src":370},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution\u002Fsection04.webp",[16,372,373,374,379],{},"ここまで解説した内容は、HPAというKubernetes本体（kube-controller-manager）の機能に関する話であり、特定のディストリビューションに依存しない。K3sはmetrics-serverを標準コンポーネントとして同梱しているため（",[40,375,378],{"href":376,"rel":377},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s",[44],"K3s公式リポジトリ","）、ContainerResourceメトリクスも追加設定なしでそのまま利用できる。",[16,381,382,383,386,387,391],{},"これは",[40,384,90],{"href":88,"rel":385},[44],"のようなK3sベースのマネージドKubernetesを選ぶ理由の一つでもある。標準Kubernetesの機能がそのまま動くため、ベンダー独自の制約を気にせずHPAの設計を本などの公式情報どおりに進められる。特に",[40,388,390],{"href":88,"rel":389},[44],"Kubo Cloud","はPrometheus + Grafanaを標準搭載しているため、ContainerResourceメトリクスに切り替えた後の効果を、既存のモニタリングスタックですぐに確認できる点も実務上のメリットになる。",[16,393,394,395,398],{},"サービスメッシュやログ収集エージェントを組み合わせた本番構成を今まさに設計している、あるいは「HPAの挙動がなぜか期待通りでない」という課題を抱えているなら、こうした運用をコスト効率よく実践できる基盤として",[40,396,90],{"href":88,"rel":397},[44],"を検討する価値はあるはずだ。",[11,400,402],{"id":401},"_5-まとめ","5. まとめ",[16,404,405],{},"HPAの標準的なResourceメトリクスは、Pod内の全コンテナの使用量を合算して利用率を計算する。この仕様は、サイドカープロキシやログエージェントを伴う現代的なPod構成では、スケーリング判断を「希薄化」させる原因になる。ContainerResourceメトリクス（Kubernetes 1.30でStable化）に切り替えることで、メインアプリケーションコンテナだけに焦点を当てたスケーリングが可能になる。",[16,407,408,409,412,413,418],{},"この仕組みはKubernetes本体の機能であり、K3sやKuboのようなマネージドK8s環境でもそのまま適用できる。サービスメッシュやObservabilityスタックを使う本番運用を設計する際は、「何に対する何%か」を常に意識しておきたい。運用基盤そのものを見直したい場合は、標準Kubernetesの機能がフルに使える",[40,410,90],{"href":88,"rel":411},[44],"のようなマネージドK3sサービスも選択肢に入れてみてほしい。月額48,000円〜という価格で、EKSやAKSと同等のHPA設計をそのまま持ち込める。",[40,414,417],{"href":415,"rel":416},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[44],"お問い合わせ","から、具体的な構成についての相談も可能だ。",[420,421,422],"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 .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sOJ5S, html code.shiki .sOJ5S{--shiki-default:#FF9E64}html pre.shiki code .sgJMe, html code.shiki .sgJMe{--shiki-default:#9ABDF5}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":134,"searchDepth":156,"depth":156,"links":424},[425,426,427,428,429],{"id":13,"depth":156,"text":14},{"id":58,"depth":156,"text":59},{"id":94,"depth":156,"text":95},{"id":363,"depth":156,"text":364},{"id":401,"depth":156,"text":402},"2026-10-21","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution",{"title":5,"description":431},"blog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution",[441,442,443,444,445,446],"k3s","kubernetes","hpa","containerresource","autoscaling","service-mesh","K_tALT4RiBFKM_jv3Rbzoa5NNGPFJmAPtyBHi2fAcAo",[449,457,464,473,479,486],{"path":450,"title":451,"description":452,"date":453,"tags":454},"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","2026-10-12",[441,442,443,455,445,456],"prometheus-adapter","observability",{"path":458,"title":459,"description":460,"date":461,"tags":462},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[441,442,443,463,445],"vpa",{"path":465,"title":466,"description":467,"date":468,"tags":469},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[441,442,470,443,445,471,472],"keda","event-driven-scaling","scaledobject",{"path":474,"title":475,"description":476,"date":477,"tags":478},"\u002Fblog\u002Fja\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","K3sでイベント駆動オートスケーリングが必要になったら。HPAとKEDA、どちらを選ぶかの判断基準","K3sでHPAのCPU\u002Fメモリベースのスケーリングでは対応しきれないイベント駆動ワークロードに直面したとき、標準のHPAを使い続けるべきか、CNCF GraduatedプロジェクトのKEDAを導入すべきか。3つの判断基準とK3s環境での注意点を整理する。","2026-09-10",[441,442,443,470,445],{"path":480,"title":481,"description":482,"date":483,"tags":484},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[441,442,443,463,445,485],"metrics-server",{"path":487,"title":488,"description":489,"date":490,"tags":491},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[441,442,463,445,492],"cgroup",1792592606326]