When setting up your
cluster.yml for RKE, there are a lot of different options that can be configured to control the behavior of how RKE launches Kubernetes.
There are several options that can be configured in cluster configuration option. There are several example yamls that contain all the options.
- Ignoring unsupported Docker versions
- Private Registries
- Cluster Level SSH Key Path
- SSH Agent
- Bastion Host
Configuring Kubernetes Cluster
- Cluster Name
- Kubernetes Version
- System Images
- Extra Args and Binds and Environment Variables
- External Etcd
- Cloud Providers
Cluster Level Options
By default, the name of your cluster will be
local. If you want a different name, you would use the
cluster_name directive to change the name of your cluster. The name will be set in your cluster’s generated kubeconfig file.
Supported Docker Versions
By default, RKE will check the installed Docker version on all hosts and fail with an error if the version is not supported by Kubernetes. The list of supported Docker versions are set specifically for each Kubernetes version. To override this behavior, set this option to
The default value is
By default, RKE is defaulted to launch with a specific Kubernetes version. You can also select a different version of Kubernetes to install for your cluster. Each version of RKE has a specific list of supported Kubernetes versions.
You can set the Kubernetes version as follows:
In case both
kubernetes_version and system images are defined, the system images configuration will take precedence over
Listing Supported Kubernetes Versions
Please refer to the release notes of the RKE version that you are running, to find the list of supported Kubernetes versions as well as the default Kubernetes version.
You can also list the supported versions and system images of specific version of RKE release with a quick command.
$ rke config --system-images --all INFO Generating images list for version [v1.13.4-rancher1-2]: ....... INFO Generating images list for version [v1.11.8-rancher1-1]: ....... INFO Generating images list for version [v1.12.6-rancher1-2]: .......
Using an unsupported Kubernetes version
As of v0.2.0, if a version is defined in
kubernetes_version and is not found in the specific list of supported Kubernetes versions, then RKE will error out.
Prior to v0.2.0, if a version is defined in
kubernetes_version and is not found in the specific list of supported Kubernetes versions, the default version from the supported list is used.
If you want to use a different version from the supported list, please use the system images option.
Cluster Level SSH Key Path
RKE connects to host(s) using
ssh. Typically, each node will have an independent path for each ssh key, i.e.
ssh_key_path, in the
nodes section, but if you have a SSH key that is able to access all hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the nodes.
If ssh key paths are defined at the cluster level and at the node level, the node-level key will take precedence.
RKE supports using ssh connection configuration from a local ssh agent. The default value for this option is
false. If you want to set using a local ssh agent, you would set this to
If you want to use an SSH private key with a passphrase, you will need to add your key to
ssh-agent and have the environment variable
$ eval "$(ssh-agent -s)" Agent pid 3975 $ ssh-add /home/user/.ssh/id_rsa Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) $ echo $SSH_AUTH_SOCK /tmp/ssh-118TMqxrXsEx/agent.3974
Add-ons Job Timeout
You can define add-ons to be deployed after the Kubernetes cluster comes up, which uses Kubernetes jobs. RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is