Kontener czy maszyna wirtualna: różnica w jednym zdaniu i jej cztery skutki

Masz uruchomić na Proxmoksie coś nowego i są dwie opcje. Obie uruchamiają Linuksa, obie stoją obok siebie w panelu, obie wyglądają, jakby robiły to samo.

Wybór podejmuje się zwykle z przyzwyczajenia do zasobów: kontener jest lżejszy. To prawda, ale nie to powinno decydować.

Różnica mieści się w jednym zdaniu: maszyna wirtualna przynosi własne jądro, kontener używa jądra serwera. Wszystko, co musisz wiedzieć, wynika z tego zdania.

Skutek pierwszy: gdzie przebiega granica

Granicę maszyny wirtualnej rysuje sprzęt. Granicę kontenera rysuje jądro serwera.

To nie znaczy, że kontener jest słaby; to znaczy, gdzie przebiega granica. Jeśli wada oprogramowania w kontenerze chce dosięgnąć serwera, musi przejść przez własne jądro serwera. W maszynie wirtualnej musi przejść przez ścianę na poziomie sprzętu.

Praktyczne pytanie brzmi tak: na ile ufasz temu, co zamierzasz uruchomić? Dla usługi napisanej przez siebie albo używanej od lat kontener nadaje się doskonale. Dla czegoś pobranego i nie do końca rozumianego lepszym miejscem jest maszyna wirtualna.

Skutek drugi: nie wszystko uruchomi się w kontenerze

Nic, co potrzebuje własnego jądra, nie uruchomi się w kontenerze. Oprogramowanie chcące innej wersji jądra, narzędzie ładujące moduły jądra, system operacyjny inny niż Linux: wszystko to wymaga maszyny wirtualnej.

To nie jest kwestia upodobania, to bezpośredni skutek powyższego zdania. Skoro kontener używa jądra serwera, nie możesz żądać od niego zmiany tego jądra.

Skutek trzeci: konserwacja dotyka ich inaczej

To najmniej znany skutek i ten, który najłatwiej zaboli.

Gdy aktualizujesz silnik maszyn wirtualnych, działające maszyny nie są tym dotknięte. Nowy silnik obowiązuje maszyny uruchomione po tej aktualizacji. Noc serwisowa może więc przejść cicho nad twoimi działającymi maszynami.

Gdy aktualizujesz warstwę uruchomieniową kontenerów, działające kontenery mogą to odczuć, bo wszystkie dzielą tę warstwę. W trakcie aktualizacji współdzielona warstwa systemu plików może zostać przemontowana i wewnątrz kontenerów mogą pojawić się krótkie błędy dostępu.

To nie jest opinia produktu, to bezpośredni skutek tego samego jednego zdania: jeśli aktualizujesz coś współdzielonego, odczuwają to wszyscy, którzy to dzielą.

Skutek czwarty: swoboda przemieszczania

Maszynę wirtualną można przenieść na inny węzeł w trakcie działania. Kontenera nie: wyłącza się go, przenosi i uruchamia ponownie.

Jeśli więc praca, która nie znosi przerw, siedzi w kontenerze, ta praca zatrzyma się w noce serwisowe. To trzeba rozważyć przy decyzji o umieszczeniu.

Praktyczna reguła

Wybierz kontener, gdy uruchamiasz zwykłą usługę linuksową, którą mógłbyś równie dobrze uruchomić na serwerze, gdy jej ufasz i gdy zniesie krótką przerwę.

Wybierz maszynę wirtualną, gdy potrzebne jest własne jądro, gdy praca nie może zostać przerwana podczas konserwacji albo gdy nie do końca ufasz temu, co uruchamiasz.

Różnica w zasobach przychodzi po tych trzech sprawdzianach. To prawda, że kontener zużywa mniej pamięci, ale koszt kontenera stojącego w niewłaściwym miejscu jest wielokrotnie większy niż ta oszczędność.

Co robi Atlas

Atlas niesie to rozróżnienie nie jako hasło, tylko jako zachowanie.

W ocenie aktualizacji silnik maszyn wirtualnych i warstwa uruchomieniowa kontenerów są traktowane osobno. Gdy aktualizowany jest silnik maszyn wirtualnych, odpowiedź dla działających maszyn jest na poziomie informacyjnym: nie są tym dotknięte, nowy silnik obowiązuje uruchomione później. Gdy aktualizowana jest warstwa kontenerów, poziom podnosi się do ostrzeżenia i wypisany zostaje powód: współdzielona warstwa może zostać przemontowana, rozważ krótkie zatrzymanie krytycznych kontenerów.

To samo rozróżnienie pojawia się przy planowaniu migracji: dla kontenerów migracja w trakcie działania nie jest oferowana jako opcja, zamiast tego podawany jest łańcuch wyłącz, przenieś, uruchom.

Produkt nie przedstawia więc obu jako dwóch odmian tej samej rzeczy. Zachowują się różnie, więc opisywane są różnie.