Pushing configuration to a node after installation

Kairos configuration mechanism is based on the cloud-config file given during installation, however, it’s possible to extend the configuration by providing additional cloud-configs in either /oem or /usr/local/cloud-config.

By default, kairos reads in lexicographic order YAML cloud-config files in the directories above, indeed, after installation you should be able to see the configuration generated by the interactive-installer as /oem/99_custom.yaml in the system.

This mechanism can be used to set and enable persistent configuration on boot after node deployment.

We are going to see how to do that manually or with Kubernetes by using the

Manually

SSH into the node and copy the config file you want to add into /oem. For instance, to add zram on boot we can copy the following file in /oem/100_zram.yaml or /usr/local/cloud-config/100_zram.yaml and reboot:

stages:
  boot:
    - name: "zram setup"
      commands:
        - modprobe zram
        - echo lzo > /sys/block/zram0/comp_algorithm
        - echo 1G > /sys/block/zram0/disksize
        - mkswap --label zram0 /dev/zram0
        - swapon --priority 100 /dev/zram0
name: "zfs setup"

With Kubernetes

To push configurations to a node, it is necessary system-upgrade-controller to be deployed in the target cluster which executes plan to the cluster nodes. In the example below, we use a plan to push a swapfile of 3gb enabled during boot, and restart the node afterward.

To install system-upgrade-controller, use kubectl:

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.9.1/system-upgrade-controller.yaml

Note

Several roll-out strategies can be used with system-upgrade-controller which are not illustrated here in this example. For instance, it can be specified in the number of hosts which are running the upgrades, filtering by labels, and more. Refer to the project documentation on how to create efficient strategies to roll plans on the nodes. In the example above, the plans are applied to every host of the cluster, one-by-one in sequence.

The following pushes a new cloud config over the /oem directory and reboots the node:

cat <<'EOF' | kubectl apply -f -
---
apiVersion: v1
kind: Secret
metadata:
  name: custom-script
  namespace: system-upgrade
type: Opaque
stringData:
  swapfile.yaml: |
   stages:
    boot:
      - name: "Setup swapfile"
        if: "[ ! -e /usr/local/swapfile ]"
        commands:
        - dd if=/dev/zero of=/usr/local/swapfile bs=1M count=3K
        - mkswap /usr/local/swapfile
      - name: "Enable swapfile"
        if: "[ -e /usr/local/swapfile ]"
        commands:
        - swapon /usr/local/swapfile
  add-oem-file.sh: |
    #!/bin/sh
    set -e
    if diff /host/run/system-upgrade/secrets/custom-script/swapfile.yaml /host/oem/10_swapfile.yaml >/dev/null; then
        echo Swapfile present
        exit 0
    fi
    # Note: this is a symlink. We can also cp -L, but be aware that standard cp doesn't work.
    cat /host/run/system-upgrade/secrets/custom-script/swapfile.yaml > /host/oem/10_swapfile.yaml
    sync

    mount --rbind /host/dev /dev
    mount --rbind /host/run /run
    nsenter -i -m -t 1 -- reboot
    exit 1
---
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: add-swapfile
  namespace: system-upgrade
spec:
  concurrency: 1
  # This is the version (tag) of the image.
  version: "leap-15.5-standard-amd64-generic-v3.0.10-k3sv1.29.3-k3s1"
  nodeSelector:
    matchExpressions:
      - { key: kubernetes.io/hostname, operator: Exists }
  serviceAccountName: system-upgrade
  cordon: false
  upgrade:
    # Here goes the image which is tied to the flavor being used.
    # Currently can pick between opensuse and alpine
    image: quay.io/kairos/opensuse
    command:
      - "/bin/bash"
      - "-c"
    args:
      - bash /host/run/system-upgrade/secrets/custom-script/add-oem-file.sh
  secrets:
    - name: custom-script
      path: /host/run/system-upgrade/secrets/custom-script
EOF

Feedback

Was this page helpful?

Awesome! Glad to hear it! Please tell us how we can improve.

Oh snap! Sorry to hear that. Please tell us how we can improve.

Last modified February 23, 2024: Reduce sizes and remove warnings (0e183ae)