Rengeteg referencia irodalom található az interneten, de néha a legegyszerűbb tanácsok a legértékesebbek. Csapat lefordított , amelyet a cikk szerzője egy év Kubernetes együttműködés után gyűjtött össze. A tippek nincsenek fontossági sorrendbe rendezve, de úgy gondoljuk, hogy mindenki talál valami hasznosat a maga számára.
A legegyszerűbb parancs a Kubernetes használatához
Először talán a legegyszerűbb és leghasznosabb művelet a Kubernetes-szel való munka során. A következő parancs engedélyezi a parancs befejezését kubectl bash shellben:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Automatikus kiegészítés kubectl A rendszer a .bashrc fájlba íródik, és automatikusan aktiválódik a shell minden indításakor. Ez felgyorsítja a hosszú parancsok és paraméterek beírását, mint pl all-namespaces. További részletek a .
Alapértelmezett memória- és CPU-korlátok a névtérben
Ha az alkalmazás rosszul van megírva, például másodpercenként nyit egy új kapcsolatot az adatbázissal, de soha nem zárja be, akkor a fürt memóriaszivárgást szenved. És ha az alkalmazásban nincs beállítva memóriakorlát a telepítés során, az csomópont meghibásodásához vezethet.
Ennek megakadályozása érdekében a Kubernetes lehetővé teszi az alapértelmezett korlátozások beállítását névterenkénti alapon. A yaml fájlba vannak írva egy adott 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
Hozzon létre egy ilyen yamlt, és alkalmazza bármely névtérre. Például a névtérre limit-example. Mostantól az ebben a névtérben telepített tárolók korlátja 512Mi lesz, kivéve, ha ehhez a tárolóhoz további egyéni korlát van beállítva.
Szemétgyűjtés a Kubernetes régebbi verzióiban
A Kubelet alapértelmezés szerint elindítja a szemétgyűjtést, amikor var/lib/docker a szabad lemezterület 90%-át foglalja el. Ez azonban nagyszerű, a Kubernetes 1.7-ig azonban nem volt alapértelmezett korlátozás a felhasznált inode-ok számára, amelyek megfelelnek a fájlrendszerben lévő fájlok számának.
Lehetséges, hogy a konténer var/lib/docker előfordulhat, hogy csak a lemezterület 50%-át használja, de kifogyhatnak az inode-ok, ami problémákat okoz a dolgozóknak.
A kubelet régebbi, 1.4-től 1.6-ig terjedő verzióihoz hozzá kell adni ezt a jelzőt:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Az 1.7-es és újabb verziókban ez a jelző alapértelmezés szerint be van állítva. A korábbi verziók azonban nem figyelik az inode limitet.
Minikube... kicsi, de erős helyi Kubernetes
A Minikube a legegyszerűbb módja a helyi Kubernetes-fürt futtatásának. Egy egyszerű paranccsal indítható el:
minikube start
A parancs futtatása valódi Kubernetes-fürtöt eredményez a számítógépen.
A trükk az, hogy hogyan kell felépíteni az alkalmazást, és helyileg futtatni az adott fürtön. Hacsak nem kap külön utasítást, a Docker lemezkép a számítógépére épül, nem a fürtre.
Ha arra kényszeríti a Dockert, hogy a képet a helyi Kubernetes-fürtbe küldje, a dokkológép a következő parancsot kapja:
eval $(minikube docker-env)
Most már építhetünk alkalmazásokat egy helyi Kubernetes-fürtre.
Ne adj kubectl hozzáférést mindenkinek
Ez nyilvánvalónak tűnik, de ha több csapat ugyanazt a fürtöt használja alkalmazásaihoz (a Kubernetes erre jött létre), akkor nem szabad mindenkinek megadni kubectl. Jobb, ha a parancsokat különválasztjuk, mindegyikhez saját névteret rendelünk, és RBAC-házirendekkel korlátozzuk a hozzáférést.
Megzavarhatja magát, ha hozzáférési, olvasási, létrehozási, törlési és egyéb műveletek jogait rendeli hozzá minden egyes podhoz. A legfontosabb azonban az, hogy korlátozzuk a titkokhoz való hozzáférést, és csak a rendszergazdák számára engedélyezzük. Így különbséget teszünk azok között, akik felügyelhetik a klasztert, és azokat, akik egyszerűen telepíthetik azt.
Pod költségvetésének kezelése
Hogyan biztosítható, hogy ne legyen leállás egy Kubernetes-fürtben lévő alkalmazásnál? PodDisruptionBudget és ismét PodDisruptionBudget.
A fürtök rendszeresen frissülnek, a csomópontok pedig kiürülnek. Semmi sem áll meg, ez a valóság. Minden egynél több példányt tartalmazó központi telepítésnek tartalmaznia kell egy PDB-t (PodDisruptionBudget). Egy egyszerű yaml-fájlban jön létre, amelyet a fürtre alkalmaznak. Egy adott EKT lefedettségi területét a címkeválasztók határozzák meg.
Megjegyzés: Az EKT költségvetését csak akkor veszik figyelembe, ha a költségvetés megsértése visszafordítható (). Hardverhiba esetén a PDB nem fog működni.
Példa EKT:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
A két fő paraméter a matchLabels и minAvailable. Az első paraméter határozza meg, hogy a költségvetés mely alkalmazásokra vonatkozik. Például, ha vannak címkés telepítéseim app: app-a и app: app-b, akkor ez az EKT csak az elsőre vonatkozik.
Paraméter minAvailable figyelembe kell venni a csomópont ürítésekor (tisztításakor). Például a mi példánkban az ürítés során az összes példányt kilakoltatják app: app-a, kettő kivételével.
Ez lehetővé teszi annak szabályozását, hogy az alkalmazás hány példánya fusson egy adott időpontban.
Alkalmazás állapotának figyelése
Az ilyen megfigyelés kétféleképpen lehetséges: Készenléti vagy Életesség tesztekkel.
Az első próba (readiness) meghatározza a tároló készenlétét a forgalom fogadására.
A második (elevenség) azt mutatja, hogy a tartály egészséges vagy újra kell indítani.
A vonatkozó konfigurációkat egyszerűen hozzáadja a yaml-hez a telepítéshez. Itt megadhatja az időtúllépéseket, a késleltetési időket és az újrapróbálkozások számát. Lásd róluk további részleteket .
A címkék mindenhol ott vannak
A címkék a Kubernetes egyik alapfogalma. Lehetővé teszik, hogy az objektumok szabadon kommunikáljanak egymással, valamint címkék alapján lekérdezéseket készítsenek. A Kubernetesben akár az ügyfélhez is eljuthat, és megtekintheti az eseményeket bizonyos címkékért.
A címkékkel szinte bármit megtehet, de jó példa erre több környezet létrehozása ugyanazon a fürtön lévő programok futtatásához.
Tegyük fel, hogy ugyanazt a fürtöt használja ehhez dev и qa. Ez azt jelenti, hogy jelentkezhet app-a, egyszerre működik mindkét környezetben qa и dev. Ebben az esetben a megfelelő paraméter megadásával külön is elérhetjük az alkalmazáspéldányt egy adott környezetben environment. Például app: app-a и environment: dev egy környezetre, és app: app-a и environment: qa a másodiknak.
Ez lehetővé teszi az alkalmazás mindkét példányának elérését, például egyidejű tesztelés céljából.
Megszervezve
A Kubernetes egy nagyon erős rendszer, de végül bármelyik rendszer elakadhat túl sok folyamat miatt. A Kubelet futtatja az összes megadott folyamatot és ellenőrzést, valamint a sajátját is.
Természetesen egyetlen árva szolgáltatás sem lassítja le a rendszert, a Kubernetes pedig az alapoktól kezdve méretezhető. De ha egy szolgáltatás helyett egymillió jelenik meg, a kubelet fuldokolni kezd.
Ha valamilyen oknál fogva töröl egy központi telepítést (tárolót, képet, bármit), egyszerűen végezzen teljes tisztítást.
Ismerkedj meg Go-val
A fő tanácsot a végére tartogattuk. Tanuld meg a Go programozási nyelvet.
A Kubernetes Go-ban van fejlesztve, minden kiterjesztés Go-ban van írva, és a kliens-go klienskönyvtár is hivatalosan támogatott.
Különféle és érdekes dolgokra használható. Például, hogy a Kubernetes rendszert ízlés szerint bővítse. Így saját programjait használhatja adatok gyűjtésére, alkalmazások telepítésére vagy egyszerűen tárolók tisztítására.
A Go programozási nyelv elsajátítása és a client-go elsajátítása talán a legfontosabb tanács, amelyet az új Kubernetes-felhasználóknak adhat.
Mit kell még olvasni:
- .
- ?
- .
Forrás: will.com