Noat. transl.: 16 maaie fan dit jier markearret in wichtige mylpeal yn 'e ûntwikkeling fan' e pakketbehearder foar Kubernetes - Helm. Op dizze dei waard de earste alfa-release fan 'e takomstige grutte ferzje fan it projekt - 3.0 - presintearre. De frijlitting dêrfan sil wichtige en langferwachte feroaringen bringe oan Helm, wêrfoar in protte yn 'e Kubernetes-mienskip hege hope hawwe. Wy sels binne ien fan dizze, om't wy Helm aktyf brûke foar applikaasje-ynset: wy hawwe it yntegreare yn ús ark foar ymplemintaasje fan CI / CD en fan tiid ta tiid wy meitsje ús bydrage oan de ûntwikkeling fan streamop. Dizze oersetting kombinearret 7 notysjes fan it offisjele Helm-blog, dy't wijd binne oan 'e earste alfa-útjefte fan Helm 3 en prate oer de skiednis fan it projekt en de haadfunksjes fan Helm 3. Harren skriuwer is Matt "bacongobbler" Fisher, in Microsoft-meiwurker en ien fan 'e wichtichste ûnderhâlders fan Helm.
Op 15 oktober 2015 waard it projekt no bekend as Helm berne. Krekt in jier nei de oprjochting kaam de Helm-mienskip by Kubernetes, wylst se aktyf wurke oan Helm 2. Yn juny 2018, Helm as in ûntwikkeljend (incubating) projekt. Snel foarút nei it hjoeddeiske, en de earste alfa-release fan 'e nije Helm 3 is ûnderweis. (dizze útjefte medio mei - ca. oerset.).
Yn dit artikel sil ik prate oer wêr't it allegear begon, hoe't wy kamen wêr't wy hjoed binne, yntrodusearje guon fan 'e unike funksjes beskikber yn' e earste alfa-release fan Helm 3, en útlizze hoe't wy fan plan binne fierder te ûntwikkeljen.
Gearfetting:
- de skiednis fan 'e skepping fan Helm;
- in teare ôfskied fan Tiller;
- chart repositories;
- release behear;
- feroarings yn diagramôfhinklikens;
- bibleteek charts;
- wat komt hjirnei?
De skiednis fan Helm
Geboorte
Helm 1 begon as in Open Source-projekt makke troch Deis. Wy wiene in lytse startup Microsoft yn maitiid 2017. Us oare Open Source-projekt, ek wol Deis neamd, hie in ark deisctl, dy't (ûnder oare) brûkt waard om it Deis-platfoarm yn te ynstallearjen en te betsjinjen . Yn dy tiid wie Fleet ien fan 'e earste kontenerorkestraasjeplatfoarms.
Mids 2015 hawwe wy besletten om koers te feroarjen en ferhuze Deis (destiids omneamd ta Deis Workflow) fan Fleet nei Kubernetes. Ien fan 'e earsten dy't opnij ûntwurpen wie it ynstallaasjeark. deisctl. Wy brûkten it om Deis Workflow te ynstallearjen en te behearjen yn it Fleet-kluster.
Helm 1 is makke yn it byld fan ferneamde pakketbehearders lykas Homebrew, apt en yum. It haaddoel wie om taken te ferienfâldigjen lykas ferpakking en ynstallaasje fan applikaasjes op Kubernetes. Helm waard offisjeel yntrodusearre yn 2015 op 'e KubeCon-konferinsje yn San Francisco.
Us earste besykjen mei Helm wurke, mar it wie net sûnder wat serieuze beheiningen. Hy naam in set fan Kubernetes-manifesten, smaak mei generators as ynliedende YAML-blokken (front-saak)*, en laden de resultaten yn Kubernetes.
* Noat. transl.: Fan 'e earste ferzje fan Helm waard YAML-syntaksis keazen om Kubernetes-boarnen te beskriuwen, en Jinja-sjabloanen en Python-skripts waarden stipe by it skriuwen fan konfiguraasjes. Wy skreaunen mear oer dit en de struktuer fan 'e earste ferzje fan Helm yn it algemien yn it haadstik "In koarte skiednis fan Helm" .
Bygelyks, om in fjild yn in YAML-bestân te ferfangen, moasten jo de folgjende konstruksje tafoegje oan it manifest:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlIt is geweldich dat sjabloanmotoren hjoeddedei besteane, is it net?
Om in protte redenen hat dizze iere Kubernetes-ynstallearder in hurdkodearre list mei manifeste bestannen nedich en allinich in lytse, fêste folchoarder fan eveneminten útfierd. It wie sa lestich te brûken dat it Deis Workflow R&D-team in hurde tiid hie doe't se besochten har produkt oer te bringen nei dit platfoarm - lykwols, de siedden fan it idee wiene al siedde. Us earste poging wie in geweldige learmooglikheid: wy realisearre dat wy wier hertstochtlik wiene oer it meitsjen fan pragmatyske ark dy't deistige problemen foar ús brûkers oplosse.
Op grûn fan 'e ûnderfining fan flaters út it ferline begon wy Helm 2 te ûntwikkeljen.
Helm meitsje 2
Oan 'e ein fan 2015 naam it Google-team kontakt mei ús op. Se wurken oan in ferlykber ark foar Kubernetes. Deployment Manager foar Kubernetes wie in haven fan in besteande ark dat waard brûkt foar Google Cloud Platform. "Soene wy wolle," fregen se, "in pear dagen besteegje oan it besprekken fan oerienkomsten en ferskillen?"
Yn jannewaris 2016 moete de Helm en Deployment Manager teams yn Seattle om ideeën út te wikseljen. De ûnderhannelings einigen mei in ambisjeus plan: beide projekten kombinearje om Helm 2 te meitsjen. Mei Deis en Google binne de jonges fan (no diel fan Bitnami - sawat oerset.), en wy begon te wurkjen oan Helm 2.
Wy woene it gebrûksgemak fan Helm behâlde, mar foegje it folgjende ta:
- diagramsjabloanen foar oanpassing;
- intra-cluster behear foar teams;
- wrâldklasse chart repository;
- stabile pakketformaat mei hantekeningopsje;
- in sterke ynset foar semantyske ferzjes en behâld fan efterkompatibiliteit tusken ferzjes.
Om dizze doelen te berikken is in twadde elemint tafoege oan it Helm-ekosysteem. Dit intra-cluster komponint waard neamd Tiller en wie ferantwurdlik foar it ynstallearjen fan Helm charts en behear se.
Sûnt de frijlitting fan Helm 2 yn 2016 hat Kubernetes ferskate grutte ynnovaasjes tafoege. Rolbasearre tagongskontrôle tafoege (), dy't úteinlik Attribute-Based Access Control (ABAC) ferfong. Nije boarne typen waarden yntrodusearre (Deployments wie noch yn beta op it stuit). Oanpaste boarne-definysjes (oarspronklik neamd Third Party Resources of TPR's) waarden útfûn. En it wichtichste is in set fan bêste praktiken ûntstien.
Te midden fan al dizze feroarings bleau Helm Kubernetes-brûkers trou tsjinje. Nei trije jier en in protte nije tafoegings wie it dúdlik dat it tiid wie om wichtige feroarings oan 'e codebase te meitsjen om te soargjen dat Helm koe trochgean mei de groeiende behoeften fan in evoluearjend ekosysteem te foldwaan.
In teare ôfskied fan Tiller
Tidens de ûntwikkeling fan Helm 2 hawwe wy Tiller yntrodusearre as ûnderdiel fan ús yntegraasje mei Google's Deployment Manager. Tiller spile in wichtige rol foar teams dy't wurkje binnen in mienskiplik kluster: it liet ferskate spesjalisten dy't de ynfrastruktuer operearje om mei deselde set releases te ynteraksje.
Sûnt rol-basearre tagong kontrôle (RBAC) waard ynskeakele standert yn Kubernetes 1.6, wurkjen mei Tiller yn produksje waard dreger. Fanwegen it grutte oantal mooglike befeiligingsbelied hat ús posysje west om standert in permissive konfiguraasje oan te bieden. Dit stelde newbies om te eksperimintearjen mei Helm en Kubernetes sûnder earst yn feiligensynstellingen te dûken. Spitigernôch koe dizze tastimmingskonfiguraasje de brûker begiftigje mei in te breed oanbod fan tagongsrjochten dy't se net nedich hawwe. DevOps- en SRE-yngenieurs moasten ekstra operasjonele stappen leare by it ynstallearjen fan Tiller yn in kluster mei meardere hierders.
Troch te learen hoe't de mienskip Helm brûkte yn spesifike situaasjes, realisearre wy dat Tiller syn release management systeem net hoege te fertrouwe op in intra-cluster komponint te behâlden steaten of fungearje as in sintrale hub foar release ynformaasje. Ynstee dêrfan koene wy gewoan ynformaasje ûntfange fan 'e Kubernetes API-tsjinner, in diagram generearje op' e kliïntside, en in rekord fan 'e ynstallaasje opslaan yn Kubernetes.
De haadtaak fan Tiller koe sûnder Tiller útfierd wurde, dus ien fan ús earste besluten oangeande Helm 3 wie om Tiller folslein te ferlitten.
Mei it fuortgean fan Tiller is it befeiligingsmodel fan Helm yngripend ferienfâldige. Helm 3 stipet no alle moderne metoaden foar feiligens, identiteit en autorisaasje fan hjoeddeistige Kubernetes. Helm tagongsrjochten wurde bepaald mei help . Klusterbehearders kinne brûkersrjochten beheine ta elk nivo fan granulariteit. Releases wurde noch bewarre binnen it kluster, en de rest fan Helm's funksjonaliteit bliuwt yntakt.
Chart repositories
Op in heech nivo is in kaartrepository in plak dêr't charts kinne wurde opslein en dield. De Helm-kliïnt pakket en stjoert de charts nei it repository. Simply set, in charts repository is in primitive HTTP-tsjinner mei in index.yaml-bestân en wat ferpakte charts.
Wylst d'r guon foardielen binne foar de Charts Repository API dy't oan de measte basale opslacheasken foldocht, binne d'r ek in pear neidielen:
- Chartrepositories binne net kompatibel mei de measte feiligensimplementaasjes dy't nedich binne yn in produksjeomjouwing. In standert API hawwe foar autentikaasje en autorisaasje is ekstreem wichtich yn produksjescenario's.
- De ark foar herkomst fan 'e kaart fan Helm, brûkt om de yntegriteit en herkomst fan in kaart te ûndertekenjen, te ferifiearjen, binne in opsjoneel diel fan it publikaasjeproses fan' e Chart.
- Yn senario's foar meardere brûkers kin itselde diagram troch in oare brûker uploade wurde, en ferdûbelje de hoemannichte romte nedich om deselde ynhâld op te slaan. Tûkere repositories binne ûntwikkele om dit probleem op te lossen, mar se binne gjin diel fan 'e formele spesifikaasje.
- It brûken fan in inkele yndeksbestân foar it sykjen, opslaan fan metadata en it opheljen fan charts hat it lestich makke om feilige ymplemintaasjes foar meardere brûkers te ûntwikkeljen.
It projekt (ek wol Docker Registry v2 bekend) is de opfolger fan Docker Registry en fungearret yn essinsje as in set ark foar ferpakking, ferstjoeren, opslaan en leverjen fan Docker-ôfbyldings. In protte grutte wolktsjinsten biede Distribúsje-basearre produkten. Mei tank oan dizze ferhege oandacht hat it Distribúsjeprojekt profitearre fan jierren fan ferbetteringen, bêste praktiken foar feiligens, en fjildtesten dy't it ien fan 'e meast suksesfolle ûnbesjoene helden fan' e Open Source-wrâld hawwe makke.
Mar wisten jo dat it Distribution Project is ûntworpen om elke foarm fan ynhâld te fersprieden, net allinich kontenerôfbyldings?
Mei tank oan de ynspannings (of OCI), Helm charts kinne wurde pleatst op alle distribúsje eksimplaar. Foar no is dit proses eksperiminteel. Oanmelde-stipe en oare funksjes dy't nedich binne foar in folsleine Helm 3 binne in wurk oan 'e gong, mar wy binne optein om te learen fan' e ûntdekkingen dy't de OCI- en Distribution-teams yn 'e rin fan' e jierren hawwe makke. En troch har mentorskip en begelieding learje wy hoe't it is om in heechbeskikbere tsjinst op skaal te betsjinjen.
In mear detaillearre beskriuwing fan guon oankommende feroarings oan de Helm chart repositories is beskikber .
Release behear
Yn Helm 3 wurdt de tapassing fan tapassing binnen it kluster folge troch in pear objekten:
- release foarwerp - fertsjintwurdiget in applikaasje eksimplaar;
- release ferzje geheim - fertsjintwurdiget de winske tastân fan 'e applikaasje op in spesifyk punt yn' e tiid (bygelyks de frijlitting fan in nije ferzje).
Challenge helm install makket in release foarwerp en release ferzje geheim. Belje helm upgrade fereasket in release-objekt (dat kin feroarje) en makket in nije release-ferzjegeheim mei de nije wearden en in taret manifest.
Release foarwerp befettet ynformaasje oer de release, dêr't release is in spesifike ynstallaasje fan in neamd diagram en wearden. Dit objekt beskriuwt de top-nivo metadata oer de frijlitting. It release-objekt bliuwt troch de heule libbenssyklus fan 'e applikaasje en fungearret as de eigner fan alle geheimen fan releaseferzje, lykas alle objekten dy't direkt wurde makke troch de Helm-diagram.
Release ferzje geheim assosjearret in release mei in rige fan ferzjes (ynstallaasje, updates, rollbacks, wiskjen).
Yn Helm 2 wiene ferzjes ekstreem konsekwint. Belje helm install makke v1, de folgjende update (upgrade) - v2, ensfh. Geheim fan frijlitting en frijlitting ferzje binne ynstoart yn ien objekt bekend as revyzje. Ferzjes waarden opslein yn deselde nammeromte as Tiller, wat betsjutte dat elke útjefte "globaal" wie wat nammeromte oanbelanget; dêrtroch koe mar ien eksimplaar fan de namme brûkt wurde.
Yn Helm 3 is elke release assosjearre mei ien of mear releaseferzjegeheimen. It release-objekt beskriuwt altyd de aktuele release ynset nei Kubernetes. Elk geheim fan releaseferzje beskriuwt mar ien ferzje fan dy release. In upgrade, bygelyks, sil in nije release-ferzje-geheim meitsje en dan it release-objekt feroarje om nei dy nije ferzje te wizen. Yn gefal fan weromdraaien kinne jo de geheimen fan eardere ferzjeferzje brûke om de frijlitting werom te rôljen nei de foarige steat.
Neidat Tiller is ferlitten, bewarret Helm 3 release data yn deselde nammeromte as de release. Dizze wiziging lit jo in diagram mei deselde releasenamme yn in oare nammeromte ynstallearje, en de gegevens wurde bewarre tusken klusterupdates / opnij yn etcd. Jo kinne bygelyks WordPress ynstalleare yn 'e "foo" nammeromte en dan yn 'e "bar" nammeromte, en beide releases kinne wurde neamd "wordpress".
Feroarings oan grafyk ôfhinklikens
Charts ynpakt (brûkende helm package) foar gebrûk mei Helm 2 kin ynstalleare wurde mei Helm 3, lykwols is de workflow fan 'e diagramûntwikkeling folslein oerwurke, sadat guon wizigingen moatte wurde makke om troch te gean mei de ûntwikkeling fan' e kaart mei Helm 3. Benammen it bestjoeringssysteem foar kaartôfhinklikens is feroare.
It ôfhinklikheidsbehearsysteem fan 'e kaart is ferpleatst fan requirements.yaml и requirements.lock op Chart.yaml и Chart.lock. Dit betsjut dat de diagrammen dy't it kommando brûkten helm dependency, fereaskje wat opset om te wurkjen yn Helm 3.
Litte wy nei in foarbyld sjen. Litte wy in ôfhinklikens tafoegje oan it diagram yn Helm 2 en sjoch wat feroaret by it ferpleatsen nei Helm 3.
In Helm 2 requirements.yaml seach der sa út:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Yn Helm 3 sil deselde ôfhinklikens wjerspegele wurde yn jo Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Charts wurde noch ynladen en pleatst yn 'e map charts/, dus subcharts (subgrafyk), lizzend yn 'e katalogus charts/, sil trochgean te wurkjen sûnder feroarings.
Yntroduksje fan Library Charts
Helm 3 stipet in klasse fan charts neamd bibleteek charts (bibleteekkaart). Dit diagram wurdt brûkt troch oare charts, mar makket gjin release artefakten op syn eigen. Bibleteekkaartsjabloanen kinne allinich eleminten ferklearje define. Oare ynhâld wurdt gewoan negearre. Hjirmei kinne brûkers koadefragmenten opnij brûke en diele dy't brûkt wurde kinne oer meardere diagrammen, sadat duplikaasje foarkomt en it prinsipe folgje .
Biblioteekkaarten wurde ferklearre yn 'e seksje dependencies yn triem Chart.yaml. It ynstallearjen en behearen fan se is net oars as oare charts.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioWy binne optein oer de gebrûksgefallen dy't dizze komponint sil iepenje foar kaartûntwikkelders, lykas de bêste praktiken dy't kinne neikomme út biblioteekkaarten.
Wat is folgjende?
Helm 3.0.0-alpha.1 is de stifting wêrop wy begjinne mei it bouwen fan in nije ferzje fan Helm. Yn it artikel beskreau ik wat nijsgjirrige skaaimerken fan Helm 3. In protte fan harren binne noch yn 'e iere stadia fan ûntwikkeling en dit is normaal; It punt fan in alfa-release is om it idee te testen, feedback te sammeljen fan iere brûkers, en ús oannames te befêstigjen.
Sa gau as de alpha ferzje wurdt útbrocht (ûnthâld dat dit is - ca. oerset.), sille wy begjinne mei it akseptearjen fan patches foar Helm 3 fan 'e mienskip. Jo moatte in sterke stifting meitsje wêrmei't nije funksjonaliteit kin wurde ûntwikkele en oannommen, en foar brûkers om har belutsen te fielen by it proses troch kaartsjes te iepenjen en reparaasjes te meitsjen.
Ik haw besocht guon fan 'e grutte ferbetteringen te markearjen dy't komme nei Helm 3, mar dizze list is lang net útputtend. De folsleine roadmap foar Helm 3 omfettet funksjes lykas ferbettere updatestrategyen, djipper yntegraasje mei OCI-registraasjes, en it brûken fan JSON-skema's om kaartwearden te validearjen. Wy binne ek fan plan om de koadebase op te romjen en dielen derfan te aktualisearjen dy't de ôfrûne trije jier binne ferwaarleazge.
As jo fiele dat wy wat hawwe mist, hearre wy jo gedachten graach!
Doch mei oan de diskusje op ús :
-
#helm-usersfoar fragen en ienfâldige kommunikaasje mei de mienskip; -
#helm-devte besprekken pull fersiken, koade en bugs.
Jo kinne ek petearje yn ús wyklikse oproppen foar iepenbiere ûntwikkelders op tongersdei om 19:30 MSK. Gearkomsten binne wijd oan it besprekken fan problemen dêr't wichtige ûntwikkelders en de mienskip oan wurkje, lykas ûnderwerpen fan diskusje foar de wike. Elkenien kin meidwaan en meidwaan oan de gearkomste. Link beskikber yn Slack-kanaal #helm-dev.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «";
- «".
Boarne: www.habr.com