[{"data":1,"prerenderedAt":806},["ShallowReactive",2],{"blog-ja-k3s-hpa-scaledown-stabilization-window-replica-flapping":3,"blog-related-ja-k3s-hpa-scaledown-stabilization-window-replica-flapping":745,"blog-ja-k3s-hpa-scaledown-stabilization-window-replica-flapping-alt":733},{"id":4,"title":5,"author":6,"body":7,"date":727,"description":728,"extension":729,"image":730,"locale":731,"meta":732,"navigation":733,"path":734,"seo":735,"stem":736,"tags":737,"__hash__":744},"blog\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping.md","HPAのレプリカ数が数分おきに増減する。原因はメトリクスではなくscaleDownスタビライゼーションウィンドウの設計不足だった","Kubo Team",{"type":8,"value":9,"toc":716},"minimark",[10,15,19,26,42,53,57,75,101,107,113,118,126,130,137,145,155,161,168,172,185,200,219,225,228,232,240,246,590,593,614,626,630,643,646,654,657,660,680,693,712],[11,12,14],"h2",{"id":13},"本番k3sクラスタでhpaのレプリカ数が5分おきに26を繰り返した","本番K3sクラスタで、HPAのレプリカ数が5分おきに2↔6を繰り返した",[16,17,18],"p",{},"ある本番のK3sクラスタで、HPA（HorizontalPodAutoscaler）を有効にしたワークロードのレプリカ数が、5分おきに2台と6台の間を行き来する現象が発生した。ダッシュボードを見る限り、リクエスト数もCPU負荷も横ばいで、明らかな異常は見当たらない。それなのにレプリカ数だけが波打つように増減し続けていた。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Fsection01.webp",[16,27,28,29,33,34,37,38,41],{},"これは典型的な「HPAのフラッピング（scaling flap）」と呼ばれる現象だ。原因調査を進めると、メトリクス取得自体には何も問題がなく、HPAの",[30,31,32],"code",{},"behavior","フィールドを一度も明示的に設定していなかったことが根本原因だと分かった。デフォルトの",[30,35,36],{},"scaleUp","\u002F",[30,39,40],{},"scaleDown","挙動が想定より攻撃的だったのだ。",[16,43,44,45,52],{},"この記事では、実際に起きた3つの原因（behaviorの非対称なデフォルト値、CPU requestsの分母問題、メトリクス同期間隔による遅延の積み上げ）を分解し、K3s環境での具体的な修正手順を解説する。こうした挙動の癖は自前でダッシュボードを組んで初めて気づくことが多いが、",[46,47,51],"a",{"href":48,"rel":49},"https:\u002F\u002Fkubo.hexabase.io\u002F",[50],"nofollow","Kubo","のCaptain UIのようにスケーリング推移が最初から可視化されていれば、気づくまでの時間を大きく縮められる。",[11,54,56],{"id":55},"原因1-scaleupscaledownのデフォルト値が非対称なのにbehaviorを何も設定していなかった","原因1: scaleUp\u002FscaleDownのデフォルト値が非対称なのに、behaviorを何も設定していなかった",[16,58,59,64,65,67,68,70,71,74],{},[46,60,63],{"href":61,"rel":62},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002Fhorizontal-pod-autoscale\u002F",[50],"Kubernetes公式ドキュメント","によれば、HPAの",[30,66,36],{},"と",[30,69,40],{},"にはそれぞれ異なるデフォルトの安定化ウィンドウ（",[30,72,73],{},"stabilizationWindowSeconds","）が設定されている。",[76,77,78,92],"ul",{},[79,80,81,83,84,87,88,91],"li",{},[30,82,36],{},": 安定化ウィンドウ 0秒（即座）、",[30,85,86],{},"selectPolicy","は",[30,89,90],{},"Max","（最も積極的な推奨値を採用）",[79,93,94,96,97,87,99],{},[30,95,40],{},": 安定化ウィンドウ 300秒（5分）、",[30,98,86],{},[30,100,90],{},[16,102,103],{},[22,104],{"alt":105,"src":106},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Fsection02.webp",[16,108,109,110,112],{},"つまり、負荷が上がった瞬間にレプリカ数は即座に増える一方、負荷が下がってもすぐには減らない。ここまでは意図された「安全側」の設計だ。しかし、",[30,111,32],{},"フィールドを何も設定していない状態で負荷がわずかに上下し続けると、scaleUpの「即座」な反応がscaleDownの「5分待ち」の効果を上書きし続け、レプリカ数がじわじわと振動する。",[114,115,117],"h3",{"id":116},"stabilization-windowの本当の役割","stabilization windowの本当の役割",[16,119,120,121,125],{},"stabilization windowは単純な「遅延タイマー」ではない。",[46,122,124],{"href":61,"rel":123},[50],"公式ドキュメント","によれば、ウィンドウ内に記録された過去の推奨レプリカ数の中から「最も保守的な値」を選ぶ仕組みだ。ウィンドウが短すぎると、この「保守的な値」を選ぶための材料が少なくなり、結果として振動を抑えきれなくなる。",[11,127,129],{"id":128},"原因2-cpu-requestsを最適化したことが逆に過敏なスケーリングを招いていた","原因2: CPU requestsを\"最適化\"したことが、逆に過敏なスケーリングを招いていた",[16,131,132,133,136],{},"コスト削減の一環として、Podの",[30,134,135],{},"resources.requests.cpu","を実測値に合わせて絞り込むチューニングを行うチームは多い。だが、これがHPAのフラッピングを悪化させることがある。",[16,138,139,144],{},[46,140,143],{"href":141,"rel":142},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fhpas-three-architectural-flaws-and-why-your-autoscaling-keeps-failing\u002F",[50],"ScaleOpsのブログ","が指摘する「パーセンテージ計算問題」がまさにこれだ。HPAのCPU使用率は次の式で計算される。",[146,147,152],"pre",{"className":148,"code":150,"language":151},[149],"language-text","utilization = 現在のCPU使用量 ÷ CPU requests × 100\n","text",[30,153,150],{"__ignoreMap":154},"",[16,156,157],{},[22,158],{"alt":159,"src":160},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Fsection03.webp",[16,162,163,164,167],{},"ワークロードの実際の消費量が変わっていなくても、",[30,165,166],{},"requests","を200mから100mに最適化した瞬間、分母が半分になるため見かけの利用率は75%から150%に跳ね上がる。HPAはこれを「負荷が急増した」と誤認し、不要なスケールアウトを引き起こす。コスト削減のためのrequests最適化が、皮肉にもスケーリングの不安定化を招く典型例だ。",[11,169,171],{"id":170},"原因3-metrics-serverとhpaの同期間隔が遅延を積み上げていた","原因3: metrics-serverとHPAの同期間隔が遅延を積み上げていた",[16,173,174,175,180,181,184],{},"K3sには標準で",[46,176,179],{"href":177,"rel":178},"https:\u002F\u002Fdocs.k3s.io\u002Finstallation\u002Fpackaged-components",[50],"metrics-serverがバンドルされており","、",[30,182,183],{},"kubectl top","コマンドやHPAのCPU\u002Fメモリメトリクスを支えている。この構成自体は便利だが、遅延の仕組みを理解しておく必要がある。",[16,186,187,192,193,196,197,199],{},[46,188,191],{"href":189,"rel":190},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fmetrics-server\u002Fblob\u002Fmaster\u002FFAQ.md",[50],"metrics-server公式リポジトリのFAQ","によれば、",[30,194,195],{},"metric-resolution","のデフォルト値は60秒だが、kubeletが計算するメトリクス自体の解像度が15秒であるため、15秒未満に設定することは推奨されていない。多くの本番環境では",[30,198,195],{},"を15秒に設定して運用している。",[16,201,202,203,208,209,212,213,218],{},"一方、HPAコントローラー自身にも同期間隔があり、",[46,204,207],{"href":205,"rel":206},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Fcommand-line-tools-reference\u002Fkube-controller-manager\u002F",[50],"kube-controller-managerのリファレンス","で定義される",[30,210,211],{},"--horizontal-pod-autoscaler-sync-period","のデフォルトは15秒だ。",[46,214,217],{"href":215,"rel":216},"https:\u002F\u002Fkubernetes-sigs.github.io\u002Fmetrics-server\u002F",[50],"metrics-server公式サイト","でも、このスクレイプ間隔とHPAのポーリング間隔が独立して動いていることが説明されている。",[16,220,221],{},[22,222],{"alt":223,"src":224},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Fsection04.webp",[16,226,227],{},"つまり、負荷が急増してからHPAが実際に「気づく」までに、単純計算でも15〜30秒の遅延が積み上がる。この遅延の間にも負荷が細かく上下していれば、HPAは常に「少し前の、既に古くなった状態」を見て判断することになり、フラッピングをさらに助長する。",[11,229,231],{"id":230},"対処-behaviorに明示的なpoliciesselectpolicyを設定してフラッピングを止める","対処: behaviorに明示的なpolicies・selectPolicyを設定してフラッピングを止める",[16,233,234,239],{},[46,235,238],{"href":236,"rel":237},"https:\u002F\u002Fmeteorops.com\u002Fblog\u002Fhow-to-configure-kubernetes-hpa-without-causing-scaling-flaps",[50],"MeteorOpsのブログ","が示す実務的な推奨値を元に、K3s上のHPAマニフェストを次のように修正した。",[16,241,242],{},[22,243],{"alt":244,"src":245},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Fsection05.webp",[146,247,251],{"className":248,"code":249,"language":250,"meta":154,"style":154},"language-yaml shiki shiki-themes tokyo-night","apiVersion: autoscaling\u002Fv2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: example\nspec:\n  scaleTargetRef:\n    apiVersion: apps\u002Fv1\n    kind: Deployment\n    name: example\n  minReplicas: 3\n  maxReplicas: 10\n  metrics:\n  - type: Resource\n    resource:\n      name: cpu\n      target:\n        type: Utilization\n        averageUtilization: 65\n  behavior:\n    scaleUp:\n      stabilizationWindowSeconds: 60\n      policies:\n      - type: Pods\n        value: 2\n        periodSeconds: 60\n      selectPolicy: Max\n    scaleDown:\n      stabilizationWindowSeconds: 300\n      policies:\n      - type: Percent\n        value: 25\n        periodSeconds: 60\n      selectPolicy: Min\n","yaml",[30,252,253,270,281,290,301,309,317,328,339,349,361,372,380,395,403,414,422,433,444,452,460,471,479,492,503,513,524,532,542,549,561,571,580],{"__ignoreMap":154},[254,255,258,262,266],"span",{"class":256,"line":257},"line",1,[254,259,261],{"class":260},"s0U2E","apiVersion",[254,263,265],{"class":264},"sAklC",":",[254,267,269],{"class":268},"sPY7s"," autoscaling\u002Fv2\n",[254,271,273,276,278],{"class":256,"line":272},2,[254,274,275],{"class":260},"kind",[254,277,265],{"class":264},[254,279,280],{"class":268}," HorizontalPodAutoscaler\n",[254,282,284,287],{"class":256,"line":283},3,[254,285,286],{"class":260},"metadata",[254,288,289],{"class":264},":\n",[254,291,293,296,298],{"class":256,"line":292},4,[254,294,295],{"class":260},"  name",[254,297,265],{"class":264},[254,299,300],{"class":268}," example\n",[254,302,304,307],{"class":256,"line":303},5,[254,305,306],{"class":260},"spec",[254,308,289],{"class":264},[254,310,312,315],{"class":256,"line":311},6,[254,313,314],{"class":260},"  scaleTargetRef",[254,316,289],{"class":264},[254,318,320,323,325],{"class":256,"line":319},7,[254,321,322],{"class":260},"    apiVersion",[254,324,265],{"class":264},[254,326,327],{"class":268}," apps\u002Fv1\n",[254,329,331,334,336],{"class":256,"line":330},8,[254,332,333],{"class":260},"    kind",[254,335,265],{"class":264},[254,337,338],{"class":268}," Deployment\n",[254,340,342,345,347],{"class":256,"line":341},9,[254,343,344],{"class":260},"    name",[254,346,265],{"class":264},[254,348,300],{"class":268},[254,350,352,355,357],{"class":256,"line":351},10,[254,353,354],{"class":260},"  minReplicas",[254,356,265],{"class":264},[254,358,360],{"class":359},"sOJ5S"," 3\n",[254,362,364,367,369],{"class":256,"line":363},11,[254,365,366],{"class":260},"  maxReplicas",[254,368,265],{"class":264},[254,370,371],{"class":359}," 10\n",[254,373,375,378],{"class":256,"line":374},12,[254,376,377],{"class":260},"  metrics",[254,379,289],{"class":264},[254,381,383,387,390,392],{"class":256,"line":382},13,[254,384,386],{"class":385},"sgJMe","  -",[254,388,389],{"class":260}," type",[254,391,265],{"class":264},[254,393,394],{"class":268}," Resource\n",[254,396,398,401],{"class":256,"line":397},14,[254,399,400],{"class":260},"    resource",[254,402,289],{"class":264},[254,404,406,409,411],{"class":256,"line":405},15,[254,407,408],{"class":260},"      name",[254,410,265],{"class":264},[254,412,413],{"class":268}," cpu\n",[254,415,417,420],{"class":256,"line":416},16,[254,418,419],{"class":260},"      target",[254,421,289],{"class":264},[254,423,425,428,430],{"class":256,"line":424},17,[254,426,427],{"class":260},"        type",[254,429,265],{"class":264},[254,431,432],{"class":268}," Utilization\n",[254,434,436,439,441],{"class":256,"line":435},18,[254,437,438],{"class":260},"        averageUtilization",[254,440,265],{"class":264},[254,442,443],{"class":359}," 65\n",[254,445,447,450],{"class":256,"line":446},19,[254,448,449],{"class":260},"  behavior",[254,451,289],{"class":264},[254,453,455,458],{"class":256,"line":454},20,[254,456,457],{"class":260},"    scaleUp",[254,459,289],{"class":264},[254,461,463,466,468],{"class":256,"line":462},21,[254,464,465],{"class":260},"      stabilizationWindowSeconds",[254,467,265],{"class":264},[254,469,470],{"class":359}," 60\n",[254,472,474,477],{"class":256,"line":473},22,[254,475,476],{"class":260},"      policies",[254,478,289],{"class":264},[254,480,482,485,487,489],{"class":256,"line":481},23,[254,483,484],{"class":385},"      -",[254,486,389],{"class":260},[254,488,265],{"class":264},[254,490,491],{"class":268}," Pods\n",[254,493,495,498,500],{"class":256,"line":494},24,[254,496,497],{"class":260},"        value",[254,499,265],{"class":264},[254,501,502],{"class":359}," 2\n",[254,504,506,509,511],{"class":256,"line":505},25,[254,507,508],{"class":260},"        periodSeconds",[254,510,265],{"class":264},[254,512,470],{"class":359},[254,514,516,519,521],{"class":256,"line":515},26,[254,517,518],{"class":260},"      selectPolicy",[254,520,265],{"class":264},[254,522,523],{"class":268}," Max\n",[254,525,527,530],{"class":256,"line":526},27,[254,528,529],{"class":260},"    scaleDown",[254,531,289],{"class":264},[254,533,535,537,539],{"class":256,"line":534},28,[254,536,465],{"class":260},[254,538,265],{"class":264},[254,540,541],{"class":359}," 300\n",[254,543,545,547],{"class":256,"line":544},29,[254,546,476],{"class":260},[254,548,289],{"class":264},[254,550,552,554,556,558],{"class":256,"line":551},30,[254,553,484],{"class":385},[254,555,389],{"class":260},[254,557,265],{"class":264},[254,559,560],{"class":268}," Percent\n",[254,562,564,566,568],{"class":256,"line":563},31,[254,565,497],{"class":260},[254,567,265],{"class":264},[254,569,570],{"class":359}," 25\n",[254,572,574,576,578],{"class":256,"line":573},32,[254,575,508],{"class":260},[254,577,265],{"class":264},[254,579,470],{"class":359},[254,581,583,585,587],{"class":256,"line":582},33,[254,584,518],{"class":260},[254,586,265],{"class":264},[254,588,589],{"class":268}," Min\n",[16,591,592],{},"ポイントは3つある。",[76,594,595,602,608],{},[79,596,597,601],{},[598,599,600],"strong",{},"scaleUpの安定化ウィンドウを60秒に設定",": 即座の反応をやめ、短命なスパイクに過剰反応しないようにする",[79,603,604,607],{},[598,605,606],{},"scaleDownをPercent 25%に制限",": 一度に大量のレプリカを削らず、段階的に減らす",[79,609,610,613],{},[598,611,612],{},"selectPolicyをMinに変更",": 複数のポリシーが競合したとき、最も保守的な（変化の少ない）値を採用する",[16,615,616,617,620,621,625],{},"あわせて、CPU requestsは実測値に対して安全マージンを持たせ、",[30,618,619],{},"averageUtilization","の目標を60〜75%程度に設定するのが",[46,622,624],{"href":236,"rel":623},[50],"MeteorOpsの推奨値","だ。本番のminReplicasも3以上を確保しておくと、スケールアップの遅延が発生してもベース容量で吸収できる。",[11,627,629],{"id":628},"設定しただけで安心しない-stabilizationwindowsecondsには既知の挙動の癖がある","設定しただけで安心しない — stabilizationWindowSecondsには既知の挙動の癖がある",[16,631,632,633,638,639,642],{},"behaviorを設定して終わり、ではない。",[46,634,637],{"href":635,"rel":636},"https:\u002F\u002Fgithub.com\u002Fkubernetes\u002Fkubernetes\u002Fissues\u002F101371",[50],"kubernetes\u002FkubernetesのGitHub Issue #101371","では、",[30,640,641],{},"stabilizationWindowSeconds: 300","と設定していても、実際には1〜2分でスケールダウンが実行されてしまうケースが報告されている。SIG Autoscalingでバグとして記録されている既知の挙動の癖だ。",[16,644,645],{},"つまり、「300秒に設定したから安全」という思い込みだけでは不十分で、実際の挙動を監視ダッシュボードで継続的に確認する必要がある。設定と実測は別物だと考えておいたほうがいい。",[16,647,648,649,653],{},"Kuboの",[46,650,652],{"href":48,"rel":651},[50],"Captain UI","を使えば、レプリカ数の推移をリアルタイムのグラフで可視化できるため、「設定通りに動いているか」を目視で確認しやすくなる。ダッシュボードを自前で構築する手間をかけずに、こうした挙動のズレに早く気づける点は運用上のメリットが大きい。",[11,655,656],{"id":656},"まとめ",[16,658,659],{},"HPAのレプリカ数が振動する原因は、「メトリクスが取れていない」ことよりも「behaviorの設計不足」であることが多い。今回のケースでは、次の3つが絡み合っていた。",[661,662,663,674,677],"ol",{},[79,664,665,667,668,670,671,673],{},[30,666,36],{},"（0秒・即座）と",[30,669,40],{},"（300秒）の非対称なデフォルト値を、明示的な",[30,672,32],{},"設定で上書きしていなかった",[79,675,676],{},"CPU requestsの最適化が、utilizationの分母を変え、見かけの利用率を跳ね上げていた",[79,678,679],{},"metrics-serverとHPAコントローラーの同期間隔（それぞれ約15秒）が遅延として積み上がっていた",[16,681,682,683,685,686,689,690,692],{},"対処としては、",[30,684,73],{},"・",[30,687,688],{},"policies","（Percent\u002FPods）・",[30,691,86],{},"を明示的に設定し、CPU requestsを実測値に合わせて調整することが基本になる。ただし設定して終わりではなく、実際の挙動を監視し続けることが重要だ。",[16,694,695,696,699,700,705,706,711],{},"K3sベースの",[46,697,51],{"href":48,"rel":698},[50],"なら、こうしたHPAのbehaviorテンプレートをAI-Driven Deploymentで適用しつつ、Captain UIでスケーリングの推移を可視化できる。EKSやAKSでは月額8万円前後かかる構成でも、Kuboなら",[46,701,704],{"href":702,"rel":703},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[50],"料金プラン","にある通り月額48,000円からフルスペックのKubernetes運用が可能だ。HPAの設定ミスに気づかないまま本番運用を続けるリスクを減らしたいなら、一度",[46,707,710],{"href":708,"rel":709},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[50],"お問い合わせ","から相談してみてほしい。",[713,714,715],"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":154,"searchDepth":272,"depth":272,"links":717},[718,719,722,723,724,725,726],{"id":13,"depth":272,"text":14},{"id":55,"depth":272,"text":56,"children":720},[721],{"id":116,"depth":283,"text":117},{"id":128,"depth":272,"text":129},{"id":170,"depth":272,"text":171},{"id":230,"depth":272,"text":231},{"id":628,"depth":272,"text":629},{"id":656,"depth":272,"text":656},"2026-09-22","K3s上のHPAでメトリクスは正常なのにレプリカ数が数分おきに増減する。原因はscaleUp\u002FscaleDownの非対称なデフォルト値とbehavior設計の不足。stabilizationWindowSecondsとCPU requestsを見直して振動を止める具体的な設定手順を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping",{"title":5,"description":728},"blog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping",[738,739,740,741,742,743],"k3s","kubernetes","scaling-policy","stabilization-window","replica-flapping","cpu-requests","NayxfAn4Uvp7WRlPFW77pEOgoX0Fuy3yMrZihTEukwI",[746,756,768,778,788,796],{"path":747,"title":748,"description":749,"date":750,"tags":751},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[738,739,752,753,754,755],"hpa","containerresource","autoscaling","service-mesh",{"path":757,"title":758,"description":759,"date":760,"tags":761},"\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",[738,739,762,763,764,765,766,767],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":769,"title":770,"description":771,"date":772,"tags":773},"\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",[738,739,774,775,776,777],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":779,"title":780,"description":781,"date":782,"tags":783},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[738,739,784,785,786,787],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":789,"title":790,"description":791,"date":792,"tags":793},"\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",[738,739,794,754,795],"vpa","cgroup",{"path":797,"title":798,"description":799,"date":800,"tags":801},"\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",[738,739,802,803,804,805],"pod-security-admission","pod-security-standards","servicelb","security",1792592606943]