午前2時の呼び出し：なぜDocker Composeだけでは不十分なのか
誰もが経験したことがあるでしょう。午前2時、ダッシュボードがダウンし、「Connection Refused（接続拒否）」というエラーを眺めている自分。原因を突き止めると、1つのコンテナがメモリ不足（OOM）制限に達し、停止したままになっていました。基本的なDocker Composeのセットアップでは、クラッシュしたコンテナは手動で介入するまで停止したままになることがよくあります。その夜、私はDocker Composeが素晴らしい出発点ではあるものの、真にレジリエントなHomeLabに必要な「自己修復機能」という頭脳が欠けていることに気づきました。
そこでK3sの登場です。これはRancherによって開発された、低リソース環境向けに構築された軽量で認定済みのKubernetesディストリビューションです。etcdのような重いコンポーネントをSQLiteに置き換え、レガシーなアルファ機能を取り除いています。その結果、わずか50MBのバイナリで、アイドル時のRAM消費が512MB以下という軽量さを実現しました。「サーバーを所有するホビイスト」から、Raspberry Pi 5や古いIntel NUC上でプロフェッショナル級のDevOpsワークフローを実践するエンジニアへとステップアップしたいなら、これは学ぶべきツールです。
K3sは、クローゼットの中のサーバーにエンタープライズ級のオーケストレーションをもたらします。電力消費の激しいサーバーラックを用意しなくても、自動再起動、ローリングアップデート、宣言的な設定を処理できます。本質的に、余っているハードウェアをミニデータセンターに変えてくれるのです。
インストール：30秒でゼロからクラスター構築まで
多くの人はKubernetesの構築に何時間もかかると考えています。標準のK8sにはkubeadmのような複雑なツールが必要ですが、K3sはシンプルなシェルスクリプトで重労働をこなしてくれます。最高の互換性を得るために、クリーンなUbuntu 24.04 LTSインスタンスで実行することをお勧めします。
まずは、システムをアップデートしてcurlをインストールします：
sudo apt update && sudo apt upgrade -y
sudo apt install curl -y次に、インストールスクリプトを実行します。ここでは初期設定をシンプルに保つために、デフォルトのTraefikインプレスコントローラーを無効にします（オールインワンのソリューションを好む場合は、K3sに管理させることも可能です）：
curl -sfL https://get.k3s.io | sh -s - --disable traefikスクリプトが終了したら、ノードの状態を確認しましょう。10〜15秒ほどで「Ready」ステータスに変わるはずです：
sudo kubectl get nodesコマンドごとにsudoを入力しなくて済むようにすると、クラスターの管理が楽になります。以下の手順で設定をホームディレクトリにコピーします：
mkdir ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
export KUBECONFIG=~/.kube/config設定：初めてのレジリエントなアプリをデプロイする
Kubernetesの世界では、単にコンテナを「実行」するだけではありません。代わりに、コピーをいくつ作成するかを指定するDeploymentと、ユーザーがそれらにアクセスする方法を定義するServiceを定義します。シンプルなNginxインスタンスをデプロイしてみましょう。これは、プライベートWikiやメディアサーバーのような、より複雑なアプリの完璧なプレースホルダーになります。
1. Deploymentの作成
webapp.yamlという名前のファイルを作成します。このマニフェストは、アプリケーションがどのように動作すべきかをK3sに正確に伝えます。もしポッド（コンテナを包むKubernetesの最小単位）が死んでも、K3sはその欠落を検知し、即座に代替を起動します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-app
spec:
replicas: 2
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web-server
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancerkubectlコマンドを使用して設定を適用します：
kubectl apply -f webapp.yaml2. 永続ストレージの取り扱い
データの管理は、HomeLab愛好家にとって通常最大のハードルです。K3sにはデフォルトでlocal-pathプロビジョナーが含まれています。Dockerのように手動でフォルダを作成してマッピングする必要はもうありません。単にPersistentVolumeClaim (PVC)を要求すれば、K3sが自動的にディスク上に必要なスペースを切り出します。マルチノード構成では最終的にLonghornやNFSに移行することになるかもしれませんが、シングルノードのラボであればデフォルトのlocal-pathは非常に堅牢です。
検証とモニタリング：安定稼働を維持するために
アプリが稼働したら、そのパフォーマンスを確認する必要があります。午前2時にトラブルシューティングをしているとき、何千行もの生のテキストファイルをgrepしたくはないはずです。
K9sの威力
kubectlは標準的なツールですが、私は日々の管理に**K9s**を使用しています。クラスターのための高速なターミナルダッシュボードと考えてください。数回のキー入力でログの表示、ポッドの再起動、コンテナへのシェル接続が可能です。長いコマンドを打ち込むよりもはるかに高速です。
# webi経由でK9sをインストール
curl -sS https://webi.sh/k9s | shヘルスチェックとトラブルシューティング
コマンドラインを好む場合は、これら2つのコマンドを使用してサービスの状態を把握しましょう：
kubectl get pods
kubectl logs -f [ポッド名]CrashLoopBackOffステータスは、通常コンテナ内部の設定エラーを示しています。ポッドがPendingのままの場合、ホストマシンのCPUまたはRAMが不足している可能性があります。
リソース制限：安定稼働の秘訣
1つのバグだらけのアプリがサーバー全体をクラッシュさせるのを防ぐために、常にリソース制限を設定しましょう。これはプロフェッショナルなセットアップの証です。コンテナ仕様にこのブロックを追加して、リソースを制御下に置きます：
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"これらの境界を強制することで、DNSやHome Assistantのような重要なサービスが必要なリソースを常に確保できるようになります。新しいテストプロジェクトでメモリリークが発生しても、コアとなるラボ環境はオンラインに保たれます。K3sへの移行には学習曲線がありますが、それによって得られる信頼性は努力に見合う価値があります。個々のコンテナを心配するのをやめて、サービスそのものに集中できるようになるのです。
