ProHoster > Blog > administratë > Heqja e një dege të vjetëruar të veçorive në një grup Kubernetes

Heqja e një dege të vjetëruar të veçorive në një grup Kubernetes

Heqja e një dege të vjetëruar të veçorive në një grup Kubernetes

Привет! Dega e veçorive (i njohur ndryshe si vrojtimi paraprak i vendosjes, aplikacioni i rishikimit) - kjo ndodh kur vendoset jo vetëm dega kryesore, por edhe çdo kërkesë tërheqëse në një URL unike. Mund të kontrolloni nëse kodi funksionon në një mjedis prodhimi; funksioni mund t'u shfaqet programuesve të tjerë ose specialistëve të produktit. Ndërsa jeni duke punuar në një kërkesë tërheqjeje, çdo vendosje e re aktuale e kryerjes për kodin e vjetër fshihet dhe vendosja e re për kodin e ri hapet. Pyetjet mund të lindin kur keni bashkuar një kërkesë tërheqjeje në degën kryesore. Nuk ju nevojitet më dega e veçorive, por burimet e Kubernetes janë ende në grup.

Më shumë rreth degëve të veçorive

Një qasje për të krijuar degë të veçorive në Kubernetes është përdorimi i hapësirave të emrave. Shkurtimisht, konfigurimi i prodhimit duket si ky:

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

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

Për një degë tipare, një hapësirë ​​emri krijohet me identifikuesin e saj (për shembull, numrin e kërkesës për tërheqje) dhe një lloj prefiksi/postfiks (për shembull, -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
...

Në përgjithësi, kam shkruar Operatori Kubernetes (një aplikacion që ka akses në burimet e grupimit), lidhje me projektin në Github. Ai heq hapësirat e emrave që i përkasin degëve të vjetra të veçorive. Në Kubernetes, nëse fshini një hapësirë ​​emri, burimet e tjera në atë hapësirë ​​emrash fshihen gjithashtu automatikisht.

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

Mund të lexoni se si të implementoni degët e veçorive në një grup këtu и këtu.

motivimi

Le të shohim një cikël jetësor tipik të kërkesës për tërheqje me integrim të vazhdueshëm (continuous integration):

  1. Ne shtyjmë një angazhim të ri në degë.
  2. Në ndërtimin, linjat dhe/ose testet janë ekzekutuar.
  3. Konfigurimet e kërkesave për tërheqje të Kubernetes krijohen menjëherë (për shembull, numri i tij futet në shabllonin e përfunduar).
  4. Duke përdorur kubectl application, konfigurimet shtohen në grup (deploy).
  5. Kërkesa për tërheqje shkrihet në degën kryesore.

Ndërsa jeni duke punuar në një kërkesë tërheqjeje, çdo vendosje e re aktuale e kryerjes për kodin e vjetër fshihet dhe vendosja e re për kodin e ri hapet. Por kur një kërkesë tërheqëse bashkohet në degën kryesore, do të ndërtohet vetëm dega kryesore. Si rezultat, rezulton se ne kemi harruar tashmë kërkesën për tërheqje, dhe burimet e tij Kubernetes janë ende në grup.

Si të përdoret

Instaloni projektin me komandën e mëposhtme:

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

Krijoni një skedar me përmbajtjen e mëposhtme dhe instaloni nëpërmjet kubectl apply -f:

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

Parametër namespaceSubstring nevojiten për të filtruar hapësirat e emrave për kërkesat e tërheqjes nga hapësirat e tjera të emrave. Për shembull, nëse grupi ka hapësirat e mëposhtme të emrave: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, atëherë kandidatët për fshirje do të jenë habr-back-end-pr-17, habr-back-end-pr-33.

Parametër pasDitëvePa Deploy nevojiten për të fshirë hapësirat e vjetra të emrave. Për shembull, nëse krijohet hapësira e emrit 3 дня 1 час prapa, dhe parametri tregon 3 дня, kjo hapësirë ​​emri do të fshihet. Ai gjithashtu funksionon në drejtim të kundërt nëse krijohet hapësira e emrave 2 дня 23 часа prapa, dhe parametri tregon 3 дня, kjo hapësirë ​​emri nuk do të fshihet.

Ekziston edhe një parametër tjetër, ai është përgjegjës për sa shpesh skanoni të gjitha hapësirat e emrave dhe kontrolloni për ditë pa u vendosur - kontrolloniEveryMinutes. Si parazgjedhje është e barabartë 30 минутам.

Si punon kjo

Në praktikë, do t'ju duhet:

  1. prerës për të punuar në një mjedis të izoluar.
  2. Minikube do të ngrejë një grup Kubernetes në nivel lokal.
  3. kubectl — Ndërfaqja e linjës së komandës për menaxhimin e grupimeve.

Ne ngremë një grup Kubernetes në nivel lokal:

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

Ne tregojmë kubectl përdorni grupin lokal si parazgjedhje:

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

Shkarkoni konfigurimet për mjedisin e prodhimit:

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

Meqenëse konfigurimet e prodhimit janë konfiguruar për të kontrolluar hapësirat e vjetra të emrave dhe grupi ynë i sapo ngritur nuk i ka ato, ne do të zëvendësojmë variablin e mjedisit IS_DEBUG mbi true. Me këtë vlerë parametri afterDaysWithoutDeploy nuk merret parasysh dhe hapësirat e emrave nuk kontrollohen për ditë pa u vendosur, vetëm për ndodhjen e nënvargut (-pr-).

Nëse jeni në Linux:

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

Nëse jeni në macOS:

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

Instalimi i projektit:

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

Duke kontrolluar nëse një burim është shfaqur në grup StaleFeatureBranch:

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

Ne kontrollojmë që një operator është shfaqur në grup:

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

Nëse shikoni regjistrat e tij, ai është gati të përpunojë burimet 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}

Ne instalojmë të gatshme fixtures (konfigurime të gatshme për modelimin e burimeve të grupimit) për një burim StaleFeatureBranch:

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

Konfigurimet tregojnë për të kërkuar hapësira emrash me një nënvarg -pr- një herë në 1 минуту.:

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

Operatori është përgjigjur dhe është gati të kontrollojë hapësirat e emrave:

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

I vendosur fixtures, që përmban dy hapësira emrash (project-pr-1, project-pr-2) dhe ata deployments, services, ingress, dhe kështu me radhë:

$ 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

Ne kontrollojmë që të gjitha burimet e mësipërme janë krijuar me sukses:

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

Meqë kemi përfshirë debug, hapësirat e emrave project-pr-1 и project-pr-2, prandaj të gjitha burimet e tjera do të duhet të fshihen menjëherë pa marrë parasysh parametrin afterDaysWithoutDeploy. Kjo mund të shihet në regjistrat e operatorit:

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

Nëse kontrolloni disponueshmërinë e burimeve, ato do të jenë në status Terminating (procesi i fshirjes) ose tashmë i fshirë (dalja e komandës është bosh).

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

Ju mund të përsërisni procesin e krijimit fixtures disa herë dhe sigurohuni që ato të hiqen brenda një minute.

alternativa

Çfarë mund të bëhet në vend të një operatori që punon në një grup? Ka disa qasje, të gjitha janë të papërsosura (dhe mangësitë e tyre janë subjektive), dhe të gjithë vendosin vetë se çfarë është më e mira për një projekt të caktuar:

  1. Fshi degën e veçorive gjatë ndërtimit të integruar të vazhdueshëm të degës kryesore.

    • Për ta bërë këtë, ju duhet të dini se cila kërkesë tërheqëse lidhet me kryerjen që po ndërtohet. Meqenëse hapësira e emrave të degës së veçorive përmban identifikuesin e kërkesës për tërheqje - numrin e tij, ose emrin e degës, identifikuesi gjithmonë duhet të specifikohet në commit.
    • Ndërtimet kryesore të degëve po dështojnë. Për shembull, ju keni fazat e mëposhtme: shkarkoni projektin, ekzekutoni testet, ndërtoni projektin, bëni një lëshim, dërgoni njoftime, pastroni degën e veçorive të kërkesës së fundit të tërheqjes. Nëse ndërtimi dështon kur dërgoni një njoftim, do t'ju duhet të fshini manualisht të gjitha burimet në grup.
    • Pa kontekstin e duhur, fshirja e degëve të veçorive në ndërtimin master nuk është e qartë.

  2. Përdorimi i grepave në internet (shembull).

    • Kjo mund të mos jetë qasja juaj. Për shembull, në Jenkins, vetëm një lloj tubacioni mbështet aftësinë për të ruajtur konfigurimet e tij në kodin burimor. Kur përdorni grepa në internet, duhet të shkruani skriptin tuaj për t'i përpunuar ato. Ky skenar do të duhet të vendoset në ndërfaqen Jenkins, e cila është e vështirë për t'u ruajtur.

  3. shkruaj Cronjob dhe shtoni një grup Kubernetes.

    • Shpenzimi i kohës për shkrim dhe mbështetje.
    • Operatori tashmë punon në një stil të ngjashëm, është i dokumentuar dhe i mbështetur.

Faleminderit për vëmendjen tuaj ndaj artikullit. Lidhja me projektin në Github.

Burimi: www.habr.com

Shto një koment