🥇 Vanhentuneen ominaisuushaaran poistaminen Kubernetes-klusterista

Hi! Ominaisuushaara (alias käyttöönoton esikatselu, tarkistussovellus) – Tällöin ei vain oteta käyttöön päähaaraa, vaan myös jokainen vetopyyntö yksilölliseen URL-osoitteeseen. Voit tarkistaa, toimiiko koodi tuotantoympäristössä, ominaisuus voidaan näyttää muille ohjelmoijille tai tuoteasiantuntijoille. Kun työskentelet vetopyynnön parissa, jokainen vanhan koodin uusi vahvistus nykyinen käyttöönotto poistetaan ja uuden koodin uusi käyttöönotto otetaan käyttöön. Kysymyksiä voi syntyä, kun yhdistät vetopyynnön päähaaraan. Et enää tarvitse ominaisuushaaraa, mutta Kubernetes-resurssit ovat edelleen klusterissa.

Lisätietoja ominaisuushaaroista

Yksi tapa tehdä ominaisuushaaroja Kubernetesissa on käyttää nimiavaruuksia. Lyhyesti sanottuna tuotantokokoonpano näyttää tältä:

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

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

Ominaisuushaaralle luodaan nimiavaruus sen tunnisteella (esimerkiksi vetopyynnön numerolla) ja jonkinlaisella etuliitteellä/jälkiliitteellä (esim. -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
...

Yleisesti ottaen kirjoitin Kubernetes-operaattori (sovellus, jolla on pääsy klusteriresursseihin), linkki projektiin Githubissa. Se poistaa nimiavaruudet, jotka kuuluvat vanhoihin ominaisuushaaroihin. Jos poistat Kubernetesissa nimitilan, myös muut nimitilan resurssit poistetaan automaattisesti.

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

Voit lukea ominaisuushaarojen toteuttamisesta klusteriksi täällä и täällä.

Motivaatio

Tarkastellaan tyypillistä vetopyynnön elinkaarta jatkuvalla integraatiolla (continuous integration):

Teemme haaralle uuden sitoumuksen.
Rakennuksessa ajetaan linterit ja/tai testit.
Kubernetesin vetopyyntökokoonpanot luodaan lennossa (esimerkiksi sen numero lisätään valmiiseen malliin).
Kubectl apply -sovelluksella kokoonpanot lisätään klusteriin (deploy).
Vetopyyntö yhdistetään päähaaraan.

Kun työskentelet vetopyynnön parissa, jokainen vanhan koodin uusi vahvistus nykyinen käyttöönotto poistetaan ja uuden koodin uusi käyttöönotto otetaan käyttöön. Mutta kun vetopyyntö yhdistetään päähaaraan, vain päähaara rakennetaan. Tämän seurauksena käy ilmi, että olemme jo unohtaneet pull-pyynnön ja sen Kubernetes-resurssit ovat edelleen klusterissa.

Kuinka käyttää

Asenna projekti alla olevalla komennolla:

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

Luo tiedosto seuraavalla sisällöllä ja asenna se kautta kubectl apply -f:

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

Parametri nimitilaSubstring tarvitaan nimiavaruuksien suodattamiseen muista nimiavaruuksista tuleville vetopyynnöille. Jos klusterilla on esimerkiksi seuraavat nimitilat: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, poistettavia ehdokkaita ovat habr-back-end-pr-17, habr-back-end-pr-33.

Parametri afterDaysWithoutDeploy tarvitaan vanhojen nimitilojen poistamiseen. Jos esimerkiksi luodaan nimiavaruus 3 дня 1 час takaisin, ja parametri osoittaa 3 дня, tämä nimiavaruus poistetaan. Se toimii myös päinvastaiseen suuntaan, jos nimiavaruus luodaan 2 дня 23 часа takaisin, ja parametri osoittaa 3 дня, tätä nimiavaruutta ei poisteta.

On vielä yksi parametri, se vastaa siitä, kuinka usein kaikki nimitilat tarkistetaan ja päiviä ilman käyttöönottoa - tarkista EveryMinutes. Oletuksena se on yhtä suuri 30 минутам.

Kuinka tämä toimii

Käytännössä tarvitset:

Satamatyöläinen työskentelyyn eristetyssä ympäristössä.
Minikube nostaa Kubernetes-klusterin paikallisesti.
kubectl — komentoriviliittymä klusterin hallintaan.

Kasvatamme Kubernetes-klusterin paikallisesti:

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

Osoitamme kubectl käytä paikallista klusteria oletuksena:

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

Lataa tuotantoympäristön kokoonpanot:

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

Koska tuotantokokoonpanot on määritetty tarkistamaan vanhat nimitilat, eikä äskettäin nostetussa klusterissamme ole niitä, korvaamme ympäristömuuttujan IS_DEBUG päälle true. Tällä arvolla parametri afterDaysWithoutDeploy ei oteta huomioon ja nimiavaruuksia ei tarkisteta päivien aikana ilman käyttöönottoa, vain alimerkkijonon (-pr-).

Jos olet päällä Linux:

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

Jos olet päällä macOS:

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

Projektin asennus:

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

Tarkistetaan, että klusteriin on ilmestynyt resurssi StaleFeatureBranch:

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

Tarkistamme, että klusteriin on ilmestynyt operaattori:

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

Jos katsot sen lokeja, se on valmis käsittelemään resursseja 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}

Asennamme valmiina fixtures (valmiit kokoonpanot klusterin resurssien mallintamiseen) resurssille StaleFeatureBranch:

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

Määritykset osoittavat nimiavaruuksien etsimisen alimerkkijonon avulla -pr- kerran sisään 1 минуту.:

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

Operaattori on vastannut ja on valmis tarkistamaan nimiavaruudet:

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

Asettaa fixtures, joka sisältää kaksi nimiavaruutta (project-pr-1, project-pr-2) ja heidät deployments, services, ingress, ja niin edelleen:

$ 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

Tarkistamme, että kaikki yllä olevat resurssit on luotu onnistuneesti:

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

Koska me sisällytimme debug, nimiavaruudet project-pr-1 и project-pr-2, joten kaikki muut resurssit on poistettava välittömästi ottamatta huomioon parametria afterDaysWithoutDeploy. Tämä näkyy operaattorilokeissa:

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

Jos tarkistat resurssien saatavuuden, ne ovat tilassa Terminating (poistoprosessi) tai jo poistettu (komennon lähtö on tyhjä).

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

Voit toistaa luomisprosessin fixtures useita kertoja ja varmista, että ne poistetaan minuutin kuluessa.

vaihtoehtoja

Mitä voidaan tehdä klusterissa työskentelevän operaattorin sijaan? On olemassa useita lähestymistapoja, ne kaikki ovat epätäydellisiä (ja niiden puutteet ovat subjektiivisia), ja jokainen päättää itse, mikä on parasta tietylle projektille:

Poista ominaisuushaara päähaaran jatkuvan integroinnin aikana.
- Tätä varten sinun on tiedettävä, mikä vetopyyntö liittyy rakennettavaan sitoumukseen. Koska ominaisuushaaran nimiavaruus sisältää vetopyynnön tunnisteen - sen numeron tai haaran nimen, tunniste on aina määritettävä toimituksessa.
- Päähaaran rakentaminen epäonnistuu. Sinulla on esimerkiksi seuraavat vaiheet: lataa projekti, suorita testit, rakenna projekti, tee julkaisu, lähetä ilmoituksia, tyhjennä ominaisuushaara viimeisestä vetopyynnöstä. Jos koontiversio epäonnistuu ilmoitusta lähetettäessä, sinun on poistettava kaikki klusterin resurssit manuaalisesti.
- Ilman asianmukaista kontekstia ominaisuushaarojen poistaminen pääkoontiversiosta ei ole ilmeistä.
Webhookien käyttäminen (esimerkki).
- Tämä ei ehkä ole sinun lähestymistapasi. Esimerkiksi sisään Jenkins, vain yksi liukuhihnatyyppi tukee määritysten tallentamista lähdekoodiin. Kun käytät webhookeja, sinun on kirjoitettava oma skripti käsitelläksesi niitä. Tämä skripti on sijoitettava Jenkinsin käyttöliittymään, jota on vaikea ylläpitää.
Kirjoittaa Cronjob ja lisää Kubernetes-klusteri.
- Käytä aikaa kirjoittamiseen ja tukeen.
- Operaattori toimii jo vastaavalla tyylillä, on dokumentoitu ja tuettu.

Kiitos huomiostasi artikkeliin. Linkki projektiin Githubissa.

Lähde: will.com

Vanhentuneen ominaisuushaaran poistaminen Kubernetes-klusterista

Lisätietoja ominaisuushaaroista

Motivaatio

Kuinka käyttää

Kuinka tämä toimii

vaihtoehtoja

Lisää kommentti Peruuta vastaus