Elavult szolgáltatáság eltávolítása egy Kubernetes-fürtből
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:
Á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.
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.
$ 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".
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
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:
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.
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.