Niezmienne dystrybucje Linux na serwerze: przegląd

Czym jest niezmienna dystrybucja Linux

Niezmienna dystrybucja Linux dostarcza system operacyjny jako pojedynczy obraz, co oznacza zastępowanie systemu zamiast jego aktualizacji w miejscu. Nie ma tu miejsca na apt upgrade nadpisywanie plików w /usr na działającej maszynie. Nowy obraz jest budowany lub pobierany, a maszyna przygotowuje go obok aktualnie uruchomionego systemu. Kolejny restart przełącza aktywną wersję. Poprzedni obraz pozostaje na dysku, więc wycofanie nieudanej aktualizacji sprowadza się do ponownego uruchomienia.

Termin "niezmienny" jest pewnym nadużyciem. Nic fizycznie nie powstrzymuje użytkownika root przed zapisem na dysku. Systemy te działają poprzez montowanie katalogów systemowych w trybie tylko do odczytu i przypisywanie ich własności do obrazu. Dane trwałe znajdują się 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 generuje 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 2 lata posiada historię, której nikt nie udokumentował. make install z pośpiesznego wieczoru. Repozytorium zewnętrznej firmy 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 często skutkuje maszyną zachowującą się inaczej. Notatki zawierają zamierzenia. Dysk zawiera prawdę.

Tryb obrazu (image mode) eliminuje 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 regularna lista kontrolna konserwacji serwera Linux rozwiązuje za pomocą dyscypliny, tutaj obsługiwany bezpośrednio przez system plików.

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

Awaria, dla której zaprojektowano ten model, jest już przez nas udokumentowana: 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ż bootloader przechowuje starsze wersje jąder, jednak tylko jądro jest wersjonowane w ten sposób. Aktualizacja glibc oraz zmiany w systemd, które pojawiły się w tej samej transakcji, zostały już zastosowane i żadne pojedyncze polecenie nie wycofa ich wszystkich 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 bootloaderze 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 opuścił 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 utrzymujący maszynę Fedora CoreOS na najnowszym wydaniu, 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 wdrożenia, któremu ufasz:

sudo ostree admin pin 0
rpm-ostree status

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

Talos wykonuje 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 bootloader wybiera drugi. Sprawdź, w którym slocie się znajdujesz 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; jest to stan, w którym maszyna znajduje się pomiędzy aktualizacją a pierwszym poprawnym uruchomieniem.

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

bootc to narzędzie, które uogólnia ten wzorzec. Opisuje się jako rozwiązanie do transakcyjnych aktualizacji systemu operacyjnego w miejscu przy użyciu obrazów kontenerowych 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.

Aby włączyć automatyczne aktualizacje, aktywuj timer dostarczany przez projekt:

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

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

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

Jeśli potrzebujesz narzędzia na działającym systemie do jednorazowej sesji debugowania:

sudo bootc usr-overlay
sudo dnf -y install strace

Polecenie to dodaje tymczasową, zapisywalną nakładkę na /usr, która jest usuwana przy następnym restarcie. Służy to do diagnozowania 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 inicjalizacja, ciągłe aktualizacje

Fedora CoreOS nie posiada interaktywnego instalatora. Należy przygotować plik Butane w formacie YAML, przetłumaczyć go na format 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 inicjalizacja systemu od zera. Konfigurację należy przetestować na maszynie testowej przed zastosowaniem jej na serwerze produkcyjnym.

Instalacja na dysku z poziomu ś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ępowania. Należy umieścić 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 każdy wpis w tablicy, gdzie każde okno rozpoczyna się od nazwy updates.periodic.window umieszczonej w podwójnych nawiasach kwadratowych jako nagłówek, po którym 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, należy wykonać sudo systemctl disable --now zincati.service, biorąc tym samym pełną odpowiedzialność za harmonogram poprawek.

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

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

Operacja ta tworzy nowe wdrożenie z dodanym pakietem, a zmiana staje się aktywna dopiero po restarcie. Koszt tego rozwiązania ujawnia się później. Zestaw warstwowy jest nakładany na każdy nowy obraz bazowy, więc pakiet, który zniknął z repozytorium w dniu aktualizacji, spowoduje jej niepowodzenie. Dokumentacja Fedora zaleca stosowanie kontenerów dla wszelkich istotnych zadań oraz obrazów 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 ogólnodostępnych opcji. System nie posiada menedżera pakietów, na którym można by polegać. Wszystkie uruchamiane elementy są kontenerami. 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. Okno czasowe ustawia się 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 wyłącza 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 spowoduje wyłączenia całej infrastruktury.

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

Talos jest najbardziej wyspecjalizowanym z czterech rozwiązań i ma jasno określony cel. Służy do uruchamiania węzłów Kubernetes. W systemie nie ma 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

Należy zastąpić znacznik wersją wydania, do której przeprowadzana jest migracja. Aktualizacja wykorzystuje schemat A-B, który zachowuje poprzednie jądro oraz obraz systemu operacyjnego. Jeśli nowy obraz nie uruchomi się, Talos automatycznie przywróci poprzednią wersję 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 obciążenie nie jest związane z Kubernetes, Talos nie jest właściwym wyborem. Jeśli jednak jest, Talos eliminuje całą kategorię incydentów, ponieważ sytuacja, w której "ktoś zalogował się na węzeł i wprowadził zmiany", jest niemożliwa do zaistnienia.

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:00 w nocy podczas awarii nie jest dostępny. W systemie bootc otrzymuje się tymczasową warstwę, która znika po restarcie. W Fedora CoreOS stosuje się warstwowe wdrażanie, które wymaga restartu. W Flatcar i Talos nie ma takiej możliwości.

Potok budowania, którego wcześniej nie było. Dodanie pakietu oznacza edycję Containerfile, zbudowanie obrazu, wypchnięcie go do rejestru i zaktualizowanie serwerów. Jest to tanie, gdy potok już istnieje. Wymaga jednak realnego nakładu pracy, jeśli go nie ma, a ponadto 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ł 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 usługodawców. Agenci monitoringu i kopii zapasowych zazwyczaj są 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 udostępniają kontenery lub dokumentują instalację w trybie obrazu. Wielu tego nie robi. Należy to sprawdzić 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 obraz dysku, co jest tematem kolejnej sekcji.

Instalacja systemu na wynajętym serwerze VPS

Przed rozpoczęciem należy potwierdzić dwie kwestie u dostawcy: dostęp do konsoli poza pasmem (VNC lub konsola szeregowa) oraz możliwość uruchomienia systemu ratunkowego. Bez dostępu do konsoli, serwer, który nie wstanie po zmianach, wymaga zgłoszenia do pomocy technicznej zamiast samodzielnej naprawy w pięć minut.

Jeśli dostawca akceptuje własne obrazy, należy przesłać obraz typu raw lub qcow2 dostarczony przez producenta. W przeciwnym razie należy samodzielnie zapisać obraz 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 wolnego 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ściwe urządzenie spowoduje bezpowrotną utratę danych, a instalator nie prosi o potwierdzenie.

bootc oferuje ścieżkę pozwalającą pominąć tryb ratunkowy, ponieważ konwertuje działający system 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 testowym. Po restarcie maszyna uruchomi się z nowego obrazu, a poprzedni zestaw pakietów zostanie 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ą zastępowane, a nie naprawiane. Każdy scenariusz, w którym odpowiedzią na awarię maszyny jest „usuń ją i stwórz nową”. 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 utrzymuje się jeden ręcznie zarządzany VPS z trzema usługami, instaluje się oprogramowanie w miarę potrzeb i nie posiada potoku budowania (build pipeline). Tryb obrazu nie eliminuje pracy. Przenosi ją z serwera do procesu budowania i wymaga utrzymywania rejestru oraz potoku. Jeśli istnieje miejsce na przeniesienie tej pracy, uzyskuje się identyczne serwery i możliwość wycofania zmian przez restart. W przeciwnym razie dodaje się ruchome elementy do działającej maszyny, co utrudnia rozwiązywanie problemów w nocy.

Nudne, pośrednie rozwiązanie nadal działa: standardowa dystrybucja z automatycznymi aktualizacjami bezpieczeństwa oraz przećwiczony proces przebudowy. 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 sposób dostarczania oprogramowania 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 aktualizacji. Zmiany wprowadzone w /usr są albo odrzucane w momencie próby zapisu, albo usuwane przy następnej aktualizacji, więc w praktyce katalogi systemowe zmieniają się tylko wraz z aktualizacją obrazu.

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 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 udostępnia zapisywalny katalog /usr, który znika po następnym restarcie.

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

Zmienia on 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. Talos i Flatcar idą o krok dalej i wycofują zmiany automatycznie, gdy nowa partycja nie uruchamia 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 z mechanizmem aktualizacji A/B i brakiem menedżera pakietów, co zapobiega niepożądanym modyfikacjom. 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.