[{"data":1,"prerenderedAt":637},["ShallowReactive",2],{"blog-ja-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods":3,"blog-related-ja-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods":590,"blog-ja-k3s-cluster-autoscaler-node-provisioning-lag-pending-pods-alt":577},{"id":4,"title":5,"author":6,"body":7,"date":571,"description":572,"extension":573,"image":574,"locale":575,"meta":576,"navigation":577,"path":578,"seo":579,"stem":580,"tags":581,"__hash__":589},"blog\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods.md","スケールアウト指示から実際にPodが動くまでの5分間。Cluster Autoscalerのノード追加が間に合わない理由","Kubo Team",{"type":8,"value":9,"toc":559},"minimark",[10,15,23,40,59,62,66,72,75,80,87,91,109,113,126,141,145,151,158,233,244,263,267,273,282,289,434,455,462,466,472,475,499,506,513,517,520,542,555],[11,12,14],"h2",{"id":13},"_1-hpaは正しく動いているのにpodが数分間pendingのままな理由","1. HPAは正しく動いているのに、Podが数分間Pendingのままな理由",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection01.webp",[16,24,25,26,30,31,34,35,39],{},"HPAのメトリクスを確認すると、確かにレプリカ数は増えている。だが ",[27,28,29],"code",{},"kubectl get pods"," を叩くと、増えたはずのPodが軒並み ",[27,32,33],{},"Pending"," のまま数分間動かない。デプロイのログにもエラーは出ていない。これは",[36,37,38],"strong",{},"HPAが壊れているのではなく、Cluster Autoscalerによるノード追加という別レイヤーの処理が追いついていない","ことがほとんどだ。",[16,41,42,43,50,51,54,55,58],{},"HPAとCluster Autoscalerは、同じ「オートスケーリング」という言葉でくくられがちだが、担当するレイヤーがまったく違う。HPAはPodの数を調整し、Cluster Autoscalerはノードの数を調整する。",[44,45,49],"a",{"href":46,"rel":47},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fhorizontal-pod-autoscale\u002F",[48],"nofollow","Kubernetes公式ドキュメント","によれば、HPAのスケールアップ時の安定化ウィンドウ（",[27,52,53],{},"stabilizationWindowSeconds","）はデフォルトで",[36,56,57],{},"0秒","、つまりメトリクスの変化にほぼ即座に反応する設計になっている。",[16,60,61],{},"一方でCluster Autoscalerは、既存ノードに空きがなく新しいPodがスケジュールできない状態（unschedulable）を検知してから、クラウドプロバイダーに新しいノードを要求し、それが起動してクラスタに参加するまで待つ必要がある。この**「即応するHPA」と「数分かかるノード追加」のギャップ**こそが、Podが宙に浮いたように見える正体だ。",[11,63,65],{"id":64},"_2-5分間の内訳を数値で分解する","2. 5分間の内訳を数値で分解する",[16,67,68],{},[19,69],{"alt":70,"src":71},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection02.webp",[16,73,74],{},"「数分」という言葉だけでは対策が立てられない。内訳を分解すると、遅延は3つの区間の直列合計であることが分かる。",[76,77,79],"h3",{"id":78},"hpaの反応時間約13分","HPAの反応時間（約1〜3分）",[16,81,82,83,86],{},"メトリクスサーバーがCPU\u002Fメモリ使用率を収集する間隔と、HPAコントローラーの同期周期が重なるため、実際に負荷が上がってからレプリカ数が更新されるまでに1〜3分ほどかかる。",[44,84,49],{"href":46,"rel":85},[48],"のbehaviorフィールドの説明にある通り、スケールアップのデフォルトポリシーは15秒周期で「現レプリカ数の100%増加」または「4 Pod追加」のうち大きい方を採用する、比較的積極的な設定だ。",[76,88,90],{"id":89},"cluster-autoscalerの反応時間30秒以内","Cluster Autoscalerの反応時間（30秒以内）",[16,92,93,98,99,102,103,108],{},[44,94,97],{"href":95,"rel":96},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fcluster-autoscaler\u002FFAQ.md",[48],"cluster-autoscalerのFAQ","によれば、Cluster Autoscalerは",[27,100,101],{},"--scan-interval","（デフォルト10秒）ごとにunschedulable Podをスキャンしている。",[44,104,107],{"href":105,"rel":106},"https:\u002F\u002Fkomodor.com\u002Flearn\u002Fcluster-autoscaler\u002F",[48],"Komodorの解説","でも、スケールアップの判定自体は「スケジュール不可能なポッドが増加した時点」で反応的にトリガーされるとされており、この検知自体は通常30秒以内に完了する。",[76,110,112],{"id":111},"クラウド側のノードプロビジョニング34分あるいはそれ以上","クラウド側のノードプロビジョニング（3〜4分、あるいはそれ以上）",[16,114,115,116,121,122,125],{},"最も時間がかかるのがこの区間だ。VMインスタンスの起動、OSブート、kubeletの起動、クラスタへの登録という一連の処理に、",[44,117,120],{"href":118,"rel":119},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fcluster-autoscaler-scale-up",[48],"Google Cloudの公式トラブルシューティングガイド","が示すようなクラウド固有の要因も加わり、通常3〜4分を要する。合計すると、HPAの検知からPodが実際に動き出すまで",[36,123,124],{},"通常約5分","というのが目安になる。",[16,127,128,129,132,133,136,137,140],{},"なお、",[44,130,97],{"href":95,"rel":131},[48],"には",[27,134,135],{},"--max-node-provision-time","（デフォルト15分）というフラグもあり、この時間内にノードが登録されないとスケールアップシミュレーションから除外され、別のノードグループへの割り当てが試みられる。逆に",[27,138,139],{},"--scale-down-delay-after-add","（デフォルト約10分）は、追加した直後のノードをすぐ削除しないための安全マージンだ。",[11,142,144],{"id":143},"_3-ノードは足りているはずなのに増えないを疑うべきチェックリスト","3. 「ノードは足りているはずなのに増えない」を疑うべきチェックリスト",[16,146,147],{},[19,148],{"alt":149,"src":150},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection03.webp",[16,152,153,154,157],{},"5分待っても状況が変わらない場合は、単純な遅延ではなく設定上の問題を疑うべきだ。",[44,155,120],{"href":118,"rel":156},[48],"は、GKEでスケールアップが失敗する典型的な原因をエラーコードとして整理している。",[159,160,161,177],"table",{},[162,163,164],"thead",{},[165,166,167,171,174],"tr",{},[168,169,170],"th",{},"エラーコード",[168,172,173],{},"原因",[168,175,176],{},"対応",[178,179,180,194,207,220],"tbody",{},[165,181,182,188,191],{},[183,184,185],"td",{},[27,186,187],{},"scale.up.error.out.of.resources",[183,189,190],{},"GPU\u002FCPUリソース不足",[183,192,193],{},"別ゾーン・別マシンタイプを検討",[165,195,196,201,204],{},[183,197,198],{},[27,199,200],{},"scale.up.error.quota.exceeded",[183,202,203],{},"Compute Engineのクォータ超過",[183,205,206],{},"クォータ増加を申請",[165,208,209,214,217],{},[183,210,211],{},[27,212,213],{},"scale.up.error.ip.space.exhausted",[183,215,216],{},"VPCのIP割り当て不足",[183,218,219],{},"サブネット設計を見直す",[165,221,222,227,230],{},[183,223,224],{},[27,225,226],{},"no.scale.up.mig.failing.predicate",[183,228,229],{},"ノードアフィニティ\u002Ftaint\u002Ftoleration不一致",[183,231,232],{},"Pod仕様を見直す",[16,234,235,236,239,240,243],{},"同ガイドでは、不健全なノードが",[36,237,238],{},"45%を超えるとCluster Autoscalerが安全装置としてスケールアップを停止する","とも説明されている。",[27,241,242],{},"kubectl describe configmap cluster-autoscaler-status -n kube-system"," で現在の判定理由を確認できるのは、クラウド問わず有効な診断手順だ。",[16,245,246,247,252,253,256,257,262],{},"K3sのようなセルフホスト・エッジ環境では、この「クラウドAPIのクォータ」という要因は存在しない代わりに、既存ノードのリソース余力そのものが焦点になる。",[44,248,251],{"href":249,"rel":250},"https:\u002F\u002Fdocs.k3s.io\u002Freference\u002Fresource-profiling",[48],"K3s公式のリソースプロファイリング","によれば、新しいエージェントノードがクラスタに参加する際、サーバー（コントロールプレーン）側のCPU使用率が基準値から",[36,254,255],{},"約20%スパイク","することが観測されており、スケーリングを制限する要因は「RAMではなくCPU」であるとされている。オンプレやエッジでノード追加が遅いと感じたら、追加先のクラウド事情だけでなく、コントロールプレーン自体のCPU余力も確認する価値がある。こうした診断をダッシュボード上で可視化できるかどうかは運用負荷に直結する部分で、",[44,258,261],{"href":259,"rel":260},"https:\u002F\u002Fkubo.hexabase.io\u002F",[48],"Kubo","のCaptain UIはこの手のノード状態・スケジューリング理由を可視化する画面を標準搭載している。",[11,264,266],{"id":265},"_4-待たずに済ませる方法1-priorityclassによる予防的オーバープロビジョニング","4. 待たずに済ませる方法1 — PriorityClassによる予防的オーバープロビジョニング",[16,268,269],{},[19,270],{"alt":271,"src":272},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection04.webp",[16,274,275,276,281],{},"ノードプロビジョニングそのものを速くすることはできなくても、「待たなくて済む」状態を事前に作ることはできる。",[44,277,280],{"href":278,"rel":279},"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcontainers\u002Feliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning\u002F",[48],"AWS公式コンテナブログ","が紹介する手法がこれだ。",[16,283,284,285,288],{},"低優先度の",[27,286,287],{},"PriorityClass","を持つ「pause」コンテナだけのダミーPodを常時デプロイし、クラスタに余剰キャパシティを予約しておく。実際の高優先度ワークロードがPendingになった瞬間、スケジューラーはこのダミーPodを即座にpreemption（立ち退き）させ、空いた枠に本物のPodを配置する。ノードプロビジョニングを待つ必要がないため、体感の遅延はほぼゼロになる。",[290,291,296],"pre",{"className":292,"code":293,"language":294,"meta":295,"style":295},"language-yaml shiki shiki-themes tokyo-night","# 実ワークロード\nresources:\n  requests:\n    cpu: \"1\"\n    memory: \"500Mi\"\npriorityClassName: high-priority\n---\n# ダミーの予約枠\nresources:\n  requests:\n    cpu: \"1\"\n    memory: \"500Mi\"\npriorityClassName: low-priority\n","yaml","",[27,297,298,307,318,326,345,360,371,378,384,391,398,411,424],{"__ignoreMap":295},[299,300,303],"span",{"class":301,"line":302},"line",1,[299,304,306],{"class":305},"sbD-w","# 実ワークロード\n",[299,308,310,314],{"class":301,"line":309},2,[299,311,313],{"class":312},"s0U2E","resources",[299,315,317],{"class":316},"sAklC",":\n",[299,319,321,324],{"class":301,"line":320},3,[299,322,323],{"class":312},"  requests",[299,325,317],{"class":316},[299,327,329,332,335,338,342],{"class":301,"line":328},4,[299,330,331],{"class":312},"    cpu",[299,333,334],{"class":316},":",[299,336,337],{"class":316}," \"",[299,339,341],{"class":340},"sPY7s","1",[299,343,344],{"class":316},"\"\n",[299,346,348,351,353,355,358],{"class":301,"line":347},5,[299,349,350],{"class":312},"    memory",[299,352,334],{"class":316},[299,354,337],{"class":316},[299,356,357],{"class":340},"500Mi",[299,359,344],{"class":316},[299,361,363,366,368],{"class":301,"line":362},6,[299,364,365],{"class":312},"priorityClassName",[299,367,334],{"class":316},[299,369,370],{"class":340}," high-priority\n",[299,372,374],{"class":301,"line":373},7,[299,375,377],{"class":376},"sGX4V","---\n",[299,379,381],{"class":301,"line":380},8,[299,382,383],{"class":305},"# ダミーの予約枠\n",[299,385,387,389],{"class":301,"line":386},9,[299,388,313],{"class":312},[299,390,317],{"class":316},[299,392,394,396],{"class":301,"line":393},10,[299,395,323],{"class":312},[299,397,317],{"class":316},[299,399,401,403,405,407,409],{"class":301,"line":400},11,[299,402,331],{"class":312},[299,404,334],{"class":316},[299,406,337],{"class":316},[299,408,341],{"class":340},[299,410,344],{"class":316},[299,412,414,416,418,420,422],{"class":301,"line":413},12,[299,415,350],{"class":312},[299,417,334],{"class":316},[299,419,337],{"class":316},[299,421,357],{"class":340},[299,423,344],{"class":316},[299,425,427,429,431],{"class":301,"line":426},13,[299,428,365],{"class":312},[299,430,334],{"class":316},[299,432,433],{"class":340}," low-priority\n",[16,435,436,437,440,441,444,445,448,449,454],{},"同ブログでは",[27,438,439],{},"cluster-proportional-autoscaler","を使い、クラスタサイズに応じてダミーPodの数を自動調整する構成（例: ",[27,442,443],{},"coresPerReplica: 8",", ",[27,446,447],{},"nodesPerReplica: 4","）も紹介されている。ただしこの方法は「常に一定の余剰リソースを遊ばせておく」ことが前提であり、コストとのトレードオフになる点は無視できない。どこまで余剰を持つかの判断基準は、バーストの頻度と許容できる遅延次第だ。",[44,450,453],{"href":451,"rel":452},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-09-08-hpa-cluster-autoscaler-burst-traffic\u002Fview",[48],"oneuptimeの分析記事","が指摘するように、需要発生からトラフィック受信までの各段階（メトリクス反映・HPA更新・Pod作成・ノード要求・ノード起動・アプリ準備）を実測してボトルネックを特定した上で、オーバープロビジョニング量を設計するのが望ましい。",[16,456,457,458,461],{},"こうした余剰リソースの管理・コスト最適化は、手動で運用するとかえって属人化しやすい領域でもある。",[44,459,261],{"href":259,"rel":460},[48],"のAI-Driven Deploymentは、こうしたリソース設計の初期構築を自然言語の指示から代行できるため、YAMLでPriorityClassやダミーPodを一つずつ組み上げる作業から解放される。",[11,463,465],{"id":464},"_5-待たずに済ませる方法2-cluster-autoscalerからkarpenterへの乗り換えという選択肢","5. 待たずに済ませる方法2 — Cluster AutoscalerからKarpenterへの乗り換えという選択肢",[16,467,468],{},[19,469],{"alt":470,"src":471},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Fsection05.webp",[16,473,474],{},"オーバープロビジョニングでコストと引き換えに遅延を隠すのではなく、ノードプロビジョニングそのものを速くするという選択肢もある。AWS環境であれば、Cluster AutoscalerからKarpenterへの乗り換えがこれにあたる。",[16,476,477,482,483,486,487,490,491,494,495,498],{},[44,478,481],{"href":479,"rel":480},"https:\u002F\u002Fcast.ai\u002Fblog\u002Fkarpenter-vs-cluster-autoscaler\u002F",[48],"CAST AIの2026年比較記事","によれば、Cluster Autoscalerはノードグループ（ASG等）という抽象化レイヤーを経由するため通常",[36,484,485],{},"3〜4分","かかるのに対し、Karpenterはクラウド側のAPI（AWSならEC2の",[27,488,489],{},"RunInstances","）を直接呼び出し、Podの要件に合う最適なインスタンスタイプを広い候補群から選ぶことで",[36,492,493],{},"45〜60秒","でノードをReadyにできる。",[44,496,107],{"href":105,"rel":497},[48],"にもある通り、Cluster Autoscalerは10秒間隔のポーリングというアーキテクチャ上の制約を持つが、Karpenterはイベント駆動でこの制約自体を回避している。",[16,500,501,502,505],{},"どちらを選ぶべきかは単純な優劣ではなく、運用体制次第だ。",[36,503,504],{},"すでにAWS EKSでバーストトラフィックが頻繁に発生し、遅延がビジネス影響（SLA違反やユーザー体験の劣化）に直結している場合はKarpenterへの移行を検討する価値が高い。逆に、バーストの頻度が低く運用チームがCluster Autoscalerの挙動を熟知している場合は、方法1のオーバープロビジョニングで十分なことも多い。"," マルチクラウドやオンプレを含むK3s環境では、Karpenterはそもそも選択肢に入らないため、方法1の設計、あるいはノードプロビジョニングの主体（VMware\u002FProxmox\u002Fベアメタル）そのものの起動速度改善が現実的な打ち手になる。",[16,507,508,509,512],{},"このレイヤーの違いを意識せずに運用するのは、インフラエンジニアにとって地味だが確実に消耗する作業だ。",[44,510,261],{"href":259,"rel":511},[48],"はK3sベースのマネージドKubernetesとして、こうしたノードプロビジョニングの判断・実行そのものをAI-Driven Deploymentに任せられる設計を志向しており、EKSの約58%のコストでフルKubernetesの機能を維持しながら、この種の「待ち時間」を運用者が意識しなくて済む方向を目指している。",[11,514,516],{"id":515},"_6-まとめ","6. まとめ",[16,518,519],{},"「HPAが遅い」と感じたときの多くは、実際にはHPAではなくCluster Autoscalerによるノードプロビジョニングという別レイヤーの遅延だ。HPAの反応時間（1〜3分）、Cluster Autoscalerのスキャン間隔（10秒）、クラウド側のノード起動（3〜4分）という3つの直列区間が、合計で約5分という体感の遅延を生んでいる。",[16,521,522,523,525,526,529,530,533,534,537,538,541],{},"対策は3段階で考えるとよい。まず",[27,524,135],{},"や",[27,527,528],{},"scale.up.error.*","系のエラーコードを確認する",[36,531,532],{},"診断","、次にPriorityClassによる",[36,535,536],{},"予防的オーバープロビジョニング","、そして根本的にアーキテクチャを変える",[36,539,540],{},"Karpenterへの移行","（AWS環境の場合）だ。どの段階まで踏み込むかは、遅延がビジネスにどれだけの影響を与えているか次第で判断すればいい。",[16,543,544,545,548,549,554],{},"こうしたノード管理の複雑さそのものを運用の関心事から外したいのであれば、",[44,546,261],{"href":259,"rel":547},[48],"のようなマネージドK3sサービスを検討する価値がある。ノードプロビジョニングの設計・監視・コスト最適化までを含めて相談したい場合は、",[44,550,553],{"href":551,"rel":552},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[48],"お問い合わせ","から気軽に話を聞いてみてほしい。",[556,557,558],"style",{},"html pre.shiki code .sbD-w, html code.shiki .sbD-w{--shiki-default:#51597D;--shiki-default-font-style:italic}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 .sGX4V, html code.shiki .sGX4V{--shiki-default:#A9B1D6}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":295,"searchDepth":309,"depth":309,"links":560},[561,562,567,568,569,570],{"id":13,"depth":309,"text":14},{"id":64,"depth":309,"text":65,"children":563},[564,565,566],{"id":78,"depth":320,"text":79},{"id":89,"depth":320,"text":90},{"id":111,"depth":320,"text":112},{"id":143,"depth":309,"text":144},{"id":265,"depth":309,"text":266},{"id":464,"depth":309,"text":465},{"id":515,"depth":309,"text":516},"2026-09-27","HPAがレプリカ数を増やしてもPodがPendingのまま動かない。原因はCluster Autoscalerのノード追加に数分かかること。遅延の内訳、診断チェックリスト、オーバープロビジョニング、Karpenterとの速度比較まで実務目線で解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods",{"title":5,"description":572},"blog\u002Fja\u002Fk3s-cluster-autoscaler-node-provisioning-lag-pending-pods",[582,583,584,585,586,587,588],"k3s","kubernetes","cluster-autoscaler","karpenter","node-provisioning","hpa","priorityclass","_mZY9rJjI3jXcwFl81KwAWMA0kkK4ChWVVMRcSU3rhk",[591,600,608,615,624,630],{"path":592,"title":593,"description":594,"date":595,"tags":596},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[582,583,587,597,598,599],"containerresource","autoscaling","service-mesh",{"path":601,"title":602,"description":603,"date":604,"tags":605},"\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",[582,583,587,606,598,607],"prometheus-adapter","observability",{"path":609,"title":610,"description":611,"date":612,"tags":613},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[582,583,587,614,598],"vpa",{"path":616,"title":617,"description":618,"date":619,"tags":620},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[582,583,621,587,598,622,623],"keda","event-driven-scaling","scaledobject",{"path":625,"title":626,"description":627,"date":628,"tags":629},"\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",[582,583,587,621,598],{"path":631,"title":632,"description":633,"date":634,"tags":635},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[582,583,587,614,598,636],"metrics-server",1792592603506]