Problem z aplikacjami stanowymi w Kubernetesie
Konfiguracja, uruchomienie i dalsze skalowanie aplikacji i usług jest łatwe w przypadku przypadków zaliczanych do kategorii bezstanowych, czyli tzw. bez zapisywania danych. Wygodnie jest uruchamiać takie usługi w Kubernetesie, korzystając z jego standardowych API, bo wszystko dzieje się „od razu po wyjęciu z pudełka”: według standardowych konfiguracji, bez żadnych konkretów i magii.
Mówiąc najprościej, aby uruchomić pięć dodatkowych kopii backendu w PHP/Ruby/Pythonie w klastrze kontenerów, wystarczy tylko 5 razy skonfigurować nowy serwer i skopiować źródła. Ponieważ w obrazie znajduje się zarówno kod źródłowy, jak i skrypt inicjujący, skalowanie aplikacji bezstanowej staje się całkowicie elementarne. Jak dobrze wiedzą miłośnicy kontenerów i architektury mikroserwisowej, trudność zaczyna się od aplikacje stanowe, tj. z trwałością danych, takich jak bazy danych i pamięci podręczne (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Dotyczy to zarówno oprogramowania, które niezależnie implementuje klaster kworum (na przykład Percona XtraDB i Cassandra), jak i oprogramowania wymagającego oddzielnych narzędzi do zarządzania (takich jak Redis, MySQL, PostgreSQL...).
Trudności pojawiają się, bo sam kod źródłowy i uruchomienie usługi już nie wystarcza – trzeba wykonać jeszcze kilka kroków. Skopiuj przynajmniej dane i/lub dołącz do klastra. Mówiąc dokładniej, usługi te wymagają zrozumienia, jak prawidłowo je skalować, aktualizować i rekonfigurować bez utraty danych lub tymczasowej niedostępności. Uwzględnianie tych potrzeb nazywa się „wiedzą operacyjną”.
Operatorzy CoreOS
W celu „zaprogramowania” wiedzy operacyjnej pod koniec ubiegłego roku powstał projekt CoreOS „nowa klasa oprogramowania” dla platformy Kubernetes – Operatorzy (od angielskiego „operacja”, czyli „operacja”).
Operatorzy korzystający i rozszerzający podstawowe możliwości Kubernetes (m.in. Zestawy stanowe, zobacz różnicę poniżej) pozwalają specjalistom DevOps na dodanie wiedzy operacyjnej do kodu aplikacji.
Cel operatora — udostępnij użytkownikowi API, które pozwala zarządzać wieloma stanowymi jednostkami aplikacji w klastrze Kubernetes, bez zastanawiania się nad tym, co kryje się pod maską (jakie dane i co z nimi zrobić, jakie polecenia należy jeszcze wykonać, aby utrzymać klaster ). Tak naprawdę Operator ma za zadanie maksymalnie uprościć pracę z aplikacją w obrębie klastra, automatyzując realizację zadań operacyjnych, które wcześniej trzeba było rozwiązywać ręcznie.
Jak działają operatorzy
Zestawy replik Kubernetes pozwala określić żądaną liczbę uruchomionych podów, a kontrolery czuwają nad utrzymaniem ich liczby (tworząc i usuwając pody). Operator działa w podobny sposób, dodając do standardowego zasobu Kubernetes i kontrolera zestaw wiedzy operacyjnej, który pozwala na wykonanie dodatkowych akcji w celu obsługi wymaganej liczby encji aplikacji.
Czym to się różni od Zestawy stanowe, zaprojektowany dla aplikacji, które wymagają, aby klaster zapewniał im zasoby stanowe, takie jak przechowywanie danych lub statyczne adresy IP? Do takich zastosowań Operatorzy mogą używać Zestawy stanowe (zamiast Zestawy replik) jako podstawa, oferta dodatkowa automatyzacja: wykonaj niezbędne działania w przypadku awarii, wykonaj kopie zapasowe, zaktualizuj konfigurację itp.
W ten sposób jak to wszystko działa? Operator jest demonem menedżera, który:
- subskrybuje event API w Kubernetesie;
- otrzymuje od niego dane o systemie (o jego Zestawy replik, Strąki, Usługi i tak dalej.);
- otrzymuje dane o Zasoby osób trzecich (patrz przykłady poniżej);
- reaguje na pojawienie się/zmianę Zasoby osób trzecich (na przykład, aby zmienić rozmiar, zmienić wersję i tak dalej);
- reaguje na zmiany stanu systemu (ok Zestawy replik, Strąki, Usługi i tak dalej.);
- najważniejsze:
- wywołuje API Kubernetes, aby stworzyć wszystko, czego potrzebuje (ponownie własne Zestawy replik, Strąki, Usługi...),
- wykonuje jakąś magię (dla uproszczenia można pomyśleć, że Operator sam wchodzi do strąków i wywołuje polecenia np. dołączenia do klastra lub aktualizacji formatu danych podczas aktualizacji wersji).
Tak naprawdę, jak widać na obrazku, do Kubernetesa po prostu dodawana jest osobna aplikacja (zwykła Rozlokowanie с Zestaw replik), który nazywany jest Operatorem. Mieszka w zwykłej kapsule (zwykle tylko w jednej) i z reguły odpowiada tylko za swoją Przestrzeń nazw. Ta aplikacja operatorska implementuje swoje API - choć nie bezpośrednio, ale poprzez Zasoby osób trzecich w Kubernetesie.
Zatem po utworzeniu w Przestrzeń nazw Operator, możemy do niego dodać Zasoby osób trzecich.
Przykład dla itp (szczegóły poniżej):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Przykład dla Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Wymagania dla Operatorów
CoreOS sformułował główne wzorce uzyskane przez inżynierów podczas pracy nad Operatorami. Pomimo tego, że wszyscy Operatorzy są indywidualni (stworzeni pod konkretną aplikację, mającą swoją charakterystykę i potrzeby), ich tworzenie musi opierać się na swego rodzaju frameworku, który narzuca następujące wymagania:
- Instalacja musi zostać przeprowadzona za pomocą pojedynczego Rozlokowanie: kubectl utwórz -f SOME_OPERATOR_URL/deployment.yaml - i nie wymagają dodatkowych działań.
- Podczas instalowania operatora w Kubernetes należy utworzyć nowy typ strony trzeciej (Zasób strony trzeciej). Aby uruchomić instancje aplikacji (instancje klastra) i dalej nimi zarządzać (aktualizacja wersji, zmiana rozmiaru itp.), użytkownik będzie korzystał z tego typu.
- Jeśli to możliwe, powinieneś używać prymitywów wbudowanych w Kubernetes, takich jak Usługi и Zestawy replikużywać dobrze przetestowanego i zrozumiałego kodu.
- Wymaga wstecznej kompatybilności Operatorów i obsługi starszych wersji zasobów tworzonych przez użytkowników.
- W przypadku usunięcia Operatora sama aplikacja powinna dalej działać bez zmian.
- Użytkownicy powinni mieć możliwość zdefiniowania żądanej wersji aplikacji i zorganizowania aktualizacji wersji aplikacji. Brak aktualizacji oprogramowania jest częstym źródłem problemów operacyjnych i bezpieczeństwa, dlatego Operatorzy muszą pomóc użytkownikom w tej kwestii.
- Operatorów należy przetestować za pomocą narzędzia takiego jak Chaos Monkey, które identyfikuje potencjalne awarie podów, konfiguracji i sieci.
itp. Operator
Przykład wdrożenia operatora - operator itp., w dniu ogłoszenia tej koncepcji. Konfiguracja klastra itp. może być złożona ze względu na konieczność utrzymania kworum, konieczność ponownej konfiguracji członkostwa w klastrze, tworzenia kopii zapasowych itp. Na przykład ręczne skalowanie klastra etcd oznacza, że musisz utworzyć nazwę DNS dla nowego elementu klastra, uruchomić nową jednostkę etcd i powiadomić klaster o nowym elemencie (dodanie członka etcdctl). W przypadku Operatora użytkownik będzie musiał jedynie zmienić wielkość klastra – cała reszta stanie się automatycznie.
A ponieważ etcd został również stworzony w CoreOS, całkiem logiczne było, aby jego Operator pojawił się jako pierwszy. Jak on pracuje? Logika operatora itp jest określany przez trzy elementy:
- Przestrzegać. Operator monitoruje stan klastra za pomocą Kubernetes API.
- Analiza. Znajduje różnice pomiędzy stanem bieżącym a pożądanym (zdefiniowanym przez konfigurację użytkownika).
- Działanie. Rozwiązuje wykryte różnice przy użyciu interfejsów API usług etcd i/lub Kubernetes.
Aby zaimplementować tę logikę, w Operatorze przygotowano funkcje Stwórz/zniszcz (tworzenie i usuwanie członków klastra itp.) i Resize (zmiana liczby członków klastra). Poprawność jego działania sprawdzono za pomocą narzędzia stworzonego na wzór Chaos Monkey od Netfliksa, tj. losowe zabijanie strąków itp.
Dla pełnej obsługi etcd Operator udostępnia dodatkowe funkcje: backup (automatyczne i niewidoczne dla użytkowników tworzenie kopii zapasowych - w konfiguracji wystarczy określić, jak często je wykonywać i ile przechowywać - a następnie przywracać z nich dane) oraz Aktualizacja (aktualizacja instalacji itp. bez przestojów).
Jak wygląda współpraca z Operatorem?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Obecny stan ettd Operator to wersja beta, wymagająca do działania Kubernetes 1.5.3+ i etcd 3.0+. Kod źródłowy i dokumentacja (w tym instrukcje obsługi) są dostępne pod adresem .
Powstała kolejna przykładowa implementacja z CoreOS - , ale nadal jest w wersji alfa (nie wszystkie zaplanowane funkcje zostały zaimplementowane).
Stan i perspektywy
Od ogłoszenia Operatorów Kubernetes minęło 5 miesięcy. W oficjalnym repozytorium CoreOS dostępne są nadal tylko dwie implementacje (dla etcd i Prometheus). Obydwa nie osiągnęły jeszcze swoich stabilnych wersji, ale zatwierdzenia są obserwowane codziennie.
Twórcy przewidują „przyszłość, w której użytkownicy instalują operatory Postgres, Cassandra Operators lub Redis Operators w swoich klastrach Kubernetes i pracują ze skalowalnymi jednostkami tych aplikacji tak łatwo, jak wdrażanie replik bezstanowych aplikacji internetowych jest dzisiaj”. Pierwszy Operatorzy od zewnętrznych programistów naprawdę zaczęło się pojawiać:
- z przedsiębiorstw UPMC;
- od Crunchy Data (ogłoszenie pod koniec marca 2017 r.);
- od autorów rozproszonego systemu przechowywania danych opartego na Ceph (Rook jest w fazie alfa);
- z SAP CCloud.
Na największej europejskiej konferencji wolnego oprogramowania FOSDEM, która odbyła się w lutym 2017 w Brukseli, Josh Wood z CoreOS ogłosił Operatorów w (film dostępny pod linkiem!), co powinno przyczynić się do wzrostu popularności tej koncepcji w szerszej społeczności Open Source.
PS Dziękujemy za zainteresowanie artykułem! Subskrybuj nasze centrum, aby nie przegapić nowych materiałów i przepisów na temat DevOps i administracji systemem GNU/Linux - będziemy je regularnie publikować!
Źródło: www.habr.com