Hej Habra!
Reprezentujemy zespół platformy Exness. Wcześniej nasi koledzy napisali już artykuł na temat . Dziś chcemy podzielić się naszym doświadczeniem z migracji usług do Kubernetes.
Na początek oferujemy kilka liczb, aby lepiej zrozumieć, co zostanie omówione:
- Nasz dział rozwoju składa się z ponad 100 osób, w tym ponad 10 różnych zespołów z samowystarczalnymi procesami QA, DevOps i Scrum. Stos programistyczny - Python, PHP, C++, Java i Golang.
- Wielkość środowiska testowego i produkcyjnego to około 2000 kontenerów każde. Używają Ranchera v1.6 na własnej wirtualizacji i pod VMware.
Motywacja
Jak to mówią nic nie trwa wiecznie, a Rancher już dawno ogłosił koniec wsparcia dla wersji 1.6. Tak, w ciągu ponad trzech lat nauczyliśmy się go przygotowywać i rozwiązywać problemy, które się pojawiają, jednak coraz częściej spotykamy się z problemami, które nigdy nie zostaną naprawione. Rancher 1.6 posiada również skostniały system wydawania uprawnień, w którym można albo zrobić prawie wszystko, albo nic.
Choć autorska wirtualizacja zapewniała większą kontrolę nad przechowywaniem danych i ich bezpieczeństwem, to jednak narzucała koszty operacyjne, które były trudne do zaakceptowania ze względu na ciągły rozwój firmy, liczbę projektów i stawianych im wymagań.
Chcieliśmy postępować zgodnie ze standardami IaC i w razie potrzeby szybko pozyskać pojemność, w dowolnej lokalizacji geograficznej i bez blokady dostawcy, a także móc szybko z niej zrezygnować.
Pierwsze kroki
Przede wszystkim chcieliśmy postawić na nowoczesne technologie i rozwiązania, które pozwolą zespołom mieć szybszy cykl rozwoju i zminimalizować koszty operacyjne interakcji z platformą zapewniającą moc.
Oczywiście pierwszą rzeczą, która przyszła nam do głowy był Kubernetes, ale nie ekscytowaliśmy się i zrobiliśmy mały research, aby sprawdzić, czy był to słuszny wybór. Ocenialiśmy tylko rozwiązania open source i w nieuczciwej bitwie Kubernetes bezwarunkowo zwyciężył.
Następnie pojawiła się kwestia wyboru narzędzia do tworzenia klastrów. Porównaliśmy najpopularniejsze rozwiązania: kops, kubespray, kubeadm.
Na początek kubeadm wydawał nam się zbyt skomplikowaną ścieżką, raczej czymś w rodzaju wynalazcy „roweru”, a kops nie miał wystarczającej elastyczności.
A zwycięzcą został:
Zaczęliśmy eksperymentować z naszą własną wirtualizacją i AWS, próbując odtworzyć coś mniej więcej podobnego do naszego poprzedniego wzorca zarządzania zasobami, w którym wszyscy dzielili ten sam „klaster”. A teraz mamy nasz pierwszy klaster składający się z 10 małych maszyn wirtualnych, z których kilka znajduje się w AWS. Zaczęliśmy próbować przenieść tam zespoły, wszystko wydawało się „w porządku” i historia mogła się zakończyć, ale…
Pierwsze problemy
Kubespray jest zbudowany na Ansible, nie jest to narzędzie, które pozwala śledzić IaC: podczas uruchamiania/likwidowania węzłów coś ciągle szło nie tak i wymagana była jakaś interwencja, a podczas korzystania z różnych systemów operacyjnych podręcznik zachowywał się inaczej. . W miarę wzrostu liczby zespołów i węzłów w klastrze zaczęliśmy zauważać, że ukończenie podręcznika zajmowało coraz więcej czasu, w wyniku czego nasz rekord wyniósł 3,5 godziny. A Twój? 🙂
I wygląda na to, że kubespray to po prostu Ansible i na pierwszy rzut oka wszystko jest jasne, ale:
Na początku podróży zadaniem było uruchomienie możliwości tylko w AWS i na wirtualizacji, ale potem, jak to często bywa, wymagania się zmieniły.
W świetle tego stało się jasne, że nasz stary schemat łączenia zasobów w jeden system orkiestracji nie jest odpowiedni – w przypadku, gdy klastry są bardzo odległe i zarządzane są przez różnych dostawców.
Ponadto. Kiedy wszystkie zespoły pracują w tym samym klastrze, różne usługi z niepoprawnie zainstalowanymi NodeSelectorami mogły polecieć do „obcego” hosta innego zespołu i wykorzystać tam zasoby, a jeśli ustawiono skażenie, ciągle pojawiały się żądania, że ta czy inna usługa nie działa, nie zostały prawidłowo rozłożone ze względu na czynnik ludzki. Kolejnym problemem było obliczenie kosztu, szczególnie biorąc pod uwagę problemy z dystrybucją usług pomiędzy węzłami.
Osobną historią było nadanie uprawnień pracownikom: każdy zespół chciał być „na czele” klastra i całkowicie nim zarządzać, co mogłoby spowodować całkowity upadek, gdyż zespoły są w zasadzie od siebie niezależne.
Co robić?
Biorąc pod uwagę powyższe oraz życzenia większej niezależności zespołów, wyciągnęliśmy prosty wniosek: jeden zespół – jeden klaster.
Mamy więc drugi:
A potem trzecia grupa:
Wtedy zaczęliśmy się zastanawiać: powiedzmy, że za rok nasze zespoły będą miały więcej niż jeden klaster? Na przykład w różnych obszarach geograficznych lub pod kontrolą różnych dostawców? Część z nich będzie chciała mieć możliwość szybkiego wdrożenia klastra tymczasowego na potrzeby niektórych testów.
Przydałby się pełny Kubernetes! Okazuje się, że jest to swego rodzaju MultiKubernetes.
Jednocześnie wszyscy będziemy musieli jakoś utrzymać te wszystkie klastry, móc łatwo zarządzać do nich dostępem, a także tworzyć nowe i likwidować stare bez ręcznej interwencji.
Od początku naszej podróży po świecie Kubernetesa minęło już trochę czasu i postanowiliśmy ponownie przyjrzeć się dostępnym rozwiązaniom. Okazało się, że istnieje już na rynku – Rancher 2.2.
Na pierwszym etapie naszych badań Rancher Labs wydało już pierwszą wersję wersji 2, ale chociaż można ją było bardzo szybko podnieść, uruchamiając kontener bez zewnętrznych zależności z kilkoma parametrami lub korzystając z oficjalnego wykresu HELM, wydawało się to prymitywne do nas i nie wiedzieliśmy, czy na tej decyzji możemy polegać, czy zostanie ona rozwinięta, czy też szybko porzucona. Paradygmat klaster = kliknięcia w samym interfejsie również nam nie odpowiadał i nie chcieliśmy wiązać się z RKE, ponieważ jest to narzędzie raczej wąsko ukierunkowane.
Wersja Rancher 2.2 miała już bardziej funkcjonalny wygląd i wraz z poprzednimi posiadała od razu kilka ciekawych funkcji, takich jak integracja z wieloma zewnętrznymi dostawcami, pojedynczy punkt dystrybucji praw i plików kubeconfig, uruchomienie kubectl obraz z Twoimi uprawnieniami w interfejsie użytkownika, zagnieżdżone przestrzenie nazw, czyli projekty.
Wokół Ranchera 2 utworzyła się już społeczność, a do zarządzania nią utworzono dostawcę o nazwie HashiCorp Terraform, co pomogło nam wszystko połączyć w jedną całość.
Co się stało
W rezultacie otrzymaliśmy jeden mały klaster z Rancherem, dostępny dla wszystkich innych klastrów, a także wiele klastrów z nim połączonych, a dostęp do dowolnego z nich można przyznać tak prosto, jak dodanie użytkownika do katalogu ldap, niezależnie od gdzie się znajduje i z jakich zasobów dostawcy korzysta.
Wykorzystując gitlab-ci i Terraform stworzono system pozwalający na utworzenie klastra o dowolnej konfiguracji u dostawców chmury lub własnej infrastrukturze i podłączenie ich do Ranchera. Wszystko to odbywa się w stylu IaC, gdzie każdy klaster jest opisany przez repozytorium, a jego stan jest wersjonowany. Jednocześnie większość modułów jest podłączona z zewnętrznych repozytoriów, więc pozostaje tylko przekazać zmienne lub opisać własną konfigurację dla instancji, co pomaga zmniejszyć procent powtórzeń kodu.
Oczywiście nasza podróż jeszcze się nie skończyła i przed nami jeszcze wiele ciekawych zadań, takich jak pojedynczy punkt pracy z logami i metrykami dowolnych klastrów, siatka usług, gitopy do zarządzania obciążeniami w multiklastrze i wiele więcej. Mamy nadzieję, że nasze doświadczenie będzie dla Ciebie interesujące!
Artykuł napisali A. Antipov, A. Ganush, Inżynierowie Platformy.
Źródło: www.habr.com