Firma URUS wypróbowała Kubernetes w różnych formach: samodzielne wdrożenie na bare metal, w Google Cloud, a następnie przeniosła swoją platformę do chmury Mail.ru Cloud Solutions (MCS). Igor Szyszkin opowiada, jak wybrali nowego dostawcę usług w chmurze i jak udało im się przeprowadzić do niego migrację w rekordowe dwie godziny (), starszy administrator systemu w URUS.
Co robi URUS?
Sposobów na poprawę jakości środowiska miejskiego jest wiele, a jednym z nich jest uczynienie go przyjaznym dla środowiska. Właśnie nad tym pracuje firma URUS – Smart Digital Services. Tutaj wdrażają rozwiązania, które pomagają przedsiębiorstwom monitorować ważne wskaźniki środowiskowe i ograniczać ich negatywny wpływ na środowisko. Czujniki zbierają dane o składzie powietrza, poziomie hałasu i innych parametrach, a następnie przesyłają je do zunifikowanej platformy URUS-Ekomon w celu analizy i przedstawienia rekomendacji.
Jak URUS działa od środka
Typowym klientem URUS jest firma zlokalizowana na osiedlu mieszkaniowym lub w jego pobliżu. Może to być fabryka, port, zajezdnia kolejowa lub inny obiekt. Jeśli nasz Klient otrzymał już ostrzeżenie, został ukarany mandatem za zanieczyszczenie środowiska, lub chce zmniejszyć hałas, zmniejszyć ilość szkodliwych emisji, przychodzi do nas, a my już oferujemy mu gotowe rozwiązanie do monitoringu środowiska.
Wykres monitorowania stężenia H2S pokazuje regularne emisje nocne z pobliskiej instalacji
Urządzenia, z których korzystamy w URUS, zawierają kilka czujników, które zbierają informacje o zawartości określonych gazów, poziomie hałasu i inne dane w celu oceny sytuacji środowiskowej. Dokładna liczba czujników jest zawsze ustalana w zależności od konkretnego zadania.
W zależności od specyfiki pomiarów urządzenia z czujnikami można lokalizować na ścianach budynków, słupach i innych dowolnych miejscach. Każde takie urządzenie zbiera informacje, agreguje je i przesyła do bramki odbiorczej danych. Tam zapisujemy dane w celu długoterminowego przechowywania i wstępnie je przetwarzamy w celu późniejszej analizy. Najprostszym przykładem tego, co otrzymujemy w wyniku analizy, jest wskaźnik jakości powietrza, znany również jako AQI.
Równolegle na naszej platformie działa wiele innych usług, lecz mają one głównie charakter usługowy. Usługa powiadomień wysyła np. powiadomienia do klientów, jeśli którykolwiek z monitorowanych parametrów (np. zawartość CO2) przekroczy dopuszczalną wartość.
Jak przechowujemy dane. Historia Kubernetesa na bare metal
Projekt monitoringu środowiska URUS posiada kilka hurtowni danych. W jednym przechowujemy „surowe” dane – to, co otrzymaliśmy bezpośrednio z samych urządzeń. Ten zapis to taśma „magnetyczna”, jak na starych kasetach magnetofonowych, z historią wszystkich wskaźników. Drugi rodzaj przechowywania służy do przechowywania danych wstępnie przetworzonych – danych z urządzeń, wzbogaconych o metadane dotyczące połączeń między czujnikami i odczytów samych urządzeń, przynależności do organizacji, lokalizacji itp. Informacje te pozwalają na dynamiczną ocenę tego, jak dany wskaźnik zachował się zmienił się w pewnym okresie czasu. Magazyn danych „surowych” wykorzystujemy m.in. jako kopię zapasową oraz do przywracania danych wstępnie przetworzonych, jeśli zajdzie taka potrzeba.
Kiedy kilka lat temu chcieliśmy rozwiązać nasz problem z pamięcią masową, mieliśmy do wyboru dwie platformy: Kubernetes i OpenStack. Ponieważ jednak ten ostatni wygląda dość monstrualnie (wystarczy spojrzeć na jego architekturę, żeby się o tym przekonać), zdecydowaliśmy się na Kubernetesa. Kolejnym argumentem przemawiającym na jego korzyść była stosunkowo prosta kontrola oprogramowania, możliwość bardziej elastycznego przycinania nawet węzłów sprzętowych według zasobów.
Równolegle z masteringiem samego Kubernetesa badaliśmy także sposoby przechowywania danych, natomiast cały nasz magazyn w Kubernetesie trzymaliśmy na własnym sprzęcie, otrzymaliśmy doskonałą wiedzę. Wszystko, co wtedy żyliśmy na Kubernetesie: pełna pamięć masowa, system monitorowania, CI/CD. Kubernetes stał się dla nas platformą typu „wszystko w jednym”.
Chcieliśmy jednak pracować z Kubernetesem jako usługą, a nie angażować się w jego wsparcie i rozwój. Poza tym nie podobało nam się, ile kosztowało nas utrzymanie go na gołym metalu, i potrzebowaliśmy ciągłego rozwoju! Przykładowo jednym z pierwszych zadań była integracja kontrolerów Kubernetes Ingress z infrastrukturą sieciową naszej organizacji. Jest to zadanie uciążliwe, zwłaszcza biorąc pod uwagę, że w tamtym czasie nie było jeszcze nic gotowego do programowego zarządzania zasobami, takiego jak rekordy DNS czy przydzielanie adresów IP. Później zaczęliśmy eksperymentować z zewnętrznym przechowywaniem danych. Nigdy nie zabraliśmy się za wdrożenie sterownika PVC, ale już wtedy stało się jasne, że jest to duży obszar pracy wymagający oddanych specjalistów.
Przejście na Google Cloud Platform jest rozwiązaniem tymczasowym
Zdaliśmy sobie sprawę, że tak nie może być dalej, i przenieśliśmy nasze dane z wersji bare metal na Google Cloud Platform. Tak naprawdę w tamtym czasie dla rosyjskiej firmy nie było zbyt wielu ciekawych opcji: poza Google Cloud Platform podobną usługę oferował tylko Amazon, ale i tak zdecydowaliśmy się na rozwiązanie od Google. Wtedy wydawało nam się to bardziej opłacalne ekonomicznie, bliżej Upstreamu, nie mówiąc już o tym, że Google sam w sobie jest swego rodzaju PoC Kubernetes in Production.
Pierwszy poważny problem pojawił się na horyzoncie wraz ze wzrostem naszej bazy klientów. Kiedy pojawiła się potrzeba przechowywania danych osobowych, stanęliśmy przed wyborem: albo współpracujemy z Google i naruszamy rosyjskie prawo, albo szukamy alternatywy w Federacji Rosyjskiej. W sumie wybór był przewidywalny. 🙂
Jak widzieliśmy idealną usługę w chmurze
Już na początku poszukiwań wiedzieliśmy, czego chcemy uzyskać od przyszłego dostawcy chmury. Jakiej usługi szukaliśmy:
- Szybki i elastyczny. Tak, abyśmy w każdej chwili mogli szybko dodać nowy węzeł lub coś wdrożyć.
- Niedrogi. Byliśmy bardzo zaniepokojeni kwestiami finansowymi, ponieważ mieliśmy ograniczone zasoby. Wiedzieliśmy już, że chcemy współpracować z Kubernetesem, a teraz zadaniem była minimalizacja jego kosztów, aby zwiększyć lub przynajmniej utrzymać efektywność wykorzystania tego rozwiązania.
- zautomatyzowany. Planowaliśmy pracować z usługą poprzez API, bez menadżerów i rozmów telefonicznych czy sytuacji, w których musimy ręcznie podnieść kilkadziesiąt węzłów w trybie awaryjnym. Ponieważ większość naszych procesów jest zautomatyzowana, tego samego oczekiwaliśmy od usługi w chmurze.
- Z serwerami w Federacji Rosyjskiej. Oczywiście planowaliśmy przestrzegać rosyjskiego ustawodawstwa i tego samego 152-FZ.
W tamtym czasie w Rosji było niewielu dostawców Kubernetes aaS i przy wyborze dostawcy ważne było dla nas, aby nie iść na kompromis w stosunku do naszych priorytetów. Zespół Mail.ru Cloud Solutions, z którym rozpoczęliśmy współpracę i nadal współpracujemy, zapewnił nam w pełni zautomatyzowaną usługę, ze wsparciem API i wygodnym panelem kontrolnym obejmującym Horizon - dzięki niemu mogliśmy szybko podnieść dowolną liczbę węzłów.
Jak udało nam się przeprowadzić migrację do MCS w dwie godziny
W przypadku takich posunięć wiele firm boryka się z trudnościami i niepowodzeniami, ale w naszym przypadku nie było żadnych. Mieliśmy szczęście: ponieważ pracowaliśmy już na Kubernetesie przed rozpoczęciem migracji, po prostu poprawiliśmy trzy pliki i uruchomiliśmy nasze usługi na nowej platformie chmurowej MCS. Przypomnę, że do tego czasu w końcu porzuciliśmy goły metal i żyliśmy na Google Cloud Platform. Dlatego sama przeprowadzka zajęła nie więcej niż dwie godziny, plus trochę więcej czasu (około godziny) poświęcono na kopiowanie danych z naszych urządzeń. Już wtedy korzystaliśmy ze Spinnakera (usługi CD obejmującej wiele chmur, zapewniającej ciągłe dostarczanie). Szybko dodaliśmy go również do nowego klastra i kontynuowaliśmy pracę jak zwykle.
Dzięki automatyzacji procesów deweloperskich i CI/CD Kubernetes w URUS obsługiwany jest przez jednego specjalistę (czyli mnie). Na pewnym etapie współpracował ze mną inny administrator systemu, ale potem okazało się, że zautomatyzowaliśmy już całą główną procedurę, a zadań ze strony naszego głównego produktu było coraz więcej i sensowne było skierowanie na to zasobów.
Od dostawcy chmury otrzymaliśmy to czego oczekiwaliśmy, gdyż rozpoczęliśmy współpracę bez złudzeń. Jeśli zdarzyły się jakieś incydenty, to głównie techniczne i takie, które można łatwo wytłumaczyć względną świeżością usługi. Najważniejsze, że zespół MCS szybko eliminuje niedociągnięcia i szybko reaguje na pytania w komunikatorach.
Jeśli porównam swoje doświadczenia z Google Cloud Platform, w ich przypadku nawet nie wiedziałem, gdzie znajduje się przycisk opinii, ponieważ po prostu nie był on potrzebny. A jeśli wystąpią jakiekolwiek problemy, Google sam rozsyła powiadomienia jednostronnie. Jednak w przypadku MCS myślę, że dużą zaletą jest to, że są jak najbliżej rosyjskich klientów – zarówno pod względem geograficznym, jak i mentalnym.
Jak widzimy pracę z chmurami w przyszłości
Teraz nasza praca jest ściśle powiązana z Kubernetesem i całkowicie nam odpowiada z punktu widzenia zadań infrastrukturalnych. Dlatego też nie planujemy z niego nigdzie migrować, aczkolwiek cały czas wprowadzamy nowe praktyki i usługi mające na celu uproszczenie rutynowych zadań i automatyzację nowych, zwiększenie stabilności i niezawodności usług... Właśnie uruchamiamy usługę Chaos Monkey (a konkretnie , używamy chaoskube, ale to nie zmienia koncepcji: ), która została pierwotnie stworzona przez Netflix. Chaos Monkey robi jedną prostą rzecz: usuwa losowy pod Kubernetes w losowym momencie. Jest to konieczne, aby nasz serwis mógł normalnie funkcjonować przy liczbie instancji n–1, dlatego szkolimy się, aby być przygotowanym na wszelkie problemy.
Teraz widzę, że korzystanie z rozwiązań firm trzecich – tych samych platform chmurowych – jest jedyną słuszną rzeczą dla młodych firm. Zwykle na początku swojej podróży mają ograniczone zasoby, zarówno ludzkie, jak i finansowe, a budowanie i utrzymanie własnej chmury lub centrum danych jest zbyt kosztowne i pracochłonne. Dostawcy usług chmurowych pozwalają zminimalizować te koszty, można szybko pozyskać od nich zasoby niezbędne do działania usług tu i teraz, a za te zasoby zapłacić już po fakcie. Jeśli chodzi o firmę URUS, na razie pozostaniemy wierni Kubernetesowi w chmurze. Ale kto wie, może będziemy musieli rozszerzyć się geograficznie lub wdrożyć rozwiązania oparte na konkretnym sprzęcie. A może ilość zużywanych zasobów uzasadnia posiadanie Kubernetesa na bare-metalu, jak za starych, dobrych czasów. 🙂
Czego nauczyliśmy się pracując z usługami w chmurze
Zaczęliśmy używać Kubernetesa na gołym metalu i nawet tam było dobrze na swój sposób. Ale jego mocne strony zostały ujawnione właśnie jako komponent aaS w chmurze. Jeśli postawisz sobie cel i zautomatyzujesz wszystko tak bardzo, jak to możliwe, będziesz w stanie uniknąć uzależnienia od dostawcy, a przemieszczanie się między dostawcami usług w chmurze zajmie kilka godzin, a komórki nerwowe pozostaną z nami. Innym firmom możemy doradzić: jeśli chcesz uruchomić własną usługę (w chmurze), mając ograniczone zasoby i maksymalną prędkość rozwoju, zacznij już teraz, wynajmując zasoby w chmurze i zbuduj swoje centrum danych po tym, jak Forbes napisze o Tobie.
Źródło: www.habr.com