Migracja z Docker Swarm do Kubernetes nie jest podmianą narzędzia, a zmianą modelu obiektów, więc plan wdrożenia porządkuje się wokół etapów rozstrzygnięć, nie wokół instalacji. Kolejność jest stała: odwzorowanie pojęć, wybór klastra, pamięć trwała i sieć, przeniesienie ruchu, a na końcu wycofanie starego środowiska.
Na skróty
Czego dowiesz się z artykułu:
- Które pojęcia Swarma odwzorowują się wprost, a które wymagają rozstrzygnięcia parametrów
- Dlaczego decyzja o klastrze zarządzanym jest decyzją menedżerską, nie techniczną
- Co w migracji kosztuje najwięcej pracy i dlaczego to nie jest konfiguracja
- Jakie role muszą istnieć po stronie zespołu, żeby klaster przetrwał pierwszy kwartał
Dla kogo jest ten artykuł:
- Menedżerowie zespołów utrzymujących usługi w kontenerach
- Liderzy techniczni planujący odejście od Swarma przed końcem jego użyteczności
- Osoby odpowiadające za budżet i obsadę po stronie platformy
Czas czytania: 7 minut
Etap pierwszy: odwzorowanie pojęć
Swarm opisuje wdrożenie jedną warstwą: usługa ma obraz, liczbę replik i sieć nakładkową, a plik stosu trzyma to razem. Kubernetes rozkłada tę samą rzecz na osobne obiekty i właśnie ten rozkład jest treścią migracji: Pod jest najmniejszą jednostką uruchomieniową, Deployment zarządza zbiorem identycznych podów i ich wymianą, Service nadaje im stały adres, a Ingress wpuszcza ruch z zewnątrz. Dokumentacja cloud.google.com o obiektach Service opisuje trzeci z tych obiektów wprost: Service grupuje punkty końcowe podów za jednym stabilnym adresem IP, więc aplikacja wołająca nie musi wiedzieć, gdzie stoi druga.
Praktyczna konsekwencja dla menedżera jest kosztowa, nie estetyczna. Pojedyncza usługa Swarma rozpada się na kilka zasobów, z których każdy ma własny plik, własną wersję grupy API (apps/v1 dla obiektu Deployment) i własnego recenzenta zmian. Zespół, który dotąd utrzymywał pojedynczy plik stosu na usługę, zaczyna utrzymywać katalog manifestów — i to jest moment, w którym warto od razu wprowadzić szablonowanie.
Dokumentacja helm.sh opisuje chart jako pakiet zasobów Kubernetes opisany szablonami i wartościami. Rozstrzygnięcie na starcie jest jedno: albo wszystkie usługi dostają wspólny chart z wartościami per usługa, albo każda dostaje własny zestaw manifestów. Pierwsze kosztuje więcej w pierwszym tygodniu, drugie kosztuje więcej przy każdej kolejnej usłudze.
Pojęcia, których odwzorowanie nie jest mechaniczne, trzeba nazwać wprost, bo właśnie one zatrzymują migracje w połowie. Odpowiednik ma każde z nich: tryb globalny usługi to DaemonSet, ograniczenia rozmieszczenia po etykietach węzłów to nodeSelector oraz bardziej wyrazisty nodeAffinity, aktualizacja krocząca to strategy.type: RollingUpdate z parametrami maxUnavailable i maxSurge w strategy.rollingUpdate, a sekret to obiekt Secret montowany jako plik albo zmienna środowiskowa. Praca nie polega więc na szukaniu zamiennika, a na rozstrzygnięciu parametrów, których Swarm nie wymagał — i to one wypełniają harmonogram.
Etap drugi: klaster zarządzany czy własny
To decyzja menedżerska, bo rozstrzyga o obsadzie, nie o technologii. Opis cloud.google.com dla usługi zarządzanej nazywa granicę: dostawca prowadzi warstwę sterowania klastra, a zespół odpowiada za obciążenia i ich konfigurację. Przy klastrze własnym ta warstwa — serwer API, baza stanu klastra, kontrolery — wraca do zespołu razem z jej aktualizacjami.
Pytanie do odhaczenia na tym etapie brzmi: kto u nas aktualizuje warstwę sterowania i co się dzieje, gdy ta osoba jest na urlopie. Jeśli odpowiedź nie ma imienia, klaster zarządzany jest tańszy niż własny, niezależnie od zestawienia cen maszyn.
Strona projektu w www.cncf.io jest tu przydatna z innego powodu: Kubernetes jest w tej fundacji projektem o statusie ukończonym (graduated), a wokół niego działa ekosystem narzędzi tej samej fundacji. Dla menedżera to argument na stabilność interfejsów i na dostępność narzędzi, nie na wybór dostawcy. Z samego statusu projektu nie wynika natomiast, że po tej migracji nie będzie następnych w warstwach wyżej — ekosystem zmienia się szybciej niż rdzeń.
Etap trzeci: pamięć trwała, sieć i to, co boli
Usługi bezstanowe przenoszą się szybko. Koszt siedzi w pozostałych: baza, kolejka, cokolwiek, co zapisuje na dysk. W Kubernetes obsługują je inne obiekty niż zwykły Deployment — zbiór stanowy z trwałą tożsamością podów oraz żądanie wolumenu trwałego. Migracja danych jest osobnym projektem z własnym planem wycofania i nie wolno jej doklejać do etapu przenoszenia usług.
Sieć jest drugim miejscem, w którym Swarm i Kubernetes rozchodzą się najmocniej. Sieć nakładkowa Swarma dawała usługom płaską widoczność; w Kubernetes ruch wewnętrzny opisują obiekty Service, a wejście z zewnątrz historycznie Ingress razem z kontrolerem, który go obsługuje.
Tu jest rozstrzygnięcie, którego nie warto odkładać. Dokumentacja cloud.google.com wskazuje dziś Gateway API jako zalecaną ścieżkę wystawiania aplikacji HTTP i prowadzi osobny opis migracji z Ingress; model rozdziela role na GatewayClass utrzymywany przez dostawcę, Gateway tworzony przez operatora klastra i HTTPRoute tworzony przez zespół aplikacyjny. Migracja planowana teraz powinna wybierać wejście ruchu z tym rozróżnieniem, a nie wyłącznie przez kontroler Ingress — inaczej kupuje sobie drugą migrację w warstwie wejścia.
Kolejność tego etapu jest nienegocjowalna: najpierw pojedyncza usługa bezstanowa przeniesiona do końca, z ruchem produkcyjnym, potem reszta bezstanowych, a stanowe na końcu. Migracja zaczęta od bazy danych nie powie nic o tym, czy metoda się skaluje, i zablokuje zespół na najtrudniejszym elemencie.
Etap czwarty: role i wycofanie Swarma
Klaster bez nazwanego właściciela platformy degraduje się cicho: wersje się rozchodzą, manifesty zaczynają żyć na laptopach, a przegląd uprawnień nie ma adresata. Właściciel platformy odpowiada za wersję klastra i za standard manifestów. Inżynier dyżurny potrzebuje opisanej ścieżki diagnostycznej, bo kubectl describe pod pokazuje inne rzeczy niż docker service ps i w pierwszych tygodniach to kosztuje czas. Lider zespołu rozstrzyga kolejność migracji usług, bo to on zna zależności biznesowe, a nie klaster.
Wycofanie Swarma jest ostatnim krokiem i ma własne kryterium: środowisko wyłącza się dopiero wtedy, gdy przez ustalony okres żadna usługa nie wróciła na nie awaryjnie. Utrzymywanie obu środowisk „na chwilę” jest najdroższym stanem całej migracji, więc ten warunek warto zapisać przed startem, a nie ustalać w trakcie.
Czytaj także
- Kubernetes vs Docker Swarm — porównanie orkiestratorów — decyzja o samej zmianie, zanim powstanie plan migracji
- Wdrożenie klastra Kubernetes w środowisku produkcyjnym — kompletny przewodnik — warstwa, na którą przenosisz usługi
- Zarządzanie wdrożeniami przez Helm charts: od czego zacząć, gdy zaczynasz od zera — czym zastąpić pliki compose, kiedy usługa stoi już na nowym klastrze
Rozwijaj kompetencje
Temat rozwijają szkolenia Docker i Kubernetes oraz Kubernetes — od podstaw do zaawansowanych technik. Pierwsze porządkuje relację między obrazem, kontenerem i orkiestracją, drugie wchodzi w obiekty klastra i ich konfigurację. Skontaktuj się z nami, żeby dopasować zakres do stanu Waszego środowiska.
Najczęściej zadawane pytania (FAQ)
Czy Docker Swarm trzeba porzucić, jeśli działa?
Nie z powodu awarii, a z powodu ekosystemu. Swarm nadal uruchamia kontenery, ale narzędzia do wdrażania, obserwowalności i polityk bezpieczeństwa powstają dziś dla Kubernetes. Argumentem za migracją jest więc dostępność narzędzi i ludzi, którzy je znają, a nie wada samego Swarma — i tak warto ją uzasadniać przed zarządem.
Ile usług przenieść w pierwszym podejściu?
Jedną, bezstanową, z ruchem produkcyjnym do końca. Pilotaż bez ruchu produkcyjnego nie sprawdza niczego, co kosztuje: ani certyfikatów, ani nagłówków, ani dyżuru. Druga usługa jest właściwym miernikiem — jeśli kosztuje tyle samo co pierwsza, zespół nie zbudował szablonu i warto wrócić do tego kroku.
Czy do migracji potrzebny jest oddzielny zespół platformowy?
Nie od pierwszego dnia, ale potrzebna jest nazwana rola właściciela platformy z wydzielonym czasem. Migracja prowadzona wyłącznie w nadgodzinach zespołu produktowego zatrzymuje się na usługach stanowych, bo to one wymagają nieprzerwanej uwagi. Rola może być pełniona rotacyjnie, byle miała zapisany zakres odpowiedzialności.
Co zrobić z plikami stosu, które opisują obecne środowisko?
Traktować jako specyfikację wejściową, nie jako źródło do konwersji automatycznej. Narzędzia konwertujące pliki stosu na manifesty dają punkt startowy, ale te elementy, które trzeba rozstrzygnąć świadomie, odwzorowują częściowo albo upraszczają: sekrety, ograniczenia rozmieszczenia i parametry strategii aktualizacji. Konwersja oszczędza pisanie, nie myślenie.