Flatcar Container Linux

Головна ідея: Flatcar Container Linux — це мінімалістична, immutable Linux-операційна система для контейнерних workload-ів, Kubernetes-кластерів і cloud-native інфраструктури.

Чому це цікаво: Flatcar є духовним спадкоємцем CoreOS Container Linux: він зберіг ідею автоматичних оновлень, read-only системного розділу, Ignition-конфігурації та серверів, які не “лікують руками”, а перевипускають і оновлюють як частину кластера.

Важливо: Flatcar Container Linux не є універсальним серверним Linux на кшталт Ubuntu Server, Debian або AlmaLinux. Він спеціально створений для запуску контейнерів і керування інфраструктурою як однотипним fleet-ом машин.

1. Загальний опис

Flatcar Container Linux — це відкрита операційна система на базі Linux, оптимізована для запуску контейнерів.

Вона використовується для:

Kubernetes worker nodes;
container hosts;
immutable infrastructure;
cloud-native платформ;
bare metal-кластерів;
edge-сценаріїв;
multi-cloud інфраструктури;
приватних Kubernetes-кластерів;
автоматизованих серверних fleet-ів;
середовищ, де важливі низьке обслуговування, безпека й передбачувані оновлення.

Офіційний сайт Flatcar описує систему як immutable Linux OS для container workloads, що має мінімальний набір компонентів для контейнеризованих застосунків, автоматичні оновлення безпеки, read-only системний розділ і зменшений attack surface. ([flatcar-linux.org](https://flatcar-linux.org/?utm_source=chatgpt.com))

2. Коротка характеристика

Характеристика	Значення
Назва	Flatcar Container Linux
Скорочення	Flatcar
Тип	Immutable Linux-дистрибутив для контейнерів
Походження	Спадкоємець CoreOS Container Linux
Основне призначення	Container hosts, Kubernetes nodes, immutable infrastructure
Package manager	Відсутній у класичному сенсі
Init-система	systemd
Provisioning	Ignition
Оновлення	A/B image-based updates
Reboot coordination	locksmith
Контейнерні runtime-и	containerd, Docker у відповідних версіях/сценаріях
Релізні канали	Alpha, Beta, Stable, LTS
CNCF статус	Incubating
Актуальні релізні гілки на травень 2026	Stable 4593.x, Beta 4628.x, Alpha 4669.x, LTS 4081.x

Flatcar був прийнятий до CNCF 2 серпня 2024 року на рівні Incubating як community Linux distribution для container workloads з high security і low maintenance. ([cncf.io](https://www.cncf.io/projects/flatcar-container-linux/?utm_source=chatgpt.com))

3. Flatcar простими словами

Звичайний серверний Linux часто виглядає так:

Встановив ОС
зайшов по SSH
поставив пакети
підправив конфіги
налаштував сервіси
час від часу оновлюєш вручну

Flatcar пропонує інший підхід:

створив node з готового образу
передав конфіг через Ignition
запускаєш workload-и в контейнерах
система автоматично оновлюється
node можна замінити без жалю

Тобто Flatcar — це не “сервер, який довго налаштовують руками”, а “однотипний вузол контейнерної інфраструктури”.

Людське пояснення: якщо класичний сервер — це індивідуально налаштований комп'ютер, то Flatcar-node — це стандартизована деталь у великому механізмі Kubernetes або container fleet.

4. Історія

Flatcar виник після змін навколо CoreOS Container Linux.

Ключові етапи:

Рік	Подія
2013	CoreOS представила CoreOS Container Linux як мінімалістичну ОС для контейнерної інфраструктури.
2018	Red Hat придбала CoreOS.
2018	Kinvolk оголосила Flatcar Container Linux як спадкоємця CoreOS Container Linux.
2020	CoreOS Container Linux досяг EOL, а Flatcar став одним із головних шляхів для користувачів, які хотіли зберегти CoreOS-подібну модель.
2021	Microsoft придбала Kinvolk, команду, що розвивала Flatcar.
2024	Flatcar Container Linux прийнято до CNCF на рівні Incubating.
2026	Flatcar продовжує розвиватися як community container OS з каналами Alpha, Beta, Stable і LTS.

5. Цікавий факт: Flatcar зберіг ідеї CoreOS, які не всі хотіли втратити

CoreOS Container Linux був дуже важливим для ранньої container-native інфраструктури.

Коли CoreOS змінив напрям після придбання Red Hat, частині спільноти потрібна була система, яка продовжить стару ідею:

мінімальна ОС;
автоматичні оновлення;
A/B partitions;
контейнерні workload-и;
Ignition;
systemd;
immutable host;
fleet-style management.

Flatcar з'явився саме як відповідь на це.

Простими словами:

CoreOS Container Linux зник,
але його філософія не зникла.
Flatcar підхопив її.

6. Основна філософія

Flatcar базується на кількох ідеях.

Ідея	Пояснення
Immutable OS	Системний розділ не змінюється як у звичайному Linux.
Container-first	Застосунки запускаються в контейнерах, а не встановлюються в host.
Minimal attack surface	У системі мало зайвих компонентів.
Automatic updates	ОС може оновлюватися автоматично.
Fleet management	Машини керуються як група, а не як унікальні сервери.
Declarative provisioning	Початкова конфігурація задається через Ignition.
Replace, not repair	Проблемний node легше замінити, ніж вручну “лікувати”.

7. Immutable filesystem

Flatcar має immutable-підхід до системи.

Офіційний сайт підкреслює, що read-only system partition допомагає усунути цілий клас високоризикових security vulnerabilities, а мінімальний набір компонентів зменшує attack surface. ([flatcar-linux.org](https://flatcar-linux.org/?utm_source=chatgpt.com))

Це означає:

системний розділ не змінюється довільно;
немає звичного встановлення пакетів у host;
зміни мають бути описані конфігураційно;
workload-и живуть у контейнерах;
host залишається максимально чистим;
node простіше відтворити.

8. Немає класичного package manager

У Flatcar немає звичного підходу:

apt install
dnf install
zypper install

Це зроблено навмисно.

Замість встановлення software на host потрібно:

запускати сервіси в контейнерах;
додавати systemd units;
використовувати Ignition;
будувати власні образи;
керувати workload-ами через Kubernetes;
оновлювати всю ОС як образ.

Практичний сенс: якщо вам хочеться встановлювати багато пакетів на host, Flatcar, імовірно, не ваш дистрибутив. Якщо host має бути чистою платформою для контейнерів — це вже його територія.

9. A/B оновлення

Flatcar використовує image-based A/B update-модель.

Ідея:

Є активний системний розділ A.
Нова версія записується в неактивний розділ B.
Після reboot система стартує з B.
Якщо щось погано — можна повернутися назад.

Це робить оновлення схожими більше на оновлення firmware або мобільної ОС, ніж на класичне оновлення Linux-пакетів.

10. update-engine

update-engine відповідає за завантаження й застосування системних оновлень.

Він працює з каналами оновлень і допомагає переводити систему на нову версію.

Типова логіка:

перевірити доступність update
завантажити update payload
записати нову систему в неактивний розділ
позначити новий розділ для boot
перезавантажити систему

11. locksmith

locksmith — reboot manager для Flatcar update engine.

Його завдання — координувати перезавантаження машин після оновлень.

GitHub-опис locksmith зазначає, що `locksmithd` може використовувати etcd, щоб гарантувати, що лише частина машин у кластері перезавантажується одночасно. ([github.com](https://github.com/flatcar/locksmith?utm_source=chatgpt.com))

Це важливо, бо якщо всі node-и перезавантажаться одночасно, кластер може втратити доступність.

12. Цікавий факт: Flatcar оновлюється як fleet, а не як один сервер

У класичному Linux:

сервер оновили
сервер перезавантажили
готово

У Flatcar-логіці важливіше:

у кластері 100 машин
оновити їх поступово
не впустити workload-и
не перезавантажити всі одночасно
дати orchestrator-у перенести контейнери

Це дуже cloud-native мислення: окремий сервер менш важливий, ніж стан усього fleet.

13. Ignition

Ignition — рекомендований спосіб provisioning для Flatcar.

Офіційна документація пояснює, що Ignition читає конфігурацію на першому boot і може:

розмічати диски;
форматувати partitions;
записувати файли;
створювати systemd units;
створювати networkd units;
налаштовувати користувачів;
застосовувати конфігурацію з remote URL, metadata service або hypervisor bridge. ([flatcar.org](https://www.flatcar.org/docs/latest/provisioning/ignition/?utm_source=chatgpt.com))

14. Ignition працює тільки на першому boot

Це важливий момент.

Ignition — не інструмент для постійної зміни системи.

Він працює при першому запуску свіжого образу.

Офіційна документація Flatcar підкреслює, що Ignition configurations розпізнаються лише при boot unmodified fresh image, бо Ignition runs only on first boot. ([flatcar.org](https://www.flatcar.org/docs/latest/installing/?utm_source=chatgpt.com))

15. Приклад Ignition-логіки

Спрощений приклад того, що може робити Ignition:

1. Створити користувача core.
2. Додати SSH key.
3. Записати systemd unit.
4. Запустити контейнерний сервіс.
5. Налаштувати мережу.
6. Підготувати диск.

У реальних проєктах Ignition config часто генерують через Butane.

16. Butane

Butane — інструмент для створення Ignition-конфігурацій у зручнішому YAML-форматі.

Загальна схема:

Butane YAML
   |
   v
butane
   |
   v
Ignition JSON
   |
   v
Flatcar first boot

Це зручніше, ніж писати великий JSON вручну.

17. systemd

Flatcar використовує systemd.

У Flatcar systemd важливий для:

запуску system services;
container units;
network configuration;
timers;
locksmith;
update-related services;
custom units через Ignition;
логіки boot process.

Приклад systemd unit може бути переданий через Ignition, щоб запускати контейнер або сервіс на node.

18. Контейнери

Flatcar створений для запуску контейнерів.

Типові workload-и:

Kubernetes pods;
Docker containers;
containerd workloads;
systemd-managed containers;
monitoring agents;
log collectors;
ingress components;
infrastructure services;
edge workloads.

Flatcar не намагається бути повноцінним general purpose host. Його ідея — бути стабільною основою для контейнерів.

19. Kubernetes

Flatcar дуже часто використовується як ОС для Kubernetes worker nodes.

Типова схема:

Kubernetes Cluster
   |
   +--> Flatcar node
   +--> Flatcar node
   +--> Flatcar node
        |
        +--> kubelet
        +--> container runtime
        +--> pods

Kubermatic документація описує Flatcar як minimal, container-optimized Linux distribution для containerized workloads, з релізними каналами Stable, Beta, Alpha і підтримкою AWS, Azure, GCP, KubeVirt, OpenStack, VMware Cloud Director і vSphere. ([docs.kubermatic.com](https://docs.kubermatic.com/machine-controller/main/references/operating-systems/?utm_source=chatgpt.com))

20. Релізні канали

Flatcar має кілька release channels.

Канал	Призначення
Alpha	Найновіші зміни, раннє тестування.
Beta	Перевірка змін перед Stable.
Stable	Основний канал для production-сценаріїв.
LTS	Довгострокова гілка з меншими змінами для консервативних середовищ.

Офіційна документація Flatcar пояснює, що Beta дає можливість валідувати зміни раніше, а для low-maintenance сценаріїв є LTS-канал, який отримує bug fix releases. Нові major-релізи виходять приблизно раз на рік і створюють новий LTS stream. ([flatcar.org](https://www.flatcar.org/docs/latest/setup/releases/switching-channels/?utm_source=chatgpt.com))

21. Актуальні релізи

На травень 2026 року Flatcar має активні канали Alpha, Beta, Stable і LTS.

У квітні 2026 року в release-плані згадувалися:

Alpha 4669.0.0;
Beta 4628.1.0;
Stable 4593.2.0;
LTS 4081.3.7. ([github.com](https://github.com/flatcar/Flatcar/issues/2076?utm_source=chatgpt.com))

Точні версії змінюються регулярно, тому для production слід перевіряти офіційну сторінку релізів Flatcar.

22. Цікавий факт: Flatcar має LTS-канал, хоча це container OS

Можна подумати, що container OS завжди має швидко оновлюватися.

Але в enterprise не всі хочуть постійних major-змін.

Тому LTS-канал корисний для команд, яким потрібно:

менше змін;
довший період стабільності;
security fixes;
передбачуваність;
менше regression-ризику;
контрольований upgrade path.

23. Платформи

Flatcar може запускатися на різних платформах.

Типові середовища:

AWS;
Azure;
Google Cloud;
OpenStack;
VMware;
QEMU/KVM;
Proxmox;
bare metal;
Packet/Equinix Metal у відповідних сценаріях;
Kubernetes-провайдери;
private cloud.

Важливе уточнення для Azure: Microsoft повідомила, що Flatcar Container Linux for AKS preview перестане підтримуватися в AKS з 8 червня 2026 року; після цього не будуть створюватися нові Flatcar node images для AKS, а 8 вересня 2026 року старі image-и буде прибрано. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/aks/flatcar-container-linux-for-aks?utm_source=chatgpt.com))

24. Flatcar і Azure

Flatcar має особливу історію з Microsoft.

Microsoft придбала Kinvolk у 2021 році, а Kinvolk була компанією, що створила Flatcar.

Проте підтримка Flatcar саме в AKS preview завершується у 2026 році, і Microsoft радить міграцію на підтримувані альтернативи, зокрема Azure Container Linux для AKS-сценаріїв. ([github.com](https://github.com/Azure/AKS/issues/5648?utm_source=chatgpt.com))

Це хороший приклад того, що open source-проєкт і конкретна підтримка в managed cloud service — не одне й те саме.

25. Безпека

Flatcar має сильний security-фокус.

Основні елементи:

мінімальний набір компонентів;
read-only system partition;
автоматичні security updates;
зменшений attack surface;
відсутність package manager;
container isolation;
signed images у відповідних процесах;
регулярні релізи;
LTS-канал для консервативних середовищ;
контрольований reboot через locksmith;
декларативний provisioning.

26. Attack surface

Attack surface — це кількість можливих місць для атаки.

Flatcar зменшує його через:

мінімальну систему;
відсутність зайвих пакетів;
контейнерну модель;
read-only system partition;
автоматичні оновлення;
уникнення ручного встановлення software на host.

Це не робить систему “магічно безпечною”, але дає хорошу базу для container infrastructure.

27. Цікавий факт: Flatcar — це Linux, який не хоче бути “сніжинкою”

У DevOps є термін snowflake server — сервер, який вручну налаштовували так довго, що ніхто вже не може точно відтворити його стан.

Flatcar бореться саме з цим.

Його ідея:

node має бути відтворюваним
конфігурація має бути декларативною
software має бути в контейнерах
оновлення мають бути системними
manual drift має бути мінімальним

28. Архітектура Flatcar

Загальна схема:

Hardware / VM / Cloud Instance
        |
        v
Flatcar Container Linux
        |
        +--> Linux Kernel
        +--> systemd
        +--> read-only system partition
        +--> update-engine
        +--> locksmith
        +--> Ignition
        +--> container runtime
        |
        v
Container Layer
        |
        +--> containerd
        +--> Docker / compatibility scenarios
        +--> Kubernetes kubelet
        |
        v
Workloads
        |
        +--> Pods
        +--> Containers
        +--> Services
        +--> Agents

29. Переваги Flatcar

Перевага	Опис
Container-first	Система створена саме для контейнерних workload-ів.
Immutable design	Зменшує configuration drift і випадкові зміни.
Automatic updates	ОС може самостійно отримувати security updates.
A/B partitions	Оновлення системи більш контрольоване й має rollback-логіку.
Ignition	Декларативне налаштування при першому boot.
Мінімальний attack surface	У системі мало зайвого software.
Kubernetes-friendly	Добре підходить для worker nodes.
LTS-канал	Є варіант для консервативних production-сценаріїв.
CNCF Incubating	Проєкт має визнання в cloud-native екосистемі.

30. Недоліки Flatcar

Недолік	Опис
Не general purpose OS	Не підходить для звичайного серверного адміністрування.
Немає package manager	Не можна просто встановити потрібний пакет на host.
Незвичний provisioning	Ignition і Butane потребують навчання.
Потрібна container-культура	Найкраще працює там, де все запускається в контейнерах.
Автооновлення треба планувати	Без координації reboot-и можуть завадити workload-ам.
Менше beginner-документації	Ubuntu/Debian мають більше простих інструкцій для новачків.
Managed cloud підтримка може змінюватися	Наприклад, AKS preview support для Flatcar завершується у 2026 році.

31. Порівняння з Bottlerocket

Критерій	Flatcar Container Linux	Bottlerocket
Походження	Спадкоємець CoreOS Container Linux.	AWS container OS.
Основна екосистема	Multi-cloud, Kubernetes, bare metal, private cloud.	AWS, EKS, ECS.
Provisioning	Ignition / Butane.	API settings, user data, AWS integrations.
Оновлення	A/B updates, update-engine, locksmith.	Image-based updates, orchestrator-aware tooling.
Package manager	Немає.	Немає.
Найкращий сценарій	Kubernetes/container fleet у різних середовищах.	EKS/ECS container nodes в AWS.

32. Порівняння з Talos Linux

Критерій	Flatcar	Talos Linux
Фокус	Container OS для Kubernetes і container hosts.	Kubernetes-only OS.
SSH	Можливий у відповідних конфігураціях.	SSH відсутній за задумом.
Provisioning	Ignition.	Talos API / machine configuration.
Адміністрування	systemd, Ignition, update engine, containers.	talosctl і API-driven управління.
Гнучкість	Трохи ближчий до класичної Linux-моделі.	Більш радикально Kubernetes-only.

33. Порівняння з Ubuntu Server

Критерій	Flatcar	Ubuntu Server
Призначення	Container host.	General purpose server.
Package manager	Немає.	APT.
Оновлення	A/B image-based.	Package-based.
Provisioning	Ignition.	cloud-init, manual setup, Ansible тощо.
Host-сервіси	Мінімізовані, бажано в контейнерах.	Можна запускати будь-які системні сервіси.
Найкраще використання	Kubernetes nodes, immutable fleet.	VPS, web, database, Docker host, general server.

34. Порівняння з Fedora CoreOS

Критерій	Flatcar	Fedora CoreOS
Походження	Спадкоємець CoreOS Container Linux через Kinvolk.	Fedora/Red Hat-напрям після CoreOS.
Екосистема	CNCF, multi-cloud, container infrastructure.	Fedora, Red Hat, OpenShift-related ecosystem.
Provisioning	Ignition.	Ignition.
Оновлення	A/B updates.	rpm-ostree/OSTree-підхід.
Для кого	Команди, що хочуть CoreOS-like систему поза прив'язкою до OpenShift.	Fedora/Red Hat/OpenShift ecosystem.

35. Коли варто використовувати Flatcar

Flatcar доцільно обрати, якщо:

потрібні Kubernetes worker nodes;
потрібна immutable container OS;
потрібна спадкоємність CoreOS-підходу;
потрібні автоматичні оновлення;
важливий мінімальний attack surface;
потрібна multi-cloud або bare metal container infrastructure;
усе запускається в контейнерах;
команда використовує Ignition/Butane;
потрібно керувати fleet-ом, а не окремими “ручними” серверами;
важлива LTS-гілка для container OS.

36. Коли Flatcar може бути не найкращим вибором

Flatcar може бути не найкращим варіантом, якщо:

потрібен звичайний VPS;
потрібно встановлювати пакети на host;
потрібен web server без контейнерів;
команда не використовує Kubernetes або containers;
адміністратори хочуть класичний SSH-first workflow;
потрібна desktop або general purpose server OS;
немає бажання вивчати Ignition/Butane;
інфраструктура залежить від managed cloud support, який може змінюватися.

37. Типові помилки новачків

Помилка	Чому виникає	Як правильно думати
“Де apt/dnf?”	Flatcar не має класичного package manager.	Software має запускатися в контейнерах.
“Чому Ignition не спрацював вдруге?”	Ignition працює лише на першому boot.	Для нової конфігурації потрібен новий fresh instance або інший процес.
“Чому система сама хоче reboot?”	Автооновлення є частиною дизайну.	Налаштовувати reboot coordination через locksmith/orchestrator.
“Чому не можна просто змінити root filesystem?”	System partition read-only.	Використовувати declarative provisioning і containers.
“Чому node не треба лагодити руками?”	Ідея immutable infrastructure.	Краще перевипустити node з правильним config.
“Чим це краще Ubuntu?”	Не краще для всього.	Flatcar кращий саме для container fleet-сценаріїв.

38. Базовий чеклист для використання

1. Визначити платформу: cloud, VM, bare metal.
2. Обрати release channel: Stable або LTS для production.
3. Підготувати Butane config.
4. Згенерувати Ignition JSON.
5. Передати Ignition config при першому boot.
6. Налаштувати SSH keys або інший доступ.
7. Налаштувати container runtime / Kubernetes.
8. Налаштувати update policy.
9. Налаштувати locksmith або orchestrator-aware reboot.
10. Перевірити monitoring і logging.
11. Тестувати rolling updates.
12. Документувати node lifecycle.

39. Цікаві факти

Факт	Пояснення
Flatcar є спадкоємцем CoreOS Container Linux	Він продовжив модель мінімальної контейнерної ОС після змін у CoreOS.
Flatcar не має класичного package manager	Це зроблено для зменшення складності й configuration drift.
Ignition працює тільки на першому boot	Це змушує думати декларативно й відтворювано.
Flatcar має A/B updates	Нова система записується в неактивний розділ і активується після reboot.
locksmith координує reboot-и	Це допомагає не перезавантажити весь кластер одночасно.
Flatcar має LTS-канал	Це корисно для консервативних enterprise-середовищ.
Flatcar став CNCF Incubating-проєктом	Це підкреслює його роль у cloud-native екосистемі.
Flatcar добре підходить для bare metal Kubernetes	Його можна використовувати не лише в public cloud.
Azure AKS preview support завершується у 2026	Це показує різницю між open source-проєктом і підтримкою в конкретному managed service.

40. Людське пояснення: чим є Flatcar

Flatcar — це операційна система для людей, які перестали думати про сервер як про домашню рослину, яку треба постійно поливати руками.

У класичному підході сервер живе довго, накопичує зміни, має свою історію, свої “тимчасові” правки й свої загадки.

У Flatcar-підході node має бути:

чистим;
відтворюваним;
оновлюваним;
замінним;
однаковим з іншими;
придатним для контейнерів.

Це не романтична система для ручного адміністрування. Це інженерна деталь для cloud-native інфраструктури.

41. Безпека

Рекомендовані практики:

використовувати Stable або LTS для production;
регулярно оновлювати nodes;
координувати reboot-и;
використовувати signed/verified container images;
не запускати зайві privileged containers;
не перетворювати host на general purpose Linux;
тримати конфігурацію в Git;
генерувати Ignition через Butane;
використовувати Kubernetes security policies;
налаштувати monitoring;
мати rollback і node replacement-план;
не покладатися лише на snapshots або update rollback замість backup для даних.

42. Flatcar у сучасній інфраструктурі

У 2026 році Flatcar залишається важливим вибором для container-first інфраструктури.

Його використовують у сценаріях:

Kubernetes worker nodes;
bare metal clusters;
private cloud;
multi-cloud;
edge;
container appliances;
immutable server fleet;
platform engineering;
managed Kubernetes-проєкти, де Flatcar підтримується конкретним провайдером;
середовища, де потрібні автоматичні оновлення і low-maintenance host OS.

Flatcar не замінює Ubuntu Server, Debian або RHEL у всіх задачах. Він замінює їх саме там, де host повинен бути мінімальним, відтворюваним і контейнерним.

43. Висновок

Flatcar Container Linux — це мінімалістична immutable Linux-операційна система для контейнерів, Kubernetes і cloud-native інфраструктури.

Її головні переваги:

container-first дизайн;
спадкоємність CoreOS Container Linux;
read-only system partition;
автоматичні A/B updates;
Ignition provisioning;
locksmith reboot coordination;
мінімальний attack surface;
релізні канали Alpha/Beta/Stable/LTS;
multi-cloud і bare metal-сценарії;
CNCF Incubating-статус.

Головні обмеження:

не general purpose OS;
немає package manager;
незвичний provisioning;
потрібна container/Kubernetes-культура;
автоматичні reboot-и треба координувати;
не підходить для ручного встановлення сервісів на host;
managed cloud support залежить від конкретного провайдера.

Flatcar найкраще підходить командам, які будують Kubernetes або container fleet і хочуть, щоб host OS була маленькою, безпечною, immutable, автоматично оновлюваною і максимально однаковою на всіх вузлах.

44. Джерела

Flatcar Container Linux official website
Flatcar Container Linux documentation
Flatcar releases
Flatcar release channels documentation
Flatcar Ignition documentation
Flatcar update and reboot strategies
Flatcar locksmith repository
Flatcar GitHub repository
CNCF Flatcar Container Linux project page
Microsoft AKS Flatcar Container Linux retirement notice
Kubermatic operating systems documentation

45. Див. також

Flatcar Container Linux Flatcar CoreOS Container Linux Fedora CoreOS Linux Container OS Kubernetes Docker containerd Ignition Butane systemd locksmith update-engine Immutable infrastructure Cloud-native CNCF Bottlerocket Talos Linux Ubuntu Server DevOps Операційні системи