[{"data":1,"prerenderedAt":511},["ShallowReactive",2],{"blog-ja-k3s-vpa-poddisruptionbudget-mass-eviction":3,"blog-related-ja-k3s-vpa-poddisruptionbudget-mass-eviction":451,"blog-ja-k3s-vpa-poddisruptionbudget-mass-eviction-alt":439},{"id":4,"title":5,"author":6,"body":7,"date":433,"description":434,"extension":435,"image":436,"locale":437,"meta":438,"navigation":439,"path":440,"seo":441,"stem":442,"tags":443,"__hash__":450},"blog\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction.md","K3sで自動リソース最適化を入れたら、全レプリカが同時に退避した。PodDisruptionBudgetという防波堤","Kubo Team",{"type":8,"value":9,"toc":425},"minimark",[10,15,19,27,34,45,49,56,82,94,107,111,117,127,141,154,158,164,180,283,300,304,310,313,373,391,399,403,406,421],[11,12,14],"h2",{"id":13},"_1-ある夜k3sクラスタの全podが同時に消えた","1. ある夜、K3sクラスタの全Podが同時に消えた",[16,17,18],"p",{},"コスト削減のために、K3sクラスタにリソース使用量を自動で最適化するVertical Pod Autoscaler（VPA）を有効化した。効果はすぐに出た。過剰に確保していたCPU・メモリのリクエスト値が実使用量に近づき、ノードの空きリソースが増えた。",[16,20,21,22,26],{},"ところがある夜、監視ダッシュボードに503エラーが並んだ。原因を追うと、あるDeploymentのレプリカが",[23,24,25],"strong",{},"すべて同時に","再作成されていた。1台ずつローリングで更新されるはずのPodが、なぜ一斉に消えたのか。",[16,28,29,30,33],{},"答えは単純だった。",[23,31,32],{},"PodDisruptionBudget（PDB）を設定していなかった","。VPAのようなリソース最適化の仕組みは、放っておくと「安全装置なし」で稼働する。K3sのような小〜中規模クラスタほど、レプリカ数が少ない分この事故の影響は大きい。この記事では、なぜリソース最適化が全滅事故を引き起こすのか、そしてPodDisruptionBudgetがどう「最後の防波堤」になるのかを、実際の設定例とともに解説する。",[16,35,36,37,44],{},"こうした「安全装置の設定漏れ」は、クラスタを手動で構築・運用している限りどこでも起こりうる。",[38,39,43],"a",{"href":40,"rel":41},"https:\u002F\u002Fkubo.hexabase.io\u002F",[42],"nofollow","Kubo","のようなマネージドK3s環境なら、この手の運用ノウハウが標準構成に組み込まれている。",[11,46,48],{"id":47},"_2-なぜリソース最適化が全滅を引き起こすのか-podの退避メカニズム","2. なぜ「リソース最適化」が全滅を引き起こすのか — Podの退避メカニズム",[16,50,51],{},[52,53],"img",{"alt":54,"src":55},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction\u002Fsection01.webp",[16,57,58,59,64,65,69,70,73,74,77,78,81],{},"VPAは「Recommender」「Updater」「Admission Controller」という3つのコンポーネントで構成される。",[38,60,63],{"href":61,"rel":62},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fvertical-pod-autoscale\u002F",[42],"Kubernetesの公式ドキュメント","によれば、UpdateModeには",[66,67,68],"code",{},"Off","（推奨値を記録するだけ）、",[66,71,72],{},"Initial","（Pod作成時のみ適用）、",[66,75,76],{},"Recreate","（差分が大きいPodを退避して再作成）、",[66,79,80],{},"InPlaceOrRecreate","（まずインプレース更新を試みる）などの種類がある。",[16,83,84,85,87,88,93],{},"問題は",[66,86,76],{},"系のモードだ。稼働中のPodのリクエスト値がRecommenderの推奨値と大きくズレると、UpdaterはそのPodを退避（evict）して再作成する。",[38,89,92],{"href":90,"rel":91},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fvertical-pod-autoscaler\u002Fdocs\u002Fcomponents.md",[42],"kubernetes\u002Fautoscalerリポジトリの公式ドキュメント","には、Updaterは「Eviction APIを使ってPodを削除する」と明記されている。",[16,95,96,97,102,103,106],{},"Eviction APIは通常、Kubernetesの",[38,98,101],{"href":99,"rel":100},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fpods\u002Fdisruptions\u002F",[42],"Pod Disruption（中断）に関する公式ドキュメント","が定義する「自発的な中断（voluntary disruption）」の一種として扱われる。",[23,104,105],{},"PodDisruptionBudgetが存在しない場合、Eviction APIによる退避を止めるものが何もない。"," つまりUpdaterは、同じDeploymentの複数レプリカを同時に退避対象と判定した場合、それを妨げる仕組みがないまま処理を進めてしまう。",[11,108,110],{"id":109},"_3-hpaとの併用で状況はさらに悪化する","3. HPAとの併用で状況はさらに悪化する",[16,112,113],{},[52,114],{"alt":115,"src":116},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction\u002Fsection02.webp",[16,118,119,120,123,124],{},"多くのK3sクラスタでは、VPAだけでなくHorizontal Pod Autoscaler（HPA）も併用されている。ここでさらに厄介な問題が起きる。HPAは",[66,121,122],{},"requests.cpu","に対する使用率(%)でスケール判断をするため、",[23,125,126],{},"VPAがリクエスト値を変更した瞬間、実際の使用量は変わらないのに使用率の計算結果だけが変わる。",[16,128,129,134,135,140],{},[38,130,133],{"href":131,"rel":132},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fautoscaler\u002Fblob\u002Fmaster\u002Fvertical-pod-autoscaler\u002Fdocs\u002Fknown-limitations.md",[42],"kubernetes\u002Fautoscalerの既知の制限事項ドキュメント","は、「VPAは同一のリソースメトリクスでHPAと併用すべきではない」と明確に警告している。",[38,136,139],{"href":137,"rel":138},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fhpas-three-architectural-flaws-and-why-your-autoscaling-keeps-failing\u002F",[42],"ScaleOpsの解説記事","は、このメカニズムを「VPAがリクエストを削減→HPAの使用率が高く見える→過剰スケールアウト→Pod当たり使用量が下がりVPAがさらに削減を推奨」という無限ループとして説明している。",[16,142,143,144,148,149,153],{},"このHPA\u002FVPAの相互作用がなぜ起きるか、メトリクスが「不明」判定になるケースまで含めた詳しい診断は、以前取り上げた",[38,145,147],{"href":146},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","で解説している。イベント駆動での代替手段を検討したい場合は",[38,150,152],{"href":151},"\u002Fblog\u002Fja\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","HPAとKEDA、どちらを選ぶかの判断基準","も参考にしてほしい。今回のPDB事故は、この悪循環がなくても単独で起きうる、より根本的な設定漏れの問題だ。",[11,155,157],{"id":156},"_4-poddisruptionbudgetという最後の防波堤の設定方法","4. PodDisruptionBudgetという「最後の防波堤」の設定方法",[16,159,160],{},[52,161],{"alt":162,"src":163},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction\u002Fsection03.webp",[16,165,166,167,171,172,175,176,179],{},"PodDisruptionBudgetは、自発的な中断によって同時にダウンできるPod数の上限を定義する仕組みだ。",[38,168,170],{"href":99,"rel":169},[42],"Kubernetes公式のDisruptionsドキュメント","では、",[66,173,174],{},"minAvailable","（最低限稼働させる数）と",[66,177,178],{},"maxUnavailable","（同時に停止できる最大数）のどちらかを指定できると説明されている。",[181,182,187],"pre",{"className":183,"code":184,"language":185,"meta":186,"style":186},"language-yaml shiki shiki-themes tokyo-night","apiVersion: policy\u002Fv1\nkind: PodDisruptionBudget\nmetadata:\n  name: my-app-pdb\nspec:\n  minAvailable: 75%\n  selector:\n    matchLabels:\n      app: my-app\n","yaml","",[66,188,189,206,217,226,237,245,256,264,272],{"__ignoreMap":186},[190,191,194,198,202],"span",{"class":192,"line":193},"line",1,[190,195,197],{"class":196},"s0U2E","apiVersion",[190,199,201],{"class":200},"sAklC",":",[190,203,205],{"class":204},"sPY7s"," policy\u002Fv1\n",[190,207,209,212,214],{"class":192,"line":208},2,[190,210,211],{"class":196},"kind",[190,213,201],{"class":200},[190,215,216],{"class":204}," PodDisruptionBudget\n",[190,218,220,223],{"class":192,"line":219},3,[190,221,222],{"class":196},"metadata",[190,224,225],{"class":200},":\n",[190,227,229,232,234],{"class":192,"line":228},4,[190,230,231],{"class":196},"  name",[190,233,201],{"class":200},[190,235,236],{"class":204}," my-app-pdb\n",[190,238,240,243],{"class":192,"line":239},5,[190,241,242],{"class":196},"spec",[190,244,225],{"class":200},[190,246,248,251,253],{"class":192,"line":247},6,[190,249,250],{"class":196},"  minAvailable",[190,252,201],{"class":200},[190,254,255],{"class":204}," 75%\n",[190,257,259,262],{"class":192,"line":258},7,[190,260,261],{"class":196},"  selector",[190,263,225],{"class":200},[190,265,267,270],{"class":192,"line":266},8,[190,268,269],{"class":196},"    matchLabels",[190,271,225],{"class":200},[190,273,275,278,280],{"class":192,"line":274},9,[190,276,277],{"class":196},"      app",[190,279,201],{"class":200},[190,281,282],{"class":204}," my-app\n",[16,284,285,286,290,291,293,294,299],{},"このPDBがある状態では、",[38,287,289],{"href":90,"rel":288},[42],"kubernetes\u002Fautoscalerの公式ドキュメント","が示すとおり、Updaterは「PodDisruptionBudgetを尊重してEviction APIを使う」ため、退避がPDBに違反する場合は処理を保留し、1台ずつ安全に更新を進める。設定の目安としては、",[66,292,174],{},"を50〜75%程度に保ち、",[23,295,296,298],{},[66,297,174],{},"をレプリカ数と同じ値にしてはならない","（自発的な中断を完全にブロックしてしまう）。",[11,301,303],{"id":302},"_5-k3s本番運用でvpaを安全に使うための設定チェックリスト","5. K3s本番運用でVPAを安全に使うための設定チェックリスト",[16,305,306],{},[52,307],{"alt":308,"src":309},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction\u002Fsection04.webp",[16,311,312],{},"K3s本番運用でVPAを安全に併用するために、次の4点を順に確認したい。",[314,315,316,335,344,350],"ul",{},[317,318,319,322,323,325,326,328,329,331,332,334],"li",{},[23,320,321],{},"updateModeを段階的に選ぶ",": 最初から",[66,324,76],{},"や",[66,327,80],{},"で自動適用するのではなく、まず",[66,330,68],{},"または",[66,333,72],{},"で推奨値を観察してから本番適用に進む",[317,336,337,343],{},[23,338,339,342],{},[66,340,341],{},"resourcePolicy.maxAllowed","を必ず設定する",": ノードの最大リソースを超える推奨値を出さないよう上限を明示する。上限がないと、推奨値がノード容量を超えて永久にPending状態になるPodが発生しうる",[317,345,346,349],{},[23,347,348],{},"PodDisruptionBudgetを必ず作成する",": 前章の設定で、Updaterによる同時退避を1台ずつのローリングに制限する",[317,351,352,355,356,358,359,361,362,325,367,372],{},[23,353,354],{},"HPAとメトリクスを分離する",": HPAをCPU\u002Fメモリで動かす場合はVPAを",[66,357,68],{},"\u002F",[66,360,72],{},"にとどめる。逆にVPAでCPU\u002Fメモリを自動管理する場合は、HPAはリクエスト数やキュー深度などのカスタムメトリクスに寄せる。",[38,363,366],{"href":364,"rel":365},"https:\u002F\u002Fcloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fverticalpodautoscaler",[42],"Google CloudのGKE向けVPAドキュメント",[38,368,371],{"href":369,"rel":370},"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Faks\u002Fvertical-pod-autoscaler",[42],"Microsoft LearnのAKS向けVPAドキュメント","も同様の分離を推奨している",[16,374,375,376,381,382,387,388,390],{},"なお、Podを退避せずにリソースを変更する「In-Place Pod Resize」は",[38,377,380],{"href":378,"rel":379},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F05\u002F16\u002Fkubernetes-v1-33-in-place-pod-resize-beta\u002F",[42],"Kubernetes v1.33でBetaに昇格","し、",[38,383,386],{"href":384,"rel":385},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F12\u002F19\u002Fkubernetes-v1-35-in-place-pod-resize-ga",[42],"v1.35で正式にStable（GA）になった","。VPAの",[66,389,80],{},"モードはこの機能を活用することで、退避そのものを減らせる可能性がある。ただし対応バージョンでない環境では従来どおり退避が発生するため、PDBの設定は依然として必須だ。",[16,392,393,394,398],{},"このチェックリストを毎回自分のクラスタで組み立て直すのは、地味に手間がかかる作業だ。",[38,395,397],{"href":40,"rel":396},[42],"Kubo Cloud","はPrometheus + Grafanaによるモニタリングを標準搭載しており、Rancher管理基盤でUpdaterのevictイベントやVPAの推奨値の変化を複数クラスタにわたって一元的に可視化できる。K3sベースのため、今回解説したVPA\u002FHPA\u002FPDBの挙動もそのまま標準のKubernetesとして扱える。",[11,400,402],{"id":401},"_6-まとめ","6. まとめ",[16,404,405],{},"「便利な自動化」ほど、安全装置の設定漏れが事故につながりやすい。VPAによるリソース最適化は本番のコスト効率を確実に改善するが、PodDisruptionBudgetという最後の防波堤なしに本番投入すると、ある夜突然、全レプリカが同時に消えるリスクを抱えたままになる。",[16,407,408,409,414,415,420],{},"もし自社のデータセンター内でPDB設計やリソース最適化の運用を落とし込む必要がある場合は、",[38,410,413],{"href":411,"rel":412},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[42],"Kubo On-Premise","であれば、自社の管理下でフルマネージドに近い運用体制を構築できる。PodDisruptionBudgetの設計や退避制御の運用負荷を減らしたいという方は、",[38,416,419],{"href":417,"rel":418},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[42],"料金プラン","で構成例を確認してみてほしい。",[422,423,424],"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 .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":186,"searchDepth":208,"depth":208,"links":426},[427,428,429,430,431,432],{"id":13,"depth":208,"text":14},{"id":47,"depth":208,"text":48},{"id":109,"depth":208,"text":110},{"id":156,"depth":208,"text":157},{"id":302,"depth":208,"text":303},{"id":401,"depth":208,"text":402},"2026-09-18","K3sでリソース最適化ツールを有効化した直後、全レプリカが同時に退避され503が発生した実例をもとに、Podが一斉に退避されるメカニズムと、PodDisruptionBudgetのminAvailable設定による具体的な防御方法をエンジニア向けに詳しく解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction",{"title":5,"description":434},"blog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction",[444,445,446,447,448,449],"k3s","kubernetes","poddisruptionbudget","eviction","vertical-scaling","resource-optimization","MEfHZrObD985n-ddvun_6AcGWYXRspE99PdOaEGi92U",[452,461,471,483,493,501],{"path":453,"title":454,"description":455,"date":456,"tags":457},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[444,445,458,446,459,460],"topology-spread-constraints","scheduling","node-drain",{"path":462,"title":463,"description":464,"date":465,"tags":466},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[444,445,467,468,469,470],"hpa","containerresource","autoscaling","service-mesh",{"path":472,"title":473,"description":474,"date":475,"tags":476},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[444,445,477,478,479,480,481,482],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":484,"title":485,"description":486,"date":487,"tags":488},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[444,445,489,490,491,492],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":494,"title":495,"description":496,"date":497,"tags":498},"\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",[444,445,499,469,500],"vpa","cgroup",{"path":502,"title":503,"description":504,"date":505,"tags":506},"\u002Fblog\u002Fja\u002Fk3s-pod-security-admission-restricted-servicelb-outage","restrictedを有効にしたらServiceLBが死んだ。K3sのPod Security Admissionに潜む、汎用ガイドにない設定差分","K3sでPod Security Admissionのrestrictedプロファイルを有効化したら、標準Kubernetesのガイド通りに進めたのにServiceLBが機能停止した。原因と安全な導入手順をK3s公式ハードニングガイドの記述とともに解説する。","2026-10-16",[444,445,507,508,509,510],"pod-security-admission","pod-security-standards","servicelb","security",1792592612363]