config: add default imports to containerd base templates
Add imports to the generated containerd config so containerd loads drop-in TOML files: config.toml.d for v2, config-v3.toml.d for v3 (e.g. /var/lib/rancher/k3s/agent/etc/containerd/config.toml.d and /var/lib/rancher/k3s/agent/etc/containerd/config-v3.toml.d).
Also fix the v3 header comment to say config-v3.toml.tmpl instead of config.toml.tmpl.
Signed-off-by: Fabiano Fidêncio ffidencio@nvidia.com
K3s - Lightweight Kubernetes
Lightweight Kubernetes. Production ready, easy to install, half the memory, all in a binary less than 100 MB.
Great for:
What is this?
K3s is a fully conformant production-ready Kubernetes distribution with the following changes:
K3s bundles the following technologies together into a single cohesive distribution:
These technologies can be disabled or swapped out for technologies of your choice.
Additionally, K3s simplifies Kubernetes operations by maintaining functionality for:
What’s with the name?
We wanted an installation of Kubernetes that was half the size in terms of memory footprint. Kubernetes is a 10 letter word stylized as k8s. So something half as big as Kubernetes would be a 5 letter word stylized as K3s. A ‘3’ is also an ‘8’ cut in half vertically. There is neither a long-form of K3s nor official pronunciation.
Is this a fork?
No, it’s a distribution. A fork implies continued divergence from the original. This is not K3s’s goal or practice. K3s explicitly intends not to change any core Kubernetes functionality. We seek to remain as close to upstream Kubernetes as possible. However, we maintain a small set of patches (well under 1000 lines) important to K3s’s use case and deployment model. We maintain patches for other components as well. When possible, we contribute these changes back to the upstream projects, for example, with SELinux support in containerd. This is a common practice amongst software distributions.
K3s is a distribution because it packages additional components and services necessary for a fully functional cluster that go beyond vanilla Kubernetes. These are opinionated choices on technologies for components like ingress, storage class, network policy, service load balancer, and even container runtime. These choices and technologies are touched on in more detail in the What is this? section.
How is this lightweight or smaller than upstream Kubernetes?
There are two major ways that K3s is lighter weight than upstream Kubernetes:
The memory footprint is reduced primarily by running many components inside of a single process. This eliminates significant overhead that would otherwise be duplicated for each component.
The binary is smaller by removing third-party storage drivers and cloud providers, explained in more detail below.
What have you removed from upstream Kubernetes?
This is a common point of confusion because it has changed over time. Early versions of K3s had much more removed than the current version. K3s currently removes two things:
Both of these have out-of-tree alternatives in the form of CSI and CCM, which work in K3s and which upstream is moving towards.
We remove these to achieve a smaller binary size. They can be removed while remaining conformant because neither affects core Kubernetes functionality. They are also dependent on third-party cloud or data center technologies/services, which may not be available in many K3s’ use cases.
Getting Started
Community
Slack
Join Slack to chat with K3s developers and other K3s users. Great place to learn and ask questions: #k3s and #k3s-contributor and #k3s channel in CNCF Slack
Getting involved
GitHub Issues - Submit your issues and feature requests via GitHub.
Community Meetings and Office hours
The K3s developer community hangs out on Zoom to chat. Everybody is welcome.
Add the Linux Foundation iCal to your calendar:
Meeting notes and agenda: https://hackmd.io/@k3s/meet-notes/
Meeting recordings: K3s Channel
You can check also the full details on the website: https://k3s.io/community
What’s next?
Check out our roadmap to see what we have planned moving forward.
Release cadence
K3s maintains pace with upstream Kubernetes releases. Our goal is to release patch releases within one week, and new minors within 30 days.
Our release versioning reflects the version of upstream Kubernetes that is being released. For example, the K3s release v1.27.4+k3s1 maps to the
v1.27.4Kubernetes release. We add a postfix in the form of+k3s<number>to allow us to make additional releases using the same version of upstream Kubernetes while remaining semver compliant. For example, if we discovered a high severity bug inv1.27.4+k3s1and needed to release an immediate fix for it, we would releasev1.27.4+k3s2.Documentation
Please see the official docs site for complete documentation.
Quick-Start - Install Script
The
install.shscript provides a convenient way to download K3s and add a service to systemd or openrc.To install k3s as a service, run:
A kubeconfig file is written to
/etc/rancher/k3s/k3s.yamland the service is automatically started or restarted. The install script will install K3s and additional utilities, such askubectl,crictl,k3s-killall.sh, andk3s-uninstall.sh, for example:K3S_TOKENis created at/var/lib/rancher/k3s/server/node-tokenon your server. To install on worker nodes, passK3S_URLalong withK3S_TOKENenvironment variables, for example:Manual Download
k3sfrom latest release, x86_64, armhf, arm64 and s390x are supported.Contributing
Please check out our contributing guide if you’re interested in contributing to K3s.
Security
Security issues in K3s can be reported by sending an email to security@k3s.io. Please do not file issues about security issues.