W internecie znajduje się wiele materiałów informacyjnych, ale czasami najcenniejsze stają się najprostsze porady. Zespół przetłumaczył , które autor artykułu zebrał po roku pracy z Kubernetes. Porady nie są uporządkowane według ważności, ale sądzimy, że każdy znajdzie coś przydatnego dla siebie.
Najprostsza komenda w pracy z Kubernetes
Na początek, chyba najprostsze i najpożyteczniejsze działanie w pracy z Kubernetes. Następująca komenda włącza autouzupełnianie komend kubectl w powłoce bash:
echo "source > ~/.bashrc
Autouzupełnianie kubectl zostanie zapisane w pliku .bashrc i będzie automatycznie aktywowane za każdym razem przy uruchamianiu powłoki. Przyspiesza to wprowadzanie długich komend i parametrów, takich jak all-namespaces. Więcej w .
Ograniczenia domyślne pamięci i CPU w przestrzeni nazw
Jeśli aplikacja jest napisana niepoprawnie, na przykład co sekundę otwiera nowe połączenie z bazą danych, ale nigdy go nie zamyka, w klastrze występuje wyciek pamięci. A jeśli dla aplikacji podczas wdrażania nie ustanowiono ograniczenia na pamięć, może to prowadzić do usunięcia węzła.
Aby tego uniknąć, Kubernetes pozwala na ustanowienie ograniczeń domyślnych dla każdej przestrzeni nazw. Są one określane w pliku YAML dla konkretnej 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
Stwórz taki plik YAML i zastosuj go do dowolnej przestrzeni nazw. Na przykład do przestrzeni nazw limit-example. Teraz dla każdego kontenera wdrożonego w tej przestrzeni nazw będzie obowiązywał limit 512Mi, jeśli dla danego kontenera nie zostanie dodatkowo ustalony inny, indywidualny limit.
Czyszczenie zasobożytnych elementów w starszych wersjach Kubernetes
Kubelet domyślnie rozpoczyna czyszczenie zasobożytnych elementów, gdy var/lib/docker zajmuje 90 % dostępnej przestrzeni dyskowej. To świetnie, jednak do wersji Kubernetes 1.7 nie było domyślnego limitu na liczbę używanych indeksowych deskryptorów inode (i-nodów), które odpowiadały liczbie plików w systemie plików.
Potencjalnie twój kontener var/lib/docker może wykorzystywać tylko 50 % przestrzeni dyskowej, ale w tym samym czasie i-nody mogą się skończyć, co spowoduje problemy w działaniu workerów.
W starszych wersjach kubelet od 1.4 do 1.6 należy dodać ten flag:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
W wersji 1.7 i nowszych ta flaga jest ustawiona domyślnie. Jednak wcześniejsze wersje nie monitorują limitu inodów.
Minikube… mały, ale potężny lokalny Kubernetes
Minikube to najprostszy sposób na uruchomienie lokalnego klastra Kubernetes. Uruchamia się prostą komendą:
minikube start
W wyniku wykonania tej komendy na twoim komputerze działa prawdziwy klaster Kubernetes.
Sztuczka polega na tym, jak zbudować aplikację i uruchomić ją lokalnie w tym klastrze. Jeśli nie podasz specjalnych wskazówek, obraz Docker będzie budowany na twoim komputerze, a nie w klastrze.
Aby zmusić Dockera do wysłania obrazu do lokalnego klastra Kubernetes, należy wydać następującą komendę:
eval $(minikube docker-env)
Teraz możemy budować aplikacje na lokalnym klastrze Kubernetes.
Nie udostępniaj dostępu kubectl wszystkim naokoło
To wydaje się oczywiste, ale jeśli kilka zespołów korzysta z jednego klastra dla swoich aplikacji (do czego został stworzony Kubernetes), nie warto po prostu udzielać dostępu wszystkim. kubectlLepiej podzielić zespoły, przydzielając każdemu z nich swoją przestrzeń nazw i ograniczając dostęp z użyciem polityk RBAC.
Można się postarać, definiując dla każdego poda uprawnienia do dostępu, odczytu, tworzenia, usuwania i innych operacji. Ale najważniejsze jest ograniczenie dostępu do sekretów, zezwalając na to tylko administratorom. W ten sposób rozdzielimy tych, którzy mogą zarządzać klastrem, i tych, którzy mogą po prostu w nim wdrażać.
Zarządzaj budżetami podów
Jak zapewnić, aby nie było przestojów w aplikacji w klastrze Kubernetes? PodDisruptionBudget i jeszcze raz PodDisruptionBudget.
Klastry są okresowo aktualizowane, a węzły są opróżniane. Nic nie stoi w miejscu, taka jest rzeczywistość. Każde wdrożenie z więcej niż jednym instancją powinno obowiązkowo zawierać PDB (PodDisruptionBudget). Tworzy się go w prostym pliku yaml, który jest stosowany do klastra. Zakres konkretnego PDB określają selektory etykiet.
Uwaga: Budżet PDB jest uwzględniony tylko przy odwracalnym naruszeniu budżetu (). W sytuacjach takich jak awarie sprzętowe PDB nie zadziała.
Przykład PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Dwa podstawowe parametry to matchLabels i minAvailableW pierwszym parametrze wskazuje się, dla jakich aplikacji obowiązuje budżet. Na przykład, jeśli mam wdrożenia z etykietami app: app-a i app: app-b, to ten PDB będzie stosowany tylko do pierwszego.
Parametr minAvailable uwzględniany podczas opróżniania (czyszczenia) węzła. Na przykład, w naszym przykładzie podczas opróżniania są usuwane wszystkie instancje app: app-a, z wyjątkiem dwóch.
Pozwala to kontrolować, ile instancji aplikacji powinno być uruchomionych w danym momencie.
Monitorowanie sprawności aplikacji
Takie monitorowanie można przeprowadzać na dwa sposoby: za pomocą sond Readiness lub Liveness.
Pierwsza sonda (readiness) określa gotowość kontenera do przyjmowania ruchu.
Druga (liveness) pokazuje, czy kontener jest sprawny, czy trzeba go zrestartować.
Odpowiednie konfiguracje po prostu dodaje się do yaml w celu wdrożenia. Tam można określić czasy oczekiwania, czas opóźnienia oraz liczbę powtórzeń. Żeby dowiedzieć się więcej, zobacz .
Etykiety wszędzie
Etykiety to jedno z podstawowych pojęć w Kubernetes. Umożliwiają obiektom swobodną komunikację oraz tworzenie zapytań na podstawie etykiet. W Kubernetes można nawet przejść do klienta i obserwować zdarzenia na podstawie konkretnych etykiet.
Za pomocą etykiet można zrobić prawie wszystko, ale dobrym przykładem będzie utworzenie kilku środowisk do uruchamiania programów w jednym klastrze.
Załóżmy, że używasz tego samego klastra dla dev i qa. To oznacza, że możesz mieć aplikację app-a, działającą jednocześnie w obu środowiskach qa i dev. W takim przypadku możemy oddzielnie uzyskać dostęp do instancji aplikacji w konkretnym środowisku, wskazując odpowiedni parametr environment. Na przykład, app: app-a i environment: dev dla jednego środowiska, a app: app-a i environment: qa dla drugiego.
Pozwala to uzyskać dostęp do obu instancji aplikacji, na przykład jednocześnie przeprowadzając testy.
Utrzymaj porządek
Kubernetes to bardzo potężny system, ale każda system w końcu może utknąć w dużej liczbie procesów. Kubelet uruchamia wszystkie określone przez ciebie procesy i kontrole, a także swoje własne.
Oczywiście, jedna niezarządzana usługa nie spowolni systemu, a Kubernetes został zaprojektowany z myślą o skalowalności. Ale jeśli zamiast jednej usługi pojawi się milion, kubelet zaczyna mieć trudności.
Jeśli z jakiegoś powodu usuwasz wdrożenie (kontener, obraz, cokolwiek), upewnij się, że zostało ono całkowicie usunięte.
Poznaj Go
Najważniejszą radę zostawiliśmy na koniec. Naucz się języka programowania Go.
Kubernetes jest napisany w Go, wszystkie rozszerzenia są napisane w Go, a także oficjalna biblioteka klienta client-go jest wspierana.
Można go używać do różnych interesujących rzeczy. Na przykład do dostosowywania systemu Kubernetes do swoich potrzeb. Możesz używać własnych programów do zbierania danych, wdrażania aplikacji lub prostego czyszczenia kontenerów.
Nauka języka programowania Go i opanowanie client-go to chyba najważniejsza rada, jaką można dać początkującym użytkownikom Kubernetes.
Co jeszcze przeczytać:
- .
- ?
- .
Źródło: habr.com
