簡単インストール！軽量Kubernetes K3s の始め方

はじめに：なぜ今、軽量Kubernetes「K3s」なのか？

現代のアプリケーション開発と運用において、コンテナ技術、そしてそのオーケストレーションツールであるKubernetesは、もはやデファクトスタンダードと言える存在になりました。マイクロサービス、Immutable Infrastructure、DevOpsといったプラクティスを実現する上で、Kubernetesが提供する自動化、スケーラビリティ、回復性は不可欠です。

しかし、従来のKubernetes（しばしば「Vanilla Kubernetes」や「Upstream Kubernetes」と呼ばれます）は、その強力さと引き換えに、いくつかの課題を抱えています。

まず、インストールとセットアップの複雑さです。マスターノードとワーカーノードのセットアップ、証明書の生成、etcdクラスターの構築、CNI（Container Network Interface）やCSI（Container Storage Interface）プラグインの導入など、多くのコンポーネントを手動または複雑なツール（kubeadm, kopsなど）を使って構築する必要があり、学習コストと導入コストが非常に高いのが実情です。

次に、リソース消費の多さです。フルセットのKubernetesは、APIサーバー、コントローラーマネージャー、スケジューラー、etcdといったコントロールプレーンのコンポーネントだけでも、それなりのCPUとメモリを消費します。これは、リソースが潤沢なデータセンターやクラウド環境では問題になりにくいですが、より制約の多い環境、例えばエッジデバイス、IoTゲートウェイ、小規模サーバー、開発者のローカルマシンなどでは大きな障壁となります。

このような背景から、Kubernetesの持つ強力なオーケストレーション能力を、より手軽に、より少ないリソースで利用したいというニーズが高まってきました。そこで登場したのが、軽量Kubernetesディストリビューションの一つであるK3sです。

K3sは、Rancher Labs（現在はSUSEの一部）によって開発された、クラウドネイティブコンピューティング財団（CNCF）のサンドボックスプロジェクトです。その最大の特徴は、「軽量」であることと、「インストールが驚くほど簡単」であることです。

この記事では、この注目の軽量KubernetesであるK3sに焦点を当て、その特徴、アーキテクチャ、そして何よりも「始め方」、つまり具体的なインストール方法から基本的な使い方までを、詳細かつ丁寧に解説します。

もしあなたが、

ローカルマシンで手軽にKubernetes環境を試したい
エッジデバイスやIoT環境でコンテナオーケストレーションを行いたい
学習用や検証用に素早くKubernetesクラスターを構築したい
CI/CDパイプラインで短命なKubernetesクラスターを使いたい
リソースが限られた環境でKubernetesを利用したい

と考えているなら、K3sはまさに理想的なソリューションかもしれません。この記事を最後まで読めば、K3sの基本的な概念を理解し、実際に自分の手でクラスターを構築し、アプリケーションを動かせるようになるでしょう。さあ、K3sの世界へ飛び込みましょう！

なぜK3sなのか？ K3sの魅力とメリット

K3sが多くの開発者や運用者に選ばれる理由は、そのユニークな特徴と、そこから生まれる数々のメリットにあります。ここでは、K3sの主な魅力を掘り下げてみましょう。

1. 圧倒的な軽量性

K3sの名称に含まれる「3S」は、Kubernetesから5文字を削ったことに由来すると言われています（K8sはKubernetesの略称）。これは、まさにK3sが従来のKubernetesから不要な機能やコンポーネントを削ぎ落とし、軽量化を徹底していることを象徴しています。

軽量化のために行われている具体的な工夫は以下の通りです。

不要なアルファ/ベータ機能の削除: K3sは、本番環境で一般的に利用されないアルファ版やベータ版のAPI、またはレガシーな機能など、標準のKubernetesに含まれる一部の機能をデフォルトで無効化または削除しています。
統合されたコンポーネント: 従来のKubernetesでは、APIサーバー、コントローラーマネージャー、スケジューラーなどが個別のバイナリとして動作しますが、K3sではこれらが単一のプロセスとして統合されています。これにより、バイナリサイズが小さくなり、メモリ使用量も削減されます。
SQLite3をデフォルトデータストアに採用: 標準のKubernetesでは、クラスターの状態を保存するデータストアとしてetcdが利用されます。etcdは分散合意アルゴリズム（Raft）に基づいた堅牢なKVSですが、セットアップが複雑で、それなりのリソースを消費します。K3sでは、より軽量なSQLite3をデフォルトのデータストアとして利用します。SQLite3は単一ファイルで動作するため、セットアップ不要で非常に軽量です。これにより、特にシングルノード構成の場合にリソース消費を大幅に削減できます。（もちろん、要件に応じてetcdや外部のPostgreSQL、MySQLを利用することも可能です。）
必要最小限のアドオン: デフォルトで含まれるアドオンも必要最小限に絞られています。コンテナランタイムはcontainerd、ネットワークはFlannel、イングレスコントローラーはTraefik、サービスロードバランサーはKlipper Service Load Balancer、DNSはCoreDNSが標準で含まれています。これらは軽量で広く利用されている実績のあるコンポーネントです。

これらの工夫により、K3sは最小構成であれば、わずか数GBのストレージ、512MB程度のメモリ、1CPUコアといった非常に限られたリソースでも動作可能です。これは、Raspberry Piのような小型デバイスや、仮想マシン上に最小限のKubernetes環境を構築したい場合に非常に有利です。

2. 驚くほど簡単なインストール

K3sのもう一つの最大の特徴は、そのインストールの手軽さです。多くの場合、単一のコマンドを実行するだけで、サーバー（マスター）ノードまたはエージェント（ワーカー）ノードとしてセットアップが完了します。

公式が提供するインストールスクリプトは、必要なバイナリのダウンロードから、システムのサービスへの登録、設定ファイルの配置、必要な証明書の生成まで、すべて自動で行います。数分どころか、ネットワーク環境によっては1分足らずで基本的なクラスターが立ち上がることもあります。

この手軽さのおかげで、Kubernetes初心者でも敷居が低く、すぐに動く環境を手に入れることができます。また、CI/CD環境でビルドやテストのために一時的にKubernetesクラスターが必要な場合にも、迅速な立ち上げと破棄が可能です。

3. シングルバイナリ

K3sは、k3sという単一のバイナリファイルとして提供されます。このバイナリの中に、Kubernetesの主要なコンポーネントだけでなく、containerd、Flannel、Traefikといったアドオンに必要な機能まで含まれています。

シングルバイナリであることの利点は、管理が非常にシンプルになることです。インストールはバイナリを配置してサービスを起動するだけ、アンインストールもバイナリと設定ファイルを削除するだけです。バージョン管理も単一のバイナリを管理すれば良いため、非常に容易です。また、オフライン環境への配布も、このバイナリファイル一つを持っていくだけで済むため容易になります。

4. オールインワンパッケージ

前述の通り、K3sのシングルバイナリには、Kubernetesを動作させるために必要な主要コンポーネントと、実用上よく使われるアドオンがデフォルトで含まれています。

コンテナランタイム: containerd
CNI (ネットワーク): Flannel (VXLAN)
CSI (ストレージ): Local Path Provisioner (デフォルト)
Ingress Controller: Traefik v2
Service Load Balancer: Klipper Service Load Balancer (NodePortサービスを自動的にホストIPに公開)
DNS: CoreDNS

これらのコンポーネントは、Vanilla Kubernetesでは別途インストールや設定が必要なものですが、K3sでは「箱から出してそのまま使える（Out-of-the-box）」状態で提供されます。これにより、導入後の初期設定の手間が大幅に削減されます。もちろん、これらのデフォルトコンポーネントを無効化したり、別のコンポーネント（Calico, Nginx Ingressなど）に置き換えたりすることも可能です。

5. 信頼性と本番環境での実績

K3sはRancher LabsというKubernetesのエキスパート集団によって開発されており、活発な開発が続けられています。また、CNCFのサンドボックスプロジェクトとして、コミュニティの貢献も受け入れています。

軽量である一方で、K3sは小規模ながらも本番環境での利用を想定して設計されており、高い信頼性を持っています。実際に多くのユーザーが、エッジ環境や小規模システムの運用にK3sを採用しています。クラスターの状態を外部の高性能なデータベース（PostgreSQL, MySQL, etcd）に保存する構成もサポートされており、より堅牢なクラスターを構築することも可能です。

6. 標準的なKubernetes API互換性

K3sは、CNCFのCertified Kubernetesディストリビューションではありませんが、標準的なKubernetes APIに準拠しています。これは非常に重要な点です。つまり、Vanilla Kubernetesで利用できるほとんどのkubectlコマンド、YAMLマニフェスト（Pod, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaimなど）は、K3s上でもそのまま動作します。

これにより、既存のKubernetesの知識や資産を無駄にすることなく、K3sにスムーズに移行したり、K3sを学習環境として活用したりすることが可能です。特定のディストリビューションにロックインされることなく、Kubernetesの標準的なエコシステムを活用できます。

7. セキュリティバイデフォルト

K3sは、デフォルトでセキュリティを考慮した設定になっています。例えば、TLS証明書は起動時に自動的に生成・管理されます。ユーザーは手動で証明書を準備・更新する必要がありません。

これらのメリットを総合すると、K3sは「手軽に始められて、リソース効率が良く、かつ標準的なKubernetesの機能を利用できる」という、非常にバランスの取れた軽量Kubernetesソリューションと言えます。次章では、K3sのアーキテクチャをもう少し詳しく見て、その軽量性の秘密に迫ります。

K3sのアーキテクチャ概要

K3sがどのように軽量化を実現しているのか、そのアーキテクチャの主要な部分を見ていきましょう。

マスター（サーバー）とエージェントの構成

K3sクラスターは、他のKubernetesクラスターと同様に、コントロールプレーンを担うサーバーノードと、コンテナワークロードを実行するエージェントノードで構成されます。

サーバーノード: Kubernetesのコントロールプレーンコンポーネント（APIサーバー、コントローラーマネージャー、スケジューラーなど）を実行します。また、クラスターの状態を保存するデータストアも保持します。最低1台のサーバーノードが必要です。
エージェントノード: kubeletとコンテナランタイム（containerd）を実行し、サーバーノードからの指示に従ってPodを実行・管理します。必要に応じて複数台のエージェントノードを追加できます。

K3sの最大の特徴は、このサーバーとエージェントの役割を、全く同じk3sという単一のバイナリファイルが実行する点です。起動時のオプションによって、そのバイナリがサーバーとして動作するのか、エージェントとして動作するのかが決まります。

シングルバイナリ `k3s` の中身

先述の通り、k3sバイナリは多機能です。その中には、以下の主要なコンポーネントが含まれています。

Kube API Server, Controller Manager, Scheduler: これらはVanilla Kubernetesでは別々のバイナリですが、K3sでは単一のプロセスとして動作します。これにより、プロセス間通信のオーバーヘッドが減り、メモリ消費量も削減されます。
containerd: 標準のOCI（Open Container Initiative）に準拠したコンテナランタイムです。Dockerのようなハイレベルなデーモンではなく、より軽量なランタイムとして利用されます。K3sはこのcontainerdを内蔵し、Podのコンテナを実行します。
Flannel: シンプルなCNIプラグインです。K3sではデフォルトでFlannelのVXLANモードが利用され、クラスター内のPod間のネットワーク通信を可能にします。
Traefik: デフォルトのIngress Controllerです。外部からのHTTP/HTTPSトラフィックを、Ingressリソースの設定に基づいてクラスター内のサービスにルーティングします。
CoreDNS: クラスター内のService Discoveryを提供するDNSサーバーです。
Klipper Service Load Balancer: Serviceリソースのtype: LoadBalancerをエミュレートするシンプルなロードバランサーです。外部ロードバランサーがない環境でも、NodePortサービスを自動的に公開ノードのIPアドレスで利用可能にします。
Local Path Provisioner: PersistentVolumeClaimが要求された際に、ノード上の指定されたローカルパスにPersistentVolumeを動的にプロビジョニングするシンプルなCSIプラグインです。開発環境やシングルノード環境で手軽に永続ストレージを利用するのに役立ちます。

これらのコンポーネントが必要に応じてk3sバイナリの中で起動・管理されます。これにより、個別にインストール・設定する手間が省かれています。

データストアの選択肢

K3sのサーバーノードは、クラスターの状態を保存するためのデータストアを必要とします。K3sでは、以下のデータストアがサポートされています。

SQLite3: K3sのデフォルトデータストアです。単一ファイル (/var/lib/rancher/k3s/server/db/state.db) にすべての状態が保存されます。セットアップ不要で非常に軽量なため、開発環境、テスト環境、エッジ環境、シングルノード構成などに最適です。ただし、高可用性（HA）構成には向いていません。
PostgreSQL: 外部のPostgreSQLデータベースをデータストアとして利用できます。エンタープライズ環境で広く利用されており、スケーラビリティと信頼性に優れています。K3sサーバーノードのHA構成に推奨されます。
MySQL (またはMariaDB): 外部のMySQLまたはMariaDBデータベースもデータストアとして利用できます。PostgreSQLと同様に、HA構成に適しています。
etcd: Upstream Kubernetesで標準的に利用されるetcdクラスターをデータストアとして利用することも可能です。etcd自体をK3sとは別に管理する必要があります。リソース消費はSQLite3より大きいですが、Kubernetes標準のデータストアとして実績があります。

多くの「始め方」のシナリオでは、セットアップが最も簡単なデフォルトのSQLite3が使われます。HA構成や大規模環境を検討する際に、外部データベースへの切り替えを検討することになります。

従来のKubernetesとの違い（内部構造）

Vanilla Kubernetesでは、etcd, kube-apiserver, kube-controller-manager, kube-schedulerといったコントロールプレーンの各コンポーネントが独立したプロセスとして動作し、互いにAPIやetcdを介して通信します。

K3sでは、先述の通りAPIサーバー、コントローラーマネージャー、スケジューラーなどが単一のプロセス内で統合されています。これにより、プロセス起動のオーバーヘッドやプロセス間通信の複雑さが軽減され、リソース効率が向上しています。

また、K3sは証明書の生成や管理を自動で行います。Vanilla Kubernetesで証明書の手動管理やkubeadmによる自動化が必要なのに対し、K3sはサーバー起動時に必要な証明書を生成し、必要に応じて更新します。

このように、K3sは「シンプルさ」と「軽量性」を追求するために、内部アーキテクチャを最適化していますが、外部から見たAPIは標準的なKubernetesと互換性があるように設計されています。

K3sのインストール方法（詳細）

いよいよK3sの具体的なインストール方法に入ります。K3sのインストールは非常に簡単ですが、いくつかの方法やオプションがあります。ここでは最も一般的なインストールスクリプトを使った方法を中心に、シングルノード構成と複数ノード構成（サーバーとエージェント）の両方を解説します。

前提条件

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

オペレーティングシステム: サポートされているLinuxディストリビューション。Ubuntu, Debian, CentOS/RHEL, openSUSEなどが一般的に利用されます。ARM64およびARMv7アーキテクチャもサポートされているため、Raspberry Piなどでも動作します。WindowsやmacOSに直接インストールすることはできませんが、WSL2（Windows Subsystem for Linux）や仮想マシン、Docker Desktop上のKubernetes置き換えとして利用することは可能です。
必要なリソース:
- サーバーノード（SQLite3データストアの場合）: 最低 512MB RAM, 1 CPUコア。推奨 1GB RAM, 1 CPUコア。
- エージェントノード: 最低 75MB RAM, 1 CPUコア。推奨 1GB RAM, 1 CPUコア。
- ストレージ: OSやコンテナイメージ、K3sデータ用に数GB以上の空き容量が必要です。
  これらの要件はあくまで最低限のものです。実際に動かすワークロードによっては、より多くのリソースが必要になります。
ネットワーク要件:
- サーバーノード: TCPポート 6443 (Kubernetes API) が、kubectlを実行するマシンや、エージェントノードからアクセス可能である必要があります。
- エージェントノード: TCPポート 6443 を使用してサーバーノードに接続できる必要があります。
- ノード間通信: デフォルトのFlannel VXLANでは、UDPポート 8472 がノード間で通信できる必要があります。
- イングレス (Traefik): デフォルトでは、TCPポート 80 (HTTP) と 443 (HTTPS) がサーバーノードまたはイングレスコントローラーが動作するノードで利用されます。
- NodePortサービス: デフォルトでは、TCPポート 30000-32767 の範囲が利用されます。
ユーザー権限: インストールスクリプトの実行にはroot権限が必要です（sudoコマンドを使用します）。インストール後、K3sはk3sという非特権ユーザーとして実行されます。
firewalld/iptables/ufw: 必要なポートが開いていることを確認してください。多くの場合、インストールスクリプトが一部のファイアウォール設定を行いますが、環境によっては手動設定が必要です。SELinuxやAppArmorが有効な場合、適切なポリシー設定が必要になることがあります。

インストールスクリプトを使った方法（最も簡単）

K3sの公式ドキュメントでは、Bashスクリプトを使ったインストール方法が推奨されています。これは非常に簡単で、数行のコマンドで完結します。

1. シングルノード（サーバー兼エージェント）としてのインストール

最もシンプルな構成は、1台のマシンにサーバー機能とエージェント機能を両方インストールするシングルノードクラスターです。開発やテスト、学習用途に最適です。

Linuxマシン上で、ターミナルを開き、以下のコマンドを実行します。

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

このコマンドは以下の処理を行います。

curl -sfL https://get.k3s.io : https://get.k3s.io からインストールスクリプトをダウンロードします。-sはサイレントモード、-fはエラー時に終了、-Lはリダイレクトに従うオプションです。
| sh - : ダウンロードしたスクリプトをshコマンドで実行します。

スクリプトが実行されると、以下の処理が自動で行われます。

K3sの最新版バイナリがダウンロードされ、/usr/local/bin/k3s に配置されます。
k3sサービスがシステムに登録され（SystemdまたはOpenRC）、起動されます。
K3sサーバーが起動し、データストアとしてデフォルトのSQLite3を使用します。
デフォルトのコンテナランタイム (containerd)、CNI (Flannel)、Ingress Controller (Traefik) などが起動されます。
kubectlコマンドがK3sクラスターと通信するための設定ファイル（kubeconfig）が/etc/rancher/k3s/k3s.yamlに生成されます。
kubectlバイナリやその他のツール (crictl, ctr) へのシンボリックリンクが/usr/local/bin/に作成されます（既に存在しない場合）。

インストールが完了すると、K3sサービスが起動し、クラスターが利用可能になります。

インストールの確認:

インストール後、以下のコマンドでK3sサービスのステータスを確認できます（Systemdの場合）。

bash sudo systemctl status k3s

また、Kubernetesクラスターが正しく起動したかを確認するには、kubectlコマンドを使用します。K3sのkubeconfigファイルは/etc/rancher/k3s/k3s.yamlにあります。通常は環境変数KUBECONFIGを設定するか、このファイルをデフォルトの場所(~/.kube/config)にコピーして利用します。

“`bash

KUBECONFIG環境変数を設定してkubectlを使う場合

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

出力例:

NAME STATUS ROLES AGE VERSION your-host Ready control-plane,master 2m30s v1.2x.y+k3s1

STATUSがReadyになっていれば、クラスターは正常に起動しています。ROLESにcontrol-planeまたはmasterが表示されているのは、このノードがサーバー機能を持っていることを示します。シングルノード構成なので、このノードはサーバー兼エージェントとして機能しています。

kubectl get pods --all-namespaces コマンドで、システム関連のPod（CoreDNS, Traefik, Metrics Serverなど）が起動していることも確認できます。

bash export KUBECONFIG=/etc/rancher/k3s/k3s.yaml # もしまだ設定していなければ kubectl get pods --all-namespaces

出力例（一部抜粋）:

NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-xxx 1/1 Running 0 3m kube-system traefik-xxx 1/1 Running 0 3m kube-system local-path-provisioner-xxx 1/1 Running 0 3m kube-system metrics-server-xxx 1/1 Running 0 3m kube-system svclb-traefik-xxxx 2/2 Running 0 3m

これらのPodがRunningステータスになっていれば、基本的なアドオンも正常に動作しています。

インストールオプション:

インストールスクリプトには様々なオプションがあり、環境変数として渡すことで動作を変更できます。よく使うオプションの例をいくつか紹介します。

K3S_VERSION: 特定のバージョンをインストールする場合。
bash curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.28.5+k3s1" sh -
バージョンを指定しない場合は最新版がインストールされます。
INSTALL_K3S_EXEC: k3s server または k3s agent コマンドに追加の引数を渡したい場合。例えば、特定のIPアドレスで待ち受けさせたり、一部のアドオンを無効にしたりする場合に利用します。
bash # Traefik Ingress Controllerを無効にしてインストール curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--no-deploy traefik" sh -
後述の複数ノード構成のサーバーやエージェントの起動オプションも、この方法で指定します。
INSTALL_K3S_SKIP_DOWNLOAD: 既にバイナリをダウンロード済みの場合、再ダウンロードをスキップします。
INSTALL_K3S_SKIP_ENABLE: K3sサービスをインストールするが、自動起動を無効にする場合。手動で起動したい場合に利用します。
INSTALL_K3S_BIN_DIR: バイナリのインストール先ディレクトリを指定する場合。
INSTALL_K3S_SYMLINK_BIN: /usr/local/bin へのシンボリックリンク作成を制御する場合。

これらのオプションを組み合わせることで、様々な要件に対応できます。詳細はK3sの公式ドキュメントを参照してください。

2. 複数ノード構成（サーバーとエージェント）のインストール

K3sクラスターを複数のマシンで構成する場合、1台をサーバーノードとしてインストールし、他のマシンをエージェントノードとしてクラスターに参加させます。

ステップ1: サーバーノードのインストール

まず、サーバーとして動作させたいマシンでK3sをインストールします。基本的なコマンドはシングルノードの場合と同じですが、ここではより明確にサーバーとしてインストールしていることを意識します。

“`bash

サーバーとしてインストール

curl -sfL https://get.k3s.io | sh –
“`

デフォルトでは、このコマンドでインストールされたノードはサーバー機能とエージェント機能の両方を持ちます。サーバー専用ノードにしたい場合は、エージェント機能を無効にするオプション --disable-agent を使用します。

“`bash

サーバー専用ノードとしてインストール (任意)

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC=”–disable-agent” sh –
“`

サーバーノードのインストールが完了したら、エージェントノードがクラスターに参加するために必要なトークンを取得します。このトークンは、サーバーノードの/var/lib/rancher/k3s/server/node-tokenファイルに保存されています。

“`bash

サーバーノードでトークンを取得

sudo cat /var/lib/rancher/k3s/server/node-token
“`

このコマンドを実行すると、ランダムな文字列が表示されます。これがノードトークンです。例: K10abcd12345efgh67890ijklmnopqrstuvwxyzABCDEFG::server:xxxxxxxxxxxxxxxx
このトークンを控えておいてください。

ステップ2: エージェントノードのインストール

次に、クラスターに参加させたいエージェントノードのマシンでインストールコマンドを実行します。エージェントとしてインストールするには、サーバーのURLと、先ほど取得したノードトークンを指定する必要があります。

“`bash

エージェントとしてインストール

curl -sfL https://get.k3s.io | K3S_URL=https://:6443 K3S_TOKEN= sh –
“`

<server_ip>: サーバーノードのIPアドレスまたはホスト名に置き換えます。APIサーバーはデフォルトで6443ポートで待ち受けています。
<token>: サーバーノードで取得したノードトークンに置き換えます。

このコマンドを実行すると、エージェントノードに必要なK3sバイナリがインストールされ、k3s-agentサービスとして登録・起動されます。k3s-agentは指定されたK3S_URLのサーバーにK3S_TOKENを使って接続し、クラスターに参加します。

エージェントインストールオプション:

エージェントインストール時にも、INSTALL_K3S_EXEC環境変数を使って追加オプションを指定できます。

–node-name: ノード名を指定する場合。省略するとホスト名が使われます。
bash curl -sfL https://get.k3s.io | K3S_URL=... K3S_TOKEN=... INSTALL_K3S_EXEC="--node-name my-agent-node-1" sh -
–node-ip: ノードのIPアドレスを指定する場合。特定のIPでサーバーと通信させたい場合などに利用します。
–docker: デフォルトのcontainerdではなく、Dockerをコンテナランタイムとして使用する場合。
bash curl -sfL https://get.k3s.io | K3S_URL=... K3S_TOKEN=... INSTALL_K3S_EXEC="--docker" sh -
（このオプションを使用する場合、事前にDockerをインストールしておく必要があります）

ステップ3: クラスターに参加したかの確認

サーバーノードのマシンに戻り、kubectl get nodesコマンドを再度実行します（必要であればexport KUBECONFIGを忘れずに）。

bash export KUBECONFIG=/etc/rancher/k3s/k3s.yaml # サーバーノードで実行 kubectl get nodes

出力例:

NAME STATUS ROLES AGE VERSION server-node Ready control-plane,master 15m v1.2x.y+k3s1 agent-node-1 Ready <none> 2m v1.2x.y+k3s1

新しく参加したエージェントノード（agent-node-1など）がReadyステータスで表示されていれば成功です。エージェントノードには通常control-planeやmasterといったロールはつきません。

ファイアウォールの設定

K3sクラスターを構築・運用するにあたり、ノード間で通信が必要なポートを開放する必要があります。環境によっては、OS標準のファイアウォール（firewalld, ufw, iptablesなど）やネットワーク機器の設定が必要です。

必要な主要ポートは以下の通りです。

TCP 6443: Kubernetes API Server。kubectlを実行するクライアントやエージェントノードからサーバーノードへの接続。
UDP 8472: デフォルトのFlannel VXLANトンネル通信。ノード間のPod間通信に使用されます。
TCP 2379-2380: 外部etcdデータストアを使用する場合、etcdクライアント-サーバー通信およびピア通信。
TCP 5432: 外部PostgreSQLデータストアを使用する場合。
TCP 3306: 外部MySQLデータストアを使用する場合。
TCP 10250: kubelet API。サーバーノードがエージェントノード上のkubeletと通信するために使用します。
TCP 30000-32767: NodePortサービスがデフォルトで使用するポート範囲。外部からNodePortサービスにアクセスする場合、これらのポートがノードのIPアドレスでアクセス可能である必要があります。
TCP 80, 443: デフォルトのTraefik Ingress Controllerが使用するポート。Ingressを使って外部からアプリケーションにアクセスする場合、サーバーノード（またはIngress Podが実行されているノード）のこれらのポートがアクセス可能である必要があります。

セキュリティグループやファイアウォールルールを設定する際は、これらのポートが必要なノード間およびクライアント間（kubectlを実行するマシン）で通信できるよう設定してください。

アンインストール方法

K3sのアンインストールも非常に簡単です。インストールスクリプトが、アンインストール用のスクリプトも/usr/local/bin/に作成してくれています。

サーバーノードのアンインストール:
bash sudo /usr/local/bin/k3s-uninstall.sh
エージェントノードのアンインストール:
bash sudo /usr/local/bin/k3s-agent-uninstall.sh

これらのスクリプトは、K3sサービスを停止・無効化し、インストールされたファイル（バイナリ、設定ファイル、データストアファイルなど）を削除します。ただし、Podによって作成されたデータディレクトリやPersistentVolumeとして利用されていたデータなどは削除されない場合があるので注意が必要です。

これで、K3sクラスターを立ち上げる基本的な方法を理解しました。シングルノードでも複数ノードでも、驚くほど簡単にインストールできることがお分かりいただけたかと思います。次章では、インストールしたK3sクラスターの基本的な使い方を見ていきます。

K3sの基本的な使い方

K3sがインストールされ、クラスターがReady状態になったら、いよいよアプリケーションをデプロイしたり、クラスターを操作したりしてみましょう。K3sは標準的なKubernetes APIに準拠しているため、多くの場合、Upstream Kubernetesと同じようにkubectlコマンドを使って操作できます。

`kubectl`コマンドのセットアップと使い方

kubectlはKubernetesクラスターを操作するためのコマンドラインツールです。K3sのインストールスクリプトは、kubectlバイナリ自体はインストールしない場合がありますが、K3s固有のk3s kubectlというラッパーコマンドや、/usr/local/bin/kubectlへのシンボリックリンクを作成します。

最も推奨される方法は、公式のkubectlを別途インストールし、K3sのkubeconfigファイルを指定して利用することです。

1. kubectlのインストール:

OSに応じた方法で公式のkubectlをインストールしてください。例えばLinuxの場合、以下の手順でインストールできます。

“`bash

実行権限を付与

chmod +x kubectl

パスが通っているディレクトリに移動（例: /usr/local/bin/）

sudo mv kubectl /usr/local/bin/
“`

インストール後、kubectl version --clientでバージョンを確認できます。

2. K3sのkubeconfigファイルの設定:

kubectlがどのKubernetesクラスターと通信するかは、kubeconfigファイルで指定されます。K3sサーバーをインストールしたマシンには、/etc/rancher/k3s/k3s.yamlというkubeconfigファイルが生成されています。

kubectlを使うには、以下のいずれかの方法でこのファイルを指定します。

方法A: 環境変数KUBECONFIGを設定する（推奨）
これは最も手軽で、他のKubernetesクラスターと切り替える際にも便利な方法です。
bash export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
この設定をログイン時に自動的に行いたい場合は、~/.bashrcや~/.profileなどのシェル設定ファイルに上記の行を追加しておきます。
方法B: デフォルトの場所~/.kube/configにコピーする
K3sクラスターを主に使用する場合に便利な方法です。既存の~/.kube/configがある場合は、内容をマージする必要があります。
bash mkdir -p ~/.kube sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config sudo chown $(id -u):$(id -g) ~/.kube/config # ファイルの所有者を現在のユーザーに変更

kubeconfigの設定が完了したら、kubectl cluster-infoコマンドでクラスターに接続できるか確認してみましょう。

bash kubectl cluster-info

APIサーバーのURLなどが表示されれば成功です。

3. 基本的なkubectlコマンドの実行:

これで、標準的なkubectlコマンドを使ってK3sクラスターを操作できます。

ノードの状態を確認:
bash kubectl get nodes
全てのPodの状態を確認:
bash kubectl get pods --all-namespaces
特定の名前空間のPodを確認:
bash kubectl get pods -n kube-system
デプロイメント、サービスなどを確認:
bash kubectl get deployments,services,ingress,pv,pvc --all-namespaces
Podの詳細情報を確認:
bash kubectl describe pod <pod-name> -n <namespace>
Podのログを確認:
bash kubectl logs <pod-name> -n <namespace>

デプロイメントの作成

Kubernetesでアプリケーションを動かす基本的な単位はPodですが、実運用ではPodの集合を管理するDeploymentリソースを使うのが一般的です。ここでは、簡単なNginxウェブサーバーをデプロイする例を見てみましょう。

以下の内容でnginx-deployment.yamlというファイルを作成します。

yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 # Podを3つ起動 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest # Nginxイメージを使用 ports: - containerPort: 80 # コンテナの80番ポートを公開

このマニフェストファイルをK3sクラスターに適用します。

bash kubectl apply -f nginx-deployment.yaml

出力例:

deployment.apps/nginx-deployment created

デプロイメントが作成されたら、Podが起動しているか確認します。

bash kubectl get pods -l app=nginx

しばらくすると、3つのPodがRunning状態になるはずです。

NAME READY STATUS RESTARTS AGE nginx-deployment-xxxxxxxxx-abcde 1/1 Running 0 1m nginx-deployment-xxxxxxxxx-fghij 1/1 Running 0 1m nginx-deployment-xxxxxxxxx-klmno 1/1 Running 0 1m

サービスの公開

デプロイしたNginx Podはクラスター内部でのみアクセス可能です。外部からアクセスできるようにするにはServiceリソースを作成します。ここでは、簡単なNodePortタイプのServiceを作成します。

以下の内容でnginx-service.yamlというファイルを作成します。

yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx # このセレクターに一致するPodにトラフィックをルーティング ports: - protocol: TCP port: 80 # Service自身のポート targetPort: 80 # Podのポート nodePort: 30080 # ノードのポート (30000-32767の範囲) type: NodePort # NodePortタイプを指定

このServiceマニフェストを適用します。

bash kubectl apply -f nginx-service.yaml

出力例:

service/nginx-service created

Serviceが作成されたか確認します。

bash kubectl get service nginx-service

出力例:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service NodePort 10.43.xxx.yyy <none> 80:30080/TCP 30s

PORT(S)列に80:30080/TCPと表示されています。これは、Serviceの80番ポートへのトラフィックが、ノードの30080番ポートにマッピングされていることを意味します。

これで、K3sクラスターのいずれかのノードのIPアドレスと、このNodePort (30080) を使ってNginxにアクセスできるようになります。

例: http://<ノードのIPアドレス>:30080

ブラウザやcurlコマンドでアクセスしてみてください。Nginxのデフォルトページが表示されるはずです。

Klipper Service Load Balancer:

K3sにはデフォルトでKlipper Service Load Balancerが含まれています。Serviceのtype: LoadBalancerを指定すると、外部ロードバランサーが存在しない環境でも、Klipper SLBが自動的にそのServiceに対応するNodePortを作成し、そのNodePortをK3sノード自身のIPアドレスにマッピングしてくれます。kubectl get serviceを実行した際に、EXTERNAL-IP列にノードのIPアドレスが表示されることがあります。これはKlipper SLBの動作によるものです。NodePortタイプと同様に、ノードのIPアドレスと公開されたポート（通常はNodePort範囲）でアクセスできます。

Traefik Ingress Controller:

より高機能な外部からのアクセス方法として、Ingressリソースがあります。K3sにはデフォルトでTraefik Ingress Controllerが含まれており、これを利用できます。

例えば、example.comというホスト名でNginxにアクセスしたい場合、以下のようなIngressリソースを作成します。

yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-ingress annotations: # Traefik特有のアノテーションなどが必要な場合があります ingress.kubernetes.io/ssl-redirect: "false" # HTTPでアクセスする場合 spec: rules: - host: example.com # アクセスしたいホスト名 http: paths: - path: / pathType: Prefix backend: service: name: nginx-service # ルーティング先のService名 port: number: 80 # Serviceのポート番号

このIngressを適用するには、kubectl apply -f nginx-ingress.yamlを実行します。

Ingress経由でアクセスするには、ローカルマシンの/etc/hostsファイルなどに、Ingress Controllerが動作しているノードのIPアドレスと指定したホスト名(example.com)のマッピングを追加する必要があります。

“`bash

/etc/hosts に追記 (例: Ingress Controllerが192.168.1.100で動作している場合)

192.168.1.100 example.com
“`

これで、ブラウザでhttp://example.comにアクセスすると、Traefik経由でNginx Podにトラフィックがルーティングされるようになります。

永続ストレージ

コンテナは通常ステートレスに設計されますが、データを永続化したい場合（データベースなど）はストレージが必要です。KubernetesではPersistentVolume (PV) とPersistentVolumeClaim (PVC) の仕組みを使ってストレージを扱います。

K3sにはデフォルトでLocal Path Provisionerが含まれています。これは、PVCが要求された際に、ノード上の指定されたパス（デフォルトは/var/lib/rancher/k3s/storage/以下）にディレクトリを作成し、それをPVとして提供するシンプルなプロビジョナーです。開発やテストには便利ですが、ノード障害時にはデータが失われる可能性があるため、本番環境ではより堅牢なストレージソリューション（NFS, Ceph, クラウドストレージなど）の利用を検討すべきです。

Local Path Provisionerを使った永続ストレージの利用例:

PersistentVolumeClaim (PVC) の作成:
yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce # ReadWriteOnce, ReadOnlyMany, ReadWriteManyなど storageClassName: local-path # Local Path Provisionerを使うことを指定 resources: requests: storage: 1Gi # 1GiBの容量を要求
kubectl apply -f my-pvc.yaml で作成します。kubectl get pvc で状態を確認できます。STATUSがBoundになれば、対応するPVがプロビジョニングされています。
PodからPVCを利用:
PodのマニフェストでvolumesとvolumeMountsを使ってPVCを参照します。
“`yaml
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-storage
spec:
containers:
- name: my-container
  image: alpine
  command: [“/bin/sh”, “-c”, “echo ‘Hello K3s Persistent Storage!’ > /data/hello.txt; sleep 3600”]
  volumeMounts:
  - name: storage-volume
    mountPath: /data # コンテナ内のマウントパス
    volumes:
- name: storage-volume
  persistentVolumeClaim:
  claimName: my-pvc # 作成したPVCの名前を指定
  ``kubectl apply -f my-pod-with-storage.yamlでPodを作成します。Podが起動すると、PVCによってプロビジョニングされたストレージが/data`にマウントされ、そこにファイルが作成されます。Podを削除しても、PVCとPVは保持され、データはノード上の指定パスに残ります。

コンフィグマップとシークレット

アプリケーションの設定情報や認証情報を、Podの定義から分離して管理するには、ConfigMapとSecretリソースを使います。

ConfigMap: アプリケーションの設定ファイル、環境変数、コマンドライン引数など、機密性の高くない設定情報を保存します。
yaml apiVersion: v1 kind: ConfigMap metadata: name: my-config data: app.properties: | database.url=jdbc:mysql://db:3306/mydb database.user=myuser config.json: | { "logLevel": "INFO" }
kubectl apply -f my-configmap.yaml で作成後、PodのenvFromやvolumeMountsを使ってコンテナに設定を渡します。
Secret: パスワード、APIキー、証明書など、機密性の高い情報を保存します。情報はBase64でエンコードされて保存されます（ただし、これは暗号化ではなくエンコードなので、クラスターへのアクセス権を持つユーザーからは容易にデコード可能です。より厳格なセキュリティが必要な場合は、外部のSecret管理システム（HashiCorp Vault, クラウドプロバイダーのSecret Managerなど）との連携を検討する必要があります）。
yaml apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque # or kubernetes.io/dockerconfigjson etc. data: username: bXl1c2Vy # base64("myuser") password: c2VjcmV0cGFzc3dvcmQ= # base64("secretpassword")
kubectl apply -f my-secret.yaml で作成後、PodのenvFromやvolumeMountsを使ってコンテナにシークレットを渡します。

ダッシュボードのインストール（オプション）

GUIでKubernetesクラスターの状態を確認したり操作したりしたい場合は、Kubernetes Dashboardをインストールすると便利です。K3sはデフォルトではダッシュボードをインストールしませんが、Helmなどのパッケージマネージャーを使って簡単にインストールできます。

例えば、Helmを使ってKubernetes Dashboardをインストールする手順は以下のようになります（事前にHelmのインストールが必要です）。

“`bash

Kubernetes DashboardのHelmリポジトリを追加

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm repo update

Dashboardと推奨アドオンをインストール

helm upgrade –install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard –namespace kubernetes-dashboard –create-namespace \
–set=fullScan=true \
–set=metricsScraper.enabled=true \
–set=protocolHttp=true # もしHTTPS設定をスキップしたい場合 (非推奨)

(必要に応じて) ダッシュボードにアクセスするためのServiceやIngressを設定

デフォルトではClusterIP Serviceが作成されるので、ポートフォワーディングなどでアクセスする必要があります。

例: kubectl port-forward service/kubernetes-dashboard -n kubernetes-dashboard 8080:80

ダッシュボードへのアクセスには認証設定が必要です。

通常はServiceAccountとClusterRoleBindingを作成し、トークンを使ってログインします。

“`

Kubernetes Dashboardのインストールや認証設定は少し複雑になるため、ここでは詳細を割愛しますが、公式ドキュメントを参照して設定してください。

これで、K3sクラスターにアプリケーションをデプロイし、外部からアクセスさせ、永続ストレージや設定情報を扱う基本的な方法を理解しました。次章では、K3sの構成と管理についてもう少し掘り下げます。

K3sの構成と管理

K3sはインストールが簡単ですが、運用する上で知っておきたい構成方法や管理コマンドがあります。

設定ファイル `/etc/rancher/k3s/config.yaml`

インストールスクリプト実行時に環境変数でオプションを渡す方法は便利ですが、より多くの設定項目を管理したり、恒久的な設定をしたい場合は、設定ファイルを使用するのが一般的です。

K3sは、YAML形式の設定ファイルを読み込むことができます。デフォルトの場所は/etc/rancher/k3s/config.yamlです。

サーバーまたはエージェントの起動時に、コマンドライン引数や環境変数で指定したオプションは、この設定ファイルの内容よりも優先されます。

設定ファイルの例：

“`yaml

/etc/rancher/k3s/config.yaml

K3sサーバー固有の設定例

datastore-endpoint: “mysql://user:password@tcp(db-server:3306)/k3s_db” # 外部DBを使う場合

disable-agent: true # サーバー専用ノードにする場合

disable-kube-proxy: true # Kube-Proxyを無効にする場合

エージェント固有の設定例

server: https://:6443 # K3S_URLの代替

token: # K3S_TOKENの代替

node-name: my-agent-node

サーバー/エージェント共通の設定例

node-ip: 192.168.1.101 # ノードのIPアドレスを指定

cluster-cidr: 10.42.0.0/16 # Cluster CIDRを指定

service-cidr: 10.43.0.0/16 # Service CIDRを指定

no-deploy: # デフォルトでデプロイされるアドオンを無効にする

– traefik

– servicelb

– metrics-server

taint: # ノードにテイントを設定

– “CriticalAddonsOnly=true:NoExecute”

– “node.kubernetes.io/diskpressure=true:NoSchedule”

containerd の設定例

containerd:

template: |

[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors]

[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”]

endpoint = [“https://mirror.gcr.io”]

“`

設定ファイルを変更した場合は、K3sサービス（k3sまたはk3s-agent）を再起動することで設定が反映されます。

bash sudo systemctl restart k3s # サーバーの場合 sudo systemctl restart k3s-agent # エージェントの場合

インストールスクリプト実行時にINSTALL_K3S_EXEC="--config /path/to/your/config.yaml"のように、カスタム設定ファイルのパスを指定することも可能です。

サービスの管理

K3sはSystemdまたはOpenRCなどのinitシステムによってサービスとして管理されます。サービスの起動、停止、再起動、ステータス確認は、systemctl（Systemdの場合）などの標準コマンドで行います。

サーバーサービス: k3s.service
bash sudo systemctl status k3s sudo systemctl start k3s sudo systemctl stop k3s sudo systemctl restart k3s sudo systemctl enable k3s # 起動時自動起動を有効化 sudo systemctl disable k3s # 起動時自動起動を無効化
エージェントサービス: k3s-agent.service
bash sudo systemctl status k3s-agent sudo systemctl start k3s-agent sudo systemctl stop k3s-agent sudo systemctl restart k3s-agent sudo systemctl enable k3s-agent sudo systemctl disable k3s-agent

K3sのログを確認したい場合は、journalctlコマンドを使用します。

“`bash

サーバーログ

sudo journalctl -u k3s -f

エージェントログ

sudo journalctl -u k3s-agent -f
“`

-fオプションを付けるとリアルタイムでログを追跡できます。トラブルシューティングの際にはこれらのログが重要になります。

データストアの管理

デフォルトのSQLite3データストアは、サーバーノードの/var/lib/rancher/k3s/server/db/state.dbファイルに保存されます。このファイルをバックアップすることで、クラスターの状態をバックアップできます。ただし、K3sサービスを停止した状態で行うのが安全です。

より高可用性やスケーラビリティが必要な場合は、PostgreSQLやMySQLといった外部データベースへの移行を検討します。移行手順はK3s公式ドキュメントに詳しく記載されています。

証明書の管理

K3sは起動時に必要なTLS証明書を自動的に生成し、管理します。証明書は/var/lib/rancher/k3s/server/tls/ディレクトリ以下に保存されます。通常、ユーザーがこれらの証明書を手動で操作する必要はありません。証明書の有効期限が近づくと、K3sが自動的に更新を行います。

アップグレード方法

K3sのアップグレードも非常に簡単です。基本的なアップグレード方法は、インストール時と同様にインストールスクリプトを再度実行するだけです。

“`bash

特定のバージョンにアップグレードする場合

curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=”v1.29.1+k3s1″ sh –
“`

スクリプトは、実行中のK3sサービスを停止し、指定されたバージョンのバイナリをダウンロードして配置し、サービスを再起動します。データストアのスキーマアップデートなども自動で行われます。

複数ノードクラスターをアップグレードする場合は、以下の手順で計画的に行うことが推奨されます。

データストアのバックアップ: アップグレード前に必ずデータストアのバックアップを取得します。
サーバーノードのアップグレード: まず全てのサーバーノードをアップグレードします。HA構成の場合、1台ずつローリングアップデートします。
エージェントノードのアップグレード: 全てのサーバーノードがアップグレードされ、クラスターが安定していることを確認したら、次に全てのエージェントノードをアップグレードします。ノードごとにPodをドレイン（退避）させてからアップグレードし、安全に再起動させます。

アップグレードの詳細な手順や注意点については、必ずアップグレード対象バージョンのK3s公式ドキュメントを参照してください。

K3sの構成ファイルやサービスの管理、アップグレードといった基本的な運用方法についても触れました。これらの知識があれば、インストールしたK3sクラスターをより安定して運用できるようになります。

K3sの応用シナリオ

K3sはその軽量性と簡単なインストールから、様々なシナリオで活用されています。ここでは代表的な応用例をいくつか紹介します。

開発環境 / テスト環境

開発者がローカルマシンや仮想マシン上に手軽にKubernetes環境を構築したい場合に最適です。Docker DesktopのKubernetes機能の代替として利用したり、特定のKubernetesバージョンの動作確認環境として利用したりできます。CI/CDパイプラインの中で、テストのために一時的にクラスターを立ち上げる用途にも向いています。

エッジコンピューティング / IoT

リソース制約が厳しいエッジデバイスやIoTゲートウェイでのコンテナオーケストレーションに最も適したソリューションの一つです。Raspberry Piのような小型デバイスでも動作するため、多数の分散したデバイス上でアプリケーションのデプロイ、アップデート、監視を効率的に行うことができます。

CI/CDパイプライン

テストやステージング環境として、ビルドパイプラインの中で一時的にK3sクラスターを起動し、アプリケーションをデプロイしてテストを実行し、完了後にクラスターを破棄するといった使い方が可能です。クラスターの起動・停止が高速なK3sは、このような短命な環境に非常に向いています。

小規模本番環境

データセンターやクラウド上で、それほど大規模ではないアプリケーションを運用する場合にも、K3sは有力な選択肢となります。特に、リソース効率を重視したい場合や、シンプルな構成で運用したい場合に適しています。外部データストア（PostgreSQL, MySQL, etcd）を利用することで、高可用性構成も構築可能です。

学習環境

Kubernetesの学習を始めたいけれど、Upstream Kubernetesのセットアップは難しすぎると感じている初心者にとって、K3sは最適なスタート地点です。基本的なKubernetesの概念やkubectlの使い方を、手軽に準備できる環境で学ぶことができます。標準APIに準拠しているため、K3sで学んだ知識はそのままUpstream Kubernetesにも応用できます。

トラブルシューティング

K3sのインストールや運用中に問題が発生した場合の一般的なトラブルシューティング方法をいくつか紹介します。

インストールスクリプトが失敗する場合:
- インターネット接続を確認してください。スクリプトはK3sバイナリなどをダウンロードします。
- システム要件（OSバージョン、アーキテクチャ）を満たしているか確認してください。
- root権限またはsudo権限で実行しているか確認してください。
- 古いK3sのインストールが残っていないか確認し、必要であればアンインストールスクリプトを実行してから再度インストールしてみてください。
- エラーメッセージを注意深く読み、検索して原因を特定します。
ノードがReadyにならない場合:
- サーバーノードの場合: sudo systemctl status k3s および sudo journalctl -u k3s -f でログを確認します。データストアへの接続問題、ポート競合などが原因である可能性があります。
- エージェントノードの場合: sudo systemctl status k3s-agent および sudo journalctl -u k3s-agent -f でログを確認します。サーバーへの接続問題、ノードトークンの誤り、ファイアウォールによる通信遮断などが原因である可能性があります。サーバーのIPアドレスやトークンが正しいか、ファイアウォールでポート6443が開放されているか確認してください。
- kubectl get nodes を実行し、イベントや条件を確認します。
- kubectl describe node <node-name> でノードの詳細情報を確認し、エラーや警告がないか調べます。
PodがPendingまたはCrashLoopBackOffになる場合:
- kubectl describe pod <pod-name> -n <namespace> でPodの詳細情報を確認します。イベント欄にスケジューリングの失敗理由やコンテナ起動エラーが表示されていることが多いです。
- PodがPendingの場合: スケジュール可能なノードがない、リソースが不足している、PersistentVolumeClaimがバインドできない、Node SelectorやTolerationsの設定ミスなどが考えられます。
- PodがCrashLoopBackOffの場合: コンテナが起動直後にクラッシュしている状態です。kubectl logs <pod-name> -n <namespace> でコンテナの標準出力/標準エラー出力を確認し、アプリケーションのエラーログを確認します。イメージのプル失敗、設定ミス、バグなどが原因です。
- kubectl get events --all-namespaces でクラスター全体のイベントを確認し、問題の手がかりを探します。
ファイアウォールやSELinuxの問題:
- K3sはデフォルトで必要なファイアウォールルールを設定しようとしますが、環境によっては手動設定が必要です。前述の必要なポートがノード間で開放されているか確認します。
- SELinuxがEnforcingモードになっている場合、K3sやコンテナの動作がSELinuxポリシーによってブロックされることがあります。ログ (audit.logなど) を確認し、適切なSELinuxポリシーを追加するか、一時的にSELinuxをPermissiveモードにして問題を切り分けます。
ログの確認:
- 最も重要なトラブルシューティングステップは、K3sサービス (journalctl -u k3s) やエージェントサービス (journalctl -u k3s-agent) のログ、およびKubernetesリソース（Pod, Node, Serviceなど）のイベントやログ (kubectl describe, kubectl logs, kubectl get events) を確認することです。エラーメッセージや警告から原因を特定し、解決策を探します。

トラブルシューティングは試行錯誤が必要な場合が多いですが、上記の基本的な手順とログの確認は、多くの問題を解決するための出発点となります。

まとめと次のステップ

この記事では、軽量KubernetesディストリビューションであるK3sについて、その背景、特徴、アーキテクチャから、具体的なインストール方法、基本的な使い方、そして運用管理のポイントまでを詳細に解説しました。

K3sは、従来のKubernetesが抱える「複雑さ」と「リソース消費」という課題に対して、軽量で簡単なインストールという明確な解決策を提供します。シングルバイナリの中に必要なコンポーネントが詰まっており、エッジ、IoT、開発/テスト、CI/CD、小規模本番環境といった様々なシナリオでその真価を発揮します。そして最も重要なのは、標準的なKubernetes APIとの高い互換性を持っているため、既存のKubernetesの知識やエコシステムをそのまま活用できる点です。

この記事を読んだことで、あなたは以下のことができるようになったはずです。

K3sがなぜ必要とされているのか、そのメリットを理解する。
K3sの基本的なアーキテクチャと、軽量性の秘密を知る。
Linux環境にK3sのシングルノードまたは複数ノードクラスターを簡単にインストールする。
kubectlコマンドを使ってK3sクラスターの基本的な操作（ノード・Pod確認、デプロイメント・サービスの作成など）を行う。
K3sにおけるサービスの公開（NodePort, Ingress）や永続ストレージ（Local Path Provisioner）の仕組みを理解し、利用する。
K3sサービスやログの確認、アップグレードといった基本的な運用管理を行う。
発生しうる問題に対する基本的なトラブルシューティング方法を知る。

これはK3s、ひいてはKubernetesの世界への素晴らしい第一歩です。さらに学びを深めたい場合は、以下のテーマに進んでみましょう。

Helm: Kubernetesアプリケーションのパッケージ管理ツール。複雑なアプリケーションもテンプレートを使って簡単にデプロイ・管理できます。
GitOps: Gitリポジトリを中心としたKubernetesクラスターの構成管理手法。FluxCDやArgo CDといったツールがあります。
モニタリングとロギング: Prometheus, Grafanaを使ったクラスター・アプリケーションの監視、Elasticsearch, Fluentd, Kibana (EFK) やLokiを使ったログ収集・分析。
高度なネットワーキング: Calico, Ciliumなどの他のCNIオプション、NetworkPolicyによるPod間通信の制御。
高度なストレージ: NFS, Ceph, 各種クラウドプロバイダーのCSIドライバーを使った、より堅牢な永続ストレージ。
セキュリティ: RBAC (Role-Based Access Control) によるアクセス制御、Pod Security Standards/Policies、ネットワークセキュリティなど。
CI/CDツールの連携: Jenkins, GitLab CI, GitHub ActionsなどからK3sクラスターにデプロイする方法。
K3sの高可用性構成: 外部データベース (PostgreSQL, MySQL, etcd) を利用したサーバーノードのHA構成。

K3sに関する最新情報やより詳細な技術情報は、公式ドキュメントを参照するのが最も良い方法です。

K3s 公式ウェブサイト: https://k3s.io/
K3s 公式ドキュメント: https://docs.k3s.io/
Rancher Labs ウェブサイト: https://rancher.com/

また、CNCF SlackのK3sチャンネルなど、コミュニティに参加して質問したり、他のユーザーと交流したりするのも良いでしょう。

K3sは、Kubernetesをより多くの場所、より多くの人が利用できるようにする、非常に価値のあるプロジェクトです。この記事が、あなたがK3sを始めるための一助となれば幸いです。

Happy Kubernet-ing (with K3s)!

簡単インストール！軽量Kubernetes K3s の始め方

はじめに：なぜ今、軽量Kubernetes「K3s」なのか？

なぜK3sなのか？ K3sの魅力とメリット

1. 圧倒的な軽量性

2. 驚くほど簡単なインストール

3. シングルバイナリ

4. オールインワンパッケージ

5. 信頼性と本番環境での実績

6. 標準的なKubernetes API互換性

7. セキュリティバイデフォルト

K3sのアーキテクチャ概要

マスター（サーバー）とエージェントの構成

シングルバイナリ k3s の中身

データストアの選択肢

従来のKubernetesとの違い（内部構造）

K3sのインストール方法（詳細）

前提条件

インストールスクリプトを使った方法（最も簡単）

1. シングルノード（サーバー兼エージェント）としてのインストール

KUBECONFIG環境変数を設定してkubectlを使う場合

2. 複数ノード構成（サーバーとエージェント）のインストール

サーバーとしてインストール

サーバー専用ノードとしてインストール (任意)

サーバーノードでトークンを取得

エージェントとしてインストール

ファイアウォールの設定

アンインストール方法

K3sの基本的な使い方

kubectlコマンドのセットアップと使い方

最新版をダウンロード

実行権限を付与

パスが通っているディレクトリに移動（例: /usr/local/bin/）

デプロイメントの作成

サービスの公開

/etc/hosts に追記 (例: Ingress Controllerが192.168.1.100で動作している場合)

永続ストレージ

コンフィグマップとシークレット

ダッシュボードのインストール（オプション）

Kubernetes DashboardのHelmリポジトリを追加

Dashboardと推奨アドオンをインストール

(必要に応じて) ダッシュボードにアクセスするためのServiceやIngressを設定

デフォルトではClusterIP Serviceが作成されるので、ポートフォワーディングなどでアクセスする必要があります。

例: kubectl port-forward service/kubernetes-dashboard -n kubernetes-dashboard 8080:80

ダッシュボードへのアクセスには認証設定が必要です。

通常はServiceAccountとClusterRoleBindingを作成し、トークンを使ってログインします。

K3sの構成と管理

設定ファイル /etc/rancher/k3s/config.yaml

/etc/rancher/k3s/config.yaml

K3sサーバー固有の設定例

datastore-endpoint: “mysql://user:password@tcp(db-server:3306)/k3s_db” # 外部DBを使う場合

disable-agent: true # サーバー専用ノードにする場合

disable-kube-proxy: true # Kube-Proxyを無効にする場合

エージェント固有の設定例

server: https://:6443 # K3S_URLの代替

token: # K3S_TOKENの代替

node-name: my-agent-node

サーバー/エージェント共通の設定例

node-ip: 192.168.1.101 # ノードのIPアドレスを指定

cluster-cidr: 10.42.0.0/16 # Cluster CIDRを指定

service-cidr: 10.43.0.0/16 # Service CIDRを指定

no-deploy: # デフォルトでデプロイされるアドオンを無効にする

– traefik

– servicelb

– metrics-server

taint: # ノードにテイントを設定

– “CriticalAddonsOnly=true:NoExecute”

– “node.kubernetes.io/diskpressure=true:NoSchedule”

containerd の設定例

containerd:

template: |

[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors]

[plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”]

endpoint = [“https://mirror.gcr.io”]

サービスの管理

サーバーログ

エージェントログ

データストアの管理

証明書の管理

アップグレード方法

最新版にアップグレードする場合

シングルバイナリ `k3s` の中身

`kubectl`コマンドのセットアップと使い方

設定ファイル `/etc/rancher/k3s/config.yaml`

コメントする返信をキャンセル