Już od pewnego czasu Kubernetes umacnia się jako de facto platforma orkiestracji kontenerów, a Docker pomaga mu to osiągnąć. Docker był już od jakiegoś czasu wiodącą technologią kontenerową, ale sytuacja na rynku orkiestracji kontenerów nie była tak jasna. Zmieniło się to pod koniec 2017 roku wraz z dołączeniem oferty Kubernetes przez największych dostawców platform chmurowych, w tym Dockera, oraz kilku zaskakujących nowych uczestników Cloud Native Computing Foundation (CNCF). Jak do tego doszło? Zobaczmy.
Kubernetes
Stworzony przez Google, Kubernetes (znany również jako K8s) został zaprojektowany w oparciu o wcześniejsze zastrzeżone przez Google platformy orkiestracji (projekt Borg). Po wydaniu wersji V1.0 w lipcu 2015 roku, Google nawiązało współpracę z Linux Foundation w celu utworzenia CNCF, a Kubernetes został przekazane jako projekt, od którego wszystko miało się zacząć.
Prace te przyniosły owocne rezultaty. Jako technologia open source, w ciągu ostatnich niespełna czterech lat Kubernetes wyrósł na najważniejszy, niejako domyślny, mechanizm orkiestracji dla rozwiązań kontenerowych. Choć robi wrażenie, czy jest to niespodzianka? Mimo tego, że K8s został przekazany jako wersja 1.0, był to projekt z dziesięcioletnim doświadczeniem we wdrażaniu kontenerów na masową skalę w Google. A kto nie chce być jak Google?
Spójrzmy na wzrost liczby wyszukiwań frazy „kubernetes” w Google w ciągu ostatnich kilku lat.
Nie wszyscy mamy zasoby lub talent, który Google ma do swojej dyspozycji. Kontenery Linux (LXC), które Google uruchamia na Kubernetes, nie są łatwe w obsłudze i wymagają dodatkowej wiedzy eksperckiej do opanowania.
Docker
Docker, który pojawił się przed Kubernetesem, sprawił, że kontenery są lepsze i łatwiejsze w użyciu. Promowany przez firmę Docker, Inc., jest w zasadzie rozszerzeniem możliwości LXC, ale dodaje szereg nowych funkcji. Obejmują one deploymenty przenośne między maszynami, ich wersjonowanie, ponowne wykorzystywanie komponentów, czy obecnie Docker Hub, który pozwala na „automatyzację pipeline-u Dev-Test, 100 000+ darmowych aplikacji oraz publiczne i prywatne rejestry”.
Poniżej ten sam wykres trendu liczby wyszukiwań frazy „docker” w Google.
We właściwym miejscu, o właściwym czasie
Jest takie powiedzenie, że czas jest wszystkim (Napoleon I) i to z pewnością wydaje się prawdziwe dla Kubernetesa. Ułatwiając korzystanie z kontenerów, Docker napędza rozwój Kubernetesa. W rzeczywistości stał się symbiotycznym związkiem wzrostu dla każdego z nich. Im więcej ludzi używa Kubernetesa, tym częściej będą używać Dockera i na odwrót.
Kilka statystyk
Zgodnie z rocznym raportem dotyczącym przyjęcia kontenerów Portworx 2017 przeprowadzonym w lutym i marcu 2017 r., statystyki są następujące:
„W przypadku firm zatrudniających ponad 5000 pracowników, Kubernetes jest używany przez 48%, a podstawowe narzędzie orkiestracji przez 33% użytkowników.”
„79% badanych wybrało Dockera jako podstawową technologię kontenerów.”
Aby umocnić Kubernetesa jako lidera, dostawcy oprogramowania i usługodawcy w chmurze wybierają go jako wsparcie kontenerów Docker.
Komercyjne oferty Kubernetes
Chociaż było wiele komercyjnych ofert, odkąd Kubernetes stał się open source, w ciągu kilku miesięcy zrobił imponujący skok w rankingu. Do długoterminowych komercyjnych dostawców należą Google (Google Container Engine), Red Hat (OpenShift), CoreOS (Tectonic), Canonical i Apprenda. Microsoft i VMware miały pewne wsparcie dla Kubernetesa, ale ostatnio zagrały all-in.
2017 był dobry dla Kubernetesa (dla Dockera również)
W drugiej połowie roku 2017, najwięksi usługodawcy w chmurze dodali Kubernetesa do swojej podstawowej oferty. Szczególnie ważne ogłoszenia to:
Amazon Web Services (AWS) dołączył do CNCF w sierpniu jako członek Platinum (najwyższy dostępny poziom). Chociaż AWS dołączający do CNCF nie był bezpośrednio związany z Kubernetesem (ponieważ obecnie CNCF prowadzi 14 projektów), AWS ma znaczną liczbę klientów korzystających z kontenerów i Kubernetesa na produkcji.
Następnie w październiku, fundacja Cloud Foundry Foundation ogłosiła, że ich środowisko wykonawcze Cloud Foundry Container Runtime (CFCR), zasilane jest przez Kubernetes, z kolei Pivotal Cloud Foundry (we współpracy z VMware) ogłosiło w październiku dostępność usługi Pivotal Container Service (PKS) w VMworld. Zarówno Pivotal, jak i VMware, wpisały się jako członkowie Platinum CNCF, co znowu oznacza najwyższy dostępny poziom.
Fakt, że VMware dostosowuje się do Kubernetesa, jest wyraźnym znakiem, że VMware zauważa, że Kubernetes i kontenery to nie tymczasowa moda i pozostaną na dłużej. Wielu kwestionowało, czy kontenery i chmura zastąpią maszyny wirtualne. Chociaż eksperci uważają, że jest miejsce, aby mogły współistnieć w przedsiębiorstwie, jest to wyraźne przesunięcie akcentów od kiedy VMware rządził na rynku wirtualizacji.
Z kolei w październiku, Microsoft Azure przemianował swoją usługę Azure Container Service (ACS) na AKS, z oznaczeniem „K” jak Kubernetes. Jest to duża zmiana w stosunku do ich wcześniejszego argumentu, że jedną z korzyści ACS było wsparcie dla wielu narzędzi orkiestrowych.
Nawet firma Docker Inc. uległa i niedawno dodała natywną obsługę Kubernetesa w ramach swojej platformy Docker Enterprise Edition. Jest to znaczący sukces Kubernetesa i wpływa na przyszłość platformy Docker Swarm. Docker uruchomił Swarm w 2015 roku, aby konkurować bezpośrednio z Kubernetesem. Docker zlecił nawet niezależny test porównawczy, by porównać obie platformy. Z pewnością istnieją szczególne przypadki użycia obu platform, ale Kubernetes jest wspierany przez Google i testowany w warunkach praktycznych (pamiętacie Pokémon GO?) . Ponadto ma bardzo dużą społeczność, a przedsiębiorstwa będą go uważać za swoją standardową platformę orkiestracji.
Źródło: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html
Co to oznacza dla przedsiębiorstwa?
Kubernetes i Docker skutecznie funkcjonują już od jakiegoś czasu. W miarę, jak firmy przenoszą się do chmury okazuje się, że nie ma uniwersalnego rozwiązania. Istnieją potrzeby, w których system PaaS lub IaaS działa najlepiej, są jednak inne, dla których kontenery (niektóre nazywają to CaaS) będą bardziej odpowiednie.
Aby wykorzystać wszystkie korzyści z chmury, firmy przechodzą na DevOps i Cloud Native Development. Po przyjęciu DevOps zaczynają tworzyć aplikacje jako niezależne komponenty, wykorzystujące mikroserwisy działające w kontenerach. Te zespoły będą mniejsze (CTO Amazona, Werner Vogels, określił je jako „two-pizza teams„) i będą miały możliwość aktualizacji funkcjonalności ich „usług” niezależnie od innych składników aplikacji. Przerzucając rozwój na małe zespoły koncentrujące się na usługach oddzielonych od produkcji, firmy mogą skalować swoje wysiłki na rzecz rozwoju i szybciej dostarczać wartość swoim klientom/użytkownikom. Teraz, zamiast jednej bazy kodu, która jest aktualizowana co sześć miesięcy, aktualizacje są dokonywane w miarę potrzeb i mogą być liczone w setkach, tysiącach, dziennie.
Aby to działało, trzeba zająć się automatyzacją. Automatyzacja jest abstrakcją złożoności. Zapewnij łatwy i powtarzalny sposób bezpiecznego dostarczania i wdrażania oprogramowania, a zespoły będą robić to częściej.
Ta abstrakcja i różnorodność technologii sprawiają, że monitorowanie stanowi ważny element układanki. Teraz masz tysiące niezależnych ruchomych części, z których wiele może wyglądać jak „czarne skrzynki” do tradycyjnych rozwiązań monitorujących. W miarę zbliżania się do Cloud Native i większej liczby aplikacji działających w chmurze, należy przyjrzeć się podejściom monitorującym zaprojektowanym specjalnie, aby dobrze działały w tym nowym świecie.
Czym monitorować Dockera, Kubernetesa i chmurę
Aby dowiedzieć się więcej o monitorowaniu kontenerów i mikroserwisów, pobierz raport od Ovum nt. Cloud Native APM: Ovum Market Radar: Cloud Native APM
Aby dowiedzieć się więcej o full stack monitoring w wykonaniu Dynatrace dla technologii Kubernetes, Docker i chmury, sprawdź następujące zasoby:
Monitorowanie Kubernetesta
Monitorowanie Dockera
Raport Ovum (PDF): On the radar: Dynatrace provides all-in-one monitoring environment
Copyright: Dynatrace
Autor oryginału: Scott Kelly
