軽量 Kubernetes ディストリビューションとして急速に普及している K3s は、シングルバイナリで動作し、わずか 512MB の RAM から本番ワークロードを実行できます。しかし「軽量＝本番に不向き」ではありません。適切な設計と運用プラクティスを適用すれば、K3s はエンタープライズレベルの信頼性を実現します。
Kubo は K3s ベースのマネージド Kubernetes プラットフォームで、月額48,000円〜で本番グレードの K3s クラスタを提供しています。本記事で紹介するベストプラクティスの多くは Kubo で自動的に適用されるため、インフラ管理の負荷を大幅に削減できます。
高可用性（HA）構成の設計
本番環境で K3s を運用する最重要ポイントは高可用性（HA）構成です。K3s 公式ドキュメントによれば、HA 構成には最低3台のサーバーノードが必要で、etcd のクォーラム維持のために奇数台で構成します。
データストアの選択
K3s は複数のデータストアバックエンドをサポートしています：
- 組み込み etcd（推奨）: 自己完結型で管理が容易。ほとんどの本番環境に適合
- 外部 PostgreSQL / MySQL: 大規模クラスタでデータストアを独立してスケールしたい場合
- 組み込み SQLite: シングルノード構成のみ。本番環境には非推奨
組み込み etcd を使用する場合、サーバーノード間でポート 2379-2380 の通信が必須です。K3s のシステム要件に記載されている全ポートを確認しましょう。
ロードバランサー戦略
サーバーノードの前段にロードバランサーを配置しますが、単一のロードバランサーは SPOF（単一障害点）になります。Keepalived を使用した冗長ロードバランサー構成、またはクラウドロードバランサーの冗長性機能を活用してください。
セキュリティハードニング
K3s はデフォルトで多くのセキュリティ緩和策が適用されていますが、本番環境ではさらなるハードニングが必要です。K3s CIS ハードニングガイドに従い、CIS ベンチマークへの準拠を目指しましょう。
Pod Security Standards
K3s v1.25 以降は Pod Security Admissions（PSA）をサポートしています。--admission-control-config-file フラグで有効化し、restricted プロファイルの適用を推奨します。
RBAC とシークレット管理
- 最小権限の原則に基づく RBAC ポリシーを設計
- Kubernetes Secrets は etcd に暗号化して保存（
--secrets-encryptionフラグ） - 外部シークレットマネージャー（HashiCorp Vault、AWS Secrets Manager）との統合を検討
ネットワークポリシー
K3s はデフォルトで Network Policy コントローラーを同梱しています。Kubernetes のネットワークポリシーを活用し、Pod 間通信を最小限に制限しましょう。
セキュリティを後から追加するのは常に困難です。Day 1 からネットワークポリシー、PSA、RBAC、シークレット管理を実装してください。
Captain.AI と連携する Kubo では、これらのセキュリティ設定がプラットフォームレベルで事前構成されています。
監視・アラートの構築
「見えないものは管理できない」という原則のとおり、インシデントが起きる前に包括的な監視・アラート体制を整備する必要があります。
Prometheus + Grafana スタック
K3s クラスタの監視には Prometheus と Grafana の組み合わせが定番です：
# Helm でのインストール例
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
--namespace monitoring --create-namespace
重要な監視メトリクス
| メトリクス | 閾値 | アクション |
|---|---|---|
| サーバー CPU 使用率 | > 90% | ノード追加を検討 |
| メモリ使用率 | > 80% | リソース制限の見直し |
| etcd レイテンシ | > 100ms | ディスク io の最適化 |
| Pod 再起動回数 | 増加傾向 | OOM / CrashLoop 調査 |
K3s のリソースプロファイリングドキュメントも参照し、クラスタサイズに応じた適切なリソース割り当てを行いましょう。
ログ収集
Fluentd / Fluent Bit を使用して、クラスタ全体のログを Elasticsearch や Loki に集約します。K3s の監査ログはデフォルトでは無効なので、本番環境では明示的に有効化してください。
バックアップ・リストア戦略
障害からの復旧能力は本番環境の信頼性を決定づけます。etcd スナップショットとアプリケーションレベルのバックアップを組み合わせましょう。
etcd スナップショット
K3s は組み込みの etcd スナップショット機能を提供しています：
# 手動スナップショットの取得
k3s etcd-snapshot save --name pre-upgrade-$(date +%Y%m%d)
# 自動スナップショットの設定（サーバー起動オプション）
# --etcd-snapshot-schedule-cron "0 */4 * * *" # 4時間ごと
# --etcd-snapshot-retention 10 # 10世代保持
4〜6時間ごとの自動スナップショットを設定し、スナップショットは S3 互換のオブジェクトストレージに外部保存します。
Velero によるアプリケーションバックアップ
Velero を使用して、Kubernetes リソースと永続ボリュームのバックアップを実施します。etcd スナップショットではカバーできないアプリケーションデータの保護に不可欠です。
リストアテスト
バックアップの価値はリストアの成功率で決まります。 定期的にリストア手順をテストし、RTO（目標復旧時間）と RPO（目標復旧時点）が要件を満たすことを確認してください。
リソース管理とアップグレード戦略
リソースリクエストとリミット
すべてのワークロードに適切な requests と limits を設定します。K3s のハードウェア要件によれば、サーバーノードは最低 2 CPU / 2GB RAM、エージェントノードは 1 CPU / 512MB RAM が必要です。
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
ローリングアップグレード
K3s のアップグレードは system-upgrade-controller を使用して自動化できます。本番環境では以下の手順を推奨します：
- ステージング環境で新バージョンをテスト
- etcd スナップショットを取得
- サーバーノードを順次アップグレード
- ワーカーノードを順次アップグレード
- アプリケーションの動作を検証
ストレージの考慮事項
K3s のデフォルトデータディレクトリ /var/lib/rancher/k3s には高速な SSD（できれば NVMe）を使用してください。特に ARM デバイスの場合、SD カードや eMMC は io 負荷に耐えられないため避けるべきです。
まとめ：K3s 本番運用チェックリスト
K3s は軽量でありながら、適切に構成すれば本番環境で十分な信頼性を発揮します。以下のチェックリストで運用準備を確認しましょう：
- HA 構成（3台以上の奇数サーバーノード + 組み込み etcd）
- CIS ハードニングガイドに準拠したセキュリティ設定
- Prometheus + Grafana による包括的な監視
- 自動 etcd スナップショット + Velero バックアップ
- 全ワークロードにリソースリクエスト / リミットを設定
- ローリングアップグレード手順の確立
これらの運用負荷を軽減したい方には、Kubo がおすすめです。 月額48,000円〜で K3s ベースのマネージド Kubernetes を利用でき、HA 構成・セキュリティ・監視・バックアップが事前構成されています。AI ワークロードの運用には Captain.AI との統合もご検討ください。