OSCHINA-MIRROR/rancher-k3os

k3OS

k3OS — это дистрибутив Linux, предназначенный для максимального упрощения обслуживания ОС в кластере Kubernetes. Он специально разработан так, чтобы иметь только то, что необходимо для запуска k3s. Кроме того, ОС предназначена для управления с помощью kubectl после начальной загрузки кластера. Узлам нужно только присоединиться к кластеру, и тогда всеми аспектами ОС можно будет управлять из Kubernetes. Обновлениями k3OS и k3s управляет оператор k3OS.

Быстрый старт
Дизайн
Установка
Конфигурация
Обновление/обслуживание
Сборка
Справочник по конфигурации

Быстрый старт

Скачайте ISO-образ с последнего релиза (https://github.com/rancher/k3os/releases) и запустите его в VMware, VirtualBox, KVM или bhyve. Сервер автоматически запустит одноузловой кластер Kubernetes. Войдите под пользователем rancher и запустите kubectl. Это «живая установка», работающая с носителя ISO, изменения не сохранятся после перезагрузки.

Чтобы скопировать k3OS на локальный диск, после входа в систему как rancher запустите sudo k3os install. Затем удалите ISO из виртуальной машины и перезагрузите компьютер.

Для «живой установки» (загрузка с ISO) требуется минимум 2 ГБ ОЗУ. Для локальной установки требуется 1 ГБ ОЗУ.

Дизайн

Основные цели дизайна k3OS:

Минимум ОС для работы Kubernetes через k3s
Возможность обновления и настройки с помощью kubectl
Универсальная установка для простого создания образов ОС.

Структура файловой системы

Критически важным для дизайна k3OS является то, как структурирована файловая система. Загруженная система будет выглядеть следующим образом:

/etc - ephemeral
/usr - read-only (кроме /usr/local, который доступен для записи и сохраняется)
/k3os - системные файлы
/home - сохраняется
/var - сохраняется
/opt - сохраняется
/usr/local - сохраняется

/etc

Все настройки в системе предназначены для временного хранения. Если вы что-то измените в /etc, оно вернётся к исходному состоянию при следующей перезагрузке. Если вы хотите сохранить изменения в конфигурации, их следует внести в файл k3OS config.yaml, который будет применяться при каждой загрузке.

/usr

Всё пользовательское пространство хранится в /usr и доступно только для чтения. Единственный способ изменить /usr — обновить версию k3OS. Каталог /usr/local — это символическая ссылка на /var/local и поэтому доступен для записи.

/k3os

Каталог k3OS содержит основные файлы операционной системы, на которые ссылаются при загрузке для построения файловой системы. Он содержит образы squashfs и двоичные файлы для k3OS, k3s и ядра Linux. При загрузке будет выбрана и настроена подходящая версия для всех трёх.

/var, /usr/local, /home, /opt

Постоянные изменения следует хранить в /var, /usr/local, /home или /opt.

Исходные дистрибутивы

Большинство бинарных файлов пользовательского пространства взято из Alpine и переупаковано для k3OS. В настоящее время исходный код ядра взят из Ubuntu 20.04 LTS. Некоторый код и большая часть вдохновения пришли от LinuxKit.

Установка

Интерактивная установка

Интерактивная установка выполняется путём загрузки с ISO. Установка выполняется с помощью команды k3os install. Подкоманда k3os install доступна только в системах, загруженных вживую. Установка на диск не будет иметь k3os install. Следуйте инструкциям для установки k3OS на диск.

Установка отформатирует весь диск. Если у вас есть один жёсткий диск, подключённый к системе, он не спросит, какой диск форматировать, а просто выберет первый и единственный.

Автоматическая установка

Установку можно автоматизировать с помощью параметров командной строки ядра. Существует множество творческих решений для загрузки машины с параметрами cmdline. Вы можете переделать ISO k3OS, выполнить PXE-загрузку, использовать qemu/kvm или автоматизировать ввод с помощью упаковщика. Ядро и initrd доступны в артефактах выпуска k3OS вместе с ISO.

Параметры командной строки: Значение k3os.mode=install или k3os.fallback_mode=install необходимо для включения автоматических установок.

Ниже приведена таблица всех аргументов командной строки, используемых для автоматизации установки:

Аргумент командной строки	По умолчанию	Пример	Описание
k3os.mode		install	Загружает k3OS в режиме установщика, а не интерактивного сеанса
k3os.fallback_mode		install	Если не удаётся найти действительный раздел K3OS_STATE для загрузки, запускает установку
k3os.install.silent	false	true	Гарантирует отсутствие вопросов
k3os.install.force_efi	false	true	Запускает установку EFI, даже если EFI не обнаружена
k3os.install.device		/dev/vda	Устройство для разбиения на разделы и форматирования (/dev/sda, /dev/vda)
k3os.install.config_url		https://gist.github.com/.../dweomer.yaml	URL конфигурации, которая будет установлена в `/k3os/system/config.yaml`
k3os.install.iso_url		https://github.com/rancher/k3os/../k3os-amd64.iso	ISO для скачивания и установки, если загрузка происходит из kernel/vmlinuz, а не с ISO
k3os.install.no_format		true	Не разбивает на разделы и не форматирует, предполагает, что макет уже существует
k3os.install.tty	auto	ttyS0	Устройство tty, используемое для консоли
k3os.install.debug	false	true	Выполняет установку с большим количеством журналов и настраивает отладку для установленной системы
k3os.install.power_off	false	true	Выключает машину после установки вместо перезагрузки

Пользовательский макет разделов

По умолчанию k3OS ожидает наличие одного раздела с меткой K3OS_STATE. K3OS_STATE должен быть отформатирован как файловая система ext4 с объёмом не менее 2 ГБ. Программа установки автоматически создаст эти разделы и файловую систему, но вы можете создать их вручную, если вам нужен расширенный макет файловой системы.

Установка с загрузкой

Вы можете установить k3OS на блочное устройство с любого современного дистрибутива Linux. Просто скачайте и запустите install.sh. Этот скрипт выполнит ту же установку, что и ISO, но он более «сырой» и не запрашивает конфигурацию.

Использование: ./install.sh [--force-efi] [--debug] [--tty TTY] [--poweroff] [--takeover] [--no-format] [--config https://.../config.yaml] DEVICE ISO_URL

Пример: ./install.sh /dev/vda https://github.com/rancher/k3os/releases/download/v0.10.0/k3os.iso

DEVICE должно быть диском, который будет разбит на разделы (/dev/vda). Если вы используете --no-format, это должно быть устройство раздела K3OS_STATE (/dev/vda2)

Имена параметров относятся к тем же именам, которые используются в cmdline, обратитесь к README.md для получения дополнительной информации.

Пересоздание ISO

Чтобы пересоздать ISO, всё, что вам нужно сделать, — это скопировать /k3os и /boot из ISO в новую папку. Затем измените /boot/grub/grub.cfg, чтобы добавить любые аргументы командной строки ядра для автоматической установки. Чтобы создать новый ISO, просто используйте утилиту grub-mkrescue следующим образом:

# Ubuntu: apt install grub-efi grub-pc-bin mtools xorriso
# CentOS: dnf install grub2-efi grub2-pc mtools xorriso
# Alpine: apk add grub-bios grub-efi mtools xorriso
mount -o loop k3os.iso /mnt
mkdir -p iso/boot/grub
cp -rf /mnt/k3os iso/
cp /mnt/boot/grub/grub.cfg iso/boot/grub/

# Edit iso/boot/grub/grub.cfg

grub-mkrescue -o k3os-new.iso iso/ -- -volid K3OS

Caveat GRUB2: Некоторые установки grub2, отличные от Alpine, создадут ${ISO}/boot/grub2 вместо Установка с захватом

Существует особый режим установки, предназначенный для установки в текущую работающую систему Linux. Он работает только на ARM64 и x86_64. Скачайте install.sh и запустите с флагом --takeover. Это установит k3OS в текущий корень и заменит grub.cfg. После перезагрузки системы k3OS удалит все файлы на корневом разделе, которые не являются k3OS, а затем выключится. Этот режим особенно удобен при создании облачных образов. Таким образом, вы можете использовать существующий базовый образ, такой как Ubuntu, и установить поверх него k3OS, сделать снимок и создать новый образ.

Для того чтобы это работало, делается несколько предположений. Во-первых, предполагается, что корневой раздел (/) является ext4. Также предполагается, что установлен grub2 и он ищет конфигурацию в /boot/grub/grub.cfg. При запуске --takeover убедитесь, что вы также установили --no-format, а DEVICE должен быть установлен в раздел /. Обратитесь к шаблону AWS packer, чтобы увидеть этот режим в действии. Ниже приведён пример запуска установки с захватом.

./install.sh --takeover --debug --tty ttyS0 --config /tmp/config.yaml --no-format /dev/vda1 https://github.com/rancher/k3os/releases/download/v0.10.0/k3os.iso

Установка через оверлей ARM

Если у вас есть пользовательское устройство ARMv7 или ARM64, вы можете легко использовать существующий загрузочный образ ARM для создания настройки k3OS. Всё, что вам нужно сделать, это загрузить систему ARM, а затем извлечь k3os-rootfs-arm.tar.gz в корень (удаление одного пути, см. пример ниже), а затем поместить свой cloud-config в /k3os/system/config.yaml. Например:

curl -sfL https://github.com/rancher/k3os/releases/download/v0.10.0/k3os-rootfs-arm.tar.gz | tar zxvf - --strip-components=1 -C /
cp myconfig.yaml /k3os/system/config.yaml
sync
reboot -f

Этот метод помещает k3OS на диск и также перезаписывает /sbin/init. На следующей перезагрузке ваш загрузчик и ядро ARM должны загрузиться, но затем, когда должно быть инициализировано пользовательское пространство, k3OS должен взять верх. Одним важным соображением на данный момент является то, что k3OS предполагает, что корневое устройство не доступно только для чтения. Обычно это означает, что вам необходимо удалить ro из командной строки ядра. Это должно быть исправлено в будущем выпуске.

Конфигурация

Вся конфигурация выполняется через один файл конфигурации в стиле cloud-init, который либо упакован в образе, загружен через cloud-init или управляется Kubernetes. Файл конфигурации находится по адресу:

/k3os/system/config.yaml
/var/lib/rancher/k3os/config.yaml
/var/lib/rancher/k3os/config.d/*

Файл /k3os/system/config.yaml зарезервирован для системной установки и не должен изменяться на работающей системе. Этот файл обычно заполняется во время процесса сборки или установки образа и содержит важную информацию о начальной загрузке (например, данные о сети или облачные источники данных).

Файлы /var/lib/rancher/k3os/config.yaml или config.d/* предназначены для использования во время выполнения. Эти файлы можно изменять вручную, с помощью сценариев или управлять с помощью оператора Kubernetes.

Пример `config.yaml`

Полный пример файла конфигурации k3OS приведён ниже.

ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...
- github:ibuildthecloud
write_files:
- encoding: ""
  content: |-
    #!/bin/bash
    echo hello, local service start
  owner: root
  path: /etc/local.d/example.start
  permissions: '0755'
hostname: myhost
init_cmd:
- "echo hello, init command"
boot_cmd:
- "echo hello, boot command"
run_cmd:
- "echo hello, run command"

k3os:
  data_sources:
  - aws
  - cdrom
  modules:
  - kvm
  - nvme
  sysctl:
    kernel.printk: "4 4 1 7"
    kernel.kptr_restrict: "1"
  dns_nameservers:
  - 8.8.8.8
  - 1.1.1.1
  ntp_servers:
  - 0.us.pool.ntp.org
  - 1.us.pool.ntp.org
  wifi:
  - name: home
    passphrase:
``` ### Kubernetes

Поскольку k3OS построен на базе k3s, вся конфигурация Kubernetes выполняется путём настройки k3s. Это в основном делается через ключи environment и k3s_args в config.yaml. Ключ write_files можно использовать для заполнения папки /var/lib/rancher/k3s/server/manifests приложениями, которые вы хотели бы развернуть при загрузке.

Подробнее о настройке Kubernetes см. в документации k3s (https://github.com/rancher/k3s/blob/master/README.md).

### Kernel cmdline

Всю конфигурацию также можно передать как параметры командной строки ядра. Ключи разделяются точкой. Например, k3os.token=TOKEN. Если ключ представляет собой срез, несколько значений устанавливаются путём повторения ключа, например k3os.dns_nameserver=1.1.1.1 k3os.dns_nameserver=8.8.8.8. Можно использовать форму множественного или единственного числа имени, просто убедитесь, что вы последовательно используете одну и ту же форму. Для значений карты используется форма key[key]=value, например, k3os.sysctl[kernel.printk]="4 4 1 7". Если значение содержит пробелы, убедитесь, что оно заключено в кавычки. Логические ключи ожидают значения true или false, или отсутствие значения означает true. Например, k3os.install.efi — это то же самое, что k3os.install.efi=true.

### Этапы

Конфигурация применяется в трёх отдельных этапах: initrd, boot, runtime. Этап initrd выполняется во время фазы initrd до того, как будет смонтирован корневой диск. Этап boot выполняется после того, как корневой диск смонтирован и файловая система настроена, но до запуска каких-либо служб. На этом этапе сеть ещё недоступна. Заключительный этап runtime выполняется после подключения к сети. Если вы используете конфигурацию от облачного провайдера (например, пользовательские данные AWS), она будет выполняться только на этапе runtime. Ниже приведена таблица поддерживаемых ключей конфигурации на каждом этапе.

| Ключ                  | initrd | boot | runtime |
|----------------------|--------|------|---------|
| ssh_authorized_keys  |        | x    | x       |
| write_files          | x     | x    | x       |
| hostname             | x     | x    | x       |
| run_cmd              |        |      | x       |
| boot_cmd             |        | x    |         |
| init_cmd             | x     |      |         |
| k3os.data_sources    |        |      | x       |
| k3os.modules         | x     | x    | x       |
| k3os.sysctls         | x     | x    | x       |
| k3os.ntp_servers     |        | x    | x       |
| k3os.dns_nameservers |        | x    | x       |
| k3os.wifi            |        | x    | x       |
| k3os.password        | x     | x    | x       |
| k3os.server_url      |        | x    | x       |
| k3os.token           |        | x    | x       |
| k3os.labels          |        | x    | x       |
| k3os.k3s_args        |        | x    | x       |
| k3os.environment     | x     | x    | x       |
| k3os.taints          |        | x    | x       |

### Сетевое взаимодействие

Сетевое взаимодействие обеспечивается connman. Чтобы настроить сетевое взаимодействие, доступны несколько вспомогательных ключей: k3os.dns_nameserver, k3os.ntp_servers, k3os.wifi. Подробнее об этих ключах см. раздел «Справочная информация». Если вы хотите настроить HTTP-прокси, установите поля http_proxy и https_proxy в k3os.environment. Всю остальную сетевую конфигурацию следует выполнять, настраивая connman напрямую с помощью ключа write_files для создания файлов [service](https://manpages.debian.org/testing/connman/connman-service.config.5.en.html) connman.

## Обновление и обслуживание

Обновление и перенастройка k3OS выполняются через оператора Kubernetes. Оператор всё ещё находится в разработке. Более подробная информация появится позже. Основной язык текста запроса — английский.  

**Базовый дизайн таков, что можно установить желаемые версии k3s и k3OS, а также их конфигурацию, и оператор развернёт это в кластере.**

### Автоматические обновления

Интеграция с [rancher/system-upgrade-controller](https://github.com/rancher/system-upgrade-controller) была реализована начиная с версии [v0.9.0](https://github.com/rancher/k3os/releases/tag/v0.9.0).
Чтобы включить автоматическое обновление узла k3OS из [последнего выпуска GitHub](https://github.com/rancher/k3os/releases/latest), необходимо убедиться, что у него есть метка `k3os.io/upgrade` со значением `latest` (для версий k3OS до v0.11.x используйте метку `plan.upgrade.cattle.io/k3os-latest`). Затем контроллер обновлений создаст задание обновления, которое отключит большинство модулей, обновит содержимое k3OS в каталоге `/k3os/system` и перезагрузит систему. Система должна вернуться к работе с последним ядром и версией k3s, включёнными в k3OS и готовыми к планированию модулей.

#### До версии v0.9.0

Если ваша установка k3OS работает на версии до версии v0.9.0 или одного из её кандидатов на выпуск, вы можете настроить системный контроллер обновлений для обновления вашей k3OS, выполнив следующие действия:

```shell script
# применить манифест system-upgrade-контроллера (один раз для кластера)
kubectl apply -f https://raw.githubusercontent.com/rancher/k3os/v0.10.0/overlay/share/rancher/k3s/server/manifests/system-upgrade-controller.yaml
# после того как модуль system-upgrade-контроллер станет готов, применить манифест плана (один раз для кластера)
kubectl apply -f https://raw.githubusercontent.com/rancher/k3os/v0.10.0/overlay/share/rancher/k3s/server/manifests/system-upgrade-plans/k3os-latest.yaml
# применить метку plan.upgrade.cattle.io/k3os-latest, как описано выше (для каждого узла k3OS), например
kubectl label nodes -l k3os.io/mode plan.upgrade.cattle.io/k3os-latest=enabled # это должно работать в любом кластере с установками k3OS версии 0.7.0 и выше

Ручные обновления

Для одноузловых или тестовых случаев использования, когда оператор не используется, вы можете обновить корневую файловую систему и ядро с помощью следующих команд. Если вы не укажете K3OS_VERSION, по умолчанию будет использоваться последняя версия.

При использовании оверлейной установки, такой как на Raspberry Pi (см. ARM Overlay Installation), исходное ядро дистрибутива (например, Raspbian) будет продолжать использоваться. В этих системах скрипт k3os-upgrade-kernel завершит работу с предупреждением и не выполнит никаких действий.

export K3OS_VERSION=v0.10.0
/usr/share/rancher/k3os/scripts/k3os-upgrade-rootfs
/usr/share/rancher/k3os/scripts/k3os-upgrade-kernel

Вы всегда должны помнить о резервном копировании данных перед обновлением и о необходимости перезагрузки после обновления.

Скрипты ручного обновления устарели

Эти скрипты были объявлены устаревшими начиная с версии v0.9.0, но всё ещё находятся в системе в папке /usr/share/rancher/k3os/scripts.

Сборка

Чтобы собрать k3OS, вам нужен только Docker, а затем запустите make. Все артефакты будут помещены в ./dist/artifacts. Если вы работаете в Linux, вы можете запустить ./scripts/run, чтобы запустить виртуальную машину k3OS в терминале. Чтобы выйти из экземпляра, введите CTRL+a c, чтобы получить консоль qemu, а затем q для выхода.

Исходный код ядра находится по адресу https://github.com/rancher/k3os-kernel, и аналогично вам нужно иметь Docker и запустить make, чтобы скомпилировать ядро.

Справочник по конфигурации

Ниже приведена ссылка на все ключи, доступные в файле config.yaml.

`ssh_authorized_keys`

Список SSH-ключей, которые должны быть добавлены пользователю rancher. У k3OS есть один основной пользователь — rancher. Пользователь root всегда отключен, не имеет пароля и никогда не получает ключ SSH. Ключи SSH можно получить из учётных записей GitHub, используя формат github:${USERNAME}. Это делается путём загрузки ключей с сайта https://github.com/${USERNAME}.keys.

Пример:

ssh_authorized_keys:
- "ssh-rsa" ### `write_files`

Список файлов, которые необходимо записать на диск при загрузке. Эти файлы могут быть в виде простого текста, сжаты с помощью gzip, закодированы с использованием base64 или base64+gzip.

Пример:

```yaml
write_files:
- encoding: b64
  content: CiMgVGhpcyBmaWxlIGNvbnRyb2xzIHRoZSBzdGF0ZSBvZiBTRUxpbnV4...
  owner: root:root
  path: /etc/connman/main.conf
  permissions: '0644'
- content: |
    # My new /etc/sysconfig/samba file

    SMDBOPTIONS="-D"
  path: /etc/sysconfig/samba
- content: !!binary |
    f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAwARAAAAAAABAAAAAAAAAAJAVAAAAAA
    AEAAHgAdAAYAAAAFAAAAQAAAAAAAAABAAEAAAAAAAEAAQAAAAAAAwAEAAAAAAA
    AAAAAAAAAwAAAAQAAAAAAgAAAAAAAAACQAAAAAAAAAJAAAAAAAAcAAAAAAAAAB
    ...
  path: /bin/arch
  permissions: '0555'
- content: |
    15 * * * * root ship_logs
  path: /etc/crontab
### `hostname`

Установка системного имени хоста. Это значение будет перезаписано DHCP, если DHCP предоставляет имя хоста для системы.

Пример:

```yaml
hostname: myhostname
### `init_cmd`, `boot_cmd`, `run_cmd`

Все три ключа используются для запуска произвольных команд при запуске на соответствующих этапах `initrd`, `boot` и `runtime`. Команды выполняются после `write_files`, поэтому можно написать скрипт на диске и запустить его из этих команд. Часто это упрощает выполнение более длительной настройки.

### `k3os.data_sources`

Эти источники данных используются для загрузки конфигурации из облачного провайдера. Допустимые параметры:

* aws
* cdrom
* digitalocean
* gcp
* hetzner
* openstack
* packet
* scaleway
* vultr

Можно поддерживать более одного источника одновременно, например:

```yaml
k3os:
  data_sources:
  - openstack
  - cdrom

Когда указано несколько источников данных, они проверяются по порядку, и первый, который предоставит `/run/config/userdata`, остановит дальнейшую обработку.

### `k3os.modules`

Список модулей ядра, загружаемых при старте.

Пример:

```yaml
k3os:
  modules:
  - kvm
  - nvme
### `k3os.sysctls`

Настройка sysctl ядра при старте. Это те же настройки, которые обычно находятся в `/etc/sysctl.conf`. Должны быть указаны как строковые значения.

```yaml
k3os:
  sysctl:
    kernel.printk: 4 4 1 7      # парсер YAML прочитает как строку
    kernel.kptr_restrict: "1"   # заставить парсер YAML читать как строку
### `k3os.ntp_servers`

Резервные серверы NTP для использования, если NTP не настроен где-либо ещё в connman.

Пример:

```yaml
k3os:
  ntp_servers:
  - 0.us.pool.ntp.org
  - 1.us.pool.ntp.org
### `k3os.dns_nameservers`

**Резервные** DNS-серверы имён для использования, если DNS не настроен DHCP или в конфигурации службы connman.

Пример:

```yaml
k3os:
  dns_nameservers:
  - 8.8.8.8
  - 1.1.1.1
### `k3os.wifi`

Простая конфигурация Wi-Fi. Всё, что принимается, — это `name` и `passphrase`. Если вам требуется более сложная настройка, вы должны использовать `write_files` для создания конфигурации службы connman.

Пример:

```yaml
k3os:
  wifi:
  - name: home
    passphrase: mypassword
  - name: nothome
    passphrase: somethingelse
### `k3os.password`

Пароль для пользователя `rancher`. По умолчанию для пользователя `rancher` нет пароля. Если вы установите пароль во время выполнения, он будет сброшен при следующей загрузке, потому что `/etc` является эфемерным. Значение пароля может быть открытым текстом или зашифрованной формой. Самый простой способ получить эту зашифрованную форму — просто изменить свой пароль в системе Linux и скопировать значение второго поля из `/etc/shadow`. Вы также можете зашифровать пароль с помощью `openssl passwd -1`.

Пример

```yaml
k3os:
  password: "$1$tYtghCfK$QHa51MS6MVAcfUKuOzNKt0"

Или открытым текстом:

```yaml
k3os:
  password: supersecure
### `k3os.server_url`

URL сервера k3s, к которому нужно присоединиться в качестве агента. ### `k3os.token`

Секретный ключ кластера или токен узла. Если значение соответствует формату токена узла, то оно автоматически считается токеном узла. В противном случае оно рассматривается как секретный ключ кластера.

Пример:
```yaml
k3os:
  token: myclustersecret

Или токен узла:

k3os:
  token: "K1074ec55daebdf54ef48294b0ddf0ce1c3cb64ee7e3d0b9ec79fbc7baf1f7ddac6::node:77689533d0140c7019416603a05275d4"

`k3os.labels`

Метки, которые будут присвоены этому узлу в Kubernetes при регистрации. После первой регистрации узла в Kubernetes значение этого параметра будет игнорироваться.

Пример:

k3os:
  labels:
    region: us-west-1
    somekey: somevalue

`k3os.k3s_args`

Аргументы, передаваемые процессу k3s. Аргументы должны начинаться с «server» или «agent», чтобы быть действительными. k3s_args — это массив аргументов в стиле exec (также называемый неинтерпретированным), что означает, что при указании флага со значением необходимо либо соединить флаг со значением с помощью = в одной записи массива, либо указать флаг в записи отдельно, а значение — в следующей записи, например:

# Флаги K3s со значениями, объединёнными с `=` в одну запись
k3os:
  k3s_args:
  - server
  - "--cluster-cidr=10.107.0.0/23"
  - "--service-cidr=10.107.1.0/23"

# Эквивалентно вызову k3s:
# exec "k3s" "server" "--cluster-cidr=10.107.0.0/23" "--service-cidr=10.107.1.0/23"

# Флаги K3s с значениями в следующей записи
k3os:
  k3s_args:
  - server
  - "--cluster-cidr"
  - "10.107.0.0/23"
  - "--service-cidr"
  - "10.107.1.0/23"

# Эквивалентно вызову k3s:
# exec "k3s" "server" "--cluster-cidr" "10.107.0.0/23" "--service-cidr" "10.107.1.0/23"

`k3os.environment`

Переменные среды, которые должны быть установлены на k3s и других процессах, таких как процесс загрузки. Основное назначение этого поля — установка http-прокси.

Пример:

k3os:
  environment:
    http_proxy: http://myserver
    https_proxy: http://myserver

`k3os.taints`

Тейнты, устанавливаемые на текущем узле при его первой регистрации. После того как узел впервые зарегистрирован, значение этого поля игнорируется.

k3os:
  taints:
  - "key1=value1:NoSchedule"
  - "key1=value1:NoExecute"