🥇Odstranjevanje zastarele veje funkcij v gruči Kubernetes

Lep pozdrav! Funkcijska veja (tudi deploy preview, review app) – to je, ko ni uvedena le glavna veja, temveč tudi vsaka zahteva za vleko na edinstven URL. Preverite lahko, ali koda deluje v produkcijskem okolju; funkcijo lahko pokažete drugim programerjem ali strokovnjakom za izdelke. Medtem ko delate v zahtevi za vlečenje, se vsaka nova potrditev trenutne uvedbe za staro kodo izbriše, nova uvedba za novo kodo pa se uvede. Vprašanja se lahko pojavijo, ko ste združili zahtevo za vlečenje v glavno vejo. Veje funkcij ne potrebujete več, vendar so viri Kubernetes še vedno v gruči.

Več o funkcijskih vejah

Eden od pristopov k ustvarjanju vej funkcij v Kubernetesu je uporaba imenskih prostorov. Na kratko je proizvodna konfiguracija videti takole:

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

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

Za vejo funkcije je ustvarjen imenski prostor z njegovim identifikatorjem (na primer številka zahteve za vlečenje) in nekakšno predpono/popono (na primer -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
...

Na splošno sem napisal Operater Kubernetes (aplikacija, ki ima dostop do virov gruče), povezava do projekta na Githubu. Odstrani imenske prostore, ki pripadajo starim vejam funkcij. Če v Kubernetesu izbrišete imenski prostor, se samodejno izbrišejo tudi drugi viri v tem imenskem prostoru.

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

Preberete lahko o tem, kako implementirati veje funkcij v gručo tukaj и tukaj.

Motivacija

Oglejmo si tipičen življenjski cikel zahteve po vleki z neprekinjeno integracijo (continuous integration):

Potisnemo novo obvezo v vejo.
Pri gradnji se izvajajo linterji in/ali testi.
Konfiguracije vlečne zahteve Kubernetes se generirajo sproti (na primer, njena številka se vstavi v končano predlogo).
Z uporabo kubectl apply se konfiguracije dodajo v gručo (deploy).
Zahteva za vlečenje je združena v glavno vejo.

Medtem ko delate v zahtevi za vlečenje, se vsaka nova potrditev trenutne uvedbe za staro kodo izbriše, nova uvedba za novo kodo pa se uvede. Toda ko je zahteva za vlečenje združena v glavno vejo, bo zgrajena samo glavna veja. Posledično se izkaže, da smo že pozabili na zahtevo za vlečenje in da so njegovi viri Kubernetes še vedno v gruči.

Kako uporabljati

Namestite projekt s spodnjim ukazom:

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

Ustvarite datoteko z naslednjo vsebino in jo namestite prek kubectl apply -f:

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

Parameter namespaceSubstring potreben za filtriranje imenskih prostorov za zahteve po vleku iz drugih imenskih prostorov. Na primer, če ima gruča naslednje imenske prostore: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, potem bodo kandidati za izbris habr-back-end-pr-17, habr-back-end-pr-33.

Parameter afterDaysWithoutDeploy potrebno za brisanje starih imenskih prostorov. Na primer, če je ustvarjen imenski prostor 3 дня 1 час nazaj, in parameter označuje 3 дня, bo ta imenski prostor izbrisan. Deluje tudi v nasprotni smeri, če je imenski prostor ustvarjen 2 дня 23 часа nazaj, in parameter označuje 3 дня, ta imenski prostor ne bo izbrisan.

Obstaja še en parameter, odgovoren je za to, kako pogosto pregledati vse imenske prostore in preveriti dneve brez uvajanja - checkEveryMinutes. Privzeto je enako 30 минутам.

Kako to deluje

V praksi boste potrebovali:

Lučki delavec za delo v izoliranem okolju.
Minikube bo lokalno ustvaril gručo Kubernetes.
kubectl — vmesnik ukazne vrstice za upravljanje gruče.

Lokalno vzgajamo gručo Kubernetes:

$ 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.

Navajamo kubectl privzeto uporabi lokalno gručo:

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

Prenesite konfiguracije za produkcijsko okolje:

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

Ker so produkcijske konfiguracije konfigurirane za preverjanje starih imenskih prostorov in jih naša na novo postavljena gruča nima, bomo zamenjali spremenljivko okolja IS_DEBUG o true. S to vrednostjo parameter afterDaysWithoutDeploy se ne upošteva in imenski prostori se ne preverjajo za dneve brez uvedbe, samo za pojav podniza (-pr-).

Če ste na Linux:

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

Če ste na macOS:

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

Namestitev projekta:

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

Preverjanje, ali se je vir pojavil v gruči StaleFeatureBranch:

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

Preverimo, ali se je v gruči pojavil operator:

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

Če pogledate njegove dnevnike, je pripravljen za obdelavo virov 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}

Montiramo že pripravljeno fixtures (pripravljene konfiguracije za modeliranje virov gruče) za vir StaleFeatureBranch:

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

Konfiguracije kažejo na iskanje imenskih prostorov s podnizom -pr- enkrat noter 1 минуту.:

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

Operater se je odzval in je pripravljen preveriti imenske prostore:

$ 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"}

Set fixtures, ki vsebuje dva imenska prostora (project-pr-1, project-pr-2) in njih deployments, services, ingress, in tako naprej:

$ 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

Preverimo, ali so bili vsi zgornji viri uspešno ustvarjeni:

$ 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
...

Ker smo vključili debug, imenski prostori project-pr-1 и project-pr-2, zato bo treba vse druge vire takoj izbrisati brez upoštevanja parametra afterDaysWithoutDeploy. To je razvidno iz dnevnikov operaterja:

$ 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"}

Če preverite razpoložljivost virov, bodo v statusu Terminating (postopek brisanja) ali že izbrisan (izhod ukaza je prazen).

$ 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
...

Postopek ustvarjanja lahko ponovite fixtures večkrat in se prepričajte, da so odstranjene v eni minuti.

Alternativa

Kaj je mogoče narediti namesto operaterja, ki dela v gruči? Obstaja več pristopov, vsi so nepopolni (in njihove pomanjkljivosti subjektivne) in vsak se sam odloči, kaj je najboljše za določen projekt:

Izbrišite vejo funkcije med gradnjo glavne veje neprekinjene integracije.
- Če želite to narediti, morate vedeti, katera zahteva za vlečenje se nanaša na objavo, ki se gradi. Ker imenski prostor veje funkcije vsebuje identifikator zahteve za vleko – njegovo številko ali ime veje, bo moral biti identifikator vedno naveden v objavi.
- Zgradbe glavne veje so neuspešne. Na primer, imate naslednje faze: prenos projekta, izvajanje preizkusov, izdelava projekta, izdaja, pošiljanje obvestil, brisanje veje funkcije zadnje zahteve za vleko. Če gradnja pri pošiljanju obvestila ne uspe, boste morali ročno izbrisati vse vire v gruči.
- Brez ustreznega konteksta brisanje vej funkcij v glavni zgradbi ni očitno.
Uporaba webhookov (Primer).
- To morda ni vaš pristop. Na primer, v Jenkins, samo ena vrsta cevovoda podpira možnost shranjevanja svojih konfiguracij v izvorno kodo. Ko uporabljate webhooke, morate napisati svoj skript za njihovo obdelavo. Ta skript bo treba postaviti v vmesnik Jenkins, ki ga je težko vzdrževati.
Za pisanje Cronjob in dodajte gručo Kubernetes.
- Poraba časa za pisanje in podporo.
- Operater že deluje v podobnem slogu, je dokumentiran in podprt.

Hvala za vašo pozornost članku. Povezava do projekta na Githubu.

Vir: www.habr.com

Odstranjevanje zastarele veje funkcij v gruči Kubernetes

Več o funkcijskih vejah

Motivacija

Kako uporabljati

Kako to deluje

Alternativa

Dodaj komentar Prekliči odgovor