K3sとは？読み方・k8sとの違いとインストール手順、構成の選び方

K3s（ケー・スリー・エス）は、Kubernetesを100MB未満の単一バイナリにまとめた軽量ディストリビューションです。CNCFの適合性認定を受けたKubernetesなので、kubectlやHelmはそのまま使えます。上流と違うのは、データストアの既定がetcdではなくSQLiteであること、Ingressやロードバランサーまで同梱していること、Linuxなら curl -sfL https://get.k3s.io | sh - の1行でクラスタが立ち上がることの3点です。既存のマニフェストやHelmチャートを移すときは、IngressコントローラーやStorageClassの違いに合わせた確認が要ります。

以下、版やコマンドは2026年9月28日時点の公式ドキュメントとstableリリース（v1.36.4+k3s1）に基づきます。

まとめ：K3sの要点

• 正体：Rancher（現SUSE）が開発したKubernetesディストリビューション。フォークではなく、上流Kubernetesに1,000行未満のパッチを当てて同梱物を足したもの。2020年8月からCNCFのSandboxプロジェクト。
• 読み方：公式の読み方も正式名称も無い。k8sの半分（10文字の半分＝5文字）という意味でK3s。
• k8sとの違い：単一バイナリ、既定データストアがSQLite、containerd・Flannel・CoreDNS・Traefik・ServiceLB・local-path-provisionerを同梱。
• 最小要件：サーバーが2コア・2GB、エージェントが1コア・512MB。Linux（x86_64・armhf・arm64）専用で、Windowsはネイティブ非対応。
• インストール：curl -sfL https://get.k3s.io | sh -。入るのはstableチャネルの版で、最新版（v1.37.0+k3s1）ではない。
• HA：組み込みetcdで3台以上の奇数サーバー、または外部のMySQL・PostgreSQL等。SQLiteのままではサーバーを増やせない。
• 選び分け：エッジ・ARM・小規模本番・CIはK3s、手元のDockerで試すならk3dやkind、政府調達・FIPS要件ならRKE2。

K3sの名前の由来と読み方

公式README（k3s-io/k3s）では、名前の由来を次のように説明しています。Kubernetesは10文字なので「k8s」と略される。メモリ使用量が半分のKubernetesなら5文字、だから「K3s」。さらに「3」は「8」を縦半分に切った形でもある、という二重の洒落です。同じ箇所に「K3sには正式な長い名称も、公式の読み方もない」と明記されています。

そのため特定の読み方だけが正しいわけではありません。アルファベットをそのまま「ケー・スリー・エス」と読めば、誤解なく伝わります。

位置づけも押さえておくと誤解が減ります。READMEは「これはフォークではなくディストリビューション」と述べ、上流から乖離させる意図はなく、保守しているパッチは1,000行を大きく下回るとしています。CNCFには2020年8月19日にSandbox成熟度で受け入れられ、2026年9月時点でもSandboxのままです（Incubating・Graduatedではありません）。Kubernetesそのものの仕組みはKubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説で扱っています。

K3sとk8s（Kubernetes）の違い

K3sは上流Kubernetesの機能を削った「簡易版」ではありません。CNCFの適合性テストに通っているので、Deployment・Service・Ingress・CRDといったAPIは同じように使えます。違いは配布の仕方と、最初から入っている部品にあります。

最小要件の数字は並べると同じです。軽さの差は、コントロールプレーンの各コンポーネントを1プロセスにまとめたことと、etcdの代わりにSQLiteを使えることから生まれます。

単一バイナリと同梱コンポーネント

v1.36.4+k3s1のリリースノートに載っている同梱物の版は、containerd v2.3.4、Flannel v0.28.4、CoreDNS v1.14.6、Traefik v3.7.8、metrics-server v0.9.0、local-path-provisioner v0.0.37です。このほか、ネットワークポリシーを処理するkube-routerのコントローラーと、HelmChartカスタムリソースを処理するhelm-controllerも入っています。

もう1つの違いが通信の向きです。上流ではコントロールプレーンが各ノードのkubelet（10250番）へ接続しますが、K3sではエージェントがサーバーの6443番へ外向きに接続し、kubeletの通信はそのトンネルを通ります。エージェント側に受信ポートを開けずに済むので、NAT越しのエッジ拠点でも組みやすくなります（ただしmetrics-serverを使うなら10250番はノード間で開ける必要があります）。

データストアの選択肢：SQLite・組み込みetcd・外部DB

他の設定が無く、ディスク上にetcdのファイルも無ければ、K3sは組み込みSQLiteを使います。シングルサーバーには十分ですが、SQLiteのままサーバーを2台以上にすることはできません。HAにするときは次の2つから選びます。

• 組み込みetcd：1台目を --cluster-init で起動し、3台以上の奇数台でクォーラムを組む。etcdを別に運用する必要はない。
• 外部データストア：--datastore-endpoint で接続文字列を渡す。認定されている版はetcd 3.5.21、MySQL 8.0／8.4、MariaDB 10.11／11.4、PostgreSQL 15.12／16.7／17.3。

外部DBには制約が2つあります。kineはリビジョンが1ずつ増える前提なので、auto_increment_increment を1より大きくするGaleraのようなマルチマスター構成は使えません。プリペアドステートメントも必須なので、トランザクションプーリングのPgBouncerを挟むなら追加設定が要ります。

K3sの動作要件とポート

公式の最小要件は、ワークロード分を含まない基礎値です。

対応アーキテクチャはx86_64、armhf（32ビットARM）、arm64です。OSは「現代的なLinuxのほとんど」で、Windowsはネイティブに対応していません。macOSでも直接は動かないので、手元のMacで試すならDocker上で動かすk3d（後述）か、Linux VMを使います。

サーバー1台で抱えられるエージェント数の目安は、2コア・4GBで350台まで、4コア・8GBで900台まで、8コア・16GBで1,800台までです。公式のサイジング目安では、3台のHA構成でエージェント数を約50％増やせるとしています。ただしワークロードによって変わり、255ノードを超える構成では既定のcluster-cidrの変更も必要です。

ディスクはSSDを推奨しています。etcdは書き込みが多く、Raspberry PiのSDカードやeMMCでは負荷に耐えられないので、組み込みetcdを使うなら外付けSSDにします。

開けるポートとファイアウォール

8472番をインターネットに晒すと、誰でもクラスタ内ネットワークに入れてしまいます。VXLANのポートは必ずファイアウォールかセキュリティグループの内側に置いてください。公式はufwやfirewalldを止めることを推奨していますが、残すならPod用の10.42.0.0/16とService用の10.43.0.0/16を許可する必要があります。

K3sのインストール手順（シングルノード）

サーバー1台で、データストア・コントロールプレーン・kubelet・コンテナランタイムまで揃った完全なクラスタになります。

# サーバーをインストール（systemd または OpenRC のサービスとして登録される）
curl -sfL https://get.k3s.io | sh -

# 動作確認
sudo k3s kubectl get nodes
sudo k3s kubectl get pods -A

インストールスクリプトは、k3sバイナリに加えて kubectl・crictl・ctr のシンボリックリンク、k3s-killall.sh、k3s-uninstall.sh を /usr/local/bin に置きます。kubeconfigは /etc/rancher/k3s/k3s.yaml に書かれ、同梱のkubectlは自動でこれを読みます。

入る版はstableチャネル：版を固定する方法

見落としやすい点です。インストールスクリプトの INSTALL_K3S_CHANNEL の既定値は stable で、2026年9月28日時点のstableはv1.36.4+k3s1（8月27日公開）です。9月14日に出たv1.37.0+k3s1はlatestチャネルの対象ですが、この時点ではstableチャネルの対象ではありません。「最新のKubernetesを試したい」なら明示が要り、本番では逆に版を固定しておかないと、ノードを後から足したときに別の版が入ります。

# 版を固定する（本番はこちら）
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.36.4+k3s1 sh -

# latest チャネルから入れる
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest sh -

設定ファイルconfig.yamlとkubeconfigの扱い

起動オプションはコマンドライン引数でも渡せますが、/etc/rancher/k3s/config.yaml に書いておくと再インストールやアップグレードのときに漏れません。

# /etc/rancher/k3s/config.yaml
disable:
  - traefik
tls-san:
  - k3s.example.internal
node-label:
  - "env=dev"

k3s.yaml は system:masters グループの資格情報で、クラスタ内の全リソースを無制限に操作できます。手元のPCから操作したいときは、このファイルを ~/.kube/config としてコピーし、server の 127.0.0.1 をサーバーのIPかホスト名に書き換えます。権限を緩める write-kubeconfig-mode: "0644" は、共用マシンでは全ユーザーに管理者権限を渡すのと同じなので避けてください。RBACで権限を絞った利用者を作る手順は上流Kubernetesと同じです。

エージェントの追加と高可用性（HA）構成

エージェントノードの参加手順と認証トークン

参加用トークンはサーバーの /var/lib/rancher/k3s/server/node-token にあります。エージェント側で K3S_URL と K3S_TOKEN を付けてスクリプトを流すと、サーバーではなくエージェントとして登録されます。

# サーバーでトークンを確認
sudo cat /var/lib/rancher/k3s/server/node-token

# エージェントで実行（SERVER_IP と TOKEN を置き換える）
# サーバーの版を固定した場合は、同じINSTALL_K3S_VERSIONも指定する
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=TOKEN sh -

ホスト名が重複するノードは参加できません。クローンしたVMやRaspberry Piを並べるときは、--with-node-id でランダムな接尾辞を付けるか、K3S_NODE_NAME で一意の名前を渡します。

組み込みetcdによる3台HA構成の作成手順

# 1台目：クラスタを初期化
curl -sfL https://get.k3s.io | K3S_TOKEN=SHARED_SECRET sh -s - server --cluster-init

# 2台目・3台目：1台目に参加
curl -sfL https://get.k3s.io | K3S_TOKEN=SHARED_SECRET sh -s - server --server https://SERVER1_IP:6443

サーバーを奇数台にするのはetcdのクォーラムのためです。n台ならクォーラムは過半数、つまりn÷2の小数部分を切り捨てて1を足した台数で、3台なら1台、5台なら2台の故障まで耐えます。4台にしても耐えられる故障は3台と同じ1台で、故障しうる台数が増えるだけです。エージェントや外部のkubectlが接続する先を固定したいときは、ロードバランサーやDNSの固定アドレスを用意し、その名前を --tls-san で証明書に入れておきます。

Traefik・ServiceLBなど同梱機能の外し方

同梱物は、サーバーの /var/lib/rancher/k3s/server/manifests に置かれたマニフェストから自動デプロイされるものがあります。ただし、ServiceLBは組み込みコントローラーで、対応するマニフェストファイルはありません。保守が継続しているIngressコントローラーやMetalLBに置き換えるなら、--disable で外します。

# インストール時に Traefik と ServiceLB を外す
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik --disable=servicelb" sh -

# Flannel も外して別の CNI を入れる場合
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend=none --disable-network-policy" sh -

--disable は既存のクラスタに後から付けても効き、該当コンポーネントをクラスタから削除してマニフェストファイルも消します。HA構成では全サーバーに同じ指定を入れてください。Flannelの設定もサーバー間で同一である必要があり、別のCNIを入れる場合はCNI側のポリシーエンジンと衝突しないよう --disable-network-policy も付けるのが公式の推奨です。

もう1つの方法が、マニフェストと同じ名前の .skip ファイル（例：traefik.yaml.skip）です。初回起動前に置けばデプロイされませんが、既にデプロイ済みのものは消えず、以後のアップグレードでも更新されなくなります。既存クラスタで外すなら --disable を使ってください。

このディレクトリには自作のマニフェストも置けます。拡張子を除いたファイル名が管理用のAddOnリソース名になるので、アンダースコアを含む名前（example_manifest.yaml など）は検証エラーになります。ベアメタルでLoadBalancerを本格的に使うならMetalLBとは？ベアメタルKubernetesでLoadBalancerを使う仕組みとL2・BGPの選び方も参考になります。

K3sのアップグレードとアンインストール

手動アップグレードは、初回と同じオプションでインストールスクリプトを再実行します。実行前に、データストアとサーバートークンをバックアップし、復元手順を確認してください。順序には決まりがあり、サーバーを1台ずつ先に上げ、エージェントは後にします。エージェントがサーバーより新しい状態はKubernetesのバージョンスキューポリシー上認められないためです。マイナー版を飛ばすのも不可で、1.34から1.36へ上げるなら1.35を経由します。

# サーバー用：初回の起動設定をすべてconfig.yamlに保存している場合の例
# 初回に引数・環境変数で渡した設定は再指定が必要
# エージェントでは参加先・トークンとagent起動指定も維持する
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.37.0+k3s1 sh -

台数が多いなら、Rancherのsystem-upgrade-controllerを入れて、Planカスタムリソースで宣言的に上げる方法があります。ただしこのコントローラー自体はマイナー版の飛び越しを防がないので、Planの版指定は自分で1段ずつ進めます。Kubernetes本体の版ごとのサポート期限はKubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順で確認できます。

アンインストールは、サーバーなら /usr/local/bin/k3s-uninstall.sh、エージェントなら /usr/local/bin/k3s-agent-uninstall.sh です。アンインストールはローカルのデータストアとlocal-path-provisionerの永続ボリュームのデータまで消します（外部DBの中身は消えません）。同じノードを再参加させる場合は、先にクラスタから kubectl delete node でノードを消しておかないと、ノードパスワードのSecretが残り、再登録が拒否される原因になります。

K3sのセキュリティ設定：Pod Security AdmissionとCIS準拠

旧来のPodSecurityPolicy（PSP）はKubernetes 1.25で削除されました。K3s v1.25以降は、Pod Security Admission（PSA）の設定ファイルをAPIサーバーに渡して制御します。以下は公式のCISハードニングガイドを基に、PSAの強制設定などを抜き出した例です。これだけでCIS準拠になるわけではなく、監査ログやNetworkPolicy、ホスト側の設定も必要です。

# /var/lib/rancher/k3s/server/psa.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
    exemptions:
      namespaces: [kube-system]

# /etc/rancher/k3s/config.yaml に追記
kube-apiserver-arg:
  - "admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml"
secrets-encryption: true
protect-kernel-defaults: true

secrets-encryption はサーバーの初回起動時に指定すると、保存時のSecret暗号化を有効にし、鍵と暗号化設定を自動生成します。protect-kernel-defaults はカーネルパラメータがkubeletの期待値と違うときに起動を止める設定で、先にsysctlを合わせておかないとサーバーが立ち上がりません。いきなり enforce: "restricted" にすると既存のPodが作れなくなることがあるので、まず warn と audit だけで違反を洗い出す順が安全です。

K3s・k3d・MicroK8s・minikube・kind・RKE2の使い分け

「軽量Kubernetes」と呼ばれるものは、実行場所と目的がそれぞれ違います。各プロジェクトの公式READMEの説明を基に並べると次のとおりです。

k3dとK3sの違いは「同じK3sをどこで動かすか」だけです。k3dはK3sをDockerコンテナとして起動する補助ツールで、MacやWindowsのDocker Desktop上でも複数ノード構成を作れます。ただしk3dはコミュニティ主導のプロジェクトで、SUSEの公式製品ではありません。本番のノードにはK3sを直接入れます。

MicroK8sとK3sの違いは配布経路と作り手です。MicroK8sはCanonicalがsnapパッケージとして配り、最小構成の上流Kubernetesに microk8s enable dns のようにアドオンを足していく方式です。snapを使わずに導入したい場合、K3sは候補になります。ただしエアギャップ環境では、バイナリだけでなくコンテナイメージやインストールスクリプトなどの事前搬入も必要です。

手元でKubernetesを学ぶだけなら、Docker上で完結するkindやminikubeでも十分です。kindの手順はk8sをローカルで動かす手順｜kindでクラスタ構築からDeployment公開・撤収までにまとめています。K3sをSSH越しに複数台へ配るなら、公式が紹介するk3sup・k3s-ansibleのほか、k0sを使うk0sctlとは？k0sクラスター構築・アップグレード手順とk3s・kubeadmとの違いも比較対象になります。

K3sを選ばない方がよい条件

• Windowsノードが要る：K3sはWindowsにネイティブ対応していない。
• コンポーネントごとにログを分けたい：Kubernetesの主要コンポーネントが同一プロセスで動き、klogの設定を共有するため、それらのログレベルや出力先を個別に変えられない。-v や --vmodule を渡しても期待どおりには効かない。
• SDカードのRaspberry Piで組み込みetcdのHA：公式が性能問題を警告している。外付けSSDにするか、シングルサーバー＋SQLiteに留める。
• 既存のGaleraクラスタを外部DBに使いたい：前述のとおりkineの前提と合わない。
• FIPSやSELinux MCSの要件がある：同じRancher系でもRKE2が対象としている領域。

K3sが起動しない・ノードが参加しないときの確認ポイント

最初に見るのはログとOS設定です。

# systemd のログ
sudo journalctl -u k3s -f          # サーバー
sudo journalctl -u k3s-agent -f    # エージェント

# カーネル設定・cgroup の不足を検査
sudo k3s check-config

• Raspberry Pi OSで起動しない：標準ではcgroupが無効。/boot/firmware/cmdline.txt の行末に cgroup_memory=1 cgroup_enable=memory を足して再起動する（Debian 11以前は /boot/cmdline.txt）。
• エージェントが参加しない：サーバーの6443番に届くか、トークンが node-token の値と一致するか、ホスト名が他ノードと重複していないかを確認する。
• Pod間通信だけが通らない：ノード間の8472/UDPがセキュリティグループやufwで止められていることが多い。
• RHEL 8.4より前でネットワークがおかしい：NetworkManagerの既知の不具合。nm-cloud-setup を無効化して再起動する。
• 80/443番が既存のnginx等とぶつかる：同梱のTraefikとServiceLBが80/443番を使うので、--disable=traefik で外すか既存サービスを移す。

Podのログは /var/log/pods、containerdのログは /var/lib/rancher/k3s/agent/containerd/containerd.log にあります。コンテナランタイムの仕組みはcontainerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説で解説しています。

K3sに関するよくある質問

K3sの読み方は何ですか？

公式の読み方は定められていません。READMEに「正式名称も公式の読み方も無い」と書かれています。アルファベットどおり「ケー・スリー・エス」と読めば誤解なく伝わります。

K3sは本番環境で使えますか？

使えます。公式はK3sを「本番運用可能で、CNCF認定のKubernetesディストリビューション」と位置づけています。本番ではSQLiteのシングルサーバーではなく、組み込みetcdの3台構成か外部DBでHAを組み、インストール時に版を固定してください。

K3sはMacやWindowsで動きますか？

直接は動きません。K3sはLinux専用です。MacやWindowsで試すなら、Docker上でK3sを動かすk3dを使うか、Linux VMを立ててその中にインストールします。

K3sとk3dの違いは何ですか？

k3dはK3sをDockerコンテナとして起動するための補助ツールで、中身のKubernetesは同じK3sです。手元で複数ノードを試すならk3d、実機やVMで動かすならK3sを直接入れます。

K3sとMicroK8sの違いは何ですか？

どちらも軽量なCNCF認定Kubernetesですが、K3sは単一バイナリをスクリプトで入れ、既定のデータストアがSQLiteです。MicroK8sはCanonicalがsnapで配布し、アドオンを有効化して機能を足します。snapを使わずに導入したい場合はK3sが候補になります。エアギャップ環境では、必要なイメージや依存パッケージを事前搬入できるかも比較してください。

関連記事

• Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説
• k8sをローカルで動かす手順｜kindでクラスタ構築からDeployment公開・撤収まで
• MetalLBとは？ベアメタルKubernetesでLoadBalancerを使う仕組みとL2・BGPの選び方
• Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順