[{"data":1,"prerenderedAt":695},["ShallowReactive",2],{"blog-ja-k3s-vpa-inplaceorrecreate-pod-resize-cgroup":3,"blog-related-ja-k3s-vpa-inplaceorrecreate-pod-resize-cgroup":645,"blog-ja-k3s-vpa-inplaceorrecreate-pod-resize-cgroup-alt":523},{"id":4,"title":5,"author":6,"body":7,"date":629,"description":630,"extension":631,"image":632,"locale":633,"meta":634,"navigation":523,"path":635,"seo":636,"stem":637,"tags":638,"__hash__":644},"blog\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup.md","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","Kubo Team",{"type":8,"value":9,"toc":621},"minimark",[10,15,32,40,51,58,62,81,88,108,152,156,167,180,192,210,219,225,229,241,264,267,275,281,285,291,446,460,467,556,580,586,590,593,600,608,617],[11,12,14],"h2",{"id":13},"無停止リサイズという触れ込みで試したらpodが再作成されていた","\"無停止リサイズ\"という触れ込みで試したら、Podが再作成されていた",[16,17,18,19,23,24,27,28,31],"p",{},"VPA（Vertical Pod Autoscaler）の",[20,21,22],"code",{},"updateMode","を",[20,25,26],{},"InPlaceOrRecreate","に変更した。これでPodを再起動せずにCPU・メモリを調整できるはずだった。ところが数日後にイベントログを見返すと、何度かPodが",[20,29,30],{},"Evicted","されて再作成されていた。",[16,33,34,35,39],{},"結論から言うと、これは不具合ではない。",[36,37,38],"strong",{},"In-Place Pod Resize（In-Place Pod Vertical Scaling）は「条件を満たした場合にだけ」コンテナを再起動せずにリソース変更できる機能であり、条件を外れると静かにPodの再作成にフォールバックする","設計になっている。",[16,41,42,43,50],{},"この記事では、VPAのInPlaceOrRecreateモードとIn-Place Pod Resizeの挙動を、K3s環境を前提に実際の設定・コマンド・ステータスの読み方まで含めて検証する（先に結論だけ言うと、",[44,45,49],"a",{"href":46,"rel":47},"https:\u002F\u002Fkubo.hexabase.io\u002F",[48],"nofollow","Kubo","のようにcgroupまわりの前提条件が構成済みのマネージドK3sであれば、この検証の大半を意識せずに済む）。",[16,52,53],{},[54,55],"img",{"alt":56,"src":57},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup\u002Fsection01.webp",[11,59,61],{"id":60},"in-place-pod-resizeの基礎-alphaからgaまでの6年間","In-Place Pod Resizeの基礎 — alphaからGAまでの6年間",[16,63,64,65,68,69,74,75,80],{},"In-Place Pod Resize（Kubernetesの",[20,66,67],{},"\u002Fresize","サブリソースを使った機能）は2023年にv1.27でalphaとして登場し、2025年5月のv1.33でbetaに昇格、そして",[44,70,73],{"href":71,"rel":72},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F12\u002F19\u002FKubernetes-v1-35-in-place-pod-resize-ga\u002F",[48],"2025年12月のv1.35でStable（GA）","に到達した。",[44,76,79],{"href":77,"rel":78},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F05\u002F16\u002FKubernetes-v1-33-in-place-pod-resize-beta\u002F",[48],"v1.33のベータ化を伝える公式ブログ","によれば、この間に再起動なしでのリソース調整がデフォルト有効になっている。",[16,82,83,84,87],{},"コンテナ単位で指定する",[20,85,86],{},"resizePolicy","には2つの値がある。",[89,90,91,100],"ul",{},[92,93,94,99],"li",{},[36,95,96],{},[20,97,98],{},"NotRequired",": リソース変更時にコンテナを再起動しない（デフォルト）",[92,101,102,107],{},[36,103,104],{},[20,105,106],{},"RestartContainer",": リソース変更時にコンテナを再起動する",[16,109,110,115,116,119,120,123,124,127,128,131,132,135,136,139,140,142,143,145,146,151],{},[44,111,114],{"href":112,"rel":113},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fconfigure-pod-container\u002Fresize-container-resources\u002F",[48],"Kubernetes公式ドキュメント","には、",[20,117,118],{},"kubectl patch pod \u003Cname> --subresource=resize","でリソースをパッチする方法と、結果を",[20,121,122],{},"status.conditions","の",[20,125,126],{},"PodResizePending","（理由: ",[20,129,130],{},"Deferred","または",[20,133,134],{},"Infeasible","）や",[20,137,138],{},"PodResizeInProgress","で確認する方法が示されている。",[20,141,130],{},"はノードの空きリソース不足による保留、",[20,144,134],{},"はノードの最大容量を超えていて実行不可能、という意味だ。2026年4月にはv1.36でPodレベルのリソースに対する",[44,147,150],{"href":148,"rel":149},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2026\u002F04\u002F30\u002Fkubernetes-v1-36-inplace-pod-level-resources-beta\u002F",[48],"in-placeリサイズもベータに昇格","しており、対象範囲は広がり続けている。",[11,153,155],{"id":154},"なぜinplaceorrecreateなのに再作成されるのか","なぜ\"InPlaceOrRecreate\"なのに再作成されるのか",[16,157,158,159,162,163,166],{},"最初に疑うべきはQoSクラスだ。",[44,160,114],{"href":112,"rel":161},[48],"が明記している通り、PodのQoSクラス（Guaranteed \u002F Burstable \u002F BestEffort）は作成時に固定され、",[36,164,165],{},"リサイズによって変更することはできない","。Burstableなコンテナのrequestsとlimitsを両方とも同じ値にしてGuaranteed相当にしてしまうような変更は、in-placeでは実行できない。",[16,168,169,170,175,176,179],{},"さらに見落としやすいのが初期値の有無だ。",[44,171,174],{"href":172,"rel":173},"https:\u002F\u002Fdevopscube.com\u002Fvpa-in-place-pod-resize\u002F",[48],"実践的な設定ガイド","によれば、",[36,177,178],{},"コンテナ側でrequests\u002Flimitsを何も設定していないと、そのPodはBestEffortとして扱われ、VPAがリソースを設定しようとした瞬間にQoSクラスが変わってしまうため再作成が必要になる","。InPlaceOrRecreateを使うなら、最初から最低限のrequests\u002Flimitsを入れておくことが前提条件になる。",[16,181,182,183,188,189,191],{},"VPA側の挙動も重要だ。",[44,184,187],{"href":185,"rel":186},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-08-25-vpa-inplaceorrecreate-feature-gate\u002Fview",[48],"InPlaceOrRecreateモードの解説記事","によると、VPAは",[20,190,67],{},"サブリソースでのパッチを試み、次の条件でevict（再作成）にフォールバックする。",[89,193,194,197,202,207],{},[92,195,196],{},"kubeletがリサイズをinfeasible、またはエラーと報告した場合",[92,198,199,201],{},[20,200,130],{},"状態が5分を超えて解消しない場合",[92,203,204,206],{},[20,205,138],{},"が1時間を超えて解消しない場合",[92,208,209],{},"提案されたリソース変更がQoSクラスを変えてしまう場合",[16,211,212,213,218],{},"同記事はもう一点、見落としがちな仕様にも触れている。",[36,214,215,217],{},[20,216,67],{},"が成功した場合はEviction APIを呼び出さないため、PodDisruptionBudgetが消費されない","。PDBで保護しているつもりでも、in-place成功時はそもそもPDBの判定を経由しないということだ。",[16,220,221],{},[54,222],{"alt":223,"src":224},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup\u002Fsection02.webp",[11,226,228],{"id":227},"k3sエッジ環境特有の罠-cgroupドライバが絡むと話がややこしくなる","K3s\u002Fエッジ環境特有の罠 — cgroupドライバが絡むと話がややこしくなる",[16,230,231,232,235,236,240],{},"K3sで運用している場合、もう一段ややこしい要因がある。cgroupのバージョンとドライバだ。In-Place Pod ResizeやPod Level Resourcesの検証では、ノードが",[20,233,234],{},"cgroup2","で動作していることが前提になっている（",[44,237,239],{"href":172,"rel":238},[48],"devopscube.comの検証ガイド","でも最初に確認すべき項目として挙げられている）。",[16,242,243,244,247,248,251,252,257,258,263],{},"K3sはあるバージョンからsystemd検出時にデフォルトのcgroupドライバを",[20,245,246],{},"cgroupfs","から",[20,249,250],{},"systemd","へ変更している。この変更自体はcgroup v2環境との親和性を高めるためのものだが、Docker上でK3sを動かす構成や、古いOSイメージのノードでは、",[44,253,256],{"href":254,"rel":255},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Fdiscussions\u002F7265",[48],"systemdドライバへの切り替えが原因でkubepodsコンテナが見つからないといった起動エラーが報告","されている。さらにエッジデバイス側では、",[44,259,262],{"href":260,"rel":261},"https:\u002F\u002Fdiscuss.luxonis.com\u002Fd\u002F6861-k3s-agent-fails-on-oak-4d-due-to-cgroup-v1-how-to-enable-cgroup-v2",[48],"K3sエージェントがcgroup v1のままでは起動に失敗する事例","も確認できる。",[16,265,266],{},"工場や店舗に置かれたエッジのK3sノードは、OSイメージの更新が後回しになりがちで、cgroup v1のまま運用され続けていることが珍しくない。そうしたノードでIn-Place Pod ResizeやVPAのInPlaceOrRecreateを有効にしても、Pod Level Resourcesを使った機能は前提から外れてしまう。「クラウドのクラスタでは動いたのに、エッジのクラスタでは同じYAMLがうまく機能しない」という事態は、まずcgroupのバージョンとドライバを疑うとよい。",[16,268,269,274],{},[44,270,273],{"href":271,"rel":272},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[48],"Kubo On-Premise","のようにK3sディストリビューション側でcgroup v2・systemdドライバの組み合わせを前提として構成しておけば、エッジ側のノードを個別に手直しする手間自体をなくせる。自前でOSイメージを管理している場合は、この前提条件のズレが最も起きやすいポイントだと意識しておきたい。",[16,276,277],{},[54,278],{"alt":279,"src":280},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup\u002Fsection03.webp",[11,282,284],{"id":283},"実践-resizepolicyの設定とkubectlでの検証手順","実践 — resizePolicyの設定とkubectlでの検証手順",[16,286,287,288,290],{},"まずコンテナ側に",[20,289,86],{},"を明示しておく。",[292,293,298],"pre",{"className":294,"code":295,"language":296,"meta":297,"style":297},"language-yaml shiki shiki-themes tokyo-night","resources:\n  requests:\n    cpu: \"250m\"\n    memory: \"256Mi\"\n  limits:\n    cpu: \"500m\"\n    memory: \"512Mi\"\nresizePolicy:\n  - resourceName: cpu\n    restartPolicy: NotRequired\n  - resourceName: memory\n    restartPolicy: RestartContainer\n","yaml","",[20,299,300,313,321,340,355,363,377,391,398,413,424,436],{"__ignoreMap":297},[301,302,305,309],"span",{"class":303,"line":304},"line",1,[301,306,308],{"class":307},"s0U2E","resources",[301,310,312],{"class":311},"sAklC",":\n",[301,314,316,319],{"class":303,"line":315},2,[301,317,318],{"class":307},"  requests",[301,320,312],{"class":311},[301,322,324,327,330,333,337],{"class":303,"line":323},3,[301,325,326],{"class":307},"    cpu",[301,328,329],{"class":311},":",[301,331,332],{"class":311}," \"",[301,334,336],{"class":335},"sPY7s","250m",[301,338,339],{"class":311},"\"\n",[301,341,343,346,348,350,353],{"class":303,"line":342},4,[301,344,345],{"class":307},"    memory",[301,347,329],{"class":311},[301,349,332],{"class":311},[301,351,352],{"class":335},"256Mi",[301,354,339],{"class":311},[301,356,358,361],{"class":303,"line":357},5,[301,359,360],{"class":307},"  limits",[301,362,312],{"class":311},[301,364,366,368,370,372,375],{"class":303,"line":365},6,[301,367,326],{"class":307},[301,369,329],{"class":311},[301,371,332],{"class":311},[301,373,374],{"class":335},"500m",[301,376,339],{"class":311},[301,378,380,382,384,386,389],{"class":303,"line":379},7,[301,381,345],{"class":307},[301,383,329],{"class":311},[301,385,332],{"class":311},[301,387,388],{"class":335},"512Mi",[301,390,339],{"class":311},[301,392,394,396],{"class":303,"line":393},8,[301,395,86],{"class":307},[301,397,312],{"class":311},[301,399,401,405,408,410],{"class":303,"line":400},9,[301,402,404],{"class":403},"sgJMe","  -",[301,406,407],{"class":307}," resourceName",[301,409,329],{"class":311},[301,411,412],{"class":335}," cpu\n",[301,414,416,419,421],{"class":303,"line":415},10,[301,417,418],{"class":307},"    restartPolicy",[301,420,329],{"class":311},[301,422,423],{"class":335}," NotRequired\n",[301,425,427,429,431,433],{"class":303,"line":426},11,[301,428,404],{"class":403},[301,430,407],{"class":307},[301,432,329],{"class":311},[301,434,435],{"class":335}," memory\n",[301,437,439,441,443],{"class":303,"line":438},12,[301,440,418],{"class":307},[301,442,329],{"class":311},[301,444,445],{"class":335}," RestartContainer\n",[16,447,448,449,451,452,454,455,459],{},"CPUは",[20,450,98],{},"で再起動なしの調整を許可しつつ、メモリは",[20,453,106],{},"にしておくと、JVMなどヒープサイズの再計算が必要なアプリケーションでも安全に動く。",[44,456,458],{"href":172,"rel":457},[48],"devopscube.comのガイド","もメモリ変更時のRestartContainer活用を推奨している。",[16,461,462,463,466],{},"検証は",[20,464,465],{},"kubectl","だけで完結する。",[292,468,472],{"className":469,"code":470,"language":471,"meta":297,"style":297},"language-bash shiki shiki-themes tokyo-night","kubectl patch pod \u003Cpod-name> --subresource=resize -p \\\n  '{\"spec\":{\"containers\":[{\"name\":\"app\",\"resources\":{\"requests\":{\"cpu\":\"400m\"}}}]}}'\n\nkubectl get pod \u003Cpod-name> -o jsonpath='{.status.conditions}'\n","bash",[20,473,474,508,519,525],{"__ignoreMap":297},[301,475,476,479,482,485,488,491,495,498,502,505],{"class":303,"line":304},[301,477,465],{"class":478},"sE3pS",[301,480,481],{"class":335}," patch",[301,483,484],{"class":335}," pod",[301,486,487],{"class":311}," \u003C",[301,489,490],{"class":335},"pod-nam",[301,492,494],{"class":493},"sGX4V","e",[301,496,497],{"class":311},">",[301,499,501],{"class":500},"sT800"," --subresource=resize",[301,503,504],{"class":500}," -p",[301,506,507],{"class":311}," \\\n",[301,509,510,513,516],{"class":303,"line":315},[301,511,512],{"class":311},"  '",[301,514,515],{"class":335},"{\"spec\":{\"containers\":[{\"name\":\"app\",\"resources\":{\"requests\":{\"cpu\":\"400m\"}}}]}}",[301,517,518],{"class":311},"'\n",[301,520,521],{"class":303,"line":323},[301,522,524],{"emptyLinePlaceholder":523},true,"\n",[301,526,527,529,532,534,536,538,540,542,545,548,551,554],{"class":303,"line":342},[301,528,465],{"class":478},[301,530,531],{"class":335}," get",[301,533,484],{"class":335},[301,535,487],{"class":311},[301,537,490],{"class":335},[301,539,494],{"class":493},[301,541,497],{"class":311},[301,543,544],{"class":500}," -o",[301,546,547],{"class":335}," jsonpath=",[301,549,550],{"class":311},"'",[301,552,553],{"class":335},"{.status.conditions}",[301,555,518],{"class":311},[16,557,558,560,561,563,564,566,567,569,570,572,573,576,577,579],{},[20,559,138],{},"が表示されていればリサイズ実行中、",[20,562,126],{},"に",[20,565,130],{},"があればノードのリソース不足、",[20,568,134],{},"があれば現在のノードでは実行不可能という意味になる。メモリを減らす方向のリサイズでは、使用量が新しいlimitを超えていると",[20,571,138],{},"が",[20,574,575],{},"Error","のまま止まることがあるため、ダウンサイジング系の変更は",[20,578,106],{},"を基本にしておくのが無難だ。",[16,581,582],{},[54,583],{"alt":584,"src":585},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup\u002Fsection04.webp",[11,587,589],{"id":588},"まとめ-再起動しないを前提に設計しない","まとめ — \"再起動しない\"を前提に設計しない",[16,591,592],{},"In-Place Pod Resizeは確かにv1.35でGAに到達し、VPAのInPlaceOrRecreateモードも実運用で使えるレベルになってきた。ただしそれは「条件を満たせば再起動が省略される」機能であって、「絶対に再起動しない」保証ではない。QoSクラスの固定、初期requests\u002Flimitsの有無、cgroupのバージョンとドライバ——この3点を事前に揃えておかないと、期待していたタイミングでPodが再作成される。",[16,594,595,596,599],{},"K3sをベースにしたマネージド環境であれば、cgroup v2とsystemdドライバの組み合わせやノード側の前提条件はあらかじめ揃っている。",[44,597,49],{"href":46,"rel":598},[48],"はK3sベースのマネージドKubernetesとして、こうした低レイヤーの前提条件を意識せずにVPAやIn-Place Pod Resizeを試せる環境を提供している。",[16,601,602,603,607],{},"VPAの運用設計そのものを見直したい場合は、",[44,604,606],{"href":46,"rel":605},[48],"Kubo Cloud","のAI-Driven Deploymentであれば、リソース設定やcgroup周りの前提条件をYAMLで細かく気にする前に、まず動く構成から始められる。EKSやAKSで同様の検証をする場合と比べて、月額48,000円〜という価格でフルスペックのKubernetesを試せる点も実務上の検討材料になるはずだ。",[16,609,610,611,616],{},"新機能を本番投入する前に、構成済みの環境で挙動を確かめたい場合は、",[44,612,615],{"href":613,"rel":614},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[48],"お問い合わせ","から相談してみてほしい。",[618,619,620],"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 .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);}html pre.shiki code .sE3pS, html code.shiki .sE3pS{--shiki-default:#C0CAF5}html pre.shiki code .sGX4V, html code.shiki .sGX4V{--shiki-default:#A9B1D6}html pre.shiki code .sT800, html code.shiki .sT800{--shiki-default:#E0AF68}",{"title":297,"searchDepth":315,"depth":315,"links":622},[623,624,625,626,627,628],{"id":13,"depth":315,"text":14},{"id":60,"depth":315,"text":61},{"id":154,"depth":315,"text":155},{"id":227,"depth":315,"text":228},{"id":283,"depth":315,"text":284},{"id":588,"depth":315,"text":589},"2026-10-17","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup\u002Ftitle.webp","ja",{},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup",{"title":5,"description":630},"blog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup",[639,640,641,642,643],"k3s","kubernetes","vpa","autoscaling","cgroup","Ql2EdNfiTMO4rPZOGzLtToaBZZYAwSXLXdqumW_4lp0",[646,653,660,668,676,685],{"path":647,"title":648,"description":649,"date":650,"tags":651},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[639,640,652,641,642],"hpa",{"path":654,"title":655,"description":656,"date":657,"tags":658},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[639,640,652,641,642,659],"metrics-server",{"path":661,"title":662,"description":663,"date":664,"tags":665},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[639,640,652,666,642,667],"containerresource","service-mesh",{"path":669,"title":670,"description":671,"date":672,"tags":673},"\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",[639,640,652,674,642,675],"prometheus-adapter","observability",{"path":677,"title":678,"description":679,"date":680,"tags":681},"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","2026-10-03",[639,640,682,652,642,683,684],"keda","event-driven-scaling","scaledobject",{"path":686,"title":687,"description":688,"date":689,"tags":690},"\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation","GPUメモリ不足でAIトレーニングジョブがOOMKilled。K3sでVPAが効かない理由とリソース設計","K3s上でAIトレーニングジョブがGPUメモリ不足でOOMKilledされる原因と、Vertical Pod Autoscalerが GPU リソースには効かない理由を解説。requests\u002Flimitsの正しい見積もり方法と実測ベースの設計手順まで、運用者向けに具体的に紹介します。","2026-09-20",[639,640,691,692,641,693,694],"gpu","oomkilled","ai-infrastructure","resource-management",1792592612132]