🥇Aegunud funktsiooniharu eemaldamine Kubernetese klastris

Tere! Funktsiooni haru (teise nimega juurutamise eelvaade, ülevaatusrakendus) – see on siis, kui juurutatakse mitte ainult põhiharu, vaid ka iga kordumatu URL-i tõmbamistaotlus. Saate kontrollida, kas kood töötab tootmiskeskkonnas, funktsiooni saab näidata teistele programmeerijatele või tootespetsialistidele. Tõmbepäringu kallal töötades kustutatakse iga uus vana koodi praegune juurutamine ja uue koodi uus juurutus võetakse kasutusele. Kui ühendasite tõmbamistaotluse põhiharuga, võib tekkida küsimusi. Te ei vaja enam funktsiooniharu, kuid Kubernetese ressursid on endiselt klastris.

Lisateavet funktsioonide harude kohta

Üks võimalus Kubernetes funktsiooniharude loomiseks on nimeruumide kasutamine. Lühidalt näeb tootmiskonfiguratsioon välja selline:

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

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

Funktsiooniharu jaoks luuakse nimeruum koos selle identifikaatoriga (näiteks tõmbepäringu number) ja mingi prefiksiga/postfiksiga (näiteks -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
...

Üldiselt ma kirjutasin Kubernetese operaator (rakendus, millel on juurdepääs klastri ressurssidele), link projektile Githubis. See eemaldab vanadesse funktsiooniharudesse kuuluvad nimeruumid. Kui kustutate Kubernetes nimeruumi, kustutatakse automaatselt ka muud selle nimeruumi ressursid.

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

Saate lugeda funktsioonide harude klastrisse juurutamise kohta siin и siin.

Motivatsioon

Vaatame tüüpilist tõmbamistaotluse elutsüklit pideva integreerimisega (continuous integration):

Anname harule uue kohustuse.
Koostamisel tehakse linterid ja/või testid.
Kubernetesi tõmbepäringu konfiguratsioonid genereeritakse käigu pealt (näiteks selle number sisestatakse valmis malli).
Rakenduse kubectl apply abil lisatakse konfiguratsioonid klastrisse (juurutamine).
Tõmbetaotlus liidetakse põhiharuga.

Tõmbepäringu kallal töötades kustutatakse iga uus kinnistamine, vana koodi praegune juurutus ja uue koodi uus juurutus. Kui aga tõmbetaotlus liidetakse põhiharuga, koostatakse ainult põhiharu. Selle tulemusena selgub, et oleme tõmbamistaotluse juba unustanud ja selle Kubernetese ressursid on endiselt klastris.

Kuidas kasutada

Installige projekt alloleva käsuga:

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

Looge järgmise sisuga fail ja installige selle kaudu kubectl apply -f:

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

Parameeter nimeruumAlamstring vajalik nimeruumide filtreerimiseks teistest nimeruumidest pärit tõmbetaotluste jaoks. Näiteks kui klastris on järgmised nimeruumid: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, siis on kandidaadid kustutamiseks habr-back-end-pr-17, habr-back-end-pr-33.

Parameeter afterDaysWithoutDeploy vaja vanade nimeruumide kustutamiseks. Näiteks kui luuakse nimeruum 3 дня 1 час tagasi ja parameeter näitab 3 дня, see nimeruum kustutatakse. See töötab ka vastupidises suunas, kui nimeruum luuakse 2 дня 23 часа tagasi ja parameeter näitab 3 дня, seda nimeruumi ei kustutata.

On veel üks parameeter, see vastutab selle eest, kui sageli skannida kõiki nimeruume ja kontrollida päevade ilma juurutamata aega - checkEveryMinutes. Vaikimisi on see võrdne 30 минутам.

Kuidas see töötab

Praktikas vajate:

laevalaadija isoleeritud keskkonnas töötamiseks.
Minikube loob kohapeal Kubernetese klastri.
kubectl — käsurea liides klastri haldamiseks.

Kubernetese klastri loomine toimub kohapeal:

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

Märkige kubectl kasuta vaikimisi kohalikku klastrit:

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

Laadige alla tootmiskeskkonna konfiguratsioonid:

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

Kuna tootmiskonfiguratsioonid on konfigureeritud kontrollima vanu nimeruume ja meie äsja loodud klastris neid pole, asendame keskkonnamuutuja IS_DEBUG edasi true. Selle väärtusega parameeter afterDaysWithoutDeploy ei võeta arvesse ja nimeruume ei kontrollita juurutamiseta päevade puhul, vaid ainult alamstringi (-pr-).

Kui olete sisse lülitatud Linux:

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

Kui olete sisse lülitatud macOS:

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

Projekti installimine:

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

Kontrollitakse, kas ressurss on klastris ilmunud StaleFeatureBranch:

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

Kontrollime, kas klastris on ilmunud operaator:

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

Kui vaatate selle logisid, on see ressursside töötlemiseks valmis 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}

Paigaldame valmis fixtures (valmis konfiguratsioonid klastri ressursside modelleerimiseks) ressursi jaoks StaleFeatureBranch:

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

Konfiguratsioonid näitavad nimeruumide otsimist alamstringiga -pr- korra sisse 1 минуту.:

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

Operaator on vastanud ja on valmis nimeruume kontrollima:

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

Komplekt fixtures, mis sisaldab kahte nimeruumi (project-pr-1, project-pr-2) ja neid deployments, services, ingress, ja nii edasi:

$ 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

Kontrollime, kas kõik ülaltoodud ressursid on edukalt loodud:

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

Kuna me kaasasime debug, nimeruumid project-pr-1 и project-pr-2, seetõttu tuleb kõik muud ressursid parameetrit arvesse võtmata kohe kustutada afterDaysWithoutDeploy. Seda saab näha operaatori logides:

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

Kui kontrollite ressursside saadavust, on need olekus Terminating (kustutamisprotsess) või juba kustutatud (käsu väljund on tühi).

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

Saate loomisprotsessi korrata fixtures mitu korda ja veenduge, et need eemaldatakse minuti jooksul.

Alternatiivid

Mida saab teha klastris töötava operaatori asemel? On mitmeid lähenemisviise, kõik need on ebatäiuslikud (ja nende puudused on subjektiivsed) ja igaüks otsustab ise, mis on konkreetse projekti jaoks parim:

Funktsiooniharu kustutamine põhiharu pideva integreerimise käigus.
- Selleks peate teadma, milline tõmbetaotlus on seotud koostatava kohustusega. Kuna funktsiooniharu nimeruum sisaldab tõmbepäringu identifikaatorit – selle numbrit või haru nime, siis tuleb identifikaator commit’is alati määrata.
- Põhiharu ehitamine ebaõnnestub. Näiteks on teil järgmised etapid: laadige projekt alla, käivitage testid, koostage projekt, looge väljalase, saatke teatised, tühjendage viimase tõmbamistaotluse funktsiooniharu. Kui koostamine teatise saatmisel nurjub, peate kõik klastri ressursid käsitsi kustutama.
- Ilma õige kontekstita pole põhiehituses funktsiooniharude kustutamine ilmne.
Veebihaagide kasutamine (näide).
- See ei pruugi olla teie lähenemine. Näiteks sisse Jenkins, ainult ühte tüüpi konveier toetab võimalust salvestada selle konfiguratsioonid lähtekoodi. Veebihaake kasutades peate nende töötlemiseks kirjutama oma skripti. See skript tuleb paigutada Jenkinsi liidesesse, mida on raske hooldada.
Kirjutage Cronjob ja lisage Kubernetese klaster.
- Aja kulutamine kirjutamisele ja toele.
- Operaator töötab juba sarnases stiilis, on dokumenteeritud ja toetatud.

Täname teid tähelepanu eest artiklile. Link projektile Githubis.

Allikas: www.habr.com

Vananenud funktsiooniharu eemaldamine Kubernetese klastris

Lisateavet funktsioonide harude kohta

Motivatsioon

Kuidas kasutada

Kuidas see töötab

Alternatiivid

Lisa kommentaar Tühista vastus