🥇Kubernetes klasterində köhnəlmiş xüsusiyyət filialının silinməsi

Привет! Xüsusiyyət şöbəsi (aka deploy preview, review app) - bu, təkcə əsas filialın deyil, həm də unikal URL-ə hər çəkmə sorğusunun yerləşdirildiyi zamandır. Kodun istehsal mühitində işlədiyini yoxlaya bilərsiniz; xüsusiyyət digər proqramçılara və ya məhsul mütəxəssislərinə göstərilə bilər. Siz çəkmə sorğusunda işləyərkən köhnə kod üçün hər yeni öhdəliyin cari yerləşdirilməsi silinir və yeni kod üçün yeni yerləşdirmə təqdim edilir. Çəkmə sorğusunu əsas filiala birləşdirən zaman suallar yarana bilər. Artıq xüsusiyyət bölməsinə ehtiyacınız yoxdur, lakin Kubernetes resursları hələ də çoxluqdadır.

Xüsusiyyət filialları haqqında daha çox

Kubernetes-də xüsusiyyət filialları yaratmaq üçün bir yanaşma ad boşluqlarından istifadə etməkdir. Bir sözlə, istehsal konfiqurasiyası belə görünür:

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

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

Xüsusiyyət bölməsi üçün onun identifikatoru (məsələn, çəkmə sorğusu nömrəsi) və bir növ prefiks/postfiks (məsələn, -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
...

Ümumiyyətlə, mən yazdım Kubernetes Operatoru (klaster resurslarına çıxışı olan proqram), Github-da layihəyə keçid. Köhnə xüsusiyyət filiallarına aid olan ad boşluqlarını silir. Kubernetes-də ad məkanını silsəniz, həmin ad məkanındakı digər resurslar da avtomatik olaraq silinir.

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

Xüsusiyyət filiallarını klasterə necə tətbiq etmək barədə oxuya bilərsiniz burada и burada.

Motivasiya

Davamlı inteqrasiya ilə tipik çəkmə sorğusunun həyat dövrünə baxaq (continuous integration):

Filial üçün yeni bir öhdəlik götürürük.
Quraşdırmada lintrlər və/yaxud sınaqlar aparılır.
Kubernetes çəkmə sorğusu konfiqurasiyaları dərhal yaradılır (məsələn, onun nömrəsi hazır şablona daxil edilir).
kubectl tətbiqindən istifadə edərək, konfiqurasiyalar klasterə əlavə olunur (yerləşdirmə).
Çəkmə sorğusu əsas filiala birləşdirilir.

Siz çəkmə sorğusu üzərində işləyərkən, hər yeni öhdəçilik, köhnə kod üçün cari yerləşdirmə silinir və yeni kod üçün yeni yerləşdirmə yayılır. Ancaq çəkmə sorğusu əsas filiala birləşdirildikdə, yalnız master filial qurulacaq. Nəticədə məlum olur ki, biz çəkmə sorğusunu artıq unutmuşuq və onun Kubernetes resursları hələ də çoxluqdadır.

Necə istifadə

Layihəni aşağıdakı komanda ilə quraşdırın:

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

Aşağıdakı məzmunlu bir fayl yaradın və vasitəsilə quraşdırın kubectl apply -f:

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

Parametr ad sahəsiSubstring digər ad boşluqlarından çəkilmə sorğuları üçün ad boşluqlarını süzmək üçün lazımdır. Məsələn, klasterdə aşağıdakı ad boşluqları varsa: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, sonra silinməyə namizədlər olacaq habr-back-end-pr-17, habr-back-end-pr-33.

Parametr afterDaysWithoutDeploy köhnə ad boşluqlarını silmək lazımdır. Məsələn, ad sahəsi yaradılarsa 3 дня 1 час geri və parametr göstərir 3 дня, bu ad sahəsi silinəcək. O, həmçinin ad sahəsi yaradılarsa, əks istiqamətdə işləyir 2 дня 23 часа geri və parametr göstərir 3 дня, bu ad sahəsi silinməyəcək.

Daha bir parametr var, o, bütün ad boşluqlarının nə qədər tez-tez skan edilməsinə və yerləşdirmədən günlərin yoxlanılmasına cavabdehdir - hər dəqiqə yoxlayın. Varsayılan olaraq bərabərdir 30 минутам.

Bu necə işləyir

Praktikada sizə lazım olacaq:

yükvuran təcrid olunmuş mühitdə işləmək üçün.
Minikube yerli olaraq Kubernetes klasterini qaldıracaq.
kubectl — klasterin idarə edilməsi üçün komanda xətti interfeysi.

Yerli olaraq Kubernetes klasterini qaldırırıq:

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

Göstərin kubectl standart olaraq yerli klasterdən istifadə edin:

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

İstehsal mühiti üçün konfiqurasiyaları endirin:

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

İstehsal konfiqurasiyaları köhnə ad boşluqlarını yoxlamaq üçün konfiqurasiya edildiyindən və yeni yaradılmış klasterimizdə olmadığından, mühit dəyişənini əvəz edəcəyik. IS_DEBUG haqqında true. Bu dəyərlə parametr afterDaysWithoutDeploy nəzərə alınmır və ad boşluqları yerləşdirmədən günlər ərzində yoxlanılmır, yalnız alt sətirin baş verməsi üçün (-pr-).

Əgər varsa Linux:

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

Əgər varsa macOS:

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

Layihənin quraşdırılması:

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

Klasterdə resursun görünməsi yoxlanılır StaleFeatureBranch:

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

Klasterdə operatorun göründüyünü yoxlayırıq:

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

Onun qeydlərinə baxsanız, o, resursları emal etməyə hazırdır 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}

Hazır quraşdırırıq fixtures resurs üçün (klaster resurslarının modelləşdirilməsi üçün hazır konfiqurasiyalar). StaleFeatureBranch:

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

Konfiqurasiyalar alt sətirlə ad boşluqlarının axtarılmasını göstərir -pr- bir dəfə 1 минуту.:

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

Operator cavab verdi və ad boşluqlarını yoxlamağa hazırdır:

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

Təyin etmək fixtures, iki ad boşluğunu ehtiva edir (project-pr-1, project-pr-2) və onlar deployments, services, ingress, və s:

$ 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

Yuxarıdakı bütün resursların uğurla yaradıldığını yoxlayırıq:

$ 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 daxil etdiyimiz üçün debug, ad boşluqları project-pr-1 и project-pr-2, buna görə də bütün digər resurslar parametr nəzərə alınmadan dərhal silinməli olacaq afterDaysWithoutDeploy. Bunu operator qeydlərində görmək olar:

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

Resursların mövcudluğunu yoxlasanız, onlar statusda olacaqlar Terminating (silmə prosesi) və ya artıq silinmişdir (əmr çıxışı boşdur).

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

Yaratma prosesini təkrarlaya bilərsiniz fixtures bir neçə dəfə və bir dəqiqə ərzində çıxarıldıqlarına əmin olun.

Alternativlər

Klasterdə işləyən operatorun yerinə nə etmək olar? Bir neçə yanaşma var, hamısı qeyri-kamildir (və çatışmazlıqları subyektivdir) və hər kəs müəyyən bir layihə üçün ən yaxşısını özü üçün qərar verir:

Əsas filialın davamlı inteqrasiya qurması zamanı xüsusiyyət filialını silin.
- Bunu etmək üçün, hansı çəkmə sorğusunun tikilməkdə olan öhdəliyə aid olduğunu bilməlisiniz. Xüsusiyyət filialının ad məkanında çəkmə sorğusu identifikatoru - onun nömrəsi və ya filialın adı olduğundan, identifikator həmişə tapşırıqda göstərilməlidir.
- Master filial qurmaları uğursuz olur. Məsələn, aşağıdakı mərhələləriniz var: layihəni yükləyin, testləri həyata keçirin, layihəni qurun, buraxılış hazırlayın, bildirişlər göndərin, son çəkmə sorğusunun xüsusiyyət bölməsini təmizləyin. Bildiriş göndərərkən qurma uğursuz olarsa, klasterdəki bütün resursları əl ilə silməli olacaqsınız.
- Müvafiq kontekst olmadan, əsas quruluşda xüsusiyyət filiallarının silinməsi aydın deyil.
Veb kancalardan istifadə (misal).
- Bu sizin yanaşmanız olmaya bilər. Məsələn, in Jenkins, yalnız bir növ boru kəməri konfiqurasiyalarını mənbə kodunda saxlamaq qabiliyyətini dəstəkləyir. Webhooks istifadə edərkən, onları emal etmək üçün öz skriptinizi yazmalısınız. Bu skript saxlamaq çətin olan Jenkins interfeysinə yerləşdirilməli olacaq.
Yaz Cronjob və Kubernetes klasterini əlavə edin.
- Yazmağa və dəstəyə vaxt ayırmaq.
- Operator artıq oxşar üslubda işləyir, sənədləşdirilir və dəstəklənir.

Məqaləyə diqqətinizə görə təşəkkür edirik. Github-da layihəyə keçid.

Mənbə: www.habr.com

Kubernetes klasterində köhnəlmiş xüsusiyyət filialını silin

Xüsusiyyət filialları haqqında daha çox

Motivasiya

Necə istifadə

Bu necə işləyir

Alternativlər

Добавить комментарий Cavab ləğv