Wsparcie techniczne Kubernetes w chmurze WebDisk

Blog WebDisk · kategoria: Chmura publiczna · czas czytania: ~7 minut

W skrócie:- Klaster Kubernetes najlepiej wygląda w dniu uruchomienia. Prawdziwa praca zaczyna się później: trzy wydania rocznie, kopie bazy etcd, monitoring, bezpieczeństwo i ktoś, kto odbierze alarm w nocy.- Dobre wsparcie techniczne to nie „pomoc, gdy coś przestanie działać”, lecz stały proces: aktualizacje, przetestowany backup, wgląd w to, co dzieje się w klastrze (obserwowalność) i jasne zasady reagowania.- W chmurze WebDisk uruchomisz zarządzany klaster Kubernetes (WebDisk K8s) albo zbudujesz własny na infrastrukturze IaaS – a w planowaniu migracji i konfiguracji pomoże nasz zespół. >Nie pracujesz z terminalem? Pomiń jedyny blok poleceń w artykule – cała reszta obywa się bez niego.

Kubernetes stał się standardem uruchamiania aplikacji zbudowanych z mikroserwisów – niewielkich, niezależnie wdrażanych usług – także w firmach, które wcale nie zaczynały „od chmury”. Typowy obraz w firmach, które rozwijają swoje oprogramowanie od lat, wygląda tak: część systemów działa na klasycznych maszynach wirtualnych, część w kontenerach Docker albo w Docker Swarm (starszym, prostszym sposobie uruchamiania kontenerów na wielu serwerach), a dopiero najnowsze projekty – w klastrze Kubernetes. Takie środowisko hybrydowe to nie zaległość do nadrobienia, tylko naturalny efekt kolejnych, rozsądnych decyzji podejmowanych przez lata.

Jest w tym jednak pułapka, o której mówi się rzadziej niż o samej migracji: klaster postawiony to nie to samo co klaster utrzymywany. Uruchomienie Kubernetes nigdy nie było prostsze; utrzymanie go w zdrowiu przez kolejne lata wciąż wymaga pracy, wiedzy i dyżurów. W tym artykule pokazujemy, na czym ta praca polega, co powinno obejmować dobre wsparcie techniczne Kubernetes i jak wygląda Kubernetes w chmurze WebDisk.

Tekst kierujemy zarówno do zespołów, które dopiero rozważają migrację, jak i do tych, które klaster już mają – i chcą uczciwie odpowiedzieć sobie na pytanie, kto właściwie go pilnuje.

Dlaczego postawienie klastra Kubernetes to dopiero początek?

Postawienie klastra to dziś kwestia godzin – instalatory i platformy chmurowe zdjęły z administratorów większość dawnej złożoności. Trudność przeniosła się gdzie indziej: do wszystkiego, co dzieje się po uruchomieniu. Cztery przykłady:

Cykl wydań. Kubernetes publikuje trzy wydania rocznie, a każde otrzymuje poprawki – w tym poprawki bezpieczeństwa – przez około 14 miesięcy. Klaster nieaktualizowany od roku z okładem wypada z tego okna, a nadrabianie zaległości nie jest jednym skokiem: wersje podnosi się po kolei, bez przeskakiwania.
Wycofywane API. Kolejne wydania usuwają przestarzałe interfejsy. Manifest wdrożeniowy, który działał bez zarzutu od dwóch lat, po aktualizacji może przestać się stosować – dlatego przegląd używanych API jest elementem każdej planowanej aktualizacji.
Certyfikaty. Komponenty klastra uwierzytelniają się nawzajem certyfikatami TLS o ograniczonej ważności – w typowych instalacjach to rok. Wygasły certyfikat warstwy zarządzającej (control plane) potrafi w jeden poranek odciąć administratorów od klastra.
etcd. To baza danych, w której klaster przechowuje cały swój stan: definicje wdrożeń, konfigurację, sekrety. Bez regularnej kopii etcd – i bez przetestowanego odtworzenia – poważna awaria control plane’u oznacza odbudowę klastra od zera.

Żaden z tych punktów nie jest egzotyczny; to zwykła, powtarzalna administracja. Pytanie brzmi tylko, czy ktoś w organizacji ma ją w obowiązkach – czy raczej dzieje się „przy okazji”, dopóki się dzieje.

Co powinno obejmować dobre wsparcie techniczne Kubernetes?

Gdy oceniasz ofertę wsparcia – zewnętrzną albo możliwości własnego zespołu – sprawdź, czy zamyka pięć obszarów:

Aktualizacje i cykl życia. Zaplanowane okna aktualizacji control plane’u i węzłów, przegląd wycofywanych API przed każdym podniesieniem wersji, pilnowanie ważności certyfikatów. Nuda – i właśnie dlatego to pierwsza rzecz, która wypada z kalendarza przeciążonego zespołu.
Backup i test odtworzenia. Regularna kopia etcd oraz – osobno – danych aplikacji na wolumenach. Kopia, której nikt nigdy nie odtworzył, to nie kopia, tylko nadzieja; zasady sensownego backupu opisaliśmy szerzej w artykule Backup w chmurze: fundament bezpieczeństwa IT.
Monitoring i alertowanie. Metryki control plane’u, węzłów i samych aplikacji oraz alerty, które docierają do dyżurnego – po stronie dostawcy albo po Twojej; to jeden z najczęściej pomijanych punktów umowy, więc ustalcie go zawczasu. Ważne jest też strojenie: system, który alarmuje bez powodu sto razy dziennie, uczy ludzi ignorowania alarmów.
Bezpieczeństwo. Kontrola dostępu oparta na rolach (RBAC – mechanizm Kubernetes rozstrzygający, kto może wykonać jaką operację), aktualizacje systemów na węzłach, skanowanie obrazów kontenerów pod kątem znanych podatności, polityki sieciowe między usługami. O tym, jak sami układamy warstwy zabezpieczeń naszej platformy, opowiadamy w artykule Stack bezpieczeństwa open source w WebDisk.
Reagowanie na incydenty. Ustalona ścieżka zgłoszeń, jasny podział odpowiedzialności między dostawcą a klientem i procedury na scenariusze awaryjne – spisane, zanim będą potrzebne.

Jeśli chcesz szybko sprawdzić kondycję własnego klastra, zacznij od trzech poleceń:

# jaka wersja serwera API — porównaj ją z kalendarzem wydań Kubernetes (poprawki ~14 miesięcy)
kubectl version

# zdrowie węzłów i spójność ich wersji
kubectl get nodes -o wide

# ostrzeżenia z całego klastra
kubectl get events -A --field-selector type=Warning

I jedno pytanie, na które nie odpowie żadne polecenie: kiedy ostatnio ktoś odtworzył kopię etcd w środowisku testowym? Jeśli odpowiedź brzmi „nigdy” – to jest pierwszy punkt na listę zadań, jeszcze przed rozmową o rozbudowie klastra.

Migracja to proces, nie przeprowadzka w weekend

Dobre wsparcie zaczyna się zresztą przed powstaniem klastra. Migracja do Kubernetes rzadko bywa jednorazowym skokiem – to sekwencja etapów: inwentaryzacja (co już działa w kontenerach, co jest stanowe, co pozostaje na maszynach wirtualnych), wybór pierwszych kandydatów, przeniesienie, obserwacja, kolejna partia. Częścią uczciwego planu jest także lista aplikacji, których nie warto przenosić: monolit stabilnie pracujący na jednej maszynie wirtualnej po konteneryzacji nie stanie się nagle skalowalnym mikroserwisem – zyska za to nową warstwę złożoności.

Pomagamy m.in. w dwóch scenariuszach: przenosinach środowisk z Docker Swarm do Kubernetes oraz migracjach całych środowisk wirtualizacji do naszej chmury – ten drugi temat opisujemy w artykule Migracja z VMware do WebDisk Cloud Computing.

Kubernetes w WebDisk: zarządzany klaster albo własny na IaaS

W naszej chmurze publicznej Kubernetes dostępny jest dwiema drogami:

Zarządzany klaster Kubernetes (WebDisk K8s) – usługa dostępna dla użytkowników WebDisk Cloud. Platforma (zbudowana na Apache CloudStack) tworzy klaster automatycznie, a liczbę węzłów zmieniasz z poziomu panelu (cloud.dco.webdisk.io), bez ręcznego dotykania każdej maszyny; aktualizację wersji klastra planujemy razem z Tobą, bo Kubernetes podnosi się po kolei, wydanie po wydaniu. „Zarządzany” znaczy tu: platforma zakłada klaster i skaluje go za Ciebie. Kopia etcd, odnawianie certyfikatów, aktualizacje systemu na węzłach i monitoring Twoich aplikacji pozostają po stronie właściciela klastra – chyba że umówimy się inaczej.
Własny klaster na IaaS – dla zespołów, które chcą pełnej kontroli nad dystrybucją i konfiguracją. IaaS (Infrastructure as a Service) oznacza, że wynajmujesz od nas maszyny wirtualne i sieć, a środowisko budujesz na nich narzędziami, które znasz; zaawansowane zespoły mogą sięgnąć po Cluster API z providerem dla CloudStacka (automatyczne zakładanie i odtwarzanie klastrów) albo po CloudStack Kubernetes Provider, który spina gotowy klaster z siecią i load balancerami platformy.

Niezależnie od drogi możesz skorzystać z pomocy naszego zespołu – od doradztwa i planu migracji po konfigurację aplikacji. Zakres takiej współpracy i jej warunki ustalamy w umowie, więc od początku wiadomo, co jest po naszej stronie, a co po Waszej. O tym, jak nasze wsparcie wygląda od kuchni – i jakimi kanałami można się z nami skontaktować – piszemy w artykule Wsparcie WebDisk.

Czego wsparcie techniczne Kubernetes nie załatwi?

Outsourcing utrzymania Kubernetes zdejmuje z zespołu realny ciężar, ale kilka rzeczy pozostaje po stronie właściciela systemu – i lepiej wiedzieć to przed podpisaniem umowy niż po:

Decyzja „czy w ogóle Kubernetes”. Nie każda aplikacja zyskuje na orkiestracji kontenerów. Dla wielu obciążeń maszyna wirtualna pozostaje prostszym i tańszym operacyjnie wyborem – o różnicach między modelami usług chmurowych pisaliśmy w artykule Chmura jako usługa, a o kosztach chmury publicznej – w artykule Chmura publiczna w rozsądnej cenie.
Granice słowa „zarządzany”. Zarządzana usługa Kubernetes zakłada klaster i skaluje go za Ciebie. Kopia etcd, odnawianie certyfikatów, aktualizacje systemu na węzłach i monitoring Twoich aplikacji nie dzieją się same – ktoś musi mieć je w obowiązkach: Twój zespół albo nasz, na podstawie umowy.
Zmiany w samej aplikacji. Wsparcie utrzyma klaster, ale nie przepisze architektury aplikacji, która nie jest gotowa na pracę w kontenerach.
Odpowiedzialność za dane. Backup infrastruktury klastra to nie to samo co polityka kopii zapasowych danych aplikacji – tę drugą trzeba świadomie zaprojektować i regularnie testować.
Złożoność jako taka. Kubernetes dodaje warstwę abstrakcji, która ma swoje koszty. Dobre wsparcie tą złożonością zarządza – ale jej nie likwiduje.

Częste pytania

Czy muszę używać Kubernetes, żeby korzystać z chmury WebDisk? Nie. Kubernetes to jedna z opcji – obok klasycznych maszyn wirtualnych, VPS i usług plikowych. Jeśli Twoje obciążenia dobrze działają na VM, migracja do kontenerów nie jest warunkiem korzystania z naszej platformy.

Postawiłem klaster samodzielnie. Czy mogę liczyć na wsparcie? Tak – z pomocy można skorzystać na dowolnym etapie: przy planowaniu migracji, po samodzielnym wdrożeniu, a także dla aplikacji działających w naszej chmurze od początku. Zakres ustalamy indywidualnie, w umowie.

Co znaczy „zarządzany” klaster Kubernetes i co pozostaje po mojej stronie? W WebDisk K8s „zarządzany” znaczy: platforma zakłada klaster i skaluje go za Ciebie – liczbę węzłów zmieniasz z poziomu panelu. Kopia etcd, odnawianie certyfikatów, aktualizacje systemu na węzłach i monitoring Twoich aplikacji pozostają po stronie właściciela klastra, chyba że umówimy się inaczej. Ten podział odpowiedzialności warto mieć spisany w umowie, zanim będzie potrzebny.

Jak często trzeba aktualizować klaster Kubernetes? Kubernetes publikuje trzy wydania rocznie, a każde otrzymuje poprawki – w tym poprawki bezpieczeństwa – przez około 14 miesięcy. Klaster nieaktualizowany od roku z okładem wypada z tego okna, a zaległości nadrabia się wersja po wersji, bez przeskakiwania. Elementem każdej planowanej aktualizacji powinien być też przegląd wycofywanych API.

Czy kopia etcd to pełny backup klastra? Nie. Kopia etcd zabezpiecza stan klastra: definicje wdrożeń, konfigurację, sekrety. Dane aplikacji – bazy danych, pliki na wolumenach – wymagają osobnej strategii kopii zapasowych, z osobnym testem odtworzenia.

Od czego zacząć migrację ze środowiska hybrydowego? Od inwentaryzacji: co już działa w kontenerach, co jest stanowe, co ma zostać na maszynach wirtualnych. Potem wybór pierwszej, niekrytycznej aplikacji, migracja, obserwacja – i dopiero wtedy kolejne etapy. Plan „wszystko naraz” to częsta przyczyna nieudanych migracji.

Podsumowanie

Kubernetes wart jest swojej popularności – ale razem z nim kupujesz obowiązki: aktualizacje, kopie, monitoring, bezpieczeństwo i gotowość do reakcji. Jeśli Twój zespół ma je ułożone – świetnie. Jeśli nie, warto o nich porozmawiać, zanim przypomni o nich pierwsza awaria. Napisz do nas – pomożemy zaplanować migrację albo przejrzeć, jak utrzymywany jest Twój obecny klaster.

Wsparcie techniczne Kubernetes: postawić klaster to najłatwiejszy etap