要件

K3sは非常に軽量ですが、以下に示す最低要件があります。

K3sをコンテナ内で実行する場合でも、ネイティブのLinuxサービスとして実行する場合でも、K3sを実行する各ノードは以下の最低要件を満たす必要があります。これらの要件はK3sおよびそのパッケージ化されたコンポーネントのためのベースラインであり、ワークロード自体によって消費されるリソースは含まれていません。

前提条件

2つのノードは同じホスト名を持つことはできません。

複数のノードが同じホスト名を持つ場合、またはホスト名が自動プロビジョニングシステムによって再利用される可能性がある場合は、--with-node-idオプションを使用して各ノードにランダムなサフィックスを追加するか、--node-nameまたは$K3S_NODE_NAMEで一意の名前を渡してクラスターに追加する各ノードに指定してください。

アーキテクチャ

K3sは以下のアーキテクチャで利用可能です:

  • x86_64

  • armhf

  • arm64/aarch64

  • s390x

ARM64 ページサイズ

2023年5月以前のリリース（v1.24.14+k3s1、v1.25.10+k3s1、v1.26.5+k3s1、v1.27.2+k3s1）では、aarch64/arm64システムでカーネルが4kページを使用する必要があります。RHEL9、Ubuntu、Raspberry PI OS、およびSLESはすべてこの要件を満たしています。

オペレーティングシステム

K3sはほとんどの最新のLinuxシステムで動作することが期待されています。

一部のOSには追加のセットアップ要件があります:

  • SUSE Linux Enterprise / openSUSE

  • Red Hat Enterprise Linux / CentOS / Fedora

  • Ubuntu / Debian

  • Raspberry Pi

firewalldをオフにすることをお勧めします:

systemctl disable firewalld --now

firewalldを有効にしたままにしたい場合、デフォルトで以下のルールが必要です:

firewall-cmd --permanent --add-port=6443/tcp #apiserver
firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 #pods
firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 #services
firewall-cmd --reload

セットアップに応じて追加のポートを開く必要がある場合があります。詳細についてはインバウンドルールを参照してください。ポッドやサービスのデフォルトCIDRを変更する場合は、ファイアウォールルールを更新する必要があります。

firewalldをオフにすることをお勧めします:

systemctl disable firewalld --now

firewalldを有効にしたままにしたい場合、デフォルトで以下のルールが必要です:

firewall-cmd --permanent --add-port=6443/tcp #apiserver
firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 #pods
firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 #services
firewall-cmd --reload

セットアップに応じて追加のポートを開く必要がある場合があります。詳細についてはインバウンドルールを参照してください。ポッドやサービスのデフォルトCIDRを変更する場合は、ファイアウォールルールを更新する必要があります。

有効になっている場合は、nm-cloud-setupを無効にしてノードを再起動する必要があります:

systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot

古いDebianリリースには既知のiptablesバグがある可能性があります。詳細は既知の問題を参照してください。

ufw（uncomplicated firewall）をオフにすることをお勧めします:

ufw disable

ufwを有効にしたままにしたい場合、デフォルトで以下のルールが必要です:

ufw allow 6443/tcp #apiserver
ufw allow from 10.42.0.0/16 to any #pods
ufw allow from 10.43.0.0/16 to any #services

セットアップに応じて追加のポートを開く必要がある場合があります。詳細についてはインバウンドルールを参照してください。ポッドやサービスのデフォルトCIDRを変更する場合は、ファイアウォールルールを更新する必要があります。

Raspberry Pi OSはDebianベースであり、既知のiptablesバグがある可能性があります。詳細は既知の問題を参照してください。

Cgroups

標準のRaspberry Pi OSインストールでは、cgroupsが有効になっていません。K3Sはsystemdサービスを開始するためにcgroupsを必要とします。cgroupsは/boot/firmware/cmdline.txtにcgroup_memory=1 cgroup_enable=memoryを追加することで有効にできます。

On Debian 11 and older Pi OS releases the cmdline.txt is located at /boot/cmdline.txt.

例のcmdline.txt:

console=serial0,115200 console=tty1 root=PARTUUID=58b06195-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory

Ubuntu Vxlan Module

Ubuntu 21.10以降、Raspberry Piでのvxlanサポートは別のカーネルモジュールに移動されました。

sudo apt install linux-modules-extra-raspi

Rancher管理のK3sクラスターでテストされたOSの詳細については、Rancherのサポートとメンテナンスの条件を参照してください。

ハードウェア

Hardware requirements scale based on the size of your deployments. The minimum requirements are:

Node CPU RAM

Server

2 cores

2 GB

Agent

1 core

512 MB

Resource Profiling captures the results of tests and analysis to determine minimum resource requirements for the K3s agent, the K3s server with a workload, and the K3s server with one agent.

Disks

K3s performance depends on the performance of the database. To ensure optimal speed, we recommend using an SSD when possible.

If deploying K3s on a Raspberry Pi or other ARM devices, it is recommended that you use an external SSD. etcd is write intensive; SD cards and eMMC cannot handle the IO load.

Server Sizing Guide

When limited on CPU and RAM on the server (control-plane + etcd) node, there are limitations on the amount of agent nodes that can be joined under standard workload conditions.

Server CPU Server RAM Number of Agents

2

4 GB

0-350

4

8 GB

351-900

8

16 GB

901-1800

16+

32 GB

1800+
High Availability Sizing

When using a high-availability setup of 3 server nodes, the number of agents can scale roughly ~50% more than the above table. E.g., 3 server with 4 vCPU/8 GB can scale to ~1200 agents.

It is recommended to join agent nodes in batches of 50 or less to allow the CPU to free up space, as there is a spike on node join. Remember to modify the default cluster-cidr if desiring more than 255 nodes!

Resource Profiling contains more information how these recommendations were found.

ネットワーキング

K3sサーバーはポート6443がすべてのノードからアクセス可能である必要があります。

ノードは、Flannel VXLANバックエンドを使用する場合はUDPポート8472を介して、Flannel WireGuardバックエンドを使用する場合はUDPポート51820（IPv6を使用する場合は51821）を介して他のノードに到達できる必要があります。ノードは他のポートでリッスンしないようにする必要があります。K3sはリバーストンネリングを使用して、ノードがサーバーに対してアウトバウンド接続を行い、すべてのkubeletトラフィックがそのトンネルを通じて実行されるようにします。ただし、Flannelを使用せずに独自のカスタムCNIを提供する場合は、Flannelが必要とするポートはK3sには必要ありません。

メトリクスサーバーを利用する場合、すべてのノードがポート10250で相互にアクセス可能である必要があります。

組み込みetcdを使用して高可用性を実現する予定がある場合、サーバーノードはポート2379および2380で相互にアクセス可能である必要があります。

重要

ノードのVXLANポートは、クラスターネットワークが誰でもアクセスできるようになるため、外部に公開しないでください。ポート8472へのアクセスを無効にするファイアウォール/セキュリティグループの背後でノードを実行してください。

Flannelは、トラフィックをスイッチングするL2ネットワークを作成するためにBridge CNIプラグインに依存しています。NET_RAW機能を持つ不正なポッドは、そのL2ネットワークを悪用してARPスプーフィングなどの攻撃を開始する可能性があります。したがって、https://kubernetes.io/docs/concepts/security/pod-security-standards/[Kubernetesドキュメント]に記載されているように、信頼できないポッドでNET_RAWを無効にする制限付きプロファイルを設定してください。

K3sノードのインバウンドルール

プロトコル ポート ソース 宛先 説明

TCP

2379-2380

サーバー

サーバー

組み込みetcdを使用したHAの場合のみ必要

TCP

6443

エージェント

サーバー

K3sスーパーバイザーおよびKubernetes APIサーバー

UDP

8472

すべてのノード

すべてのノード

Flannel VXLANの場合のみ必要

TCP

10250

すべてのノード

すべてのノード

Kubeletメトリクス

UDP

51820

すべてのノード

すべてのノード

Flannel WireguardをIPv4で使用する場合のみ必要

UDP

51821

すべてのノード

すべてのノード

Flannel WireguardをIPv6で使用する場合のみ必要

TCP

5001

すべてのノード

すべてのノード

組み込み分散レジストリ（Spegel）の場合のみ必要

TCP

6443

すべてのノード

すべてのノード

組み込み分散レジストリ（Spegel）の場合のみ必要

通常、すべてのアウトバウンドトラフィックは許可されます。

使用するOSに応じて、ファイアウォールに追加の変更が必要な場合があります。

大規模クラスター

ハードウェア要件はK3sクラスターの規模に基づいています。プロダクションおよび大規模クラスターの場合、外部データベースを使用した高可用性セットアップをお勧めします。プロダクションでの外部データベースには以下のオプションが推奨されます:

  • MySQL

  • PostgreSQL

  • etcd

CPUとメモリ

高可用性K3sサーバーのノードに必要な最小CPUおよびメモリ要件は以下の通りです:

デプロイメント規模 ノード数 vCPUs RAM

小規模

最大10

2

4 GB

中規模

最大100

4

8 GB

大規模

最大250

8

16 GB

超大規模

最大500

16

32 GB

超超大規模

500+

32

64 GB

ディスク

クラスターのパフォーマンスはデータベースのパフォーマンスに依存します。最適な速度を確保するために、常にSSDディスクを使用してK3sクラスターをバックアップすることをお勧めします。クラウドプロバイダーでは、最大IOPSを許可する最小サイズを使用することもお勧めします。

ネットワーク

クラスターCIDRのサブネットサイズを増やして、ポッドのIPが不足しないようにすることを検討してください。K3sサーバーを起動する際に--cluster-cidrオプションを渡すことでそれを行うことができます。

データベース

K3sはMySQL、PostgreSQL、MariaDB、およびetcdなどのさまざまなデータベースをサポートしています。詳細についてはクラスターデータストアを参照してください。

大規模クラスターを実行するために必要なデータベースリソースのサイズガイドは以下の通りです:

デプロイメント規模 ノード数 vCPUs RAM

小規模

最大10

1

2 GB

中規模

最大100

2

8 GB

大規模

最大250

4

16 GB

超大規模

最大500

8

32 GB

超超大規模

500+

16

64 GB