[{"data":1,"prerenderedAt":443},["ShallowReactive",2],{"blog-ja-k3s-hpa-prometheus-adapter-discovery-interval-stale-metrics":3,"blog-related-ja-k3s-hpa-prometheus-adapter-discovery-interval-stale-metrics":398,"blog-ja-k3s-hpa-prometheus-adapter-discovery-interval-stale-metrics-alt":386},{"id":4,"title":5,"author":6,"body":7,"date":380,"description":381,"extension":382,"image":383,"locale":384,"meta":385,"navigation":386,"path":387,"seo":388,"stem":389,"tags":390,"__hash__":397},"blog\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics.md","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","Kubo Team",{"type":8,"value":9,"toc":370},"minimark",[10,15,23,26,56,70,79,83,86,146,153,157,163,177,194,197,201,207,219,232,241,249,253,259,262,340,347,351,354,357],[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-prometheus-adapter-discovery-interval-stale-metrics\u002Fsection01.webp",[16,24,25],{},"K3sでHPA（Horizontal Pod Autoscaler）とPrometheus Adapterを組み合わせて運用していると、ある日突然「CPU使用率もカスタムメトリクスも数値上は正常なのに、Podがまったく増えない」という事故に遭遇することがあります。",[16,27,28,32,33,36,37,44,45,48,49,48,52,55],{},[29,30,31],"code",{},"kubectl describe hpa"," を実行すると、ターゲットの値が ",[29,34,35],{},"\u003Cunknown>\u002F50"," のように表示されることがあります。",[38,39,43],"a",{"href":40,"rel":41},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale\u002F",[42],"nofollow","Kubernetes公式ドキュメント","によれば、これはPodのresource requestsが未設定、metrics-serverが未導入、あるいは ",[29,46,47],{},"metrics.k8s.io"," \u002F ",[29,50,51],{},"custom.metrics.k8s.io",[29,53,54],{},"external.metrics.k8s.io"," のいずれかのメトリクスAPIへのクエリが失敗している場合に起きます。",[16,57,58,59,63,64,69],{},"さらに厄介なのは、メトリクスが「古いまま固定される」だけでなく、逆に",[60,61,62],"strong",{},"メトリクス破損が過剰スケールを引き起こす","ケースもあることです。prometheus-adapterの公式リポジトリに寄せられた",[38,65,68],{"href":66,"rel":67},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fprometheus-adapter\u002Fissues\u002F636",[42],"実際の障害報告","では、CPU・メモリ・カスタムメトリクスの3つを使うHPA構成で、カスタムメトリクスが404を返すようになった結果、HPAが制御不能になりDeploymentが過剰にスケールアップされてしまったという事例が報告されています。「メトリクスが古い」ことと「メトリクスが壊れている」ことは別の障害モードであり、どちらもPrometheus Adapterというメトリクスパイプラインの状態に起因します。",[16,71,72,73,78],{},"こうしたメトリクス基盤の運用負荷は、自前でPrometheus Adapterを構築・保守している限りついて回ります。",[38,74,77],{"href":75,"rel":76},"https:\u002F\u002Fkubo.hexabase.io\u002F",[42],"Kubo","のようにPrometheus監視がK3sベースのマネージド基盤に標準搭載されていれば、少なくとも「監視基盤自体の保守」からは解放されます。",[11,80,82],{"id":81},"_2-犯人はhpaではなくメトリクスが届くまでの三層の時差","2. 犯人はHPAではなく、メトリクスが届くまでの\"三層の時差\"",[16,84,85],{},"この種の事故の多くは、HPA本体のバグではなく、メトリクスが「Prometheus→Prometheus Adapter→HPA」という3つの層を通過する間に生じる遅延の積み重ねが原因です。",[87,88,89,106,129],"ol",{},[90,91,92,95,96,101,102,105],"li",{},[60,93,94],{},"Prometheusのスクレイプ間隔",": ",[38,97,100],{"href":98,"rel":99},"https:\u002F\u002Fprometheus.io\u002Fdocs\u002Fprometheus\u002Flatest\u002Fconfiguration\u002Fconfiguration\u002F",[42],"Prometheus公式ドキュメント","によると、",[29,103,104],{},"scrape_interval"," のグローバル既定値は1分です。ターゲットごとに上書きしない限り、メトリクスはこの間隔でしか更新されません。",[90,107,108,95,111,116,117,120,121,124,125,128],{},[60,109,110],{},"Prometheus Adapterの鮮度パラメータ",[38,112,115],{"href":113,"rel":114},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fprometheus-adapter\u002Fblob\u002Fmaster\u002FREADME.md",[42],"prometheus-adapter公式README","によれば、",[29,118,119],{},"--metrics-relist-interval","（既定10分）はPrometheusから「どんなメトリクスが存在するか」の一覧を更新する間隔、",[29,122,123],{},"--metrics-max-age","（既定は",[29,126,127],{},"metrics-relist-interval","と同値）はアダプターが「このメトリクスはまだ有効だ」とみなすための時間窓です。公式READMEはこの窓を口語的に\"discovery interval\"とも呼んでいます。",[90,130,131,95,134,137,138,141,142,145],{},[60,132,133],{},"HPAのポーリング間隔",[38,135,43],{"href":40,"rel":136},[42],"が示す通り、",[29,139,140],{},"kube-controller-manager"," の ",[29,143,144],{},"--horizontal-pod-autoscaler-sync-period"," は既定15秒です。K3sでもこの値を明示的に変更しない限りデフォルトのまま動きます。",[16,147,148,149,152],{},"ここで見落とされがちなのが、",[60,150,151],{},"HPAは15秒ごとに律儀にメトリクスを見に行っているが、見ている値自体がmetrics-relist-interval\u002Fmetrics-max-ageの設定時間ぶん古い可能性がある","という非対称です。既定値の組み合わせだと、アダプター側の鮮度窓（10分オーダー）がHPAのポーリング間隔（15秒）よりはるかに粗く、瞬間的なトラフィックスパイクに対してはPodが増えるまでに数分単位の遅れが生じても不思議ではありません。",[11,154,156],{"id":155},"_3-discoveryintervalmetrics-max-ageを収集間隔より短くすると何が起きるか","3. discoveryInterval（metrics-max-age）を収集間隔より短くすると何が起きるか",[16,158,159],{},[19,160],{"alt":161,"src":162},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics\u002Fsection02.webp",[16,164,165,166,168,169,172,173,176],{},"discoveryInterval（実体は",[29,167,123],{},"）の設定で特に注意すべきなのが、Prometheusのスクレイプ間隔との大小関係です。",[38,170,115],{"href":113,"rel":171},[42],"は明確に「",[29,174,175],{},"metrics-max-age"," はPrometheusのスクレイプ間隔と同じか、それ以上にすべき。さもないとメトリクスがアダプターから時々消える」と警告しています。",[16,178,179,180,185,186,189,190,193],{},"逆に言えば、discoveryIntervalを必要以上に短く設定していると、Prometheus側のスクレイプがたまたま遅れたタイミングでアダプターのウィンドウからメトリクスが外れ、HPAからは「メトリクスが存在しない」状態に見えてしまいます。",[38,181,184],{"href":182,"rel":183},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fprometheus-adapter\u002Fblob\u002Fmaster\u002Fdocs\u002Fconfig.md",[42],"prometheus-adapterのconfig.md","が定義する ",[29,187,188],{},"metricsQuery"," のrate窓（例: ",[29,191,192],{},"rate(http_requests_total[2m])","）も同様で、窓が短すぎると瞬間的な欠損に敏感になり、長すぎると平滑化されすぎて反応が遅れるというトレードオフがあります。",[16,195,196],{},"K3s環境でPrometheus Operatorやkube-prometheus-stackをデフォルト設定のまま導入していると、この「discoveryIntervalとスクレイプ間隔の大小関係」を意識する機会自体がほとんどありません。だからこそ、HPAが不安定になったときに真っ先に疑うべき設定項目になります。",[11,198,200],{"id":199},"_4-kedaを足しても速くならない理由","4. KEDAを足しても速くならない理由",[16,202,203],{},[19,204],{"alt":205,"src":206},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics\u002Fsection03.webp",[16,208,209,210,116,215,218],{},"「HPAが遅いならKEDAを入れればいい」という判断は半分だけ正しく、半分は誤解です。",[38,211,214],{"href":212,"rel":213},"https:\u002F\u002Fkeda.sh\u002Fdocs\u002F2.20\u002Freference\u002Fscaledobject-spec",[42],"KEDA公式のScaledObject仕様",[29,216,217],{},"pollingInterval","（既定30秒）はKEDAが各トリガーをチェックする間隔で、レプリカ数が0のときはこの間隔でポーリングしてスケール判断を行います。",[16,220,221,222,224,225,227,228,231],{},"しかし、レプリカ数が1〜Nの範囲にある間は、KEDAに加えて通常のHPAも定期的にメトリクスを評価しており、その頻度は",[29,223,140],{},"の",[29,226,144],{},"（既定15秒）で決まります。つまり",[60,229,230],{},"1→Nのスケールアップ・ダウン局面では、結局HPAがPrometheus Adapter経由のメトリクスをそのまま見ている","ため、discoveryInterval\u002Fmetrics-relist-intervalが引き起こす鮮度問題はKEDAを足しても解消しません。KEDAが追加で担っているのは、あくまで0→1の起動判定という別レイヤーの話です。",[16,233,234,235,240],{},"ちなみにKubernetesコミュニティでは、外部メトリクス取得が一定時間失敗し続けた場合に静的なフォールバックレプリカ数を使う仕組み（",[38,236,239],{"href":237,"rel":238},"https:\u002F\u002Fwww.kubernetes.dev\u002Fresources\u002Fkeps\u002F5679\u002F",[42],"KEP-5679","）が議論されていますが、これはあくまで「取得失敗」への対処であり、「取得はできるが値が古い」という本稿のテーマには直接効きません。現状はメトリクスパイプラインの間隔設計を運用側で揃えるしかない、というのが実情です。",[16,242,243,244,248],{},"KEDAもHPAも結局は自分たちで監視基盤の間隔設計を背負うことになる、という点は見落とされがちです。",[38,245,247],{"href":75,"rel":246},[42],"Kubo Cloud","ならGitOps対応・Helmチャート対応と合わせてPrometheus + Grafanaが標準搭載されており、KEDA\u002FHPAの設定変更もArgoCD\u002FFlux経由でバージョン管理しながら運用できます。",[11,250,252],{"id":251},"_5-k3skubo環境での診断チェックリスト","5. K3s\u002FKubo環境での診断チェックリスト",[16,254,255],{},[19,256],{"alt":257,"src":258},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics\u002Fsection04.webp",[16,260,261],{},"実際に「HPAが反応しない」事故が起きたときの診断手順を、優先度順に整理します。",[87,263,264,291,307,316,330],{},[90,265,266,95,269,272,273,276,277,282,283,286,287,290],{},[60,267,268],{},"Conditionsを確認する",[29,270,271],{},"kubectl describe hpa \u003Cname>"," を実行し、ターゲット値が",[29,274,275],{},"\u003Cunknown>","になっていないか、Conditions欄にエラーが出ていないか確認します。",[38,278,281],{"href":279,"rel":280},"https:\u002F\u002Fdocs.datadoghq.com\u002Fcontainers\u002Ftroubleshooting\u002Fhpa\u002F",[42],"Datadog公式のトラブルシューティングドキュメント","が示すように、",[29,284,285],{},"FailedGetExternalMetric","はRBAC設定不足やメトリクスプロバイダーとの接続問題、",[29,288,289],{},"FailedComputeMetricsReplicas","はメトリクスプロバイダー自体が起動していない場合に出やすいエラーです。",[90,292,293,95,296,299,300,48,303,306],{},[60,294,295],{},"APIServiceの状態を確認する",[29,297,298],{},"kubectl get apiservices | grep metrics"," で ",[29,301,302],{},"v1beta1.custom.metrics.k8s.io",[29,304,305],{},"v1beta1.external.metrics.k8s.io"," がAvailable=Trueになっているか確認します。",[90,308,309,95,312,315],{},[60,310,311],{},"メトリクスがAPIに登録されているか直接確認する",[29,313,314],{},"kubectl get --raw \u002Fapis\u002Fcustom.metrics.k8s.io\u002Fv1beta1"," で、狙っているメトリクスが一覧に出てくるかを直接見ます。",[90,317,318,321,322,48,324,326,327,329],{},[60,319,320],{},"間隔設定を突き合わせる",": prometheus-adapterの起動引数 ",[29,323,119],{},[29,325,123],{}," と、実際のPrometheusの",[29,328,104],{},"を比較します。後者が前者を上回っていればメトリクスが周期的に消える可能性があります。",[90,331,332,335,336,339],{},[60,333,334],{},"resource requestsを確認する",": CPU使用率ベースのHPAでは、",[38,337,43],{"href":40,"rel":338},[42],"の通り、Podにresource requestsが定義されていないとそもそも使用率が計算できません。",[16,341,342,343,346],{},"K3sでPrometheus + Grafanaを自前で構築・運用している場合、こうした間隔設定のチューニングと監視自体がSREチームの継続的な運用負荷になります。",[38,344,77],{"href":75,"rel":345},[42],"のようにPrometheus + Grafanaが標準搭載されたマネージドK3s環境であれば、メトリクス基盤そのものの構築・バージョン追従に時間を割く必要がなくなり、こうした「鮮度設計」のチューニングに集中できます。",[11,348,350],{"id":349},"_6-まとめ","6. まとめ",[16,352,353],{},"HPAが「メトリクス上は正常なのに反応しない」事故の多くは、HPA自体の不具合ではなく、Prometheusのスクレイプ間隔・prometheus-adapterのmetrics-relist-interval\u002Fmetrics-max-age・HPAのsync-periodという3つの独立した時間設定が噛み合っていないことが原因です。discoveryInterval（metrics-max-age）という一見地味なパラメータこそ、障害調査で真っ先に疑うべき設定だと言えます。",[16,355,356],{},"KEDAの導入は0→1のスケール判定を速くしますが、1→Nのフェーズでは結局HPAがPrometheus Adapter経由のメトリクスに依存するため、本稿で扱った鮮度問題そのものの解決策にはなりません。「メトリクスの値」だけでなく「メトリクスが届く速さ」を疑う視点を持つことが、K3s\u002FKubernetes運用における次のオートスケーリング障害を未然に防ぐ鍵になります。",[16,358,359,360,363,364,369],{},"こうした運用ノウハウを自前で蓄積し続けるコストを下げたいなら、",[38,361,247],{"href":75,"rel":362},[42],"はPrometheus + Grafanaの監視基盤をK3sベースで標準搭載しており、EKS\u002FAKSの半額以下のコストで本格的なKubernetes運用を始められます。メトリクス周りの設定を一つひとつ手作業で揃えるのではなく、",[38,365,368],{"href":366,"rel":367},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[42],"お問い合わせ","から構成相談をしてみるのも一つの選択肢です。",{"title":371,"searchDepth":372,"depth":372,"links":373},"",2,[374,375,376,377,378,379],{"id":13,"depth":372,"text":14},{"id":81,"depth":372,"text":82},{"id":155,"depth":372,"text":156},{"id":199,"depth":372,"text":200},{"id":251,"depth":372,"text":252},{"id":349,"depth":372,"text":350},"2026-10-12","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics",{"title":5,"description":381},"blog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics",[391,392,393,394,395,396],"k3s","kubernetes","hpa","prometheus-adapter","autoscaling","observability","gqtPlRNIh7iCoUQITbOK9xM0qD35n3rqNVbUsyF-Ono",[399,407,414,423,429,436],{"path":400,"title":401,"description":402,"date":403,"tags":404},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[391,392,393,405,395,406],"containerresource","service-mesh",{"path":408,"title":409,"description":410,"date":411,"tags":412},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[391,392,393,413,395],"vpa",{"path":415,"title":416,"description":417,"date":418,"tags":419},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[391,392,420,393,395,421,422],"keda","event-driven-scaling","scaledobject",{"path":424,"title":425,"description":426,"date":427,"tags":428},"\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",[391,392,393,420,395],{"path":430,"title":431,"description":432,"date":433,"tags":434},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[391,392,393,413,395,435],"metrics-server",{"path":437,"title":438,"description":439,"date":440,"tags":441},"\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",[391,392,413,395,442],"cgroup",1792592606738]