Niezmienne dystrybucje Linux na serwerze: przegląd

Czym jest niezmienna dystrybucja systemu Linux

Niezmienna dystrybucja systemu Linux dostarcza system operacyjny jako jeden obraz, co oznacza, że zamiast aktualizować system w miejscu, dokonuje się jego wymiany. Nie ma tu miejsca na nadpisywanie plików w apt upgrade w katalogu /usr na działającej maszynie. Buduje się lub pobiera nowy obraz, maszyna przygotowuje go obok aktualnie uruchomionego, a kolejny restart przełącza aktywną wersję. Poprzedni obraz pozostaje na dysku, więc wycofanie nieudanej aktualizacji sprowadza się do ponownego uruchomienia komputera.

Słowo "niezmienna" jest pewnym nadużyciem. Nic fizycznie nie powstrzymuje użytkownika root przed zapisem na dysku. Systemy te montują katalogi systemowe w trybie tylko do odczytu i przypisują ich własność do obrazu. Trwałe dane przechowywane są w /var. Konfiguracja specyficzna dla maszyny znajduje się w /etc. Wszystko w /usr należy do obrazu, dlatego dwa serwery korzystające z tego samego tagu obrazu posiadają identyczne pliki systemowe.

Nazewnictwo stosowane przez Red Hat dla tych dwóch modeli jest najbardziej przejrzyste: tryb pakietowy (package mode) oraz tryb obrazu (image mode). Tryb pakietowy to działający system wraz z menedżerem pakietów, który go modyfikuje. Tryb obrazu to etap budowania przeprowadzany w innym miejscu, który tworzy artefakt, a serwer ma za zadanie jedynie uruchomić wskazany artefakt. Wszystkie poniższe informacje wynikają z tej jednej różnicy.

Dlaczego system tylko do odczytu jest kluczowy na serwerze

Serwer działający przez dwa lata posiada historię, której nikt nie udokumentował. make install z pośpiesznie przeprowadzonych prac wieczornych. Repozytorium zewnętrznych dostawców dodane dla jednego pakietu. Plik konfiguracyjny edytowany podczas awarii, który nigdy nie wrócił do systemu zarządzania konfiguracją. Zjawisko to nazywa się dryfem konfiguracji i jest powodem, dla którego odtworzenie „tego samego” serwera na podstawie notatek tak często skutkuje maszyną zachowującą się inaczej. Notatki zawierają zamierzenia. Dysk zawiera prawdę.

Tryb obrazu usuwa miejsce, w którym gromadzi się dryf. /usr jest w czasie pracy systemu tylko do odczytu, więc ręczna instalacja albo kończy się niepowodzeniem, albo zostaje zarejestrowana jako warstwa, którą można wyświetlić jednym poleceniem. Dzięki temu różnice między dwiema maszynami są widoczne, zamiast wymagać pracy archeologicznej. Jest to ten sam problem, który standardowa lista kontrolna konserwacji serwera Linux rozwiązuje za pomocą dyscypliny, tutaj natomiast obsługiwany jest przez system plików.

Wycofanie zmian to restart i na tym polega cała koncepcja

Awaria, dla której zaprojektowano ten model, jest tą, którą już opisaliśmy: serwer VPS, który nie uruchamia się po aktualizacji jądra. W trybie pakietowym odzyskiwanie systemu odbywa się z poziomu konsoli ratunkowej dostawcy. Należy zamontować dysk, wykonać chroot i ręcznie usunąć pakiet jądra. Działa to, ponieważ program rozruchowy zachowuje starsze wersje jądra, ale tylko jądro jest w ten sposób wersjonowane. Aktualizacja glibc oraz zmiany w systemd, które pojawiły się w tej samej transakcji, zostały już zastosowane i nie ma jednego polecenia, które cofnęłoby je wszystkie jednocześnie.

W trybie obrazu jednostką jest cały system. Na hoście bootc:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback zmienia kolejność w programie rozruchowym na poprzedni wpis, czyli obraz, który działał godzinę temu, wraz z jądrem i przestrzenią użytkownika. Nic nie jest pobierane ani przebudowywane, ponieważ stary obraz nigdy nie został usunięty z dysku.

Fedora CoreOS robi to samo pod innymi nazwami:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Najpierw należy zatrzymać Zincati. Zincati to agent, który utrzymuje maszynę Fedora CoreOS na najnowszej wersji, więc jeśli pozostanie uruchomiony, przygotuje aktualizację, z której właśnie zrezygnowano. -r wykonuje restart po przygotowaniu wycofania zmian. Aby zapobiec usunięciu zaufanego wdrożenia przez mechanizm garbage collection:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status wyświetla listę wdrożeń w kolejności, w jakiej oferuje je program rozruchowy, oznacza uruchomione wdrożenie kropką i pokazuje Pinned: yes przy tym, które zostało przypięte.

Talos realizuje to za pomocą jednego wywołania API ze stacji roboczej:

talosctl rollback --nodes 10.20.30.40

Flatcar utrzymuje dwie partycje /usr i przełącza się między nimi. Każdy slot posiada priorytet oraz licznik prób w tablicy partycji, więc slot, który nigdy nie uruchomi się poprawnie, wyczerpuje liczbę prób, a program rozruchowy wybiera drugi. Należy sprawdzić, w którym slocie znajduje się system i czy został on oznaczony jako poprawny:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Poprawnie działający slot wyświetla linię zawierającą priority=1 tries=0 successful=1. Brak pasującej linii oznacza, że bieżący slot nigdy nie został potwierdzony, co jest stanem, w jakim maszyna znajduje się pomiędzy aktualizacją a pierwszym poprawnym rozruchem.

Co zastępuje „instalację pakietu”: bootc i Containerfile

bootc to narzędzie, które uogólnia ten wzorzec. Opisuje się jako transakcyjne, wykonywane w miejscu aktualizacje systemu operacyjnego przy użyciu obrazów kontenerów OCI (Open Container Initiative) i jest projektem CNCF Sandbox. Serwer staje się plikiem Containerfile. Według stanu na sierpień 2026 obraz bazowy Fedora to quay.io/fedora/fedora-bootc:44, a obraz bazowy CentOS Stream to quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

Buduj i wypychaj obraz tak samo, jak każdy inny:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Następnie na serwerze:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade odpytuje źródło obrazu i kolejkuje nowy obraz do następnego uruchomienia. --check informuje, czy dostępna jest aktualizacja, nie wprowadzając żadnych zmian. --apply wykonuje restart do nowej wersji. bootc switch registry.example.com/edge/web:next wskazuje maszynie inny obraz, zachowując /etc oraz /var, co pozwala na przenoszenie serwera między strumieniami obrazów bez konieczności reinstalacji.

W celu automatyzacji aktualizacji należy włączyć timer dostarczany przez projekt:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Jest to odpowiedź trybu obrazowego na automatyczne aktualizacje w Ubuntu oraz na dnf-automatic w systemach Rocky i Alma. Różnica polega na tym, co trafia do systemu. Timer w trybie pakietowym stosuje wersje dostępne w repozytorium w danej nocy, więc wynikowy zestaw oprogramowania jest nieco inny na każdej maszynie. Timer w trybie obrazowym stosuje jeden artefakt, który został już przetestowany w innym miejscu.

Z tego pliku Containerfile wynikają dwie zasady budowania. Dane zapisywalne powinny znajdować się w /var, więc oprogramowanie, które wymaga zapisu we własnym katalogu instalacyjnym, potrzebuje dowiązania symbolicznego lub linii BindPaths= w systemd dodanej na etapie budowania. Ponadto /etc jest scalane trójstronnie podczas aktualizacji, co oznacza, że plik, który nigdy nie był modyfikowany, otrzymuje nową wersję z obrazu, podczas gdy plik edytowany lokalnie zostaje zachowany.

Gdy potrzebne jest narzędzie na działającej maszynie do jednorazowej sesji debugowania:

sudo bootc usr-overlay
sudo dnf -y install strace

To polecenie dodaje tymczasową, zapisywalną nakładkę na /usr, która jest usuwana przy następnym restarcie. Służy to do analizy problemu, a nie do jego naprawy. W ten sposób nie można zmienić jądra systemu, a wszystko, co zostanie zainstalowane, zgodnie z założeniem znika po restarcie.

Fedora CoreOS: jednorazowa konfiguracja, ciągłe aktualizacje

Fedora CoreOS nie posiada interaktywnego instalatora. Należy przygotować plik Butane YAML, przekonwertować go do formatu Ignition JSON i przekazać maszynie podczas pierwszego uruchomienia:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition działa w initramfs wyłącznie podczas pierwszego rozruchu. Jest to punkt krytyczny dla osób przechodzących z cloud-init. Jeśli konfiguracja nie zawiera klucza SSH, maszyna uruchomi się bez możliwości zdalnego dostępu, a jedynym rozwiązaniem jest ponowna instalacja od zera. Przetestuj konfigurację na maszynie testowej, zanim zastosujesz ją na serwerze produkcyjnym.

Instalacja na dysku ze środowiska live:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Aktualizacje są domyślnie automatyczne. Użytkownik decyduje o czasie ich przeprowadzania, a nie o samym fakcie ich wystąpienia. Utwórz plik TOML w /etc/zincati/config.d/55-updates-strategy.toml, aby wybrać strategię okresową:

[updates]
strategy = "periodic"

W ramach tej strategii dodaje się jedno okno serwisowe na wpis w tablicy, gdzie każde okno rozpoczyna się od nazwy updates.periodic.window umieszczonej w podwójnych nawiasach kwadratowych jako nagłówek, a po nim następują trzy klucze:

• days, lista nazw dni, takich jak "Sat" oraz "Sun".
• start_time, moment otwarcia okna, zapisany jako "22:30".
• length_minutes, czas trwania okna, na przykład 60.

Podane czasy są w formacie UTC. Aby całkowicie zatrzymać aktualizacje, wykonaj sudo systemctl disable --now zincati.service i zaakceptuj fakt, że od tego momentu samodzielnie odpowiadasz za harmonogram poprawek.

Warstwowanie pakietów (package layering) stanowi rozwiązanie awaryjne:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Polecenie to tworzy nowe wdrożenie z dodanym pakietem, a zmiana wchodzi w życie dopiero po restarcie. Koszt tego rozwiązania pojawia się później. Warstwa użytkownika jest nakładana na każdy nowy obraz bazowy, więc pakiet, który zniknął z repozytorium w dniu aktualizacji, spowoduje niepowodzenie całego procesu. Dokumentacja Fedora zaleca stosowanie kontenerów dla wszelkich istotnych usług oraz obrazów typu bootc w sytuacjach, gdy konieczna jest rzeczywista modyfikacja systemu operacyjnego.

Flatcar Container Linux: brak menedżera pakietów

Flatcar jest kontynuacją CoreOS Container Linux i najbardziej rygorystyczną z opcji ogólnego przeznaczenia. System nie posiada menedżera pakietów, na którym można by polegać. Wszystko, co uruchamiasz, działa jako kontener. Inicjalizacja odbywa się za pomocą Ignition, podobnie jak w Fedora CoreOS. Aktualizacje realizowane są poprzez dwie partycje A/B /usr opisane powyżej, sterowane przez update_engine, przy czym locksmithd decyduje o momencie wykonania restartu.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT oznacza, że pasywna partycja zawiera już nowy obraz i oczekuje jedynie na restart. Domyślną strategią restartu jest reboot z pięciominutowym opóźnieniem, więc pojedynczy produkcyjny VPS zrestartuje się zgodnie z własnym harmonogramem, chyba że skonfigurujesz inaczej. Ustaw okno czasowe w /etc/flatcar/update.conf:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off pozostawia decyzję o restarcie użytkownikowi. SERVER=disabled w tym samym pliku całkowicie zatrzymuje sprawdzanie aktualizacji. W przypadku klastra, REBOOT_STRATEGY=etcd-lock w połączeniu z locksmithctl set-max 4 ogranicza liczbę węzłów, które mogą zrestartować się jednocześnie, dzięki czemu aktualizacja nigdy nie wyłączy całej floty w tym samym czasie.

Talos Linux: brak powłoki, brak SSH, brak konsoli

Talos jest najbardziej wyspecjalizowanym z czterech rozwiązań i ma najściślej określone przeznaczenie. Służy do uruchamiania węzłów Kubernetes. System nie posiada demona SSH, powłoki ani możliwości logowania przez konsolę. Każda operacja jest wywołaniem API gRPC, wykonywanym za pomocą talosctl ze stacji roboczej, w oparciu o konfigurację maszyny przechowywaną w git.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

Zastąp znacznik wersją wydania, na którą przeprowadzasz migrację. Aktualizacja wykorzystuje schemat A-B, który zachowuje poprzednie jądro oraz obraz systemu operacyjnego. Dzięki temu, jeśli nowa wersja nie uruchomi się, Talos automatycznie przywróci poprzednią konfigurację bez ingerencji użytkownika. Debugowanie wygląda inaczej, ponieważ brak jest powłoki: zamiast journalctl na maszynie, używa się talosctl logs oraz talosctl dmesg.

Jeśli Twoje obciążenie nie jest związane z Kubernetes, Talos nie jest właściwym rozwiązaniem. Jeśli jednak jest, Talos eliminuje całą kategorię incydentów, ponieważ sytuacja, w której "ktoś zalogował się na węzeł i wprowadził zmiany", nie ma prawa zaistnieć.

Z czego faktycznie rezygnuje użytkownik VPS

Instalacje ad-hoc na działającym systemie. To najważniejsza kwestia. sudo apt install htop o 2 nad ranem podczas awarii nie jest dostępne. W systemie bootc otrzymuje się tymczasową nakładkę, która znika po restarcie. W Fedora CoreOS stosuje się warstwowe wdrażanie, które wymaga restartu. W Flatcar i Talos nie otrzymuje się niczego.

Potok budowania, którego wcześniej nie było. Dodanie pakietu oznacza edycję pliku Containerfile, zbudowanie obrazu, wypchnięcie go do rejestru i zaktualizowanie serwerów. Jest to tanie, gdy potok już istnieje. Stworzenie go od podstaw to realna praca, która wymaga rejestru dostępnego dla serwerów, co stanowi kolejną usługę do utrzymania lub kolejny koszt.

Moduły jądra. Jądro pochodzi z obrazu, więc moduł skompilowany dla działającego jądra nie przetrwa kolejnej aktualizacji. Moduły spoza drzewa źródeł jądra oraz pakiety DKMS (dynamic kernel module support) muszą być wbudowane w obraz, w oparciu o jądro tego obrazu. Wszystko, co wymaga modułu nieobecnego w obrazie bazowym, staje się problemem budowania, a nie instalacji.

Agenci dostawców i producentów. Agenci monitoringu i kopii zapasowych są zazwyczaj dostarczani jako .deb lub .rpm ze skryptem instalacyjnym, który zapisuje dane w /usr i aktywuje jednostkę systemd. W systemie z systemem plików tylko do odczytu taki skrypt kończy się niepowodzeniem. Niektórzy dostawcy publikują kontenery lub dokumentują instalację w trybie obrazu. Wielu tego nie robi. Sprawdź to przed podjęciem decyzji, ponieważ flota, której nie można monitorować, jest gorsza niż flota, w której występuje dryf konfiguracji.

Sam obraz. Prawie żaden panel sterowania VPS nie wymienia Fedora CoreOS, Flatcar czy Talos obok Ubuntu i Debian. Użytkownik musi dostarczyć własny dysk, co jest tematem kolejnej sekcji.

Instalacja systemu na wynajętym serwerze VPS

Najpierw należy potwierdzić dwie kwestie u dostawcy: dostęp do konsoli poza pasmem (out-of-band), czyli VNC lub konsoli szeregowej, oraz możliwość uruchomienia systemu ratunkowego. Bez dostępu do konsoli, maszyna, która nie wstanie po restarcie, wymaga zgłoszenia do pomocy technicznej zamiast pięciominutowej naprawy.

Jeśli dostawca akceptuje własne obrazy, należy przesłać obraz typu raw lub qcow2 dostarczony przez producenta, co kończy proces. W przeciwnym razie należy zapisać obraz na dysku z poziomu systemu ratunkowego. Flatcar zawiera gotowy skrypt do tego celu, który można uruchomić z dowolnego systemu Linux:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Skrypt należy uruchomić z poziomu systemu ratunkowego, nigdy z serwera, który jest zastępowany, ponieważ skrypt partycjonuje urządzenie docelowe w trakcie pracy. Wymagane jest co najmniej 8 GB dostępnego miejsca na urządzeniu, a środowisko ratunkowe musi udostępniać bash, bzip2 lub lbzip2, lsblk, wget, udevadm, gpg oraz gawk. Plik ignition.json musi zawierać klucz SSH, w przeciwnym razie dostęp do zainstalowanego systemu będzie niemożliwy.

Fedora CoreOS działa w podobny sposób, a jej instalator uruchamia się jako kontener:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Przed uruchomieniem należy sprawdzić nazwę urządzenia za pomocą lsblk. Zapis na niewłaściwym urządzeniu powoduje bezpowrotną utratę danych bez wyświetlenia monitu o potwierdzenie.

Narzędzie bootc oferuje ścieżkę pozwalającą pominąć tryb ratunkowy, ponieważ dokonuje konwersji działającego systemu Linux w miejscu:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Przed uruchomieniem należy zapoznać się z dokumentacją używanego obrazu bazowego i przetestować proces na serwerze, który można bez obaw usunąć. Po restarcie maszyna uruchamia obraz, a poprzedni zestaw pakietów zostaje usunięty.

Kto powinien korzystać z niezmiennych serwerów, a kto nie

To rozwiązanie jest wskazane, gdy serwery traktuje się jak bydło (cattle). Wiele maszyn tworzonych według jednego przepisu. Agenty CI (continuous integration), które działają przez godzinę. Węzły k3s lub Kubernetes, które są wymieniane, a nie naprawiane. Każdy przypadek, w którym rozwiązaniem problemu z uszkodzoną maszyną jest jej usunięcie i stworzenie nowej. Opłaca się to również wtedy, gdy należy udowodnić audytorowi, co działa na maszynie, ponieważ odpowiedzią jest skrót obrazu (image digest), a nie lista pakietów.

To rozwiązanie nie jest wskazane, jeśli utrzymujesz jeden ręcznie zarządzany VPS z trzema usługami, instalujesz oprogramowanie w miarę potrzeb i nie posiadasz potoku budowania (build pipeline). Tryb obrazu nie eliminuje pracy. Przenosi ją z serwera do procesu budowania i wymaga posiadania rejestru oraz potoku. Jeśli masz gdzie przenieść tę pracę, zyskujesz identyczne serwery i możliwość wycofania zmian poprzez restart. Jeśli nie, dodajesz ruchome elementy do maszyny, która działała poprawnie, co utrudnia rozwiązywanie awarii w nocy.

Nudne, pośrednie rozwiązanie nadal działa: standardowa dystrybucja z automatycznymi aktualizacjami bezpieczeństwa oraz procedura przebudowy, którą faktycznie przećwiczono. Wybór podstawy systemu to osobna decyzja, omówiona w wybór systemu operacyjnego dla VPS. Tryb obrazu to tylko najnowsza odsłona bardzo starego sporu o to, jak oprogramowanie powinno trafiać na maszynę, a historia dystrybucji Linux to w dużej mierze powtarzający się ten sam spór.

FAQ

Czy niezmienna dystrybucja Linux jest rzeczywiście niezmienna?

Nie, a sama nazwa wprowadza w błąd. Użytkownik root nadal może zapisywać dane na dysku. W rzeczywistości /usr jest montowany w trybie tylko do odczytu podczas działania systemu i zastępowany w całości przez nowy obraz, podczas gdy /etc oraz /var pozostają zapisywalne i zachowują dane po aktualizacjach. Zmiany wprowadzone w /usr są odrzucane w momencie próby zapisu lub usuwane przy kolejnej aktualizacji, więc w praktyce katalogi systemowe zmieniają się tylko wtedy, gdy zmienia się obraz.

Czy mogę uruchomić Fedora CoreOS lub Flatcar na VPS, który ich nie oferuje?

Zazwyczaj tak, jeśli dostawca zapewnia system ratunkowy i dostęp do konsoli. Należy uruchomić system ratunkowy, zapisać obraz dysku dystrybucji na urządzeniu blokowym, a następnie zrestartować maszynę. Skrypt flatcar-install systemu Flatcar wykonuje to z poziomu dowolnego systemu Linux, a Fedora CoreOS udostępnia coreos-installer jako kontener, który można uruchomić w ten sam sposób. Oba systemy wymagają pliku Ignition zawierającego klucz SSH, ponieważ nie ma możliwości ustawienia hasła przy pierwszym uruchomieniu. Bez dostępu do konsoli nie należy podejmować prób: maszyna, która nie wróci do stanu pracy, nie pozwoli na zdiagnozowanie przyczyny.

Jak zainstalować pakiet na niezmiennym serwerze?

Należy dodać go do obrazu i wdrożyć ponownie. W przypadku bootc jest to linia RUN dnf -y install ... w pliku Containerfile, przebudowanie obrazu, wypchnięcie go do rejestru, a następnie wykonanie sudo bootc upgrade --apply na maszynie. W Fedora CoreOS można nałożyć pakiet za pomocą sudo rpm-ostree install i zrestartować system, co wiąże się z koniecznością ponownego nakładania pakietu przy każdej przyszłej aktualizacji. W systemach Flatcar i Talos nie ma menedżera pakietów, więc jedynym rozwiązaniem jest kontener. W przypadku jednorazowego narzędzia diagnostycznego na hoście bootc, sudo bootc usr-overlay zapewnia zapisywalny katalog /usr, który znika po kolejnym restarcie.

Czy tryb obrazu naprawia VPS, który nie uruchamia się po aktualizacji jądra?

Zmienia to proces odzyskiwania z pracy w konsoli ratunkowej na zwykły restart. Poprzedni obraz, zawierający jądro i przestrzeń użytkownika, nadal znajduje się na dysku, więc sudo bootc rollback lub sudo rpm-ostree rollback -r pozwala na powrót do niego. Systemy Talos i Flatcar idą o krok dalej i wycofują zmiany automatycznie, gdy nowy slot nie uruchomi się poprawnie, ponieważ wpis rozruchowy staje się domyślnym dopiero po jednym udanym uruchomieniu. Żadne z tych rozwiązań nie zapobiega błędnej aktualizacji. Sprawia jedynie, że jej wycofanie jest tanie i szybkie.

Którą niezmienną dystrybucję wybrać na serwer?

Wybierz bootc, jeśli potrzebujesz uniwersalnego serwera Linux, który budujesz jak obraz kontenera i możesz zainstalować na posiadanej maszynie. Wybierz Fedora CoreOS, jeśli oczekujesz tego modelu z gotowym procesem budowania i automatycznymi aktualizacjami. Wybierz Flatcar, jeśli potrzebujesz minimalnego hosta kontenerów ze schematem aktualizacji A/B i brakiem menedżera pakietów. Wybierz Talos tylko wtedy, gdy maszyna ma być węzłem Kubernetes, ponieważ system ten nie posiada powłoki i nie uruchamia żadnych innych usług.