Dzisiaj opowiemy Wam o tym, czym jest Kubernetes, o jego podstawowych możliwościach i dlaczego sam Docker to często za mało, aby prowadzić poważne środowisko produkcyjne. Jeśli nie masz jeszcze pełnej wiedzy o Dockerze, to polecamy nasze artykuły w tym temacie.

 

Czym jest Kubernetes?

Jest on narzędziem orkiestracji kontenerów na dużą skalę niezależnie od dostawcy chmurowego. Pozwala na automatyczny deployment i zarządzanie kontenerami aplikacyjnymi. Jest narzędziem, które oferuje dużo więcej niż Docker. Można o nim myśleć jak o docker-compose z dodatkowymi funkcjami pozwalającym na pracę na wielu fizycznych maszynach.  Warto także wspomnieć, że Kubernetes występuje w wielu wersjach jak np.:

    • standardowy, tzw. vanilla Kubernetes - wymaga on dodatkowych środków i umiejętności administratora wynikających z samodzielnej instalacji i wdrożenia. Zapewnia jedynie podstawowe komponenty wymagane do działania klastra.
    • zarządzalny - usługodawcy chmurowi tacy jak Azure, AWS czy Google zajmują się zarządzaniem podstawową infrastrukturą, w tym dostarczaniem, skalowaniem i utrzymaniem klastra Kubernetes, umożliwiając użytkownikom skoncentrowanie się zarządzaniu ich aplikacjami. Skazuje nas to jednak na konkretnego dostawcę chmurowego.
    • dystrybucyjny - to taki, który posiada w sobie dodatkowe narzędzia jak np. rancher, ale jest jednocześnie open-source i pozwala na własne wdrożenie.
    • lekki - często używany do lokalnego wdrożenia np. minikube (jest wdrażany na pojedynczym węźle).

 

Dlaczego Docker jest niewystarczający?

Można wymienić ku temu kilka powodów jak np.:

  • brak automatycznego respawny kontenera w przypadku awarii w Dockerze - Kubernetes może to robić w sposób automatyczny i to nawet w przypadku fizycznej awarii któregoś serwera
  • docker nie pozwala na automatyczne skalowanie - Kubernetes pozwala na skalowanie horyzontalne aplikacji, czyli zwiększenie liczby kontenerów
  • kubernetes posiada wbudowane możliwości load balancingu, a także możliwość działania na wielu fizycznych maszynach jednocześnie jako klaster

Warto jednak wspomnieć, że istnieją także alternatywy do orkiestracji kontenerów jak np. AWS ECS (nie mylić z przedstawionym wyżej EKS) integrujące zarządzanie kontenerami z chmurą AWS. Porównanie Kubernetes do AWS ECS nie jest do końca trafne, ponieważ ECS opiera się na Docker Engine, a jego integracja z pozostałymi usługami AWS daje mu dodatkowe możliwości jak np. reset kontenera, autoscaling czy load-balancing, a także pozwala także na provisioning dodatkowych zasobów od AWS, co nie jest dostępne z poziomu Kubernetes. Wadą tego rozwiązania jest jednak zbytnie przywiązanie do dostawcy chmurowego, ponieważ konfiguracje yaml’owe dla ECS działają jedynie w ramach AWS, natomiast konfiguracje Kubernetes’owe działają niezależnie od dostawcy (o ile dostawca dostarcza odpowiednią wersję Kubernetes w ramach swojej infrastruktury).

 

Podstawowe pojęcia 

Teraz, gdy już mamy pewną intuicję co do tego czym jest Kubernetes i jak różni się od Docker’a możemy przejść do omawiania podstawowych pojęć i klasyfikacji, których używamy rozmawiając o K8s. 

Rysunek 1 - elementy klastra Kubernetes, źródło: medium.com

Podstawowy podział jaki można wyróżnić w przypadku Kubernetes to:

  • warstwa kontroli (control plane) odpowiadająca za zarządzanie klastrem i podejmowanie odpowiednich decyzji, jak harmonogramowanie czy utrzymanie pożądanego stanu klastra. W jej skład wchodzą tzw. master nodes, czyli te węzły klastra, które odpowiadają właśnie za zarządzanie. 
  • warstwa danych (data plane) odpowiada za przetwarzanie danych w klastrze za pomocą tzw. worker nodes (te węzły, które wykonują obliczenia). To tam działają skonteneryzowane aplikacje na których wykonywane są operacje obliczeniowe.

Czasem w Internecie można spotkać określenie, że warstwa kontroli jest jak mózg, a warstwa danych jak reszta ciała i wydaje się to dość trafnym porównaniem. W skład tych warstw wchodzą różne komponenty, które możemy zaobserwować na powyższym rysunku. Można więc powiedzieć, że na klaster (tj. grupę współpracujących ze sobą komputerów) Kubernetes składa się z warstwy kontrolnej złożonej z master nodes wewnątrz których są różne procesy i usługi do zarządzania oraz z warstwy danych (data plane), które składa się zwykle z większej ilości tzw. worker nodes wewnątrz których znajdują się odpowiedni komponenty.

W skład warstwy kontroli wchodzą:

  • serwer API - komponent z którym wchodzą w interakcje inne komponenty w celu zarządzania klastrem. Jest to REST API.
  • baza etcd - baza klucz-wartość odpowiadająca za przechowywanie wszystkich danych o klastrze tj. metadanych, danych o stanie, komponentach i zasobach
  • control manager - odpowiada za zarządzanie stanem klastra i składa się z kilku elementów takich jak kontroler węzła czy replikacji. Pilnuje tego, aby klaster znajdował się w stanie spójnym z wytyczoną konfiguracją.
  • scheduler - odpowiedzialny za przydzielanie odpowiednich pod’ów na odpowiednie worker nodes. Pilnuje także ograniczeń co do zasobów i wymagań zasobów co do uruchomienia danego pod’a.


Natomiast na warstwę danych składają się między innymi takie elementy jak:

  • kubelet - agent działający na worker node odpowiedzialny za zarządzanie węzłem w sposób określony przez master node.
  • pod - jest to najmniejsza, atomowa jednostka w Kubernetes posiadająca w sobie kontener. Jest to abstrakcyjny pojemnik zwykle posiadający w sobie pojedynczy kontener, ale z możliwością umieszczenia tam kilku z nich. 
  • proxy - element odpowiadający za ruch sieciowy do danego worker node’a, load balancing, routing do odpowiednich aplikacji działających na podach.
  • container runtime - komponent odpowiedzialny za zarządzanie cyklem życia kontenerów w Kubernetes.

  •  

Kubernetes - za co jest odpowiedzialny?

Warto także wspomnieć o tym za co Kubernetes jest odpowiedzialny, a za co administrator/deweloper go obsługujący. Stworzenie klastra, uruchomienie odpowiednich serwisów czy odpowiednich zasobów jak np. cloud storage z którego będzie korzystał Kubernetes to odpowiedzialność dewelopera. Natomiast zarządzanie podami, skalowanie, dążenie do osiągnięcia odpowiedniego stanu wytyczonego w konfiguracji to zadanie dla Kubernetes.

 

Podsumowanie

To już wszystko, o czym chcieliśmy Wam opowiedzieć w ramach wprowadzenia. Koniecznie zapoznajcie się z naszymi artykułami na temat dobrych praktyk w Dockerze oraz samego Dockera, jeśli chcecie zbudować solidne podstawy pod rozumienie Kubernetes. Do usłyszenia za tydzień!

 

Źródła: