RKE2
RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution.
It is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
To meet these goals, RKE2 does the following:
For more information and detailed installation and operation instructions, please visit our docs.
Quick Start
Here's the extremely quick start:
curl -sfL https://get.rke2.io | sh -
systemctl enable rke2-server.service
systemctl start rke2-server.service
# Wait a bit
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin
kubectl get nodes
For a bit more, check out our full quick start guide.
Installation
A full breakdown of installation methods and information can be found here.
Configuration File
The primary way to configure RKE2 is through its config file. Command line arguments and environment variables are also available, but RKE2 is installed as a systemd service and thus these are not as easy to leverage.
By default, RKE2 will launch with the values present in the YAML file located at /etc/rancher/rke2/config.yaml.
An example of a basic server config file is below:
# /etc/rancher/rke2/config.yaml
write-kubeconfig-mode: "0644"
tls-san:
- "foo.local"
node-label:
- "foo=bar"
- "something=amazing"
In general, cli arguments map to their respective yaml key, with repeatable cli args being represented as yaml lists. So, an identical configuration using solely cli arguments is shown below to demonstrate this:
rke2 server \
--write-kubeconfig-mode "0644" \
--tls-san "foo.local" \
--node-label "foo=bar" \
--node-label "something=amazing"
It is also possible to use both a configuration file and cli arguments. In these situations, values will be loaded from both sources, but cli arguments will take precedence. For repeatable arguments such as --node-label, the cli arguments will overwrite all values in the list.
Finally, the location of the config file can be changed either through the cli argument --config FILE, -c FILE, or the environment variable $RKE2_CONFIG_FILE.
Release cadence
RKE2 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 RKE2 release v1.36.1+rke2r1 maps to the v1.36.1 Kubernetes release. We add a postfix in the form of +rke2r 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 in v1.36.1+rke2r1 and needed to release an immediate fix for it, we would release v1.36.1+rke2r2.
FAQ
Security
Please do not open security issues here. Instead, refer to our Security Policy to learn how to report any vulnerabilities.
