You are viewing documentation for the Kairos release v3.2.4. For the latest release, click here.
Configuration
Welcome to the Kairos configuration reference page. This page provides details on the fields available in the YAML file used for installing Kairos, a Linux distribution focused on running Kubernetes. This file, written in cloud-config format, allows you to enable Kairos features, configure k3s, and set various other options.
The structure of the configuration file is as follows:
The p2p
block is used to enable the p2p full-mesh functionalities of Kairos. If you do not want to use these functionalities, simply don’t specify a kairos block in your configuration file.
Inside the p2p
block, you can specify the network_token field, which is used to establish the p2p full meshed network. If you do not want to use the full-mesh functionalities, don’t specify a network_token value.
The role field allows you to manually set the node role for your Kairos installation. The available options are master
and worker
, and the default value is auto (which means no role is set).
The network_id
field allows you to set a user-defined network ID, which can be used to have multiple Kairos clusters on the same network.
Finally, the dns
field allows you to enable embedded DNS for Kairos. For more information on DNS in Kairos, see the link provided in the YAML code above.
That’s a brief overview of the structure and fields available in the Kairos configuration file. For more detailed information on how to use these fields, see the examples and explanations provided in the sections below.
Syntax
Kairos supports a portion of the standard cloud-init syntax, and the extended syntax which is based on yip.
Examples using the extended notation for running K3s as agent or server can be found in the examples directory of the Kairos repository.
Here’s an example that shows how to set up DNS at the boot stage using the extended syntax:
Note
Kairos does not use cloud-init. yip was created with the goal of being distro agnostic, and does not use Bash at all (with the exception of systemd configurations, which are assumed to be available). This makes it possible to run yip on minimal Linux distros that have been built from scratch.
The rationale behind using yip instead of cloud-init is that it allows Kairos to have very minimal requirements. The cloud-init implementation has dependencies, while yip does not, which keeps the dependency tree small. There is also a CoreOS implementation of cloud-init, but it makes assumptions about the layout of the system that are not always applicable to Kairos, making it less portable.
The extended syntax can also be used to pass commands through Kernel boot parameters. See the examples below for more details.
Test your cloud configs
Writing YAML files can be a tedious process, and it’s easy to make syntax or indentation errors. To make sure your configuration is correct, you can use the cloud-init commands to test your YAML files locally in a container.
Here’s an example of how to test your configurations on the initramfs
stage using a Docker container:
Validate Your Cloud Config
Note
Validation of configuration is available on Kairos v1.6.0-rc1 and later. If you’re interested in the validation rules or want to build a tool based on it, you can access them online viahttps://kairos.io/RELEASE/cloud-config.json
e.g. v1.6.0 cloud-config.json
You have two options to validate your Cloud Config, one is with the Kairos command line, and the other with the Web UI.
Configuration Validation via the Kairos Command Line
To validate a configuration using the command line, we have introduced the validate
command. As an argument you need to pass a URL or local file to be validated, e.g.:
If you had the following cloud-config.yaml
in the current working directory
You could validate it as follows
Configuration Validation via Web UI
The validation in the Web UI is automatic, all you need to do is copy/paste or type your configuration on the input.
Using templates
Fields in the Kairos cloud-init configuration can be templated, which allows for dynamic configuration. Node information is retrieved using the sysinfo library, and can be templated in the commands
, file
, and entity
fields.
Here’s an example of how you can use templating in your Kairos configuration:
In addition to standard templating, sprig functions are also available for use in your Kairos configuration.
Automatic Hostname at scale
You can also use templating to automatically generate hostnames for a set of machines. For example, if you have a single cloud-init
file that you want to use for multiple machines, you can use the machine ID (which is generated for each host) to automatically set the hostname for each machine.
Here’s an example of how you can do this:
This will set the hostname for each machine based on the first 4 characters of the machine ID. For example, if the machine ID for a particular machine is abcdef123456
, the hostname for that machine will be set to node-abcd
.
K3s settings
The k3s
and k3s-agent
blocks in the Kairos configuration file allow you to customize the environment and argument settings for K3s.
Here’s an example of how to use these blocks in your Kairos configuration:
Warning
The K3s args are only applied when the K3s service is created, which is during installation. Changing theargs
key after installation won’t have any effect.
For more examples of how to configure K3s manually, see the examples section or HA.
Grub options
The install.grub_options
field in the Kairos configuration file allows you to set key/value pairs for GRUB options that will be set in the GRUB environment after installation.
Here’s an example of how you can use this field to set the panic=0
boot argument:
The table below lists all the available options for the install.grub_options
field:
Variable | Description |
---|---|
next_entry | Set the next reboot entry |
saved_entry | Set the default boot entry |
default_menu_entry | Set the name entries on the GRUB menu |
extra_active_cmdline | Set additional boot commands when booting into active |
extra_passive_cmdline | Set additional boot commands when booting into passive |
extra_recovery_cmdline | Set additional boot commands when booting into recovery |
extra_cmdline | Set additional boot commands for all entries |
default_fallback | Sets default fallback logic |
Kubernetes manifests
The k3s
distribution of Kubernetes allows you to automatically deploy Helm charts or Kubernetes resources after deployment.
Here’s an example of how you can use the k3s
configuration file to deploy Fleet out of the box:
This configuration will automatically deploy the Fleet Helm chart in the cattle-system namespace after the deployment of k3s
using the extended syntax.
Kernel boot parameters
All the configurations can be issued via Kernel boot parameters, for instance, consider to add an user from the boot menu:
stages.boot[0].authorized_keys.root[0]=github:mudler
Or to either load a config url from network:
config_url=http://...
Usually secret gists are used to share such config files.
Additional users
Kairos comes with the kairos
user pre-configured, however, it is possible to configure additional users to the system via the cloud-init config mechanism
Add a user during first-install
Consider the following example cloud-config, containing the default kairos
user (which always has sudo access) and adds the testuser
user to the system with admin access:
Add a user to an existing install
To add an user to an existing installation you can simply add a /oem
file for the new user. For instance, consider the following:
This configuration can be either manually copied over, or can be propagated also via Kubernetes using the system upgrade controller. See the after-install section for an example.
P2P configuration
P2P functionalities are experimental Kairos features and disabled by default. In order to enable them, just use the p2p
configuration block.
p2p.network_token
This defines the network token used by peers to join the p2p virtual private network. You can generate it with the Kairos CLI with kairos generate-token
. Check out the P2P section for more instructions.
p2p.role
Define a role for the node. Accepted: worker
, master
. Currently only one master is supported.
p2p.network_id
Define a custom ID for the Kubernetes cluster. This can be used to create multiple clusters in the same network segment by specifying the same id across nodes with the same network token. Accepted: any string.
p2p.dns
When the p2p.dns
is set to true
the embedded DNS is configured on the node. This allows to propagate custom records to the nodes by using the blockchain DNS server. For example, this is assuming kairosctl bridge
is running in a separate terminal:
It will add the foo.bar
domain with 2.2.2.2
as A
response.
Every node with DNS enabled will be able to resolve the domain after the domain is correctly announced.
You can check out the DNS in the DNS page in the API, see also the EdgeVPN docs.
Furthermore, it is possible to tweak the DNS server which are used to forward requests for domain listed outside, and as well, it’s possible to lock down resolving only to nodes in the blockchain, by customizing the configuration file:
Stages
The stages
key is a map that allows to execute blocks of cloud-init directives during the lifecycle of the node stages.
A full example of a stage is the following:
Note multiple stages can be specified, to execute blocks into different stages, consider:
Below you can find a list of all the supported fields. Mind to replace with the appropriate stage you want to hook into.
Filtering stages by node hostname
Stages can be filtered using the node
key with a hostname value:
Filtering stages with if statement
Stages can be skipped based on if statements:
The expression inside the if
will be evaluated in bash and, if specified, the stage gets executed only if the condition returns successfully (exit 0).
name
A description of the stage step. Used only when printing output to console.
node
If defined, the node hostname where this stage has to run, otherwise it skips the execution. The node can also be a regexp in the Golang format.
Modules
For each stage, a number of modules are available, that implement various useful functions. Read more about them in this page: Stage modules
Running commands on different shells
By default, all commands are executed in the sh
shell. However, it is possible to run commands in a different shell by prefixing the command with the executable.
For example, to run a command in the bash
shell, you can use the following syntax: