[{"data":1,"prerenderedAt":468},["ShallowReactive",2],{"blog-ja-k3s-longhorn-storage-network-multus-replica-rebuild-stall":3,"blog-related-ja-k3s-longhorn-storage-network-multus-replica-rebuild-stall":407,"blog-ja-k3s-longhorn-storage-network-multus-replica-rebuild-stall-alt":395},{"id":4,"title":5,"author":6,"body":7,"date":389,"description":390,"extension":391,"image":392,"locale":393,"meta":394,"navigation":395,"path":396,"seo":397,"stem":398,"tags":399,"__hash__":406},"blog\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall.md","K3sノードを再起動したら、Longhornのレプリカ再構築が0%のまま静かに止まっていた。Storage Networkの起動順序という盲点","Kubo Team",{"type":8,"value":9,"toc":375},"minimark",[10,15,33,56,63,80,84,99,119,130,136,140,156,163,171,175,178,182,208,214,217,250,257,261,264,317,323,330,337,340,343,356,359],[11,12,14],"h2",{"id":13},"_1-症状-uiはrebuildingと言っているのにレプリカは0のまま動かない","1. 症状 — UIは「rebuilding」と言っているのに、レプリカは0%のまま動かない",[16,17,18,19,23,24,27,28,32],"p",{},"K3sクラスタでLonghornを使ってPersistentVolumeを運用している現場で、こんな経験はないだろうか。\n定期メンテナンスでノードを1台再起動した。しばらくしてLonghornのUIを見ると、対象ボリュームは\n",[20,21,22],"code",{},"degraded","のまま。詳細を開くと",[20,25,26],{},"rebuilding","と表示され、進んでいるように見える。だが数時間経っても\n",[29,30,31],"strong",{},"レプリカ再構築の進捗は0%から動かない","。",[16,34,35,36,39,40,43,44,51,52,55],{},"これは架空の話ではない。Longhornの上流プロジェクトであるHarvesterで、実際にこの症状が報告されている。\nあるノード再起動の直後、38個のボリュームが「attached\u002Fdegraded」のまま37時間も停滞し、\n",[20,37,38],{},"rebuildStatus","は",[20,41,42],{},"isRebuilding: true","を返し続けたという（",[45,46,50],"a",{"href":47,"rel":48},"https:\u002F\u002Fgithub.com\u002Fharvester\u002Fharvester\u002Fissues\u002F11639",[49],"nofollow","Harvester #11639","）。\nUIは「動いている」と主張するが、実態は無限ループで詰んでいる。ここが本記事で扱う",[29,53,54],{},"静かな障害","の正体だ。",[16,57,58],{},[59,60],"img",{"alt":61,"src":62},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall\u002Fsection01.webp",[16,64,65,66,69,70,73,74,79],{},"この手のトラブルが厄介なのは、アラートが上がりにくいことだ。ボリュームはまだ",[20,67,68],{},"attached","であり\nPodは動き続けている。",[29,71,72],{},"冗長性が失われているだけ","なので、次にもう1ノード落ちるまで誰も気づかない。\nK3s本番運用でLonghornを採用しているなら、レプリカ再構築が本当に進んでいるかを定期的に確認する\n仕組みが必要になる。この運用監視の負荷を自前で背負い込むか、",[45,75,78],{"href":76,"rel":77},"https:\u002F\u002Fkubo.hexabase.io\u002F",[49],"Kubo","のように\nモニタリングが標準搭載されたマネージドK3s基盤に任せるかは、検討する価値のある分岐点だ。",[11,81,83],{"id":82},"_2-原因-instance-managerがstorage-networkより1秒早く起動していた","2. 原因 — instance-managerがStorage Networkより1秒早く起動していた",[16,85,86,87,90,91,94,95,98],{},"Harvesterのバグ報告を詳しく見ると、原因は驚くほど狭い時間差にある。ノード再起動後、\nLonghornの",[20,88,89],{},"instance-manager","ポッドが起動した",[29,92,93],{},"わずか1秒後","に、ストレージ用ネットワークを\n提供する",[20,96,97],{},"rke2-multus","が準備完了した。この1秒のずれが致命傷になった。",[16,100,101,102,105,106,111,112,115,116,32],{},"Longhornは本番環境で、レプリケーション通信をKubernetesの通常CNIネットワークから分離するために\n",[29,103,104],{},"Storage Network","という機能を提供している。共有ネットワーク上でレプリケーション通信を流すと、\n他のPod通信と帯域を奪い合い、レイテンシが予測不能になるためだ（",[45,107,110],{"href":108,"rel":109},"https:\u002F\u002Flonghorn.io\u002Fdocs\u002F1.12.1\u002Fadvanced-resources\u002Fdeploy\u002Fstorage-network\u002F",[49],"Longhorn公式ドキュメント: Storage Network","）。\n実現方法はMultusによるセカンドネットワークの割り当てで、有効化するとLonghornの\ninstance-manager・backing-image-manager・backing-image-data-sourceの各Podに\n",[20,113,114],{},"k8s.v1.cni.cncf.io\u002Fnetworks","アノテーションが付与され、対象Podが",[29,117,118],{},"すべて再作成される",[16,120,121,122,125,126,129],{},"問題の1秒差では、instance-managerがストレージネットワークへの接続を要求したにもかかわらず、\nMultus側の",[20,123,124],{},"k8s.v1.cni.cncf.io\u002Fnetworks-status","アノテーションをまだ受け取れなかった。Longhornは\nアノテーションが見つからない場合にPodネットワークIPへフォールバックする実装になっており、\n結果として",[29,127,128],{},"ソースエンジンはストレージネットワークに、ターゲットレプリカはPodネットワークIPに","\nという経路の不一致が生まれた。これがレプリカ再構築が0%から進まなくなった直接の原因である。",[16,131,132],{},[59,133],{"alt":134,"src":135},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall\u002Fsection02.webp",[11,137,139],{"id":138},"_3-なぜこの1秒がクリティカルなのか-multusのバージョンによる仕様変化","3. なぜこの1秒がクリティカルなのか — Multusのバージョンによる仕様変化",[16,141,142,143,145,146,149,150,155],{},"さらに厄介なのは、この問題が単発のタイミング競合にとどまらないことだ。LonghornはStorage Networkの\n状態確認を、長らく",[20,144,124],{},"アノテーションに依存してきた。ところが\nMultusはv3.6でこのアノテーションを非推奨化し、",[29,147,148],{},"v4.0.0で完全に削除した","（",[45,151,154],{"href":152,"rel":153},"https:\u002F\u002Fgithub.com\u002Flonghorn\u002Flonghorn\u002Fissues\u002F6953",[49],"longhorn\u002Flonghorn #6953","）。\nMultusをアップグレードした構成では、起動タイミングの問題以前に、Longhorn自体がストレージ\nネットワークの状態を認識できなくなる。",[16,157,158,159,162],{},"つまり「レプリカ再構築が進まない」という同じ症状が、①起動順序の一時的な競合と、\n②Multusのバージョンに起因する恒常的な非互換、という",[29,160,161],{},"2つの異なる原因","から発生しうる。\nK3sクラスタでMultusを使ってStorage Networkを構成しているなら、Multusのバージョンと\nLonghornのバージョンの組み合わせを事前に確認しておく必要がある。",[16,164,165,166,170],{},"こうしたコンポーネント間のバージョン互換性を自前で追いかけ続けるのは地味に工数がかかる。\n",[45,167,169],{"href":76,"rel":168},[49],"Kubo Cloud","ならCNIやストレージ関連コンポーネントのバージョン\n整合性を含めて検証済みの構成で提供されるため、この種の「アップグレードしたら壊れた」を\n未然に減らせる。",[11,172,174],{"id":173},"_4-見落としがちな設計-レプリカ数とノードdrainの最後の健全レプリカ保護","4. 見落としがちな設計 — レプリカ数とノードdrainの「最後の健全レプリカ」保護",[16,176,177],{},"起動順序やネットワークの問題を回避できたとしても、レプリカ設計そのものに落とし穴が残っている。",[179,180,181],"h3",{"id":181},"レプリカ数は2か3か",[16,183,184,185,188,189,194,195,198,199,204,205,32],{},"Longhornのレプリカ数はデフォルトで3だが、本番クラスタのチューニングガイドでは\n",[29,186,187],{},"デフォルトを2に引き下げる","ことも提案されている。ディスク消費量と書き込みレイテンシを\n抑えられるためだ（",[45,190,193],{"href":191,"rel":192},"https:\u002F\u002Fcloudcasa.io\u002Fblog\u002Flonghorn-on-production-clusters-storage-configuration-tuning-and-gotchas\u002F",[49],"CloudCasa: Longhorn on Production Clusters","）。\n一方で別のベストプラクティスガイドは、レプリカ数2は1ノード障害まで、レプリカ数3は\n2ノード障害まで耐えられるとしており、",[29,196,197],{},"本番環境ではレプリカ数3を推奨","している\n（",[45,200,203],{"href":201,"rel":202},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-set-longhorn-volume-replica-count\u002Fview",[49],"OneUptime: How to Set Longhorn Volume Replica Count","）。\nどちらが正解かはワークロードの重要度次第だが、",[29,206,207],{},"両者の間にトレードオフがあることを知らずに\nデフォルト値のまま運用している現場は少なくない",[16,209,210],{},[59,211],{"alt":212,"src":213},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall\u002Fsection03.webp",[179,215,216],{"id":216},"ノードdrainが完了しない",[16,218,219,220,149,223,228,229,232,233,238,239,242,243,245,246,249],{},"もう一つの詰みポイントはノードメンテナンス時だ。ノードをcordonすると、Longhornは\nそのノードへの新規スケジューリングを自動的に無効化する。しかし",[29,221,222],{},"cordon時にレプリカを\n自動で退避させる機能は実装されていない",[45,224,227],{"href":225,"rel":226},"https:\u002F\u002Fgithub.com\u002Flonghorn\u002Flonghorn\u002Fdiscussions\u002F5736",[49],"longhorn\u002Flonghorn Discussion #5736","）。\nさらにdrainを実行した際、対象ノードにあるレプリカが",[29,230,231],{},"そのボリュームにとって最後の健全な\nレプリカ","だった場合、Longhornはデータ保護のためdrainの完了そのものをブロックする\n（",[45,234,237],{"href":235,"rel":236},"https:\u002F\u002Flonghorn.io\u002Fdocs\u002F1.12.1\u002Fmaintenance\u002Fmaintenance\u002F",[49],"Longhorn Node Maintenance Guide","）。\nこの状態になると、UIから手動でレプリカの退避を指示するか、Node Drain Policyを変更しない限り、\n",[20,240,241],{},"kubectl drain","はいつまでも終わらない。なお",[20,244,241],{},"には",[20,247,248],{},"--ignore-daemonsets","の指定が\n必須で、これを忘れるとLonghorn manager・CSI plugin・engine imageのDaemonSetによって\ndrainがそもそも開始できない。",[16,251,252,253,256],{},"メンテナンス手順を運用ドキュメントに落とし込み、チーム全員が同じ手順を踏めるようにするのは\n地味だが重要な仕事だ。",[45,254,169],{"href":76,"rel":255},[49],"のCaptain UIであれば、\nボリュームごとのレプリカ配置状況が可視化されているため、「どのノードが最後の健全レプリカを\n持っているか」を事前に確認しやすい。",[11,258,260],{"id":259},"_5-k3s本番運用でlonghornを安全に使うためのチェックリスト","5. K3s本番運用でLonghornを安全に使うためのチェックリスト",[16,262,263],{},"ここまでの障害パターンを踏まえ、K3s + Longhornを本番運用する前に確認すべき点を整理する。",[265,266,267,278,294,300,306],"ul",{},[268,269,270,273,274,277],"li",{},[29,271,272],{},"レプリカ再構築の進捗を監視する",": ",[20,275,276],{},"isRebuilding","だけでなく実際の進捗率をアラート条件に含める",[268,279,280,283,284,287,288,293],{},[29,281,282],{},"Storage Network導入前にMultusのバージョンを確認する",": v4.0.0以上では",[20,285,286],{},"networks-status","アノテーションが削除されている前提で検証する（",[45,289,292],{"href":290,"rel":291},"https:\u002F\u002Flonghorn.io\u002Fdocs\u002F1.12.1\u002Fadvanced-resources\u002Frebuilding\u002F",[49],"Longhorn Rebuilding docs","）",[268,295,296,299],{},[29,297,298],{},"レプリカ数はワークロードの重要度で決める",": デフォルト値のまま放置しない",[268,301,302,305],{},[29,303,304],{},"drain前に「最後の健全レプリカ」を確認する",": 事前にボリューム状態を棚卸しし、手動退避が必要なボリュームを洗い出す",[268,307,308,311,312,293],{},[29,309,310],{},"スナップショットの保持ポリシーを設定する",": 無制限に蓄積するとディスク枯渇からカスケード障害に発展しうる（",[45,313,316],{"href":314,"rel":315},"https:\u002F\u002Fperun.au\u002Finsights\u002Flonghorn-production",[49],"Perun Engineering: Longhorn in production, five failure patterns",[16,318,319],{},[59,320],{"alt":321,"src":322},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall\u002Fsection04.webp",[16,324,325,326,329],{},"これらはどれも単体では難しくない設定だが、",[29,327,328],{},"ノードの起動順序・CNIのバージョン・レプリカ設計・\nメンテナンス手順","という複数のレイヤーを横断して初めて事故が起きる。1つのレイヤーだけを\n見ていては再現も予防もできない、というのがこの障害の本質だ。",[16,331,332,333,336],{},"こうしたネットワーク分離やレプリカ設計をクラスタごとに手作業で見直し続けるのは、\n本来インフラチームがやりたい仕事だろうか。",[45,334,169],{"href":76,"rel":335},[49],"は\nK3sベースでRancher管理基盤とPrometheus\u002FGrafanaによるモニタリングを標準搭載しており、\nこうしたストレージ層の異常も可視化された管理画面から早期に検知しやすい構成になっている。",[11,338,339],{"id":339},"まとめ",[16,341,342],{},"Longhornのレプリカ再構築が0%のまま止まる問題は、単一の設定ミスではなく、\n「ノードの起動順序」「Multusのバージョン仕様変化」「レプリカ数設計」「drain時の保護機構」という\n複数の要因が重なって発生する。EKS\u002FAKSのマネージドストレージであればこうした\nコンポーネント間の起動順序やバージョン互換性はクラウドプロバイダー側の責任範囲になるが、\nセルフホストのK3s + Longhorn構成ではすべて自前で追いかける必要がある。",[16,344,345,346,349,350,355],{},"K3sの軽量さはそのままに、こうした運用の複雑さを引き受けたいと考えるなら、\n",[45,347,78],{"href":76,"rel":348},[49],"は月額48,000円からフルスペックのKubernetes環境を\nマネージドで提供している。ストレージ設計を含めた運用の負荷を減らしたい場合は、\n",[45,351,354],{"href":352,"rel":353},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[49],"お問い合わせ","から相談してみてほしい。",[16,357,358],{},"関連記事:",[265,360,361,368],{},[268,362,363],{},[45,364,367],{"href":365,"rel":366},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fk3s-local-path-provisioner-capacity-node-affinity-pvc-pending",[49],"K3sのPVCがPendingのまま戻ってこない。ローカルストレージの『容量無視』とノードアフィニティが起こす静かな詰み",[268,369,370],{},[45,371,374],{"href":372,"rel":373},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction",[49],"K3sで自動リソース最適化を入れたら、全レプリカが同時に退避した。PodDisruptionBudgetという防波堤",{"title":376,"searchDepth":377,"depth":377,"links":378},"",2,[379,380,381,382,387,388],{"id":13,"depth":377,"text":14},{"id":82,"depth":377,"text":83},{"id":138,"depth":377,"text":139},{"id":173,"depth":377,"text":174,"children":383},[384,386],{"id":181,"depth":385,"text":181},3,{"id":216,"depth":385,"text":216},{"id":259,"depth":377,"text":260},{"id":339,"depth":377,"text":339},"2026-09-23","K3sノードを再起動したらLonghornのレプリカ再構築が0%で止まっていた。実際のバグ報告からStorage Network(Multus)の起動順序、レプリカ数設計、ノードdrain時の詰みポイントを解説する","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall",{"title":5,"description":390},"blog\u002Fja\u002Fk3s-longhorn-storage-network-multus-replica-rebuild-stall",[400,401,402,403,404,405],"k3s","kubernetes","longhorn","storage-network","multus","persistent-storage","MNIDsX4j_1Czlaa3yzCn8mK9gMmOKm4QKGf0hSH636E",[408,418,430,440,450,458],{"path":409,"title":410,"description":411,"date":412,"tags":413},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[400,401,414,415,416,417],"hpa","containerresource","autoscaling","service-mesh",{"path":419,"title":420,"description":421,"date":422,"tags":423},"\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",[400,401,424,425,426,427,428,429],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":431,"title":432,"description":433,"date":434,"tags":435},"\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",[400,401,436,437,438,439],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":441,"title":442,"description":443,"date":444,"tags":445},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[400,401,446,447,448,449],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":451,"title":452,"description":453,"date":454,"tags":455},"\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",[400,401,456,416,457],"vpa","cgroup",{"path":459,"title":460,"description":461,"date":462,"tags":463},"\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",[400,401,464,465,466,467],"pod-security-admission","pod-security-standards","servicelb","security",1792592608607]