[{"data":1,"prerenderedAt":562},["ShallowReactive",2],{"blog-ja-k3s-proxmox-storage-expansion-sata-scsi-pitfall":3,"blog-related-ja-k3s-proxmox-storage-expansion-sata-scsi-pitfall":508,"blog-ja-k3s-proxmox-storage-expansion-sata-scsi-pitfall-alt":561},{"id":4,"title":5,"author":6,"body":7,"date":491,"description":492,"extension":493,"image":494,"locale":495,"meta":496,"navigation":202,"path":497,"seo":498,"stem":499,"tags":500,"__hash__":507},"blog\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall.md","Proxmoxのディスクを無停止で拡張したつもりが、K3sノードには反映されなかった。SATAコントローラという見落とし","Kubo Team",{"type":8,"value":9,"toc":482},"minimark",[10,15,23,31,34,45,49,55,84,98,136,143,148,286,289,293,299,308,316,342,349,353,359,362,375,396,403,415,419,425,428,453,456,469,478],[11,12,14],"h2",{"id":13},"その夜ディスク使用率は99を超えていた","その夜、ディスク使用率は99%を超えていた",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Fsection01.webp",[16,24,25,26,30],{},"監視ダッシュボードのディスク使用率が99%に張り付いている。K3sの",[27,28,29],"code",{},"local-path-provisioner","が使うボリュームか、それともコンテナイメージのキャッシュか。原因はどうあれ、やることは一つしかない。Proxmoxのストレージを拡張することだ。",[16,32,33],{},"Proxmox VEでのストレージ拡張は、公式ドキュメントを読む限り単純な作業に見える。VMを止めずにディスクを大きくし、ゲストOS側でファイルシステムを広げるだけだ。しかし本番のK3sクラスタでこの作業をやったことがあるエンジニアなら、「拡張したはずなのに反映されない」という経験に心当たりがあるはずだ。",[16,35,36,37,44],{},"この記事では、Proxmoxで本番運用中のK3s\u002FKuboクラスタのストレージを拡張する際に実際に起きる落とし穴と、単一VMでは足りない場合にCephで無停止拡張する方法、そしてその作業がK3sのetcd(クォーラム)に与える影響までを、公式ドキュメントのレベルで具体的に整理する。こうした運用の細部を自社で背負うか、",[38,39,43],"a",{"href":40,"rel":41},"https:\u002F\u002Fkubo.hexabase.io\u002F",[42],"nofollow","Kubo","のようなマネージドK3s基盤に任せるかは、後述する落とし穴の深さを知ってから判断しても遅くない。",[11,46,48],{"id":47},"無停止で拡張できるはずが裏切られた理由-コントローラという見落とし","「無停止で拡張できるはず」が裏切られた理由 — コントローラという見落とし",[16,50,51],{},[19,52],{"alt":53,"src":54},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Fsection02.webp",[16,56,57,58,63,64,67,68,71,72,75,76,79,80,83],{},"Proxmoxの",[38,59,62],{"href":60,"rel":61},"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FResize_disks",[42],"公式Wiki","が示すディスク拡張手順自体はシンプルだ。",[27,65,66],{},"qm resize","コマンド、またはGUIの Hardware > Hard Disk > Disk Action > Resize でディスクサイズを変更し、ゲスト側で",[27,69,70],{},"parted","によるパーティション拡張、その後",[27,73,74],{},"pvresize","\u002F",[27,77,78],{},"lvresize","（LVM構成の場合）や",[27,81,82],{},"resize2fs","でファイルシステムを広げる、という3段階だ。",[16,85,86,87,91,92,97],{},"ところがこの手順がすんなり通るかどうかは、",[88,89,90],"strong",{},"VMにアタッチされているディスクコントローラの種類","に左右される。",[38,93,96],{"href":94,"rel":95},"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FQemu\u002FKVM_Virtual_Machines",[42],"Proxmox公式ドキュメントのQEMU\u002FKVM仮想マシンの章","では、ディスクコントローラとしてIDE・SATA・SCSI・VirtIO Blockの4種類が説明されているが、パフォーマンスと機能面で推奨されているのは一貫して「VirtIO SCSI single」タイプのSCSIコントローラだ。IDEは1984年設計、SATAも2003年設計と、いずれも古い規格をベースにしており、Proxmox VE 7.3以降でLinux VMの新規作成時にデフォルトになっているのもVirtIO SCSI singleである。",[16,99,100,108,109,112,113,116,117,116,120,116,123,116,126,116,129,132,133,135],{},[38,101,104,107],{"href":102,"rel":103},"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FManual:_qm.conf",[42],[27,105,106],{},"qm.conf","のマニュアル","を見ると、",[27,110,111],{},"scsihw","パラメータには",[27,114,115],{},"lsi","・",[27,118,119],{},"lsi53c810",[27,121,122],{},"megasas",[27,124,125],{},"pvscsi",[27,127,128],{},"virtio-scsi-pci",[27,130,131],{},"virtio-scsi-single","が指定できるが、パフォーマンスを重視するならIO Threadを有効にした",[27,134,131],{},"が推奨されている。古い構成のまま残っているVM、あるいは他のハイパーバイザーからP2V移行してきたVMでは、意識しないままSATAやIDEコントローラが使われ続けているケースが少なくない。",[16,137,138,139,142],{},"拡張作業に入る前に、対象のK3sノードVMがどのコントローラ種別を使っているかを",[27,140,141],{},"qm config \u003Cvmid>","で必ず確認すること。もしSATAやIDEであれば、ディスクの拡張よりも先に、VMを一度停止してコントローラをSCSI(VirtIO SCSI single)に変更する作業が必要になる。つまり「無停止で拡張するはずだった作業」に、想定外の再起動が挟まることになる。",[144,145,147],"h3",{"id":146},"正しい拡張手順-qm-resizeからファイルシステムまで","正しい拡張手順 — qm resizeからファイルシステムまで",[149,150,155],"pre",{"className":151,"code":152,"language":153,"meta":154,"style":154},"language-bash shiki shiki-themes tokyo-night","# 1. Proxmoxホスト側でディスクを拡張(VM実行中でも可、SCSI\u002FVirtIOコントローラの場合)\nqm resize \u003Cvmid> scsi0 +50G\n\n# 2. ゲストOS内でパーティションを拡張(parted)\nparted \u002Fdev\u002Fsda ---pretend-input-tty resizepart 1 100%\n\n# 3a. LVM構成の場合: 物理ボリューム→論理ボリューム→ファイルシステムを一括拡張\npvresize \u002Fdev\u002Fsda1\nlvresize --extents +100%FREE --resizefs \u002Fdev\u002Fmapper\u002Fvg-root\n\n# 3b. LVMなしの場合: ファイルシステムを直接拡張\nresize2fs \u002Fdev\u002Fsda1\n","bash","",[27,156,157,166,197,204,210,232,237,243,251,268,273,279],{"__ignoreMap":154},[158,159,162],"span",{"class":160,"line":161},"line",1,[158,163,165],{"class":164},"sbD-w","# 1. Proxmoxホスト側でディスクを拡張(VM実行中でも可、SCSI\u002FVirtIOコントローラの場合)\n",[158,167,169,173,177,181,184,188,191,194],{"class":160,"line":168},2,[158,170,172],{"class":171},"sE3pS","qm",[158,174,176],{"class":175},"sPY7s"," resize",[158,178,180],{"class":179},"sAklC"," \u003C",[158,182,183],{"class":175},"vmi",[158,185,187],{"class":186},"sGX4V","d",[158,189,190],{"class":179},">",[158,192,193],{"class":175}," scsi0",[158,195,196],{"class":175}," +50G\n",[158,198,200],{"class":160,"line":199},3,[158,201,203],{"emptyLinePlaceholder":202},true,"\n",[158,205,207],{"class":160,"line":206},4,[158,208,209],{"class":164},"# 2. ゲストOS内でパーティションを拡張(parted)\n",[158,211,213,215,218,222,225,229],{"class":160,"line":212},5,[158,214,70],{"class":171},[158,216,217],{"class":175}," \u002Fdev\u002Fsda",[158,219,221],{"class":220},"sT800"," ---pretend-input-tty",[158,223,224],{"class":175}," resizepart",[158,226,228],{"class":227},"sOJ5S"," 1",[158,230,231],{"class":175}," 100%\n",[158,233,235],{"class":160,"line":234},6,[158,236,203],{"emptyLinePlaceholder":202},[158,238,240],{"class":160,"line":239},7,[158,241,242],{"class":164},"# 3a. LVM構成の場合: 物理ボリューム→論理ボリューム→ファイルシステムを一括拡張\n",[158,244,246,248],{"class":160,"line":245},8,[158,247,74],{"class":171},[158,249,250],{"class":175}," \u002Fdev\u002Fsda1\n",[158,252,254,256,259,262,265],{"class":160,"line":253},9,[158,255,78],{"class":171},[158,257,258],{"class":220}," --extents",[158,260,261],{"class":175}," +100%FREE",[158,263,264],{"class":220}," --resizefs",[158,266,267],{"class":175}," \u002Fdev\u002Fmapper\u002Fvg-root\n",[158,269,271],{"class":160,"line":270},10,[158,272,203],{"emptyLinePlaceholder":202},[158,274,276],{"class":160,"line":275},11,[158,277,278],{"class":164},"# 3b. LVMなしの場合: ファイルシステムを直接拡張\n",[158,280,282,284],{"class":160,"line":281},12,[158,283,82],{"class":171},[158,285,250],{"class":175},[16,287,288],{},"ディスクの縮小はサポートされていないため、あらかじめファイルシステムとパーティションのサイズを小さくしてからでないと縮小できない点にも注意したい。",[11,290,292],{"id":291},"ノード単位では足りない時-cephで無停止にディスクノードを足す","ノード単位では足りない時 — Cephで無停止にディスク\u002Fノードを足す",[16,294,295],{},[19,296],{"alt":297,"src":298},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Fsection03.webp",[16,300,301,302,307],{},"単一VMのディスク拡張では追いつかないほど容量が逼迫している場合、選択肢になるのがCephによるストレージプールの拡張だ。Proxmoxは",[38,303,306],{"href":304,"rel":305},"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FDeploy_Hyper-Converged_Ceph_Cluster",[42],"Hyper-Converged Ceph Cluster","としてCephをネイティブに統合しており、稼働中のクラスタにノードやOSD(Object Storage Daemon、物理ディスク1台に対応)を追加できる。",[16,309,310,315],{},[38,311,314],{"href":312,"rel":313},"https:\u002F\u002Fdocs.ceph.com\u002Fen\u002Flatest\u002Frados\u002Foperations\u002Fadd-or-rm-osds\u002F",[42],"Ceph公式ドキュメント","が示す手順は、新規OSDの作成・メタデータディレクトリの初期化・認証キーの登録・CRUSHマップへの追加という流れになる。Proxmoxの管理画面からであれば、対象ノードでディスクを選び「Ceph → OSD → Create」を実行するだけで、この一連の処理がGUI越しに実行される。",[16,317,318,319,322,323,326,327,329,330,333,334,337,338,341],{},"OSDを追加すると、Cephは自動的にデータの再配置(リバランス)を開始する。Ceph公式ドキュメントによれば、この間プレースメントグループ(PG)の状態は",[27,320,321],{},"active+clean","から",[27,324,325],{},"active, some degraded","のような一時的な状態に遷移し、リバランス完了後に",[27,328,321],{},"へ戻る。この進捗は",[27,331,332],{},"ceph -w","や",[27,335,336],{},"watch ceph status","で監視できる。重要なのは、",[88,339,340],{},"このリバランス中も既存のK3sノードVMは通常どおり稼働を継続できる","という点だ。単一ディスクの容量が尽きた時とは異なり、クラスタ全体としての無停止性を維持できるのがCephの最大の利点である。",[16,343,344,345,348],{},"ただしCeph公式ドキュメントは、クラスタが",[27,346,347],{},"full ratio","(デフォルトで容量の95%程度)に達する前に拡張作業を始めるよう強く警告している。容量が逼迫しきってからOSDを追加しようとすると、リバランス自体がI\u002FO帯域を圧迫し、状況を悪化させかねない。",[11,350,352],{"id":351},"拡張中k3sのetcdは何を見ているか","拡張中、K3sのetcdは何を見ているか",[16,354,355],{},[19,356],{"alt":357,"src":358},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Fsection04.webp",[16,360,361],{},"ここまでの手順は、Proxmoxホスト・Cephクラスタというインフラ層の話だった。しかし本番のK3sクラスタをHA(High Availability)構成で運用している場合、ストレージ拡張作業はもう一段上のレイヤー、つまりK3sのコントロールプレーンにも影響しうる。",[16,363,364,365,368,369,374],{},"K3sのHA構成では、既定でSQLiteではなく",[88,366,367],{},"embedded etcd","がデータストアとして使われる。",[38,370,373],{"href":371,"rel":372},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore\u002Fha-embedded",[42],"K3s公式ドキュメント","は、HA embedded etcdクラスタは奇数個のサーバーノード(最低3台)で構成する必要があり、クォーラム(過半数合意)を維持するにはn台中n\u002F2+1台が生きている必要があると説明している。同ドキュメントは「Raspberry PiのSDカードのような低速ディスクでは、embedded etcd(HA)がパフォーマンス問題を起こすことがある」とも明記しており、ディスク性能への感度の高さを裏付けている。",[16,376,377,378,383,384,389,390,395],{},"この感度の根拠は、etcdそのものの設計にある。",[38,379,382],{"href":380,"rel":381},"https:\u002F\u002Fetcd.io\u002Fdocs\u002Fv3.3\u002Fop-guide\u002Fhardware\u002F",[42],"etcd公式のハードウェア推奨事項","では、負荷の高いクラスタではローカルSSD相当の500 IOPS以上のシーケンシャル書き込み性能が推奨されており、「書き込みが遅すぎるとハートビートがタイムアウトし、選挙が発生してクラスタの安定性が損なわれる」と警告されている。",[38,385,388],{"href":386,"rel":387},"https:\u002F\u002Fv1-34.docs.kubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fconfigure-upgrade-etcd",[42],"Kubernetes公式ドキュメント","も同様に、etcdはネットワークとディスクI\u002FOの両方に敏感であり、リソース枯渇がハートビートタイムアウトとクラスタ不安定化につながると警告している。",[38,391,394],{"href":392,"rel":393},"https:\u002F\u002Fetcd.io\u002Fdocs\u002Fv3.4\u002Ffaq\u002F",[42],"etcd公式FAQ","が示す目安は明確で、fsync遅延の99パーセンタイル値が10ms未満であることが安定運用の条件とされている。",[16,397,398,399,402],{},"つまり、Cephのリバランスやディスクコントローラ変更のためのVM再起動といった作業中は、embedded etcdを動かしているサーバーノードのディスクI\u002FOが一時的に競合し、fsyncレイテンシが跳ね上がるリスクがある。レイテンシがしきい値を超えれば、ネットワーク的には正常でもリーダーが「実質的に到達不能」と判定され、新しいリーダー選挙が発生しうる。拡張作業そのものは無停止でも、",[88,400,401],{},"その裏でK3sのコントロールプレーンが不安定化する","という間接的な影響が起こりうるということだ。",[16,404,405,406,409,410,414],{},"対策としては、embedded etcdを持つサーバーノードから作業を始めない、拡張作業中は",[27,407,408],{},"etcd_disk_wal_fsync_duration_seconds","相当の指標(Prometheusで収集している場合)を監視する、可能であればetcdのデータディレクトリだけは専用の高速ディスクに分離しておく、といった対応が有効だ。",[38,411,413],{"href":40,"rel":412},[42],"Kubo Cloud","はPrometheus+Grafanaを標準搭載しており、こうしたetcdクォーラムの健全性監視をゼロから構築せずに始められる。",[11,416,418],{"id":417},"まとめ-拡張前にチェックすべき3点","まとめ — 拡張前にチェックすべき3点",[16,420,421],{},[19,422],{"alt":423,"src":424},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Fsection05.webp",[16,426,427],{},"Proxmox上でK3s\u002FKuboクラスタのストレージ容量が逼迫した時、慌てて拡張作業に入る前に確認しておきたいのは次の3点だ。",[429,430,431,441,447],"ul",{},[432,433,434,437,438,440],"li",{},[88,435,436],{},"ディスクコントローラはSCSI(VirtIO SCSI single)か",": ",[27,439,141],{},"で確認し、SATA\u002FIDEであれば先にコントローラ変更(要停止)を計画する",[432,442,443,446],{},[88,444,445],{},"ノード単位かクラスタ全体かで手段を選ぶ",": 単一VMのディスク拡張で足りるのか、Cephでのノード\u002FOSD追加が必要な規模なのかを見極める",[432,448,449,452],{},[88,450,451],{},"拡張作業中はetcdのfsyncレイテンシを監視する",": embedded etcdを使うHA構成では、ディスクI\u002FO競合がコントロールプレーンの安定性に波及しうる",[16,454,455],{},"こうした「本番運用中の落とし穴」は、Proxmoxひとつ、K3sひとつを個別に見ていても気づきにくい。インフラ層とコントロールプレーン層の両方を横断して設計・監視する体制が必要になる。",[16,457,458,463,464,468],{},[38,459,462],{"href":460,"rel":461},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[42],"Kubo On-Premise","は、Proxmoxのような自社インフラ上でK3sベースのフルマネージドKubernetesを構築できるサービスだ。ディスクコントローラの選定からetcdクォーラムの監視まで、こうした運用の細部をKuboの標準構成が引き受ける。データを外に出せない金融・医療・製造業の現場でも、",[38,465,467],{"href":460,"rel":466},[42],"Air-Gapped環境","での完全自社管理が可能になる。",[16,470,471,472,477],{},"ストレージ拡張のたびに「今回もちゃんと反映されるか」と冷や汗をかく運用から抜け出したいなら、",[38,473,476],{"href":474,"rel":475},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[42],"お問い合わせ","からKubo On-Premiseの無料相談を検討してみてほしい。EKS\u002FAKSのようなクラウド依存のマネージドK8sとは異なり、自社ハードウェアの上でフルマネージドの運用体験を実現できる。",[479,480,481],"style",{},"html pre.shiki code .sbD-w, html code.shiki .sbD-w{--shiki-default:#51597D;--shiki-default-font-style:italic}html pre.shiki code .sE3pS, html code.shiki .sE3pS{--shiki-default:#C0CAF5}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sGX4V, html code.shiki .sGX4V{--shiki-default:#A9B1D6}html pre.shiki code .sT800, html code.shiki .sT800{--shiki-default:#E0AF68}html pre.shiki code .sOJ5S, html code.shiki .sOJ5S{--shiki-default:#FF9E64}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":168,"depth":168,"links":483},[484,485,488,489,490],{"id":13,"depth":168,"text":14},{"id":47,"depth":168,"text":48,"children":486},[487],{"id":146,"depth":199,"text":147},{"id":291,"depth":168,"text":292},{"id":351,"depth":168,"text":352},{"id":417,"depth":168,"text":418},"2026-09-17","Proxmoxで本番運用中のK3sクラスタのストレージが逼迫した時、無停止で拡張したつもりが反映されない典型的な原因(ディスクコントローラ設定)と、CephでOSDを追加する際にK3sのetcdクォーラムが受ける影響、公式ドキュメントに基づく正しい拡張手順を具体的に解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall\u002Ftitle.webp","ja",{},"\u002Fblog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall",{"title":5,"description":492},"blog\u002Fja\u002Fk3s-proxmox-storage-expansion-sata-scsi-pitfall",[501,502,503,504,505,506],"k3s","kubernetes","proxmox","storage","ceph","etcd","LI2Eb5gS9qnK2Sx7e1jARo-bgVHlD7EKS1gz4TcZN3g",[509,517,524,532,541,551],{"path":510,"title":511,"description":512,"date":513,"tags":514},"\u002Fblog\u002Fja\u002Fk3s-proxmox-live-migration-etcd-quorum-affinity-design","Proxmoxのライブマイグレーションで、K3sのetcdクォーラムが静かに崩れる。仮想化とRaftが衝突する設計","Proxmox上のK3sコントロールプレーンVMをライブマイグレーションした際にetcdクォーラムが崩れる仕組みを、heartbeat\u002Felection-timeoutとProxmoxのaffinity設計から解説。実運用で使える具体的な対策手順を紹介する。","2026-09-09",[501,502,503,506,515,516],"live-migration","high-availability",{"path":518,"title":519,"description":520,"date":521,"tags":522},"\u002Fblog\u002Fja\u002Fk3s-kubeadm-ha-etcd-failover-rto-gap","RTO30秒のはずが3分止まった。K3sとkubeadmのHA構成で\"カタログ値\"と\"実運用\"がズレる理由","K3sのembedded etcdとkubeadmのstacked\u002Fexternal etcd、HA構成のフェイルオーバーは実際どれだけ時間がかかるのか。公式ドキュメントのRTO目安と実運用の体感時間のギャップを、障害ドメインの分離・必要ノード数の違いから検証する。","2026-10-09",[501,502,506,516,523],"kubeadm",{"path":525,"title":526,"description":527,"date":528,"tags":529},"\u002Fblog\u002Fja\u002Fk3s-etcd-snapshot-restore-token-cluster-reset-pitfalls","自動etcdスナップショットは毎日取れていた。K3sのリストアが本番障害で動かなかった理由","K3sのetcdスナップショットは正常に取れていたのに、本番障害でリストアが失敗した——トークン管理、S3リストア事故、cluster-resetの落とし穴という3つの実例から、embedded etcdバックアップの本当のリスクを解説する。","2026-09-21",[501,502,506,530,531,516],"backup-restore","disaster-recovery",{"path":533,"title":534,"description":535,"date":536,"tags":537},"\u002Fblog\u002Fja\u002Fk3s-local-path-provisioner-capacity-node-affinity-pvc-pending","K3sのPVCがPendingのまま戻ってこない。ローカルストレージの『容量無視』とノードアフィニティが起こす静かな詰み","K3sのPVCがPending状態から戻らない原因は、local-path-provisionerが容量制限を無視する設計にある。ハイパーバイザーのthin provisioning、Volume Node Affinity Conflict、バックアップの誤解まで、K3sのローカルストレージ設計の落とし穴を解説する。","2026-09-12",[501,502,504,29,538,539,540],"persistent-volume","node-affinity","zfs",{"path":542,"title":543,"description":544,"date":545,"tags":546},"\u002Fblog\u002Fja\u002Fk3s-on-proxmox-cluster","Proxmox 上に K3s クラスタを構築する: ステップバイステップ","Proxmox VE 上に K3s 軽量 Kubernetes クラスタを構築する完全手順。VM テンプレート作成から HA 構成、ストレージ、Ingress 設定まで網羅。","2026-05-27",[501,502,503,547,548,549,550],"セルフホスティング","コンテナ","クラスタ構築","devops",{"path":552,"title":553,"description":554,"date":555,"tags":556},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[501,502,557,558,559,560],"hpa","containerresource","autoscaling","service-mesh",false,1792592610417]