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

Отстранување на застарена гранка на функции во кластерот Kubernetes

Отстранување на застарена гранка на функции во кластерот Kubernetes

Здраво! Филијала на карактеристики (познато како преглед на распоредување, апликација за прегледување) - ова е кога не е распоредена само главната гранка, туку и секое барање за повлекување до единствена URL-адреса. Може да проверите дали кодот работи во производствена средина; функцијата може да се прикаже на други програмери или специјалисти за производи. Додека работите во барање за повлекување, секое ново тековно распоредување на commit за стариот код се брише, а новото распоредување за новиот код се пушта. Може да се појават прашања кога сте споиле барање за повлекување во главната гранка. Веќе не ви е потребна гранката на функции, но ресурсите на Kubernetes сè уште се во кластерот.

Повеќе за гранките на функции

Еден пристап за правење гранки на карактеристики во Кубернетес е да се користат именски простори. Накратко, производната конфигурација изгледа вака:

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

Во принцип, напишав Оператор Кубернетес (апликација која има пристап до ресурсите на кластерот), линк до проектот на Github. Ги отстранува именските простори што припаѓаат на старите гранки на карактеристики. Во Kubernetes, ако избришете именски простор, другите ресурси во тој именски простор исто така се бришат автоматски.

$ 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. Ние туркаме нов commit на гранката.
  2. На конструкцијата, се извршуваат линтери и/или тестови.
  3. Конфигурациите за барање за повлекување на Kubernetes се генерираат веднаш (на пример, неговиот број е вметнат во готовиот шаблон).
  4. Со примена на kubectl, конфигурациите се додаваат во кластерот (распоредување).
  5. Барањето за повлекување е споено во главната гранка.

Додека работите во барање за повлекување, секое ново тековно распоредување на commit за стариот код се брише, а новото распоредување за новиот код се пушта. Но, кога барањето за повлекување ќе се спои во главната гранка, ќе се изгради само главната гранка. Како резултат на тоа, излегува дека веќе сме заборавиле на барањето за повлекување, а неговите ресурси на Kubernetes сè уште се во кластерот.

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

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

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

Параметар afterDaysWithoutDeploy потребни за бришење стари именски простори. На пример, ако се создаде именски простор 3 дня 1 час назад, и параметарот покажува 3 дня, овој именски простор ќе биде избришан. Работи и во спротивна насока ако се создаде именскиот простор 2 дня 23 часа назад, и параметарот покажува 3 дня, овој именски простор нема да се избрише.

Има уште еден параметар, тој е одговорен за тоа колку често се скенираат сите именски простори и се проверуваат деновите без распоредување - проверете гоEveryMinutes. Стандардно е еднакво 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. Да се ​​напише Кроњоб и додадете кластер Kubernetes.

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

Ви благодариме за вниманието на статијата. Линк до проектот на Github.

Извор: www.habr.com

Додадете коментар