ProHoster > Blog > Ma'muriyat > Kubernetes klasteridagi eskirgan xususiyat filialini olib tashlash

Kubernetes klasteridagi eskirgan xususiyat filialini olib tashlash

Kubernetes klasteridagi eskirgan xususiyat filialini olib tashlash

Salom! Xususiyat bo'limi (aka deploy preview, review app) - bu nafaqat asosiy filial o'rnatiladi, balki noyob URL manziliga har bir tortib olish so'rovi ham amalga oshiriladi. Kod ishlab chiqarish muhitida ishlayotganligini tekshirishingiz mumkin; xususiyat boshqa dasturchilar yoki mahsulot mutaxassislariga ko'rsatilishi mumkin. Siz tortib olish so'rovida ishlayotganingizda, eski kod uchun har bir yangi joriy tarqatish o'chiriladi va yangi kod uchun yangi tarqatish chiqariladi. O'chirish so'rovini asosiy filialga birlashtirganda savollar paydo bo'lishi mumkin. Sizga endi xususiyat bo'limi kerak emas, lekin Kubernetes resurslari hali ham klasterda.

Xususiyat filiallari haqida ko'proq

Kubernetes-da xususiyat filiallarini yaratishning bir usuli nomlar bo'shliqlaridan foydalanishdir. Qisqacha aytganda, ishlab chiqarish konfiguratsiyasi quyidagicha ko'rinadi:

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

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

Xususiyat bo'limi uchun nom maydoni uning identifikatori (masalan, tortish so'rovi raqami) va qandaydir prefiks/postfiks (masalan, -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
...

Umuman olganda, men yozdim Kubernetes operatori (klaster resurslariga kirish huquqiga ega ilova), Github-dagi loyihaga havola. U eski xususiyat shoxlariga tegishli nom bo'shliqlarini olib tashlaydi. Kubernetes-da, agar siz nom maydonini o'chirsangiz, ushbu nom maydonidagi boshqa resurslar ham avtomatik ravishda o'chiriladi.

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

Xususiyat shoxlarini klasterga qanday kiritish haqida o'qishingiz mumkin shu yerda ΠΈ shu yerda.

Motivatsiya

Keling, doimiy integratsiya bilan odatiy tortishish so'rovining hayot aylanishini ko'rib chiqaylik (continuous integration):

  1. Biz filialga yangi majburiyatni topshiramiz.
  2. Qurilishda linterlar va/yoki sinovlar o'tkaziladi.
  3. Kubernetes pull so'rovi konfiguratsiyasi tezda yaratiladi (masalan, uning raqami tayyor shablonga kiritilgan).
  4. kubectl application dan foydalanib, konfiguratsiyalar klasterga qo'shiladi (tartibga solish).
  5. Pull so'rovi asosiy filialga birlashtiriladi.

Siz tortib olish so'rovida ishlayotganingizda, eski kod uchun har bir yangi joriy tarqatish o'chiriladi va yangi kod uchun yangi tarqatish chiqariladi. Biroq, tortish so'rovi asosiy filialga birlashtirilganda, faqat asosiy filial quriladi. Natijada, biz tortishish so'rovini allaqachon unutganimiz va uning Kubernetes resurslari hali ham klasterda ekanligi ma'lum bo'ldi.

Qanday foydalanish kerak

Loyihani quyidagi buyruq bilan o'rnating:

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

Quyidagi tarkibga ega fayl yarating va orqali o'rnating kubectl apply -f:

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

Parametr namespaceSubstring boshqa nom maydonlaridan tortib olish so'rovlari uchun nom maydonlarini filtrlash uchun kerak. Misol uchun, agar klasterda quyidagi nomlar bo'shliqlari bo'lsa: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, keyin o'chirish uchun nomzodlar bo'ladi habr-back-end-pr-17, habr-back-end-pr-33.

Parametr afterDaysWithoutDeploy eski nom maydonlarini o'chirish uchun kerak. Misol uchun, agar nom maydoni yaratilgan bo'lsa 3 дня 1 час orqaga, va parametr ko'rsatadi 3 дня, bu nom maydoni o'chiriladi. Agar nomlar maydoni yaratilgan bo'lsa, u teskari yo'nalishda ham ishlaydi 2 дня 23 часа orqaga, va parametr ko'rsatadi 3 дня, bu nom maydoni o'chirilmaydi.

Yana bir parametr bor, u barcha nom maydonlarini qanchalik tez-tez skanerlash va joylashtirmasdan kunlarni tekshirish uchun javobgardir - Har daqiqani tekshiring. Odatiy bo'lib, u tengdir 30 ΠΌΠΈΠ½ΡƒΡ‚Π°ΠΌ.

U qanday ishlaydi

Amalda, sizga kerak bo'ladi:

  1. Docker izolyatsiya qilingan muhitda ishlash uchun.
  2. Minikube mahalliy darajada Kubernetes klasterini ko'taradi.
  3. kubectl β€” klasterni boshqarish uchun buyruq qatori interfeysi.

Biz mahalliy darajada Kubernetes klasterini yaratamiz:

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

Belgilash kubectl sukut bo'yicha mahalliy klasterdan foydalaning:

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

Ishlab chiqarish muhiti uchun konfiguratsiyalarni yuklab oling:

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

Ishlab chiqarish konfiguratsiyasi eski nom maydonlarini tekshirish uchun sozlangan va bizning yangi tashkil etilgan klasterimizda ular mavjud emasligi sababli, biz muhit oΚ»zgaruvchisini almashtiramiz. IS_DEBUG haqida true. Ushbu qiymat bilan parametr afterDaysWithoutDeploy e'tiborga olinmaydi va nomlar bo'shliqlari joylashtirilmasdan kunlar davomida tekshirilmaydi, faqat pastki qatorning paydo bo'lishi uchun (-pr-).

Agar siz yoqilgan bo'lsangiz Linux:

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

Agar siz yoqilgan bo'lsangiz macOS:

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

Loyihani o'rnatish:

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

Klasterda resurs paydo bo'lganligini tekshirish StaleFeatureBranch:

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

Klasterda operator paydo bo'lganligini tekshiramiz:

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

Agar siz uning jurnallariga qarasangiz, u resurslarni qayta ishlashga tayyor 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}

Biz tayyor holda o'rnatamiz fixtures (klaster resurslarini modellashtirish uchun tayyor konfiguratsiyalar) resurs uchun StaleFeatureBranch:

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

Konfiguratsiyalar pastki qatorli nomlar bo'shliqlarini qidirishni bildiradi -pr- bir marta kirib 1 ΠΌΠΈΠ½ΡƒΡ‚Ρƒ.:

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

Operator javob berdi va nom bo'shliqlarini tekshirishga tayyor:

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

O'rnatish fixtures, ikkita nom maydonini o'z ichiga oladi (project-pr-1, project-pr-2) va ular deployments, services, ingress, va hokazo:

$ 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

Yuqoridagi barcha resurslar muvaffaqiyatli yaratilganligini tekshiramiz:

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

Biz kiritganimizdan beri debug, nom maydonlari project-pr-1 ΠΈ project-pr-2, shuning uchun boshqa barcha resurslar parametrni hisobga olmasdan darhol o'chirilishi kerak bo'ladi afterDaysWithoutDeploy. Buni operator jurnallarida ko'rish mumkin:

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

Agar siz resurslarning mavjudligini tekshirsangiz, ular holatida bo'ladi Terminating (o'chirish jarayoni) yoki allaqachon o'chirilgan (buyruqning chiqishi bo'sh).

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

Yaratish jarayonini takrorlashingiz mumkin fixtures bir necha marta va bir daqiqa ichida olib tashlanganligiga ishonch hosil qiling.

Shu bilan bir qatorda

Klasterda ishlaydigan operator o'rniga nima qilish mumkin? Bir nechta yondashuvlar mavjud, ularning barchasi nomukammal (va ularning kamchiliklari sub'ektivdir) va har kim ma'lum bir loyiha uchun eng yaxshisini o'zi hal qiladi:

  1. Asosiy filialning uzluksiz integratsiyalashuvi vaqtida xususiyat filialini o'chiring.

    • Buni amalga oshirish uchun siz qaysi tortishish so'rovi qurilayotgan majburiyatga tegishli ekanligini bilishingiz kerak. Xususiyat filiali nom maydonida tortish so'rovi identifikatori - uning raqami yoki filial nomi bo'lganligi sababli, identifikator har doim majburiyatda ko'rsatilishi kerak.
    • Asosiy filialni qurish muvaffaqiyatsiz tugadi. Misol uchun, sizda quyidagi bosqichlar mavjud: loyihani yuklab oling, testlarni o'tkazing, loyihani yarating, nashrni chiqaring, bildirishnomalarni yuboring, so'nggi tortishish so'rovining xususiyat bo'limini o'chiring. Agar bildirishnoma yuborishda tuzilish muvaffaqiyatsiz tugasa, klasterdagi barcha resurslarni qo'lda o'chirishingiz kerak bo'ladi.
    • Tegishli kontekstsiz, asosiy tuzilmadagi xususiyat filiallarini o'chirish aniq emas.

  2. Vebhuklardan foydalanish (misol).

    • Bu sizning yondashuvingiz bo'lmasligi mumkin. Masalan, in Jenkins, faqat bitta turdagi quvur liniyasi konfiguratsiyalarini manba kodida saqlash qobiliyatini qo'llab-quvvatlaydi. Webhuklardan foydalanganda ularni qayta ishlash uchun o'z skriptingizni yozishingiz kerak. Ushbu skript Jenkins interfeysiga joylashtirilishi kerak, uni saqlash qiyin.

  3. Yozing Cronjob va Kubernetes klasterini qo'shing.

    • Yozish va qo'llab-quvvatlash uchun vaqt sarflash.
    • Operator allaqachon shunga o'xshash uslubda ishlaydi, hujjatlashtirilgan va qo'llab-quvvatlanadi.

Maqolaga e'tibor berganingiz uchun tashakkur. Github-dagi loyihaga havola.

Manba: www.habr.com

a Izoh qo'shish