Literatury przedmiotu w Internecie jest mnóstwo, jednak czasami najprostsza rada jest najcenniejsza. Zespół przetłumaczony , które autor artykułu zebrał po roku pracy z Kubernetesem. Wskazówki nie są posortowane według ważności, ale uważamy, że każdy znajdzie coś dla siebie.
Najprostsze polecenie do pracy z Kubernetesem
Na początek chyba najprostsza i najbardziej przydatna czynność w pracy z Kubernetesem. Poniższe polecenie umożliwia dokończenie polecenia kubectl w powłoce bash:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Autouzupełnianie kubectl zostanie zapisany w pliku .bashrc i będzie automatycznie aktywowany przy każdym uruchomieniu powłoki. Przyspiesza to wpisywanie długich poleceń i parametrów, takich jak all-namespaces. Więcej szczegółów w .
Domyślne limity pamięci i procesora w przestrzeni nazw
Jeśli na przykład aplikacja jest napisana niepoprawnie, co sekundę otwiera nowe połączenie z bazą danych, ale nigdy go nie zamyka, oznacza to, że w klastrze występuje wyciek pamięci. Jeśli podczas wdrażania aplikacja nie ma ustawionego limitu pamięci, może to prowadzić do awarii węzła.
Aby temu zapobiec, Kubernetes umożliwia ustawienie domyślnych ograniczeń dla poszczególnych przestrzeni nazw. Są one zapisywane w pliku YAML dla określonej przestrzeni nazw. Oto przykład takiego pliku:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Utwórz taki YAML i zastosuj do dowolnej przestrzeni nazw. Na przykład do przestrzeni nazw limit-example. Teraz każdy kontener wdrożony w tej przestrzeni nazw będzie miał limit 512Mi, chyba że dla tego kontenera zostanie dodatkowo ustawiony inny indywidualny limit.
Wyrzucanie śmieci w starszych wersjach Kubernetesa
Kubelet domyślnie rozpoczyna odśmiecanie, kiedy var/lib/doker zajmuje 90% dostępnego miejsca na dysku. To świetnie, jednak do Kubernetesa 1.7 nie było domyślnego limitu liczby używanych i-węzłów, które odpowiadały liczbie plików w systemie plików.
Potencjalnie Twój kontener var/lib/doker może wykorzystywać tylko 50% miejsca na dysku, ale może zabraknąć i-węzłów, co spowoduje problemy dla pracowników.
W starszych wersjach kubelet od 1.4 do 1.6 będziesz musiał dodać tę flagę:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
W wersjach 1.7 i nowszych ta flaga jest ustawiona domyślnie. Jednak poprzednie wersje nie monitorują limitu i-węzłów.
Minikube... mały, ale potężny lokalny Kubernetes
Minikube to najprostszy sposób na uruchomienie lokalnego klastra Kubernetes. Uruchamia się go za pomocą prostego polecenia:
minikube start
Uruchomienie tego polecenia spowoduje uruchomienie prawdziwego klastra Kubernetes na Twoim komputerze.
Sztuka polega na tym, jak zbudować aplikację i uruchomić ją lokalnie w tym klastrze. O ile nie podano specjalnych instrukcji, obraz platformy Docker zostanie zbudowany na komputerze, a nie w klastrze.
Aby zmusić Dockera do wypchnięcia obrazu do lokalnego klastra Kubernetes, komputer dokujący otrzymuje następujące polecenie:
eval $(minikube docker-env)
Teraz możemy budować aplikacje na lokalnym klastrze Kubernetes.
Nie dawaj kubectl dostępu każdemu
Wydaje się to oczywiste, ale jeśli wiele zespołów używa tego samego klastra w swoich aplikacjach (do tego został stworzony Kubernetes), nie powinieneś po prostu dawać wszystkim kubectl. Lepiej jest rozdzielić polecenia, przypisując każdemu z nich własną przestrzeń nazw i ograniczając dostęp za pomocą polityk RBAC.
Możesz się pomylić, przypisując prawa dostępu, odczytu, tworzenia, usuwania i innych operacji dla każdego poda. Ale najważniejsze jest ograniczenie dostępu do tajemnic, pozwalając na to tylko administratorom. W ten sposób rozróżnimy tych, którzy mogą administrować klastrem, od tych, którzy mogą po prostu wdrożyć w nim klaster.
Zarządzaj budżetami podów
Jak zapewnić brak przestojów aplikacji w klastrze Kubernetes? PodDisruptionBudget i jeszcze raz PodDisruptionBudget.
Klastry są okresowo aktualizowane, a węzły opróżniane. Nic nie stoi w miejscu, taka jest rzeczywistość. Każde wdrożenie z więcej niż jedną instancją powinno zawierać plik PDB (PodDisruptionBudget). Jest on tworzony w prostym pliku YAML, który jest stosowany do klastra. Obszar pokrycia konkretnego PDB jest określany przez selektory etykiet.
Uwaga: Budżet WPB jest brany pod uwagę tylko wtedy, gdy naruszenie budżetu jest odwracalne (). W sytuacjach takich jak awarie sprzętu PDB nie będzie działać.
Przykładowy WPB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Dwa główne parametry to matchLabels и minAvailable. Pierwszy parametr określa, jakich wniosków dotyczy budżet. Na przykład, jeśli mam wdrożenia z etykietami app: app-a и app: app-b, wówczas ten WPB będzie miał zastosowanie tylko do pierwszego.
Parametr minAvailable brane pod uwagę przy opróżnianiu (czyszczeniu) węzła. Na przykład w naszym przykładzie podczas opróżniania wszystkie instancje są eksmitowane app: app-a, z wyjątkiem dwóch.
Dzięki temu możesz kontrolować, ile instancji aplikacji powinno być uruchomionych w danym momencie.
Monitorowanie stanu aplikacji
Monitoring taki jest możliwy na dwa sposoby: za pomocą testów Gotowości lub Żywotności.
Pierwsza sonda (gotowość) określa gotowość kontenera do odbioru ruchu.
Drugi (żywotność) pokazuje, czy kontener jest w dobrym stanie, czy też wymaga ponownego uruchomienia.
Odpowiednie konfiguracje są po prostu dodawane do pliku YAML w celu wdrożenia. Można tam określić limity czasu, czasy opóźnień i liczbę ponownych prób. Zobacz więcej szczegółów na ich temat .
Tagi są wszędzie
Etykiety to jedno z podstawowych pojęć w Kubernetesie. Pozwalają obiektom na swobodną komunikację między sobą, a także tworzenie zapytań w oparciu o etykiety. W Kubernetes możesz nawet przejść do klienta i obejrzeć zdarzenia dla konkretnych tagów.
Ze znacznikami możesz zrobić prawie wszystko, ale dobrym przykładem byłoby utworzenie wielu środowisk do uruchamiania programów w tym samym klastrze.
Załóżmy, że używasz tego samego klastra dev и qa. Oznacza to, że możesz mieć aplikację app-a, pracując jednocześnie w obu środowiskach qa и dev. W takim przypadku możemy oddzielnie uzyskać dostęp do instancji aplikacji w konkretnym środowisku, podając odpowiedni parametr environment. Na przykład app: app-a и environment: dev dla jednego środowiska i app: app-a и environment: qa dla drugiego.
Dzięki temu można uzyskać dostęp do obu instancji aplikacji, na przykład w celu jednoczesnego przeprowadzenia testów.
Być zorganizowanym
Kubernetes to bardzo potężny system, ale każdy system może w końcu ugrzęznąć w zbyt dużej liczbie procesów. Kubelet uruchamia wszystkie określone przez Ciebie procesy i kontrole, a także własne.
Oczywiście jedna osierocona usługa nie spowolni systemu, a Kubernetes jest zaprojektowany tak, aby skalować się od podstaw. Ale jeśli zamiast jednej usługi pojawi się milion, kubelet zaczyna się dusić.
Jeśli z jakiegoś powodu usuniesz wdrożenie (kontener, obraz, cokolwiek innego), po prostu wykonaj pełne czyszczenie.
Poznaj Go
Główną radę zachowaliśmy na koniec. Naucz się języka programowania Go.
Kubernetes jest rozwijany w Go, wszystkie rozszerzenia są pisane w Go, a biblioteka klienta typu Client-Go jest również oficjalnie obsługiwana.
Można go używać do różnych i ciekawych rzeczy. Na przykład, aby rozbudować system Kubernetes według własnych upodobań. Możesz więc używać własnych programów do gromadzenia danych, wdrażania aplikacji lub po prostu czyszczenia kontenerów.
Nauka języka programowania Go i opanowanie obsługi klienta to być może najważniejsza rada, jakiej możesz udzielić nowym użytkownikom Kubernetes.
Co jeszcze przeczytać:
- .
- ?
- .
Źródło: www.habr.com