Znasz Kubernetesa? Nie? Wracaj do jaskini! Teraz wszyscy mają “kubki”.
Takie i podobne zdania można usłyszeć na wielu konferencjach i meetupach branżowych oraz przeczytać na blogach, w sieciach społecznościowych i forach. Jednym zdaniem – nie mając Kubernetesa (K8s) nie zrobisz dobrego softu. Ale czy ktoś zastanowił się, po co właściwie Google zainwestował tyle pieniędzy w jego rozwój?
Borg wiecznie żywy
Na początek kilka faktów. Google nie stoi na K8s. Niektórzy mogą być zdziwieni, że Google używa do uruchamiania swoich serwisów (bardzo możliwe, że również K8s) projektu o nazwie Borg, który docelowo miał być zastąpiony przez projekt Omega – zmienia on zupełnie podejście do rezerwowania zasobów.
Kolejny fakt: K8s nie był pierwszym otwartym zarządcą zasobów. Kilka lat temu na rynku mieliśmy dostępnych wiele tego typu rozwiązań. Powszechnie znanym i używanym był OpenStack. Chociaż w rzeczywistości skupia się on na uruchamianiu maszyn wirtualnych, formalnie zajmuje się zarządzaniem dostępnymi zasobami. Inne przykłady to:
- Mesos – powiedziałbym, że była to pierwsza otwarta implementacja Borga, powstała ona na potrzeby Twittera, ale później została przekazana do fundacji Apache. Obecnie poza Twitterem napędza również takie firmy jak Uber, Apple, Verizon, Yelp czy Allegro oraz wiele innych).
- Docker Swarm – zbudowany przez Dockera, żeby jeszcze lepiej sprzedawać jego kontenery
- Helios – stworzony przez Spotify do zarządzania ich serwisami (porzucony po przejściu Spotify na infrastrukturę Googla)
- Nomad – system od Hashicorp idealnie wpisujący się w ich ecosystem aka Hashicorp Enterprise Suite.
Chociaż wszystkie wymienione przykłady są podobne, trudno je porównać (ale można), bo skupiają się na różnych przypadkach użycia. Ich zastosowanie jest do tego stopnia różne, że Mesosa można uruchomić na OpenStacku, na Mesosie postawić K8s, a na nim Openstacka.
Obecnie K8s jest chyba najpowszechniej stosowanym rozwiązaniem do zarządzania kontenerami. Na tyle zdominował rynek, że Docker Swarm wprowadził wsparcie dla niego. W jaki sposób powinniśmy mierzyć popularność rozwiązania? Ilością instalacji? Wielkością klastrów? Rozmiarem społeczności? W swoich początkach K8s był bardzo ograniczony i to nie jeśli chodzi o funkcjonalność, a o maksymalne rozmiary klastrów, którymi potrafił zarządzać. Na początku było to ledwie kilkaset serwerów [sic!].
Wciąż jest to poniżej 5000 maszyn. Jednak jeśli liczyć rozmiar społeczności, trudno konkurować z K8s. Ponad 15 tysięcy forków i prawie 50 tysięcy gwiazdek. Siłą K8s jest ogromna rzesza deweloperów, oraz błogosławieństwo dużej firmy – i to niejednej.
CNCF
Kod K8s jet otwarty. Pracuje nad nim wielu programistów, ale kto jest jego właścicielem? Mamy tu do czynienia z ciekawym zabiegiem. Wiele firm przekazywało swoje projekty różnym fundacją np. Apache albo Eclipse. Google powołał do życia zupełnie nowy twór o nazwie Cloud Native Foundation (CNCF) (pod patronatem Linux Foundation) i razem z innymi firmami finansuje jej działania. Co ciekawe w odróżnieniu od Apache foundation CNCF zatrudnia również deweloperów i ewangelistów technologi, którym patronuje. Warto zaznaczyć, że Google powoli stara się odcinać od K8s, jednak wciąż ma giagntyczny wpływ na jego rozwój.
#GIFEE
Wypuszczeniu Kubernetesa towarzyszyła akcja marketingowa znana jakoa #GIFEE, czyli Infrastruktura Googla dla Wszystkich (ang. Google Infrastructure for Everyone Else). Ciekawe, biorąc pod uwagę fakt, że sam Google nie używa K8s. Jednak marketingowo był to świetny zabieg. Przecież skoro Google tego używa, to czemu nie my? Jeśli też masz takie problemy, pamiętaj: nie jesteś Googlem (chyba, że jesteś, ale wtedy nie czytasz tego Bloga, bo wiesz, po co Ci Kubernetes).
Kolejnym zabiegiem było skupienie się na budowaniu bazy użytkowników zamiast rozwoju kodu. Bardzo szybko Kubernetes został zaadoptowany przez małe firmy, które potrzebowały raptem kilku do kilkunastu węzłów w swoich klastrach. Dzięki temu zamiast ubiegać się o miano rozwiązania Enterprise wszedł pod strzechy i każdy mógł zbudować własny klaster na RaspberryPi.
Chmura ☁
“Trzymaj się swoich chmur.” –– Andrzej Poniedzielski
Powoli dochodzimy do najważniejszego powodu, dla którego Google zrobił K8s – GCP, czyli Google Cloud Platform. Gdy Google wchodził do gry o publiczną chmurę, na rynku rządził Amazon Web Services (AWS), który nadal trzyma lwią część rynku i przez niektórych jest określany jako swoisty podatek (a wszelkie startupy to po prostu rura z pieniędzmi od inwestorów do AWSa). Kto raz wszedł w AWSa, prędko z niego nie wyjdzie. Oczywiście są firmy, które świadomie bronią się przed zbytnim uzależnieniem się od dostawcy infrastruktury, jednak to zdecydowana mniejszość. Żal nie używać dostarczonych usług, które działają znacznie lepiej niż cokolwiek, co sami stworzymy – nawet jeśli są trochę droższe. Podobnie jest z dowolnym innym dostawcą. Konkurencja na tym rynku podobna jest tej na stacjach benzynowych, które nie zarabiają na swoim głównym produkcie (paliwie), lecz na usługach dodanych.
Kubernetes == Kindle
Krok, na który zdecydował się Google, był bardzo interesujący. Po wypuszeczniu K8s wprowadził wsparcie dla niego na swojej platformie GKE (Google Containers Engine przemianowane na Google Kubernetes Engine). Najciekawsze jest to, że tę zagrywkę skopiował od… Amazona. Kubernetes jest mianowicie dla GCP tym samym, czym Kindle dla Amazona (nie mylić z AWS).
Amazon sprzedaje czytniki po niższej cenie z nadzieją, że klienci będą kupować w jego sklepie. Dlaczego mieliby to robić, skoro mogą kupić książki gdzie indziej? Odpowiedź jest prosta – po prostu sklep Amazona oferuje najlepszą integrację z czytnikami. Co więcej, działa wyśmienicie na samym czytniku. Podobnie jest z Kubernetes. Można go uruchomić na każdej infrastrukturze i klient może go po prostu sobie wziąć za darmo. Jednak K8s najlepiej działa na infrastrukturze Google.
K8s ma otwarty kod – użytkownicy nie boją się, że zostaną zamknięci (nawet jeśli zostaną) bo w teorii mogą przenieść klaster gdziekolwiek i będzie działał tak samo dobrze. Dodatkowo Google dostaje zupełnie za darmo mnóstwo deweloperów, którzy pracując dla innych firm testują, zgłaszają i poprawiają błędy oraz rozwijają K8s o nowe funkcjonalności. Ta praca jest nie do przecenienia. Kubernetes stał się tak popularny, że inni usługodawcy (np: AWS, AKS) wprowadzili go do swojej oferty rezygnując z rozwijania własnych rozwiązań.
Na koniec warto zastanowić się, co to znaczy dla nas. Czy Kubernetes jest zły? Oczywiście nie, warto go używać, bo dzięki olbrzymiej społeczności i możliwości kontrybucji dostajemy dobrze działający kawał oprogramowania, który zgodnie z prawem Linusa powinien mieć minimalną ilość błędów. Co więcej, obecnie został zaadoptowany w większości rozwiązań i powoli staje się standardem orkiestracji kontenerów. Warto jednak zdawać sobie sprawę z celu, w jakim ten projekt został stworzony.
„Jeśli mamy wystarczająco oczu, wszystkie bugi są powierzchowne.” –– Prawo Linusa