ProHoster > Blog > Administrazioa > Kubernetes kluster batean zaharkitutako eginbide-adar bat kentzea

Kubernetes kluster batean zaharkitutako eginbide-adar bat kentzea

Kubernetes kluster batean zaharkitutako eginbide-adar bat kentzea

Hi! Ezaugarri adarra (Inplementatu aurrebista, berrikusi aplikazioa) - hau da, adar nagusia ez ezik, URL esklusibo batera tiratzeko eskaera bakoitza ere zabaltzen denean. Kodeak produkzio-ingurune batean funtzionatzen duen egiazta dezakezu; funtzioa beste programatzaile edo produktu-espezialistei erakutsi diezaieke. Tira-eskaera batean lanean ari zaren bitartean, kode zaharraren uneko inplementazio berri bakoitza ezabatzen da eta kode berriaren inplementazio berria zabaltzen da. Galderak sor daitezke tira-eskaera bat adar nagusiarekin bateratzean. Jada ez duzu eginbide-adarra behar, baina Kubernetes baliabideak klusterrean daude oraindik.

Ezaugarrien adarrei buruzko informazio gehiago

Kubernetes-en ezaugarri-adarrak egiteko ikuspegi bat izen-espazioak erabiltzea da. Laburbilduz, ekoizpenaren konfigurazioa honelakoa da:

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

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

Ezaugarrien adar baterako, izen-espazio bat sortzen da bere identifikatzailearekin (adibidez, tira-eskaeraren zenbakia) eta nolabaiteko aurrizki/postfixarekin (adibidez, -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
...

Oro har, idatzi nuen Kubernetes operadorea (kluster baliabideetarako sarbidea duen aplikazioa), Github-en proiekturako esteka. Ezaugarrien adar zaharrei dagozkien izen-espazioak kentzen ditu. Kubernetes-en, izen-eremu bat ezabatzen baduzu, izen-eremu horretako beste baliabide batzuk ere automatikoki ezabatzen dira.

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

Ezaugarrien adarrak kluster batean nola ezartzeari buruz irakur dezakezu Hemen ΠΈ Hemen.

Motibazioa

Ikus dezagun tira-eskaeraren bizi-ziklo tipiko bat etengabeko integrazioarekin (continuous integration):

  1. Adarrarekin konpromiso berri bat bultzatzen dugu.
  2. Eraikuntzan, linters eta/edo probak egiten dira.
  3. Kubernetes pull-eskaeraren konfigurazioak berehala sortzen dira (adibidez, bere zenbakia amaitutako txantiloian txertatzen da).
  4. Kubectl apply erabiliz, konfigurazioak klusterera gehitzen dira (inplementatu).
  5. Pull eskaera adar nagusiarekin bateratzen da.

Tira-eskaera batean lanean ari zaren bitartean, kode zaharraren uneko inplementazio berri bakoitza ezabatzen da eta kode berriaren inplementazio berria zabaltzen da. Baina tira eskaera bat adar nagusiarekin bateratzen denean, adar nagusia bakarrik eraikiko da. Ondorioz, ondorioztatzen da dagoeneko ahaztu dugula pull eskaera, eta bere Kubernetes baliabideak oraindik klusterrean daude.

Nola erabili

Instalatu proiektua beheko komandoarekin:

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

Sortu fitxategi bat eduki honekin eta instalatu bidez kubectl apply -f:

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

Parametroa namespaceAzpikatea beste izen-espazio batzuetako tira-eskaeretarako izen-espazioak iragazi behar dira. Adibidez, klusterrak izen-espazio hauek baditu: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, orduan ezabatzeko hautagaiak izango dira habr-back-end-pr-17, habr-back-end-pr-33.

Parametroa AfterDaysWithoutDeploy izen-espazio zaharrak ezabatu behar dira. Adibidez, izen-espazioa sortzen bada 3 дня 1 час atzera, eta parametroak adierazten du 3 дня, izen-espazio hau ezabatu egingo da. Kontrako norabidean ere funtzionatzen du izen-espazioa sortzen bada 2 дня 23 часа atzera, eta parametroak adierazten du 3 дня, izen-eremu hau ez da ezabatuko.

Parametro bat gehiago dago, izen-espazio guztiak zenbat aldiz eskaneatu eta inplementatu gabe egunak egiaztatzeaz arduratzen da - checkEveryMinutes. Berez berdina da 30 ΠΌΠΈΠ½ΡƒΡ‚Π°ΠΌ.

Nola egiten du lan

Praktikan, behar izango duzu:

  1. Docker ingurune isolatu batean lan egiteko.
  2. Minikube Kubernetes kluster bat sortuko du lokalean.
  3. kubectl β€” komando-lerroko interfazea kluster kudeaketarako.

Kubernetes kluster bat sortzen dugu lokalean:

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

Adierazten dugu kubectl Erabili kluster lokala lehenespenez:

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

Deskargatu ekoizpen ingurunerako konfigurazioak:

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

Produkzio-konfigurazioak izen-espazio zaharrak egiaztatzeko konfiguratuta daudenez eta sortu berri dugun klusterrak ez dituenez, ingurune-aldagaia ordezkatuko dugu. IS_DEBUG on true. Balio honekin parametroa afterDaysWithoutDeploy ez da kontuan hartzen eta izen-espazioak ez dira inplementatu gabe egunetan egiaztatzen, azpikatearen agerpenerako soilik (-pr-).

On bazaude Linux:

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

On bazaude macOS:

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

Proiektua instalatzea:

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

Klusterrean baliabide bat agertu dela egiaztatzea StaleFeatureBranch:

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

Klusterean operadore bat agertu dela egiaztatzen dugu:

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

Bere erregistroak begiratzen badituzu, prest dago baliabideak prozesatzeko 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}

Prest eginda instalatzen dugu fixtures (kluster baliabideak modelatzeko prest dauden konfigurazioak) baliabide baterako StaleFeatureBranch:

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

Konfigurazioek azpikate bat duten izen-espazioak bilatzeko adierazten dute -pr- behin sartuta 1 ΠΌΠΈΠ½ΡƒΡ‚Ρƒ.:

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

Operadoreak erantzun du eta prest dago izen-espazioak egiaztatzeko:

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

Ezarri fixtures, bi izen-espazio dituena (project-pr-1, project-pr-2) eta haiek deployments, services, ingress, eta abar:

$ 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

Goiko baliabide guztiak behar bezala sortu direla egiaztatzen dugu:

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

Sartu genuenetik debug, izen-espazioak project-pr-1 ΠΈ project-pr-2, beraz, gainerako baliabide guztiak berehala ezabatu beharko dira parametroa kontuan hartu gabe afterDaysWithoutDeploy. Hau operadoreen erregistroetan ikus daiteke:

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

Baliabideen erabilgarritasuna egiaztatzen baduzu, egoeran egongo dira Terminating (ezabatze prozesua) edo dagoeneko ezabatuta (komandoaren irteera hutsik dago).

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

Sortze-prozesua errepikatu dezakezu fixtures hainbat aldiz eta ziurtatu minutu batean kentzen direla.

alternatibak

Zer egin daiteke kluster batean lan egiten duen operadore baten ordez? Hainbat planteamendu daude, guztiak inperfektuak dira (eta haien gabeziak subjektiboak dira), eta bakoitzak bere kabuz erabakitzen du zein den onena proiektu jakin baterako:

  1. Ezabatu eginbide-adarra adar nagusiaren etengabeko integrazioa eraikitzean.

    • Horretarako, eraikitzen ari den konpromezuarekin zer tira-eskaera duen jakin behar duzu. Ezaugarrien adarraren izen-eremuak pull-eskaeraren identifikatzailea - bere zenbakia edo adarraren izena daukanez, identifikatzailea beti zehaztu beharko da konpromisoan.
    • Adar nagusien eraikuntzak huts egiten ari dira. Adibidez, fase hauek dituzu: proiektua deskargatu, probak exekutatu, proiektua eraiki, kaleratze bat egin, jakinarazpenak bidali, azken tira-eskaeraren eginbide-adarra garbitu. Jakinarazpen bat bidaltzean eraikuntzak huts egiten badu, klusterreko baliabide guztiak eskuz ezabatu beharko dituzu.
    • Testuinguru egokirik gabe, eraikuntza nagusiko ezaugarri-adarrak ezabatzea ez da begi bistakoa.

  2. Webhook-ak erabiliz (Adibidez).

    • Baliteke hau ez izatea zure planteamendua. Adibidez, in Jenkins, kanalizazio mota batek bakarrik onartzen du bere konfigurazioak iturburu-kodean gordetzeko gaitasuna. Webhook-ak erabiltzean, zure script-a idatzi behar duzu haiek prozesatzeko. Script hau Jenkins interfazean jarri beharko da, eta hori mantentzea zaila da.

  3. Idazteko Cronjob eta gehitu Kubernetes kluster bat.

    • Idazten eta laguntzan denbora ematea.
    • Eragileak dagoeneko antzeko estiloan lan egiten du, dokumentatuta eta onartzen da.

Eskerrik asko artikuluari emandako arretagatik. Github-en proiekturako esteka.

Iturria: www.habr.com

Gehitu iruzkin berria