おうちKubernetes、皆さんはどのディストリビューションを使っていますか？
我が家ではこれまで、ベースのKubernetesとしてMicroK8sを愛用していました。Ubuntuサーバーに「とりあえず簡単にk8sを立てる」用途としては最高でした。
しかし今後、「Ubuntu（Incus VM）のコントロールプレーン」と「Mac StudioのGPU仮想ノード（Virtual Kubelet）」を組み合わせたハイブリッドなアーキテクチャを組んでいこうと思っています。このように将来的に高度でプログラマブルな環境を構築・運用していくことを見据えると、いまのうちにディストリビューションを見直し、土台を綺麗にしておく必要があると感じたのです。
そこで思い切って、軽量かつオープンな k3s へと基盤を移行することにしました。理由は2つあります。
1. 自作Virtual Kubeletプロバイダ開発における「素直さ」への期待
これが一番の動機です。今後、Mac Studio上のプロセスをk8sのノードとして組み込むという変則的な構成をとろうと考えています。実のところ、Mac向けのデファクトツールは存在せず、「最悪、自分でプロバイダを実装するしかない」状態です。 正直なところAPI接続自体はMicroK8sでも大きく変わらない気もしますが、Snapパッケージでネットワークや証明書が独自に隠蔽されている環境より、純粋でオープンなバイナリ構成であるk3sの方が、自作ツールで謎のエラーを踏んだときのトラブルシューティングがやりやすい（はずだ）という期待があります。
2. Incus VM におけるフットプリントと運用保守性
インフラの土台となるIncus VM上で動かす際の、システムとしての「美しさ」と「軽さ」も重要です。
MicroK8sは snapd に強く依存しており、バックグラウンドでの自動更新や複雑なループバックマウントがVMのリソースを静かに圧迫します。一方、k3sは不要なドライバを極限まで削ぎ落としており、1つの実行バイナリと1つの systemd サービスだけで完結します。コントロールプレーンとしてのメモリ消費量も非常に少なく、VM内が驚くほどクリーンに保たれます。
結果から言うと、k3sにして本当にシュッとしました。今後の異機種・異環境をまたぐアーキテクチャ統合に向けて、見通しの良いクリーンな土台が出来上がりました。
ただ、その「ちゃちゃっと」終わるはずの移行作業の裏で、いくつかの地味なトラップに引っかかったんですよね。今回はその備忘録として、OS選びからk3s固有の罠、そして安全な移行のコツをまとめてみたいと思います。
OS選びの迷走：最新は正義か、それとも…？
クラスターを再構築するにあたり、せっかくならOSも新しくしようと思いました。
「最新こそ正義！」と意気込んで、リリースされたばかりのUbuntu 26.04 (Resolute) に手を出してみたんです。ところが、いざセットアップを始めると apt update が Waiting for headers のままピタッと止まってしまう絶望。
何度再起動してもダメ。「やはり最新版は罠が多いのか……インフラ構築における『急がば回れ』はいつの時代も真理だな」と悟った気になり、結局、安定の24.04 LTSにダウングレードする決断をしました。
知っておくと救われる apt の Tips（と、まさかの結末）
さて、安定の24.04 LTSに戻したものの、実はここでも全く同じaptの通信エラーに悩まされました。
「OSを戻したのにまたか……」と頭を抱えましたが、調べてみるとUbuntu 24.04以降、環境によってはデフォルトの http ミラーへの接続が不安定になることがあるようです。/etc/apt/sources.list.d/ubuntu.sources の http を https に書き換えるだけであっさり解決しました。
sudo sed -i 's/http:\/\/archive.ubuntu.com/https:\/\/archive.ubuntu.com/g' /etc/apt/sources.list.d/ubuntu.sourcesそしてここで気づいてしまったのです。 「あれ、これって26.04の不具合じゃなくて、単なるミラーの通信エラーだったんじゃ……？」
試しにもう一度 26.04 を入れ直し、このHTTPS化のワンライナーを実行してみたところ、見事にサクサク動きました。ダウングレードに溶かした時間は完全に無駄でした。結局、最新のUbuntu 26.04で元気に動いています。
こういう「勘違いによる遠回り」で地味なストレスが積もるので、このHTTPS化は初期セットアップのスクリプトに必ず組み込んでおくのが吉です。
K3sインストール
OSの準備ができたら、いよいよK3sのインストールです。
K3sはデフォルトでTraefikやServiceLBが同梱されていて、立ち上げればすぐに使えるのが強みです。しかし、我が家の環境ではこれまで通り独自のHelm Chart (Traefik + MetalLB) でIngressやロードバランサーを管理したかったので、これらは不要でした。
そこで、インストールのコマンドは以下のように「引き算」の構成にします。
curl -sfL https://get.k3s.io | sh -s - --disable traefik --disable servicelbこの一行で、余計なものを省いたプレーンなKubernetesが立ち上がります。自分たちでコントロールしたい部分を綺麗に切り離せるのは、K3sの設計の良さを感じます。
「コマンドが効かない！」Kubeconfigの罠
インストールが終わって、「よし、ノードを確認しよう」と kubectl get nodes を叩くと、エラーが返ってくる。
MicroK8sの microk8s kubectl というコマンド体系に慣れきっていたため、標準の kubectl や helm がどこを見に行っているのかをすっかり忘れていました。
K3sの場合、kubeconfigは /etc/rancher/k3s/k3s.yaml に生成されます。これを環境変数としてexportし、一般ユーザーでも読めるように権限を変更する「儀式」が必要です。
echo 'export KUBECONFIG=/etc/rancher/k3s/k3s.yaml' >> ~/.bashrcsudo chmod 644 /etc/rancher/k3s/k3s.yaml一度設定してしまえば終わりですが、これも移行時ならではの「あるある」な罠でした。
GitOps (Argo CD) の復活と「App-of-Apps」の強さ
ここまで来ればこっちのものです。クラスターにArgo CDさえ入れてしまえば、あとはGitに預けてある定義が勝手にアプリケーションを元の状態に戻してくれます。
ルートのアプリケーションを一つデプロイするだけで、芋づる式にすべてのインフラとアプリがデプロイされていく「App-of-Apps」。おすすめです。
TLS証明書の儀式：Stagingでの生存確認
移行に伴い、TraefikやCert-Managerも再構築されます。ここで絶対にやってはいけないのが、いきなり本番（Production）のLet’s Encrypt証明書を取りに行くことです。
過去に設定ミスを連発して、Let’s Encryptのレートリミット（発行制限）に引っかかり、数日間証明書が発行できなくなるという苦い経験をしたことがあります。シンプルに地獄です。
なので、再構築直後は必ず Let's Encrypt Staging Issuer に切り替えて、DNS-01チャレンジが正しく通るか、ダミーの証明書が発行されるかを確認します。
# 検証中は Staging を使用clusterIssuer: letsencrypt-staging-cloudflareブラウザでアクセスすると「安全ではありません」という警告は出ますが、このダミー証明書が正しく適用されていれば勝確です。動作確認ができたら、一行書き換えて本番へ切り替えます。
# 本番運用時はこちらclusterIssuer: letsencrypt-production-cloudflareこのワンクッションを置くだけで、精神的な安心感が段違いです。
まとめ
Ubuntuのバージョン選びやaptの通信エラー、Kubeconfigなど、いくつかのハマりどころはありましたが、それを乗り越えればk3sへの移行は本当に「ちゃちゃっと」終わるものでした。
MicroK8sは「とりあえず一番早くk8sを立てる」には最適ですが、Incus VMという仮想化レイヤーの上で、さらにMac Studioという異機種のGPUリソースをVirtual Kubelet経由で統合するような、高度でプログラマブルなインフラを目指すのであれば、軽量かつオープンで、エコシステムの恩恵を最大限に受けられる k3s こそが、その基盤に最もふさわしい選択だと実感しています。
「ちゃちゃっと移行」というスピード感の中に、レート制限に引っかからないための安全策といった「プロっぽさ」を少しだけ混ぜてみる。そんな週末のインフラいじりも悪くないですね。
もし、少し込み入ったアーキテクチャへの移行を検討している方がいれば、参考にどうぞ。
