Stāsta par Kubernetes populārāko pakotņu pārvaldnieku būtību varētu attēlot, izmantojot emocijzīmi:
- kaste ir Helm (kas ir vistuvāk jaunākajai Emoji versijai);
- slēdzene - apsardze;
- mazais cilvēks ir problēmas risinājums.
Patiesībā viss būs nedaudz sarežģītāk, un stāsts ir pilns ar tehniskām detaļām par Kā padarīt Helmu drošu.
- Īsumā, kas ir Helms, ja nezināt vai aizmirsāt. Kādas problēmas tas risina un kur tas atrodas ekosistēmā.
- Apskatīsim Helmas arhitektūru. Neviena saruna par drošību un to, kā padarīt rīku vai risinājumu drošāku, nenotiek, neizprotot komponenta arhitektūru.
- Apspriedīsim Helm komponentus.
- Degošākais jautājums ir par nākotni – Helm 3 jaunā versija.
Viss šajā rakstā norādītais attiecas uz Helm 2. Šī versija pašlaik tiek ražota, un, visticamāk, tā ir tā, kuru pašlaik izmantojat, un tajā ir ietverti drošības riski.
Par runātāju: Aleksandrs Hajorovs () ir izstrādāts jau 10 gadus, palīdzot uzlabot saturu un pievienojās komitejai . Tagad viņš strādā uzņēmumā Chainstack kā izstrādes vadītājs — tas ir hibrīds starp izstrādes vadītāju un personu, kas ir atbildīga par galīgo laidienu piegādi. Tas ir, tas atrodas kaujas laukā, kur notiek viss no produkta radīšanas līdz tā darbībai.
Chainstack ir mazs, aktīvi augošs jaunuzņēmums, kura misija ir ļaut klientiem aizmirst par infrastruktūru un decentralizēto lietojumprogrammu darbības sarežģītību; izstrādes komanda atrodas Singapūrā. Nelūdziet Chainstack pārdot vai pirkt kriptovalūtu, bet piedāvājiet runāt par uzņēmuma blokķēdes ietvariem, un viņi jums ar prieku atbildēs.
Stūre
Šis ir Kubernetes pakotnes (diagrammas) pārvaldnieks. Intuitīvākais un universālākais veids, kā iekļaut lietojumprogrammas Kubernetes klasterī.
Mēs, protams, runājam par strukturālāku un rūpnieciskāku pieeju, nevis par savu YAML manifestu izveidi un nelielu utilītu rakstīšanu.
Helm ir labākais, kas šobrīd ir pieejams un populārs.
Kāpēc Helma? Galvenokārt tāpēc, ka to atbalsta CNCF. Cloud Native ir liela organizācija un ir mātes uzņēmums projektiem Kubernetes, etcd, Fluentd un citiem.
Vēl viens svarīgs fakts ir tas, ka Helm ir ļoti populārs projekts. Kad 2019. gada janvārī sāku runāt par to, kā padarīt Helmu drošu, projektam GitHub bija tūkstoš zvaigžņu. Līdz maijam to bija 12 tūkstoši.
Daudzus cilvēkus interesē Helm, tāpēc pat tad, ja jūs to vēl neizmantojat, jums būs noderīgi uzzināt par tā drošību. Drošība ir svarīga.
Helm galveno komandu atbalsta Microsoft Azure, un tāpēc atšķirībā no daudziem citiem tas ir diezgan stabils projekts. Helm 3 Alpha 2 iznākšana jūlija vidū liecina, ka pie projekta strādā diezgan daudz cilvēku, kuriem ir vēlme un enerģija Helm attīstīt un uzlabot.
Helm atrisina vairākas Kubernetes lietojumprogrammu pārvaldības pamatproblēmas.
- Pielietojuma iepakojums. Pat tāda lietojumprogramma kā “Sveika, pasaule” pakalpojumā WordPress jau sastāv no vairākiem pakalpojumiem, un jūs vēlaties tos iesaiņot kopā.
- Šo lietojumprogrammu pārvaldības sarežģītības pārvaldība.
- Dzīves cikls, kas nebeidzas pēc lietojumprogrammas instalēšanas vai izvietošanas. Tas turpina darboties, tas ir jāatjaunina, un Helm palīdz ar to un cenšas ieviest pareizos pasākumus un politiku.
Iepakošana maisos tas ir sakārtots skaidri: ir metadati, kas pilnībā atbilst parastā Linux, Windows vai MacOS pakotņu pārvaldnieka darbam. Tas ir, repozitorijs, atkarības no dažādām pakotnēm, meta informācija lietojumprogrammām, iestatījumi, konfigurācijas līdzekļi, informācijas indeksēšana utt. Helm ļauj to visu iegūt un izmantot lietojumprogrammām.
Sarežģītības vadība. Ja jums ir daudz viena veida lietojumprogrammu, ir nepieciešama parametrēšana. Veidnes nāk no tā, taču, lai nebūtu jāizdomā savs veids, kā izveidot veidnes, varat izmantot to, ko Helm piedāvā.
Lietojumprogrammu dzīves cikla pārvaldība - manuprāt, tas ir interesantākais un neatrisinātākais jautājums. Tāpēc es atbraucu uz Helmu toreiz. Mums bija jāseko līdzi lietojumprogrammu dzīves ciklam, un mēs vēlējāmies pārvietot mūsu CI/CD un lietojumprogrammu ciklus uz šo paradigmu.
Helm ļauj:
- pārvaldīt izvietošanu, ievieš konfigurācijas un pārskatīšanas jēdzienu;
- veiksmīgi veikt atcelšanu;
- izmantot āķus dažādiem pasākumiem;
- pievienot papildu lietojumprogrammu pārbaudes un reaģēt uz to rezultātiem.
Turklāt Stūrei ir “baterijas” - milzīgs skaits garšīgu lietu, kuras var iekļaut spraudņu veidā, vienkāršojot jūsu dzīvi. Spraudņus var rakstīt neatkarīgi, tie ir diezgan izolēti un neprasa harmonisku arhitektūru. Ja vēlaties kaut ko ieviest, iesaku to izdarīt kā spraudni un pēc tam, iespējams, iekļaut to augšpusē.
Helm pamatā ir trīs galvenie jēdzieni:
- Diagramma Repo — jūsu manifesta iespējamo parametru apraksts un masīvs.
- config — tas ir, vērtības, kas tiks lietotas (teksts, skaitliskās vērtības utt.).
- Atlaidiet savāc divus augšējos komponentus, un kopā tie pārvēršas par atbrīvošanu. Izlaidumus var veikt versijas, tādējādi panākot organizētu dzīves ciklu: mazs instalēšanas laikā un liels jaunināšanas, pazemināšanas vai atcelšanas laikā.
Stūres arhitektūra
Diagramma konceptuāli attēlo Helmas augsta līmeņa arhitektūru.
Atgādināšu, ka Helms ir kaut kas saistīts ar Kubernetes. Tāpēc mēs nevaram iztikt bez Kubernetes klastera (taisnstūra). Kube-apiserver komponents atrodas galvenajā. Bez Helm mums ir Kubeconfig. Helm atnes vienu mazu bināro, ja tā var nosaukt, Helm CLI utilītu, kas tiek instalēta datorā, portatīvajā datorā, lieldatorā - uz jebko.
Bet ar to nepietiek. Helm ir servera komponents ar nosaukumu Tiller. Tas pārstāv Helmas intereses klasterī; tā ir lietojumprogramma Kubernetes klasterī, tāpat kā jebkura cita.
Nākamais Chart Repo komponents ir repozitorijs ar diagrammām. Ir oficiāla repozitorija, un var būt privāta uzņēmuma vai projekta krātuve.
Mijiedarbība
Apskatīsim, kā mijiedarbojas arhitektūras komponenti, kad vēlamies instalēt lietojumprogrammu, izmantojot Helm.
- Mēs runājam
Helm install, piekļūstiet krātuvei (Chart Repo) un iegūstiet Helm diagrammu.
- Helm utilīta (Helm CLI) mijiedarbojas ar Kubeconfig, lai noskaidrotu, ar kuru kopu sazināties.
- Saņemot šo informāciju, utilīta atsaucas uz Tiller, kas atrodas mūsu klasterī, kā lietojumprogrammu.
- Tiller izsauc Kube-apiserver, lai veiktu darbības Kubernetes, izveidotu dažus objektus (pakalpojumus, podi, kopijas, noslēpumus utt.).
Tālāk mēs sarežģīsim diagrammu, lai redzētu uzbrukuma vektoru, kuram var tikt pakļauta visa Helm arhitektūra kopumā. Un tad mēs centīsimies viņu aizsargāt.
Uzbrukuma vektors
Pirmais iespējamais vājais punkts ir priviliģēta APISākot nolietotājs. Shēmas ietvaros šis ir hakeris, kurš ir ieguvis administratora piekļuvi Helm CLI.
Nepriviliģēts API lietotājs var arī radīt briesmas, ja tas atrodas kaut kur tuvumā. Šādam lietotājam būs atšķirīgs konteksts, piemēram, viņš var tikt fiksēts vienā klastera nosaukumvietā Kubeconfig iestatījumos.
Interesantākais uzbrukuma vektors var būt process, kas atrodas klasterī kaut kur netālu no Tiller un var tam piekļūt. Tas var būt tīmekļa serveris vai mikropakalpojums, kas redz klastera tīkla vidi.
Eksotisks, bet arvien populārāks uzbrukuma variants ietver Chart Repo. Negodīga autora izveidotā diagrammā var būt nedroši resursi, un jūs to pabeigsit, izmantojot ticību. Vai arī tas var aizstāt diagrammu, ko lejupielādējat no oficiālā repozitorija, un, piemēram, izveidot resursu politiku veidā un palielināt tā piekļuvi.
Mēģināsim atvairīt uzbrukumus no visām šīm četrām pusēm un izdomāsim, kur Helm arhitektūrā ir problēmas un kur, iespējams, nav.
Palielināsim diagrammu, pievienosim vairāk elementu, bet saglabāsim visas pamata sastāvdaļas.
Helm CLI sazinās ar Chart Repo, mijiedarbojas ar Kubeconfig, un darbs tiek pārsūtīts uz klasteru uz Tiller komponentu.
Tileru attēlo divi objekti:
- Tiller-deploy svc, kas atklāj noteiktu pakalpojumu;
- Tiller-deploy pod (shēmā vienā eksemplārā vienā replikā), kurā darbojas visa ielāde, kas piekļūst klasterim.
Mijiedarbībai tiek izmantoti dažādi protokoli un shēmas. No drošības viedokļa mūs visvairāk interesē:
- Mehānisms, ar kuru Helm CLI piekļūst diagrammas repo: kāds protokols, vai ir autentifikācija un ko ar to var izdarīt.
- Protokols, ar kuru Helm CLI, izmantojot kubectl, sazinās ar Tiller. Šis ir klasterī instalēts RPC serveris.
- Pati Tiller ir pieejama mikropakalpojumiem, kas atrodas klasterī un mijiedarbojas ar Kube-apiserver.
Apspriedīsim visas šīs jomas secībā.
RBAC
Nav jēgas runāt par Helm vai jebkura cita klastera pakalpojuma drošību, ja vien nav iespējots RBAC.
Šķiet, ka šis nav jaunākais ieteikums, bet esmu pārliecināts, ka daudzi joprojām nav iespējojuši RBAC pat ražošanā, jo tas ir liels satraukums un daudzas lietas ir jākonfigurē. Tomēr es aicinu jūs to darīt.
— RBAC vietņu jurists. Tajā ir milzīgs daudzums interesantu materiālu, kas palīdzēs iestatīt RBAC, parādīs, kāpēc tas ir labs un kā būtībā ar to sadzīvot ražošanā.
Mēģināšu paskaidrot, kā darbojas Tiller un RBAC. Tiller strādā klasterī ar noteiktu pakalpojuma kontu. Parasti, ja RBAC nav konfigurēts, tas būs superlietotājs. Pamatkonfigurācijā Tiller būs administrators. Tāpēc bieži tiek teikts, ka Tiller ir SSH tunelis jūsu klasterim. Faktiski tā ir taisnība, tāpēc iepriekš redzamajā diagrammā noklusējuma pakalpojuma konta vietā varat izmantot atsevišķu pakalpojumu kontu.
Inicializējot Helm un instalējot to serverī pirmo reizi, varat iestatīt pakalpojuma kontu, izmantojot --service-account. Tas ļaus jums izmantot lietotāju ar minimālo nepieciešamo tiesību kopumu. Tiesa, jums būs jāizveido šāda “vītne”: Role un RoleBinding.
Diemžēl Helma to neizdarīs jūsu vietā. Lai izturētu Helm, jums vai jūsu Kubernetes klastera administratoram ir iepriekš jāsagatavo pakalpojuma konta lomu un lomu saišu kopa.
Rodas jautājums – kāda ir atšķirība starp Role un ClusterRole? Atšķirība ir tāda, ka ClusterRole darbojas visās nosaukumvietās, atšķirībā no parastajām lomām un RoleBindings, kas darbojas tikai specializētā nosaukumvietā. Varat konfigurēt politikas visam klasterim un visām nosaukumvietām vai personalizēt katrai nosaukumvietai atsevišķi.
Ir vērts pieminēt, ka RBAC atrisina vēl vienu lielu problēmu. Daudzi cilvēki sūdzas, ka Helm diemžēl nav daudzīre (neatbalsta vairāku īri). Ja vairākas komandas patērē klasteru un izmanto Helm, šajā klasterī principā nav iespējams iestatīt politikas un ierobežot viņu piekļuvi, jo ir noteikts pakalpojuma konts, zem kura darbojas Helm, un tas no tā izveido visus klastera resursus. , kas dažkārt ir ļoti neērti. Tā ir taisnība — tāpat kā pats binārais fails, tāpat kā process, Helmam Tilleram nav daudzdzīvokļu jēdziena.
Tomēr ir lielisks veids, kas ļauj klasterī palaist Tiller vairākas reizes. Ar to nav nekādu problēmu, Tiller var palaist katrā nosaukumvietā. Tādējādi kā kontekstu varat izmantot RBAC, Kubeconfig un ierobežot piekļuvi īpašai Helm.
Tas izskatīsies šādi.
Piemēram, ir divas Kubeconfigs ar kontekstu dažādām komandām (divas nosaukumvietas): X Team izstrādes komandai un administratoru klasterim. Administratora klasterim ir savs plašs Tiller, kas atrodas Kube sistēmas nosaukumvietā, attiecīgi uzlabots pakalpojumu konts. Un atsevišķa nosaukumvieta izstrādes komandai, viņi varēs izvietot savus pakalpojumus īpašā nosaukumvietā.
Šī ir praktiski izmantojama pieeja, jo Tillers nav tik ļoti izsalcis, lai tas būtiski ietekmētu jūsu budžetu. Šis ir viens no ātrajiem risinājumiem.
Jūtieties brīvi konfigurēt Tiller atsevišķi un nodrošināt Kubeconfig ar kontekstu komandai, konkrētam izstrādātājam vai videi: Dev, Staging, Production (apšaubāmi, ka viss būs vienā klasterī, tomēr to var izdarīt).
Turpinot stāstu, pāriesim no RBAC un runāsim par ConfigMaps.
ConfigMaps
Helm kā datu krātuvi izmanto ConfigMaps. Kad mēs runājām par arhitektūru, nekur nebija datu bāzes, kas glabātu informāciju par izlaidumiem, konfigurācijām, atcelšanu utt. Šim nolūkam tiek izmantots ConfigMaps.
Galvenā problēma ar ConfigMaps ir zināma – tās principā ir nedrošas; nav iespējams saglabāt sensitīvus datus. Mēs runājam par visu, kas nedrīkst pārsniegt pakalpojumu, piemēram, paroles. Pašlaik Helm vispiemērotākais veids ir pārslēgties no ConfigMaps uz noslēpumiem.
Tas tiek darīts ļoti vienkārši. Ignorēt Tiller iestatījumu un norādiet, ka krātuve būs slepena. Tad par katru izvietošanu jūs saņemsiet nevis ConfigMap, bet gan noslēpumu.
Jūs varētu iebilst, ka paši noslēpumi ir dīvains jēdziens un ne pārāk droši. Tomēr ir vērts saprast, ka to dara paši Kubernetes izstrādātāji. Sākot ar versiju 1.10, t.i. Jau labu laiku vismaz publiskos mākoņos ir iespējams pieslēgt pareizo krātuvi noslēpumu glabāšanai. Komanda tagad strādā pie veidiem, kā labāk izplatīt piekļuvi noslēpumiem, atsevišķiem blokiem vai citām entītijām.
Storage Helm ir labāk nodot noslēpumiem, un tie, savukārt, tiek nodrošināti centralizēti.
Protams, ka paliks datu uzglabāšanas ierobežojums 1 MB. Helm šeit izmanto etcd kā ConfigMaps izplatīto krātuvi. Un tur viņi uzskatīja, ka tas ir piemērots datu gabals replikācijai utt. Reddit par to ir interesanta diskusija, iesaku nedēļas nogalei atrast šo smieklīgo lasāmvielu vai izlasīt izrakstu .
Diagrammu repo
Diagrammas ir sociāli visneaizsargātākās un var kļūt par “cilvēka vidū” avotu, īpaši, ja izmantojat akciju risinājumu. Pirmkārt, mēs runājam par krātuvēm, kuras tiek pakļautas, izmantojot HTTP.
Jums noteikti ir jāatklāj Helm Repo, izmantojot HTTPS — tas ir labākais risinājums un ir lēts.
Ņemiet diagrammas parakstīšanas mehānisms. Tehnoloģija ir vienkārša. Tas ir tas pats, ko izmantojat GitHub, parastā PGP mašīnā ar publiskām un privātajām atslēgām. Iestatiet un pārliecinieties, ka jums ir nepieciešamās atslēgas un viss parakstās, ka šī patiešām ir jūsu diagramma.
Bez tam, Helm klients atbalsta TLS (nevis servera puses HTTP nozīmē, bet savstarpējā TLS). Lai sazinātos, varat izmantot servera un klienta atslēgas. Godīgi sakot, es šādu mehānismu neizmantoju, jo man nepatīk savstarpējie sertifikāti. Būtībā, - galvenais rīks Helm Repo iestatīšanai Helm 2 - atbalsta arī pamata autentifikāciju. Varat izmantot pamata autentifikāciju, ja tas ir ērtāk un klusāk.
Ir arī spraudnis , kas ļauj mitināt diagrammu repo pakalpojumā Google Cloud Storage. Tas ir diezgan ērti, darbojas lieliski un ir diezgan droši, jo visi aprakstītie mehānismi tiek pārstrādāti.
Ja iespējosiet HTTPS vai TLS, izmantojiet mTLS un iespējosiet pamata autentifikāciju, lai vēl vairāk samazinātu riskus, jūs iegūsit drošu saziņas kanālu ar Helm CLI un Chart Repo.
grRPC API
Ļoti svarīgs ir nākamais solis - nodrošināt Tiller, kas atrodas klasterī un ir, no vienas puses, serveris, no otras puses, tas pats piekļūst citiem komponentiem un mēģina izlikties par kādu.
Kā jau teicu, Tiller ir pakalpojums, kas atklāj gRPC, Helm klients tam nonāk caur gRPC. Pēc noklusējuma, protams, TLS ir atspējots. Kāpēc tas tika darīts, ir diskutabls jautājums, man šķiet, ka sākumā ir jāvienkāršo iestatīšana.
Ražošanai un pat iestudēšanai iesaku iespējot TLS gRPC.
Manuprāt, atšķirībā no mTLS diagrammām, tas šeit ir piemērots un tiek darīts ļoti vienkārši - ģenerējiet PQI infrastruktūru, izveidojiet sertifikātu, palaidiet Tiller, pārsūtiet sertifikātu inicializācijas laikā. Pēc tam jūs varat izpildīt visas Helm komandas, parādot sevi ar ģenerēto sertifikātu un privāto atslēgu.
Tādā veidā jūs pasargāsities no visiem pieprasījumiem Tiller no ārpuses.
Tātad, mēs esam nodrošinājuši savienojuma kanālu ar Tiller, mēs jau esam apsprieduši RBAC un pielāgojuši Kubernetes apiservera tiesības, samazinot domēnu, ar kuru tas var mijiedarboties.
Aizsargāta stūre
Apskatīsim galīgo diagrammu. Tā ir tā pati arhitektūra ar tām pašām bultām.
Tagad visus savienojumus var droši zīmēt zaļā krāsā:
- Chart Repo mēs izmantojam TLS vai mTLS un pamata autentifikāciju;
- mTLS for Tiller, un tas ir pakļauts kā gRPC pakalpojums ar TLS, mēs izmantojam sertifikātus;
- klasteris izmanto īpašu pakalpojumu kontu ar Role un RoleBinding.
Mēs esam ievērojami nodrošinājuši klasteru, bet kāds gudrs teica:
"Var būt tikai viens absolūti drošs risinājums - izslēgts dators, kas atrodas betona kastē un ko apsargā karavīri."
Ir dažādi veidi, kā manipulēt ar datiem un atrast jaunus uzbrukuma vektorus. Tomēr esmu pārliecināts, ka šie ieteikumi sasniegs nozares drošības pamatstandartu.
prēmija
Šī daļa nav tieši saistīta ar drošību, bet arī noderēs. Es jums parādīšu dažas interesantas lietas, par kurām daži zina. Piemēram, kā meklēt diagrammas - oficiālas un neoficiālas.
Repozitorijā Tagad ir aptuveni 300 diagrammu un divas straumes: stabilā un inkubatora. Ikviens, kurš sniedz ieguldījumu, lieliski zina, cik grūti ir nokļūt no inkubatora uz stalli un cik viegli ir izlidot no staļļa. Tomēr šis nav labākais rīks, lai meklētu diagrammas Prometheus un citam, kas jums patīk, viena vienkārša iemesla dēļ - tas nav portāls, kurā var ērti meklēt pakotnes.
Bet ir pakalpojums , kas padara diagrammu atrašanu daudz ērtāku. Vissvarīgākais ir tas, ka ir pieejams daudz vairāk ārējo repozitoriju un gandrīz 800 piekariņu. Turklāt varat pievienot savu repozitoriju, ja kāda iemesla dēļ nevēlaties sūtīt diagrammas uz stabilu.
Izmēģiniet hub.helm.sh un izstrādāsim to kopā. Šis pakalpojums ir Helm projekta ietvaros, un jūs pat varat dot ieguldījumu tā lietotāja saskarnē, ja esat priekšgala izstrādātājs un vēlaties tikai uzlabot izskatu.
Es arī vēlos pievērst jūsu uzmanību Open Service Broker API integrācija. Tas izklausās apgrūtinoši un neskaidri, taču tas atrisina problēmas, ar kurām saskaras ikviens. Ļaujiet man paskaidrot ar vienkāršu piemēru.
Ir Kubernetes klasteris, kurā mēs vēlamies palaist klasisko lietojumprogrammu - WordPress. Parasti pilnīgai funkcionalitātei ir nepieciešama datubāze. Ir daudz dažādu risinājumu, piemēram, varat palaist savu statusfull pakalpojumu. Tas nav īpaši ērti, bet daudzi cilvēki to dara.
Citi, piemēram, mēs, Chainstack, saviem serveriem izmanto pārvaldītas datu bāzes, piemēram, MySQL vai PostgreSQL. Tāpēc mūsu datu bāzes atrodas kaut kur mākonī.
Taču rodas problēma: mums ir jāsavieno mūsu pakalpojums ar datu bāzi, jāizveido datu bāzes atveide, jāpārsūta akreditācijas dati un kaut kā jāpārvalda. To visu parasti manuāli veic sistēmas administrators vai izstrādātājs. Un nav problēmu, ja pieteikumu ir maz. Kad to ir daudz, vajag kombainu. Ir tāds harvesteris - tas ir Service Broker. Tas ļauj izmantot īpašu spraudni publiskam mākoņu klasterim un pasūtīt resursus no pakalpojumu sniedzēja, izmantojot Broker, it kā tas būtu API. Lai to izdarītu, varat izmantot vietējos Kubernetes rīkus.
Tas ir ļoti vienkārši. Varat vaicāt, piemēram, Managed MySQL pakalpojumā Azure ar bāzes līmeni (to var konfigurēt). Izmantojot Azure API, datu bāze tiks izveidota un sagatavota lietošanai. Jums tas nav jāiejaucas, par to atbild spraudnis. Piemēram, OSBA (Azure spraudnis) atgriezīs pakalpojuma akreditācijas datus un nodos tos Helm. Jūs varēsiet lietot WordPress ar mākoņa MySQL, vispār nenodarboties ar pārvaldītām datu bāzēm un neuztraukties par iekšējiem statusa pakalpojumiem.
Var teikt, ka Helm darbojas kā līme, kas, no vienas puses, ļauj izvietot pakalpojumus un, no otras puses, patērē mākoņpakalpojumu sniedzēju resursus.
Varat uzrakstīt savu spraudni un izmantot visu šo stāstu uz vietas. Tad jums vienkārši būs savs spraudnis korporatīvajam mākoņa pakalpojumu sniedzējam. Es iesaku izmēģināt šo pieeju, it īpaši, ja jums ir liels apjoms un vēlaties ātri izvietot izstrādātāju, iestudējumu vai visu objekta infrastruktūru. Tas atvieglos jūsu darbību vai DevOps darbību.
Vēl viens atradums, ko jau minēju, ir spraudnis helm-gcs, kas ļauj izmantot Google spaiņus (objektu krātuvi), lai saglabātu Helm diagrammas.
Lai sāktu to lietot, nepieciešamas tikai četras komandas:
- instalējiet spraudni;
- uzsākt to;
- iestatiet ceļu uz spaini, kas atrodas gcp;
- publicēt diagrammas standarta veidā.
Skaistums ir tāds, ka autorizācijai tiks izmantota vietējā gcp metode. Varat izmantot pakalpojuma kontu, izstrādātāja kontu, ko vien vēlaties. Tas ir ļoti ērti un neko nemaksā. Ja jūs, tāpat kā es, popularizējat opsless filozofiju, tad tas būs ļoti ērti, īpaši mazām komandām.
Alternatīvas
Helm nav vienīgais pakalpojumu pārvaldības risinājums. Par to ir daudz jautājumu, iespējams, tāpēc tik ātri parādījās trešā versija. Protams, ir alternatīvas.
Tie var būt specializēti risinājumi, piemēram, Ksonnet vai Metaparticle. Jūs varat izmantot savus klasiskos infrastruktūras pārvaldības rīkus (Ansible, Terraform, Chef utt.) tiem pašiem mērķiem, par kuriem es runāju.
Beidzot ir risinājums , kuras popularitāte pieaug.
Operator Framework ir labākā Helm alternatīva, kas jāapsver.
Tā dzimtene ir CNCF un Kubernetes, bet barjera ienākšanai ir daudz augstāka, vairāk jāprogrammē un mazāk jāapraksta manifesti.
Ir dažādi papildinājumi, piemēram, Draft, Scaffold. Tie ievērojami atvieglo dzīvi, piemēram, tie vienkāršo Helm nosūtīšanas un palaišanas ciklu, lai izstrādātāji varētu izvietot testa vidi. Es tos sauktu par pilnvarotājiem.
Šeit ir vizuāla diagramma, kur viss atrodas.
Uz x ass ir jūsu personīgās kontroles līmenis pār notiekošo, uz y ass ir Kubernetes dzimtenes līmenis. Helm versija 2 iekrīt kaut kur pa vidu. 3. versijā ne milzīgi, taču ir uzlabota gan kontrole, gan dzimtenes līmenis. Risinājumi Ksonnet līmenī joprojām ir zemāki pat par Helm 2. Tomēr tos ir vērts apskatīt, lai uzzinātu, kas vēl ir šajā pasaulē. Protams, jūsu konfigurācijas pārvaldnieks būs jūsu kontrolē, taču tas absolūti nav Kubernetes vietējais.
Operator Framework ir absolūti Kubernetes vietējais un ļauj to pārvaldīt daudz elegantāk un skrupulozi (bet atcerieties par sākuma līmeni). Tas drīzāk ir piemērots specializētai lietojumprogrammai un tās pārvaldības izveidei, nevis masveida kombainam daudzu lietojumprogrammu iepakošanai, izmantojot Helm.
Paplašinātāji vienkārši nedaudz uzlabo vadību, papildina darbplūsmu vai samazina CI/CD cauruļvadu stūrus.
Helmas nākotne
Labās ziņas ir tādas, ka tuvojas Helm 3. Helm 3.0.0-alpha.2 alfa versija jau ir izlaista, varat to izmēģināt. Tas ir diezgan stabils, taču funkcionalitāte joprojām ir ierobežota.
Kāpēc jums ir nepieciešams Helm 3? Pirmkārt, šis ir stāsts par Tillera pazušana, kā sastāvdaļa. Tas, kā jau saprotat, ir milzīgs solis uz priekšu, jo no arhitektūras drošības viedokļa viss ir vienkāršots.
Kad tika izveidots Helm 2, kas bija aptuveni Kubernetes 1.8 vai pat agrāk, daudzi jēdzieni bija nenobrieduši. Piemēram, CRD koncepcija šobrīd tiek aktīvi ieviesta, un Helms to darīs izmantot CRDkonstrukciju uzglabāšanai. Būs iespējams izmantot tikai klientu, nevis uzturēt servera daļu. Attiecīgi izmantojiet vietējās Kubernetes komandas, lai strādātu ar struktūrām un resursiem. Tas ir milzīgs solis uz priekšu.
Parādīsies atbalsts vietējām OCI krātuvēm (Atvērtā konteinera iniciatīva). Šī ir milzīga iniciatīva, un Helmu galvenokārt interesē, lai publicētu tās diagrammas. Tas nonāk pie tā, ka, piemēram, Docker Hub atbalsta daudzus OCI standartus. Es nedomāju, bet, iespējams, klasiskie Docker repozitoriju nodrošinātāji sāks sniegt jums iespēju mitināt jūsu Helm diagrammas.
Pretrunīgi vērtētais stāsts man ir Lua atbalsts, kā veidņu dzinējs skriptu rakstīšanai. Es neesmu liels Lua cienītājs, taču tā būtu pilnīgi neobligāta funkcija. Es to pārbaudīju 3 reizes - izmantot Lua nebūs nepieciešams. Tāpēc tie, kas vēlas izmantot Lua, tie, kuriem patīk Go, pievienojieties mūsu milzīgajai nometnei un šim nolūkam izmantojiet go-tmpl.
Visbeidzot, tas, kas man noteikti pietrūka, bija shēmas rašanās un datu tipu validācija. Vairs nebūs problēmu ar int vai virkni, nevajadzēs ietīt nulli dubultpēdiņās. Tiks parādīta JSONS shēma, kas ļaus jums to precīzi aprakstīt vērtībām.
Tiks stipri pārstrādāts uz notikumu orientēts modelis. Tas jau ir konceptuāli aprakstīts. Paskatieties uz Helm 3 filiāli, un jūs redzēsiet, cik daudz notikumu un āķu un citu lietu ir pievienots, kas ievērojami vienkāršos un, no otras puses, pievienos kontroli pār izvietošanas procesiem un reakcijām uz tiem.
Helm 3 būs vienkāršāka, drošāka un jautrāka nevis tāpēc, ka mums nepatīk Helm 2, bet gan tāpēc, ka Kubernetes kļūst arvien progresīvāks. Attiecīgi Helms var izmantot Kubernetes izstrādnes un tajā izveidot izcilus Kubernetes menedžerus.
Vēl viena laba ziņa ir tā Aleksandrs Hajorovs jums pateiks, Atgādināsim, ka konference par izstrādes, testēšanas un ekspluatācijas procesu integrāciju notiks Maskavā 30. septembris un 1. oktobris. Vēl vari to izdarīt līdz 20. augustam un pastāstiet mums par savu pieredzi ar risinājumu DevOps pieejas uzdevumi.
Sekojiet konferences kontrolpunktiem un jaunumiem plkst и .
Avots: www.habr.com