Einföld og örugg leið til að gera sjálfvirkan dreifingu kanarífugla með Helm

Canary dreifing er mjög áhrifarík leið til að prófa nýjan kóða á undirhópi notenda. Það dregur verulega úr umferðarálagi sem getur verið vandamál meðan á dreifingarferlinu stendur, þar sem það gerist aðeins innan tiltekins undirmengis. Þessi athugasemd er helguð því hvernig á að skipuleggja slíka uppsetningu með Kubernetes og sjálfvirkni dreifingar. Við gerum ráð fyrir að þú vitir eitthvað um Helm og Kubernetes auðlindir.



Einföld kanarídreifing á Kubernetes inniheldur tvö lykilúrræði: þjónustuna sjálfa og dreifingartólið. Canary dreifing virkar í gegnum eina þjónustu sem hefur samskipti við tvö mismunandi tilföng sem þjóna uppfærsluumferð. Eitt af þessum auðlindum mun virka með „kanaríútgáfunni“ og annað mun virka með stöðugu útgáfunni. Í þessum aðstæðum getum við stjórnað fjölda kanaríútgáfu til að draga úr umferð sem þarf til að þjóna. Ef þú vilt til dæmis nota Yaml, þá mun það líta svona út í Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

Það er jafnvel auðveldara að ímynda sér þennan valkost með því að nota kubectl og inn Kubernetes skjöl Það er meira að segja fullt kennsluefni um þessa atburðarás. En aðalspurning þessarar færslu er hvernig við ætlum að gera þetta ferli sjálfvirkt með því að nota Helm.

Sjálfvirkni í dreifingu kanarífugla

Fyrst af öllu þurfum við Helm kortkort, sem inniheldur nú þegar auðlindirnar sem við ræddum hér að ofan. Það ætti að líta einhvern veginn svona út:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Grunnurinn að Helm hugmyndinni er stjórnun fjölútgáfu útgáfur. Stöðuga útgáfan er helsta stöðuga greinin okkar á verkefniskóðanum. En með Helm getum við sett upp kanaríútgáfu með tilraunakóðanum okkar. Aðalatriðið er að viðhalda umferðarskiptum milli stöðugu útgáfunnar og kanaríútgáfunnar. Við munum stjórna öllu þessu með því að nota sérstakan val:

selector:
  app.kubernetes.io/name: myapp

„kanarífugl“ og stöðugt dreifingarúrræði okkar munu gefa til kynna þennan merkimiða á einingunum. Ef allt er rétt stillt, þá munum við sjá að umferð verður beint að nýuppsettu einingunum meðan á dreifingu kanaríútgáfunnar af Helm kortakortinu okkar stendur. Stöðug útgáfa af þessari skipun mun líta svona út:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Nú skulum við athuga kanaríútgáfuna okkar. Til að dreifa kanaríútgáfunni þurfum við að muna tvennt. Útgáfuheitið verður að vera annað svo að við setjum ekki út uppfærslu á núverandi stöðugu útgáfu. Útgáfan og merkið verða líka að vera öðruvísi svo að við getum notað annan kóða og greint mismun með auðlindamerkjum.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Það er allt og sumt! Ef þú pingar þjónustuna geturðu séð að kanaríuppfærslan leiðir umferð aðeins hluta af tímanum.

Ef þú ert að leita að sjálfvirkum dreifingarverkfærum sem innihalda lýst rökfræði, þá skaltu fylgjast með Deliverybot og Helm sjálfvirkniverkfæri á GitHub. Hjálmarkortin sem notuð eru til að útfæra aðferðina sem lýst er hér að ofan eru á Github, hér. Almennt séð var þetta fræðilegt yfirlit um hvernig á að innleiða sjálfvirkni í dreifingu á kanaríútgáfum í reynd, með sérstökum hugtökum og dæmum.

Heimild: www.habr.com