メインコンテンツまでスキップ

要件

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には追加のセットアップ要件があります:

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を変更する場合は、ファイアウォールルールを更新する必要があります。

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

ハードウェア​

ハードウェア要件はデプロイメントの規模に応じてスケールします。ここでは最低限の推奨事項を示します。

スペック最低限推奨
CPU1コア2コア
RAM512 MB1 GB

リソースプロファイリングでは、K3sエージェント、ワークロードを持つK3sサーバー、および1つのエージェントを持つK3sサーバーの最小リソース要件を決定するためのテスト結果をキャプチャしています。また、K3sサーバーとエージェントの利用に最も大きな影響を与える要因についての分析や、エージェントやワークロードからクラスターのデータストアを保護する方法についても含まれています。

Raspberry Piと組み込みetcd

Raspberry Piで組み込みetcdを使用してK3sをデプロイする場合、外部SSDを使用することをお勧めします。etcdは書き込みが多く、SDカードはIO負荷に耐えられません。

ディスク​

K3sのパフォーマンスはデータベースのパフォーマンスに依存します。最適な速度を確保するために、可能であればSSDを使用することをお勧めします。ARMデバイスでSDカードやeMMCを使用する場合、ディスクのパフォーマンスは異なります。

ネットワーキング​

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スプーフィングなどの攻撃を開始する可能性があります。したがって、Kubernetesドキュメントに記載されているように、信頼できないポッドでNET_RAWを無効にする制限付きプロファイルを設定してください。

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

プロトコルポートソース宛先説明
TCP2379-2380サーバーサーバー組み込みetcdを使用したHAの場合のみ必要
TCP6443エージェントサーバーK3sスーパーバイザーおよびKubernetes APIサーバー
UDP8472すべてのノードすべてのノードFlannel VXLANの場合のみ必要
TCP10250すべてのノードすべてのノードKubeletメトリクス
UDP51820すべてのノードすべてのノードFlannel WireguardをIPv4で使用する場合のみ必要
UDP51821すべてのノードすべてのノードFlannel WireguardをIPv6で使用する場合のみ必要
TCP5001すべてのノードすべてのノード組み込み分散レジストリ（Spegel）の場合のみ必要
TCP6443すべてのノードすべてのノード組み込み分散レジストリ（Spegel）の場合のみ必要

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

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

大規模クラスター​

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

  • MySQL
  • PostgreSQL
  • etcd

CPUとメモリ​

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

デプロイメント規模ノード数VCPUSRAM
小規模最大1024 GB
中規模最大10048 GB
大規模最大250816 GB
超大規模最大5001632 GB
超超大規模500+3264 GB

ディスク​

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

ネットワーク​

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

データベース​

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

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

デプロイメント規模ノード数VCPUSRAM
小規模最大1012 GB
中規模最大10028 GB
大規模最大250416 GB
超大規模最大500832 GB
超超大規模500+1664 GB