W wielu organizacjach dyskusja o Kubernetes toczy się w kategoriach zastępowania: „migrujemy z maszyn wirtualnych na kontenery”. To fałszywa alternatywa. Klaster Kubernetes sam działa na maszynach wirtualnych, a spora część obciążeń w typowej firmie nie powinna trafić do kontenerów nigdy. Właściwe pytanie brzmi: które obciążenie gdzie, i według jakiego kryterium.
Co zostaje na Hyper-V
Kontrolery domeny. Active Directory wymaga stabilnej tożsamości maszyny, przewidywalnego adresu i pełnego systemu Windows. Nie ma powodu, by to konteneryzować, i nie ma wspieranego sposobu, by to zrobić dobrze.
Serwery aplikacji, które nikt nie będzie przebudowywał. Aplikacja z 2012 roku, działająca jako usługa Windows z konfiguracją w rejestrze, będzie działała na maszynie wirtualnej do końca swojego cyklu życia. Koszt jej konteneryzacji przewyższa korzyści, bo korzyści są żadne: aplikacja nie skaluje się, nie jest wydawana często i nie ma zespołu, który by z tego skorzystał.
Systemy z licencjami związanymi z maszyną. Część oprogramowania komercyjnego liczy licencje per host, per rdzeń fizyczny albo wiąże klucz z identyfikatorem sprzętowym. W kontenerze to komplikuje wszystko.
Usługi infrastrukturalne dla samego klastra. Rejestr obrazów, serwer Git, system CI, centralne logi. Można je uruchomić w klastrze, ale wtedy awaria klastra odbiera narzędzia potrzebne do jego naprawy. Przynajmniej jedna kopia tych usług powinna działać poza platformą, którą obsługuje.
Co idzie do Kubernetes
Aplikacje wydawane często. Jeśli zespół wdraża zmiany kilka razy w tygodniu, kontenery i deklaratywne wdrożenia oszczędzają czas przy każdym wydaniu. Przy jednym wydaniu na kwartał ta oszczędność nie istnieje.
Aplikacje bezstanowe i skalowalne poziomo. Interfejsy webowe, API, workery kolejek. To jest przypadek, do którego Kubernetes został zaprojektowany.
Nowe usługi wewnętrzne. Narzędzie napisane w tym roku przez własny zespół powinno od początku być budowane jako obraz i wdrażane z repozytorium. Tu nie ma kosztu migracji, jest tylko wybór platformy startowej.
Bazy danych, ale ostrożnie. Operatory baz danych dojrzały i failover działa. Wymaga to jednak zrozumienia, jak działa przechowywanie danych w klastrze, testów awarii i monitorowania replikacji. Baza danych, której nikt w zespole nie potrafi odzyskać ręcznie w kontenerze, jest bezpieczniejsza na maszynie wirtualnej.
Kryterium, które działa
Zamiast pytać „czy da się to skonteneryzować”, warto zadać trzy pytania:
- Jak często się to zmienia? Rzadko: maszyna wirtualna. Często: kontener.
- Kto to utrzymuje? Jeśli zespół zna Windows Server i nie zna Kubernetes, przeniesienie obciążenia do klastra nie poprawi jego dostępności, tylko ją obniży.
- Co się stanie, gdy platforma padnie? Jeśli obciążenie jest potrzebne do naprawy platformy, nie może na niej działać.
Współistnienie w praktyce
Obie platformy muszą się widzieć i nie mogą sobie przeszkadzać. Kilka zasad:
- Węzły klastra to zwykłe maszyny wirtualne na Hyper-V, z zarezerwowanymi zasobami, bez dynamicznej pamięci i z wyłączonymi punktami kontrolnymi, które psują etcd.
- Sieć klastra jest oddzielnym segmentem. Ruch między klasyczną siecią serwerową a usługami w klastrze przechodzi przez jasno określone punkty wejścia, nie przez adresy podów.
- Uwierzytelnianie w klastrze korzysta z tego samego katalogu tożsamości, co reszta środowiska. Osobne konta w Kubernetes to osobny problem do audytu.
- Kopie zapasowe obejmują oba światy: maszyny wirtualne przez narzędzia do wirtualizacji, stan klastra przez repozytorium i migawki wolumenów.
Podsumowanie
Hyper-V i Kubernetes rozwiązują różne problemy. Pierwsza platforma daje izolację i stabilność dla systemów, które mają działać latami bez zmian. Druga daje szybkość i powtarzalność dla systemów, które zmieniają się co tydzień. Środowisko, które ma oba typy obciążeń, potrzebuje obu platform, a decyzja o umiejscowieniu każdego obciążenia powinna wynikać z jego charakterystyki, nie z kierunku, w którym akurat zmierza branża.