Az interneten sok referenciaanyag található, de néha a legegyszerűbb tanácsok a legértékesebbek. A csapat lefordította , amelyet a cikk szerzője egy évnyi Kubernetes munkája során gyűjtött össze. A tanácsok nem fontossági sorrendben vannak, de úgy gondoljuk, hogy mindenki talál benne hasznos dolgokat.
A legegyszerűbb parancs a Kubernetes használatában
Először is, talán a legkönnyebb és leghasznosabb feladat a Kubernetes használatában. A következő parancs aktiválja a parancsok autokomplettálását kubectl a bash shellben:
echo "source > ~//.bashrc
Az autokomplettálás kubectl a .bashrc fájlba kerül, és automatikusan aktiválódik, amikor a shell elindul. Ez felgyorsítja a hosszú parancsok és paraméterek beírását, mint például all-namespaces. További információ .
Alapértelmezett memória- és CPU-korlátozások névtérben
Ha az alkalmazás hibásan van írva, például minden másodpercben új kapcsolatot nyit az adatbázissal, de soha nem zárja be azt, memória szivárgás történik a klaszterben. Ha az alkalmazás telepítésekor nincs memóriahatár beállítva, az csomópontleálláshoz vezethet.
Ennek megelőzése érdekében a Kubernetes lehetőséget ad a névtér szintű alapértelmezett korlátozások beállítására. Ezek egy yaml fájlban vannak meghatározva a konkrét névtérhez. Íme egy példa egy ilyen fájlra:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Hozz létre egy ilyen yaml fájlt, és alkalmazd bármely névtérre. Például a limit-example. Mostantól bármely, ebben a névtérben telepített konténerre érvényes lesz az 512Mi korlátozás, hacsak a konténerhez nem állítanak be külön egyedi korlátot.
A szemétgyűjtés régi Kubernetes verziókban
A Kubelet alapértelmezés szerint elkezdi a szemétgyűjtést, amikor var/lib/docker a rendelkezésre álló lemezterület 90%-át elfoglalja. Ez nagyszerű, azonban a Kubernetes 1.7 verzióig nem volt alapértelmezett korlátozás a használt inode indexelési deszkák számában, amelyek megfelelnek a fájlrendszer fájljainak számának.
Potenciálisan a konténered var/lib/docker csak a rendelkezésre álló lemezterület 50%-át használhatja, de az inodok elfogyhatnak, ami problémákat okozhat a munkafolyamatokban.
A kubelet 1.4 és 1.6 közötti régi verzióiban egy ilyen kapcsolót kell hozzáadni:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
A 1.7-es és annál frissebb verziókban ez a zászló alapértelmezés szerint be van állítva. Az előző verziók nem követik az inodok limitjét.
A Minikube... kicsi, de erőteljes helyi Kubernetes.
A Minikube a legegyszerűbb módja egy helyi Kubernetes klaszter indításának. Egy egyszerű parancs futtatásával elindítható:
minikube start
Ennek a parancsnak a végrehajtása után a számítógépén valódi Kubernetes klaszter működik.
A trükk az, hogyan kell az alkalmazást felépíteni és helyben futtatni ebben a klaszterben. Ha nem adunk speciális utasításokat, a Docker-kép a számítógépén fog felépülni, nem a klaszterben.
Ahhoz, hogy a Dockert rávegyük, hogy a képet a helyi Kubernetes klaszterre küldje, a docker-machine a következő parancsot kapja:
eval $(minikube docker-env)
Most már alkalmazásokat építhetünk a helyi Kubernetes klaszteren.
Ne adjunk hozzáférést a kubectl-hez mindenkinek.
Ez nyilvánvalónak tűnik, de ha több csapat használ egy klasztert az alkalmazásaikhoz (amiért a Kubernetes létrejött), nem érdemes egyszerűen mindenkinek megadni. kubectlJobb, ha szétválasztjuk a csapatokat, és minden csapatnak a saját névtartományát biztosítjuk, korlátozva a hozzáférést az RBAC politikák révén.
Lehetőség van arra, hogy minden pod számára jogokat állítsunk be a hozzáférés, olvasás, létrehozás, törlés és más műveletek végrehajtására. De a legfontosabb az, hogy korlátozzuk a hozzáférést a titkokhoz, csak az adminisztrátorok számára engedélyezve azt. Így megkülönböztetjük azokat, akik adminisztrálhatják a klasztert, és azoktól, akik csak telepíthetnek benne.
Kezelje a podok költségvetését.
Hogyan garantálhatjuk, hogy az alkalmazásnak ne legyen leállása a Kubernetes klaszterben? PodDisruptionBudget, és még egyszer PodDisruptionBudget.
A klaszterek időről időre frissülnek, és a csomópontok kiürülnek. Semmi sem marad meg, ez a valóság. Minden, több mint egy példányt tartalmazó telepítéshez kötelezően hozzá kell adni a PDB-t (PodDisruptionBudget). Ez egy egyszerű yaml fájlban jön létre, amelyet a klaszterhez alkalmazunk. A konkrét PDB lefedettségét a címkekiválasztók határozzák meg.
Megjegyzés: A PDB költségvetése csak a visszafordítható költségvetés megsértése esetén érvényes (). Hardverhibák esetén a PDB nem lép működésbe.
Példa PDB-re:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
A két alapvető paraméter a matchLabels és minAvailableAz első paraméterben megadjuk, hogy mely alkalmazásokra vonatkozik a költségvetés. Például, ha van néhány telepítésem címkékkel app: app-a és app: app-b, akkor ez a PDB csak az elsőre vonatkozik.
A parameter minAvailable figyelembe vételre kerül a csomópont kiürítése (takarítása) során. Például a mi esetünkben a kiürítés során minden példány ki lesz szorítva app: app-a, kivéve kettőt.
Ez lehetővé teszi a konténerben futó alkalmazásoknak a pillanatnyi példányainak a számának ellenőrzését.
Az alkalmazás állapotának ellenőrzése
Ez a monitoring kétféleképpen lehet: Readiness vagy Liveness próba segítségével.
Az első próba (readiness) meghatározza, hogy a konténer kész-e a forgalom fogadására.
A második (liveness) jelzi, hogy a konténer működik-e vagy újra kell indítani.
A megfelelő konfigurációk egyszerűen hozzáadhatók a yaml-hoz a telepítéshez. Ott megadhatók a timeoutok, késési idő és a próbák száma. Részletesebben róluk itt olvashat .
Címkék mindenhol
A címkék a Kubernetes egyik alapvető fogalma. Ezek lehetővé teszik az objektumok szabad összekapcsolását egymással, valamint a címkék alapján történő lekérdezés készítését. A Kubernetesben akár a klienshez is át lehet térni, és figyelni az eseményeket egy adott címke alapján.
A címkékkel gyakorlatilag bármit meg lehet valósítani, de jó példa lehet több környezet létrehozása a programok futtatásához egy klaszterben.
Tegyük fel, hogy ugyanazt a klasztert használja dev és qa. Ez azt jelenti, hogy lehet egy app-a, amely egyszerre működik mindkét környezetben qa és dev. Ebben az esetben különböző példányhoz férhetünk hozzá a konkrét környezetben, a megfelelő paraméter megadásával környezet. Például, app: app-a és environment: dev az egyik környezethez, és app: app-a és environment: qa a másikhoz.
Ez lehetővé teszi, hogy mindkét alkalmazás példányához egyszerre hozzáférhessünk, például tesztelés végrehajtásához.
Rendbe rakni
A Kubernetes egy nagyon erőteljes rendszer, de bármelyik rendszer végül belefulladhat a rengeteg folyamatba. A Kubelet elindítja az Ön által megadott összes folyamatot és ellenőrzést, valamint a sajátjait is.
Természetesen egy elhanyagolt szolgáltatás nem lassítja le a rendszert, és a Kubernetes kezdetben a skálázhatóságra lett tervezve. De ha egymillió szolgáltatás van, a kubelet már nehezen birkózik meg.
Ha valamilyen okból eltávolít egy telepítést (konténer, kép, bármi), csak győződjön meg róla, hogy teljesen tisztít.
Ismerkedjen meg a Go-val
A legfontosabb tanácsot a végére hagytuk. Tanulja meg a Go programozási nyelvet.
A Kubernetes Go nyelven készült, minden kiterjesztés Go-ban íródott, és hivatalosan támogatott a client-go kliens könyvtár.
Diverse és érdekes dolgokra használható. Például a Kubernetes rendszer bővítésére az Ön ízlése szerint. Így saját programokat használhat adatok gyűjtésére, alkalmazások telepítésére vagy konténerek egyszerű tisztítására.
A legfontosabb tanács, amit a Kubernetes kezdő felhasználóknak adhatunk, hogy tanulják meg a Go programozási nyelvet és sajátítsák el a client-go használatát.
Mit érdemes még olvasni:
- .
- ?
- .
Forrás: habr.com
