2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Kubernetesを学ぶ9日間 - Day 2: Talos Linux入門 - SSH不要のImmutable Kubernetes OS

Last updated at Posted at 2025-12-04

はじめに

「ジャンルなしオンラインもくもく会 Advent Calendar 2025」の4日目の記事です。

本記事は、Kubernetesクラスタ構築シリーズの第2回です。今回は、Talos LinuxというImmutable OSについて解説します。

本シリーズの全体構成

前回のおさらい

12/3: Kubernetesアーキテクチャ完全ガイドでは、Kubernetesの基本アーキテクチャを学びました。

本記事で学べること

  • Immutable OSとは何か
  • Talos Linuxの特徴とアーキテクチャ
  • 従来のLinux(Ubuntu/RHEL系)との違い
  • Hyper-V対応の詳細
  • 明日の構築に向けた準備

1. Immutable OSとは

1.1 従来のMutable OS(変更可能なOS)

例: Ubuntu/Rocky Linux

# パッケージのインストール
apt-get install nginx

# 設定ファイルの直接編集
vi /etc/nginx/nginx.conf

# 手動でのサービス管理
systemctl start nginx

# SSH経由でログイン
ssh user@server

問題点

  • ❌ 構成ドリフト(時間経過で状態が不明瞭になる)
  • ❌ SSHによるセキュリティリスク
  • ❌ 手動操作によるヒューマンエラー
  • ❌ 再現性の欠如

1.2 Immutable OS(変更不可能なOS)

特徴

  • ✅ ファイルシステムが読み取り専用
  • ✅ SSH不要(API駆動)
  • ✅ 宣言的な設定管理
  • ✅ 更新は「全部成功」か「全部失敗」(中途半端な状態にならない)

2. Talos Linux の特徴

2.1 コア機能

特徴 説明
SSH不要 全ての操作はAPI経由(gRPC)
超軽量 わずか約200MBのディスクフットプリント
API駆動 talosctl CLI または Kubernetes API で管理
セキュアブート UEFI Secure Boot対応
自動更新 ローリングアップデート対応

2.2 従来のLinuxとの比較

項目 Ubuntu/Rocky Linux Talos Linux
SSH ✅ 利用可能 ❌ 不要
パッケージマネージャ apt/yum ❌ なし
シェルアクセス ✅ bash/zsh ❌ なし
設定方法 ファイル編集 YAML定義
管理方法 手動 API駆動
ディスクサイズ 数GB 約200MB
アップデート 手動 自動

2.3 Talos Linuxのアーキテクチャ


3. Talos Linux の管理方法

3.1 talosctl CLI

Talos Linux の管理は全て talosctl コマンドで行います。SSH の代わりとなる統合管理ツールです。

# バージョン確認
$ talosctl version
Client:
  Tag:         v1.11.5
  SHA:         a1e5a5d
  Built:       2025-11-06T10:00:00Z
Server:
  NODE         v1.11.5
  etcd         3.5.13
  kubelet      v1.34.1

3.2 主要コマンド一覧

コマンド 説明 用途
talosctl dashboard リアルタイムダッシュボード システム監視
talosctl logs ログ表示 トラブルシューティング
talosctl service サービス状態確認 ヘルスチェック
talosctl get リソース取得 設定確認
talosctl apply-config 設定適用 構成変更
talosctl upgrade OSアップグレード バージョンアップ
talosctl reset ノードリセット 再構築

ダッシュボード表示

# リアルタイムでシステム状態を監視
$ talosctl dashboard --nodes 10.0.0.101
talos-2ge-d6m (v1.11.5): uptime 300h45m58s, 2x3.49GHz, 3.8 GiB RAM, PROCS 34, CPU 7.7%, RAM 36.8%

 UUID       82020287-e644-0442-8840-17dbdbe37e54                               TYPE               controlplane                     HOST         talos-2ge-d6m
 CLUSTER    homelab-k8s (4 machines)                                           KUBERNETES         v1.34.1                          IP           10.0.0.101/24, 2400:4152:95c1:7e00:215:5dff:fe00:c45/64,
 SIDEROLINK n/a                                                                KUBELET            √ Healthy                        2400:4152:9860:dc00:215:5dff:fe00:c45/64
 STAGE      √ Running                                                          APISERVER          √ Healthy                        GW           10.0.0.1, fe80::9296:f3ff:fec5:b8f0
 READY      √ True                                                             CONTROLLER-MANAGER √ Healthy                        CONNECTIVITY √ OK
 SECUREBOOT × False                                                            SCHEDULER          √ Healthy                        DNS          10.0.0.1
── Logs ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 "enx00155d000c45"}
 user: warning: [2025-12-01T04:11:28.386758933Z]: [talos] updated etcd peer URLs {"component": "controller-runtime", "controller": "etcd.AdvertisedPeerController", "new_peer_urls": ["https://
 10.0.0.101:2380"], "member_id": 4962503959072242187}
 user: warning: [2025-12-01T04:11:33.981105933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:49912->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:11:33.981213933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:42172->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:11:35.982482933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:39239->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:11:35.982525933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:48088->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:11:35.982723933Z]: [talos] hello failed {"component": "controller-runtime", "controller": "cluster.DiscoveryServiceController", "error": "rpc error: code = Unavailable desc =
 dns: A record lookup error: lookup discovery.talos.dev on 127.0.0.53:53: server misbehaving", "endpoint": "discovery.talos.dev:443"}
 user: warning: [2025-12-01T04:12:08.336455933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:33823->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:12:08.336516933Z]: [talos] error serving dns request {"component": "dns-resolve-cache", "error": "read udp 10.0.0.101:46676->10.0.0.1:53: i/o timeout"}
 user: warning: [2025-12-01T04:12:08.517655933Z]: [talos] hello failed {"component": "controller-runtime", "controller": "cluster.DiscoveryServiceController", "error": "rpc error: code = Unavailable desc =
 connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match discovery.talos.dev\"", "endpoint":
 "discovery.talos.dev:443"}

[10.0.0.101] --- [Summary] --- [F2: Monitor]──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

ダッシュボードでは以下の情報が確認できます

  • CPU / メモリ使用率
  • 各サービスのステータス(apid, machined, kubelet など)
  • ネットワーク情報
  • ディスク使用量

ログ確認

# 特定サービスのログを確認
$ talosctl logs kubelet --nodes 10.0.0.101

# リアルタイムでログを追跡
$ talosctl logs kubelet --nodes 10.0.0.101 -f

サービス状態確認

$ talosctl service --nodes 10.0.0.101
SERVICE      STATE     HEALTH   LAST CHANGE
apid         Running   OK       5h ago
containerd   Running   OK       5h ago
etcd         Running   OK       5h ago
kubelet      Running   OK       5h ago
machined     Running   OK       5h ago

3.3 設定の適用方法

machine.yaml(宣言的な設定)

version: v1alpha1
machine:
  type: controlplane
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.11.5
  network:
    hostname: talos-cp-1
    interfaces:
      - interface: eth0
        dhcp: true
  kubelet:
    image: ghcr.io/siderolabs/kubelet:v1.34.1
cluster:
  network:
    cni:
      name: flannel
    podSubnets:
      - 10.244.0.0/16
    serviceSubnets:
      - 10.96.0.0/12
  controlPlane:
    endpoint: https://10.0.0.101:6443

適用コマンド

# 設定の適用
talosctl apply-config --insecure \
  --nodes 10.0.0.101 \
  --file machine.yaml

# ブートストラップ(初回のみ)
talosctl bootstrap --nodes 10.0.0.101

# kubeconfigの取得
talosctl kubeconfig --nodes 10.0.0.101

4. Hyper-V対応の詳細

4.1 公式サポート状況

Talos Linux は Hyper-V を公式サポートしています。

公式サイト: https://www.talos.dev/v1.11/talos-guides/install/virtualized-platforms/hyper-v/


4.2 Hyper-V での構築手順(概要)

明日(12/5)の記事で詳しく解説しますが、大まかな流れは以下の通りです。

Step 1: 準備

# ISOイメージのダウンロード
curl -LO https://github.com/siderolabs/talos/releases/download/v1.11.5/metal-amd64.iso

Step 2: VM作成(PowerShell)

# Hyper-V Virtual Switch の作成
New-VMSwitch -Name "LAB" -NetAdapterName "Ethernet" -AllowManagementOS $true

# Talos VM の作成(公式 PowerShell モジュール使用)
New-TalosVM -Name "talos-cp-1" -Switch "LAB" -Memory 4GB -CPU 2
New-TalosVM -Name "talos-worker-1" -Switch "LAB" -Memory 4GB -CPU 2
New-TalosVM -Name "talos-worker-2" -Switch "LAB" -Memory 4GB -CPU 2
New-TalosVM -Name "talos-worker-3" -Switch "LAB" -Memory 4GB -CPU 2

Step 3: Maintenance 状態

VMを起動すると、以下のような画面が表示されます。

Talos Linux - Maintenance状態

STAGE: Maintenance は設定待ち状態を示しています。この状態で talosctl apply-config を実行します。

Step 4: 設定適用とブートストラップ

# 設定の適用
talosctl apply-config --insecure --nodes <IP> --file controlplane.yaml

# ブートストラップ(Control Planeのみ、初回のみ)
talosctl bootstrap --nodes <IP>

# Worker ノードにも設定適用
talosctl apply-config --insecure --nodes <WORKER_IP> --file worker.yaml

Step 5: Running 状態

Bootstrap が完了すると、以下のような画面に変わります。

Talos Linux - Running状態

STAGE: Running に変わり、全コンポーネントが Healthy になれば構築完了です。

重要なポイント

  • ✅ Bootstrap完了後にISO除去必須(再起動時にISOからブートしてしまうため)
  • ✅ Virtual SwitchはExternal推奨(ホストネットワークと通信するため)
  • ✅ 最小4ノード構成(CP x1 + Worker x3)

5. Talos Linux のユースケース

5.1 適しているケース

  • ✅ セキュリティ要件が高い環境
  • ✅ 複数クラスタの統一管理
  • ✅ エッジコンピューティング(軽量)
  • ✅ GitOps / Infrastructure as Code

5.2 適していないケース

  • ❌ デバッグ目的でSSHが必要
  • ❌ カスタムカーネルモジュール
  • ❌ レガシーなシステム依存

6. セキュリティ上の利点

6.1 攻撃対象領域の削減

効果

  • ✅ SSH経由の攻撃を完全に排除
  • ✅ パッケージマネージャの脆弱性なし
  • ✅ シェルアクセス不可

6.2 証明書ベースの認証

# talosconfig(クライアント証明書)
$ cat ~/.talos/config
context: default
contexts:
  default:
    endpoints:
      - 10.0.0.101
    ca: LS0t...  # CA証明書
    crt: LS0t... # クライアント証明書
    key: LS0t... # 秘密鍵

セキュリティポイント

  • mTLS(相互TLS)による認証
  • パスワード不要
  • 証明書のローテーション対応

7. Talos Linux のライフサイクル管理

Talos Linux のノード管理は全て API 経由で行います。従来の SSH + systemctl による管理から解放されます。

7.1 アップグレード

Talos Linux のアップグレードは、ローリングアップデート方式で行われます。

📖 詳細は 公式ドキュメント: Upgrading Talos を参照してください。

# コマンド例(公式ドキュメントより)

# 現在のバージョン確認
$ talosctl version --nodes 10.0.0.101

# アップグレード実行
$ talosctl upgrade --nodes 10.0.0.101 \
  --image ghcr.io/siderolabs/installer:v1.11.5

# 複数ノードを順番にアップグレード
$ talosctl upgrade --nodes 10.0.0.102,10.0.0.103,10.0.0.104 \
  --image ghcr.io/siderolabs/installer:v1.11.5

アップグレードの特徴

  • ✅ ダウンタイムなし(ローリングアップデート)
  • ✅ 失敗時は自動ロールバック
  • ✅ Kubernetes コンポーネントも同時更新

7.2 再起動とシャットダウン

# ノードの再起動
$ talosctl reboot --nodes 10.0.0.101

# ノードのシャットダウン
$ talosctl shutdown --nodes 10.0.0.101

⚠️ Control Plane ノードの再起動時は、etcd のクォーラムに注意してください。


7.3 設定変更

設定変更も apply-config コマンドで宣言的に行います。

# 設定ファイルを編集後、適用
$ talosctl apply-config --nodes 10.0.0.101 --file controlplane.yaml

# 設定変更のモード
#   --mode=auto     : 変更内容に応じて自動判断(デフォルト)
#   --mode=reboot   : 再起動が必要
#   --mode=no-reboot: 再起動なしで適用

7.4 ノードのリセット

ノードを初期状態に戻す場合は reset コマンドを使用します。

# ノードをリセット(データ消去)
$ talosctl reset --nodes 10.0.0.102 --graceful

# 強制リセット(応答がない場合)
$ talosctl reset --nodes 10.0.0.102 --graceful=false

⚠️ リセットを実行すると、そのノードのデータは全て消去されます。


8. 他のImmutable OSとの比較

OS 対象環境 特徴
Talos Linux 汎用 SSH不要、Kubernetes専用
Flatcar Container Linux 汎用 CoreOS後継、Docker/Kubernetes
Bottlerocket (AWS) AWS AWS最適化、自動更新
RancherOS 汎用 Docker中心(開発終了)

Talos Linuxを選ぶ理由

  • ✅ Kubernetes専用設計
  • ✅ API駆動で自動化しやすい
  • ✅ 活発な開発コミュニティ
  • ✅ マルチプラットフォーム対応(Hyper-V含む)

9. よくある質問(FAQ)

Q1: SSHできないのにトラブルシューティングはどうする?

talosctlコマンドで全ての情報にアクセスできます。

# システムログの確認
$ talosctl logs kubelet --nodes 10.0.0.101

# リアルタイムダッシュボード
$ talosctl dashboard --nodes 10.0.0.101

# dmesg(カーネルログ)
$ talosctl dmesg --nodes 10.0.0.101

# プロセス一覧
$ talosctl processes --nodes 10.0.0.101

Q2: 設定ミスをしたらどうなる?

📖 詳細は 公式ドキュメント: Configuration を参照してください。

  • 設定に文法エラーがあれば、適用前にエラーが返される
  • 最悪の場合はtalosctl resetで初期化可能
# 設定のバリデーション(適用前にチェック)
# ※ 完全な machine config ファイルが必要(パッチファイルは不可)
$ talosctl validate --config controlplane.yaml --mode metal

# パッチファイルの場合は gen config で生成後に検証
$ talosctl gen config my-cluster https://10.0.0.101:6443 \
  --config-patch @patches/controlplane.yaml

Q3: カスタムカーネルモジュールは使える?

基本的には使えません。Talos Linuxは最小限のカーネルモジュールのみを含んでいます。

ただし、System Extensionsを使って一部のモジュールを追加できます。

# machine.yaml での System Extensions 設定例
machine:
  install:
    extensions:
      - image: ghcr.io/siderolabs/iscsi-tools:v0.1.4

対応しているExtensionsはTalos Extensions リポジトリで確認できます。


Q4: コンソール画面からは何もできない?

Talosのコンソール画面はモニタリング専用です。キーボード入力は受け付けません。

表示される情報

  • ステージ(Maintenance/Running)
  • ノード情報(ホスト名、IP)
  • サービス状態(kubelet,etcd等)
  • リソース使用率

全ての操作は別端末からtalosctlで行います。


10.Talos Linuxのエコシステム

Talos Linuxには公式の管理ツールも用意されています。

  • Omni: 複数クラスタを一元管理できるSaaS
  • Sidero Metal: ベアメタル環境向けのCluster APIプロバイダー

本シリーズではtalosctlで十分ですが、大規模運用時の選択肢として覚えておくと良いでしょう。


11. 次回: Terraformでクラスタ構築

明日(12/5)は、Terraform × Hyper-Vで実際にTalos Linuxクラスタを構築します。

学べること

  • Terraform Provider for Hyper-Vの使い方
  • Talos Linuxのブートストラップ手順
  • 外部端末からのリモート管理

準備しておくこと

  • WindowsマシンにHyper-Vを有効化
  • Terraformのインストール(Mac側)
  • talosctlのインストール(Mac側)
# MacでTerraform & taloscliのインストール
brew install terraform
brew install siderolabs/tap/talosctl

まとめ

本記事では、Talos LinuxというImmutable OSについて解説しました。

重要ポイント

  1. ✅ Immutable OS = 構成ドリフト防止
  2. ✅ SSH不要 = セキュリティリスク削減
  3. ✅ API駆動 = 自動化しやすい
  4. ✅ Hyper-V公式対応 = Windows環境で実践可能

所感

自宅でKubernetesを運用するのは、正直ハードルが高いと感じていました。従来のLinuxではSSHでログインしてパッケージを更新し、設定ファイルを編集 or Ansibleで設定という作業が必要で、いつの間にか放置...

今回Talos LinuxのようなImmutable OSでその状況が変わりました。API経由で宣言的に管理できるため、VMware ESXivSphere Clientで操作するような感覚でクラスタを扱えます。


参考リンク

2
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?