🥇Elavult szolgáltatáság eltávolítása egy Kubernetes-fürtben

Hi! Funkció ág (más néven deploy preview, review app) – ekkor nem csak a fő ág kerül telepítésre, hanem minden lekérési kérelem egyedi URL-re is. Ellenőrizheti, hogy a kód működik-e éles környezetben, a funkciót meg lehet mutatni más programozóknak vagy termékspecialistáknak. Miközben a lekéréses kérésben dolgozik, a régi kód minden új véglegesítési aktuális központi telepítése törlődik, és az új kód új telepítése kerül bevezetésre. Kérdések merülhetnek fel, amikor egy lehívási kérelmet egyesített a fő ágba. Már nincs szüksége a szolgáltatáságra, de a Kubernetes-erőforrások továbbra is a fürtben vannak.

További információ a szolgáltatási ágakról

A Kubernetes szolgáltatáságak létrehozásának egyik módja a névterek használata. Röviden, a gyártási konfiguráció így néz ki:

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

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

Egy jellemző ághoz névtér jön létre az azonosítójával (például a lekérési kérés számával) és valamilyen előtaggal/utótaggal (például -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
...

Általában írtam Kubernetes operátor (egy olyan alkalmazás, amely hozzáfér a fürt erőforrásokhoz), link a projekthez a Githubon. Eltávolítja a régi jellemző ágakhoz tartozó névtereket. A Kubernetesben, ha töröl egy névteret, a névtér többi erőforrása is automatikusan törlődik.

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

Olvassa el, hogyan lehet a szolgáltatáságakat fürtbe implementálni itt и itt.

motiváció

Nézzünk meg egy tipikus lekérési kérés életciklust folyamatos integrációval (continuous integration):

Új kötelezettségvállalást teszünk az ágra.
Az összeállítás során lintereket és/vagy teszteket futtatnak.
A Kubernetes lekérési kérés konfigurációi menet közben jönnek létre (például a szám bekerül a kész sablonba).
A kubectl apply használatával a konfigurációk hozzáadódnak a fürthöz (telepítés).
A lehúzási kérés egyesül a fő ággal.

Miközben egy lekérési kérelmen dolgozik, minden új véglegesítés, a régi kód jelenlegi központi telepítése törlődik, és az új kód új telepítése kerül bevezetésre. De amikor egy lehívási kérelmet egyesítenek a fő ágba, csak a fő ág épül fel. Ennek eredményeként kiderül, hogy már elfelejtettük a lehívási kérést, és annak Kubernetes erőforrásai még mindig a fürtben vannak.

Hogyan kell használni

Telepítse a projektet az alábbi paranccsal:

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

Hozzon létre egy fájlt a következő tartalommal, és telepítse a következőn keresztül kubectl apply -f:

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

Paraméter namespaceSubstring szükséges a névterek szűréséhez más névterekből származó lekérési kérésekhez. Például, ha a fürt a következő névterekkel rendelkezik: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, akkor a törlésre jelöltek lesznek habr-back-end-pr-17, habr-back-end-pr-33.

Paraméter afterDaysWithoutDeploy régi névterek törléséhez szükséges. Például ha névteret hozunk létre 3 дня 1 час vissza, és a paraméter jelzi 3 дня, ez a névtér törlésre kerül. Ellenkező irányban is működik, ha létrejön a névtér 2 дня 23 часа vissza, és a paraméter jelzi 3 дня, ez a névtér nem törlődik.

Van még egy paraméter, ez felelős azért, hogy milyen gyakran kell átvizsgálni az összes névteret, és ellenőrizni, hogy nincsenek-e napok telepítés nélkül - checkEveryMinutes. Alapértelmezés szerint egyenlő 30 минутам.

Ez hogy működik

A gyakorlatban szüksége lesz:

Dokkmunkás elszigetelt környezetben végzett munkához.
Minikube Kubernetes klasztert fog létrehozni helyben.
kubectl — parancssori felület a fürtkezeléshez.

Kubernetes klasztert hozunk létre helyben:

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

jelezzük kubectl alapértelmezés szerint helyi fürt használata:

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

Konfigurációk letöltése az éles környezethez:

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

Mivel az éles konfigurációk úgy vannak beállítva, hogy ellenőrizze a régi névtereket, és az újonnan felállított fürtünk nem rendelkezik ilyenekkel, lecseréljük a környezeti változót IS_DEBUG on true. Ezzel az értékkel a paraméter afterDaysWithoutDeploy nem veszik figyelembe, és a névtereket a rendszer nem ellenőrzi a telepítés nélküli napokig, csak az alstring (-pr-).

Ha be van kapcsolva Linux:

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

Ha be van kapcsolva macOS:

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

A projekt telepítése:

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

Annak ellenőrzése, hogy egy erőforrás megjelent-e a fürtben StaleFeatureBranch:

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

Ellenőrizzük, hogy megjelent-e egy operátor a fürtben:

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

Ha megnézi a naplóit, készen áll az erőforrások feldolgozására 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}

Készen telepítjük fixtures (kész konfigurációk a fürterőforrások modellezéséhez) egy erőforráshoz StaleFeatureBranch:

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

A konfigurációk azt jelzik, hogy a névtereket részkarakterlánccal kell keresni -pr- egyszer bent 1 минуту.:

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

Az operátor válaszolt, és készen áll a névterek ellenőrzésére:

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

Készlet fixtures, amely két névteret tartalmaz (project-pr-1, project-pr-2) és ők deployments, services, ingress, stb:

$ 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

Ellenőrizzük, hogy a fenti források mindegyike sikeresen létrejött-e:

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

Mivel mi is beleértjük debug, névterek project-pr-1 и project-pr-2, ezért az összes többi erőforrást azonnal törölni kell a paraméter figyelembevétele nélkül afterDaysWithoutDeploy. Ez látható az operátori naplókban:

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

Ha ellenőrzi az erőforrások elérhetőségét, azok állapotba kerülnek Terminating (törlési folyamat) vagy már törölve (a parancskimenet üres).

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

Megismételheti a létrehozási folyamatot fixtures többször, és győződjön meg róla, hogy egy percen belül eltávolítja őket.

Alternatívák

Mit lehet tenni a klaszterben dolgozó operátor helyett? Számos megközelítés létezik, mindegyik tökéletlen (és hiányosságaik szubjektívek), és mindenki maga dönti el, mi a legjobb egy adott projekthez:

Szolgáltatás ág törlése a fő ág folyamatos integrációja során.
- Ehhez tudnia kell, hogy melyik lekérési kérelem kapcsolódik a készülő véglegesítéshez. Mivel a jellemző ág névtér tartalmazza a lekérési kérés azonosítóját - annak számát, vagy az ág nevét, az azonosítót mindig meg kell adni a véglegesítésben.
- A fő ág buildek hibásak. Például a következő lépések állnak rendelkezésére: a projekt letöltése, tesztek futtatása, a projekt felépítése, kiadás létrehozása, értesítések küldése, az utolsó lekérési kérelem szolgáltatási ágának törlése. Ha a felépítés meghiúsul az értesítés küldésekor, manuálisan kell törölnie a fürt összes erőforrását.
- Megfelelő kontextus nélkül nem nyilvánvaló a fő build szolgáltatáságainak törlése.
Webhook használata (példa).
- Lehet, hogy ez nem a te megközelítésed. Például be Jenkins, csak egy típusú folyamat támogatja a konfigurációk forráskódba mentését. Webhookok használatakor saját szkriptet kell írnia a feldolgozásukhoz. Ezt a szkriptet a Jenkins felületen kell elhelyezni, amit nehéz karbantartani.
Írni Cronjob és adjunk hozzá egy Kubernetes-fürtöt.
- Töltsön időt írásra és támogatásra.
- Az operátor már hasonló stílusban dolgozik, dokumentált és támogatott.

Köszönöm a cikkre fordított figyelmet. Link a projekthez a Githubon.

Forrás: will.com

Elavult szolgáltatáság eltávolítása egy Kubernetes-fürtből

További információ a szolgáltatási ágakról

motiváció

Hogyan kell használni

Ez hogy működik

Alternatívák

Hozzászólás Megszünteti a választ