[{"data":1,"prerenderedAt":380},["ShallowReactive",2],{"blog-ja-k3s-kubeadm-memory-benchmark-datastore-comparison":3,"blog-related-ja-k3s-kubeadm-memory-benchmark-datastore-comparison":321,"blog-ja-k3s-kubeadm-memory-benchmark-datastore-comparison-alt":308},{"id":4,"title":5,"author":6,"body":7,"date":302,"description":303,"extension":304,"image":305,"locale":306,"meta":307,"navigation":308,"path":309,"seo":310,"stem":311,"tags":312,"__hash__":320},"blog\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison.md","「K3sは軽い」は本当か。Kubernetes標準(kubeadm)とメモリ使用量を実測したら、結果が割れた","Kubo Team",{"type":8,"value":9,"toc":291},"minimark",[10,15,23,26,34,49,53,59,68,71,78,82,88,97,106,120,128,132,138,147,154,161,165,171,180,193,205,209,215,218,240,255,262,265,272],[11,12,14],"h2",{"id":13},"_1-k3sは軽いという前提を一度疑ってみる","1. 「K3sは軽い」という前提を、一度疑ってみる",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection01.webp",[16,24,25],{},"K3sを選ぶ理由として最初に挙がるのは、ほぼ例外なく「軽量だから」だ。公式サイトも「lightweight Kubernetes」を謳い、エッジやIoT、開発環境での採用事例の多くがこの軽さを根拠にしている。",[16,27,28,29,33],{},"ところが、K3sとKubernetes標準構成（kubeadmで構築するクラスタ）のメモリ使用量を比較した複数の実測データを横断して読むと、話はそれほど単純ではない。測定条件によっては、K3sの方が標準Kubernetesより",[30,31,32],"strong",{},"重い","という結果すら報告されている。",[16,35,36,37,40,41,48],{},"本記事では、K3s公式のリソースプロファイリングデータと、独立した第三者のベンチマーク結果を突き合わせ、「K3s vs Kubernetes(kubeadm)」のメモリ・CPU使用量比較を",[30,38,39],{},"条件別に","整理する。K3s\u002FKubernetesの技術選定に関わるインフラエンジニア・SREが、自分の環境に当てはめて判断できることを目指す（こうした選定・チューニングの負荷そのものを下げたいなら、",[42,43,47],"a",{"href":44,"rel":45},"https:\u002F\u002Fkubo.hexabase.io\u002F",[46],"nofollow","Kubo","のようなマネージドK3sという選択肢もある）。",[11,50,52],{"id":51},"_2-k3s公式のリソースプロファイリングを読む","2. K3s公式のリソースプロファイリングを読む",[16,54,55],{},[19,56],{"alt":57,"src":58},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection02.webp",[16,60,61,62,67],{},"まず一次情報として、",[42,63,66],{"href":64,"rel":65},"https:\u002F\u002Fdocs.k3s.io\u002Freference\u002Fresource-profiling",[46],"K3s公式のResource Profilingドキュメント","を確認する。このドキュメントはPrometheusによる定常状態の95パーセンタイル値を測定しており、曖昧な「〜MB程度」ではなく再現可能な数値を提示している点で信頼性が高い。",[16,69,70],{},"測定環境はAWS c6id.xlarge（8GB RAM）とRaspberry Pi 4Bの2系統。ワークロードを乗せたサーバーノード単体では、Kine\u002FSQLite構成でIntel環境約1.6GB、Pi4B環境約1.59GB、embedded etcd構成でもほぼ同水準（Intel約1.61GB、Pi4B約1.61GB）という結果だ。一方でエージェントノード単体は両構成ともおよそ275MB前後に収まっている。",[16,72,73,74,77],{},"つまり公式データが示すのは、",[30,75,76],{},"データストアの選択（etcd\u002FSQLite）がメモリ使用量そのものを大きく左右するわけではなく、むしろディスクI\u002FOの要求値（IOPSやレイテンシ）に差が出る","、という点だ。この構図は次のセクションでより詳しく見ていく。",[11,79,81],{"id":80},"_3-データストア選択embedded-etcd-vs-sqliteが本当に左右するもの","3. データストア選択(embedded etcd vs SQLite)が本当に左右するもの",[16,83,84],{},[19,85],{"alt":86,"src":87},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection03.webp",[16,89,90,91,96],{},"K3sはデフォルトでetcdの代わりにSQLiteを採用しており、この設計がバイナリサイズとシンプルさに大きく寄与している（",[42,92,95],{"href":93,"rel":94},"https:\u002F\u002Fwww.suse.com\u002Fc\u002Francher_blog\u002Fintroduction-to-k3s-2\u002F",[46],"SUSE\u002FRancher公式ブログ","によれば、K3s本体は54MBのシングルバイナリにcontainerd・Flannel・CoreDNS・Traefikまで同梱されている）。",[16,98,99,100,105],{},"単一ノード環境でのデータストア別オーバーヘッドを検証した",[42,101,104],{"href":102,"rel":103},"https:\u002F\u002Fwww.bigiron.cc\u002Fguides\u002Fk3s-single-node-with-embedded-etcd-vs-sqlite",[46],"Big Ironの比較ガイド","によると、SQLite（kine経由）のオーバーヘッドは約50〜80MBとほぼ無視できる水準である一方、embedded etcdはアイドル状態でも300〜500MB、Secret数やCRD数、watch接続数が増えるビジーなクラスタでは1〜2GBに達することがあるという。",[16,107,108,109,114,115,119],{},"この差は、8GB RAM程度の環境では無視できない割合になる。",[42,110,113],{"href":111,"rel":112},"https:\u002F\u002Fdocs.k3s.io\u002Fdatastore\u002Fha-embedded",[46],"K3s公式のHA構成ドキュメント","でも、既存のSQLiteクラスタは",[116,117,118],"code",{},"--cluster-init","フラグでetcdに変換できると説明されており、両者は用途に応じて後から切り替え可能な設計になっている。マルチノードHAを見据えるならetcd、単一ノードやエッジ用途でリソースを切り詰めたいならSQLite、という使い分けが現実的だ。",[16,121,122,123,127],{},"この「どちらを選ぶか」の判断と初期設定を自分たちで抱え込まず、",[42,124,126],{"href":44,"rel":125},[46],"Kubo Cloud","のAI-Driven Deploymentに任せるという選択肢もある。構成済みのK3sベース環境を前提に、運用側はアプリケーションの設計に集中できる。",[11,129,131],{"id":130},"_4-独立ベンチマークではむしろk3sの方が重いという結果も出ている","4. 独立ベンチマークでは、むしろK3sの方が重いという結果も出ている",[16,133,134],{},[19,135],{"alt":136,"src":137},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection04.webp",[16,139,140,141,146],{},"ここからが本題だ。",[42,142,145],{"href":143,"rel":144},"https:\u002F\u002Fwww.siderolabs.com\u002Fblog\u002Fwhich-kubernetes-is-the-smallest",[46],"Sidero Labsが公開した独立ベンチマーク","は、2 vCPU・4096MBのVM上で各ディストリビューションを1時間アイドル状態にし、Prometheus node exporterとGrafanaでメモリ使用量を計測している。",[16,148,149,150,153],{},"結果は直感に反するものだった。kubeadmを基準とした相対値で見ると、Talos Linuxは7%削減できた一方、",[30,151,152],{},"K3sはむしろ15%増加","。さらにRKE2は150%増、Canonical Kubernetesに至っては201%増という結果だった。同記事はこの増加要因について、embedded etcdサーバーの採用がメモリ使用量を押し上げている可能性を指摘している。",[16,155,156,157,160],{},"K3s公式のプロファイリング（セクション2）とこの独立ベンチマークの結果が食い違って見えるのは、測定対象が異なるからだ。公式データは「ワークロードを乗せた定常状態の95パーセンタイル」、Sidero Labsの測定は「1時間のアイドル状態」であり、データストア構成（SQLiteかetcdか）も明記されていない。",[30,158,159],{},"「K3s vs Kubernetes」の軽さ比較は、測定条件を揃えない限り結論が逆転しうる","、というのがここでの実務的な教訓だ。",[11,162,164],{"id":163},"_5-4倍のram差という数字の正体","5. 「4倍のRAM差」という数字の正体",[16,166,167],{},[19,168],{"alt":169,"src":170},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection05.webp",[16,172,173,174,179],{},"「K3sはkubeadmよりメモリが4分の1で済む」という言説もよく見かけるが、これも文脈を正確に見る必要がある。",[42,175,178],{"href":176,"rel":177},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fsetup\u002Fproduction-environment\u002Ftools\u002Fkubeadm\u002Finstall-kubeadm\u002F",[46],"Kubernetes公式のkubeadmインストールガイド","は、コントロールプレーン・ワーカーを問わず全マシンに「2GB以上のRAM」「コントロールプレーンは2CPU以上」を最小要件として明記している。",[16,181,182,183,188,189,192],{},"一方、",[42,184,187],{"href":185,"rel":186},"https:\u002F\u002Fbex.co\u002Fblog\u002F2026\u002F09\u002F28\u002Fk3s-vs-kubernetes-vs-microk8s-ram-gap-fleet",[46],"k3s\u002Fkubeadm\u002FMicroK8sの公称値を比較した記事","が指摘する「4倍のRAM差」は、",[30,190,191],{},"ワーカー\u002Fエージェントノードに限った差","だ。K3sのエージェントノードは512MBで動作するのに対し、kubeadmの標準ワーカーは2GBを要求する。しかしコントロールプレーン同士を比べれば、公称値はどちらも2GBで変わらない。同記事はさらに「実運用のkubeadmコントロールプレーンは、公称2GBではなく実際には4〜8GBを使うことが多い」とも補足している。",[16,194,195,200,201,204],{},[42,196,199],{"href":197,"rel":198},"https:\u002F\u002Fajmani.dev\u002Fk3s-vs-k8s-performance-comparison\u002F",[46],"k3sとkubeadmの実運用環境でのパフォーマンス比較","では、4vCPU\u002F8GB RAM環境でのアイドルメモリがK3s約512〜700MB、kubeadm約1.5〜2GBとなり、クラスタの起動時間もK3sが60秒未満、kubeadmが5〜8分と明確な差が出ている。「軽さ」の実感は、起動時間やワーカーノードの最小要件といった",[30,202,203],{},"どの指標を見るか","によって大きく変わるということだ。",[11,206,208],{"id":207},"_6-結局どちらを選ぶべきか-判断の軸","6. 結局どちらを選ぶべきか — 判断の軸",[16,210,211],{},[19,212],{"alt":213,"src":214},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Fsection06.webp",[16,216,217],{},"ここまでの実測データを踏まえると、判断軸は次のように整理できる。",[219,220,221,228,234],"ul",{},[222,223,224,227],"li",{},[30,225,226],{},"単一ノード・エッジ用途で起動速度とフットプリントを優先するなら",": K3s + SQLite構成。エージェントノードは512MB前後で動作し、起動も60秒未満",[222,229,230,233],{},[30,231,232],{},"マルチノードHAを前提にスケールさせたい、かつメモリに余裕があるなら",": K3s + embedded etcd、または標準のetcdクラスタ構成",[222,235,236,239],{},[30,237,238],{},"既存のkubeadmベースの運用ノウハウ・ツールチェーンをそのまま活かしたいなら",": 無理にK3sへ移行せず、実運用で必要なメモリ（4〜8GB）を見込んだ上でkubeadm構成を継続",[16,241,242,243,248,249,254],{},"実のところ、こうしたデータストア選択・リソース設計のチューニングは、クラスタ運用の中でも地味に工数を食う領域だ。関連して、CI\u002FCDビルドランナー基盤でのK3s選定を扱った",[42,244,247],{"href":245,"rel":246},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cicd-build-runner-latency-cost",[46],"過去記事","や、クラウド側のコスト構造を比較した",[42,250,253],{"href":251,"rel":252},"https:\u002F\u002Fkubo.hexabase.io\u002Fblog\u002Fja\u002Faks-cost-optimization-fixed-cost-structure-k3s-comparison",[46],"こちらの記事","も、同じ「K3s vs 標準Kubernetes」という選定軸で書いているので合わせて参考にしてほしい。",[16,256,257,258,261],{},"マネージドK8sサービスの",[42,259,47],{"href":44,"rel":260},[46],"は、このK3sベースの構成をあらかじめ最適化した状態で提供している。データストアの選定やリソースチューニングに工数をかけず、EKSやAKSの半額近いコストでフルスペックのKubernetesを運用できる点が特徴だ（4vCPU\u002F8GB\u002F40GB×3ノード構成でKubo月額48,000円、AWS EKSは82,700円という比較もある）。",[11,263,264],{"id":264},"まとめ",[16,266,267,268,271],{},"「K3sは軽い」という通説は、多くのケースで正しい。だが実測データを横断して見ると、その軽さは",[30,269,270],{},"測定条件・データストア選択・どのノード種別を見るか","に強く依存していることがわかる。独立ベンチマークではK3sがkubeadmより重くなるケースも報告されている以上、「軽いから採用する」という単純な判断ではなく、自分のワークロードに即した計測を一度は行うことをおすすめしたい。",[16,273,274,275,280,281,284,285,290],{},"こうした判断や構築・運用の手間を省きたい場合は、",[42,276,279],{"href":277,"rel":278},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[46],"Kubo On-Premise","や",[42,282,47],{"href":44,"rel":283},[46],"が提供するマネージドな選択肢も検討してみてほしい。構成の最適化はすでに済んだ状態で、本格的なKubernetesをすぐに使い始められる。気になる方は",[42,286,289],{"href":287,"rel":288},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[46],"お問い合わせ","から相談も可能だ。",{"title":292,"searchDepth":293,"depth":293,"links":294},"",2,[295,296,297,298,299,300,301],{"id":13,"depth":293,"text":14},{"id":51,"depth":293,"text":52},{"id":80,"depth":293,"text":81},{"id":130,"depth":293,"text":131},{"id":163,"depth":293,"text":164},{"id":207,"depth":293,"text":208},{"id":264,"depth":293,"text":264},"2026-10-04","K3sは本当に軽いのか。Kubernetes標準のkubeadmとコントロールプレーンのメモリ・CPU使用量を公式データと複数の独立ベンチマークで比較。データストア選択(etcd\u002FSQLite)次第で結果が逆転する理由を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison",{"title":5,"description":303},"blog\u002Fja\u002Fk3s-kubeadm-memory-benchmark-datastore-comparison",[313,314,315,316,317,318,319],"k3s","kubernetes","kubeadm","resource-profiling","memory-benchmark","control-plane","datastore-comparison","HisRYzHFW_xkj38VhgjgPy7BM2b_G7WphPP-SGE-39c",[322,330,340,352,362,372],{"path":323,"title":324,"description":325,"date":326,"tags":327},"\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",[313,314,328,329,315],"etcd","high-availability",{"path":331,"title":332,"description":333,"date":334,"tags":335},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[313,314,336,337,338,339],"hpa","containerresource","autoscaling","service-mesh",{"path":341,"title":342,"description":343,"date":344,"tags":345},"\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",[313,314,346,347,348,349,350,351],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":353,"title":354,"description":355,"date":356,"tags":357},"\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",[313,314,358,359,360,361],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":363,"title":364,"description":365,"date":366,"tags":367},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[313,314,368,369,370,371],"validatingadmissionpolicy","kyverno","cel","admission-control",{"path":373,"title":374,"description":375,"date":376,"tags":377},"\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",[313,314,378,338,379],"vpa","cgroup",1792592608009]