Kubernetes向けTalos Linuxのデプロイ：安全で最小限のイミュータブルOS

Table of Contents

背景と導入の理由

日曜日の深夜2時15分、PagerDutyからSev-1アラートが発報されます。本番クラスタ内の3台のワーカーノードがNodeNotReadyを報告しています。原因を調査すべくSSHでログインしたところ、金曜日のシフト中にエンジニアが手動でapt-get upgradeを実行していたことが判明しました。そのアップデートによって共有glibc依存関係のバージョンが上がり、kubeletランタイムが破損してしまっていたのです。構成ドリフト（設定の乖離）が密かに進行し、スケジューラが定期デプロイを試みるまで誰もその異常に気づきませんでした。

UbuntuやDebian、RHELといった汎用ディストリビューションは、本来コンテナを実行するためだけに設計されたものではありません。パッケージマネージャ、systemdユニット、対話型シェル、ユーザーアカウント、そして数千もの動的依存関係がバンドルされています。ディスク上の変更可能なコンポーネントはすべて、攻撃ベクトルとなり運用上のリスク要因となります。

Talos Linuxは、この従来型モデルを完全に排除します。Kubernetes専用に設計された、目的特化型のイミュータブル（不変）オペレーティングシステムです：

SSHやシェルの完全排除： bashやPythonインタプリタは存在せず、ポート22で待ち受けるSSHデーモンもありません。対話型のログインや、稼働中バイナリへのホットパッチ適用は不可能です。
読み取り専用SquashFSルート： コアOSはRAM上の読み取り専用ファイルシステムに起動します。一時的な状態は分離され、マルウェアの永続化や不正なディスク書き込みを防ぎます。
API駆動型の管理： ネットワークのセットアップからカーネルのsysctlチューニングに至るまで、すべての運用タスクはtalosctlと相互TLS（mTLS）を使用し、ポート50000のセキュアなgRPC API経由で実行されます。
極めて小さなフットプリント： インストールイメージ全体のサイズは約80MBで、一般的なエンタープライズLinuxディストリビューション（1.5〜2.5GB）と比べて極小です。Linuxカーネル、GoベースのカスタムPID 1 initシステム、containerd、およびコアKubernetesコンポーネントのみがパッケージ化されています。

イミュータブルOSを採用することで、構成ドリフトを根本から排除できます。ノードに不具合が発生しても、破損したシステムパッケージのデバッグに何時間も費やす必要はありません。ノードを初期化するか、クリーンなイメージを再ロールアウトするだけで済みます。

インストール

Talosクラスタは、ローカルワークステーションから2つのバイナリを使用して宣言的に管理します。OS管理用のtalosctlと、ワークロードオーケストレーション用のkubectlです。

1. talosctlと前提ツールのインストール

公式のtalosctlクライアントをダウンロードします：

# 最新のtalosctlバイナリをダウンロードしてインストール
curl -sL https://talos.dev/install | bash

# クライアントのバージョンを確認
talosctl version --client

2. クラスタ構成ファイルの生成

Talosでは、手動のインストールウィザードの代わりに宣言型のYAML設定ファイルを使用します。コントロールプレーンとワーカーノードの両方について、暗号署名されたマシン設定を事前生成します。

この例では、コントロールプレーンのエンドポイントを192.168.1.100:6443、ワーカーノードを192.168.1.101、クラスタ名をtalos-prod-01とします：

# PKIシークレットとマシン構成ファイルを生成
talosctl gen config talos-prod-01 https://192.168.1.100:6443 \
  --output-dir ./_out

このコマンドを実行すると、./_outディレクトリ内に4つの重要なファイルが出力されます：

controlplane.yaml: コントロールプレーンインスタンス用のマシン構成（etcd、kube-apiserver、kube-controller-managerを実行）。
worker.yaml: コンテナワークロードを実行するコンピュートノード用のマシン構成。
talosconfig: talosctl用クライアント証明書を含む管理者認証情報。
secrets.yaml: ルート証明書、暗号化キー、ブートストラップトークン。

3. Talos Linuxイメージでノードを起動

対象の物理ハードウェア、Proxmox VM、またはクラウドインスタンス（AWS AMI、GCP、Hetznerなど）を公式のTalos ISOまたはRAWディスクイメージから起動します。初回起動時、Talosはメンテナンスモードに入り、ポート50000でgRPC APIを公開して設定データの受信を待機します。

構成

インスタンスへのネットワーク疎通が確認できたら、生成した構成をgRPC経由で直接ノードに送信します。

1. ローカルtalosctlコンテキストの設定

ワークステーションのCLIで、生成されたtalosconfigを指定し、対象ノードのエンドポイントを設定します：

# talosctlの参照先を生成された構成ファイルに設定
export TALOSCONFIG="./_out/talosconfig"

# デフォルトの対象エンドポイントとノードを設定
talosctl config endpoint 192.168.1.100
talosctl config node 192.168.1.100

2. ノードへのマシン構成の適用

YAML定義を各マシンに送信します。Talosはスキーマを検証し、対象ドライブ（例: /dev/sdaや/dev/nvme0n1）にOSをインストールして自動的に再起動します。

# コントロールプレーンノードに構成を適用
talosctl apply-config --insecure \
  --nodes 192.168.1.100 \
  --file ./_out/controlplane.yaml

# ワーカーノードに構成を適用
talosctl apply-config --insecure \
  --nodes 192.168.1.101 \
  --file ./_out/worker.yaml

注: --insecureフラグは、ノード固有のTLS証明書が確立される前の初期ハンドオフ時にのみ必要です。

3. etcdおよびKubernetesコントロールプレーンのブートストラップ

コントロールプレーンノードが再起動したら、1つのコマンドで単一ノードまたはマルチノードのetcdクラスタを初期化します：

# 初回限りのetcdクラスタ初期化を実行
talosctl bootstrap --nodes 192.168.1.100

これによりPID 1スーパーバイザが起動され、etcdの立ち上げ、静的Podマニフェストの初期化、そしてKubernetes APIサーバーの起動が順次行われます。

4. kubeconfigの取得

クラスタ内部のPKIに対して認証された管理者用kubeconfigを生成します：

# Talos API経由で管理者用kubeconfigを直接ダウンロード
talosctl kubeconfig ./kubeconfig --nodes 192.168.1.100
export KUBECONFIG="$(pwd)/kubeconfig"

# クラスタへのアクセスを確認
kubectl get nodes -o wide

検証とモニタリング

ノード上にはsystemctl、top、journalctlといった従来の診断ユーティリティが存在しないため、すべてのトラブルシューティングはtalosctlを通じて行います。

1. コアサービスとランタイムログの確認

Talosによって直接管理されているコアサービス（machined、containerd、kubeletなど）の健全性を確認します：

# すべての内部Talos OSサービスと稼働状態を一覧表示
talosctl services --nodes 192.168.1.100

# kubeletサービスからリアルタイムログをストリーミング
talosctl logs kubelet --nodes 192.168.1.100 --tail 50

2. 組み込みターミナルダッシュボード

Talosにはリアルタイムのターミナルダッシュボードが付属しています。サードパーティの監視エージェントを導入することなく、CPU負荷、メモリ使用率、ネットワークスループット、コンテナの状態を追跡できます：

# 対話型ターミナルUIを起動
talosctl dashboard --nodes 192.168.1.100

3. etcdのヘルス状態とハードウェアステータスの確認

コントロールプレーンのトラブルシューティング時には、低レイヤのetcdヘルス状態やシステムリソースを直接照会できます：

# etcdメンバーシップとリーダーの健全性を確認
talosctl etcd status --nodes 192.168.1.100

# アクティブなネットワークインターフェースとストレージマウントを確認
talosctl get interfaces --nodes 192.168.1.100
talosctl get disks --nodes 192.168.1.100

4. アトミックでダウンタイムのないOSアップグレード

Talos Linuxのアップグレードでは、個々のパッケージを変更することはありません。代わりに、デュアルA/Bパーティションを使用してOSイメージ全体をアトミック（不可分）に切り替えます：

# ワーカーノードでアトミックなOSアップグレードを実行
talosctl upgrade \
  --nodes 192.168.1.101 \
  --image ghcr.io/siderolabs/installer:v1.8.0 \
  --preserve=true

この処理中、TalosはKubernetes経由で実行中のワークロードを安全に退避（drain）させ、もう一方のパーティションに新しいイメージを書き込み、15〜30秒以内に再起動して組み込みのヘルスチェックを実行します。万が一新しいカーネルの初期化に失敗した場合、ブートローダは以前の正常なパーティションへと自動的にロールバックします。