Mi nomiĝas Dmitry Sugrobov, mi estas programisto ĉe Leroy Merlin. En ĉi tiu artikolo mi rakontos al vi kial Helm estas bezonata, kiel ĝi simpligas labori kun Kubernetes, kio ŝanĝiĝis en la tria versio, kaj kiel uzi ĝin por ĝisdatigi aplikojn en produktado sen malfunkcio.
Ĉi tio estas resumo bazita sur parolado en konferenco by - se vi ne volas legi, rigardu la videon.
Kial ni uzas Kubernetes en produktado
Leroy Merlin estas gvidanto en la DIY podetala merkato en Rusio kaj Eŭropo. Nia firmao havas pli ol cent programistojn, 33 internajn dungitojn kaj grandegan nombron da homoj vizitantaj hiperbazarojn kaj la retejon. Por feliĉigi ilin ĉiujn, ni decidis sekvi industriajn normajn alirojn. Disvolvu novajn aplikojn uzante mikroservan arkitekturon; uzu ujojn por izoli mediojn kaj certigi taŭgan liveron; kaj uzu Kubernetes por instrumentado. La prezo de uzado de orkestrantoj rapide fariĝas pli malmultekosta: la nombro da inĝenieroj kapablaj pri la teknologio kreskas sur la merkato, kaj provizantoj aperas proponante Kubernetes kiel servon.
Ĉio, kion Kubernetes faras, kompreneble, povas esti farita alimaniere, ekzemple, kovrante iujn Jenkins kaj docker-komponi per skriptoj, sed kial kompliki la vivon se ekzistas preta kaj fidinda solvo? Tial ni venis al Kubernetes kaj jam de unu jaro uzas ĝin en produktado. Nuntempe ni havas dudek kvar Kubernetes-aretojn, la plej malnova el kiuj estas pli ol unujara, kun ĉirkaŭ ducent balgoj.
La malbeno de grandaj YAML-dosieroj en Kubernetes
Por lanĉi mikroservon en Kubernetes, ni kreos almenaŭ kvin YAML-dosierojn: por Deployment, Service, Ingress, ConfigMap, Secrets - kaj sendos ilin al la areto. Por la sekva aplikaĵo ni skribos la saman pakon de skafaldaro, kun la tria ni skribos alian, ktp. Se ni multobligas la nombron da dokumentoj per la nombro da medioj, ni jam ricevos centojn da dosieroj, kaj ĉi tio ankoraŭ ne konsideras dinamikajn mediojn.
Adam Reese, kerna prizorganto de Helm, lanĉis la koncepton de"", kiu aspektas jene:
- Kopiu YAML - kopiu YAML-dosieron.
- Paste YAML - algluu ĝin.
- Fix Indents - ripari indentojn.
- Ripeti - ripeti denove.
La opcio funkcias, sed vi devas kopii la YAML-dosierojn multfoje. Por ŝanĝi ĉi tiun ciklon, Helm estis inventita.
Kio estas Helm
Unue, Helm - pakaĵmanaĝero, kiu helpas vin trovi kaj instali la programojn, kiujn vi bezonas. Por instali, ekzemple, MongoDB, vi ne bezonas iri al la oficiala retejo kaj elŝuti binarojn, nur rulu la komandon helm install stable/mongodb.
Due, Helm - ŝablona motoro, helpas parametrigi dosierojn. Ni revenu al la situacio kun YAML-dosieroj en Kubernetes. Estas pli facile skribi la saman YAML-dosieron, aldoni kelkajn anstataŭaĵojn al ĝi, en kiuj Helm anstataŭigos la valorojn. Tio estas, anstataŭ granda aro da skafaldoj, estos aro da ŝablonoj, en kiuj la postulataj valoroj estos anstataŭigitaj en la ĝusta tempo.
Trie, Helm - deplojmastro. Per ĝi vi povas instali, restarigi kaj ĝisdatigi aplikaĵojn. Ni eltrovu kiel fari tion.
Kiel uzi Helm por disfaldi viajn proprajn aplikojn
Ni instalu la Helm-klienton en via komputilo, sekvante la oficialan . Poste ni kreos aron da YAML-dosieroj. Anstataŭ specifi specifajn valorojn, ni lasos anstataŭaĵojn, kiujn Helm plenigos per informoj estonte. Aro de tiaj dosieroj nomiĝas Helm-diagramo. Ĝi povas esti sendita al la Helm-konzola kliento laŭ tri manieroj:
- indiki dosierujon kun ŝablonoj;
- paku la arkivon en .tar kaj montru ĝin;
- metu la ŝablonon en fora deponejo kaj aldonu ligilon al la deponejo en la Helm-kliento.
Vi ankaŭ bezonas dosieron kun valoroj - values.yaml. La datumoj de tie estos enmetitaj en la ŝablonon. Ni kreu ĝin ankaŭ.
La dua versio de Helm havas kroman servilan aplikaĵon - Tiller. Ĝi pendas ekster Kubernetes kaj atendas petojn de la Helm-kliento, kaj kiam vokita, anstataŭigas la postulatajn valorojn en la ŝablonon kaj sendas ĝin al Kubernetes.
Helm 3 estas pli simpla: anstataŭ prilaborado de ŝablonoj sur la servilo, informoj nun estas prilaboritaj tute ĉe la klientflanko de Helm kaj senditaj rekte al la Kubernetes API. Ĉi tiu simpligo plibonigas la sekurecon de la areto kaj faciligas la landan skemon.
Kiel ĉio funkcias
Rulu la komandon helm install. Ni indiku la nomon de la aplikaĵa eldono kaj donu la vojon al values.yaml. Fine ni indikos la deponejon en kiu troviĝas la diagramo kaj la nomon de la diagramo. En la ekzemplo, ĉi tiuj estas "lmru" kaj "bestchart", respektive.
helm install --name bestapp --values values.yaml lmru/bestchart
La komando povas esti ekzekutita nur unufoje, kiam denove ekzekutita anstataŭe install bezonas uzi upgrade. Por simpleco, anstataŭ du ordonoj, vi povas ruli la komandon upgrade kun aldona ŝlosilo --install. Kiam ekzekutita por la unua fojo, Helm sendos komandon por instali la eldonon, kaj ĝisdatigos ĝin estonte.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Malsukcesoj de deploji novajn versiojn de aplikaĵo kun Helm
Je ĉi tiu punkto de la rakonto, mi ludas Kiu Volas Esti Milionulo kun la spektantaro, kaj ni eltrovas kiel igi Helm ĝisdatigi la version de la programo. .
Kiam mi lernis kiel funkcias Helm, mi estis surprizita de stranga konduto, kiam mi provis ĝisdatigi versiojn de rulantaj aplikaĵoj. Mi ĝisdatigis la aplikan kodon, alŝutis novan bildon al la registro de Docker, sendis la deplojan komandon - kaj nenio okazis. Malsupre estas kelkaj ne tute sukcesaj manieroj ĝisdatigi aplikojn. Studante ĉiun el ili pli detale, vi komencas kompreni la internan strukturon de la instrumento kaj la kialojn de ĉi tiu ne evidenta konduto.
Metodo 1. Ne ŝanĝu informojn ekde la lasta lanĉo
Kiel ĝi diras Helm, "Kubernetes-diagramoj povas esti grandaj kaj kompleksaj, do Helm provas ne tro tuŝi ion ajn." Sekve, se vi ĝisdatigas la plej novan version de la aplika bildo en la docker-registro kaj rulu la komandon helm upgrade, tiam nenio okazos. Helm pensos, ke nenio ŝanĝiĝis kaj ne necesas sendi komandon al Kubernetes por ĝisdatigi la aplikaĵon.
Ĉi tie kaj sube, la plej nova etikedo estas montrita nur kiel ekzemplo. Kiam vi specifas ĉi tiun etikedon, Kubernetes elŝutos la bildon el la docker-registro ĉiufoje, sendepende de la parametro imagePullPolicy. Uzado de plej nova en produktado estas nedezirinda kaj kaŭzas kromefikojn.
Metodo 2. Ĝisdatigu LABEL en bildo
Kiel skribite en la sama , "Helm ĝisdatigos aplikaĵon nur se ĝi ŝanĝiĝis ekde la lasta eldono." Logika opcio por ĉi tio ŝajnus esti ĝisdatigi la LABEL en la docker-bildo mem. Tamen, Helm ne rigardas la aplikaĵbildojn kaj havas neniun ideon pri iuj ŝanĝoj al ili. Sekve, ĝisdatigante etikedojn en la bildo, Helm ne scios pri ili, kaj la aplikaĵa ĝisdatiga komando ne estos sendita al Kubernetes.
Metodo 3: Uzu ŝlosilon --force
Ni turnu nin al la manlibroj kaj serĉu la bezonatan ŝlosilon. La ŝlosilo havas la plej sencon --force. Malgraŭ la evidenta nomo, la konduto estas malsama ol atendita. Anstataŭ devigi aplikaĵon ĝisdatigon, ĝia vera celo estas restarigi eldonon kiu estas en FAILED statuso. Se vi ne uzas ĉi tiun ŝlosilon, vi devas plenumi la ordonojn sinsekve helm delete && helm install --replace. Oni sugestas uzi la ŝlosilon anstataŭe --force, kiu aŭtomatigas la sinsekvan ekzekuton de ĉi tiuj komandoj. Pliaj informoj en ĉi tio . Por diri al Helm ĝisdatigi la aplikaĵversion, bedaŭrinde ĉi tiu ŝlosilo ne funkcios.
Metodo 4. Ŝanĝu etikedojn rekte en Kubernetes
Ĝisdatigante etikedon rekte en la areto uzante la komandon kubectl edit — malbona ideo. Ĉi tiu ago kondukos al malkongruo de informoj inter la funkcianta aplikaĵo kaj tiu, kiu estis origine sendita por deplojo. La konduto de Helm dum deplojo ĉi-kaze diferencas de ĝia versio: Helm 2 nenion faros, kaj Helm 3 disfaldigos la novan version de la aplikaĵo. Por kompreni kial, vi devas kompreni kiel Helm funkcias.
Kiel funkcias Helm?
Por determini ĉu aplikaĵo ŝanĝiĝis ekde sia lasta eldono, Helm povas uzi:
- ruli aplikaĵon en Kubernetes;
- novaj valoroj.yaml kaj aktuala diagramo;
- La internaj eldoninformoj de Helm.
Por la pli scivolemaj: kie Helm stokas internajn informojn pri eldonoj?Ekzekutante la komandon helm history, ni ricevos ĉiujn informojn pri la versioj instalitaj uzante Helm.
Estas ankaŭ detalaj informoj pri la senditaj ŝablonoj kaj valoroj. Ni povas peti ĝin:
En la dua versio de Helm, ĉi tiu informo troviĝas en la sama nomspaco kie Tiller funkcias (kube-sistemo defaŭlte), en la KonfigMapo, markita per la etikedo "OWNER=TILLER":
Kiam la tria versio de Helm aperis, la informoj moviĝis al sekretoj, kaj al la sama nomspaco kie la aplikaĵo funkciis. Dank' al tio, eblis ruli plurajn aplikaĵojn samtempe en malsamaj nomspacoj kun la sama eldonnomo. En la dua versio estis severa kapdoloro kiam nomspacoj estas izolitaj sed povas influi unu la alian.
La dua Helm, provante kompreni ĉu ĝisdatigo estas bezonata, uzas nur du fontojn de informoj: kio estas provizita al ĝi nun, kaj internajn informojn pri eldonoj, kiuj kuŝas en la KonfigMapo.
La tria Helm uzas tridirektan kunfandan strategion: krom tiuj informoj, ĝi ankaŭ konsideras la aplikaĵon, kiu funkcias nun en Kubernetes.
Tial, la malnova versio de Helm nenion faros, ĉar ĝi ne konsideras la aplikaĵinformojn en la grapolo, sed Helm 3 ricevos la ŝanĝojn kaj sendos la novan aplikaĵon por deplojo.
Metodo 5. Uzu la --recreate-pods-ŝaltilon
Kun ŝlosilo --recreate-pods vi povas atingi tion, kion vi origine planis atingi per la ŝlosilo --force. La ujoj rekomencos kaj, laŭ la imagePullPolicy: Ĉiam politiko por la plej nova etikedo (pli pri tio en la piednoto supre), Kubernetes elŝutos kaj lanĉos novan version de la bildo. Ĉi tio ne estos farita en la plej bona maniero: sen konsideri la StrategyType de deplojo, ĝi subite malŝaltos ĉiujn malnovajn aplikaĵinstancojn kaj komencos lanĉi novajn. Dum la rekomenco, la sistemo ne funkcios, uzantoj suferos.
En Kubernetes mem, simila problemo ekzistis ankaŭ dum longa tempo. Kaj nun, 4 jarojn post la malfermo , la problemo estis riparita, kaj ekde la versio 1.15 de Kubernetes, aperas la kapablo ruliĝi rekomenci podojn.
Helm simple malŝaltas ĉiujn aplikojn kaj lanĉas novajn ujojn proksime. Vi ne povas fari ĉi tion en produktado, por ne kaŭzi malfunkcion de aplikaĵo. Ĉi tio estas nur necesa por evoluaj bezonoj kaj nur povas esti farita en scenejaj medioj.
Kiel ĝisdatigi la aplikaĵversion per Helm?
Ni ŝanĝos la valorojn senditajn al Helm. Tipe, ĉi tiuj estas valoroj, kiuj estas anstataŭigitaj anstataŭ la bilda etikedo. En la kazo de plej nova, kiu estas ofte uzata por neproduktemaj medioj, la ŝanĝebla informo estas komentario, kiu estas senutila por Kubernetes mem, kaj por Helm ĝi funkcios kiel signalo por la bezono ĝisdatigi la aplikaĵon. Opcioj por plenigi la komentadan valoron:
- Hazarda valoro uzante la norman funkcion -
{{ randAlphaNum 6 }}.
Estas averto: post ĉiu deplojo uzante diagramon kun tia variablo, la komentada valoro estos unika, kaj Helm supozos, ke ekzistas ŝanĝoj. Rezultas, ke ni ĉiam rekomencos la aplikaĵon, eĉ se ni ne ŝanĝis ĝian version. Ĉi tio ne estas kritika, ĉar ne estos malfunkcio, sed ĝi ankoraŭ estas malagrabla. - Algluu fluon dato kaj horo -
{{ .Release.Date }}.
Variaĵo similas al hazarda valoro kun konstante unika variablo. - Pli ĝusta maniero estas uzi ĉeksumoj. Ĉi tio estas la SHA de la bildo aŭ la SHA de la lasta komit en la git -
{{ .Values.sha }}.
Ili devos esti kalkulitaj kaj senditaj al la Helm-kliento ĉe la alvokanta flanko, ekzemple en Jenkins. Se la aplikaĵo ŝanĝiĝis, tiam la ĉeksumo ŝanĝiĝos. Tial Helm ĝisdatigos la aplikaĵon nur kiam necese.
Ni resumu niajn provojn
- Helm faras ŝanĝojn en la malplej enpenetra maniero, do ajna ŝanĝo ĉe la aplika bildo-nivelo en la Docker-Registro ne rezultigos ĝisdatigon: nenio okazos post kiam la komando estos ekzekutita.
- Ключ
--forceuzata por restarigi problemajn eldonojn kaj ne rilatas al devigitaj ĝisdatigoj. - Ключ
--recreate-podsperforte ĝisdatigos aplikaĵojn, sed faros tion vandale: ĝi abrupte malŝaltos ĉiujn ujojn. Uzantoj suferos pro tio; vi ne faru tion en produktado. - Rekte faru ŝanĝojn al la Kubernetes-grupo per la komando
kubectl editne faru: ni rompos konsekvencon, kaj la konduto malsamos depende de la versio de Helm. - Kun la ĵeto de la nova versio de Helm, multaj nuancoj aperis. Problemoj en la Helm-deponejo estas priskribitaj en klara lingvo, ili helpos vin kompreni la detalojn.
- Aldono de redaktebla komentario al diagramo igos ĝin pli fleksebla. Ĉi tio permesos al vi ruliĝi la aplikaĵon ĝuste, sen malfunkcio.
Penso de "mondpaco", kiu funkcias en ĉiuj kampoj de la vivo: legu la instrukciojn antaŭ uzo, ne post. Nur kun kompleta informo eblos konstrui fidindajn sistemojn kaj feliĉigi uzantojn.
Aliaj rilataj ligiloj:
Ĉi tiu raporto unue estis prezentita ĉe de Mail.ru Cloud Solutions. Rigardu aliajn prezentojn kaj abonu eventoncon sur Telegramo .
fonto: www.habr.com