🥇 Tar bort den föråldrade feature branch i Kubernetes-klustret

Hej! Funktionsgren (även kallad distributionsförhandsgranskning, granskning av app) — det är när inte bara master-grenen distribueras, utan även varje pull request till en unik URL. Du kan kontrollera om koden fungerar i produktionsmiljö, och funktionen kan visas för andra programmerare eller produktchefer. Medan du arbetar i en pull request raderas den aktuella distributionen för den gamla koden med varje ny commit, och en ny distribution för den nya koden rullas ut. Frågor kan uppstå efter att du har sammanslagit din pull request till master-grenen. Funktionsgrenen behövs inte längre, men Kubernetes-resurserna finns fortfarande kvar i klustret.

Mer om funktionsgrenar

Ett av sätten att skapa funktionsgrenar i Kubernetes är att använda namnrymder. Om vi sammanfattar, ser produktionskonfigurationerna ut så här:

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

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

För funktionsgrenen skapas en namnrymd med dess identifierare (till exempel, numret på pull requesten) och någon form av prefix/suffix (till exempel, -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
...

Sammanfattningsvis, jag skrev Kubernetes Operator (en applikation som har åtkomst till klustrets resurser), länk till projektet på Github. Den tar bort namnrymder som hör till gamla funktionsgrenar. I Kubernetes, om du tar bort en namnrymd, tas andra resurser i denna namnrymd bort automatiskt.

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

För information om hur man implementerar funktionsgrenar i klustret, kan du läsa ). Ett typiskt exempel på användning: och ). Ett typiskt exempel på användning:.

Motivation

Låt oss titta på en typisk livscykel för en pull request med kontinuerlig integration (kontinuerlig integration):

Vi pushar en ny commit till grenen.
Vid bygget körs linters och/eller tester.
Kubernetes-konfigurationerna för pull requesten formuleras dynamiskt (till exempel, dess nummer sätts in i en förberedd mall).
Med hjälp av kubectl apply kommer konfigurationerna att överföras till klustret (distribuera).
Pull requesten slås samman med master-grenen.

Medan du arbetar i en pull request raderas den aktuella distributionen för den gamla koden med varje ny commit, och en ny distribution för den nya koden rullas ut. Men när pull requesten slås samman med master-grenen byggs endast master-grenen. Resultatet blir att vi har glömt pull requesten, men dess Kubernetes-resurser finns fortfarande kvar i klustret.

Hur man använder

Installera projektet med kommandot nedan:

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

Skapa en fil med följande innehåll och installera genom kubectl apply -f:

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

Parameter namespaceSubstring behövs för att filtrera namespace för pull request från andra namespace. Till exempel, om klustret har följande namespace: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, då kommer kandidaterna för borttagning att vara habr-back-end-pr-17, habr-back-end-pr-33.

Parameter afterDaysWithoutDeploy behövs för att ta bort gamla namespace. Till exempel, om namespace skapades 3 dagar 1 timme sedan, och parametern anges som 3 dagar, kommer detta namespace att tas bort. Det fungerar också tvärtom; om namespace skapades 2 dagar 23 timmar sedan, och parametern anges som 3 dagar, kommer detta namespace inte att tas bort.

Det finns en annan parameter som ansvarar för hur ofta alla namespace inspekteras och kontrolleras för dagar utan deploy — checkEveryMinutes. Som standard är den inställd på 30 minuter.

Hur det fungerar

I praktiken kommer det att behövas:

Docker för att arbeta i en isolerad miljö.
Minikube startar Kubernetes-klustret lokalt.
kubectl — kommandoradsgränssnitt för att hantera klustret.

Startar Kubernetes-klustret lokalt:

$ minikube start --vm-driver=docker
minikube v1.11.0 på Darwin 10.15.5
Använder docker-drivrutinen baserat på befintlig profil.
Startar kontrollplanet nod minikube i klustret minikube.

Ange kubectl använda det lokala klustret som standard:

$ kubectl config use-context minikube
Bytte till kontext "minikube".

Laddar ner konfigurationerna för produktionsmiljön:

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

Eftersom produktionskonfigurationerna är inställda på att kontrollera gamla namespace, och det inte finns några i vårt nyuppsatta kluster, kommer vi att byta ut miljövariabeln IS_DEBUG till true. När detta värde är inställt beaktas inte parametern och namespace kontrolleras inte för dagar utan deploy, endast för förekomsten av delsträngen ( afterDaysWithoutDeploy Om du är på-pr-).

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

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

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

Installerar projektet:

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

Kontrollerar att resursen har dykt upp i klustret

StaleFeatureBranch $ kubectl api-resources | grep stalefeaturebranches NAMN ... APIGROUP ... TYP stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch:

Kontrollerar att operatören har dykt upp i klustret:

$ kubectl get pods --namespace stale-feature-branch-operator NAMN ... STATUS ... ÅLDER stale-feature-branch-operator-6bfbfd4df8-m7sch ... Kör ... 38s

Om man kollar loggarna för det, är det redo att hantera resurser

$ 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} $ kubectl api-resources | grep stalefeaturebranches NAMN ... APIGROUP ... TYP stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch:

Installerar färdiga

fixtures armaturer (färdiga konfigurationer för resurskluster) för resursen $ kubectl api-resources | grep stalefeaturebranches NAMN ... APIGROUP ... TYP stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch:

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

I konfigurationerna anges att söka efter namespaces med delsträng -pr- varje 1 minut.:

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

Operatören reagerade och är redo att kontrollera namespaces:

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

Installera armaturer, som innehåller två namespaces (project-pr-1, project-pr-2) och deras deployment, tjänster, ingress, och så vidare:

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

Vi kontrollerar att alla resurser ovan har skapats framgångsrikt:

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

Eftersom vi har aktiverat debug, namespaces project-pr-1 och project-pr-2, måste därför alla andra resurser avlägsnas omedelbart oavsett parametern afterDaysWithoutDeploy. Detta kan ses i operatörens loggar:

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

Om du kontrollerar tillgången till resurser kommer de att vara i status Terminating (borttagningsprocess) eller redan borttagna (kommandoutdata är tomt).

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

Du kan upprepa skapelseprocessen armaturer flera gånger och se till att de tas bort inom en minut.

Alternativ

Vad kan man göra istället för en operator som arbetar i en kluster? Det finns flera tillvägagångssätt, alla är inte perfekta (och deras nackdelar är subjektiva), och varje person måste avgöra vad som passar bäst för just sitt projekt:

Att ta bort feature branch under bygget av master-grenen för kontinuerlig integration.
- För detta måste man veta vilken pull request som hör till commit'en som byggs. Eftersom feature branch-namnet innehåller identifieraren för pull request'en — dess nummer eller namnet på grenen, måste identifieraren alltid anges i commit'en.
- Byggen av master-grenar misslyckas. Till exempel, har ni följande steg: ladda ner projektet, köra tester, bygga projektet, göra en release, skicka meddelanden, rensa feature branch av den senaste pull request'en. Om bygget misslyckas vid avsändandet av meddelandet, måste ni ta bort alla resurser i klustret manuellt.
- Utan rätt sammanhang är det inte uppenbart att ta bort feature branch i master-bygget.
Använda webhookar (exempel).
- Kanske är det inte din metod. Till exempel, i Jenkins, stöder endast en typ av pipeline möjligheten att spara dess konfigurationer i källkoden. Vid användning av webhookar måste man skriva ett eget skript för deras hantering. Detta skript måste placeras i Jenkins-gränssnittet, vilket är svårt att underhålla.
Skriva Cronjob och lägga till Kubernetes-klustret.
- Tid som läggs på att skriva och underhålla.
- Operatören fungerar redan i en liknande stil, är dokumenterad och underhålls.