ProHoster > Blog > administrasie > Vee 'n verouderde kenmerktak in 'n Kubernetes-kluster uit

Vee 'n verouderde kenmerktak in 'n Kubernetes-kluster uit

Vee 'n verouderde kenmerktak in 'n Kubernetes-kluster uit

Привет! kenmerk tak (ook bekend as ontplooi voorskou, hersien app) is wanneer nie net die meestertak ontplooi word nie, maar ook elke trekversoek na 'n unieke URL. U kan kyk of die kode in die produksie-omgewing werk, u kan die kenmerk aan ander programmeerders of produkbestuurders wys. Terwyl jy aan 'n trekversoek werk, word elke nuwe commit die huidige ontplooiing vir die ou kode verwyder, en 'n nuwe ontplooiing vir die nuwe kode word ontplooi. Vrae kan ontstaan ​​wanneer jy 'n trekversoek in die meestertak saamgevoeg het. Jy het nie meer die kenmerktak nodig nie, maar die Kubernetes-hulpbronne is steeds in die groepie.

Meer oor kenmerktakke

Een benadering om kenmerktakke in Kubernetes te maak, is om naamruimtes te gebruik. Kortom, die produksiekonfigurasie lyk soos volg:

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

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

Vir 'n kenmerktak word 'n naamruimte geskep met sy identifiseerder (byvoorbeeld die trekversoeknommer) en een of ander voorvoegsel / postfix (byvoorbeeld, -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
...

Oor die algemeen het ek geskryf Kubernetes-operateur (toepassing wat toegang tot groephulpbronne het), projekskakel op Github. Dit verwyder naamruimtes wat aan ou kenmerktakke behoort. In Kubernetes, as jy 'n naamspasie uitvee, word ander hulpbronne in daardie naamspasie ook outomaties uitgevee.

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

Jy kan lees oor hoe om kenmerktakke in 'n groepie te implementeer hier и hier.

Motivering

Kom ons kyk na 'n tipiese deurlopende integrasie trek versoek lewensiklus (continuous integration):

  1. Ons druk 'n nuwe verbintenis tot die tak.
  2. Op die bouvorm word linters en/of toetse uitgevoer.
  3. Kubernetes-trekversoekkonfigurasies word dadelik gevorm (byvoorbeeld, die nommer daarvan word in die voltooide sjabloon vervang).
  4. Deur kubectl application te gebruik, kom die konfigurasies in die groep in (ontplooi).
  5. Die trekversoek word saamgevoeg in die meestertak.

Terwyl jy aan 'n trekversoek werk, word elke nuwe commit die huidige ontplooiing vir die ou kode verwyder, en 'n nuwe ontplooiing vir die nuwe kode word ontplooi. Maar wanneer 'n trekversoek in die meestertak saamgevoeg word, sal slegs die meestertak gebou word. As gevolg hiervan blyk dit dat ons reeds van die trekversoek vergeet het, en sy Kubernetes-hulpbronne is steeds in die groep.

Hoe om te gebruik

Installeer die projek met die opdrag hieronder:

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

Skep 'n lêer met die volgende inhoud en installeer via kubectl apply -f:

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

Parameter naamruimteSubstring nodig om trekversoek-naamruimtes van ander naamruimtes te filter. Byvoorbeeld, as die groep die volgende naamruimtes het: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, dan sal die kandidate vir skrapping wees habr-back-end-pr-17, habr-back-end-pr-33.

Parameter afterDaysWithoutDeploy nodig om ou naamruimtes te verwyder. Byvoorbeeld, as naamruimte geskep word 3 дня 1 час terug, en die parameter spesifiseer 3 дня, sal hierdie naamspasie verwyder word. Werk andersom as naamruimte geskep word 2 дня 23 часа terug, en die parameter spesifiseer 3 дня, sal hierdie naamspasie nie verwyder word nie.

Daar is nog een parameter, dit is verantwoordelik vir hoe gereeld om alle naamruimtes te skandeer en vir dae na te gaan sonder om te ontplooi - checkEveryMinutes. By verstek is dit gelyk aan 30 минутам.

Hoe werk dit

In die praktyk sal jy nodig hê:

  1. Docker om in 'n geïsoleerde omgewing te werk.
  2. Minikube sal 'n Kubernetes-kluster plaaslik oprig.
  3. kubectl - opdragreël-koppelvlak vir groepbestuur.

Ons kweek die Kubernetes-kluster plaaslik:

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

Ons dui aan kubectl gebruik standaard plaaslike cluster:

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

Laai die konfigurasie vir die produksie-omgewing af:

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

Aangesien die produksiekonfigurasies gekonfigureer is om na ou naamruimtes te kyk, en daar is geen in ons nuwe groepering nie, sal ons die omgewingsveranderlike vervang IS_DEBUG op true. Met hierdie waarde, die parameter afterDaysWithoutDeploy word nie in ag geneem nie en naamruimtes word nie vir dae sonder ontplooiing nagegaan nie, slegs vir die voorkoms van 'n substring (-pr-).

As jy aan is Linux:

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

As jy aan is macOS:

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

Installeer die projek:

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

Kontroleer dat 'n hulpbron in die groep verskyn het StaleFeatureBranch:

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

Ons kyk of 'n operateur in die groep verskyn het:

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

As jy na sy logs kyk, is hy gereed om hulpbronne te verwerk 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}

Ons installeer gereed fixtures (gereedgemaakte konfigurasies vir die modellering van groephulpbronne) vir 'n hulpbron StaleFeatureBranch:

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

Die konfigurasies dui aan om te soek na naamruimtes met 'n substring -pr- een keer in 1 минуту.:

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

Die operateur het gereageer en is gereed om naamruimtes na te gaan:

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

Stel fixtures, wat twee naamruimtes bevat (project-pr-1, project-pr-2) en hulle deployments, services, ingress, en so aan:

$ 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

Kontroleer dat alle hulpbronne hierbo suksesvol geskep is:

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

Aangesien ons ingesluit het debug, naamruimtes project-pr-1 и project-pr-2, dus sal alle ander hulpbronne onmiddellik uitgevee moet word sonder om die parameter in ag te neem afterDaysWithoutDeploy. Dit kan gesien word in die logs van die operateur:

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

As jy die beskikbaarheid van hulpbronne nagaan, sal hulle in die status wees Terminating (uitveeproses) of reeds uitgevee (beveluitvoer is leeg).

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

U kan die skeppingsproses herhaal fixtures verskeie kere en maak seker dat hulle binne 'n minuut verwyder word.

alternatiewe

Wat kan gedoen word in plaas van 'n operateur wat in 'n groep werk? Daar is verskeie benaderings, almal is nie ideaal nie (en hul tekortkominge is subjektief), en elkeen besluit self wat die beste is vir 'n spesifieke projek:

  1. Verwyder kenmerktak tydens meestertak deurlopende integrasiebou.

    • Om dit te doen, moet jy weet watter trekversoek behoort aan die commit wat gebou word. Aangesien die kenmerktaknaamruimte die trekversoekidentifiseerder bevat - sy nommer, of die naam van die tak, sal die identifiseerder altyd in die commit gespesifiseer moet word.
    • Bouwerk van meestertakke misluk. Byvoorbeeld, jy het die volgende stadiums: laai die projek af, voer toetse uit, bou die projek, maak 'n vrystelling, stuur kennisgewings, maak die kenmerktak van die laaste trekversoek skoon. As die bou misluk met die stuur van 'n kennisgewing, sal jy alle hulpbronne in die groep met die hand moet uitvee.
    • Sonder behoorlike konteks is dit nie voor die hand liggend om 'n kenmerktak in 'n meesterbou uit te vee nie.

  2. Gebruik webhooks (Byvoorbeeld).

    • Miskien is dit nie jou benadering nie. Byvoorbeeld, in Jenkins, ondersteun slegs een tipe pyplyn die vermoë om sy konfigurasies in die bronkode te stoor. Wanneer jy webhooks gebruik, moet jy jou eie skrif skryf om dit te verwerk. Hierdie skrif sal in die Jenkins-koppelvlak geplaas moet word, wat moeilik is om te onderhou.

  3. Skryf cron werk en voeg 'n Kubernetes-kluster by.

    • Tyd bestee aan skryf en instandhouding.
    • Die operateur werk reeds in 'n soortgelyke styl, is gedokumenteer en ondersteun.

Dankie vir u aandag aan die artikel. Skakel na die projek op Github.

Bron: will.com

Voeg 'n opmerking