- Spis treści
- Książka
- Czym jest kontener? https://kubernetes.io/docs/concepts/overview/
- Problem - zarządzanie zbiorem kontenerów (mikroserwisów)
- Restartowanie konterów w przypadku crasha / deadlocka
- Przeniesienie kontenera na inną maszynę (VM) w przypadku awarii sprzętu
- Skalowanie zależne od natężenia ruchu (duplikacja kontenerów)
- Konfiguracja sieci
- Dostęp do konfiguracji całego klastra w jednym miejscu
- Rollout/rollback wszystkich kontenerów
- Historia
- 2004: Borg - Rozwiązanie closed source od Google'a do zarządzania klastrami
- 2015: Kubernetes 1.0 - Stworzone przez Google, od początku open source Powstanie CNCF (Cloud Native Computing Foundation)
- 2016: Helm - package manager dla Kubernetes
- 2017: Wsparcie od VMWare, Docker, Microsoft Azure, AWS
- Filozofia Kubernetes - deklaratywny kod specyfikuje pożądany stan systemu, a kubernetes robi wszystko, żeby go osiągnąć
- Podsumowanie komponentów (https://kubernetes.io/docs/concepts/overview/components/)
- Pod - zbiór kontenerów i woluminów (volumes, np. baza danych) działających na jednej maszynie (node)
- Najmniejsza jednostka w Kubernetes
- Każdy pod ma osobne IP
- Każdy kontener wewnątrz poda jest w osobnej cgroupie, ale dzieli niektóre namespace'y z innymi
- Przykład 5.1
- Health checks (liveness probe - restartuje kontener po kilku porażkach, readiness probe - wyłącza spod z load balancera po kilku porażkach)
- Zarządzanie zasobami (minimalne - gwarantowane, maksymalne - nie do przekroczenia)
- Przykład 5.6
- Pod Demo
- ReplicaSet
- Tworzy kopie danego poda
- ReplicaSet demo
- Deployment
- Rolling update
- Podgląd historii i łatwy powrót do poprzednich wersji
- Deployment demo
- Service discovery
- Problem: które procesy słuchają na jakich adresach pod jakimi portami?
- Rozwiązanie:
- Stwórz serwis, w którym każdy pod automatycznie dostaje label identyfikujący serwis (np.
app=my-app) - Żeby dostać się do konkretnego serwisu, wystarczy znać jego port i dostać się do dowolnego node'a, a ten przekieruje nas do poda (być może na innym node), gdzie znajduje się dany serwis. To wykorzystuje kube-proxy oraz wewnętrzny serwis dns.
- Alternatywnie osobny load balancer (tylko w chmurze)
- Stwórz serwis, w którym każdy pod automatycznie dostaje label identyfikujący serwis (np.
- Service discovery demo
- DaemonSet
- Umieszcza po jednej kopii danego poda na każdym node
- Jobs
- Pojedyncze wykonanie
- Wykonanie zadań z kolejki i wyjście
- CronJob
- Podsumowanie komponentów (https://kubernetes.io/docs/concepts/overview/components/)
- Co ma Kubernetes czego nie ma Docker Swarm?
- Wsparcie dla innych typów kontenerów niż docker (Containerd, CRI-O, ...)
- Automatyczne skalowanie (np. na podstawie zużycia procesora)
- Automatyczne zarządzanie sekretami
- RBAC (Role-based access control)
- Automatyczny self-healing
- Duże wsparcie społeczności (pluginy)
- Dostępne jako gotowy serwis u popularnych dostawców chmurowych (GCP, AWS, Azure)
- Wbudowany monitoring i dashboard
- Zalety Docker Swarm
- Prostszy, szybszy do nauki
- Wbudowany w docker engine, zintegrowany z narzędziami dockerowymi
- Automatyczny load balancing
- Idealny do mniejszych projektów
- StatefulSet z przykładem MongoDB?