Firma „URUS” przetestowała Kubernetes w różnych odsłonach: samodzielne wdrożenie na sprzęcie fizycznym, w Google Cloud, a następnie przeniosła swoją platformę do chmury Mail.ru Cloud Solutions (MCS). O tym, jak wybierano nowego dostawcę chmury i jak udało się dokonać migracji w rekordowe dwie godziny, opowiada Igor Szyszkina (), starszy administrator systemów w firmie „URUS”.
Czym zajmuje się „URUS”
Istnieje wiele sposobów na poprawę jakości miejskiego środowiska, a jednym z nich jest uczynienie go ekologicznym. Nad tym właśnie pracuje firma „URUS – Inteligentne usługi cyfrowe”. Wdrażają tu rozwiązania, które pomagają firmom kontrolować istotne wskaźniki ekologiczne i zmniejszać 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 jedynej platformy „URUS – Ekomon” do analizy i opracowywania zaleceń.
Jak działa „URUS” od środka
Typowym klientem „URUSa” jest firma, która znajduje się w strefie mieszkalnej lub w jej pobliżu. Może to być fabryka, port, dworzec kolejowy lub jakikolwiek inny obiekt. Jeśli nasz klient otrzymał już ostrzeżenie, został ukarany za zanieczyszczanie środowiska lub chce sam generować mniej hałasu, zmniejszyć ilość szkodliwych emisji, zgłasza się do nas, a my proponujemy gotowe rozwiązanie w zakresie monitoringu ekologicznego.
Na wykresie monitoringu stężenia H2S widoczne są regularne nocne emisje pobliskiego zakładu
Urządzenia, które wykorzystujemy w „URUS”, zawierają kilka czujników, które zbierają informacje o zawartości określonych gazów, poziomie hałasu i inne dane do oceny sytuacji ekologicznej. Dokładna liczba czujników zawsze jest określona przez konkretne zadanie.
W zależności od specyfiki pomiarów, urządzenia z czujnikami mogą być umieszczane na ścianach budynków, słupach i w innych dowolnych miejscach. Każde takie urządzenie zbiera informacje, agreguje je i przesyła do bramy przyjmującej dane. Tam przechowujemy dane na długi okres i wstępnie je przetwarzamy do dalszej analizy. Najprostszy przykład tego, co otrzymujemy po analizie, to wskaźnik jakości powietrza, znany także jako AQI.
Równolegle na naszej platformie działa wiele innych usług, ale głównie mają one charakter serwisowy. Na przykład usługa powiadomień wysyła klientom informacje, jeśli któryś z monitorowanych parametrów (na przykład zawartość CO2) przekroczy dozwolony poziom.
Jak przechowujemy dane. Historia z Kubernetes na bare metal
W projekcie ekomonitoringu „URUS” istnieje kilka magazynów danych. W jednym przechowujemy „surowe” dane — to, co uzyskaliśmy bezpośrednio z urządzeń. Ten magazyn działa jak „taśma” magnetyczna, jak w starych kasetach, z historią wszystkich wskaźników. Drugi typ magazynu jest używany dla przetworzonych danych — danych z urządzeń, wzbogaconych o metadane dotyczące połączeń czujników oraz samych pomiarów, przynależności do organizacji, lokalizacji itd. Ta informacja pozwala dynamicznie ocenić, jak zmieniał się dany wskaźnik w określonym czasie. Magazyn „surowych” danych wykorzystujemy również jako kopię zapasową i do przywracania przetworzonych danych, jeśli zajdzie taka potrzeba.
Kiedy kilka lat temu szukaliśmy rozwiązania problemu z przechowywaniem, mieliśmy dwa warianty do wyboru: Kubernetes i OpenStack. Jednak ponieważ ten ostatni wygląda dość monumentalnie (wystarczy spojrzeć na jego architekturę, aby się o tym przekonać), zdecydowaliśmy się na Kubernetes. Innym argumentem na jego korzyść była względna prostota zarządzania programowego oraz możliwość bardziej elastycznego przydzielania zasobów nawet do fizycznych węzłów.
Równolegle z nauką samego Kubernetes, badaliśmy także sposoby przechowywania danych. Dopóki wszystkie nasze magazyny były trzymane w Kubernetes na naszym sprzęcie, zdobyliśmy doskonałą wiedzę fachową. Wszystko, co wtedy mieliśmy, działało właśnie na Kubernetesie: stateful store, system monitorowania, CI/CD. Kubernetes stał się dla nas platformą all-in-one.
Chcieliśmy jednak pracować z Kubernetes jak z usługą, a nie zajmować się jego wsparciem i rozwojem. Ponadto nie podobały nam się koszty związane z jego utrzymywaniem na sprzęcie. Wymagana była ciągła praca nad rozwojem! Na przykład jednym z pierwszych zadań było włączenie kontrolerów Ingress Kubernetes w sieciową infrastrukturę naszej organizacji. To złożone zadanie, zwłaszcza biorąc pod uwagę, że w tamtym czasie nie istniały żadne przygotowane rozwiązania do programowego zarządzania zasobami, takimi jak rekordy DNS czy wydzielanie. adresów IPPóźniej zaczęliśmy eksperymentować z zewnętrznym magazynem danych. Nigdy nie doszliśmy do implementacji kontrolera PVC, ale już wtedy było jasne, że oznacza to ogromną ilość pracy, dla której potrzeba było wyznaczyć specjalistów.
Przejście na Google Cloud Platform – rozwiązanie tymczasowe.
Zdaliśmy sobie sprawę, że tak dalej być nie może i przenieśliśmy nasze dane z bare metal do Google Cloud Platform. W rzeczywistości w tamtym czasie dla rosyjskiej firmy nie było zbyt wielu interesujących opcji: oprócz Google Cloud Platform, podobną usługę oferował tylko Amazon, ale ostatecznie zdecydowaliśmy się na rozwiązanie od Google. Wydawało się nam to bardziej opłacalne, bliższe Upstream, nie wspominając o tym, że Google sam w sobie jest swoistym PoC Kubernetes w Production.
Pierwszy poważny problem pojawił się na horyzoncie równocześnie z rosnącą bazą klientów. Kiedy potrzebowaliśmy przechowywać dane osobowe, stanęliśmy przed wyborem: albo pracujemy z Google i łamiemy rosyjskie prawo, albo szukamy alternatywy w Rosji. Wybór był w zasadzie przewidywalny. 🙂
Jak widzieliśmy idealną usługę chmurową.
Na początku poszukiwań już wiedzieliśmy, czego chcemy od przyszłego dostawcy chmurowego. Jaką usługę szukaliśmy:
- Szybka i elastyczna.Taka, abyśmy mogli w każdej chwili szybko dodać nowy węzeł lub coś uruchomić.
- Tania.Bardzo martwił nas aspekt finansowy, ponieważ byliśmy ograniczeni zasobami. Już wtedy wiedzieliśmy, że chcemy pracować z Kubernetes, a teraz naszym zadaniem było zminimalizowanie jego kosztów, aby zwiększyć lub przynajmniej zachować efektywność korzystania z tego rozwiązania.
- Zautomatyzowana.. Planowaliśmy pracować z serwisem przez API, bez menedżerów i telefonów, czy sytuacji, w których trzeba ręcznie uruchamiać dziesiątki węzłów w trybie awaryjnym. Ponieważ większość procesów u nas była zautomatyzowana, tego samego oczekiwaliśmy od chmurowego serwisu.
- Z serwerami w Rosji. Oczywiście, planowaliśmy przestrzegać rosyjskiego prawa i ustawy 152-FZ.
W tamtym czasie w Rosji było niewiele dostawców Kubernetes w modelu aaS, a przy wyborze dostawcy ważne było dla nas, aby nie rezygnować z naszych priorytetów. Zespół Mail.ru Cloud Solutions, z którym zaczęliśmy współpracować i współpracujemy do dziś, zapewnił nam w pełni zautomatyzowaną usługę, z obsługą API i wygodnym panelem zarządzania, w którym znajduje się Horizon — dzięki niemu mogliśmy szybko uruchomić dowolną liczbę węzłów.
Jak udało nam się migrować do MCS w dwie godziny
Podczas takich migracji wiele firm napotyka trudności i niepowodzenia, ale w naszym przypadku ich nie było. Mieliśmy szczęście: ponieważ przed migracją pracowaliśmy już na Kubernetesie, po prostu poprawiliśmy trzy pliki i uruchomiliśmy nasze usługi na nowej platformie chmurowej w MCS. Przypomnę, że w tym czasie ostatecznie przeszliśmy z bare metal i działaliśmy na Google Cloud Platform. Samo przeniesienie zajęło nie więcej niż dwie godziny, a dodatkowo około godziny potrzebowaliśmy na skopiowanie danych z naszych urządzeń. Wtedy już korzystaliśmy z Spinnakera (wielochmurowej usługi CD do zapewnienia ciągłej dostawy). Również szybko dodaliśmy go do nowego klastra i kontynuowaliśmy pracę w normalnym trybie.
Dzięki automatyzacji procesów rozwoju i CI/CD Kubernetesem w „URUS” zajmuje się jedna osoba (i to ja). Na pewnym etapie współpracował ze mną jeszcze jeden administrator systemów, ale potem okazało się, że całą rutynę już zautomatyzowaliśmy, a z naszej strony zadania związane z głównym produktem było coraz więcej i sensowne było skierowanie zasobów na to.
Otrzymaliśmy od dostawcy chmurowego to, czego oczekiwaliśmy, ponieważ rozpoczęliśmy współpracę bez złudzeń. Jeśli wydarzyły się jakieś incydenty, to w większości techniczne i takie, które łatwo wyjaśnić względną nowością serwisu. Najważniejsze, że zespół MCS szybko eliminuje niedociągnięcia i szybko reaguje na pytania w komunikatorach.
Porównując doświadczenia z Google Cloud Platform, w ich przypadku nawet nie wiedziałem, gdzie znajduje się przycisk do kontaktu, ponieważ nie było takiej potrzeby. Gdy pojawiały się jakieś problemy, Google samo wysyłało powiadomienia w trybie jednostronnym. Natomiast w przypadku MCS dużym plusem uważam to, że są maksymalnie blisko rosyjskich klientów — zarówno pod względem terytorialnym, jak i mentalnym.
Jak widzimy przyszłość pracy z chmurami
Obecnie nasza praca jest mocno związana z Kubernetesem i w pełni spełnia nasze potrzeby w zakresie zadań infrastrukturalnych. Dlatego nie planujemy migracji gdzie indziej, choć stale wprowadzamy nowe praktyki i usługi w celu uproszczenia rutynowych zadań i automatyzacji nowych, zwiększenia stabilności i niezawodności usług… Obecnie uruchamiamy usługę Chaos Monkey (a konkretnie używamy chaoskube, ale to nie zmienia koncepcji :), która pierwotnie została stworzona w Netflixie. Chaos Monkey wykonuje jedną prostą rzecz: w losowym czasie usuwa losowy pod w Kubernetesie. Jest to ważne, aby nasza usługa poprawnie działała z liczbą instancji n–1, w ten sposób uczymy się być gotowi na wszelkie awarie.
Obecnie widzę wykorzystanie rozwiązań zewnętrznych — takich jak chmurowe platformy — jako jedynie słuszne dla młodych firm. Zazwyczaj na początku drogi są one ograniczone zasobami, zarówno kadrowymi, jak i finansowymi, a budowanie i utrzymywanie własnej chmury czy centrum danych jest zbyt kosztowne i pracochłonne. Dostawcy chmur pozwalają zminimalizować te koszty, można szybko uzyskać zasoby niezbędne do działania usług tutaj i teraz, płacąc za nie w momencie wykorzystania. Jeśli chodzi o firmę „УРУС”, na razie pozostaniemy wierni Kubernetesowi w chmurze. Ale kto wie, może będziemy musieli się rozszerzyć geograficznie lub wdrożyć rozwiązania oparte na jakimś specyficznym sprzęcie. A może ilość zużywanych zasobów usprawiedliwi utworzenie własnego Kubernetes na bare-metal, jak za dawnych dobrych czasów. 🙂
Co wyciągnęliśmy z doświadczeń pracy z usługami chmurowymi
Zaczęliśmy korzystać z Kubernetesa na infrastrukturze bare metal, i nawet tam sprawdził się bardzo dobrze. Jednak jego mocne strony ujawniają się najlepiej jako komponent aaS w chmurze. Jeśli postawimy sobie cel i maksymalnie zautomatyzujemy wszystko, uda się uniknąć vendor lock-in, a migracja między dostawcami chmury zajmie tylko kilka godzin, a nasze nerwy pozostaną w nienaruszonym stanie. Inne firmy mogą od nas usłyszeć: jeśli chcecie uruchomić swój (chmurowy) serwis, mając ograniczone zasoby i maksymalną prędkość rozwoju — zacznijcie teraz od wynajmu zasobów chmurowych, a swoje centrum danych budujcie dopiero po tym, jak napisze o was Forbes.
Źródło: habr.com
