Proxmox + K3s でセルフホスト Kubernetes を構築する記事やチュートリアルは、ここ数年で急増しました。「5分でクラスタが立ち上がる」「ハードウェアコストだけで始められる」という魅力的な宣伝文句に惹かれ、多くの開発チームがセルフホストを選択しています。
しかし、「構築できる」と「運用できる」は全く別物です。

CNCF（Cloud Native Computing Foundation）の 2025 年調査では、セルフホスト Kubernetes の運用に「operational complexity」と「costly maintenance」が主要な課題として挙げられています。専任エンジニア 1-2 名分の工数（日本のインフラエンジニアの平均年収 800 万円を基準にすると年間 800〜1,600 万円相当）が継続的に必要とされ、ハードウェア保守・監視ツール・セキュリティ対応を含めると、年間 1,000〜2,000 万円のコストが隠れています。

さらに、CAST AI の 2026 年 State of Kubernetes Optimization Reportによると、CPU overprovisioning が 69%、memory overprovisioning が 79% に達しており、リソース非効率性が運用負荷を増幅させています。セルフホスト環境では、この非効率性がそのままハードウェアコスト・電力コストに直結します。

本記事では、Proxmox + K3s のセルフホスト Kubernetes（クバネティス）の「構築の容易さ」と「運用の現実」を対比させ、Docker・CI/CD・ネットワーク設定の統合インフラにおける隠れコストを明らかにします。そして、マネージド Kubernetes とオンプレミス対応マネージドサービスという、第 2・第 3 の選択肢を提示します。データ主権が求められる金融・医療業界の読者には、特に後半のセクションが参考になるでしょう。

1. Proxmox + K3s でセルフホスト Kubernetes は「5分で構築」できる — でも、それだけではない

Proxmox VE（Virtual Environment）は、仮想マシンと Linux コンテナを統合管理できるオープンソースの仮想化プラットフォームです。Web ベースの GUI で直感的に操作でき、USB インストーラーから 10 分程度でセットアップが完了します。中古サーバーや Raspberry Pi クラスタでも動作するため、初期ハードウェアコストを数万円から始められます。

K3s は、Kubernetes のフル機能を保ちながら軽量化した実装です。単一バイナリで配布され、メモリフットプリントは従来の Kubernetes の約半分。systemd サービスとして自動起動するため、VM 上での構築が非常に簡単です。実際、Proxmox 上に VM を作成し、K3s をインストールしてクラスタを立ち上げるまで、手順に慣れていれば 5 分程度で完了します。

この「構築の容易さ」が、Proxmox + K3s の最大の魅力です。しかし、ここに大きな誤解があります。

クラスタの「構築」と「運用」は別のスキルセットであり、後者の方が圧倒的に工数がかかるのです。

構築フェーズで必要なのは、Proxmox の基本操作と K3s のインストールコマンド程度です。一方、運用フェーズでは以下のタスクが継続的に発生します:

• 監視・アラート設定：ノードの CPU・メモリ使用率、ポッドの再起動回数、ネットワークトラフィックの異常検知
• セキュリティパッチ適用：Proxmox、K3s、Linux カーネル、containerd の脆弱性対応
• バックアップ自動化：etcd クラスタの定期バックアップ、災害復旧計画の策定
• ストレージ管理：Persistent Volume の容量監視、ストレージクラスの設定
• ネットワーク設定：Service、Ingress、CNI プラグイン（Flannel / Calico / Cilium）の設定とトラブルシューティング

これらは「構築後に発生する継続的な運用タスク」であり、スタートアップや小規模チームにとって、専任エンジニアを配置する余裕がない場合、大きな負担になります。

Docker × Kubernetes × CI/CD の統合インフラを実現したい開発チームにとって、初期構築の容易さは「入口」に過ぎません。本当の勝負は、その後の運用フェーズで始まります。

2. セルフホスト Kubernetes の隠れコスト — 「無料」の裏にある年間 2,000 万円

「Proxmox + K3s は無料で始められる」— これは事実です。ソフトウェアライセンス料はゼロ、ハードウェアも中古サーバーで数万円から揃います。しかし、TCO（Total Cost of Ownership：総所有コスト）を計算すると、驚くべき隠れコストが浮上します。

CNCF の 2025 年調査では、セルフホスト Kubernetes の運用に「operational complexity」と「costly maintenance」が主要な課題として挙げられています。以下は、一般的な運用コストの試算です:

• 専任エンジニアの工数：フルタイム 1-2 名分（年間 800〜1,600 万円相当）
• ハードウェア保守：電力・ネットワーク・ストレージの維持費（年間 100〜200 万円）
• 監視・ログ管理ツール：Prometheus、Grafana、Loki 等のセットアップと運用（年間 50〜100 万円）
• セキュリティ対応：CVE（Common Vulnerabilities and Exposures）への対応、ペネトレーションテスト（年間 100〜200 万円）

合計すると、年間 1,050〜2,100 万円のコストが「無料」の裏に潜んでいます。

さらに深刻なのが、リソース非効率性です。CAST AI の 2026 年レポートによると、CPU overprovisioning が 69%、memory overprovisioning が 79% に達しており、過剰プロビジョニングによって不要なノード数が増加しています。セルフホスト環境では、この非効率性がそのままハードウェアコスト・電力コストに直結します。

マネージド Kubernetes サービス（AWS EKS、Google GKE、Azure AKS、Kubo 等）では、こうした運用タスクの大部分がプロバイダー側で自動化されています。月額料金（月額8800円〜）を支払うことで、専任エンジニアの工数を開発業務に再配分できます。

「無料で始められる」というメリットは、運用フェーズの隠れコストを考慮すると、必ずしも最安の選択肢ではないことを認識すべきです。

3. Docker + Kubernetes + CI/CD — 3つが揃って初めて「モダンインフラ」が完成する

Proxmox で VM を作り、Docker でコンテナ化し、K3s でオーケストレーションしても、それだけでは「モダンインフラ」とは言えません。CI/CD パイプラインが統合されて初めて、開発速度とデプロイ信頼性が大幅に向上します。

なぜ Docker だけでは本番運用に不十分なのか

Docker Compose は単一ホスト上で複数コンテナを統制する優れたツールですが、本番環境では以下の限界があります:

• スケーリングの制約：複数ノードにまたがるコンテナ配置ができない
• 障害復旧の手動化：コンテナが停止した場合、手動で再起動が必要
• 負荷分散の不在：トラフィックの増加に対して自動的にコンテナを増やす仕組みがない

Kubernetes はこれらの課題を解決しますが、手動デプロイでは新たな問題が生じます。コードを変更するたびに、エンジニアが以下の手順を手動で実行する必要があります:

• Docker イメージをビルド
• コンテナレジストリにプッシュ
• kubectl コマンドで K8s クラスタにデプロイ
• ポッドの起動状態を確認

この手動プロセスは、ヒューマンエラーの温床です。デプロイ中に間違ったイメージタグを指定したり、設定ファイルの変更を反映し忘れたりすることで、サービス停止のリスクが高まります。

CI/CD で実現する「コミットから本番まで完全自動化」

GitHub Actions や GitLab CI を使った CI/CD パイプラインは、この問題を根本から解決します。以下の 3 ステップで、コードのコミットから本番環境へのデプロイまでを自動化できます:

• テスト：npm test または pytest で自動テスト実行
• ビルド：docker build で Docker イメージを作成し、レジストリにプッシュ
• デプロイ：kubectl apply -f deployment.yaml で K8s クラスタにデプロイ

これらのステップは、コードを GitHub にプッシュした瞬間に自動実行されます。エンジニアが手動で操作する必要はありません。

Hexabase のAI駆動開発伴走セミナーでは、Docker・K8s・CI/CD の統合インフラを実際のプロジェクトで導入する実践的な研修コース（入門 2 日 / AI 活用 1 日 / リスキリング 3 ヶ月）を提供しています。技術選定から導入まで、チームの開発速度を上げる具体的なステップを学べます。

Docker、Kubernetes、CI/CD の3つが揃って初めて、エンジニアは「インフラ運用作業」から解放され、開発に集中できるようになります。

4. Kubernetes ネットワークの「複雑さ」が運用負荷の 80% を占める

Proxmox + K3s の構築記事を読んだエンジニアが最初にぶつかる壁が、Kubernetes ネットワークの複雑さです。CNCF の調査でも、「K8s 運用の課題」として「complexity」が回答者の 34% から挙げられており、初学者・中級者ともに最も苦労する領域の1つです。

ポッド間通信 — IP アドレスの動的変更に対処する

Kubernetes では、ポッドが再起動されるたびに新しい内部 IP アドレスが割り当てられます。この「一時的な IP アドレス」により、固定 IP に頼った従来のネットワーク設計は通用しません。

Service リソースは、この課題を解決するための抽象化レイヤーです。ポッドの内部 IP を隠蔽し、固定の DNS 名（例: my-service.default.svc.cluster.local）を提供することで、バックエンドのポッドが変わっても接続先が変わらないようにします。

しかし、Service には 3 つのタイプ（ClusterIP / NodePort / LoadBalancer）があり、それぞれの使い分けが初学者にとって分かりにくい:

• ClusterIP：クラスタ内部からのみアクセス可能。マイクロサービス間の通信に使用
• NodePort：ノードの特定ポートを公開し、外部からアクセス可能にする。開発環境で便利だが、本番では推奨されない
• LoadBalancer：クラウドプロバイダーのロードバランサーを自動作成。セルフホスト環境では MetalLB 等の追加設定が必要

CNI プラグインの選択 — Flannel / Calico / Cilium の違い

CNI（Container Network Interface）プラグインは、ポッド間のネットワーク通信を実現する低レイヤーのコンポーネントです。K3s はデフォルトで Flannel を使用しますが、高度なネットワークポリシー（ファイアウォールルール）が必要な場合は Calico または Cilium への変更が必要です。

各プラグインの特徴:

• Flannel：シンプル・軽量。ネットワークポリシーは非対応
• Calico：ネットワークポリシー対応。中規模クラスタに適している
• Cilium：eBPF ベースの高性能 CNI。マルチクラウド・マルチテナント環境に最適

初学者が「どの CNI を選ぶべきか」を判断するには、ネットワークアーキテクチャの深い理解が必要です。これが、セルフホスト Kubernetes の運用負荷の大部分を占める理由です。

Ingress — 外部トラフィックの制御

Ingress は、HTTP/HTTPS トラフィックをクラスタ内のサービスにルーティングする仕組みです。Nginx Ingress Controller や Traefik を使用しますが、SSL 証明書の自動更新（Let's Encrypt との連携）、パスベースルーティング（/api → サービスA、/admin → サービスB）、レート制限の設定など、細かな設定が必要です。

セルフホスト環境では、これらの設定を全て手動で行う必要があります。マネージド Kubernetes では、Ingress Controller が自動的にプロビジョニングされ、SSL 証明書も自動更新されます。

ネットワーク設定の複雑さは、セルフホスト Kubernetes の運用負荷の大部分を占めます。 この領域の理解と運用に、専任エンジニアの多くの時間が割かれることを覚悟すべきです。

5. Proxmox は「ホームラボ」じゃない — 金融・医療が選ぶオンプレミス Kubernetes

Proxmox + K3s の記事やチュートリアルの多くが、「自宅サーバーで Kubernetes を学習する」という文脈で紹介されています。このため、Proxmox = ホームラボ用という印象が強くなっています。

しかし、Proxmox は本番インフラとしても十分に採用されています。 特に、以下の業界でオンプレミス Kubernetes 基盤として選ばれています:

データ主権が求められる業界 — 金融・医療・製造

金融機関、医療機関、製造業では、法規制やセキュリティポリシーにより、顧客データや機密情報をクラウドに置けない制約があります。この「データ主権」の要求により、オンプレミスインフラが唯一の選択肢になります。

• 金融機関：顧客の口座情報・取引履歴は、GDPR（EU一般データ保護規則）や個人情報保護法の対象。クラウドに預けることで第三者（クラウドプロバイダー）がデータにアクセスできる状態は避けたい
• 医療機関：電子カルテや診療記録は、HIPAA（米国医療保険の相互運用性と説明責任に関する法律）や国内の医療情報ガイドラインの対象。Air-Gapped 環境（インターネット非接続）での運用が求められるケースもある
• 製造業：製品設計データや生産ライン情報は企業の競争力の源泉。外部ネットワークに接続しない閉域環境での管理が必要

これらの業界では、Proxmox + K3s のセルフホスト構成が採用されています。しかし、前述の通り、完全セルフホストは運用負荷が膨大です。

オンプレミス対応マネージド Kubernetes という第3の選択肢

「クラウドのマネージドサービスは使えない」「完全セルフホストは運用負荷が高い」— この2つのジレンマを解決するのが、オンプレミス対応マネージド Kubernetes です。

Kubo On-Premise のようなサービスでは、以下の特徴を持ちます:

• オンプレミス環境にインストール：データは自社のデータセンター内に保持。クラウドに出さない
• 運用はベンダーに委託：Kubernetes クラスタの監視・アップデート・セキュリティパッチ適用をベンダー側で実施
• Air-Gapped 対応：インターネット非接続環境でも動作するオフラインインストールモード

つまり、「データ主権を守りつつ、運用負荷は削減する」という、SaaS とセルフホストの中間的な選択肢です。

Proxmox は「ホームラボ」ではなく、データ主権が求められる本番環境で選ばれるプラットフォームです。 ただし、完全セルフホストの運用負荷を理解した上で、オンプレミス対応マネージドサービスという選択肢も検討すべきです。

6. マネージド vs セルフホスト vs オンプレミス対応マネージド — 3 つの選択肢

Kubernetes を本番環境で運用する選択肢は、大きく 3 つに分類されます。以下の比較表を参考に、自社の要件に最適な選択肢を判断してください。

セルフホスト（Proxmox + K3s）

適している組織：ホームラボ・学習目的 / スタートアップの初期インフラ（専任エンジニアが配置可能）/ オープンソースへの深い理解があるチーム

メリット：初期コストが低い（ハードウェア数万円〜）/ フルコントロール可能（カスタマイズの自由度が高い）/ ベンダーロックインがない

デメリット：運用工数が膨大（専任エンジニア 1-2 名必要）/ ネットワーク設定・監視・セキュリティパッチを全て手動 / リソース非効率性（CPU overprovisioning 69%, memory overprovisioning 79%）

年間コスト：1,050〜2,100 万円（人件費込み）

マネージド Kubernetes（Kubo / EKS / GKE / AKS）

適している組織：クラウド利用が可能な企業 / 開発スピードを優先したいスタートアップ / 運用負荷を削減したい中小企業

メリット：運用負荷の大幅削減（ネットワーク・監視・セキュリティが自動化）/ 自動スケーリング・自動復旧が標準装備 / 月額料金でコストが予測可能

デメリット：データをクラウドに預ける必要がある（データ主権の制約）/ ベンダーロックインのリスク / 月額コストが継続的に発生

月額コスト：月額8800円〜（ノード数・スペックによる）

Kubo は、8800円〜利用可能で K8s クラスタのネットワーク設定・監視・自動スケーリングを自動化します。専任エンジニアを配置する必要がなく、開発チームは開発に集中できます。

オンプレミス対応マネージド（Kubo On-Premise）

適している組織：データ主権が求められる金融・医療・製造業 / Air-Gapped 環境（インターネット非接続）での運用が必要 / オンプレミスでありながら運用負荷を削減したい企業

メリット：データを自社データセンター内に保持（データ主権を守る）/ 運用負荷の削減（監視・アップデート・セキュリティ対応はベンダーが実施）/ Air-Gapped 対応（オフラインインストール可能）

デメリット：初期導入コストがマネージドより高い / ハードウェア保守は自社負担

導入コスト：個別見積もり（ハードウェア・ライセンス・導入支援費用）

Kubo On-Premise なら、オンプレミス環境でありながら、Kubernetes の運用を Hexabase に任せることができます。データ主権を守りつつ、年間 2,000 万円の運用コストを削減する選択肢として、無料相談でご要件をお聞かせください。

7. まとめ — 「構築できる」と「運用できる」は別。選ぶべきは Kubernetes の種類ではなく、運用体制

Proxmox + K3s でセルフホスト Kubernetes を構築できることは事実です。しかし、「5分で構築できる」という魅力的な宣伝文句の裏には、年間 2,000 万円相当の隠れコストが潜んでいます。

本記事で明らかにしたポイントを振り返ります:

• 構築と運用は別のスキルセット：構築は数時間で完了するが、運用は専任エンジニア 1-2 名の継続的な工数を要する
• Docker・Kubernetes・CI/CD の統合が必須：3 つが揃って初めて開発速度が上がり、デプロイの信頼性が向上する
• ネットワーク設定が運用負荷の大部分：Service、Ingress、CNI プラグインの設定とトラブルシューティングが最大の壁
• Proxmox は本番インフラとしても使える：データ主権が求められる金融・医療業界で採用されている
• 3 つの選択肢を比較検討すべき：セルフホスト / マネージド / オンプレミス対応マネージドの特徴を理解し、自社の要件に合った選択を

選ぶべきは Kubernetes の「種類」（K3s / K8s / EKS）ではなく、「運用体制」です。

• 専任エンジニアを配置できるなら、セルフホストで自由度を最大化できる
• 開発スピードを優先するなら、マネージド Kubernetes で運用負荷を削減すべき
• データ主権が必須なら、オンプレミス対応マネージドサービスという第 3 の選択肢がある

「無料で始められる」という初期コストの低さに惹かれ、運用フェーズの隠れコストを見落とすと、後で大きな負担になります。Kubernetes を長期的に運用するには、初期構築よりも運用体制の設計が重要です。