
Jo nuk janë të gjitha platformat e serverëve, madje as ato më të fuqishmet dhe më të shkallëzuara, që plotësojnë të gjitha nevojat ashtu siç janë. Megjithëse Kubernetes funksionon shkëlqyeshëm vetë, mund t'u mungojnë disa pjesë të nevojshme. Gjithmonë do të gjeni raste specifike që injorojnë nevojat tuaja, ose ku Kubernetes nuk do të funksionojë me instalimin e tij standard — për shembull, mbështetja për baza të dhënash ose operimi i CDN.
Këtu shfaqen shtesat, zgjerimet dhe të tjera gjëra të këndshme për këtë orkestrator konteinerësh, të mbështetur nga një komunitet shumë të gjerë. Në këtë artikull do të përmendim 11 gjërat më të mira që kemi gjetur. Për ne vetë, ato janë shumë interesante, dhe ne planifikojmë t'i shqyrtojmë ato në praktikë — të çmontojmë dhe të shohim se çfarë ndodhet brenda. Disa nga ato do të plotësojnë shkëlqyeshëm çdo grup Kubernetes, ndërsa të tjerat do të ndihmojnë në zgjidhjen e detyrave specifike, që nuk janë implementuar në shpërndarjen standard të Kubernetes.
Gatekeeper: menaxhimi i politikave
Projekt (OPA) ofron mundësinë e krijimit të politikave mbi grumbujt e aplikacioneve në Kubernetes, duke filluar nga ingress dhe duke përfunduar në service mesh. ofron një mundësi të natyrshme për Kubernetes për të zbatuar politikat në grupin automatikisht, si dhe ofron verifikimin e çdo ngjarjeje ose burimi që shkel politikën. Të gjitha këto përpunohen nga një mekanizëm relativisht i ri i Kubernetes, menaxheri i aprovimit të Webhooks, që aktivizohet kur ndryshojnë burimet. Me ndihmën e Gatekeeper, politikat OPA bëhen një pjesë tjetër e gjendjes së grupit tuaj Kubernetes, pa pasur nevojë për mbikëqyrje të vazhdueshme.
Gravity: Grumbujt e transportueshëm Kubernetes
Nëse dëshironi të përhapni një aplikacion në Kubernetes, shumë aplikacione ka Helm chart, i cili e drejton dhe automatizon këtë proces. Por çfarë ndodh nëse dëshironi të merrni grumbullin tuaj Kubernetes "ashtu si është", dhe ta shpërndani diku tjetër?
krijon fotografi të gjendjes së grumbujve Kubernetes, regjistrin e tyre për imazhet e kontejnerëve, si dhe aplikacionet që funksionojnë, të quajtura "paketa aplikacionesh". Një paketë, që përbën një skedë standarde .tar, mund të riprodhojë grumbullin kudo që mund të punojë Kubernetes.
Gravity gjithashtu verifikon që infrastruktura e synuar funksionon ashtu si origjinali, si dhe që mjedisi Kubernetes në destinacion është i aksesueshëm. Versioni me pagesë i Gravity gjithashtu shton funksione sigurie, duke përfshirë RBAC dhe mundësinë e sinkronizimit të cilësimeve të sigurisë në shpërndarje të ndryshme grumbujsh.
Versioni i fundit kryesor, Gravity 7, mund të shpërndajë imazhin Gravity në një grup ekzistues Kubernetes, në vend që të krijojë një grup të ri nga imazhi. Gravity 7 gjithashtu mund të punojë me grumbuj që janë instaluar pa përdorur imazhin Gravity. Për më tepër, Gravity mbështet SELinux dhe punon në mënyrë natyrale me portin Teleport SSH.
Kaniko: Ndërtoni kontejnerë në grupin Kubernetes
Shumica e imazheve të kontejnerëve ndërtohen në sisteme jashtë grumbujve të kontejnerëve. Megjithatë, ndonjëherë është e nevojshme të ndërtohet një imazh brenda grumbullit të kontejnerëve, për shembull diku brenda një kontejneri funksional, apo në një grup Kubernetes.
ndërton kontejnerë brenda mjedisit të kontejnerëve, por pa varësi nga një shërbim kontejnerizimi, siç është Docker. Në vend të kësaj, Kaniko nxjerr sistemin e skedarëve nga imazhi bazë, ekzekuton të gjitha komandat e ndërtimit në hapësirën e përdoruesit mbi sistemin e skedarëve të nxjerrë, duke bërë një foto të sistemit të skedarëve pas çdo komande.
Shënim: Kaniko aktualisht (maj 2020) shënim i përkthyesitnuk mund të ndërtojë kontejnerë Windows.
Kubecost: Mundësitë e kostos për nisjen e Kubernetes
Shumica e mjeteve të administrimit Kubernetes synojnë lehtësinë e përdorimit, monitorimin, kuptimin e sjelljes brenda pod, etj. Por çfarë ndodh me vëzhgimin e kostos — në rubla dhe cope — që lidhet me nisjen e Kubernetes?
punon me parametrat e Kubernetes në kohë reale, gjë që çon në mbledhjen e informacionit mbi kostot aktuale nga grumbujt e nisur te ofruesit kryesorë të shërbimeve të çelikut, të shfaqur në panelin me kostot mujore të secilit grumbull. Çmimet për RAM-në, kohën e procesorit, GPU-në dhe sistemin e diskëve janë të shpërndara sipas komponentëve të Kubernetes (kontejner, pod, shërbim, etj.)
Kubecost gjithashtu ndjek kostot e burimeve jashtë grumbujve, siç janë Amazon S3 buckets, megjithëse është e kufizuar në AWS. Të dhënat mbi kostot mund të dërgohen në Prometheus, kështu që mund t'i përdorni për të ndryshuar sjelljen e grumbullit me program.
Kubecost është falas për t'u përdorur, nëse ju mjaftojnë të dhënat e regjistrave për 15 ditë. Për funksione të tjera, çmimet fillojnë nga 199$ në muaj për monitorimin e 50 node-ve.
KubeDB: Nisja e bazave të dhënash të betejave në Kubernetes
Datenbase janë gjithashtu mjaft të vështira për t'u lançuar me efektivitet në Kubernetes. Do të gjeni operatorë Kubernetes për MySQL, PostgreSQL, MongoDB dhe Redis, por të gjithë ata kanë mangësi. Po ashtu, grupi tipik i funksioneve të Kubernetes nuk lejon të zgjidhen drejtpërdrejt shumicën e problemeve specifike me bazat e të dhënave.
ndihmon që të krijoni operatorët tuaj Kubernetes për menaxhimin e bazave të të dhënave. Aktivitetet si backup, klonim, monitorim, krijimi i kopjeve dhe krijimi deklarativ i bazave janë përbërësit e tij. Rrethanat e mbështetjes së funksioneve varen nga baza e të dhënave. Për shembull, krijimi i një klasteri funksionon për PostgreSQL, por jo për MySQL ( ka, siç e theksoi saktë , shënim i përkthyesit).
Kube-monkey: Chaos Monkey për Kubernetes
Mënyra më e sigurt për testimin e stresit janë dështimet e rastësishme. Kjo teori është në themel të Chaos Monkey nga Netflix, një mjet ingjinierik haotik që ndalon në mënyrë rastësore makina virtuale dhe kontejnerë në mjedisin e prodhimit, për të "nxitur" zhvilluesit të krijojnë sisteme më të qëndrueshme. - është një implementim i së njëjtës teori themelore të testimit të stresit për klasterat Kubernetes. Ai funksionon duke vrarë në mënyrë rastësore module në klasterin që ju caktoni dhe gjithashtu mund të konfigurohet për të punuar në një interval të caktuar kohor.
Kubernetes Ingress Controller për AWS
Kubernetes siguron një balancues të ngarkesës së jashtme dhe shërbime të rrjetit të klasterit përmes një shërbimi të quajtur AWS ofron funksione balancimi ngarkese, por nuk i lidh ato automatikisht me të njëjtat mundësi të Kubernetes. mbulon këtë boshllëk.
Ai automatizon menaxhimin e burimeve AWS për çdo objekt ingress në klaster, duke krijuar balancues ngarkese për resurset e reja të ingress dhe duke hequr balancuesit kur resurset hiqen. Ai përdor CloudFormation për të garantuar që gjendja e klasterit të mbetet e integruar. Ai gjithashtu mbështet konfigurimet e Alarmit CloudWatch dhe menaxhon automatikisht elementë të tjerë të përdorur në klaster, si certifikatat SSL dhe Grupet e Auto Scaling të EC2.
Kubespray: Instalimi automatik i Kubernetes
automatizon instalimin e një klasteri Kubernetes të gatshëm për përdorim industrial, duke filluar nga instalimi në serverë "metalik", deri në cloud-ët publikë të njohur. Ai përdor Ansible (Vagrant - opsional) për të filluar shpërndarjen dhe për të ndërtuar një klaster të ardhshëm me disponueshmëri të lartë nga zero me shtesën tuaj të rrjetit të zgjedhur (si Flannel, Calico dhe të tjera) në distribucionin tuaj të njohur të Linux kur instaloni në serverët "metalik".
Skaffold: Zhvillimi iterativ për Kubernetes
- është një nga mjetet e Google, të përdorura për organizimin e aplikacioneve CD në Kubernetes. Sapo bëni ndryshime në kodin burim, skaffold e identifikon automatikisht, fillon ndërtimin dhe shpërndarjen, dhe ju paralajmëron nëse ka ndonjë gabim. Skaffold ekzekutohet plotësisht në anën e klientit, kështu që mund të ketë disa nuanca me instalimin ose azhurnimin. Ai mund të përdoret me tubacione ekzistuese CICD, si dhe të ndërveprojë me disa mjete të jashtme ndërtimi, kryesisht me Bazel nga Google.
Teresa: PaaS-i më i thjeshtë mbi Kubernetes
është një sistem shpërndarjeje aplikacionesh që ekzekuton një PaaS të thjeshtë mbi Kubernetes. Përdoruesit, të ndarë në ekipe, mund të shpërndajnë dhe menaxhojnë aplikacionet e tyre. Kjo e bën punën më të thjeshtë për ata që besojnë në këtë aplikacion dhe nuk duan të merren me Kubernetes dhe të gjitha kompleksitetet e tij.
Tilt: Dërgimi i përditësimeve të kontejnerëve në klasterat Kubernetes
, e zhvilluar nga Windmill Engineering, vëzhgon ndryshimet në skedarë të ndryshëm Dockerfile dhe më pas gradualisht shpërndan kontejnerët përkatës në klasterin Kubernetes. Në thelb, ai lejon përditësimin e klasterit në prodhim në kohë reale thjesht duke rinovuar skedarët Dockerfile. Tilt bën ndërtimin brenda klasterit, duke përdorur kodin burim si gjithçka që duhet ndryshuar. Ju gjithashtu mund të bëni një kopje të gjendjes së klasterit dhe të regjistroni kushtet e papërshtatshmërisë direkt nga Tilt, për t'i ndarë me anëtarët e ekipit për debugging.
P.S. Të gjithë këto mjete ne i kemi provuar disa herë me duarton e gjykueshme. Për të paraqitur praktikat reale tashmë (shpresoj!) në intensive offline në shkurt. 8–10 shkurt 2021. Dhe 12–14 shkurt. Sinqerisht, gjithashtu na ka munguar atmosfera e ngrohtë dhe energjikë e mësimit offline. Çfarëdo qoftë teknologjitë e avancuara, ato nuk e zëvendësojnë komunikimin njerëzor dhe atmosferën e veçantë, kur bashkohen mendje të ngjashme. 12–14 shkurt. Sinqerisht, ne gjithashtu na ka munguar atmosfera e ngrohtë dhe energjike e mësimit offline. Çfarëdo teknologjie avancuara që të jetë, ato nuk do të zëvendësojnë kurrë komunikimin njerëzor dhe atmosferën e veçantë kur bashkohen njerëz me mendime të ngjashme.
Burimi: habr.com
