この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

要件

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

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

前提条件

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

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

アーキテクチャ

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

  • x86_64

  • armhf

  • arm64/aarch64

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

Firewalld

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

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

Red Hat Enterprise Linux / CentOS / Fedora

RHEL 10

RHEL 10では、追加のパッケージが必要です：

sudo dnf install -y kernel-modules-extra

Firewalld

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

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

古いRHEL/CentOSリリース

RHEL 8.4以前のOSバージョンには、K3sのネットワーキングに干渉する既知のバグを持つNetworkManagerが含まれています。古いリリースを使用している場合は、nm-cloud-setupを無効にし、ノードを再起動する必要があります：

systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot
Ubuntu / Debian

UFW

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

ufw（簡易ファイアウォール）をオフにすることをお勧めします：

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

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

Raspberry Pi

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

Cgroups

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

Debian 11および古いPi OSリリースでは、cmdline.txtは`/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モジュール

Ubuntu 21.10 から Ubuntu 23.10 まで、Raspberry Pi の vxlan サポートは別のカーネルモジュールに移動されました。このステップは Ubuntu 24.04 以降では必要ありません。

sudo apt install linux-modules-extra-raspi

Rancher 管理の K3s クラスターでテストされた OS についての詳細は、https://rancher.com/support-maintenance-terms/[Rancher サポートおよびメンテナンス条件]を参照してください。

Hardware (ハードウェア)

ハードウェア要件は、デプロイメントの規模に基づいてスケールします。最小要件は次のとおりです：

ノード CPU RAM

サーバ

2コア

2GB

エージェント

1コア

512MB

リソースプロファイリングは、K3s エージェント、ワークロードを持つ K3s サーバー、および 1 つのエージェントを持つ K3s サーバーの最小リソース要件を決定するためのテストと分析の結果をキャプチャします。

ディスク

K3s のパフォーマンスはデータベースのパフォーマンスに依存します。最適な速度を確保するために、可能な限り SSD の使用をお勧めします。

Raspberry Pi や他の ARM デバイスに K3s をデプロイする場合は、外部 SSD の使用をお勧めします。etcd は書き込み集約型であり、SD カードや eMMC は IO 負荷に耐えられません。

サーバーサイズガイド

サーバー（コントロールプレーン + etcd）ノードの CPU と RAM が制限されている場合、標準のワークロード条件下で参加できるエージェントノードの数に制限があります。

サーバー CPU サーバのRAM エージェントの数

2

4GB

0-350

4

8GB

351-900

8

16GB

901-1800

16+

32GB

1800+
高可用性サイズ

3つのサーバーノードの高可用性セットアップを使用する場合、エージェントの数は上記の表よりも約50%増加する可能性があります。例えば、4つのvCPU/8GBを持つ3つのサーバーは1200エージェントにスケールできます。

CPUがスペースを解放できるように、エージェントノードは50以下のバッチで参加することをお勧めします。ノード参加時にスパイクが発生します。255ノード以上を希望する場合は、デフォルトの`cluster-cidr`を変更することを忘れないでください！

リソースプロファイリングには、これらの推奨事項がどのように見つかったかに関する詳細情報が含まれています。

ネットワーキング

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ネットワークを作成するためにhttps://www.cni.dev/plugins/current/main/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

すべてのノード

すべてのノード

IPv4を使用したFlannel Wireguardにのみ必要

UDP

51821

すべてのノード

すべてのノード

IPv6を使用したFlannel Wireguardにのみ必要

TCP

5001

すべてのノード

すべてのノード

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

TCP

6443

すべてのノード

すべてのノード

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

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

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

大規模クラスター

ハードウェア要件は、K3sクラスターのサイズに基づいています。本番環境および大規模クラスターの場合、高可用性のセットアップと外部データベースの使用を推奨します。本番環境の外部データベースに推奨されるオプションは次のとおりです：

  • MySQL

  • PostgreSQL

  • etcd

CPUとメモリ

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

デプロイメントサイズ ノード vCPUs RAM

小規模

最大10

2

4GB

中

最大100

4

8GB

大規模

最大250

8

16GB

エクストララージ

最大500

16

32GB

ダブルエクストララージ

500+

32

64GB

ディスク

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

ネットワーク

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

データベース

K3sはMySQL、PostgreSQL、MariaDB、etcdなどの異なるデータベースをサポートしています。 詳細については、クラスターデータストアをご覧ください。

以下は、大規模クラスターを運用するために必要なデータベースリソースのサイズガイドです。

デプロイメントサイズ ノード vCPUs RAM

小規模

最大10

1

2GB

中

最大100

2

8GB

大規模

最大250

4

16GB

エクストララージ

最大500

8

32GB

ダブルエクストララージ

500+

16

64GB