Wdrożenie Kubernetes w przedsiębiorstwie – najczęściej zadawane pytania
Kubernetes to system open-source do automatyzacji wdrażania, skalowania i zarządzania skonteneryzowanymi aplikacjami. System był rozwijany w Google na wzór Borga, innego narzędzia wykorzystywanego w tej firmie do zarządzania klastrami. Głównym zadaniem Kubernetes jest grupowanie i orkiestracja kontenerów, czyli wykonywalnego kodu wraz ze wszystkimi zależnościami, który może być wdrożony na dowolnej infrastrukturze IT a później swobodnie przenoszony – to niezwykle istotne w dobie cloud culture. Takie grupowanie kontenerów w logiczne jednostki ułatwia zarządzanie i ich odkrywanie, co ma z kolei szczególne znacznie w przypadku dużych aplikacji korporacyjnych, które mogą składać się z setek czy nawet tysięcy kontenerów.
Firmy są zainteresowane wdrożeniem Kubernetes, ponieważ większość dużych organizacji to dzisiaj, przynajmniej w pewnej mierze, producenci oprogramowania. Aplikacje stały się fundamentem działania nowoczesnych przedsiębiorstw. Kontenery ułatwiają rozwiązywanie problemów, które pojawiają się zwykle w takiej sytuacji: przyspieszają dostarczanie oprogramowania, ułatwiają aktualizacje i modernizację programów czy zarządzanie kodem w skali całego cyklu użytkowania aplikacji
Z pewnością wdrożenie Kubernetes nie jest jednak zadaniem prostym. W poniższym tekście postaramy się odpowiedzieć na najczęściej zadawane przez firmy pytania stawiane w związku z takim projektem.
Czy warto wdrożyć Kubernetes w przedsiębiorstwie?
Niewątpliwie warto, zwłaszcza, że jeśli firma produkuje duże ilości oprogramowania i chce robić to jeszcze szybciej, łatwiej i bezpieczniej. Niemniej warto podkreślić już w tym miejscu, że Kubernetes jako platforma orkiestracji kontenerów nie jest panaceum na wszelkie zło związane z budowaniem i zarządzaniem aplikacjami. Sam Kubernetes to duży pojazd, którym będziemy transportować różne rzeczy. Jeśli nie mamy jednak czego wozić, to kupowanie takiego pojazdu nie ma sensu.
„Kubernetes to tylko narzędzie, którego instalacja w firmowym środowisku nie sprawi magicznie, że będziemy uruchamiać aplikacje niwelując wszystkie problemy powstające w skali całego cyklu ich życia. Potrzebny jest jeszcze framework, aplikacje wspierające i wiele innych drobnych elementów. Samo wdrożenie Kubernetes to tylko początek drogi do usprawniania developmentu” – mówi Łukasz Sztachański, Cloud Engineer w Mindbox.
Jak przebiega proces wdrożenia Kubernetes w firmie?
Zasadniczo mamy do wyboru dwie drogi: budowanie Kubernetes od podstaw albo użycie rozwiązania komercyjnego, takiego jak np. OpenShift, który jest dzisiaj de facto standardem. Zacznijmy od tej drugiej opcji. Komercyjni dostawcy zapewniają gotową receptę na idealny zestaw technologii, które stworzą platformę Kubernetes. Ogromną zaletą tego podejścia jest to, że cały proces instalacji jest maksymalnie uproszczony. Finalnie otrzymujemy platformę, która wspiera wszystkie procesy DevOps i łatwo można z niej korzystać.
Najczęściej używaną, najbardziej popularną platformą bazującą na Kubernetesie jest OpenShift. Zaproponowany przez RedHat stos technologiczny jest [i]optymalny. Posiada komponenty do logowania zdarzeń, oferuje panel graficzny, kompletne rozwiązania dla baz danych oraz platformę do rozwoju oprogramowania.
Niewątpliwym minusem wyboru gotowego rozwiązania, poza kosztem licencji, który jest nietrywialny, jest jednak to, że gotowa recepta, pomimo tego, że bardzo dobra, nie pasuje jednak do wszystkich zastosowań.
Ten problem rozwiązuje podejście polegające na zbudowaniu Kubernetesa od zera. Pozwala bowiem stworzyć idealnie dopasowaną do potrzeb i wymagań firmy platformę. Wymaga jednak posiadania ludzi, którzy mają bogatą wiedzę i doświadczenie oraz silnej edukacji. Dodatkowo potrzeba znacznie więcej czasu niż w przypadku wdrażania rozwiązania komercyjnego.
Ile czasu potrzeba w obu przypadkach? „Zakładając, że nie ma żadnych ograniczeń w środowisku organizacji, które mogłyby opóźniać wdrożenie, takich jak np. brak dostępu do pewnych systemów, to platformę bazującą na gotowym rozwiązaniu można wdrożyć w tydzień. Na instalację potrzeba kilka godzin, ale później trzeba jeszcze dostosować platformę do firmowego środowiska. Po tygodniu zespoły programistycznie przy minimalnym tarciu mogą wdrażać aplikacje na uruchomiony klaster przy pomocy procesu CI/CD (Continuous Integration/Continuous Delivery). Oczywiście także w tym przypadku potrzebna jest wiedza ekspercka dotycząca integracji centrum uwierzytelniania czy konfiguracji ustawień sieciowych, ale wszystko to jest relatywnie proste w porównaniu do budowania od podstaw, które może potrwać kilka miesięcy. Zbudowanie platformy o funkcjonalnościach porównywalnych z rozwiązaniami komercyjnymi oceniłbym na dwa miesiące” – komentuje Łukasz Sztachański.
Jakie są symptomy źle wdrożonego Kubernetes?
Podstawowym założeniem architektury Kubernetes jest pełna, zautomatyzowana redundancja infrastruktury i działających aplikacji. Dlatego wszelkie awarie powinny być praktycznie niezauważalne. Przy tym konfiguracja platformy powinna być utrzymywana w kodzie. Nikt nie powinien niczego robić manualnie. Całe zarzadzanie i rozwój platformy powinno odbywać się z poziomu kodu. Dzięki temu, jeśli nagle z dowolnego powodu nasza aplikacja znika, to ten sam klaster z tą samą konfiguracją i aplikacjami jesteśmy w stanie zestawić w innym centrum danych w ciągu kilku godzin, ponieważ mamy już receptę, którą przygotowaliśmy wcześniej.
Jeśli jednak nadal posiadamy pojedynczy punkt awarii albo zauważamy awarie części centrum danych to jest to coś niepokojącego, coś co sugeruje, że wdrożenie Kubernetes nie poszło po naszej myśli. Podobnie jest z aplikacjami. Jeśli są napisane w sposób, który nie pozwala na przenoszenie ich bez zauważalnego przestoju na inną część klastra Kubernetes, to znaczy że mamy problem. Przy dobrym wdrożeniu powinniśmy być odporni na awarie.
Czym odznacza się dobrze wdrożony Kubernetes?
Przeciwnie, jeśli jesteśmy odporni na awarie, nie trzeba działać manualnie i można szybko odtwarzać konfiguracje. Jeśli jesteśmy w stanie wycofywać eksperymentalne zmiany, to znaczy, że najprawdopodobniej wszystko działa znakomicie.
„Zadajmy sobie kilka pytań dotyczących wykorzystania naszego klastra Kubernetes. Przykładowo: czy mamy procesy CI/CD przy tworzeniu oprogramowania? Albo: czy dostarczamy oprogramowanie w szybki i zautomatyzowany sposób? Odpowiadając sobie na takie pytania, szybko dowiemy się czy mamy dobrze wdrożony Kubernetes” – mówi Łukasz Sztachański.
Strategie wdrażania Kubernetes
Przygotowując się do wdrożenia organizacja ma zasadniczo dwie strategie do wyboru: Big Bang lub selekcja jednego projektu. Pierwsza opcja to całkowita, gwałtowna rewolucja, budowa jednej platformy, na którą przeniesiemy wszystkie projekty programistyczne. Od ustalonego momentu wszystkie aplikacje będą działać na tej platformie (lub kilku platformach wykorzystywanych w organizacji). W jednej chwili zaprzestajemy rozwoju oprogramowania w starym modelu i przechodzimy na nowy. Programiści mają jeden punkt interakcji. To z jednej strony dobre rozwiązanie. Oferuje wysoki potencjalny zysk, ale jest obarczone jednocześnie wysokim ryzykiem porażki. Bardzo szybko spłacamy dług technologiczny, ale wymuszamy coś na organizacji i testujemy na żywym organizmie. Czasem może powinąć się noga.
Drugi model polega na wyborze jednego projektu. Przykładowo w banku może to być czat dla klientów. Dla tego jednego elementu w całym firmowym środowisku tworzymy szablon, który będzie opisywał jak stworzyć platformę, jak ją zainstalować, jak pisać kod i jakie narzędzia CI/CD zastosujemy. Po zbudowaniu takiej platformy wraz ze wszystkimi dodatkowymi elementami, uruchomimy nową aplikację czatu z klientami. Później ten sam szablon możemy odtworzyć dla innego projektu w organizacji np. w przypadku naszego banku może to być aplikacja wspierająca wyświetlanie salda czy interakcje z BIK.
Wdrożenie Kubernetes vs Docker
Docker to silnik do uruchamiania kontenerów. Kubernetes to orkiestrator kontenerów, kompletny, złożony system, który dba o to, żeby kontenery zachowały stan opisany przez programistów. Przykładowo, jeśli zespół programistów ustali, że ich aplikacja skonteneryzowana przy pomocy Dockera ma działać w czterech kopiach, to platforma Kubernetes będzie odpowiedzialna za to, żeby zostały one uruchomione i cały czas będzie utrzymywać te cztery kopie. W przypadku awarii Kubrenets zareaguje w odpowiedni sposób i uruchomi kolejną kopię. Oczywiście te mechanizmy są o wiele bardziej skomplikowane, topologia może być bardziej skomplikowana, można tworzyć bardziej skomplikowane reguły, ale zasada się zawsze ta sama.
„Jeszcze do niedawna na polu orkiestracji kontenerów można było mówić o konkurencji. Alternatywą był np. Docker Swarm, ale oferował on, podobnie jak inni konkurenci o wiele mniej niż Kubernetes. I właśnie dlatego Kubernetes stał się dzisiaj de facto standardem” – podsumowuje Łukasz Sztachański.
Porozmawiajmy!
a my pomożemy Ci wdrożyć najnowsze rozwiązania!
Podobne wpisy:
Migracja do Chmury – najważniejsze kroki
Hybrid Cloud – czy takie rozwiązanie będzie przydatne w przedsiębiorstwie?
WebAssembly (WASM) – czy to rewolucja ukryta w przeglądarce?
Low code, czyli czy platformy niskokodowe są przyszłością tworzenia oprogramowania?