K3s とは? 概要と基本設定を解説
完全な Kubernetes ディストリビューションよりも少ないリソースを使用し、可動部分を少なくしたい場合は、Rancher Labs(現在は SUSE の一部)で開発された K3s プロジェクトを検討することをお勧めします。K3s は Cloud Native Computing Foundation(CNCF)プロジェクトになったため、Kubneretes 用に構築された構成を機能させるには、他の CNCF 認定ディストリビューションと同じソフトウェア適合性テストに合格する必要があります。
一般的な Kubernetes (K8s)よりも稼働するリソースを減らしたい場合、機能をシンプルにしたい場合は、機能削減版の軽量ツール「K3s」を導入するのがおすすめです。
この記事では、K3sの導入を検討している方に向けて、概要や設定などの基本を解説します。あわせて代替となる軽量Kubernetes ディストリビューションも紹介しますので、比較の参考となれば幸いです
関 連 記 事
Kubernetesとは?Kubernetesセキュリティ
の基礎Kubernetesアーキテクチャの
設計方法AWSのEKS
(Elastic Kubernetes Service)Kubernetesの
クラスターとは? Kubernetes のノードとは?KubernetesのPodとは?KubernetesのHelmとは?クラウドセキュリティと
ランタイムインサイト
K3s とは
K3sとは、コンテナオーケストレーションツールのKubernetesの軽量版として、エッジコンピューティング向けに改良されたプラットフォームです。
Kubernetesの一般的な短縮形が「K8s」であることから、それをもじって「K3s」と命名されました。8はkとsの間の文字数(k「ubernete」s)を表します。K3sという言葉は、K3sの要件である「K8sから5つの要素を変更(削除)して軽量化(5 less than K8s)した」ことを表すために、Kubernetesの文字の総数(10)を半分に割り、8を3に置き換えました。
なおK3sは、Rancher Labs(現在はSUSEの一部)で開発され、Cloud Native Computing Foundation(CNCF)プロジェクトになったものです。Kubneretes 用に構築された構成を機能させるには、他のCNCF認定ディストリビューションと同じソフトウェア適合性テストに合格する必要があります。
K3sとK8sの違い
K3sとKubernetes(K8s)は、ともにコンテナオーケストレーションツールですが、仕様が異なります。ここではアーキテクチャの違いを詳しく見ていきましょう。
Kubernetesアーキテクチャモデルには 6 つの主要なコンポーネントがあります (それぞれが個別のプロセスです)。
コントロールプレーンノードで実行される 4 つの Kubernetes コンポーネントは次のとおりです。
- API Server:コンポーネント間のすべての通信を管理します。
- Controller Manager:クラスターを維持するために使用されるすべてのジョブを管理します。
- Scheduler:新しく作成された Pod(ホームが含まれない)を探して、それらを見つけます。
- Cloud Controller Manager(オプション):ストレージやロードバランサの構成などについて、既知のクラウドプロバイダとやり取りします。
さらに、クラスターがその状態を管理するために使用する構成関連の情報を保持するために、キー/値ストアも必要です。この目的で最も一般的に使用されるデータベースは etcd であり、通常はコントロールプレーンで実行されます。
ワーカーノードには、次の 2 つのコンポーネントがあります:
- kubelet:ノードで実行されているコンテナのライフサイクルを処理します。
- kube-proxy:ホストとの間で送受信されるクラスター内ネットワークトラフィックの中心点です。

Kubernetes の完全なアーキテクチャ
(出典: https://kubernetes.io/docs/concepts/overview/components/)
対して、K3s のアプローチは、アルファとベータの段階のすべての API 仕様を含む、オプションのすべてを取り除いた Kubernetes ディストリビューションを提供することです。一部の軽量ディストリビューションでは、これ以上の合理化はできませんが、K3s では、さらに一歩進んで、残りの機能を 2 つのカスタムバイナリ(コントロールプレーンコンポーネントとワーカーノードコンポーネント)に構築します。
デプロイと運用モデルをさらに簡素化するために、これらのバイナリにはネットワーキング用の CNI プラグインと組み込みのキー/値データストアも含まれています。組み込みデータストアは、外部データベースを実行する必要はないように、単一のコントロールプレーンノードを備えたクラスターで使用されます(このような場合は過度のオーバーヘッドが発生します)。

K3s アーキテクチャ
(出典: https://k3s.io/img/how-it-works-k3s-revised.svg)
K3dとK3sの違い
K3dは、Dockerコンテナ内でK3sを動かすためのツールです。
そもそもK3dは、プロセスではありません。コンテナとしてオペレーティングシステムでK3sを直接実行するコミュニティ主導のオープンソースユーティリティであり、これがデフォルトの構成になります。その他の利点は、単一のホストOS内で複数のK3sクラスターを実行できることです。複数ノード構成のテストに役立ち、CI/CDパイプラインをサポートするために複数のクラスターをスピンする際の速度と信頼性が向上します。
詳細については、k3d.io を参照してください。 K3sと同じく開発を推進するコミュニティや営利団体がK3dにもありますが、K3dは現在商業的なサポートを受けていないことも押さえておきたいポイントです。
K3sの基本設定
K3sには、設定に使用できるデプロイモデルがいくつかあります。単一ノードクラスター、複数のワーカーを備えた単一のコントロールプレーンノード、または複数のワーカーを備えた複数のコントロールプレーンノードを使用できます。
Rancher のクイックスタートガイドでも説明していますが、単一ノードクラスターのインストールは、単一のコマンドを発行するのと同じくらい簡単です。
root@server:~# curl -sfL https://get.k3s.io | sh -
[INFO] Finding release for channel stable
[INFO] Using v1.22.6+k3s1 as release
[INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/sha256sum-amd64.txt
[INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/k3s
[INFO] Verifying binary download
[INFO] Installing k3s to /usr/local/bin/k3s
[INFO] Skipping installation of SELinux RPM
[INFO] Creating /usr/local/bin/kubectl symlink to k3s
[INFO] Creating /usr/local/bin/crictl symlink to k3s
[INFO] Creating /usr/local/bin/ctr symlink to k3s
[INFO] Creating killall script /usr/local/bin/k3s-killall.sh
[INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh
[INFO] env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO] systemd: Creating service file /etc/systemd/system/k3s.service
[INFO] systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO] systemd: Starting k3s
コマンドは追加の構成なしで動作し、すべてが適切に開始されたようです。
root@server:~# kubectl get nodes -A
NAME STATUS ROLES AGE VERSION
server Ready control-plane,master 1m29s v1.22.6+k3s1
ワーカーノードの追加
すべての要件が満たされていれば、ワーカーノードの追加も単一のコマンドを発行するのと同じくらい簡単です。サーバーのホスト名と /var/lib/rancher/k3s/server/token ファイルからのトークンが必要になります。
[root@agent ~]# curl -sfL https://get.k3s.io |
K3S_URL=https://myserver:6443
K3S_TOKEN=mynodetoken
sh -
[INFO] Finding release for channel stable
[INFO] Using v1.22.6+k3s1 as release
[INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/sha256sum-amd64.txt
[INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.22.6+k3s1/k3s
[INFO] Verifying binary download
[INFO] Installing k3s to /usr/local/bin/k3s
[INFO] Skipping installation of SELinux RPM
[INFO] Creating /usr/local/bin/kubectl symlink to k3s
[INFO] Creating /usr/local/bin/crictl symlink to k3s
[INFO] Creating /usr/local/bin/ctr symlink to k3s
[INFO] Creating killall script /usr/local/bin/k3s-killall.sh
[INFO] Creating uninstall script /usr/local/bin/k3s-agent-uninstall.sh
[INFO] env: Creating environment file /etc/systemd/system/k3s-agent.service.env
[INFO] systemd: Creating service file /etc/systemd/system/k3s-agent.service
[INFO] systemd: Enabling k3s-agent unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s-agent.service → /etc/systemd/system/k3s-agent.service.
[INFO] systemd: Starting k3s-agent
動作しましたか?はい、動作しました。
root@server:~# kubectl get nodes -A
NAME STATUS ROLES AGE VERSION
server Ready control-plane,master 4m35s v1.22.6+k3s1
agent Ready <none> 50s v1.22.6+k3s1
エアギャップインストール
インターネットが利用できない、または信頼できない環境でインストールを実行する必要がある場合、またはインターネットからのランダムなスクリプトを信頼したくない場合は、エアギャップインストールを実行する必要があります(「エアギャップ」とは、もともとセキュリティ業界で使用されていた用語で、インターネットと該当のデバイスの間に物理的な分離があることを意味しています)。
このタイプのインストールを実行するには、公式の GitHub リポジトリ(https://github.com/k3s-io/k3s/releases)から選択した K3s リリースをダウンロードする必要があります。次に、Rancher のエアギャップのドキュメントに記載されていインストール手順に従います。リリースアーカイブをダウンロードして解凍するだけなので、インストールは非常に簡単です。
高可用性のための複数ノードコントロールプレーンの有効化
K3s は、すぐに使用できる高可用性コントロールプレーンをサポートするように構成されていませんが、そのような機能を構成して高可用性を実現することは可能です。これらの手順の説明と追加の要件については、Rancher のインストールドキュメントを参照してください。
Rancher の高可用性インストールガイドによると、コントロールプレーンのメンバーとなるすべてのノードで、外部データストアを指す追加のパラメータを使用してサーバーの設定を実行するのが一般的です。次に、ワーカーを追加する前に、ワーカーが接続するための単一のエントリポイントを設定する必要があります。これにより、コントロールプレーンノードに障害が発生した場合に、ワーカーを再構成する必要がなくなります。通常は、仮想 IP またはロードバランサがその機能を提供します。
これらを設定したら、前述と同じコマンドを使用してワーカーノードを追加します。
代替となる軽量Kubernetes ディストリビューション
さまざまなプロジェクトで軽量の Kubernetes ディストリビューションが開発されています。
中でも一般的なものがMinikube」「MicroK8s」「MicroShift」の3つです。以下はK3sとの比較表となります。
K3s、MicroK8s、Minikube、MicroShift
K3s
MicroK8s
Minikube
MicroShift
支援
CNCF
(Rancher が寄付)
Canonical
Kubernetes(CNCF 傘下)
Red Hat
最小メモリ
0.5 GB
0.5 GB
2 GB
2 GB
アーキテクチャ
x86、ARM64、ARMv7
x86、ARM64、s390x
x86、ARM64、ARMv7、ppc64、s390x
x86(AMD64)、ARM64、または riscv64
デフォルト HA
いいえ
はい
いいえ
いいえ
デフォルト CNI
Flannel
Flannel
KindNet
Flannel
デフォルトイングレス
traefik
N/A
N/A
OpenShift-ingress
パッケージ OS
N/A
Ubuntu
Debian
N/A
実行 OS
ほとんどの主要な Linux ディストリビューション(Ubuntu、SUSE、RHEL、Rocky など)
MacOS、Windows、ほとんどの主要な Linux ディストリビューション
MacOS、Windows、ほとんどの主要な Linux ディストリビューション
Red Hat ファミリ(CentOS Streams、Fedora、RHEL)の最近の Linux ディストリビューション向けに設計
カスタム Kubernetes バイナリ
はい
いいえ
いいえ
いいえ
商業サポートの利用
はい
(SUSE)
はい
(Canonical)
いいえ
まだ利用できません
(Red Hat)
Minkube
Minikube は、Kubernetes プロジェクトによって開発および管理されています。その主な目的は、開発とテストの目的で使用する単一ノードの Kubernetes クラスターを提供することです。これは、クラスターと同様に最も基本的な機能である Kubernetes であるため、CNI、イングレス、CSI、デプロイなど、他のクラスターに適用する構成を適用できます。Minikube の標準的なデプロイは、Debian Linux VM 内で実行され、Docker、HyperKit、Hyper-V、KVM、Parallels、Podman、VirtualBox、VMware Fusion/Workstation で実行されます。これは VM モデルを使用しているため、MacOS、Windows、Linux デスクトップで同様に適切に実行できます。
MicroK8s
MicroK8s は、リソースに制約のある環境に対処するために Canonical によって開発されました。また、Minikube よりもベースランタイムに必要なメモリが少なく、本番環境で実行できるものと正確に一致するため、開発とテストの多くの環境で採用されています。Minikube と同様、MicroK8s は Ubuntu ベースの VM として利用できるため、既存の Ubuntu ホストに直接デプロイすることもできます。Kubernetes クラスター内のホストは、開発ホストやテストホストとは異なり、通常は単一目的であるため、これは本番環境で最もよく使用されるモデルです。
MicroShift
OpenShift は、Red Hat によって構築されたエンタープライズ向けの主要な Kubernetes ディストリビューションです。これらは、MicroShiftと呼ばれる軽量のディストリビューションを提供します。これは、同じエンタープライズ向けのテクノロジを組み合わせて構築されていますが、エッジのユースケースに重点を置いています。これは前述の他のオプションほど成熟していませんが、MicroShift はテクノロジスタックに含まれる選択肢が規範的です(K3s と同様)。
まとめ
K3s は認定された Kubernetes ディストリビューションであるため、Kubernetes のあらゆるデプロイで適切に機能します。
ただし、大規模なクラスターを使用する場合は、Rancher の RKE2 や、GKE、EKS、Civo などのマネージドサービスを使用することをお勧めします。
K3s が真価を発揮するのは、開発環境やテスト環境、IoT やエッジコンピューティングなどのリソースに制約のある環境です。Kubernetes はその機能で優れており、軽量のランタイムを使用した合理化されたデプロイは、まさにそのような状況で必要とされているものです。
