Rancher to platforma zarządzania klastrami Kubernetes: pozwala tworzyć klastry, nadawać dostęp, wymuszać polityki i obserwować stan środowisk z jednego miejsca, niezależnie od tego, u kogo te klastry działają. Decyzja o niej nie dotyczy technologii kontenerowej jako takiej, tylko tego, kto i na jakich zasadach panuje nad rozproszonym środowiskiem uruchomieniowym.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi, gdy każde środowisko rządzi się własnymi regułami dostępu
- Jakie warunki muszą wystąpić razem, żeby dokładanie warstwy zarządzania było uzasadnione
- Kiedy narzędzia natywne albo konsola dostawcy chmury wystarczą i nic dokładać nie trzeba
- Jakie alternatywy istnieją i jaką cenę niesie każda z nich
- Co organizacja bierze na siebie na lata, wprowadzając kolejną warstwę operacyjną
Dla kogo ten artykuł:
- Kierownicy zespołów operacyjnych odpowiedzialni za środowiska kontenerowe
- Architekci rozstrzygający o modelu dostępu i polityk w wielu środowiskach naraz
- Menedżerowie rozliczani z audytu dostępu i z kosztu utrzymania infrastruktury
Czym płaci organizacja, w której każde środowisko ma własne reguły dostępu?
Problem nie zaczyna się od technologii, tylko od pytania, na które nikt nie potrafi szybko odpowiedzieć: kto ma dziś dostęp do środowiska produkcyjnego i skąd to wiadomo. W firmie, w której zespoły uruchamiały kolejne klastry w miarę potrzeb — osobno dla projektu, osobno dla regionu, osobno u innego dostawcy chmury — każde z tych środowisk niesie własną listę użytkowników, własny kalendarz aktualizacji i własny zestaw polityk sieciowych. Rachunek jest wystawiany po cichu: audytor dostaje odpowiedź składaną ręcznie z wielu źródeł, incydent trwa dłużej, bo nie ma jednego miejsca, w którym widać stan wszystkich środowisk, a różnice w konfiguracji wychodzą dopiero przy awarii.
Warto od razu rozgraniczyć dwa porządki, bo bywają mylone przy tej samej tablicy. Wybór środowiska, w którym wykonuje się kod aplikacji — serwer aplikacyjny, obraz kontenera, funkcja bezserwerowa — jest osobnym rozstrzygnięciem, o osobnym budżecie i osobnym właścicielu. Tutaj mowa wyłącznie o warstwie, z której zarządza się klastrami: kto je tworzy, kto ma do nich dostęp, jakie reguły obowiązują w każdym z nich i skąd to widać. Sam Kubernetes tego nie rozstrzyga — dokumentacja Kubernetes Documentation — Concepts opisuje mechanizmy pojedynczego klastra, a nie sposób zarządzania ich zbiorem.
Rozproszenie narasta stopniowo i prawie nigdy nie jest decyzją. Zaczyna się od pierwszego środowiska produkcyjnego postawionego solidnie, potem dochodzi drugie, bo zespół potrzebował izolacji, potem trzecie u innego dostawcy, bo tam był kontrakt. Jak wygląda uczciwe postawienie tego pierwszego, opisuje tekst o wdrożeniu klastra w środowisku produkcyjnym.
Kiedy warstwa zarządzania klastrami jest właściwą odpowiedzią?
Dokładanie warstwy zarządzania broni się wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno.
- Klastrów jest kilka i mają różnych właścicieli. Środowiska należące do odrębnych zespołów, regionów albo dostawców nie dają się rozliczyć wspólną polityką bez miejsca, w którym ta polityka jest zapisana raz.
- Dostęp musi być rozliczalny wobec kontroli zewnętrznej. Gdy trzeba wykazać, kto i kiedy miał uprawnienia w środowisku produkcyjnym, rzutowanie ról z katalogu firmowego na wszystkie klastry przestaje być wygodą, a staje się wymaganiem.
- Reguły mają obowiązywać jednakowo niezależnie od dostawcy. Polityki sieciowe, ograniczenia uruchomieniowe i standardy obrazów wdrażane osobno w każdym środowisku rozjeżdżają się zawsze — pytanie brzmi tylko, po jakim czasie.
Gdy te warunki występują razem, warstwa zarządzania przestaje być wygodą konsoli, a staje się mechanizmem kontroli. Praktyczne kompetencje potrzebne do jej prowadzenia — provisioning klastrów, zarządzanie dostępem, polityki bezpieczeństwa, monitorowanie i praca ze środowiskiem wieloklastrowym — obejmuje szkolenie Zarządzanie Kubernetes z Rancher.
Kiedy nie sięgać po warstwę zarządzania klastrami?
Najczęstszym błędem jest dokładanie warstwy zarządzania do problemu, który nie jest problemem skali, tylko problemem dyscypliny. Organizacja bez odtwarzalnej konfiguracji środowisk nie zyskuje jej przez instalację kolejnego narzędzia — dostaje wygodniejszy widok na ten sam bałagan i drugie miejsce, w którym trzeba go teraz utrzymywać.
Drugi przypadek to pojedyncze środowisko. Przy jednym klastrze mechanizmy wbudowane — role, przestrzenie nazw, polityki sieciowe — pokrywają całość potrzeby, a dołożona warstwa jest wtedy wyłącznie kosztem: własną wersją, własną aktualizacją i własnym oknem serwisowym. Trzeci przypadek to pełna jednorodność dostawcy: jeżeli wszystkie klastry pracują w usłudze zarządzanej tego samego dostawcy chmury, jego konsola i model uprawnień robią już to, po co sięga się po warstwę zewnętrzną, a dołożenie jej oznacza utrzymywanie dwóch źródeł prawdy o dostępie. Warstwa zarządzania nie tworzy dyscypliny operacyjnej — ona ją egzekwuje, a egzekwować da się tylko to, co wcześniej zostało ustalone.
Jakie są alternatywy i ile kosztują?
Pierwszą alternatywą jest zarządzanie konfiguracją z repozytorium: stan klastrów opisany w plikach, wprowadzany przez proces automatyczny, przeglądany jak kod. Ceną jest własna integracja, utrzymanie repozytoriów i to, że nadawanie dostępu przestaje być czynnością w interfejsie, a staje się zmianą podlegającą przeglądowi.
Drugą alternatywą jest deklaratywne tworzenie klastrów opisane w The Cluster API Book: klaster staje się obiektem, którym zarządza inny klaster, a cały cykl życia środowiska podlega tym samym regułom co reszta konfiguracji. Ta droga wymaga jednak kompetencji utrzymaniowej i własnego planu aktualizacji, więc bywa tańsza tylko dla zespołów, które już pracują w tym modelu. Trzecia droga to pozostanie przy narzędziach dostawcy chmury — najtańsza w starcie i najdroższa w chwili, gdy pojawia się środowisko poza tą chmurą. Szerszy kontekst pracy z klastrami w skali przedsiębiorstwa daje tekst o Kubernetes w praktyce.
Co organizacja bierze na siebie, wprowadzając tę warstwę?
Każde narzędzie zarządzające ma własny cykl wydawniczy i własną macierz zgodności z wersjami zarządzanych środowisk; opisuje ją Rancher Manager Documentation. Oznacza to, że kalendarz aktualizacji klastrów przestaje zależeć wyłącznie od nich samych — dochodzi drugi kalendarz, który trzeba z pierwszym uzgodnić, a rozjazd między nimi blokuje aktualizacje po obu stronach.
Druga konsekwencja jest poważniejsza. Warstwa, przez którą przechodzi uwierzytelnianie i dostęp, staje się elementem ścieżki krytycznej: jej niedostępność jest incydentem nawet wtedy, gdy same aplikacje działają bez zarzutu. Organizacja, która ją wdraża, powinna z góry ustalić, kto jest jej właścicielem, jak wygląda dostęp awaryjny z pominięciem konsoli i gdzie leży kopia konfiguracji. Bez tych ustaleń narzędzie porządkujące dostęp samo staje się pojedynczym punktem awarii — dokładnie tym, przed czym miało chronić.
FAQ — najczęściej zadawane pytania
Czy warstwa zarządzania zastępuje kompetencje z zakresu Kubernetes?
Nie. Upraszcza czynności powtarzalne i porządkuje dostęp, ale diagnozowanie problemów nadal wymaga rozumienia mechanizmów samego klastra — harmonogramowania, sieci i zasobów. Zespół, który liczy na to, że interfejs zastąpi wiedzę, przekonuje się o czymś przeciwnym przy pierwszej awarii, kiedy odpowiedzi trzeba szukać poniżej konsoli.
Czy da się wprowadzić taką warstwę do istniejących środowisk bez ich przebudowy?
Zwykle tak — działające klastry można podłączyć do zarządzania bez ich odtwarzania. Kosztem nie jest wtedy migracja, tylko uzgodnienie: różnice w politykach i rolach, które dotąd żyły osobno, trzeba sprowadzić do wspólnego modelu, a to zwykle ujawnia uprawnienia, o których nikt nie pamiętał.
Od czego zacząć ocenę, czy ta warstwa się opłaci?
Od policzenia, ile czasu zespół poświęca miesięcznie na nadawanie dostępu, uzgadnianie polityk i odpowiadanie na pytania kontroli. Jeżeli ten czas jest krótki, a środowisko jednorodne, warstwa zarządzania będzie kosztem bez pokrycia. Jeżeli jest długi i rośnie razem z liczbą środowisk, decyzja przestaje dotyczyć narzędzia, a zaczyna dotyczyć modelu operacyjnego.