Уклањање застареле гране функција у Кубернетес кластеру
Здраво! Феатуре грана (тзв. преглед примене, преглед апликације) – ово је када се не примењује само главна грана, већ и сваки захтев за повлачење на јединствени УРЛ. Можете проверити да ли код ради у производном окружењу, а функција се може приказати другим програмерима или стручњацима за производе. Док радите у захтеву за повлачење, свако ново урезивање тренутног распореда за стари код се брише, а ново распоређивање за нови код се уводи. Могу се појавити питања када спојите захтев за повлачење у главну грану. Више вам није потребна грана функција, али Кубернетес ресурси су и даље у кластеру.
Више о гранама карактеристика
Један приступ прављењу грана функција у Кубернетес-у је коришћење простора имена. Укратко, производна конфигурација изгледа овако:
За грану обележја, креира се простор имена са његовим идентификатором (на пример, бројем захтева за повлачење) и неком врстом префикса/постфикса (на пример, -пр-):
Генерално, написао сам Кубернетес Оператор (апликација која има приступ ресурсима кластера), линк ка пројекту на Гитхуб-у. Уклања просторе имена који припадају старим гранама карактеристика. У Кубернетесу, ако избришете именски простор, други ресурси у том именском простору се такође аутоматски бришу.
$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h
Можете прочитати о томе како да имплементирате гране функција у кластер овде и овде.
Мотивација
Хајде да погледамо типичан животни циклус захтева за повлачење са континуираном интеграцијом (continuous integration):
Гурамо ново урезивање у грану.
На изградњи се покрећу линтери и/или тестови.
Кубернетес конфигурације захтева за повлачење се генеришу у ходу (на пример, његов број се убацује у готов шаблон).
Користећи кубецтл аппли, конфигурације се додају кластеру (деплои).
Захтев за повлачење је спојен у главну грану.
Док радите у захтеву за повлачење, свако ново урезивање тренутног распореда за стари код се брише, а ново распоређивање за нови код се уводи. Али када се захтев за повлачење споји у главну грану, биће изграђена само главна грана. Као резултат тога, испоставило се да смо већ заборавили на захтев за повлачење, а његови Кубернетес ресурси су још увек у кластеру.
Параметар намеспацеСубстринг потребно за филтрирање именских простора за захтеве за повлачење из других именских простора. На пример, ако кластер има следеће именске просторе: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, онда ће кандидати за брисање бити habr-back-end-pr-17, habr-back-end-pr-33.
Параметар афтерДаисВитхоутДеплои потребно за брисање старих именских простора. На пример, ако се креира именски простор 3 дня 1 час назад, а параметар показује 3 дня, овај простор имена ће бити избрисан. Такође ради у супротном смеру ако се креира именски простор 2 дня 23 часа назад, а параметар показује 3 дня, овај простор имена неће бити обрисан.
Постоји још један параметар, он је одговоран за колико често скенирати све именске просторе и проверавати дане без постављања - цхецкЕвериМинутес. Подразумевано је једнако 30 минутам.
кубецтл — интерфејс командне линије за управљање кластером.
Локално подижемо Кубернетес кластер:
$ 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.
Указујемо kubectl подразумевано користи локални кластер:
$ kubectl config use-context minikube
Switched to context "minikube".
Пошто су производне конфигурације конфигурисане да провере старе просторе имена, а наш новоподигнут кластер их нема, заменићемо променљиву окружења IS_DEBUG на true. Са овом вредношћу параметар afterDaysWithoutDeploy се не узима у обзир и именски простори се не проверавају данима без постављања, само за појављивање подниза (-pr-).
Ако сте на Linux:
$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml
Ако сте на macOS:
$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml
$ kubectl get pods --namespace stale-feature-branch-operator
NAME ... STATUS ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s
Ако погледате његове евиденције, спреман је за обраду ресурса StaleFeatureBranch:
Оператер је одговорио и спреман је да провери именске просторе:
$ 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"}
Сет fixtures, који садржи два именска простора (project-pr-1, project-pr-2) и они deployments, services, ingress, и тако даље:
$ 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
Проверавамо да ли су сви горенаведени ресурси успешно креирани:
$ 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
...
Пошто смо укључили debug, именски простори project-pr-1 и project-pr-2, стога ће сви остали ресурси морати одмах да се обришу без узимања у обзир параметра afterDaysWithoutDeploy. Ово се може видети у евиденцији оператера:
$ 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"}
Ако проверите доступност ресурса, они ће бити у статусу Terminating (процес брисања) или већ обрисан (излаз команде је празан).
$ 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
...
Можете поновити процес креирања fixtures неколико пута и уверите се да су уклоњени у року од једног минута.
Алтернатива
Шта може да се ради уместо оператера који ради у кластеру? Постоји неколико приступа, сви су несавршени (а њихови недостаци су субјективни) и свако одлучује за себе шта је најбоље за одређени пројекат:
Избришите грану функције током континуиране интеграције главне гране.
Да бисте то урадили, морате да знате који захтев за повлачење се односи на урезивање које се гради. Пошто простор имена гране функције садржи идентификатор захтева за извлачење – његов број или име гране, идентификатор ће увек морати да буде наведен у урезивању.
Изградња главне гране не успева. На пример, имате следеће фазе: преузмите пројекат, покрените тестове, направите пројекат, направите издање, пошаљите обавештења, обришите грану функције последњег захтева за повлачење. Ако изградња не успе приликом слања обавештења, мораћете ручно да избришете све ресурсе у кластеру.
Без одговарајућег контекста, брисање грана функција у главној верзији није очигледно.
Ово можда није ваш приступ. На пример, у јенкинс, само један тип цевовода подржава могућност чувања његових конфигурација у изворном коду. Када користите вебхоокове, потребно је да напишете сопствену скрипту да бисте их обрадили. Ова скрипта ће морати да се постави у Џенкинсов интерфејс, који је тешко одржавати.