跳到主要内容

系统需求

K3s 尽管非常轻量级，但仍如下所示有一些最低要求：

无论你是在容器中，还是作为原生 Linux 系统服务而配置使用 K3s，每个节点都应满足以下最低条件。这些条件是 K3s 自身及其组件包的（性能）基线，不含工作负载自身消耗的系统资源。

前提​

同一主机名不可为多个节点使用。

If multiple nodes will have the same hostname, or if hostnames may be reused by an automated provisioning system, use the --with-node-id option to append a random suffix for each node, or devise a unique name to pass with --node-name or $K3S_NODE_NAME for each node you add to the cluster.

系统架构​

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 系统的内核必须使用 4 KB 分页大小。RHEL9、Ubuntu、Raspberry PI OS 和 SLES 等均满足此要求。

操作系统​

K3s 应运行于最新 Linux 系统中。

部分操作系统有额外的安装条件：

It is recommended to turn off firewalld:

systemctl disable firewalld --now

If you wish to keep firewalld enabled, by default, the following rules are required:

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

Additional ports may need to be opened depending on your setup. See Inbound Rules for more information. If you change the default CIDR for pods or services, you will need to update the firewall rules accordingly.

If enabled, it is required to disable nm-cloud-setup and reboot the node:

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

For more information on which OSs were tested with Rancher managed K3s clusters, refer to the Rancher support and maintenance terms.

Hardware​

Hardware requirements scale based on the size of your deployments. Minimum recommendations are outlined here.

SpecMinimumRecommended
CPU1 core2 cores
RAM512 MB1 GB

Resource Profiling captures the results of tests to determine minimum resource requirements for the K3s agent, the K3s server with a workload, and the K3s server with one agent. It also contains analysis about what has the biggest impact on K3s server and agent utilization, and how the cluster datastore can be protected from interference from agents and workloads.

Raspberry Pi and embedded etcd

If deploying K3s with embedded etcd on a Raspberry Pi, it is recommended that you use an external SSD. etcd is write intensive, and SD cards cannot handle the IO load.

Disks​

K3s performance depends on the performance of the database. To ensure optimal speed, we recommend using an SSD when possible. Disk performance will vary on ARM devices utilizing an SD card or eMMC.

Networking​

The K3s server needs port 6443 to be accessible by all nodes.

The nodes need to be able to reach other nodes over UDP port 8472 when using the Flannel VXLAN backend, or over UDP port 51820 (and 51821 if IPv6 is used) when using the Flannel WireGuard backend. The node should not listen on any other port. K3s uses reverse tunneling such that the nodes make outbound connections to the server and all kubelet traffic runs through that tunnel. However, if you do not use Flannel and provide your own custom CNI, then the ports needed by Flannel are not needed by K3s.

If you wish to utilize the metrics server, all nodes must be accessible to each other on port 10250.

If you plan on achieving high availability with embedded etcd, server nodes must be accessible to each other on ports 2379 and 2380.

Important

The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.

危险

Flannel relies on the Bridge CNI plugin to create a L2 network that switches traffic. Rogue pods with NET_RAW capabilities can abuse that L2 network to launch attacks such as ARP spoofing. Therefore, as documented in the Kubernetes docs, please set a restricted profile that disables NET_RAW on non-trustable pods.

Inbound Rules for K3s Nodes​

ProtocolPortSourceDestinationDescription
TCP2379-2380ServersServersRequired only for HA with embedded etcd
TCP6443AgentsServersK3s supervisor and Kubernetes API Server
UDP8472All nodesAll nodesRequired only for Flannel VXLAN
TCP10250All nodesAll nodesKubelet metrics
UDP51820All nodesAll nodesRequired only for Flannel Wireguard with IPv4
UDP51821All nodesAll nodesRequired only for Flannel Wireguard with IPv6
TCP5001All nodesAll nodesRequired only for embedded distributed registry (Spegel)
TCP6443All nodesAll nodesRequired only for embedded distributed registry (Spegel)

Typically, all outbound traffic is allowed.

Additional changes to the firewall may be required depending on the OS used.

Large Clusters​

Hardware requirements are based on the size of your K3s cluster. For production and large clusters, we recommend using a high-availability setup with an external database. The following options are recommended for the external database in production:

  • MySQL
  • PostgreSQL
  • etcd

CPU and Memory​

The following are the minimum CPU and memory requirements for nodes in a high-availability K3s server:

Deployment SizeNodesVCPUSRAM
SmallUp to 1024 GB
MediumUp to 10048 GB
LargeUp to 250816 GB
X-LargeUp to 5001632 GB
XX-Large500+3264 GB

Disks​

The cluster performance depends on database performance. To ensure optimal speed, we recommend always using SSD disks to back your K3s cluster. On cloud providers, you will also want to use the minimum size that allows the maximum IOPS.

Network​

You should consider increasing the subnet size for the cluster CIDR so that you don't run out of IPs for the pods. You can do that by passing the --cluster-cidr option to K3s server upon starting.

Database​

K3s supports different databases including MySQL, PostgreSQL, MariaDB, and etcd. See Cluster Datastore for more info.

The following is a sizing guide for the database resources you need to run large clusters:

Deployment SizeNodesVCPUSRAM
SmallUp to 1012 GB
MediumUp to 10028 GB
LargeUp to 250416 GB
X-LargeUp to 500832 GB
XX-Large500+1664 GB