[{"data":1,"prerenderedAt":884},["ShallowReactive",2],{"blog-ja-k3s-kubelet-eviction-inode-exhaustion-diskpressure":3,"blog-related-ja-k3s-kubelet-eviction-inode-exhaustion-diskpressure":827,"blog-ja-k3s-kubelet-eviction-inode-exhaustion-diskpressure-alt":405},{"id":4,"title":5,"author":6,"body":7,"date":810,"description":811,"extension":812,"image":813,"locale":814,"meta":815,"navigation":405,"path":816,"seo":817,"stem":818,"tags":819,"__hash__":826},"blog\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure.md","K3sでPodが次々Evictedされた。ディスクは余っているのにinodeだけ枯渇していた","Kubo Team",{"type":8,"value":9,"toc":790},"minimark",[10,18,38,54,62,68,83,107,111,126,130,136,149,247,264,268,278,281,289,295,304,496,504,508,531,544,548,554,568,581,590,594,600,603,606,614,699,703,722,725,746,753,756,766,772,786],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection01.webp",[11,19,20,21,25,26,29,30,33,34,37],{},"ある朝、K3sクラスタの複数ノードで突然Podが次々とEvictedされ始めた。",[22,23,24],"code",{},"kubectl get pod -A","を叩くと、",[22,27,28],{},"Evicted","の文字がずらりと並ぶ。真っ先に疑うのはディスク容量不足だ。ところが",[22,31,32],{},"df -h","を確認すると、どのノードも空き容量は十分にある。それでもノードは",[22,35,36],{},"DiskPressure","のままで、新しいPodをスケジュールできない。",[11,39,40,41,45,46,53],{},"この記事では、K3s\u002FKubernetes運用で見落とされがちな",[42,43,44],"strong",{},"kubeletのeviction manager","とinode枯渇の関係を、実際に起こりうるトラブルシュートの流れで解説する。ディスク容量（バイト）だけを監視していると、K3sのPodが次々Evictedされる本当の原因に気づけない。こうした「気づけないノードリソース枯渇」は、深夜のアラート対応を属人化させる典型パターンでもある。",[47,48,52],"a",{"href":49,"rel":50},"https:\u002F\u002Fkubo.hexabase.io\u002F",[51],"nofollow","Kubo","のようなマネージドK3s環境を検討している場合、この記事で解説する監視ポイントがそのまま判断材料になるはずだ。",[55,56,58,59,61],"h2",{"id":57},"_1-犯人はdf-hには映らないinodeというファイル作成能力の枯渇","1. 犯人は",[22,60,32],{},"には映らない。inodeという「ファイル作成能力」の枯渇",[11,63,64],{},[14,65],{"alt":66,"src":67},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection02.webp",[11,69,70,71,74,75,78,79,82],{},"Linuxのファイルシステムは、ディスク容量（バイト）とは別に",[42,72,73],{},"inode","という管理領域を持つ。inodeはファイルやディレクトリのメタデータ（所有者、パーミッション、データブロックの位置など）を記録する構造体で、ファイルを1つ作るたびに1つ消費される。ext4のようなファイルシステムは、フォーマット時に総容量から一定の比率（",[22,76,77],{},"inode_ratio","、デフォルト16384バイトにつき1inode）でinode総数を確保し、この数は",[42,80,81],{},"後から変更できない","。",[11,84,85,86,89,90,93,94,99,100,102,103,106],{},"つまり、大きなファイルを少数置いている分には余裕があっても、",[42,87,88],{},"小さなファイルを大量に作るワークロード","ではバイト容量より先にinodeが枯渇する。クラウドネイティブ技術の普及団体であるCNCFが2026年10月に公開した調査では、ある実クラスタでディスク使用率83%・inode使用率67%という状態から、Node.jsの",[22,91,92],{},"node_modules","ディレクトリ（1スナップショットあたり21,553ファイル）が複数のコンテナイメージレイヤーに重複して存在していたことが原因と特定されている（",[47,95,98],{"href":96,"rel":97},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F10\u002F05\u002Fkubelet-watches-inodes-just-not-until-its-an-emergency\u002F",[51],"CNCF blog","）。同記事の試算では、標準的なext4の",[22,101,77],{},"設定の場合、",[42,104,105],{},"ディスク使用率わずか25%の時点でinodeが枯渇しうる","という。",[108,109,110],"h3",{"id":110},"なぜ気づきにくいのか",[112,113,114,120,123],"ul",{},[115,116,117,119],"li",{},[22,118,32],{},"はバイト単位の空き容量しか表示しない",[115,121,122],{},"監視ダッシュボードの多くはディスク使用率（%）をバイトベースで集計している",[115,124,125],{},"ログ・キャッシュ・一時ファイルなど「小さなファイルが大量にできる」処理は普段意識されにくい",[55,127,129],{"id":128},"_2-kubeletが監視している6つのシグナルと効かない早期警戒","2. kubeletが監視している6つのシグナルと、効かない早期警戒",[11,131,132],{},[14,133],{"alt":134,"src":135},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection03.webp",[11,137,138,139,142,143,148],{},"Kubernetesの公式ドキュメントによると、kubeletはノードリソースの圧力を検知するために複数の",[42,140,141],{},"eviction signal","を監視している（",[47,144,147],{"href":145,"rel":146},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Fnode-pressure-eviction",[51],"Kubernetes公式: Node-pressure Eviction","）。ディスク・inode関連だけでも次の6シグナルが存在する。",[150,151,152,168],"table",{},[153,154,155],"thead",{},[156,157,158,162,165],"tr",{},[159,160,161],"th",{},"ファイルシステム",[159,163,164],{},"対象",[159,166,167],{},"シグナル",[169,170,171,185,197,210,222,235],"tbody",{},[156,172,173,177,180],{},[174,175,176],"td",{},"nodefs",[174,178,179],{},"ノード本体の容量",[174,181,182],{},[22,183,184],{},"nodefs.available",[156,186,187,189,192],{},[174,188,176],{},[174,190,191],{},"ノード本体のinode",[174,193,194],{},[22,195,196],{},"nodefs.inodesFree",[156,198,199,202,205],{},[174,200,201],{},"imagefs",[174,203,204],{},"イメージストアの容量",[174,206,207],{},[22,208,209],{},"imagefs.available",[156,211,212,214,217],{},[174,213,201],{},[174,215,216],{},"イメージストアのinode",[174,218,219],{},[22,220,221],{},"imagefs.inodesFree",[156,223,224,227,230],{},[174,225,226],{},"containerfs",[174,228,229],{},"書き込み層の容量",[174,231,232],{},[22,233,234],{},"containerfs.available",[156,236,237,239,242],{},[174,238,226],{},[174,240,241],{},"書き込み層のinode",[174,243,244],{},[22,245,246],{},"containerfs.inodesFree",[11,248,249,250,253,254,257,258,263],{},"クラウドネイティブ監視ツールを提供するNetdataの解説によれば、Linuxでのデフォルトのhard eviction閾値は、",[42,251,252],{},"nodefs: 利用可能容量10%未満・inode空き5%未満","、",[42,255,256],{},"imagefs: 利用可能容量15%未満・inode空き5%未満","とされている（",[47,259,262],{"href":260,"rel":261},"https:\u002F\u002Fwww.netdata.cloud\u002Fguides\u002Fkubernetes\u002Fkubernetes-node-disk-pressure\u002F",[51],"Netdata: Kubernetes node DiskPressure","）。",[108,265,267],{"id":266},"バイトには早期警戒があるのにinodeには無い","バイトには早期警戒があるのに、inodeには無い",[11,269,270,271,274,275,263],{},"ここに構造的なギャップがある。kubeletのイメージガベージコレクションは、imagefsの使用率が85%（高水位）に達した時点で不要イメージの削除を始め、80%（低水位）まで下げる、というバイトベースの早期介入が組み込まれている。ところがinodeについては、",[42,272,273],{},"hard eviction閾値の5%未満という一点のみ","が監視対象で、バイトのような段階的な早期警戒が存在しない。CNCFの記事はこれを「kubeletはinodeを監視してはいるが、緊急事態になるまで動かない」と評している（",[47,276,98],{"href":96,"rel":277},[51],[11,279,280],{},"K3sもこの仕組みを継承しているため、node_modulesのような小ファイル大量生成ワークロードを動かしているK3sクラスタでは、同じ落とし穴が発生しうる。",[55,282,284,285,288],{"id":283},"_3-df-iで診断しhard-evictionの恐さを理解する","3. ",[22,286,287],{},"df -i","で診断し、hard evictionの恐さを理解する",[11,290,291],{},[14,292],{"alt":293,"src":294},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection04.webp",[11,296,297,298,303],{},"実際にPodがEvictedされた際の調査手順は、Kubernetes向けオブザーバビリティを提供するOneUptimeの診断ガイドが具体的だ（",[47,299,302],{"href":300,"rel":301},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-08-27-diagnose-diskpressure-inode-evictions-ephemeral-storage\u002Fmarkdown",[51],"OneUptime: DiskPressure\u002FInode診断ガイド","）。要点は以下の通り。",[305,306,311],"pre",{"className":307,"code":308,"language":309,"meta":310,"style":310},"language-bash shiki shiki-themes tokyo-night","# Evicted Podの詳細確認\nkubectl describe pod \u003Cpod-name> -n \u003Cnamespace>\nkubectl get events -n \u003Cnamespace> --field-selector involvedObject.name=\u003Cpod-name>\n\n# 該当ノードのDiskPressure状態\nkubectl get node \u003Cnode-name> -o json | jq '.status.conditions[] | select(.type == \"DiskPressure\")'\n\n# ★ここが核心: バイトとinodeを両方確認する\ndf -h \u002F \u002Fvar\u002Flib\u002Fkubelet \u002Fvar\u002Flog\ndf -i \u002F \u002Fvar\u002Flib\u002Fkubelet \u002Fvar\u002Flog\n","bash","",[22,312,313,322,364,400,407,413,453,458,464,482],{"__ignoreMap":310},[314,315,318],"span",{"class":316,"line":317},"line",1,[314,319,321],{"class":320},"sbD-w","# Evicted Podの詳細確認\n",[314,323,325,329,333,336,340,343,347,350,354,356,359,361],{"class":316,"line":324},2,[314,326,328],{"class":327},"sE3pS","kubectl",[314,330,332],{"class":331},"sPY7s"," describe",[314,334,335],{"class":331}," pod",[314,337,339],{"class":338},"sAklC"," \u003C",[314,341,342],{"class":331},"pod-nam",[314,344,346],{"class":345},"sGX4V","e",[314,348,349],{"class":338},">",[314,351,353],{"class":352},"sT800"," -n",[314,355,339],{"class":338},[314,357,358],{"class":331},"namespac",[314,360,346],{"class":345},[314,362,363],{"class":338},">\n",[314,365,367,369,372,375,377,379,381,383,385,388,391,394,396,398],{"class":316,"line":366},3,[314,368,328],{"class":327},[314,370,371],{"class":331}," get",[314,373,374],{"class":331}," events",[314,376,353],{"class":352},[314,378,339],{"class":338},[314,380,358],{"class":331},[314,382,346],{"class":345},[314,384,349],{"class":338},[314,386,387],{"class":352}," --field-selector",[314,389,390],{"class":331}," involvedObject.name=",[314,392,393],{"class":338},"\u003C",[314,395,342],{"class":331},[314,397,346],{"class":345},[314,399,363],{"class":338},[314,401,403],{"class":316,"line":402},4,[314,404,406],{"emptyLinePlaceholder":405},true,"\n",[314,408,410],{"class":316,"line":409},5,[314,411,412],{"class":320},"# 該当ノードのDiskPressure状態\n",[314,414,416,418,420,423,425,428,430,432,435,438,441,444,447,450],{"class":316,"line":415},6,[314,417,328],{"class":327},[314,419,371],{"class":331},[314,421,422],{"class":331}," node",[314,424,339],{"class":338},[314,426,427],{"class":331},"node-nam",[314,429,346],{"class":345},[314,431,349],{"class":338},[314,433,434],{"class":352}," -o",[314,436,437],{"class":331}," json",[314,439,440],{"class":338}," |",[314,442,443],{"class":327}," jq",[314,445,446],{"class":338}," '",[314,448,449],{"class":331},".status.conditions[] | select(.type == \"DiskPressure\")",[314,451,452],{"class":338},"'\n",[314,454,456],{"class":316,"line":455},7,[314,457,406],{"emptyLinePlaceholder":405},[314,459,461],{"class":316,"line":460},8,[314,462,463],{"class":320},"# ★ここが核心: バイトとinodeを両方確認する\n",[314,465,467,470,473,476,479],{"class":316,"line":466},9,[314,468,469],{"class":327},"df",[314,471,472],{"class":352}," -h",[314,474,475],{"class":331}," \u002F",[314,477,478],{"class":331}," \u002Fvar\u002Flib\u002Fkubelet",[314,480,481],{"class":331}," \u002Fvar\u002Flog\n",[314,483,485,487,490,492,494],{"class":316,"line":484},10,[314,486,469],{"class":327},[314,488,489],{"class":352}," -i",[314,491,475],{"class":331},[314,493,478],{"class":331},[314,495,481],{"class":331},[11,497,498,500,501,503],{},[22,499,32],{},"では空き容量が十分あるのに",[22,502,287],{},"でinode使用率が100%近くになっていれば、原因はinode枯渇で確定だ。",[108,505,507],{"id":506},"hard-evictionの恐さ","Hard evictionの恐さ",[11,509,510,511,514,515,518,519,526,527,530],{},"Kubernetes公式ドキュメントが明記しているとおり、hard eviction thresholdを超えた場合、kubeletは",[42,512,513],{},"grace period 0秒","でPodを強制終了する。しかもこのnode-pressure evictionは、通常のAPI経由のeviction（",[22,516,517],{},"kubectl drain","等）とは異なり、",[42,520,521,522,525],{},"PodDisruptionBudgetもコンテナの",[22,523,524],{},"terminationGracePeriodSeconds","も一切尊重しない","（",[47,528,147],{"href":145,"rel":529},[51],"）。つまり、可用性を守るために設定したPDBがあっても、ノードリソース圧力の前では無力化される。これが「気づいたときには既に障害が広がっている」事態を招く理由だ。",[11,532,533,534,537,538,543],{},"さらに、Pod自身のephemeral-storage制限やemptyDirの",[22,535,536],{},"sizeLimit","を超過した場合も、Pod単位でevictionがトリガーされる（",[47,539,542],{"href":540,"rel":541},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fstorage\u002Fephemeral-storage\u002F",[51],"Kubernetes公式: Local ephemeral storage","）。ノード全体の圧力とPod単位の制限超過、2つの経路があることを理解しておく必要がある。",[55,545,547],{"id":546},"_4-k3scontainerdならではの落とし穴","4. K3s\u002Fcontainerdならではの落とし穴",[11,549,550],{},[14,551],{"alt":552,"src":553},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection05.webp",[11,555,556,557,560,561,564,565,263],{},"K3sはデフォルトでcontainerdをコンテナランタイムとして使用する。containerdはイメージレイヤーを",[22,558,559],{},"\u002Fvar\u002Flib\u002Fcontainerd\u002Fio.containerd.snapshotter.v1.overlayfs\u002Fsnapshots\u002F","配下に展開して管理しており、各番号付きディレクトリが1つのイメージレイヤーに対応する。CNCFの記事が指摘するように、node_modulesに限らずPythonの仮想環境、PHPのvendorディレクトリ、Rubyのgemなど、",[42,562,563],{},"大量の小ファイルで構成される依存関係","を含むイメージは同じ問題を起こしうる（",[47,566,98],{"href":96,"rel":567},[51],[11,569,570,571,574,575,580],{},"またK3sのGitHub issueでは、cgroup v2環境で",[22,572,573],{},"containerd-shim","が大量のinotifyインスタンスを生成し、「Too many open files」エラーが発生した事例も報告されている（",[47,576,579],{"href":577,"rel":578},"https:\u002F\u002Fgithub.com\u002Fk3s-io\u002Fk3s\u002Fissues\u002F10020",[51],"k3s-io\u002Fk3s Issue #10020","）。これはinodeそのものの枯渇とは別の問題だが、「ノードのファイル関連リソースが見えないところで枯渇する」という点で根は同じだ。ディスク容量・inode・ファイルディスクリプタの3つは、いずれも監視ダッシュボードの初期設定では見落とされやすい。",[11,582,583,584,589],{},"小規模なオンプレ\u002Fエッジ環境でK3sを運用している場合、ノード台数が少なく冗長性が低い分、1台のinode枯渇がクラスタ全体の可用性に直結しやすい点にも注意したい。データを外部に出せないオンプレ要件がある場合は、",[47,585,588],{"href":586,"rel":587},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[51],"Kubo On-Premise","のようにノード監視込みでAir-Gapped環境に展開できる選択肢もある。",[55,591,593],{"id":592},"_5-再発防止策マルチステージビルドログローテーション監視","5. 再発防止策——マルチステージビルド・ログローテーション・監視",[11,595,596],{},[14,597],{"alt":598,"src":599},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Fsection06.webp",[11,601,602],{},"inode枯渇によるEvictedを防ぐには、イメージ設計と監視の両面から対策する必要がある。",[108,604,605],{"id":605},"イメージを軽くする",[11,607,608,609,263],{},"Dockerの公式ドキュメントが解説するマルチステージビルドを使い、ビルド専用ステージと実行用ステージを分離すれば、node_modulesのような開発時依存関係を本番イメージから除外できる（",[47,610,613],{"href":611,"rel":612},"https:\u002F\u002Fdocs.docker.com\u002Fbuild\u002Fbuilding\u002Fmulti-stage\u002F",[51],"Docker公式: Multi-stage builds",[305,615,619],{"className":616,"code":617,"language":618,"meta":310,"style":310},"language-dockerfile shiki shiki-themes tokyo-night","# ビルドステージ\nFROM node:22 AS builder\nWORKDIR \u002Fapp\nCOPY package*.json .\u002F\nRUN npm ci\nCOPY . .\nRUN npm run build\n\n# 実行ステージ（node_modulesを含まない）\nFROM node:22-slim\nWORKDIR \u002Fapp\nCOPY --from=builder \u002Fapp\u002Fdist .\u002Fdist\nCOPY --from=builder \u002Fapp\u002Fpackage*.json .\u002F\nRUN npm ci --production\nCMD [\"node\", \"dist\u002Findex.js\"]\n","dockerfile",[22,620,621,626,631,636,641,646,651,656,660,665,670,675,681,687,693],{"__ignoreMap":310},[314,622,623],{"class":316,"line":317},[314,624,625],{},"# ビルドステージ\n",[314,627,628],{"class":316,"line":324},[314,629,630],{},"FROM node:22 AS builder\n",[314,632,633],{"class":316,"line":366},[314,634,635],{},"WORKDIR \u002Fapp\n",[314,637,638],{"class":316,"line":402},[314,639,640],{},"COPY package*.json .\u002F\n",[314,642,643],{"class":316,"line":409},[314,644,645],{},"RUN npm ci\n",[314,647,648],{"class":316,"line":415},[314,649,650],{},"COPY . .\n",[314,652,653],{"class":316,"line":455},[314,654,655],{},"RUN npm run build\n",[314,657,658],{"class":316,"line":460},[314,659,406],{"emptyLinePlaceholder":405},[314,661,662],{"class":316,"line":466},[314,663,664],{},"# 実行ステージ（node_modulesを含まない）\n",[314,666,667],{"class":316,"line":484},[314,668,669],{},"FROM node:22-slim\n",[314,671,673],{"class":316,"line":672},11,[314,674,635],{},[314,676,678],{"class":316,"line":677},12,[314,679,680],{},"COPY --from=builder \u002Fapp\u002Fdist .\u002Fdist\n",[314,682,684],{"class":316,"line":683},13,[314,685,686],{},"COPY --from=builder \u002Fapp\u002Fpackage*.json .\u002F\n",[314,688,690],{"class":316,"line":689},14,[314,691,692],{},"RUN npm ci --production\n",[314,694,696],{"class":316,"line":695},15,[314,697,698],{},"CMD [\"node\", \"dist\u002Findex.js\"]\n",[108,700,702],{"id":701},"ログとemptydirに上限を設ける","ログとemptyDirに上限を設ける",[112,704,705,716],{},[115,706,707,708,711,712,715],{},"コンテナログのローテーション: kubeletの",[22,709,710],{},"containerLogMaxSize","・",[22,713,714],{},"containerLogMaxFiles","を設定",[115,717,718,719,721],{},"emptyDirを使うPodには",[22,720,536],{},"を必ず指定し、無制限の小ファイル生成を防ぐ",[108,723,724],{"id":724},"監視とクリーンアップ",[112,726,727,733],{},[115,728,729,732],{},[22,730,731],{},"node_filesystem_files_free","のようなinode関連メトリクスを、バイト使用率とは別にアラート設定する（80%の時点で警戒するのが目安）",[115,734,735,736,739,740,745],{},"緊急時は",[22,737,738],{},"crictl rmi --prune","で未使用イメージを一括削除できる。ある事例ではディスク使用率71%から20%まで削減できたと報告されている（",[47,741,744],{"href":742,"rel":743},"https:\u002F\u002Fwww.virtualizationhowto.com\u002F2025\u002F04\u002Ffree-up-disk-space-in-your-kubernetes-cluster\u002F",[51],"virtualizationhowto.com: Kubernetesクラスタのディスク容量解放","）",[11,747,748,749,752],{},"これらの対策は単発のコマンドではなく、「ビルド時に小ファイルを持ち込まない」「運用中は上限とアラートで気づけるようにする」という2段構えの設計が肝になる。",[47,750,52],{"href":49,"rel":751},[51],"のようなマネージドK3s環境では、この手のノードリソース監視をCaptain UI上で可視化し、inode使用率を含めたアラートをあらかじめ組み込んだ状態で提供している。自前でPrometheusのアラートルールを設計・運用する手間を省きたい場合は検討の余地がある。",[55,754,755],{"id":755},"まとめ",[11,757,758,759,761,762,765],{},"K3s\u002FKubernetesの運用で「ディスクは余っているのにPodがEvictedされる」という現象に遭遇したら、まず疑うべきは",[22,760,32],{},"では見えないinode枯渇だ。kubeletはnodefs\u002Fimagefs\u002Fcontainerfsの計6シグナルを監視しているが、inodeに対してはバイトのような段階的な早期警戒が組み込まれておらず、hard evictionに達すると",[42,763,764],{},"PodDisruptionBudgetも無視して","Podを強制終了する。",[11,767,768,769,771],{},"K3sではcontainerdのoverlayfsスナップショットが小ファイル中心のイメージで肥大化しやすいため、マルチステージビルドでの依存関係除外、ログローテーション、emptyDirの",[22,770,536],{},"設定、inodeメトリクスの監視という対策を組み合わせておきたい。",[11,773,774,775,779,780,785],{},"こうしたノードリソースの可視化・監視を自前で構築する負荷が気になる場合は、",[47,776,778],{"href":49,"rel":777},[51],"Kubo Cloud","でのマネージド運用も選択肢になる。ディスク容量に加えてinode使用率までカバーした監視を、追加のPrometheus設計なしで利用できる。K3sベースでEKS\u002FAKS\u002FGKEと比べてもコスト効率よく、本格的なKubernetesの運用をそのまま継続できる点も検討材料になるはずだ。気になる場合は",[47,781,784],{"href":782,"rel":783},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[51],"お問い合わせ","から相談してみてほしい。",[787,788,789],"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 .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":310,"searchDepth":324,"depth":324,"links":791},[792,796,799,803,804,809],{"id":57,"depth":324,"text":793,"children":794},"1. 犯人はdf -hには映らない。inodeという「ファイル作成能力」の枯渇",[795],{"id":110,"depth":366,"text":110},{"id":128,"depth":324,"text":129,"children":797},[798],{"id":266,"depth":366,"text":267},{"id":283,"depth":324,"text":800,"children":801},"3. df -iで診断し、hard evictionの恐さを理解する",[802],{"id":506,"depth":366,"text":507},{"id":546,"depth":324,"text":547},{"id":592,"depth":324,"text":593,"children":805},[806,807,808],{"id":605,"depth":366,"text":605},{"id":701,"depth":366,"text":702},{"id":724,"depth":366,"text":724},{"id":755,"depth":324,"text":755},"2026-11-08","K3sでPodが次々Evictedされ、df -hは正常なのに復旧しない。原因はディスク容量ではなくinode枯渇だった。kubeletのeviction閾値とdf -iでの診断、再発防止策を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure\u002Ftitle.webp","ja",{},"\u002Fblog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure",{"title":5,"description":811},"blog\u002Fja\u002Fk3s-kubelet-eviction-inode-exhaustion-diskpressure",[820,821,822,823,824,825],"k3s","kubernetes","kubelet","eviction","diskpressure","troubleshooting","yqwtSTaeoyeGME56mUH1ZapblyW7U-DSMrF5qJBpXjs",[828,836,845,855,865,875],{"path":829,"title":830,"description":831,"date":832,"tags":833},"\u002Fblog\u002Fja\u002Fk3s-rootless-kubelet-user-namespace-k8s-137","KubeletInUserNamespaceがBetaになった日、K3sのRootless Modeは「時代遅れ」になったのか","Kubernetes 1.37でKubeletInUserNamespace(Rootless Mode)がBetaに昇格した。K3sは以前から独自のRootless Modeを持つが仕組みは全く別物だ。2つの方式の違いと、環境に応じた選び方を解説する。","2026-10-28",[820,821,834,835,822],"rootless","security",{"path":837,"title":838,"description":839,"date":840,"tags":841},"\u002Fblog\u002Fja\u002Fk3s-vpa-poddisruptionbudget-mass-eviction","K3sで自動リソース最適化を入れたら、全レプリカが同時に退避した。PodDisruptionBudgetという防波堤","K3sでリソース最適化ツールを有効化した直後、全レプリカが同時に退避され503が発生した実例をもとに、Podが一斉に退避されるメカニズムと、PodDisruptionBudgetのminAvailable設定による具体的な防御方法をエンジニア向けに詳しく解説する。","2026-09-18",[820,821,842,823,843,844],"poddisruptionbudget","vertical-scaling","resource-optimization",{"path":846,"title":847,"description":848,"date":849,"tags":850},"\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap","AIエージェントがKubernetes APIを叩いた後、何をしたのか追えなかった。Audit Logの設定に空いていた穴","AIエージェントをKubernetes上で動かし始めたら、トラブル発生時にAudit Logだけでは「誰が・何の目的で」操作したのか追えないことに気づいた。Audit Policyの盲点とトレーサビリティ確保の実践を解説する。","2026-11-09",[820,821,851,852,853,854],"ai-agent","audit-log","rbac","observability",{"path":856,"title":857,"description":858,"date":859,"tags":860},"\u002Fblog\u002Fja\u002Fk3s-cilium-kube-proxy-replacement-nodeport-unreachable","K3sでCiliumのkube-proxy置き換えをしたら、NodePortだけ繋がらなくなった","K3sにCiliumのkube-proxy replacementを公式手順通りに導入したら、NodePort経由の通信だけが届かなくなった。原因はFlannelやServiceLB(Klipper)との競合、k8sServiceHost未設定などK3s特有の設定差分にあった。本番投入前のチェックリストを解説。","2026-11-07",[820,821,861,862,863,864],"cilium","ebpf","kube-proxy","networking",{"path":866,"title":867,"description":868,"date":869,"tags":870},"\u002Fblog\u002Fja\u002Fk3s-memory-qos-cgroup-v2-memory-high-throttling","requestsもlimitsも正しいのに、K3sのPodが突然重くなった。犯人はOOMKillではなくcgroup v2のmemory.high早期スロットリングだった","K3sでrequests\u002Flimitsを正しく設定したPodが、OOMKilledイベントもなく突然重くなった謎を追った記録。原因はcgroup v2のmemory.highによる早期スロットリング。切り分け方法と対策を解説する。","2026-11-06",[820,821,871,872,873,874],"cgroup-v2","memory-qos","memory-high","resource-management",{"path":876,"title":877,"description":878,"date":879,"tags":880},"\u002Fblog\u002Fja\u002Fdocker-compose-k3s-local-path-provisioner-permission-denied","Docker Composeではそのまま動いていたボリュームが、K3sに持ち込んだ瞬間Permission deniedになった","Docker ComposeからK3sへ移行したら、ローカルでは問題なかったボリュームがPermission deniedになった。local-path-provisionerの仕様が原因。移行時の回避策を実例で解説。","2026-11-05",[820,821,881,882,883],"docker-compose","local-path-provisioner","persistent-storage",1794305484047]