11 rīki, kas uzlabo Kubernetes

Ne visas serveru platformas, pat visjaudīgākās un elastīgākās, atbilst visām prasībām. Lai gan Kubernetes pats par sevi darbojas lieliski, tam var pietrūkt nepieciešamo komponentu pilnībai. Jūs vienmēr atradīsiet īpašu gadījumu, kas ignorē jūsu vajadzības, vai situāciju, kurā Kubernetes nedarbojas pēc noklusējuma instalācijas — piemēram, datu bāzu atbalsts vai CD darbība.

Šeit parādās papildinājumi, paplašinājumi un citi noderīgi rīki šim konteineru orķestratoram, ko atbalsta plašā sabiedrība. Šajā rakstā tiks apskatītas 11 labākās lietas, ko mēs esam atraduši. Mums pašiem tās Southbridge ērti interesē, un mēs plānojam ar tām strādāt praktiski — izpētīt sīkumus un noskaidrot, kas ir iekšā. Daļa no tām lieliski papildinās jebkuru Kubernetes klasteri, bet citas palīdzēs risināt specifiskas problēmas, kas nav īstenotas standarta Kubernetes piegādē.

Gatekeeper: politiku pārvaldība

Projekts Open Policy Agent (OPA) sniedz iespēju veidot politikas virs mākoņa lietojumprogrammu stekiem Kubernetes, sākot no ingress līdz service mesh. Gatekeeper nodrošina nativu Kubernetes funkcionalitāti politiku automātiskai piemērošanai klasterī, kā arī nodrošina uzraudzību par jebkuriem notikumiem vai resursiem, kas pārkāpj politiku. Viss tiek apstrādāts relatīvi jaunā Kubernetes mehānismā, Webhook piekļuves kontrolierī, kas aktivizējas resursu izmaiņu gadījumā. Izmantojot Gatekeeper, OPA politikas kļūst par vēl vienu daļu no jūsu Kubernetes klastera stāvokļa, neprasot pastāvīgu uzraudzību.

Gravity: Pārvietojami Kubernetes klasteri

Ja vēlaties izvietot lietojumprogrammu Kubernetes, daudzas lietojumprogrammas ietver Helm chart, kas vada un automatizē šo procesu. Bet ko darīt, ja vēlaties paņemt savu Kubernetes klasteri "kā ir" un izvietot to kaut kur citur?

Gravity veic Kubernetes klasteru stāvokļu, to attēlu reģistru un palaižamo lietojumprogrammu, ko sauc par "lietojumprogrammu pakotēm", snapshot'us. Šāda pakete, kas ir parasts fails .tar, var replicēt klasteri visur, kur var darboties Kubernetes.

Gravity arī pārbauda, vai mērķa infrastruktūra uzvedas tāpat kā sākotnējā, kā arī vai Kubernetes vide mērķī ir pieejama. Maksas versija Gravity arī pievieno drošības funkcijas, tostarp RBAC un drošības iestatījumu sinhronizāciju starp dažādiem klasteru izvietojumiem.

Pēdējā galvenā versija, Gravity 7, var izplatīt Gravity attēlu esošā Kubernetes klasterī, nevis izvērst pilnīgi jaunu klasteri no attēla. Gravity 7 arī var strādāt ar klasteriem, kas ir uzstādīti bez Gravity attēla izmantošanas. Turklāt Gravity atbalsta SELinux un darbojas ar Teleport SSH vārteju.

Kaniko: Konteineru būvniecība Kubernetes klasterī

Lielākā daļa konteineru attēlu tiek būvēti ārpus konteineru kaudzes. Tomēr dažreiz jāuzbūvē attēls iekšā konteineru kaudzē, piemēram, kaut kur strādājošā konteinerā vai Kubernetes klasterī.

Kaniko veic konteineru būvniecību konteineru vidē, bet bez atkarības no konteinerizācijas pakalpojuma, piemēram, Docker. Tā vietā Kaniko izgūst failu sistēmu no pamata attēla, veic visas būvniecības komandas lietotāja telpā virs izgūtās failu sistēmas, veicot failu sistēmas momentuzņēmumu pēc katras komandas.

Piezīme: Kaniko šobrīd (2020. gada maijā, piezīme tulkotājam) nevar būvēt Windows konteinerus.

Kubecost: Kubernetes palaišanas izmaksu parametri

Lielākā daļa Kubernetes administrēšanas rīku ir vērsti uz lietošanas vienkāršību, uzraudzību, uzvedības izpratni iekšējos podū, utt. Bet kā par izmaksu novērošanu - rubļos un kapeikās - kas saistītas ar Kubernetes palaišanu?

Kubecost apstrādā Kubernetes parametrus reāllaikā, kas noved pie aktuālo izmaksu informācijas saņemšanas no palaistajiem klasteriem pie galvenajiem mākoņa pakalpojumu sniedzējiem, attēlotiem panelī ar katra klastera ikmēneša izmaksām. Izmaksas par operatīvo atmiņu, procesoru, GPU un disku apakšsistēmu tiek sadalītas pa Kubernetes komponentiem (konteineru, podu, pakalpojuma utt.)

Kubecost arī izseko ārpus klastera resursu izmaksas, piemēram, Amazon S3 bucketi, lai gan tās ir ierobežotas līdz AWS. Izmaksu dati var tikt nosūtīti uz Prometheus, lai jūs varētu tos izmantot, lai programmatiski mainītu klastera uzvedību.

Kubecost ir bezmaksas lietošanai, ja jums pietiek ar žurnālu datiem 15 dienām. Papildu funkcijām cenas sākas no 199$ mēnesī par 50 mezglu uzraudzību.

KubeDB: Ražošanas datubāzu palaišana Kubernetes

Datubāzu palaišana Kubernetes ir pietiekami sarežģīta. Jūs atradīsit Kubernetes operatorus MySQL, PostgreSQL, MongoDB un Redis, bet visiem no tiem ir trūkumi. Turklāt tipiska Kubernetes funkcionalitāte neļauj tieši atrisināt lielāko daļu specifisku problēmu ar datubāzēm.

KubeDB palīdz jums izveidot savus Kubernetes operatorus datubāzu pārvaldībai. Datu atjaunošanas, klonēšanas, uzraudzības, momentuzņēmumu izveides un deklaratīvas datubāzu izveides elementi ir tās sastāvdaļas. Ņemiet vērā, ka funkciju atbalsts ir atkarīgs no datubāzes. Piemēram, klastera izveide darbojas PostgreSQL, bet ne MySQL (jau ir, kā pareizi norādījāt dnbstd, piezīme tulkotājam).

Kube-monkey: Chaos Monkey Kubernetes

Visefektīvākais veids stresa testēšanai ir nejauši bojājumi. Šī teorija ir Chaos Monkey no Netflix pamatā, haotiskajam inženierijas instrumentam, kas nejauši izslēdz virtuālās mašīnas un konteinerus ražošanas vidē, lai "stimulētu" izstrādātājus izveidot izturīgākas sistēmas. Kube-monkey — to pašu pamata stresa testēšanas teoriju īstenojums Kubernetes klasteriem. Tas darbojas, nejauši iznīcinot modulīšus klasterī, kurus jūs norādāt, un var tikt konfigurēts darbam noteiktā laikā.

Kubernetes Ingress Controller AWS

Kubernetes nodrošina ārēju slodzes balansētāju un klastera tīkla pakalpojumus caur pakalpojumu, ko sauc par Egress AWS nodrošina slodzes balansēšanas funkcijas, bet automātiski tās nesavieno arīdzīgām Kubernetes funkcijām. Kubernetes Ingress Controller for AWS aizpilda šo trūkumu.

Tas automātiski pārvalda AWS resursus katram ieejas objektam klasterī, radot slodzes balansētājus jaunajiem ieejas resursiem un dzēšot balansētājus, kad resursi tiek dzēsti. Tas izmanto CloudFormation, lai nodrošinātu, ka klastera stāvoklis paliek integrēts. Tas arī atbalsta CloudWatch Alarm iestatījumus un automātiski pārvalda citus elementus, kas tiek izmantoti klasterī, piemēram, SSL sertifikātus un EC2 Auto Scaling Groups.

Kubespray: Automātiska Kubernetes instalācija

Kubespray automātiski instalē gatavu, rūpnieciskai lietošanai paredzētu Kubernetes klasteri, sākot no instalācijas uz „dzelžu” serveriem un beidzot ar galvenajiem publiskajiem mākoniem. Tas izmanto Ansible (Vagrant — papildus), lai uzsāktu izplatīšanu un izveidotu augsti pieejamu klasteri no nulles ar jūsu izvēlēto tīkla papildinājumu (piemēram, Flannel, Calico un citi) uz jūsu izvēlētā populārā Linux izplatījuma, uzstādot uz „dzelžu” serveriem.

Skaffold: Iteratīva izstrāde Kubernetes vidē

Skaffold — viens no Google rīkiem, ko lieto CD lietojumprogrammu organizēšanai Kubernetes. Tiklīdz jūs veicat izmaiņas avota kodā — Skaffold automātiski to identificē, uzsāk būvniecību un izplatīšanu, brīdina, ja rodas kādas kļūdas. Skaffold darbojas pilnībā klienta pusē, tāpēc var būt nelielas nianses ar instalēšanu vai atjaunināšanu. To var izmantot kopā ar esošajiem CICD cauruļvadiem, kā arī sadarboties ar dažiem ārējiem būvju rīkiem, galvenokārt ar Google izstrādāto Bazel.

Teresa: Vienkāršākais PaaS Kubernetes

Teresa ir lietojumprogrammu izplatīšanas sistēma, kas uzsāk vienkāršāko PaaS virs Kubernetes. Lietotāji, kuri ir grupēti pa komandām, var izplatīt un pārvaldīt viņiem piederošās lietojumprogrammas. Tas nedaudz atvieglo darbu cilvēkiem, kuri uzticas šai lietotnei un nevēlas saskarties ar Kubernetes un visām tā sarežģījumiem.

Tilt: Plūsmas atjauninājumu izplatīšana Kubernetes klasteros

Tilt, izstrādāts Windmill Engineering, novēro izmaiņas dažādos Dockerfile failos, un pēc tam pakāpeniski izplata attiecīgos konteinerus Kubernetes klasterī. Patiesībā tas ļauj veikt ražotnes klastera atjaunināšanu reāllaikā, vienkārši atjauninot Dockerfile failus. Tilt veic būvniecību klasterī, avota kods ir viss, kas jāmaina. Jūs varat arī izveidot klastera stāvokļa atjaunošanu un fiksēt kļūdu aktivizācijas apstākļus tieši no Tilt, lai dalītos ar tiem ar komandas locekļiem, lai novērstu kļūdas.

P.S. Visus šos rīkus mēs ne reizi vien esam Southbridge izpētījuši ar mūsu ziņkārīgajām rokām. Lai iepazīstinātu ar reālām praktikām jau (cerams!) oflaina intensīvās nodarbībās februārī. Kubernetes Bāze 8–10 februārī 2021. G. Kubernetes Mega 12.–14. februāris. Godīgi sakot, mēs arī ilgojamies pēc silta un enerģiski uzlādēta klātienes mācību atmosfēras. Neatkarīgi no tā, cik novatorīgas ir tehnoloģijas, tās nevar aizstāt dzīvo cilvēku saziņu un īpašo atmosfēru, kad pulcējas domubiedri.

Avots: habr.com