ProHoster > Dienoraštis > Administravimas > Pašalinama pasenusi funkcijų šaka Kubernetes klasteryje

Pašalinama pasenusi funkcijų šaka Kubernetes klasteryje

Pašalinama pasenusi funkcijų šaka Kubernetes klasteryje

Sveiki! Funkcijų šaka (dar žinomas kaip diegimo peržiūra, peržiūros programa) – tai yra tada, kai įdiegiama ne tik pagrindinė šaka, bet ir kiekviena ištraukimo užklausa į unikalų URL. Galite patikrinti, ar kodas veikia gamybinėje aplinkoje, funkcija gali būti parodyta kitiems programuotojams ar produktų specialistams. Kol dirbate su ištraukimo užklausa, kiekvienas naujas senojo kodo įdiegimas yra ištrinamas ir išleidžiamas naujas naujo kodo diegimas. Sujungus ištraukimo užklausą į pagrindinę šaką, gali kilti klausimų. Jums nebereikia funkcijų šakos, bet Kubernetes ištekliai vis dar yra klasteryje.

Daugiau apie funkcijų šakas

Vienas iš būdų sukurti funkcijų šakas „Kubernetes“ yra naudoti vardų erdves. Trumpai tariant, gamybos konfigūracija atrodo taip:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

Funkcijos šakai sukuriama vardų erdvė su jos identifikatoriumi (pavyzdžiui, ištraukimo užklausos numeriu) ir tam tikru priešdėliu / postfiksu (pavyzdžiui, -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

Apskritai aš parašiau Kubernetes operatorius (programa, turinti prieigą prie klasterio išteklių), nuoroda į projektą „Github“.. Jis pašalina vardų sritis, priklausančias senoms funkcijų šakoms. Jei „Kubernetes“ ištrinate vardų sritį, kiti tos vardų srities ištekliai taip pat bus ištrinti automatiškai.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

Galite perskaityti, kaip įtraukti funkcijų šakas į klasterį čia и čia.

Motyvacija

Pažvelkime į tipinį ištraukimo užklausos gyvavimo ciklą su nuolatine integracija (continuous integration):

  1. Mes stumiame naują įsipareigojimą filialui.
  2. Konstravimo metu atliekami linteriai ir (arba) bandymai.
  3. „Kubernetes“ ištraukimo užklausos konfigūracijos generuojamos skrydžio metu (pavyzdžiui, jos numeris įterpiamas į baigtą šabloną).
  4. Naudojant kubectl apply, konfigūracijos pridedamos prie klasterio (diegimas).
  5. Ištraukimo užklausa sujungiama į pagrindinę šaką.

Kol dirbate su ištraukimo užklausa, kiekvienas naujas senojo kodo įdiegimas ištrinamas, o naujas naujojo kodo diegimas išleidžiamas. Bet kai ištraukimo užklausa sujungiama į pagrindinę šaką, bus sukurta tik pagrindinė šaka. Dėl to paaiškėja, kad mes jau pamiršome apie ištraukimo užklausą, o jos „Kubernetes“ ištekliai vis dar yra klasteryje.

Kaip naudotis

Įdiekite projektą naudodami toliau pateiktą komandą:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

Sukurkite failą su tokiu turiniu ir įdiekite per kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

Parametras vardų erdvė poeilutė reikalingas norint filtruoti vardų sritis, kad būtų galima gauti užklausas iš kitų vardų erdvių. Pavyzdžiui, jei klasteris turi šias vardų sritis: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, tada kandidatai bus ištrinti habr-back-end-pr-17, habr-back-end-pr-33.

Parametras afterDaysWithoutDeploy reikia ištrinti senas vardų sritis. Pavyzdžiui, jei sukurta vardų erdvė 3 дня 1 час atgal, o parametras rodo 3 дня, ši vardų erdvė bus ištrinta. Jis taip pat veikia priešinga kryptimi, jei sukuriama vardų erdvė 2 дня 23 часа atgal, o parametras rodo 3 дня, ši vardų erdvė nebus ištrinta.

Yra dar vienas parametras, jis yra atsakingas už tai, kaip dažnai nuskaityti visas vardų sritis ir patikrinti dienų be diegimo. checkEveryMinutes. Pagal numatytuosius nustatymus jis yra lygus 30 минутам.

Kaip tai veikia

Praktiškai jums reikės:

  1. dokininkas darbui izoliuotoje aplinkoje.
  2. Minikubas iškels Kubernetes klasterį vietoje.
  3. kubectl — komandų eilutės sąsaja, skirta klasterio valdymui.

Mes sukuriame Kubernetes klasterį vietoje:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

Mes nurodome kubectl naudoti vietinį klasterį pagal numatytuosius nustatymus:

$ kubectl config use-context minikube
Switched to context "minikube".

Atsisiųskite gamybos aplinkos konfigūracijas:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

Kadangi gamybos konfigūracijos sukonfigūruotos patikrinti senas vardų sritis, o mūsų naujai sukurtame klasteryje jų nėra, pakeisime aplinkos kintamąjį IS_DEBUG apie true. Su šia reikšme parametras afterDaysWithoutDeploy neatsižvelgiama ir vardų erdvės netikrinamos kelias dienas be diegimo, tik dėl poeilutės (-pr-).

Jei esate įjungtas Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

Jei esate įjungtas macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

Projekto diegimas:

$ kubectl apply -f stale-feature-branch-production-configs.yml

Tikrinama, ar klasteryje atsirado išteklių StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Mes patikriname, ar klasteryje atsirado operatorius:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

Jei pažvelgsite į jo žurnalus, jis yra pasirengęs apdoroti išteklius StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

Montuojame jau paruoštą fixtures (paruoštos konfigūracijos klasterio ištekliams modeliuoti) ištekliui StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

Konfigūracijos rodo, kad reikia ieškoti vardų erdvių su eilute -pr- kartą įėjęs 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

Operatorius atsakė ir yra pasirengęs patikrinti vardų sritis:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

Nustatyti fixtures, turinčios dvi vardų sritis (project-pr-1, project-pr-2) ir juos deployments, services, ingress, ir taip toliau:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

Mes patikriname, ar visi aukščiau pateikti ištekliai buvo sėkmingai sukurti:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

Kadangi mes įtraukėme debug, vardų sritis project-pr-1 и project-pr-2, todėl visi kiti ištekliai turės būti nedelsiant ištrinti, neatsižvelgiant į parametrą afterDaysWithoutDeploy. Tai galima pamatyti operatoriaus žurnaluose:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

Jei patikrinsite išteklių prieinamumą, jie bus būsenoje Terminating (ištrynimo procesas) arba jau ištrintas (komandos išvestis tuščia).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

Galite pakartoti kūrimo procesą fixtures kelis kartus ir įsitikinkite, kad jie bus pašalinti per minutę.

Alternatyvos

Ką galima padaryti vietoj operatoriaus, kuris dirba klasteryje? Yra keletas požiūrių, visi jie yra netobuli (o jų trūkumai yra subjektyvūs), ir kiekvienas nusprendžia, kas geriausiai tinka konkrečiam projektui:

  1. Ištrinkite funkcijos šaką nuolat integruojant pagrindinį šaką.

    • Norėdami tai padaryti, turite žinoti, kuri ištraukimo užklausa yra susijusi su kuriamu įsipareigojimu. Kadangi funkcijų šakos vardų erdvėje yra ištraukimo užklausos identifikatorius - jo numeris arba šakos pavadinimas, identifikatorius visada turės būti nurodytas įsipareigojime.
    • Pagrindinės šakos kūrimo nepavyksta. Pavyzdžiui, turite šiuos etapus: atsisiųskite projektą, vykdykite testus, sukurkite projektą, išleiskite, siųskite pranešimus, išvalykite paskutinės ištraukimo užklausos funkcijų šaką. Jei kūrimas nepavyks siunčiant pranešimą, turėsite rankiniu būdu ištrinti visus klasterio išteklius.
    • Be tinkamo konteksto pagrindinės versijos funkcijų šakų ištrynimas nėra akivaizdus.

  2. „Webhooks“ naudojimas (pavyzdys).

    • Tai gali būti ne jūsų požiūris. Pavyzdžiui, į Jenkins, tik vieno tipo dujotiekis palaiko galimybę išsaugoti jo konfigūracijas šaltinio kode. Kai naudojate žiniatinklio kabliukus, turite parašyti savo scenarijų, kad galėtumėte juos apdoroti. Šis scenarijus turės būti įdėtas į Jenkins sąsają, kurią sunku prižiūrėti.

  3. Rašyti Kronjobas ir pridėkite „Kubernetes“ klasterį.

    • Skirkite laiko rašymui ir palaikymui.
    • Operatorius jau dirba panašiu stiliumi, yra dokumentuotas ir palaikomas.

Dėkojame, kad atkreipėte dėmesį į straipsnį. Nuoroda į projektą Github.

Šaltinis: www.habr.com

Добавить комментарий