Það er mikið af heimildarritum á netinu en stundum eru einföldustu ráðin dýrmætust. Lið þýtt , sem höfundur greinarinnar safnaði saman eftir árs samstarf við Kubernetes. Ábendingunum er ekki raðað eftir mikilvægi, en við teljum að allir finni eitthvað gagnlegt fyrir sig.
Einfaldasta skipunin til að vinna með Kubernetes
Til að byrja með, kannski einfaldasta og gagnlegasta aðgerðin í að vinna með Kubernetes. Eftirfarandi skipun gerir kleift að ljúka skipunum kubectl í bash skel:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Sjálfvirk útfylling kubectl verður skrifað í .bashrc skrána og verður sjálfkrafa virkjuð í hvert skipti sem skelin er ræst. Þetta flýtir fyrir því að slá inn langar skipanir og færibreytur eins og all-namespaces. Lestu meira í .
Sjálfgefin takmörk fyrir minni og örgjörva í nafnrými
Ef forritið er vitlaust skrifað opnar það til dæmis nýja tengingu við gagnagrunninn á hverri sekúndu en lokar honum aldrei, þá er minnisleka í þyrpingunni. Og ef forritið er ekki með minnistakmörk stillt við uppsetningu getur það leitt til bilunar í hnút.
Til að koma í veg fyrir þetta leyfir Kubernetes þér að setja sjálfgefnar takmarkanir á hvert nafnrými. Þau eru skrifuð í yaml skrána fyrir ákveðið nafnrými. Hér er dæmi um slíka skrá:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Búðu til svona yaml og notaðu til hvaða nafnrýmis sem er. Til dæmis í nafnrýmið limit-example. Nú munu allir gámar sem eru notaðir í þessu nafnarými hafa takmörk upp á 512Mi, nema önnur einstök takmörk séu til viðbótar sett fyrir þennan gám.
Sorphirða í eldri útgáfum af Kubernetes
Kubelet byrjar sjálfgefið sorphirðu þegar var/lib/docker tekur 90% af tiltæku plássi. Þetta er hins vegar frábært, þar til Kubernetes 1.7 voru engin sjálfgefin takmörk á fjölda inóða sem notuð eru, sem samsvara fjölda skráa í skráarkerfinu.
Hugsanlega ílátið þitt var/lib/docker getur aðeins notað 50% af diskplássinu, en gæti klárast af inódum, sem mun valda vandræðum fyrir starfsmenn.
Í eldri útgáfum af kubelet frá 1.4 til 1.6 verður þú að bæta við þessum fána:
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
Í 1.7 og síðari útgáfum er þetta flagg sjálfgefið stillt. Hins vegar, fyrri útgáfur fylgjast ekki með inode takmörkunum.
Minikube... lítill en öflugur staðbundinn Kubernetes
Minikube er auðveldasta leiðin til að reka staðbundinn Kubernetes þyrping. Það er hleypt af stokkunum með einfaldri skipun:
minikube start
Að keyra þessa skipun leiðir til þess að raunverulegur Kubernetes þyrping keyrir á vélinni þinni.
The bragð er hvernig á að byggja forritið og keyra það á staðnum á þeim þyrping. Nema sérstaklega fyrirmæli, Docker myndin verður byggð á tölvunni þinni en ekki á þyrpingunni.
Til að þvinga Docker til að ýta myndinni í staðbundna Kubernetes klasann fær docker vélin eftirfarandi skipun:
eval $(minikube docker-env)
Nú getum við smíðað forrit á staðbundnum Kubernetes klasa.
Ekki veita öllum aðgang að kubectl
Þetta virðist augljóst, en ef mörg teymi nota sama klasann fyrir forritin sín (sem er það sem Kubernetes var búið til fyrir), ættirðu ekki bara að gefa öllum kubectl. Það er betra að aðskilja skipanirnar, úthluta hverri þeirra eigin nafnrými og takmarka aðgang með RBAC stefnum.
Þú getur ruglast með því að úthluta rétti til að fá aðgang, lesa, búa til, eyða og öðrum aðgerðum fyrir hvern hólf. En aðalatriðið er að takmarka aðgang að leyndarmálum, leyfa það aðeins stjórnendum. Þannig munum við gera greinarmun á þeim sem geta stjórnað klasanum og þeim sem geta einfaldlega sent til hans.
Stjórna Pod Budgets
Hvernig á að tryggja enga niður í miðbæ fyrir forrit í Kubernetes klasa? PodDisruptionBudget og aftur PodDisruptionBudget.
Klasar eru uppfærðir reglulega og hnútar eru tæmdir. Ekkert stendur í stað, það er raunveruleikinn. Sérhver dreifing með fleiri en einu tilviki ætti að innihalda PDB (PodDisruptionBudget). Það er búið til í einfaldri yaml skrá sem er sett á klasann. Umfangssvæði tiltekins PDB er ákvarðað af merkimiðavöldum.
Ath: Fjárhagsáætlun PDB er aðeins tekin til greina þegar fjárhagsáætlunarbrotið er afturkræft (). Í aðstæðum eins og vélbúnaðarbilun mun PDB ekki virka.
Dæmi PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Helstu breyturnar tvær eru matchLabels и minAvailable. Fyrsta færibreytan tilgreinir hvaða forrit fjárhagsáætlunin á við. Til dæmis, ef ég er með dreifingar með merki app: app-a и app: app-b, þá mun þessi PDB aðeins gilda um þann fyrsta.
Viðfang minAvailable tekið tillit til þess þegar hnúturinn er tæmdur (hreinsaður). Til dæmis, í okkar dæmi, meðan á tæmingu stendur, er öllum tilfellum vísað út app: app-a, nema tveir.
Þetta gerir þér kleift að stjórna því hversu mörg tilvik af forritinu eiga að vera í gangi hverju sinni.
Heilsueftirlit með umsókn
Slík vöktun er möguleg á tvo vegu: með því að nota viðbúnaðarpróf eða lífleikapróf.
Fyrsti rannsakandi (viðbúnaður) ákvarðar reiðubúinn ílátið til að taka á móti umferð.
Annað (lifandi) sýnir hvort ílátið er heilbrigt eða þarf að endurræsa það.
Viðeigandi stillingum er einfaldlega bætt við yaml fyrir uppsetningu. Þar er hægt að tilgreina tímamörk, seinkunartíma og fjölda endurtekinna prófana. Sjá nánari upplýsingar um þau .
Merki eru alls staðar
Merki eru eitt af grundvallarhugtökum Kubernetes. Þeir leyfa hlutum að eiga frjáls samskipti sín á milli, auk þess að búa til fyrirspurnir byggðar á merkimiðum. Í Kubernetes geturðu jafnvel farið til viðskiptavinarins og horft á viðburði fyrir ákveðin merki.
Þú getur gert nánast hvað sem er með merkjum, en gott dæmi væri að búa til mörg umhverfi til að keyra forrit á sama þyrpingunni.
Segjum að þú notir sama klasa fyrir dev и qa. Þetta þýðir að þú getur haft umsókn app-a, vinna samtímis í báðum umhverfi qa и dev. Í þessu tilviki getum við sérstaklega fengið aðgang að forritatilvikinu í tilteknu umhverfi með því að tilgreina viðeigandi færibreytu environment. Til dæmis, app: app-a и environment: dev fyrir eitt umhverfi, og app: app-a и environment: qa fyrir annað.
Þetta gerir þér kleift að fá aðgang að báðum tilfellum forritsins, til dæmis til að framkvæma prófanir samtímis.
Settu hlutina í röð
Kubernetes er mjög öflugt kerfi, en hvaða kerfi sem er getur á endanum fest sig í sessi með of mörgum ferlum. Kubelet keyrir alla ferla og athuganir sem þú tilgreinir, svo og sína eigin.
Auðvitað mun ein munaðarlaus þjónusta ekki hægja á kerfinu og Kubernetes er hannað til að stækka frá grunni. En ef milljón birtist í stað einnar þjónustu byrjar kúbelet að kafna.
Ef þú eyðir dreifingu af einhverjum ástæðum (íláti, mynd, hvað sem er), vertu bara viss um að gera algjöra hreinsun.
Hittu Go
Við geymdum aðalráðið til síðasta. Lærðu Go forritunarmálið.
Kubernetes er þróað í Go, allar viðbætur eru skrifaðar í Go, og client-go viðskiptavinasafnið er einnig opinberlega stutt.
Það er hægt að nota fyrir mismunandi og áhugaverða hluti. Til dæmis til að stækka Kubernetes kerfið að þínum smekk. Svo þú getur notað þín eigin forrit til að safna gögnum, dreifa forritum eða einfaldlega hreinsa upp gáma.
Að læra Go forritunarmálið og ná tökum á client-go er kannski mikilvægasta ráðið sem þú getur gefið nýjum Kubernetes notendum.
Hvað annað að lesa:
- .
- ?
- .
Heimild: www.habr.com