Skip to main content

Proxmox 上に K3s クラスタを構築する: ステップバイステップ

2026年5月27日by Kubo Team #K3s #Kubernetes #Proxmox #セルフホスティング #コンテナ #クラスタ構築 #DevOps

Kubernetes は現代のアプリケーションデプロイメントのデファクトスタンダードですが、完全な K8s クラスタの構築・運用には高い専門知識が求められます。K3s は Rancher Labs が開発した軽量 Kubernetes ディストリビューションで、フルスペックの Kubernetes 機能を最小限のリソースで提供します。Proxmox VE と組み合わせることで、柔軟でコスト効率の高い Kubernetes 基盤を構築できます。

本格的なマネージド Kubernetes が必要な場合は、Kubo On-Premise が Proxmox 上でもフルマネージド K8s 環境を提供します。インフラ管理の負担を最小限に抑え、開発に集中したい方に最適です。

アーキテクチャ設計と VM 計画

K3s クラスタの設計は、可用性要件とリソース予算のバランスで決まります。K3s 公式ドキュメントでは、本番環境に最低 3 つのサーバーノードを推奨しています。

推奨構成

ロールノード数CPUメモリストレージOS
サーバー（コントロールプレーン）34 vCPU8 GB50 GB SSDUbuntu 24.04 LTS
ワーカー（データプレーン）3+4 vCPU16 GB100 GB SSDUbuntu 24.04 LTS

ネットワーク設計

クラスタノードには DHCP 範囲外の静的 IP を割り当てます:

ノードホスト名IP アドレス
サーバー 1k3s-server-1192.168.1.101
サーバー 2k3s-server-2192.168.1.102
サーバー 3k3s-server-3192.168.1.103
ワーカー 1k3s-worker-1192.168.1.111
ワーカー 2k3s-worker-2192.168.1.112
ワーカー 3k3s-worker-3192.168.1.113

Proxmox のネットワーク設定で VLAN を活用すれば、管理ネットワークとクラスタネットワークを分離できます。

VM テンプレートの作成

効率的なノードデプロイのために、Cloud-Init 対応の VM テンプレートを作成します。これにより、クローン操作だけで新しいノードを数分でプロビジョニングできます。

Ubuntu Cloud Image のダウンロードとテンプレート化

bash
# Proxmox ホストで実行
# Ubuntu 24.04 Cloud Image をダウンロード
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# VM を作成（ID: 9000 をテンプレート用に使用）
qm create 9000 --name ubuntu-2404-template --memory 4096 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single

# ディスクイメージをインポート
qm set 9000 --scsi0 local-lvm:0,import-from=/root/noble-server-cloudimg-amd64.img

# Cloud-Init ドライブを追加
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0

# Cloud-Init のデフォルト設定
qm set 9000 --ciuser ubuntu --cipassword <password>
qm set 9000 --sshkeys ~/.ssh/id_rsa.pub
qm set 9000 --ipconfig0 ip=dhcp

# テンプレートに変換
qm template 9000

ノードのクローン

テンプレートから各ノードをフルクローンします:

bash
# サーバーノード
qm clone 9000 101 --name k3s-server-1 --full
qm clone 9000 102 --name k3s-server-2 --full
qm clone 9000 103 --name k3s-server-3 --full

# ワーカーノード（リソースを増量）
qm clone 9000 111 --name k3s-worker-1 --full
qm set 111 --memory 16384 --cores 4
qm clone 9000 112 --name k3s-worker-2 --full
qm set 112 --memory 16384 --cores 4

各ノードに静的 IP を設定します:

bash
qm set 101 --ipconfig0 ip=192.168.1.101/24,gw=192.168.1.1
qm set 102 --ipconfig0 ip=192.168.1.102/24,gw=192.168.1.1
# 以下同様

Kubo を使えば、このようなクラスタ構築・管理の複雑さから解放され、宣言的な設定だけで本番グレードの K8s 環境が手に入ります。

K3s のインストールと構成

サーバーノードの初期化

最初のサーバーノード（k3s-server-1）で K3s クラスタを初期化します。K3s クイックスタートガイドに従い、以下を実行します:

bash
# 最初のサーバーノードで実行
curl -sfL https://get.k3s.io | K3S_TOKEN=<secure-token> sh -s - server \
  --cluster-init \
  --tls-san=192.168.1.100 \
  --disable traefik \
  --write-kubeconfig-mode 644

オプション説明:

  • --cluster-init: 組み込み etcd を使った HA モードで初期化
  • --tls-san: ロードバランサー VIP を SAN に追加
  • --disable traefik: 後で独自の Ingress Controller を導入するため無効化
  • --write-kubeconfig-mode 644: kubeconfig の読み取り権限を設定

追加サーバーノードの参加

残りのサーバーノードをクラスタに参加させます:

bash
# k3s-server-2, k3s-server-3 で実行
curl -sfL https://get.k3s.io | K3S_TOKEN=<secure-token> sh -s - server \
  --server https://192.168.1.101:6443 \
  --tls-san=192.168.1.100

ワーカーノードの追加

ワーカーノードは K3S_URL 環境変数を指定して参加させます:

bash
# 各ワーカーノードで実行
curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.101:6443 \
  K3S_TOKEN=<secure-token> sh -

サーバーノードのトークンは /var/lib/rancher/k3s/server/node-token から取得できます。

kubeconfig の設定

ローカルマシンから kubectl で操作するために、kubeconfig をコピーします:

bash
# サーバーノードから kubeconfig を取得
scp ubuntu@192.168.1.101:/etc/rancher/k3s/k3s.yaml ~/.kube/config

# サーバーアドレスを外部 IP に変更
sed -i 's/127.0.0.1/192.168.1.101/' ~/.kube/config

# ノード一覧を確認
kubectl get nodes -o wide

ネットワークとストレージの設定

MetalLB ロードバランサー

ベアメタル環境では、MetalLB が LoadBalancer タイプの Service に外部 IP を払い出します:

bash
# MetalLB のインストール
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml

# IP アドレスプールの設定
cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.200-192.168.1.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default
  namespace: metallb-system
EOF

NGINX Ingress Controller

NGINX Ingress Controller で HTTP/HTTPS トラフィックをルーティングします:

bash
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/baremetal/deploy.yaml

Longhorn 分散ストレージ

Longhorn は Kubernetes ネイティブの分散ブロックストレージで、K3s との統合が優れています:

bash
# Longhorn のインストール
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/deploy/longhorn.yaml

# デフォルト StorageClass として設定
kubectl patch storageclass longhorn -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

運用と監視

クラスタの状態確認

bash
# ノードの状態
kubectl get nodes -o wide

# システムポッドの確認
kubectl get pods -A

# K3s サービスの確認
systemctl status k3s       # サーバーノード
systemctl status k3s-agent # ワーカーノード

バックアップと復旧

etcd のスナップショットは K3s が自動的に取得しますが、手動バックアップも重要です:

bash
# 手動 etcd スナップショット
k3s etcd-snapshot save --name manual-backup-$(date +%Y%m%d)

# スナップショット一覧
k3s etcd-snapshot ls

K3s クラスタの運用を自動化し、エンタープライズグレードの信頼性を実現したい場合は、Kubo On-Premise が最適なソリューションです。

まとめ

Proxmox VE 上に K3s クラスタを構築することで、柔軟で費用対効果の高い Kubernetes 環境が実現します。VM テンプレートによる効率的なプロビジョニング、HA 構成による高可用性、Longhorn による分散ストレージと、本番運用に必要な要素をすべてカバーしました。

より高度な管理機能やエンタープライズサポートが必要な場合は、Kubo の導入をご検討ください。Proxmox 上でも Kubo On-Premise ならフルマネージド K8s として、クラスタのライフサイクル管理、自動スケーリング、セキュリティパッチ適用まで一括で対応します。

詳細は お問い合わせ からご連絡ください。

関連リンク:

← Back to all posts