k3s完全ガイド：特徴から導入、基本的な使い方まで

By /

はい、承知いたしました。K3sの完全ガイドとして、特徴、導入、基本的な使い方を中心に、約5000語の詳細な技術記事を作成します。

K3s 完全ガイド：特徴から導入、基本的な使い方まで

はじめに：Kubernetesの軽量化がなぜ必要か、そしてK3sとは

Kubernetesは、コンテナ化されたワークロードを自動でデプロイ、スケーリング、管理するための強力なプラットフォームです。クラウドネイティブ時代の基盤として広く採用されています。しかし、その柔軟性と機能性の高さゆえに、従来のKubernetes（しばしば「バニラKubernetes」や「upstream Kubernetes」と呼ばれます）は、比較的多くのリソース（CPU、メモリ、ストレージ）と複雑なセットアッププロセスを要求します。これは、大規模なデータセンターやパブリッククラウド環境には適していますが、リソースが限られている環境や、迅速な開発・テスト環境には課題となることが少なくありませんでした。

具体的には、以下のようなシナリオで従来のKubernetesの課題が顕在化します。

  1. エッジコンピューティング/IoTデバイス: 工場、店舗、車両、センサーネットワークなど、リソースが制約され、ネットワーク接続が不安定な環境でアプリケーションを実行する場合、Kubernetesの複雑な構成とリソース消費は大きな負担となります。
  2. 開発/テスト環境: 開発者のローカルマシンやCI/CDパイプライン上でKubernetesクラスターを立ち上げる際、軽量で簡単にセットアップできる環境が求められます。MinikubeやKindのようなツールもありますが、より本番に近い形での軽量クラスターが必要な場合があります。
  3. ブランチオフィス/リモートロケーション: データセンターではない小規模な拠点にKubernetesクラスターを設置する場合、運用の容易さとリソース効率が重要になります。
  4. 学習目的: Kubernetesの学習を始めたい人が、手軽に実験できる環境を求めている場合。

これらの課題に応えるために開発されたのが、軽量Kubernetesディストリビューションである K3s です。Rancher Labs (現在はSUSEの一部) によって開発されたK3sは、「プロダクションでの利用に適した最小限のKubernetes」を標榜し、上記のあらゆるシナリオでKubernetesを利用可能にすることを目的としています。

K3sは、従来のKubernetesから不要な機能を削ぎ落とし、シングルバイナリとして提供することで、劇的な軽量化と導入の容易さを実現しています。本記事では、このK3sに焦点を当て、その特徴、アーキテクチャ、詳細な導入方法、そして基本的な使い方を網羅的に解説することで、「K3s完全ガイド」とすることを目標とします。この記事を読み終える頃には、あなたがK3sを理解し、自身のプロジェクトや環境で活用するための知識とスキルが身についているでしょう。

K3sの主な特徴

K3sが従来のKubernetesと一線を画す、その独自の特徴を見ていきましょう。これらの特徴が、K3sを特定のユースケースで非常に強力な選択肢としています。

1. 極限までの軽量化

  • シングルバイナリ: K3sの最大の特徴は、Control PlaneとWorker Nodeの必要なコンポーネントの大部分が、わずか約50MB程度の単一のバイナリにまとめられている点です。これにより、配布、インストール、および管理が非常に容易になります。従来のKubernetesのように、個別のコンポーネント（kube-apiserver, kube-controller-manager, kube-scheduler, etcdなど）を個別にインストール・設定する必要がありません。
  • 不要なコンポーネントの削除: 従来のKubernetesに含まれる、多くのクラウドプロバイダー固有の統合、不要な機能（例: In-tree Volume Provisionerの多く）、およびアルファ/ベータ機能の一部が削除されています。これにより、バイナリサイズとリソース消費量が大幅に削減されています。
  • etcdの代替オプション: Kubernetesの主要なコンポーネントの一つである分散キーバリューストア etcd は、リソース消費が比較的高く、運用も複雑になりがちです。K3sはデフォルトで etcd の代わりに軽量な SQLite3 をデータストアとして利用します。これにより、単一ノードクラスターのセットアップが極めて簡単になります。ただし、高可用性が求められるマルチノードクラスター構成では、PostgreSQLやMySQLなどの外部データベース、あるいは組み込みのetcdを利用するオプションも提供されています。
  • 最小限のリソース要件: これらの軽量化により、K3sは非常に少ないリソースで動作します。公式ドキュメントによれば、最小構成ではわずか512MBのRAMで動作可能とされています（もちろん、デプロイするアプリケーションによりますが）。これは、Raspberry Piのようなシングルボードコンピューターや、VMware Fusion/VirtualBox上の小さな仮想マシンでも快適にKubernetesクラスターを構築できることを意味します。

2. 圧倒的な導入の容易さ

  • シェルスクリプトによるワンステップインストール: K3sのインストールは、提供されているシェルスクリプトを実行するだけで完了します。curl ... | sh - といったコマンド一本で、Server（Control Plane）またはAgent（Worker Node）をセットアップできます。数分以内に動作するKubernetesクラスターを手に入れることができます。
  • 組み込みコンポーネント: インストールスクリプトには、Containerd（コンテナランタイム）、CoreDNS（サービスディスカバリ）、Traefik（デフォルトIngressコントローラー）、Klipper-lb（Service Type=LoadBalancerの実装）、Local Path Provisioner（デフォルトストレージクラス）など、Kubernetesクラスターの運用に必要な基本的なコンポーネントが組み込まれています。これらの設定やインストールを個別に行う必要がありません。
  • 自動証明書管理: クラスター内部で利用されるTLS証明書は、インストール時に自動生成および管理されます。外部向けサービスにはLet’s Encryptとの連携も可能です。

3. プロダクションレベルの高可用性 (HA)

  • 単一ノード構成は非常に簡単ですが、K3sはプロダクション環境に必要な高可用性構成もサポートしています。
  • 外部データベースサポート: 前述の通り、デフォルトのSQLite3は単一ノード向けですが、PostgreSQLやMySQL/MariaDBを外部データベースとして利用することで、複数のK3s Serverノードで同じ状態を共有し、HA構成を構築できます。
  • 組み込みetcd: よりKubernetes標準に近いHA構成として、組み込みのetcdクラスタを利用するオプションも選択できます。この場合、3台以上のServerノードで冗長性を確保します。
  • Server/Agentアーキテクチャ: HA構成では、複数のServerノードがControl Planeを構成し、AgentノードがWorkerとしてコンテナを実行します。Serverノードがダウンしても、他のServerノードがクラスターの操作を引き継ぎます。

4. セキュリティ

  • デフォルトでのセキュリティ設定: K3sはデフォルトでセキュリティを意識した設定が適用されています。
  • 証明書管理: 内部証明書は自動で管理され、外部サービスにはLet’s Encryptとの連携機能も組み込まれています。
  • 最小権限: 必要な権限のみを持つユーザーで動作するように設計されています。

5. エッジ/IoT/開発環境への最適性

  • リソースの制約が厳しい環境でも動作する軽量性。
  • シェルスクリプトによる簡単なデプロイと運用。
  • ARM64およびARMv7アーキテクチャのサポート（Raspberry Piなど）。
  • ネットワーク接続が限定される環境向けのオフラインインストールオプション。

6. エンタープライズ対応と拡張性

  • Rancher Labs / SUSEによるエンタープライズサポートが提供されています。
  • Kubernetesの標準APIに準拠しており、kubectlなどの標準ツールが利用できます。
  • Helmチャートを利用したアプリケーションデプロイや、Kubernetesのカスタムリソース定義（CRDs）を利用した機能拡張も可能です。
  • CNI（Container Network Interface）、CSI（Container Storage Interface）インターフェースに対応しており、必要に応じてデフォルト以外のネットワークやストレージのプラグインを利用できます。

これらの特徴により、K3sは単なる「軽量版」ではなく、特定のユースケースにおいては従来のKubernetesよりも優れた選択肢となり得る、独立した強力なKubernetesディストリビューションとなっています。

K3sのアーキテクチャ

K3sは、従来のKubernetesアーキテクチャをベースとしながらも、軽量化とシンプル化のためにいくつかの重要な変更を加えています。

シングルバイナリの内部構成

K3sのバイナリは、Go言語で記述されており、以下の主要なコンポーネントを内蔵しています。

  • kube-apiserver: Kubernetes APIを提供します。
  • kube-controller-manager: クラスターの状態を監視し、desired stateに近づけるためのコントローラー群です。
  • kube-scheduler: 新しいPodをどのノードに配置するかを決定します。
  • containerd: コンテナランタイムです。Dockerは含まれていませんが、Dockerデーモンが実行されているノードにK3sエージェントをインストールすることも可能です（非推奨）。
  • CoreDNS: サービスディスカバリのためのDNSサーバーです。
  • Traefik: デフォルトのIngressコントローラーです。
  • Klipper-lb: Service Type=LoadBalancerをソフトウェアで実現するためのコンポーネントです。ノードポートを介して外部からのトラフィックをServiceに転送します。
  • Kube-routerまたはFlannel: デフォルトのCNIプラグインです。Kubernetes Pods間のネットワークを構築します。
  • Local Path Provisioner: PersistentVolumeClaimに対応するためのデフォルトStorageClassを提供します。ノッドレスターミナルマウントをPodのローカルストレージとして利用します。
  • Helm コントローラー: Helm ChartをKubernetesリソースとして管理するためのコントローラーです。
  • K3s Agent: Serverに接続し、kubelet（Podの実行とノードの状態報告）、kube-proxy（Serviceネットワーク）、およびContainerdを制御します。

Serverモードで起動すると、Serverに必要なコンポーネント（apiserver, scheduler, controller-manager, etcd代替など）が有効になり、Agentモードで起動すると、Agentに必要なコンポーネント（kubelet, kube-proxy, containerdなど）が有効になります。これにより、単一のバイナリでControl PlaneノードとWorkerノードの両方の役割を果たすことができます。

データストアオプション

K3sはKubernetesの状態を保存するためのデータストアとして、以下のオプションをサポートしています。

  • SQLite3: デフォルトのデータストアです。単一のK3s Serverノード構成に最適で、セットアップが最も簡単です。ファイルシステム上に単一のファイルとして保存されます。
  • PostgreSQL: 外部データベースとして利用できます。複数のK3s ServerノードによるHA構成を構築する場合に推奨されます。
  • MySQL/MariaDB: PostgreSQLと同様に、外部データベースとしてHA構成で利用できます。
  • etcd: 組み込みのetcdクラスタを利用することも可能です。これもHA構成で利用できます。従来のKubernetesの知識を活かしたい場合や、パフォーマンス要件が高い場合に選択されることがあります。

データストアの選択は、クラスターの構成（単一ノードかHAか）と要件（シンプルさかパフォーマンスか）に依存します。

ServerとAgentの役割

  • K3s Server (Control Plane): Kubernetes Control Planeの役割を果たします。kube-apiserver, kube-controller-manager, kube-schedulerなどのコンポーネントを実行し、クラスターの状態を管理します。データストア（SQLite3, DB, etcd）と通信します。単一ノード構成では、ServerがControl PlaneとWorkerの両方の役割を兼ねます。HA構成では、複数のServerノードでControl Planeを構成します。
  • K3s Agent (Worker Node): アプリケーションコンテナを実行するWorkerノードの役割を果たします。kubelet, kube-proxy, containerdなどのコンポーネントを実行します。K3s Serverに接続し、Podの実行指示を受け取ったり、ノードの状態を報告したりします。Agentノードはデータストアには直接アクセスしません。

このアーキテクチャ図をイメージすると、K3s ServerがKubernetes APIを提供し、そのAPIに対してAgentノードが登録され、ワークロード（Pod）の実行要求を受けてコンテナを起動・管理する、という標準的なKubernetesの構成になっていることがわかります。異なるのは、それらのコンポーネントが軽量化され、一つのバイナリに凝縮されている点です。

K3sの導入

K3sの導入は非常に簡単です。ここでは、最も一般的なシェルスクリプトを使ったインストール方法を中心に解説し、HA構成やエージェントの追加方法にも触れます。

前提条件

K3sをインストールする前に、以下の前提条件を確認してください。

  • OS: K3sはLinuxカーネル上で動作します。以下の主要なLinuxディストリビューションをサポートしています。
    • Ubuntu (16.04 LTS 以降を推奨)
    • CentOS/RHEL (7 以降を推奨)
    • Raspbian/Raspberry Pi OS
    • SUSE Linux Enterprise Server (SLES)
    • その他、systemdまたはOpenRCをサポートする多くのLinuxディストリビューション
  • ハードウェア要件:
    • CPU: 1コア以上
    • RAM: 512MB以上 (ただし、デプロイするワークロードに大きく依存します。快適に利用するには1GB以上を推奨)
    • ストレージ: 1GB以上の空き容量 (データストア、コンテナイメージなど)
  • ネットワーク要件:
    • Serverノードは、Agentノードおよびkubectlクライアントからの接続を受け付ける必要があります。デフォルトでは以下のポートが利用されます。
      • TCP 6443: Kubernetes APIサーバー (Agentノードとkubectlクライアントからの接続)
      • TCP 2379-2380: 組み込みetcd (etcdを利用する場合)
      • TCP 8472: Flannel VXLAN (ノード間Podネットワーク)
      • TCP 10250: Kubelet (Prometheusなどの監視ツールが利用)
      • TCP 30000-32767: NodePort Services (デフォルトレンジ)
    • Agentノードは、ServerノードのTCP 6443に接続できる必要があります。
    • インターネットにアクセスできる環境が推奨されますが、オフラインインストールも可能です。

シェルスクリプトによる簡単インストール (単一ノード)

これがK3sの最も一般的なインストール方法です。インターネットに接続されたLinuxマシン上で、root権限を持つユーザーとして以下のコマンドを実行します。

bash
curl -sfL https://get.k3s.io | sh -

このコマンドは何をしているのか？

  1. curl -sfL https://get.k3s.io: K3sの公式インストールスクリプトをダウンロードします。-sはサイレントモード、-fはエラー時に失敗、-Lはリダイレクトをフォローするオプションです。
  2. | sh -: ダウンロードしたスクリプトを標準入力として受け取り、shコマンド（シェル）で実行します。

このスクリプトを実行すると、以下の処理が行われます。

  1. システム情報を確認し、適切なK3sバイナリをダウンロードします。
  2. K3sバイナリを /usr/local/bin/k3s にインストールします。
  3. K3sサービスを systemd (またはOpenRC) に登録し、自動起動するように設定します。
  4. K3sサービスを開始します。
  5. Kubernetesの設定ファイル (kubeconfig) を /etc/rancher/k3s/k3s.yaml に作成します。
  6. kubectl コマンドへのシンボリックリンクを /usr/local/bin/kubectl に作成します。
  7. crictl (Container Runtime Interface ツール) へのシンボリックリンクを作成します。

インストールが完了すると、以下のような出力が表示されます（バージョンによって異なる場合があります）。

[INFO] Downloading K3s from https://github.com/k3s-io/k3s/releases/download/v1.28.4+k3s1/k3s
[INFO] Installing K3s to /usr/local/bin/k3s
[INFO] Creating /usr/local/bin/kubectl symbolic link to K3s binary
[INFO] Creating /usr/local/bin/crictl symbolic link to K3s binary
[INFO] Creating /usr/local/bin/ctr symbolic link to K3s binary
[INFO] Installing service 'k3s'
[INFO] Skipping /usr/local/bin/kubectl symlink to /usr/local/bin/k3s, already exists.
[INFO] Skipping /usr/local/bin/crictl symlink to /usr/local/bin/k3s, already exists.
[INFO] Skipping /usr/local/bin/ctr symlink to /usr/local/bin/k3s, already exists.
[INFO] Generated /etc/rancher/k3s/k3s.yaml
[INFO] Additional user setup required for access to /etc/rancher/k3s/k3s.yaml
[INFO] run 'kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get nodes' to validate:

インストール後の確認:

インストールスクリプトの指示に従い、kubectlコマンドを使ってクラスターの状態を確認します。

bash
kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get nodes

または、環境変数 KUBECONFIG を設定して、より簡単に kubectl を実行できるようにします。

bash
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

出力は以下のようになるはずです。(node名) はホストマシンの名前です。STATUSがReadyになっていれば、Kubernetesクラスターが正常に起動しています。

NAME STATUS ROLES AGE VERSION
<node名> Ready control-plane,master 2m30s v1.28.4+k3s1

この単一ノード構成では、ServerノードがControl PlaneとWorkerノードの両方を兼ねています。

インストールオプション

インストールスクリプトは、環境変数を使うことで様々なオプションを指定できます。よく使うオプションをいくつか紹介します。

  • K3S_URL: エージェントを既存のサーバークラスターに参加させる場合に、サーバーのAPIエンドポイントを指定します。
  • K3S_TOKEN: クラスター参加のための共有トークンを指定します。サーバーインストール時に /var/lib/rancher/k3s/server/node-token に生成されます。
  • INSTALL_K3S_VERSION: インストールするK3sのバージョンを指定します (例: INSTALL_K3S_VERSION=v1.28.4+k3s1).
  • INSTALL_K3S_EXEC: K3sバイナリ実行時の追加コマンドライン引数を指定します (例: INSTALL_K3S_EXEC="--no- कुलकर्णी --disable traefik").
  • INSTALL_K3S_AGENT: エージェントのみをインストールします (例: INSTALL_K3S_AGENT=true).
  • INSTALL_K3S_NO_AGENT: サーバーをインストールしますが、エージェントはインストールしません (Server専用ノード).
  • INSTALL_K3S_NO_ENABLE: K3sサービスをインストールしますが、自動起動および即時起動はしません。
  • K3S_NODE_NAME: ノード名を指定します。
  • K3S_NODE_LABELS: ノードにラベルを追加します (例: K3S_NODE_LABELS="env=dev,tier=frontend").
  • K3S_NODE_TAINTS: ノードにテイントを追加します (例: K3S_NODE_TAINTS="node.kubernetes.io/disk-pressure=true:NoSchedule").
  • K3S_TOKEN_FILE: トークンをファイルから読み込みます。

例: Traefik (デフォルトIngressコントローラー) を無効にしてインストール

bash
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -

例: 特定バージョンをインストールし、ノード名を指定

bash
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.27.7+k3s1 K3S_NODE_NAME=my-server-node sh -

これらのオプションを組み合わせることで、様々な要件に合わせたインストールが可能です。

HA構成でのインストール

HA構成を構築するには、複数のK3s Serverノードと、必要に応じて複数のAgentノードを用意します。HA構成では、単一ノード構成のデフォルトであるSQLite3ではなく、PostgreSQL、MySQL、または組み込みetcdをデータストアとして利用する必要があります。

1. 外部データベース (PostgreSQL/MySQL) を利用する場合

  • データベースサーバーの準備: 外部のPostgreSQLまたはMySQL/MariaDBデータベースサーバーを事前にセットアップします。K3s Serverノードからアクセスできる必要があります。

  • 最初のServerノードのインストール: 最初のServerノードをインストールします。このとき、データベース接続情報を指定します。

    “`bash

    PostgreSQL の場合

    curl -sfL https://get.k3s.io | sh -s – server \
    –datastore-endpoint=’postgres://user:password@host:port/database’ \
    –tls-san <ロードバランサー/仮想IPまたはDNS名>
    “`

    “`bash

    MySQL の場合

    curl -sfL https://get.k3s.io | sh -s – server \
    –datastore-endpoint=’mysql://user:password@tcp(host:port)/database’ \
    –tls-san <ロードバランサー/仮想IPまたはDNS名>
    ``
    *    sh -s – server: インストールスクリプトに引数—以降を渡します。-sは標準入力からスクリプトを読み込みます。serverはServerモードでインストールすることを示します。
    *    –datastore-endpoint: データベース接続URLを指定します。
    *    –tls-san`: 複数のServerノードで構成されるHAクラスターの場合、APIエンドポイントとして利用するロードバランサーや仮想IP、またはDNS名を指定する必要があります。これにより、TLS証明書にその名前が含まれ、Agentノードやkubectlクライアントが安全に接続できます。

  • ロードバランサーの準備: 複数のServerノード間でトラフィックを分散するために、外部ロードバランサー（NGINX、HAProxy、クラウドプロバイダーのLB、仮想IPなど）を準備し、K3s ServerのTCP 6443ポートに転送するように設定します。--tls-san で指定したアドレスがこのロードバランサーのアドレスになるべきです。

  • 2台目以降のServerノードのインストール: 2台目以降のServerノードをインストールします。この際も同じデータベース接続情報を指定します。ロードバランサーの設定も行います。

    bash
    curl -sfL https://get.k3s.io | sh -s - server \
    --datastore-endpoint='...' \
    --tls-san <ロードバランサー/仮想IPまたはDNS名>
    特別なHAオプションは不要です。同じデータベースエンドポイントを指定することで、自動的に既存のクラスターに参加します。

  • Agentノードの追加: Serverノード群にエージェントノードを追加します。AgentはクラスターのAPIエンドポイント（ロードバランサーのアドレス）と、Serverノードから取得したクラスタートークンを知っている必要があります。

    “`bash

    Serverノードのいずれかでトークンを取得

    cat /var/lib/rancher/k3s/server/node-token

    Agentノードでインストール

    curl -sfL https://get.k3s.io | sh -s – agent \
    –server https://<ロードバランサー/仮想IPまたはDNS名>:6443 \
    –token
    ``
    *    sh -s – agent: Agentモードでインストールします。
    *    –server: 接続するK3s ServerのAPIエンドポイントを指定します。HA構成ではロードバランサーのアドレスを指定します。
    *    –token`: クラスター参加のためのトークンを指定します。

2. 組み込みetcdを利用する場合

HA構成で組み込みetcdを利用する場合、最低3台のK3s Serverノードが必要です（一般的なetcdの推奨構成に従います）。各Serverノードは互いに通信できる必要があります。

  • 最初のServerノードのインストール:

    bash
    curl -sfL https://get.k3s.io | sh -s - server \
    --cluster-init \
    --datastore-endpoint='etcd:///var/lib/rancher/k3s/server/db/etcd' \
    --tls-san <ロードバランサー/仮想IPまたはDNS名>
    * --cluster-init: このノードを新しいetcdクラスタの最初のメンバーとして初期化します。
    * --datastore-endpoint='etcd:///...': etcdをデータストアとして使用することを明示的に指定します。

  • ロードバランサーの準備: 外部DBの場合と同様にロードバランサーを準備し、ServerノードのTCP 6443に転送します。

  • 2台目以降のServerノードのインストール: 既存のetcdクラスタに参加させます。

    bash
    curl -sfL https://get.k3s.io | sh -s - server \
    --server https://<最初のServerノードのIP/ホスト名>:6443 \
    --token <最初のServerノードから取得したトークン> \
    --tls-san <ロードバランサー/仮想IPまたはDNS名>
    * --server: 参加するetcdクラスタの既存メンバー（通常は最初のノード）を指定します。インストール完了後、他のServerノードやロードバランサーのアドレスに変更しても構いません。
    * --token: Serverノード用のクラスタートークンです。最初のServerノードの /var/lib/rancher/k3s/server/token にあります (Agent用の node-token とは別のファイルです)。

  • Agentノードの追加: 外部DBの場合と同様に、ロードバランサーのアドレスと node-token を使ってAgentノードを追加します。

HA構成のセットアップは単一ノードより複雑ですが、シェルスクリプトと適切なオプション、そして外部の依存関係（DBまたはetcdクラスタ構成）を準備すれば比較的容易に構築できます。

オフラインインストール

インターネット接続が制限される環境向けに、オフラインインストールもサポートされています。

  1. 必要なファイルのダウンロード: インターネットに接続された環境で、インストールスクリプトと、対象アーキテクチャのK3sバイナリおよび必要なイメージをダウンロードします。

    “`bash

    スクリプトをダウンロード

    curl -sfL https://get.k3s.io -o install.sh

    インストールしたいバージョンを指定 (例: v1.28.4+k3s1)

    K3S_VERSION=v1.28.4+k3s1

    バイナリをダウンロード

    curl -sfL https://github.com/k3s-io/k3s/releases/download/${K3S_VERSION}/k3s -o k3s

    イメージをダウンロード (対象アーキテクチャを指定, 例: amd64)

    curl -sfL https://github.com/k3s-io/k3s/releases/download/${K3S_VERSION}/k3s-airgap-images-amd64.tar -o k3s-airgap-images-amd64.tar
    “`
    * 対象アーキテクチャ (amd64, arm64, armhf) に応じてイメージファイル名を変更してください。

  2. オフライン環境へのファイル転送: ダウンロードした install.sh, k3s, k3s-airgap-images-*.tar ファイルを、インストール先のオフライン環境に転送します。

  3. オフラインインストール: オフライン環境で、転送したファイルを使ってインストールします。

    “`bash

    バイナリとイメージファイルをインストールスクリプトと同じディレクトリに配置するか、

    k3sバイナリをPATHの通ったディレクトリに置き、

    イメージtarファイルを /var/lib/rancher/k3s/agent/images/ ディレクトリに置く

    インストールスクリプトに実行権限を付与

    chmod +x install.sh

    INSTALL_K3S_SKIP_DOWNLOAD=true を指定してインストールスクリプトを実行

    必要に応じて他のオプションも指定

    INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
    ``
    *    INSTALL_K3S_SKIP_DOWNLOAD=trueを指定することで、スクリプトはファイルのダウンロードをスキップし、ローカルにあるファイルを使用します。
    *    k3sバイナリは/usr/local/bin/k3s(デフォルト) に、イメージファイルはインストール中に/var/lib/rancher/k3s/agent/images/` に配置される必要があります。スクリプトはこれらの場所を自動的にチェックします。

エージェントノードの追加

既存のK3s ServerクラスターにAgentノードを追加するには、以下の手順を行います。

  1. Serverノードでトークンを取得: K3s Serverノードで、Agentノード参加用のトークンを取得します。

    bash
    sudo cat /var/lib/rancher/k3s/server/node-token
    このコマンドは、クラスタートークン（ランダムな文字列）を表示します。

  2. Agentノードでインストール: Agentとして参加させたいノードで、以下のコマンドを実行します。

    bash
    curl -sfL https://get.k3s.io | sh -s - agent \
    --server https://<ServerノードのIPまたはホスト名>:6443 \
    --token <Serverノードから取得したトークン>
    * <ServerノードのIPまたはホスト名> は、AgentノードからアクセスできるServerノードのIPアドレスまたはホスト名です。HA構成の場合はロードバランサーのアドレスを指定します。
    * <Serverノードから取得したトークン> には、ステップ1で取得したトークンの文字列を指定します。

インストールスクリプトは、Agentに必要なコンポーネントのみをインストールし、K3sサービスをAgentモードで起動します。Agentノードは指定されたServerに接続し、クラスターの一部として機能を開始します。

確認: Serverノードまたは kubectl が構成されたマシンから、kubectl get nodes を実行して、新しいAgentノードがクラスターに参加していることを確認します。

アンインストール

K3sにはアンインストールスクリプトが付属しています。

  • Serverのアンインストール:

    bash
    /usr/local/bin/k3s-uninstall.sh

  • Agentのアンインストール:

    bash
    /usr/local/bin/k3s-agent-uninstall.sh

これらのスクリプトは、K3sサービスを停止し、インストールされたファイルやディレクトリ（バイナリ、systemd unit、データディレクトリ /var/lib/rancher/k3s など）を削除します。ただし、PersistentVolumeによって作成されたデータなどは削除されない場合があるため注意が必要です。

K3sの基本的な使い方

K3sがインストールされ、クラスターが稼働したら、標準のKubernetesツールであるkubectlを使ってクラスターを操作できます。

kubectlコマンドの利用

K3sはインストール時に /usr/local/bin/kubectl に kubectl コマンドへのシンボリックリンクを作成します。また、クラスターへの接続設定ファイルである kubeconfig を /etc/rancher/k3s/k3s.yaml に生成します。

kubectl を使うには、以下のいずれかの方法で kubeconfig ファイルを指定する必要があります。

  1. --kubeconfig オプションを使う:

    bash
    kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get nodes
    この方法はコマンドごとに kubeconfig を指定する必要があります。

  2. 環境変数 KUBECONFIG を設定する:

    bash
    export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
    kubectl get nodes
    一度設定すれば、それ以降の kubectl コマンドはこの設定を使います。.bashrc や .profile ファイルに追加しておくと、ログイン時に自動的に設定されます。

  3. kubeconfig ファイルを標準の場所にコピー/リンクする:
    ~/.kube/config は kubectl がデフォルトで参照する場所です。

    bash
    mkdir ~/.kube
    sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
    sudo chown $(id -u):$(id -g) ~/.kube/config # 必要に応じてファイルの所有者を変更
    kubectl get nodes
    この方法が最も一般的で便利ですが、他のKubernetesクラスターの kubeconfig と競合する可能性がある場合は注意が必要です。

kubectl が使えるようになれば、Kubernetesの標準的な操作はすべて可能です。

  • ノードの確認: kubectl get nodes
  • すべてのPodの確認 (全てのNamespace): kubectl get pods --all-namespaces
  • 特定のNamespaceのPodの確認: kubectl get pods -n <namespace名>
  • Deploymentの確認: kubectl get deployments
  • Serviceの確認: kubectl get services
  • Ingressの確認: kubectl get ingress
  • リソースの作成: kubectl apply -f <ファイル名.yaml>
  • リソースの削除: kubectl delete -f <ファイル名.yaml> または kubectl delete <リソースタイプ> <リソース名>
  • Podのログ確認: kubectl logs <pod名>
  • Pod内のコマンド実行: kubectl exec -it <pod名> -- <コマンド>
  • リソースの詳細確認: kubectl describe <リソースタイプ> <リソース名>

K3sクラスターに対してこれらのコマンドを実行することで、アプリケーションのデプロイ、管理、デバッグを行うことができます。

組み込み機能の利用

K3sには、運用に便利なデフォルトの組み込みコンポーネントがいくつか含まれています。これらを活用することで、追加のセットアップなしに様々な機能を利用できます。

Ingress (Traefik)

K3sはデフォルトでTraefikをIngressコントローラーとしてインストールします。これにより、クラスター内で実行されているServiceを外部からHTTP/HTTPSでアクセスできるように設定できます。

Ingressリソースの作成例:

まず、簡単なDeploymentとServiceを作成します。

“`yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: echo-app
spec:
replicas: 2
selector:
matchLabels:
app: echo-app
template:
metadata:
labels:
app: echo-app
spec:
containers:
– name: echo-app
image: gcr.io/google_containers/echoserver:1.10
ports:
– containerPort: 8080

“`

“`yaml

service.yaml

apiVersion: v1
kind: Service
metadata:
name: echo-service
spec:
selector:
app: echo-app
ports:
– protocol: TCP
port: 80
targetPort: 8080

“`

これらのリソースをデプロイします。

bash
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

次に、このServiceにアクセスするためのIngressリソースを作成します。

“`yaml

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: echo-ingress
spec:
rules:
– host: echo.example.com # アクセスしたいホスト名を指定
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: echo-service
port:
number: 80

“`

このIngressリソースをデプロイします。

bash
kubectl apply -f ingress.yaml

Ingressが正常に作成されたか確認します。

bash
kubectl get ingress

出力例：

NAME CLASS HOSTS ADDRESS PORTS AGE
echo-ingress <none> echo.example.com <Node IP> 80 1m

ADDRESS 列には、K3s Serverノード（またはHA構成の場合はロードバランサー）のIPアドレスが表示されます。このIPアドレスをDNSに登録するか、ローカルの /etc/hosts ファイルに追記して echo.example.com にマッピングすれば、ブラウザから http://echo.example.com/ にアクセスしてアプリケーションに到達できるはずです。

Traefikは自動でPodとしてデプロイされ、Ingressリソースを監視してルーティング設定を更新します。HTTPSやLet’s Encryptによる証明書自動取得など、より高度なTraefikの設定も可能ですが、ここでは基本的なIngressの利用にとどめます。

Storage (Local Path Provisioner)

K3sはデフォルトでLocal Path Provisionerをインストールします。これにより、PersistentVolumeClaim (PVC) を作成すると、ノードのローカルファイルシステム上のパスを動的にプロビジョニングして PersistentVolume (PV) を作成できます。これは、開発やテスト環境、単一ノード構成で手軽に永続ストレージを利用したい場合に便利です。

PVCの作成例:

“`yaml

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-local-storage
spec:
accessModes:
– ReadWriteOnce # 一つのノードから読み書き可能
storageClassName: local-path # デフォルトのStorageClass名
resources:
requests:
storage: 1Gi # 1GBのリクエスト

“`

PVCを作成します。

bash
kubectl apply -f pvc.yaml

PVが作成され、PVCにバインドされたか確認します。

bash
kubectl get pvc
kubectl get pv

PVCの状態が Bound になっていれば、PVと関連付けられています。

PodからのPVCの利用例:

“`yaml

pod-with-volume.yaml

apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
– name: my-container
image: busybox
command: [“/bin/sh”, “-c”, “echo ‘Hello from K3s’ > /mnt/volume/hello.txt; sleep 3600”]
volumeMounts:
– name: persistent-storage
mountPath: /mnt/volume
volumes:
– name: persistent-storage
persistentVolumeClaim:
claimName: my-local-storage

“`

このPodを作成すると、my-local-storage PVCが利用され、指定されたパス (/mnt/volume) にマウントされます。Podが終了しても、PV/PVCが削除されない限りデータは永続化されます。

“`bash
kubectl apply -f pod-with-volume.yaml

PodがRunningになるのを待つ

kubectl logs my-app
kubectl exec my-app — cat /mnt/volume/hello.txt # ファイル内容を確認
“`

Local Path Provisionerは単一ノードまたは同じノード上でのPodの再起動には有効ですが、複数のノード間で永続データを共有したり、ノード障害時に他のノードでPodが起動した場合に同じデータにアクセスしたりすることはできません。より堅牢な永続ストレージが必要な場合は、NFS、Ceph、クラウドプロバイダーのCSIドライバーなど、別のストレージソリューションを検討する必要があります。

LoadBalancer (Klipper-lb)

Kubernetesの Service タイプ LoadBalancer は、通常クラウドプロバイダーのロードバランサーと連携して外部IPアドレスをServiceに割り当てます。K3sは組み込みで Klipper-lb というソフトウェアロードバランサーを提供しており、クラウド環境以外でも Service タイプ LoadBalancer を利用可能にします。

Klipper-lb は、デフォルトではノードポートを通じてトラフィックをServiceに転送します。つまり、LoadBalancer タイプのServiceを作成すると、ノードの外部IPアドレスと割り当てられたノードポートを介してServiceにアクセスできるようになります。HA構成でロードバランサーを使っている場合は、そのロードバランサーがノードポートに転送するように設定することも可能です。

Service Type=LoadBalancer の作成例:

前の例で作成した echo-service を LoadBalancer タイプに変更してみます（Serviceの変更は kubectl apply -f service.yaml で可能です）。

“`yaml

service-lb.yaml

apiVersion: v1
kind: Service
metadata:
name: echo-service
spec:
selector:
app: echo-app
ports:
– protocol: TCP
port: 80
targetPort: 8080
type: LoadBalancer # ここを変更

“`

bash
kubectl apply -f service-lb.yaml
kubectl get service echo-service

出力例：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
echo-service LoadBalancer 10.43.xx.xx <Node IP> 80:3xxxx/TCP 2m

EXTERNAL-IP 列にノードのIPアドレスが表示され、PORT(S) 列に NodePort (例: 3xxxx) が表示されます。これは、Node IP:NodePort でServiceにアクセスできることを意味します。Ingressのようにホスト名ベースのルーティングではなく、IPアドレスとポート番号でのアクセスになります。

Klipper-lb はシンプルですが、プロダクション環境でより高度なLoadBalancer機能（DNS統合、HTTPS終端など）が必要な場合は、MetalLBのような他のソフトウェアLBソリューションや、外部のハードウェア/クラウドLBとの連携を検討することも可能です。

Helm コントローラー

K3sにはHelm ChartをKubernetesリソースとして管理するためのHelmコントローラーが含まれています。これにより、Helm CLIを使わずに HelmChart や HelmChartConfig というカスタムリソースを定義して、Helm Chartをデプロイ・管理できます。

例えば、nginx-ingress Helm Chartをデプロイしたい場合、以下のような HelmChart リソースを作成します。

“`yaml
apiVersion: k3s.cattle.io/v1
kind: HelmChart
metadata:
name: nginx-ingress
namespace: kube-system # Helm Chartがインストールされるnamespace
spec:
chart: ingress-nginx
repo: https://kubernetes.github.io/ingress-nginx
targetNamespace: ingress-nginx # Chartがリソースをデプロイするnamespace
valuesContent: |
controller:
service:
type: ClusterIP # 例: ServiceタイプをClusterIPに変更
defaultBackend:
enabled: true # 例: デフォルトバックエンドを有効化

“`

kubectl apply -f nginx-ingress-chart.yaml のように適用することで、K3sのHelmコントローラーが指定されたHelm Chartをインストールします。valuesContent には、Helmの values.yaml ファイルの内容をYAML形式で直接記述できます。

これにより、クラスターの設定をKubernetesマニフェストとして一元管理しやすくなりますが、慣れている場合は通常のHelm CLIを使うことももちろん可能です。

ノード管理

クラスターに参加しているノードの状態を確認し、管理するための基本的な操作です。

  • ノード一覧と状態確認:

    bash
    kubectl get nodes
    STATUSが Ready であれば正常に動作しています。NotReady の場合は、ノードやK3sサービスに問題がある可能性があります。

  • ノードの詳細確認:

    bash
    kubectl describe node <node名>
    ノードの容量、リソース割り当て、コンディション、イベント、Pod一覧などが表示され、トラブルシューティングに役立ちます。

  • ノードへのラベル付け:
    特定のノードにアプリケーションを配置したい場合などに利用します。

    “`bash
    kubectl label node <キー>=<値> [<キー2>=<値2>…]

    例: 環境ラベルを追加

    kubectl label node my-server-node environment=production
    “`

  • ノードへのテイント/容認 (Taints/Tolerations):
    特定のPodが特定のノードに配置されないようにテイントを設定したり、そのテイントを持つノードにPodを配置できるように容認設定を行ったりします。

    “`bash

    テイントを追加 (例: masterノードに一般Podを配置しない)

    kubectl taint node node-role.kubernetes.io/master=:NoSchedule

    テイントを削除

    kubectl taint node node-role.kubernetes.io/master=:NoSchedule-
    “`

ログとデバッグ

問題発生時やクラスターの状態を確認する際に役立つログやデバッグの方法です。

  • K3sサービス自体のログ:
    K3sはsystemdサービスとして動作します。サービスのログは journalctl で確認できます。

    bash
    sudo journalctl -u k3s -f # Serverのログをリアルタイム表示
    sudo journalctl -u k3s-agent -f # Agentのログをリアルタイム表示
    インストールや起動に関するエラーはここを確認します。

  • Podのログ:
    アプリケーションコンテナのログを確認します。

    bash
    kubectl logs <pod名> [-n <namespace>]
    kubectl logs -f <pod名> [-n <namespace>] # リアルタイム表示
    kubectl logs --previous <pod名> [-n <namespace>] # 以前のコンテナのログ

  • クラスターイベントの確認:
    Podのスケジューリング、ノードの状態変化、エラーなどのクラスターレベルのイベントを確認できます。

    bash
    kubectl get events [--all-namespaces] [-w]

  • Pod内のデバッグ実行:
    kubectl exec を使って、実行中のコンテナ内でシェルなどを起動し、内部状態を確認できます。

    bash
    kubectl exec -it <pod名> [-n <namespace>] -- /bin/bash # bashがある場合
    kubectl exec -it <pod名> [-n <namespace>] -- /bin/sh # shがある場合

  • K3sコンフィグレーション:
    K3sのサービス設定は、デフォルトでは /etc/rancher/k3s/config.yaml に記述されます。このファイルはインストールスクリプトに渡したコマンドライン引数に基づいて自動生成される場合もあれば、手動で作成・編集する場合もあります。
    例えば、デフォルトのネットワークCIDRを変更したり、特定の組み込みコンポーネントを無効にしたり、外部データベース接続情報を記述したりします。
    ファイルを変更した場合は、K3sサービスを再起動する必要があります (sudo systemctl restart k3s または sudo systemctl restart k3s-agent)。

    kubectl get --raw /metrics でPrometheus形式のメトリクスを確認することもできます。

これらの基本的な使い方をマスターすれば、K3sクラスター上でアプリケーションをデプロイし、運用を開始できます。

K3sの応用的な使い方

K3sは軽量ながらも多くの標準Kubernetes機能をサポートしており、様々な応用的な使い方や他のツールとの連携が可能です。

外部サービスとの連携

  • 外部データベースの利用: HA構成で説明したように、PostgreSQLやMySQLをデータストアとして利用することで、より堅牢な構成を組むことができます。
  • 外部ロードバランサーの利用: HA構成時のAPIエンドポイントだけでなく、IngressやService Type=LoadBalancerのために、外部のロードバランサー（MetalLB、ハードウェアLB、クラウドLBなど）を利用することも可能です。Klipper-lbを無効にして、外部LBや他のソフトウェアLBを別途インストール・設定することで実現します。
  • 外部ストレージプロバイダー: Local Path Provisionerはローカルストレージのみを扱いますが、NFS、Ceph、iSCSIなどの共有ストレージをCSIドライバーとしてインストール・設定することで、より高度な永続ストレージ機能（ReadWriteManyアクセスモード、スナップショットなど）を利用できます。

セキュリティ強化

  • RBAC (Role-Based Access Control): 標準のKubernetesと同様にRBACを使って、Kubernetes APIへのアクセス権限を細かく制御できます。kubectl get clusterroles,clusterrolebindings,roles,rolebindings --all-namespacesなどで既存の設定を確認し、必要に応じて追加・変更します。
  • Pod Security Standards (PSS): Podのセキュリティに関する標準を適用できます。Kubernetes 1.25以降、PSP (Pod Security Policy) はPSSに置き換えられました。K3sでもPodSecurity Admission Controllerを設定することでPSSを適用できます。
  • NetworkPolicy: CalicoやKube-routerなどのCNIがNetworkPolicyをサポートしていれば、Pod間のネットワーク通信を制限するポリシーを設定できます。K3sはデフォルトでKube-routerまたはFlannelを使いますが、どちらもNetworkPolicyをサポートしています。

監視と運用

  • PrometheusとGrafana: Kubernetesクラスターの監視でよく使われるPrometheus (メトリクス収集) とGrafana (ダッシュボード) を導入できます。Helm ChartやOperatorHub (Operator Lifecycle Managerを導入した場合) を利用して簡単にデプロイ可能です。K3sノードやPodからメトリクスを収集し、リソース使用率やエラー発生率などを監視できます。
  • ログ収集: FluentdやFluent Bitを各ノードにDaemonSetとしてデプロイし、コンテナログを収集してElasticsearch/Opensearch, Loki, S3などのストレージに転送し、KibanaやGrafana Lokiで可視化・分析できます。
  • アラート: Prometheus Alertmanagerなどを設定し、特定の閾値やエラーパターンに基づいて通知（Slack, Emailなど）を受け取ることができます。

CI/CDとの連携

Jenkins, GitLab CI, GitHub Actions, Argo CD, Flux CDなどのCI/CDツールと連携し、コードの変更をトリガーにアプリケーションをK3sクラスターに自動デプロイするパイプラインを構築できます。kubeconfig ファイルをCI/CD環境に安全に渡し、kubectl や Helm コマンドを実行することで実現します。K3sの軽量性は、CI/CDパイプライン内で一時的なテストクラスターを迅速に立ち上げる用途にも適しています。

マルチクラスター管理 (Rancherとの連携)

Rancherは、複数のKubernetesクラスターを管理するためのプラットフォームです。RancherはK3sの開発元と同じ会社であるRancher Labsによって開発されており、K3sとの連携が非常にスムーズです。Rancherを導入することで、複数のK3sクラスター（および他のKubernetesクラスター）を単一のUIから集中管理したり、認証・認可、監視、ログ収集などの機能を統合したりできます。大規模にK3sを運用する場合や、様々な環境に多数のK3sクラスターを展開する場合は、Rancherの利用を検討する価値があります。

K3sと他のKubernetesディストリビューションとの比較

KubernetesにはK3s以外にも様々なディストリビューションやツールが存在します。ここでは、代表的なものと比較し、K3sがどのような立ち位置にあるかを明確にします。

  • Upstream Kubernetes (Vanilla K8s):

    • 特徴: Kubernetesプロジェクト本体が提供する標準的な実装です。すべての機能が含まれており、最も柔軟性が高いです。クラウドプロバイダーとの密な統合を持ちます。
    • K3sとの比較: セットアップと運用が複雑で、リソース消費も大きいです。K3sは不要な機能を削ぎ落とし、単一バイナリ化、デフォルトデータストアの変更などにより、軽量化と導入の容易さを追求しています。K8sは大規模なデータセンターやパブリッククラウドの本番環境に、K3sはエッジ、IoT、リソース制約のある環境、開発/テスト環境にそれぞれ強みがあります。

  • K0s:

    • 特徴: K3sと同様に、Spin by Mirantisによって開発されている軽量Kubernetesディストリビューションです。K3sと同様にシングルバイナリを指向していますが、組み込みコンポーネントの選択（例: Konnectivity, Calicoなど）やアーキテクチャに違いがあります。CNCF認証を受けています。
    • K3sとの比較: K0sも非常に軽量で導入が容易ですが、K3sはより長い歴史と広いユーザーベース、Rancherとの強力な連携という強みがあります。どちらを選ぶかは、特定の要件や慣れ、コミュニティの活動状況などによります。

  • MicroK8s:

    • 特徴: Canonical (Ubuntuの開発元) が開発しているKubernetesディストリビューションです。スナップパッケージとして提供され、簡単なインストールとアドオンによる機能拡張（DNS, Dashboard, Storage, Istioなど）が特徴です。シングルノードまたは小規模クラスター向けです。
    • K3sとの比較: MicroK8sも単一コマンドでインストールできますが、K3sはよりバイナリサイズが小さく、リソース消費も少ない傾向があります。MicroK8sのアドオンシステムは便利ですが、K3sはよりKubernetesの標準的なツール（kubectl, Helm）との連携を重視していると言えます。エッジ環境やリソース制約が非常に厳しい環境ではK3sが優位な場合があります。

  • Minikube / Kind:

    • 特徴: これらはプロダクション向けというより、主にローカルマシンでの開発やテストを目的としたツールです。MinikubeはVM内にKubernetesクラスターを起動し、KindはDockerコンテナとしてクラスターを起動します。
    • K3sとの比較: MinikubeやKindは開発・学習目的に特化しており、プロダクション環境へのデプロイには通常利用されません。K3sはローカル開発だけでなく、エッジや小規模本番環境へのデプロイも想定されています。

利用シーンによる選択肢:

  • 大規模な本番環境 (パブリッククラウド/プライベートクラウド): Upstream Kubernetes、またはクラウドプロバイダー提供のマネージドKubernetesサービス (EKS, GKE, AKSなど)。
  • エッジ/IoT/リソース制約のある環境: K3s、K0s。
  • 小規模な本番環境 (ブランチオフィスなど): K3s (HA構成)、K0s。
  • 開発/テスト環境 (ローカル/CI): K3s、Minikube、Kind、MicroK8s。
  • Kubernetes学習: K3s、Minikube、Kind、MicroK8s。

K3sは、その軽量性、簡単な導入、そしてプロダクションレベルの機能サポートのバランスから、上記様々なシーンで有力な選択肢となります。

K3sの制限事項と注意点

K3sは多くの利点を持つ一方で、いくつかの制限事項や注意点があります。

  • Kubernetesの全てのAPIや機能が含まれているわけではない: 軽量化のために一部の古いAPIバージョンや、使用頻度の低いアルファ/ベータ機能などが削除または無効化されている場合があります。ほとんどの標準的なワークロードには影響ありませんが、特定の高度な機能やレガシーなKubernetesリソースを利用している場合は互換性を確認する必要があります。
  • クラウドプロバイダー固有の統合が削除されている: K3sは汎用的な環境での動作を想定しているため、AWS EBS ProvisionerやAzure Disk Provisionerのようなクラウドプロバイダー固有のIn-treeボリュームプラグインなどは含まれていません。クラウド環境でこれらの機能を利用したい場合は、対応するCSIドライバーを別途インストールする必要があります。
  • 組み込みコンポーネントのカスタマイズ性: Traefik、CoreDNSなどの組み込みコンポーネントは、K3sにバンドルされてインストールされます。これらのバージョンアップグレードや詳細な設定変更は、通常のKubernetes Manifestによる管理とは少し異なる場合（K3sの設定ファイルやHelm Chartのカスタマイズなど）があり、完全にアンバンドルして別のものを利用したい場合は、インストールオプションで無効化してから別途インストールする必要があります。
  • SQLite3の限界: デフォルトのSQLite3は単一ノード構成では非常に便利ですが、複数ノードでのHA構成や、高いI/O性能が求められる状況には適していません。HA構成では必ず外部データベースまたは組み込みetcdを利用してください。
  • Windowsノードの非サポート: K3s AgentはLinuxのみをサポートしています。WindowsノードをWorkerとしてクラスターに参加させることはできません。
  • デフォルトストレージ (Local Path Provisioner) の制約: 前述の通り、Local Path Provisionerは単一ノード内での永続性を提供しますが、複数のノード間でデータを共有したり、ノード障害時にデータを引き継いだりすることはできません。

これらの制限事項を理解し、利用したい機能やデプロイ環境に合わせてK3sが適切かどうかを判断することが重要です。多くの場合、K3sの提供する価値（軽量性、容易さ）はこれらの制限を上回ります。

まとめ

本記事では、軽量KubernetesディストリビューションであるK3sについて、その特徴、アーキテクチャ、詳細な導入方法、そして基本的な使い方から応用的な使い方までを網羅的に解説しました。

K3sは、従来のKubernetesが持つ複雑さやリソース要件といった課題を克服し、エッジコンピューティング、IoT、リソース制約のある環境、開発・テスト環境といった新しい分野でのKubernetesの利用を現実のものとしました。わずか50MB程度のシングルバイナリ、シェルスクリプト一本での簡単なインストール、SQLite3をデフォルトデータストアとする手軽さ、そしてTraefik、Local Path Provisionerなどの便利な組み込みコンポーネントが、その普及を後押ししています。

同時に、外部データベースや組み込みetcdを組み合わせることで高可用性構成にも対応し、ProdSecurity Standards (PSS) や NetworkPolicy などのセキュリティ機能、Prometheus/Grafanaによる監視連携、CI/CDパイプラインへの組み込み、Rancherによるマルチクラスター管理など、プロダクション環境で求められる多くの要件も満たしています。

K3sは、Kubernetesの標準APIに準拠しているため、kubectl や Helm など、あなたが既に使い慣れているツールやワークフローをそのまま利用できます。これにより、学習コストを抑えつつ、Kubernetesのエコシステムが提供する豊富なリソースを活用することが可能です。

K3sは「全てのKubernetes機能をエッジで動かす」ことを目指すのではなく、「エッジやリソース制約のある環境でプロダクションワークロードを安定稼働させるために、最小限必要な機能を厳選して提供する」というアプローチをとっています。その結果、特定の高度な機能が削除されていたり、組み込みコンポーネントのカスタマイズに制約があったりする点には注意が必要ですが、そのトレードオフによって得られる軽量性と容易さは、多くのユースケースにおいて非常に魅力的です。

もしあなたが、従来のKubernetesが重すぎると感じている、手軽にKubernetes環境を構築したい、エッジデバイスでコンテナ化されたアプリケーションを管理したい、あるいはKubernetesを学習するための軽量な環境を探しているなら、K3sは間違いなく検討すべき優れた選択肢です。

本ガイドが、あなたがK3sを理解し、自身の環境で成功裏に導入・活用するための一助となれば幸いです。公式ドキュメントやコミュニティリソースも積極的に活用し、K3sの可能性を最大限に引き出してください。

参考資料

以上で、約5000語を目指したK3sの完全ガイドの記事となります。特徴、アーキテクチャ、詳細な導入方法（単一ノード、HA、オフライン、エージェント）、基本的な使い方（kubectl、組み込み機能、ノード管理、ログ）、応用的な使い方、他のディストリビューションとの比較、制限事項、まとめを含む内容としました。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール