ProHoster > Օրագիր > Վարչակազմը > Kubernetes կլաստերի հնացած գործառույթի ճյուղի հեռացում

Kubernetes կլաստերի հնացած գործառույթի ճյուղի հեռացում

Kubernetes կլաստերի հնացած գործառույթի ճյուղի հեռացում

Hi! Հատկանիշի մասնաճյուղ (aka deploy նախադիտում, վերանայման հավելված) - սա այն դեպքում, երբ տեղակայվում է ոչ միայն հիմնական մասնաճյուղը, այլև յուրաքանչյուր ձգման հարցում դեպի եզակի URL: Դուք կարող եք ստուգել, ​​թե արդյոք կոդը աշխատում է արտադրական միջավայրում, հատկանիշը կարող է ցուցադրվել այլ ծրագրավորողների կամ արտադրանքի մասնագետների։ Մինչ դուք աշխատում եք pull-ի հարցումով, յուրաքանչյուր նոր commit ընթացիկ տեղակայում հին կոդի համար ջնջվում է, և նոր տեղակայումը նոր կոդի համար դուրս է գրվում: Հարցեր կարող են առաջանալ, երբ դուք միավորում եք pull-ի հարցումը հիմնական մասնաճյուղում: Ձեզ այլևս պետք չէ հատկանիշի ճյուղը, սակայն Kubernetes-ի ռեսուրսները դեռ կլաստերի մեջ են:

Մանրամասն խաղարկային ճյուղերի մասին

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

Ընդհանրապես գրել եմ Kubernetes օպերատոր (հավելված, որը հասանելի է կլաստերի ռեսուրսներին), հղում նախագծին 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. Մենք նոր պարտավորություն ենք դնում մասնաճյուղ:
  2. Կառուցման վրա կատարվում են լինտերներ և/կամ թեստեր:
  3. Kubernetes-ի ձգման հարցումների կոնֆիգուրացիաները ստեղծվում են անմիջապես (օրինակ, դրա համարը տեղադրվում է պատրաստի ձևանմուշում):
  4. Օգտագործելով kubectl application-ը, կոնֆիգուրացիաները ավելացվում են կլաստերին (տեղակայում):
  5. Ձգման հարցումը միաձուլվում է գլխավոր մասնաճյուղին:

Մինչ դուք աշխատում եք ձգման հարցումի վրա, յուրաքանչյուր նոր հանձնում, հին կոդի ընթացիկ տեղակայումը ջնջվում է, իսկ նոր կոդի նոր տեղակայումը դուրս է գրվում: Բայց երբ ձգման հարցումը միաձուլվում է գլխավոր ճյուղին, կկառուցվի միայն գլխավոր ճյուղը: Արդյունքում պարզվում է, որ մենք արդեն մոռացել ենք ձգման հարցումը, և նրա 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

Parameter namespace Ենթատող անհրաժեշտ է անվանատարածքները զտել այլ անվանատարածքներից քաշելու հարցումների համար: Օրինակ, եթե կլաստերը ունի հետևյալ անունների տարածքները. 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.

Parameter afterDaysWithoutDeploy անհրաժեշտ է հին անվանատարածքները ջնջելու համար: Օրինակ, եթե ստեղծվել է անվանատարածք 3 дня 1 час ետ, և պարամետրը ցույց է տալիս 3 дня, այս անվանատարածքը կջնջվի: Այն նաև աշխատում է հակառակ ուղղությամբ, եթե ստեղծվում է անվանատարածք 2 дня 23 часа ետ, և պարամետրը ցույց է տալիս 3 дня, այս անվանատարածքը չի ջնջվի:

Կա ևս մեկ պարամետր, այն պատասխանատու է այն բանի համար, թե որքան հաճախ է սկանավորում բոլոր անվանատարածքները և ստուգում օրերով առանց տեղակայման. ստուգեքEveryMinutes. Լռելյայն հավասար է 30 минутам.

Ինչպես է այն աշխատում

Գործնականում ձեզ հարկավոր է.

  1. դոկեր մեկուսացված միջավայրում աշխատելու համար.
  2. Մինիկուբե կբարձրացնի Kubernetes կլաստերը տեղական մակարդակում:
  3. կուբեկտլ — հրամանի տողի ինտերֆեյս կլաստերի կառավարման համար:

Մենք տեղական մակարդակում բարձրացնում ենք Kubernetes կլաստերը.

$ 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. Ջնջել հատկանիշի ճյուղը հիմնական ճյուղի շարունակական ինտեգրման ժամանակ:

    • Դա անելու համար դուք պետք է իմանաք, թե որ ձգման հարցումն է վերաբերում կառուցվող պարտավորությանը: Քանի որ առանձնահատկությունների ճյուղի անվանատարածքը պարունակում է pull request նույնացուցիչը՝ դրա համարը կամ ճյուղի անվանումը, նույնացուցիչը միշտ պետք է նշվի commit-ում:
    • Մասնաճյուղերի կառուցումը ձախողվում է: Օրինակ, դուք ունեք հետևյալ փուլերը՝ ներբեռնեք նախագիծը, կատարեք թեստեր, կառուցեք նախագիծը, թողարկեք, ուղարկեք ծանուցումներ, մաքրեք վերջին ձգման հարցումի գործառույթի ճյուղը: Եթե ​​ծանուցում ուղարկելիս build-ը ձախողվի, դուք ստիպված կլինեք ձեռքով ջնջել կլաստերի բոլոր ռեսուրսները:
    • Առանց համապատասխան համատեքստի, հիմնական կառուցվածքում գործառույթների ճյուղերի ջնջումը ակնհայտ չէ:

  2. Օգտագործելով վեբ-կեռիկներ (օրինակ).

    • Սա չի կարող լինել ձեր մոտեցումը: Օրինակ՝ մեջ Jenkins, խողովակաշարի միայն մեկ տեսակն աջակցում է սկզբնական կոդում իր կազմաձևերը պահպանելու հնարավորությունը: Վեբ-կեռիկներ օգտագործելիս դուք պետք է գրեք ձեր սեփական սցենարը՝ դրանք մշակելու համար: Այս սցենարը պետք է տեղադրվի Jenkins ինտերֆեյսում, որը դժվար է պահպանել:

  3. Գրեք Քրոնջոբ և ավելացրեք Kubernetes կլաստեր:

    • Ժամանակ ծախսել գրելու և աջակցելու վրա:
    • Օպերատորն արդեն աշխատում է նմանատիպ ոճով, փաստաթղթավորված է և աջակցվում է:

Շնորհակալություն հոդվածի նկատմամբ ուշադրության համար։ Հղում դեպի նախագծի Github-ում.

Source: www.habr.com

Добавить комментарий