Kubernetes (lub K8s) to popularna platforma open source do orkiestracji kontenerów - czyli do zarządzania aplikacjami zbudowanymi z wielu, w dużej mierze samodzielnych runtime’ów zwanych kontenerami. Kontenery stały się coraz bardziej popularne od czasu uruchomienia projektu konteneryzacji Docker w 2013 roku, ale duże, rozproszone aplikacje skonteneryzowane mogą stać się coraz trudniejsze do skoordynowania. Dzięki temu, że Kubernetes znacznie ułatwia zarządzanie aplikacjami w skali, stał się kluczową częścią rewolucji kontenerowej.

Na czym polega orkiestracja kontenerów?

Kontenery wspierają separację obaw w sposób podobny do maszyn wirtualnych, ale z dużo mniejszym narzutem i dużo większą elastycznością. W rezultacie kontenery zmieniły sposób, w jaki ludzie myślą o tworzeniu, wdrażaniu i utrzymaniu oprogramowania. W architekturze kontenerowej różne usługi składające się na aplikację są pakowane w oddzielne kontenery i rozmieszczane na klastrze maszyn fizycznych lub wirtualnych. Ale to rodzi potrzebę orkiestracji kontenerów – narzędzia, które automatyzuje wdrażanie, zarządzanie, skalowanie, sieciowanie i dostępność aplikacji opartych na kontenerach.

Zobacz również:

• Ta inicjatywa ma ułatwić firmom zadanie wdrażania systemów AI

Kubernetes – co to właściwie jest?

Kubernetes to projekt open source, który stał się jednym z najpopularniejszych narzędzi do orkiestracji kontenerów; pozwala on na wdrażanie i zarządzanie aplikacjami wielokontenerowymi w skali. Chociaż w praktyce Kubernetes jest najczęściej używany z Dockerem, najpopularniejszą platformą do konteneryzacji, może również współpracować z każdym systemem kontenerowym, który jest zgodny ze standardami Open Container Initiative (OCI) dla formatów obrazów kontenerów i systemów uruchomieniowych. A ponieważ Kubernetes to open source, z relatywnie niewielką liczbą ograniczeń co do jego wykorzystania, może być swobodnie używany przez każdego, kto chce uruchomić kontenery, w większości przypadków – lokalnie, w chmurze publicznej lub w obu tych miejscach.

Google a Kubernetes

Kubernetes rozpoczął życie jako projekt w ramach Google. Jest to następca, ale nie bezpośredni potomek Google Borg, wcześniejszego narzędzia do zarządzania kontenerami, które Google wykorzystywało wewnętrznie. Google udostępnił Kubernetes w 2014 roku, częściowo dlatego, że rozproszona architektura mikroserwisów, którą Kubernetes ułatwia, pozwala na łatwe uruchamianie aplikacji w chmurze. Google postrzega przyjęcie kontenerów, mikroserwisów i Kubernetes jako potencjalnie napędzające klientów do swoich usług w chmurze (chociaż Kubernetes z pewnością działa również z Azure i AWS). Kubernetes jest obecnie utrzymywany przez Cloud Native Computing Foundation, która sama jest pod parasolem Linux Foundation.

Kubernetes vs. inne projekty

Kubernetes nie jest jedynym sposobem na zarządzanie kontenerami w skali, choć wyrósł na najbardziej powszechny i szeroko wspierany. Kilka innych opcji zasługuje na omówienie.

Kubernetes vs. Docker i tryb roju Docker

Kubernetes nie zastępuje Dockera, ale go rozszerza. Jednak Kubernetes może wystarczyć za niektóre z technologii wyższego poziomu, które pojawiły się wokół Dockera.

Jedną z takich technologii jest tryb rojowy Dockera, tzn. system zarządzania klastrem silników Dockera określanym jako „rój”, a w istocie mały system orkiestracji. Nadal możliwe jest użycie trybu roju Dockera zamiast Kubernetesa, ale Docker Inc. zdecydował się uczynić Kubernetesa kluczową częścią wsparcia dla Dockera w przyszłości.

Należy jednak pamiętać, że Kubernetes jest znacznie bardziej skomplikowany niż tryb roju Dockera i wymaga więcej pracy, aby go wdrożyć. Ale ponownie, praca ta ma zapewnić duży zysk w dłuższej perspektywie – łatwiejsza w zarządzaniu, odporna infrastruktura aplikacji. Dla prac rozwojowych i mniejszych klastrów kontenerów, tryb roju Dockera jest lepszą opcją.

Kubernetes vs. Mesos

Innym konkurencyjnym wobec Kubernetes projektem jest Mesos. Mesos to projekt Apache, który pierwotnie powstał z inicjatywy programistów z Twittera; był początkowo postrzegany jako odpowiedź na projekt Google Borg. Mesos faktycznie oferuje usługi orkiestracji kontenerów, ale jego ambicje są znacznie większe: ma być czymś w rodzaju systemu operacyjnego chmury, który może koordynować zarówno skonteneryzowane, jak i nieskonteneryzowane komponenty. W tym celu wiele różnych platform może działać w ramach Mesos – w tym sam Kubernetes.

Architektura Kubernetes: jak to działa?

Architektura Kubernetes korzysta z różnych koncepcji i abstrakcji. Niektóre z nich są wariacjami na temat istniejących, znanych pojęć, ale inne są specyficzne dla Kubernetes.

Klastry Kubernetes

Najwyższy poziom abstrakcji Kubernetes, klaster, odnosi się do grupy maszyn, na których działa Kubernetes (sam w sobie jest aplikacją klastrową) i kontenerów przez niego zarządzanych. Klaster Kubernetes musi posiadać master, czyli system, który dowodzi i kontroluje wszystkie pozostałe maszyny Kubernetes w klastrze. Wysoko dostępny klaster Kubernetes replikuje obiekty mistrza na wiele maszyn. Ale tylko jeden master w tym samym czasie uruchamia harmonogram zadań i controller-manager.

Węzły i strąki Kubernetes

Każdy klaster zawiera węzły Kubernetes. Węzły mogą być fizycznymi maszynami lub maszynami wirtualnymi. Ponownie, ideą jest abstrakcja: niezależnie od tego, na czym działa aplikacja, Kubernetes obsługuje wdrażanie na tym podłożu..

Węzły uruchamiają strąki, najbardziej podstawowe obiekty Kubernetesa, które mogą być tworzone lub zarządzane. Każdy strąk reprezentuje pojedynczą instancję aplikacji lub działającego procesu w Kubernetes i składa się z jednego lub więcej kontenerów. Kubernetes uruchamia, zatrzymuje i replikuje wszystkie kontenery w strąku jako grupę. Pody utrzymują uwagę użytkownika na aplikacji, a nie na samych kontenerach. Szczegóły dotyczące konfiguracji Kubernetes, począwszy od stanu kontenerów, są przechowywane w Etcd, rozproszonym magazynie wartości kluczowych.

Strąki są tworzone bądź niszczone na węzłach w zależności od aktualnych potrzeb użytkownika. Kubernetes dostarcza abstrakcję zwaną kontrolerem, która zajmuje się logistyką – tym, jak strąki są uruchamiane, rozwijane i wyłączane. Kontrolery występują w kilku różnych odmianach, w zależności od rodzaju zarządzanej aplikacji. Na przykład, kontroler StatefulSet jest używany do obsługi aplikacji, które potrzebują trwałego stanu. Kontroler Deployment jest używany do skalowania aplikacji w górę lub w dół, aktualizowania aplikacji do nowej wersji lub cofania aplikacji do starej wersji.

Usługi Kubernetes

Ponieważ strąki żyją i umierają w zależności od potrzeb, potrzebujemy innej abstrakcji do radzenia sobie z cyklem życia aplikacji. Aplikacja ma być trwałym bytem, nawet jeśli strąki uruchamiające kontenery, które składają się na aplikację, same nie są trwałe. W tym celu, Kubernetes dostarcza abstrakcję zwaną usługą (lub serwisem). Serwis w Kubernetes jest abstrakcyjnym obiektem, który definiuje logiczny zbiór podów oraz politykę dostępu do nich – innymi słowy opisuje, w jaki sposób dana grupa strąków (lub innych obiektów Kubernetes) może być dostępna poprzez sieć. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu lub w JSONie - tak, jak wszystkie obiekty Kubernetes. Zbiór podów, które obsługuje serwis, jest zazwyczaj określany przez LabelSelector. Strąki, które tworzą back-end aplikacji mogą się zmieniać, ale front-end nie powinien o tym wiedzieć ani tego śledzić. Usługi czynią to możliwym.

Kilka innych elementów wewnętrznych Kubernetes dopełnia obrazu. Program szeregujący przydziela obciążenia do węzłów, tak aby były one zrównoważone pomiędzy zasobami i aby wdrożenia spełniały wymagania definicji aplikacji. Menedżer kontrolera dba o to, aby stan systemu - aplikacji, obciążeń itp. - odpowiadał pożądanemu stanowi zdefiniowanemu w ustawieniach konfiguracyjnych, itd.

Należy pamiętać, że żaden z niskopoziomowych mechanizmów używanych przez kontenery, takich jak sam Docker, nie został zastąpiony przez Kubernetes. Kubernetes dostarcza raczej większy zestaw abstrakcji do korzystania z tych mechanizmów w celu utrzymania aplikacji działających w skali.

Polityki Kubernetes

Dzięki politykom Kubernetes strąki przestrzegają pewnych standardów zachowania. Polityki zapobiegają na przykład nadmiernemu wykorzystaniu CPU, pamięci, identyfikatorów procesów lub przestrzeni dyskowej. Takie „zakresy limitów” wyrażane są w wartościach względnych dla CPU (np. 50% wątku sprzętowego) i bezwzględnych dla pamięci (np. 200 MB). Limity te mogą być połączone z kwotami zasobów, aby zapewnić, że różne zespoły użytkowników Kubernetes (w przeciwieństwie do aplikacji ogólnie) mają równy dostęp do zasobów.

Ingress Kubernetes

Usługi Kubernetes są postrzegane jako działające w ramach klastra. Kubernetes posiada kilka komponentów, które ułatwiają dostęp z zewnątrz w różnym stopniu, w tym NodePort i LoadBalancer, ale komponentem o największej elastyczności jest Ingress. Ingress to API, które zarządza zewnętrznym dostępem do usług klastra, zazwyczaj poprzez HTTP.

Ingress wymaga nieco wprawy, aby go poprawnie skonfigurować.

Dashboard Kubernetes

Jednym z komponentów Kubernetes, który pomaga utrzymać się na szczycie wszystkich tych innych komponentów jest Dashboard, webowy interfejs użytkownika, za pomocą którego można wdrażać i rozwiązywać problemy z aplikacjami oraz zarządzać zasobami klastra. Dashboard nie jest domyślnie zainstalowany, ale dodanie go nie jest zbyt skomplikowane.

Wideo: Co to jest Kubernetes?

Joe Beda, założyciel i CTO w Heptio, a przede wszystkim jeden z twórców technologii stojącej za Kubernetes, opowiada o tym systemie open-source do automatyzacji skonteneryzowanych aplikacji.

Zalety Kubernetes

Ponieważ Kubernetes wprowadza nowe abstrakcje i koncepcje, a krzywa uczenia się Kubernetes jest wysoka, nasuwa się pytanie o długoterminowe korzyści z używania Kubernetes. Oto one:

• Kubernetes zarządza za użytkownika zdrowiem aplikacji, replikacją, równoważeniem obciążenia i alokacją zasobów sprzętowych, np. utrzymywanie aplikacji w gotowości do pracy i reagowanie na potrzeby użytkowników. Aplikacje, które stają się „niezdrowe” lub nie odpowiadają definicji zdrowia, którą dla nich określisz, mogą być automatycznie uzdrawiane.

• Kolejną korzyścią, jaką zapewnia Kubernetes, jest maksymalizacja wykorzystania zasobów sprzętowych, w tym pamięci, pamięci masowej I/O oraz przepustowości sieci. Aplikacje mogą mieć ustawione miękkie i twarde limity na wykorzystanie zasobów. Wiele aplikacji, które wykorzystują minimalne zasoby, może być upakowanych razem na tym samym sprzęcie; aplikacje, które muszą się rozrastać, mogą być umieszczone na systemach, gdzie mają miejsce na rozwój. I znowu, aktualizacje w całym klastrze, lub cofanie, jeśli aktualizacje się zepsują, mogą być zautomatyzowane.

• Kubernetes ułatwia wdrażanie wstępnie skonfigurowanych aplikacji dzięki wykresom Helm.

• Menedżery pakietów, takie jak APT Debiana Linuxa i Pip Pythona, oszczędzają użytkownikom kłopotów z ręczną instalacją i konfiguracją aplikacji. Jest to szczególnie przydatne, gdy aplikacja ma wiele zewnętrznych zależności.

• Helm jest w zasadzie menedżerem pakietów dla Kubernetes. Wiele popularnych aplikacji musi działać w Kubernetes jako grupa współzależnych kontenerów. Helm dostarcza mechanizm definicji, „wykres”, który opisuje, w jaki sposób aplikacja lub usługa może być uruchomiona jako grupa kontenerów wewnątrz Kubernetes.

• Można tworzyć własne wykresy Helm od podstaw (to konieczne w przypadku tworzenia niestandardowej aplikacji, która ma być wdrożona wewnętrznie). Ale już w przypadku popularnej aplikacji, która ma wspólny wzorzec wdrażania, istnieje duża szansa, że ktoś już skomponował dla niej wykres Helm i opublikował go w Artifact Hub. Innym miejscem, w którym można szukać oficjalnych wykresów Helm, jest katalog Kubeapps.com.

• Kubernetes upraszcza zarządzanie pamięcią masową, sekretami i innymi zasobami związanymi z aplikacją

• Kontenery mają być niezmienne; kod i dane, które w nich umieszczasz nie powinny się zmieniać. Aplikacje jednak potrzebują niezawodnego sposobu radzenia sobie z zewnętrznymi wolumenami pamięci masowej. To wszystko jest jeszcze bardziej skomplikowane przez sposób, w jaki kontenery żyją, umierają i odradzają się w trakcie życia aplikacji.

• Kubernetes dostarcza abstrakcji, które pozwalają kontenerom i aplikacjom radzić sobie z pamięcią masową w taki sam odsprzężony sposób, jak w przypadku innych zasobów. Wiele popularnych rodzajów pamięci masowej, od wolumenów Amazon EBS po zwykłe stare udziały NFS, może być dostępnych poprzez sterowniki pamięci masowej Kubernetes, zwane wolumenami. Zazwyczaj wolumeny są przypisane do konkretnego strąka, ale podtyp wolumenu zwany „Persistent Volume” może być używany dla danych, które muszą być przechowywane niezależnie od każdego strąka.

• Kontenery często muszą pracować z „sekretami" - poświadczeniami, takimi jak klucze API lub hasła do usług, których nie chcesz zakodować w kontenerze lub przechowywać na woluminie dysku. Podczas gdy dostępne są rozwiązania firm trzecich, takie jak Docker secrets czy HashiCorp Vault, Kubernetes posiada własny mechanizm do natywnej obsługi sekretów, choć wymaga on ostrożnej konfiguracji.

• Aplikacje Kubernetes mogą działać w chmurach hybrydowych i środowiskach multicloud

• Jednym z odwiecznych marzeń o chmurze obliczeniowej jest możliwość uruchomienia dowolnej aplikacji w dowolnej chmurze, lub w dowolnej mieszance chmur publicznych i prywatnych. Nie chodzi tu tylko o uniknięcie uzależnienia od dostawcy, ale także o możliwość korzystania z funkcji specyficznych dla poszczególnych chmur.

• Projekt Kubernetes SIG o nazwie KubeFed, czyli Kubernetes Cluster Federation, może być wykorzystany do utrzymywania wielu klastrów w synchronizacji między sobą w wielu regionach i chmurach. Na przykład, dane wdrożenie aplikacji może być utrzymywane w spójności pomiędzy wieloma klastrami, a różne klastry mogą współdzielić wykrywanie usług, dzięki czemu zasób back-end może być dostępny z dowolnego klastra. Federacja może być również używana do tworzenia wysoce dostępnych lub odpornych na błędy wdrożeń Kubernetes, niezależnie od tego, czy korzystasz z wielu środowisk chmurowych, czy nie.

• KubeFed jest wciąż projektem beta, z komponentami na poziomie alfa. Nie jest to również rozwiązanie federacyjne wysokiego poziomu, ale bardziej niskopoziomowy zestaw komponentów używanych do umożliwienia przyszłych funkcji, takich jak (zgodnie z oficjalnymi dokumentami KubeFed) odzyskiwanie po awarii lub aplikacje rozproszone w domenach geograficznych.

W jaki sposób i gdzie pozyskać Kubernetes

Kubernetes jest dostępny w wielu formach - od bitów open source, przez komercyjne dystrybucje, po usługi w chmurze publicznej - dlatego najlepszym sposobem na określenie, gdzie go zdobyć, jest zastosowanie go w konkretnym przypadku.

Jeśli chcemy zrobić wszystko sami, od podstaw: kod źródłowy, a także wstępnie zbudowane binaria dla większości popularnych platform, można pobrać z repozytorium GitHub dla Kubernetes. Jeśli chcemu wypróbować małą instancję Kubernetes na własnym systemie, możemy użyć Minikube, aby utworzyć lokalny klaster na pojedynczej maszynie.

Jeśli używamy Docker Community lub Docker Enterprise: najnowsze edycje Dockera dostarczane są z Kubernetesem jako pack-in. Jest to bez wątpienia najłatwiejszy sposób, aby zapoznać się z Kubernetesem (Docker może również używać Minikube do wdrażania).

Jeśli wdrażamy na miejscu lub w prywatnej chmurze: istnieje duża szansa, że infrastruktura, którą wybierzemy dla swojej prywatnej chmury, ma wbudowany Kubernetes. Standardowe, certyfikowane, wspierane dystrybucje Kubernetes są dostępne u kilkudziesięciu dostawców.

Jeśli wdrażamy w chmurze publicznej: Wszyscy trzej główni dostawcy chmury publicznej oferują Kubernetes jako usługę. Google Cloud Platform oferuje Google Kubernetes Engine. Microsoft Azure oferuje Azure Kubernetes Service. A Amazon dodał Kubernetes do swojej istniejącej usługi Elastic Container Service. Zarządzane usługi Kubernetes są również dostępne od wielu dostawców.

Tutoriale Kubernetes

Istnieje wiele samouczków do Kubernetes, począwszy od www projektu Kubernetes. Zestawienie 10 najlepszych samouczków Kubernetes przygtowało Quick Code.

Certyfikacja Kubernetes

Certyfikaty Kubernetes są oferowane wspólnie przez Linux Foundation i Cloud Native Computing Foundation:

• Certified Kubernetes Administrator, który ma na celu „zapewnienie, że posiadacze CKA mają umiejętności, wiedzę i kompetencje do wykonywania obowiązków administratorów Kubernetes”, w tym zarządzania cyklem życia aplikacji, instalacji, konfiguracji, walidacji, utrzymania klastra i rozwiązywania problemów.

• Certified Kubernetes Application Developer, który zaświadcza, że użytkownicy potrafią projektować, budować, konfigurować i eksponować natywne aplikacje chmurowe dla Kubernetes.

Egzaminy certyfikacyjne kosztują 375 USD każdy. Istnieją również towarzyszące kursy szkoleniowe, które mogą służyć jako dobry, ustrukturyzowany sposób, aby dowiedzieć się więcej o Kubernetes dla tych, którzy są zainteresowani.

Oprac. i tłum. Anna Ładan

Źródło: InfoWorld