ProHoster > блог > Администрација > Уклањање застареле гране функција у Кубернетес кластеру

Уклањање застареле гране функција у Кубернетес кластеру

Уклањање застареле гране функција у Кубернетес кластеру

Здраво! Феатуре грана (тзв. преглед примене, преглед апликације) – ово је када се не примењује само главна грана, већ и сваки захтев за повлачење на јединствени УРЛ. Можете проверити да ли код ради у производном окружењу, а функција се може приказати другим програмерима или стручњацима за производе. Док радите у захтеву за повлачење, свако ново урезивање тренутног распореда за стари код се брише, а ново распоређивање за нови код се уводи. Могу се појавити питања када спојите захтев за повлачење у главну грану. Више вам није потребна грана функција, али Кубернетес ресурси су и даље у кластеру.

Више о гранама карактеристика

Један приступ прављењу грана функција у Кубернетес-у је коришћење простора имена. Укратко, производна конфигурација изгледа овако:

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

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

За грану обележја, креира се простор имена са његовим идентификатором (на пример, бројем захтева за повлачење) и неком врстом префикса/постфикса (на пример, -пр-):

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

Генерално, написао сам Кубернетес Оператор (апликација која има приступ ресурсима кластера), линк ка пројекту на Гитхуб-у. Уклања просторе имена који припадају старим гранама карактеристика. У Кубернетесу, ако избришете именски простор, други ресурси у том именском простору се такође аутоматски бришу.

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

Можете прочитати о томе како да имплементирате гране функција у кластер овде и овде.

Мотивација

Хајде да погледамо типичан животни циклус захтева за повлачење са континуираном интеграцијом (continuous integration):

  1. Гурамо ново урезивање у грану.
  2. На изградњи се покрећу линтери и/или тестови.
  3. Кубернетес конфигурације захтева за повлачење се генеришу у ходу (на пример, његов број се убацује у готов шаблон).
  4. Користећи кубецтл аппли, конфигурације се додају кластеру (деплои).
  5. Захтев за повлачење је спојен у главну грану.

Док радите у захтеву за повлачење, свако ново урезивање тренутног распореда за стари код се брише, а ново распоређивање за нови код се уводи. Али када се захтев за повлачење споји у главну грану, биће изграђена само главна грана. Као резултат тога, испоставило се да смо већ заборавили на захтев за повлачење, а његови Кубернетес ресурси су још увек у кластеру.

Како користити

Инсталирајте пројекат помоћу наредбе испод:

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

Направите датотеку са следећим садржајем и инсталирајте преко kubectl apply -f:

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

Параметар намеспацеСубстринг потребно за филтрирање именских простора за захтеве за повлачење из других именских простора. На пример, ако кластер има следеће именске просторе: 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 минутам.

Како ово ради

У пракси ће вам требати:

  1. лучки радник за рад у изолованом окружењу.
  2. Миникубе ће подићи Кубернетес кластер локално.
  3. кубецтл — интерфејс командне линије за управљање кластером.

Локално подижемо Кубернетес кластер:

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

Преузмите конфигурације за производно окружење:

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

Пошто су производне конфигурације конфигурисане да провере старе просторе имена, а наш новоподигнут кластер их нема, заменићемо променљиву окружења 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 apply -f stale-feature-branch-production-configs.yml

Провера да ли се ресурс појавио у кластеру StaleFeatureBranch:

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

Проверавамо да ли се у кластеру појавио оператор:

$ 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":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

Монтирамо готове fixtures (готове конфигурације за моделирање ресурса кластера) за ресурс StaleFeatureBranch:

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

Конфигурације указују на тражење простора имена са поднизом -pr- једном сваки 1 минуту.:

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

Оператер је одговорио и спреман је да провери именске просторе:

$ 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 неколико пута и уверите се да су уклоњени у року од једног минута.

Алтернатива

Шта може да се ради уместо оператера који ради у кластеру? Постоји неколико приступа, сви су несавршени (а њихови недостаци су субјективни) и свако одлучује за себе шта је најбоље за одређени пројекат:

  1. Избришите грану функције током континуиране интеграције главне гране.

    • Да бисте то урадили, морате да знате који захтев за повлачење се односи на урезивање које се гради. Пошто простор имена гране функције садржи идентификатор захтева за извлачење – његов број или име гране, идентификатор ће увек морати да буде наведен у урезивању.
    • Изградња главне гране не успева. На пример, имате следеће фазе: преузмите пројекат, покрените тестове, направите пројекат, направите издање, пошаљите обавештења, обришите грану функције последњег захтева за повлачење. Ако изградња не успе приликом слања обавештења, мораћете ручно да избришете све ресурсе у кластеру.
    • Без одговарајућег контекста, брисање грана функција у главној верзији није очигледно.

  2. Коришћење веб-хукова (пример).

    • Ово можда није ваш приступ. На пример, у јенкинс, само један тип цевовода подржава могућност чувања његових конфигурација у изворном коду. Када користите вебхоокове, потребно је да напишете сопствену скрипту да бисте их обрадили. Ова скрипта ће морати да се постави у Џенкинсов интерфејс, који је тешко одржавати.

  3. Да напишем Цроњоб и додајте Кубернетес кластер.

    • Трошење времена на писање и подршку.
    • Оператер већ ради у сличном стилу, документован је и подржан.

Хвала вам на пажњи према чланку. Веза до пројекта на Гитхуб-у.

Извор: ввв.хабр.цом

Купите поуздан хостинг за сајтове са ДДоС заштитом, ВПС ВДС сервере 🔥 Купите поуздан веб хостинг са DDoS заштитом, VPS VDS сервере | ProHoster