Po przedstawiamy jego starszego brata — . To projekt Open Source, który jest używany do instalacji w klastrze Kubernetes komponentów systemowych, które można nazwać wspólnym słowem — dodatki.
Po co w ogóle jakieś dodatki?
Nie jest tajemnicą, że Kubernetes to nie gotowy produkt all-in-one, a do zbudowania „dojrzałego” klastra potrzebne będą różne dodatki. Addon-operator pomoże w instalacji, konfiguracji i utrzymaniu tych dodatków w aktualnym stanie.
Konieczność dodatkowych komponentów w klastrze została przedstawiona w koledzy . Krótko mówiąc, sytuacja z Kubernetes na chwilę obecną jest taka, że do prostego zainstalowania „do zabawy” można obejść się komponentami z pudełka, dla deweloperów i testowania można dodać Ingress, ale do pełnoprawnej instalacji, o której można powiedzieć „twój produkcyjny klaster jest gotowy”, trzeba dodać około dziesięciu różnych dodatków: coś do monitorowania, coś do logów, nie zapomnieć o ingress i cert-manager, wyznaczyć grupy węzłów, dodać polityki sieciowe, przyprawić ustawieniami sysctl i pod autoscaler’em…
Na czym polega specyfika pracy z nimi?
Jak pokazuje praktyka, sama instalacja to nie wszystko. Aby komfortowo pracować z klastrem, dodatki należy aktualizować, wyłączać (usuwać z klastra), a coś może chcieć się przetestować przed zainstalowaniem w klastrze produkcyjnym.
Więc może Ansible wystarczy? Możliwe. Ale pełnoprawne dodatki w ogólnym przypadku nie działają bez konfiguracji. Te ustawienia mogą się różnić w zależności od opcji klastra (aws, gce, azure, bare-metal, do, …). Niektóre ustawienia nie mogą być określone z góry — trzeba je pobrać z klastra. A klaster nie jest statyczny: w przypadku niektórych ustawień trzeba będzie śledzić zmiany. I tu już Ansible nie wystarczy: potrzebny jest program, który żyje w klastrze, tzn. Kubernetes Operator.
Ci, którzy wypróbowali to w praktyce , powiedzą, że zadania instalacji i aktualizacji dodatków oraz śledzenia konfiguracji można rozwiązać za pomocą dla shell-operator. Można napisać skrypt, który będzie robił warunkowy kubectl apply i śledzić, na przykład, ConfigMap, w którym będą przechowywane ustawienia. Praktycznie to właśnie zostało zrealizowane w addon-operator.
Jak to zorganizowano w addon-operator?
Tworząc nowe rozwiązanie, kierowaliśmy się następującymi zasadami:
- Instalator dodatków musi wspierać szablonowanie i deklaratywną konfigurację. Nie tworzymy magicznych skryptów instalujących rozszerzenia. Addon-operator używa Helma do instalacji rozszerzeń. Aby zainstalować, należy stworzyć chart i wyodrębnić wartości, które będą użyte do konfiguracji.
- Ustawienia można generować podczas instalacji, można je uzyskać z klastra, albo otrzymywać aktualizacje, śledząc zasoby klastra. Te operacje można zrealizować za pomocą hooków.
- Ustawienia można przechowywać w klastrze. Aby przechowywać ustawienia w klastrze, tworzy się ConfigMap/addon-operator, a Addon-operator monitoruje zmiany tego ConfigMap. Addon-operator daje hookom dostęp do ustawień za pomocą prostych konwencji.
- Rozszerzenie zależy od ustawień. Jeśli ustawienia się zmienią, to Addon-operator wdraża chart Helma z nowymi wartościami. Połączenie charta Helma, jego wartości i hooków nazwaliśmy modułem (szczegóły poniżej).
- Staging. Nie ma magicznych skryptów wydania. Mechanizm aktualizacji jest podobny do standardowej aplikacji — zbieramy rozszerzenia i addon-operator w obraz, tagujemy i wdrażamy.
- Kontrola wyniku. Addon-operator potrafi udostępniać metryki dla Prometheusa.
Czym jest rozszerzenie w addon-operator?
Rozszerzeniem można nazwać wszystko, co dodaje do klastra nowe funkcje. Na przykład, instalacja Ingress to doskonały przykład rozszerzenia. Może to być dowolny operator lub kontroler ze swoim CRD: prometheus-operator, cert-manager, kube-controller-manager itp. Lub coś małego, co upraszcza eksploatację — na przykład secret copier, który kopiuje tajne dane rejestru do nowych przestrzeni nazw, lub sysctl tuner, który konfiguruje parametry sysctl na nowych węzłach.
Aby zrealizować rozszerzenia, Addon-operator oferuje kilka koncepcji:
- Helm chart jest używany do instalacji różnego oprogramowania w klastrze — na przykład Prometheusa, Grafany, nginx-ingress. Jeśli dany komponent ma chart Helma, instalacja go za pomocą Addon-operatora będzie bardzo prosta.
- Przechowalnia wartości. Charty Helma zazwyczaj mają wiele różnych ustawień, które mogą się zmieniać z czasem. Addon-operator wspiera przechowywanie tych ustawień i potrafi monitorować ich zmiany, aby ponownie zainstalować chart Helma z nowymi wartościami.
- Hooki — to pliki wykonywalne, które Addon-operator uruchamia na zdarzenia i które mają dostęp do przechowalni values. Hak może monitorować zmiany w klastrze i aktualizować wartości w przechowalni values. Tzn. za pomocą haków można przeprowadzić discovery, aby zbierać wartości z klastra podczas uruchamiania lub według harmonogramu, a także można przeprowadzić continuous discovery, zbierając wartości z klastra według zmian w klastrze.
- Moduł — to połączenie wykresu Helm, przechowalni values i haków. Moduły można włączać i wyłączać. Wyłączenie modułu polega na usunięciu wszystkich wydań wykresu Helm. Moduły mogą dynamicznie włączać same siebie, na przykład jeśli włączone są wszystkie potrzebne im moduły lub jeśli discovery w hakach znalazło odpowiednie parametry — robi się to z pomocą pomocniczego skryptu enabled.
- Globalne haki. To haki „same w sobie”, nie są dołączone do modułów i mają dostęp do globalnej przechowalni values, wartości z której są dostępne wszystkim hakom w modułach.
Jak te części współpracują? Zobaczmy obrazek z dokumentacji:
Scenariuszy pracy są dwa:
- Globalny hak uruchamiany jest na zdarzenie — na przykład, gdy zasób w klastrze ulega zmianie. Ten hak przetwarza zmiany i zapisuje nowe wartości w globalnej przechowalni values. Addon-operator dostrzega, że globalna przechowalnia się zmieniła i uruchamia wszystkie moduły. Każdy moduł za pomocą swoich haków określa, czy powinien się włączyć, i aktualizuje swoją przechowalnię values. Jeśli moduł jest włączony, to Addon-operator uruchamia instalację wykresu Helm. Wykresowi Helm są wówczas dostępne wartości z przechowalni modułu i z globalnej przechowalni.
- Drugi scenariusz jest prostszy: modułowy hak uruchamiany jest na zdarzenie, zmienia wartości w przechowalni values modułu. Addon-operator to dostrzega i uruchamia wykres Helm z zaktualizowanymi wartościami.
Dodatek może być zrealizowany jako pojedynczy hak lub jako jeden wykres Helm, lub nawet jako kilka zależnych modułów — to zależy od złożoności komponentu instalowanego w klastrze i od wymaganego poziomu elastyczności ustawień. Na przykład, w repozytorium () znajduje się dodatek sysctl-tuner, który został zrealizowany zarówno jako prosty moduł z hakiem i wykresem Helm, jak i z wykorzystaniem przechowalni values, co daje możliwość dodawania ustawień przez edytowanie ConfigMap.
Dostawa aktualizacji
Kilka słów na temat organizacji aktualizacji komponentów, które instaluje Addon-operator.
Aby uruchomić Addon-operator w klastrze, należy stworzyć obraz z dodatkami w postaci plików hooków i Helm-chartów, dodać plik binarny addon-operator i wszystko, co będzie potrzebne do hooków: bash, kubectl, jq, python itd. Następnie ten obraz można wdrożyć w klastrze jak zwykłą aplikację i prawdopodobnie będziecie chcieli zorganizować jakąś wersję tagowania. Jeśli klastrów jest niewiele, podejście takie jak w przypadku aplikacji może być wystarczające: nowa wersja, nowa edycja, przejść przez wszystkie klastry i zmienić obraz dla Podów. Jednak w przypadku wdrożenia na znaczną liczbę klastrów, bardziej odpowiednia jest koncepcja samodzielnej aktualizacji z kanału.
U nas wygląda to tak:
- Kanał to w zasadzie identyfikator, który można definiować dowolnie (np. dev/stage/ea/stable).
- Nazwa kanału to tag obrazu. Kiedy trzeba wdrożyć aktualizacje w kanale, tworzony jest nowy obraz i tagowany jest nazwą kanału.
- Kiedy w rejestrze pojawia się nowy obraz, Addon-operator jest restartowany i uruchamiany z nowym obrazem.
To nie jest najlepsza praktyka, o czym pisano w . Tak nie powinno się robić, ale mówimy o zwykłej aplikacji, która żyje w jednym klastrze. W przypadku Addon-operatora aplikacja to wiele wdrożeń rozproszonych po klastrach, a samodzielna aktualizacja bardzo pomaga i ułatwia życie.
Kanały pomagają także w testowaniu: jeśli istnieje pomocniczy klaster, można skonfigurować go na kanał stage i wdrożyć w nim aktualizacje przed wprowadzeniem ich w kanałach ea i stable. Jeśli z klastrem na kanale ea pojawił się błąd, można go przełączyć na stable, podczas gdy trwa dochodzenie w sprawie problemu z tym klastrem. Jeśli klaster zostanie wyłączony z aktywnego wsparcia, przełącza się na swój „zamrożony” kanał — na przykład, freeze-2019-03-20.
Oprócz aktualizacji hooków i Helm-chartów, może być konieczne zaktualizowanie także komponentu zewnętrznego. Na przykład, zauważyliście błąd w warunkowym node-exporter i wymyśliliście, jak go poprawić. Następnie otworzyliście PR i czekacie na nową wersję, aby przejść przez wszystkie klastry i zwiększyć wersję obrazu. Aby nie czekać nieokreślony czas, można zbudować własny node-exporter i przełączyć się na niego do czasu zaakceptowania PR.
Ogólnie rzecz biorąc, można to zrobić również bez Addon-operator, ale z Addon-operator moduł do instalacji node-exporter będzie widoczny w jednym repozytorium, a Dockerfile do budowy własnego obrazu można trzymać od razu tam, wszystkim uczestnikom procesu łatwiej jest zrozumieć, co się dzieje... A jeśli jest kilka klastrów, staje się to prostsze zarówno w testowaniu swojego PR, jak i w wdrażaniu nowej wersji!
Ta organizacja aktualizacji komponentów działa u nas pomyślnie, ale można wdrożyć dowolny inny odpowiedni schemat — w końcu w tym przypadku Addon-operator jest prostym plikiem binarnym.
Podsumowanie
Zasady wdrażane w Addon-operatorze pozwalają na zbudowanie przejrzystego procesu tworzenia, testowania, instalacji i aktualizacji dodatków w klastrze, analogicznego do procesów rozwoju zwykłych aplikacji.
Dodatki dla Addon-operatora w formacie modułów (Helm-chart + hooki) można udostępniać szeroko. My, firma Flant, planujemy w ciągu lata udostępnić nasze osiągnięcia w formie takich dodatków. Dołącz do rozwoju na GitHubie (, ), spróbuj stworzyć swój dodatek na podstawie i , czekaj na wiadomości na Habra i na naszym !
P.S.
Przeczytaj także na naszym blogu:
- «»;
- «».
Źródło: habr.com
