Helm менен канарларды жайгаштырууну автоматташтыруунун жөнөкөй жана коопсуз жолу

Канарияны жайылтуу - бул колдонуучулардын бир бөлүгүндө жаңы кодду сынап көрүүнүн эң натыйжалуу жолу. Бул жайгаштыруу процессинде көйгөйлүү болушу мүмкүн болгон трафиктин жүгүн бир топ азайтат, анткени ал белгилүү бир топтун ичинде гана пайда болот. Бул эскертүү Kubernetes жана жайылтууну автоматташтыруу аркылуу мындай жайгаштырууну кантип уюштуруу керектиги жөнүндө. Бул сизде Helm жана Kubernetes ресурстары боюнча кандайдыр бир билимиңиз бар деп болжолдойт..



Kubernetes үчүн жөнөкөй канарларды жайгаштыруу эки негизги ресурстарды камтыйт: кызматтын өзү жана жайылтуу куралы. Канарияны жайылтуу жаңыртуу трафигин тейлеген эки башка ресурстар менен байланышуучу бир кызмат аркылуу иштейт. Бул ресурстардын бири "канарея" версиясы менен иштейт, ал эми экинчиси - туруктуу. Мындай кырдаалда биз тейлөө үчүн талап кылынган трафиктин көлөмүн азайтуу үчүн канар версияларынын санын тууралай алабыз. Эгер, мисалы, сиз Yaml колдонууну кааласаңыз, анда ал 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.

Мындай вариантты kubectlде элестетүү дагы оңой Kubernetes үчүн документтер бул сценарий боюнча толук окуу куралы да бар. Бирок бул посттун негизги суроосу - бул процессти Helm аркылуу кантип автоматташтырабыз.

Canary Deployment Automation

Биринчиден, бизге Helm диаграмма картасы керек, анда жогоруда талкууланган ресурстар камтылган. Ал төмөнкүдөй көрүнүшү керек:

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

Helm концепциясынын негизин мультиверсиялык релиздерди башкаруу түзөт. Туруктуу версия долбоор үчүн биздин негизги туруктуу код бутагы болуп саналат. Бирок Helm жардамы менен биз эксперименталдык кодубуз менен канареянын чыгарылышын орното алабыз. Эң негизгиси - туруктуу версия менен канареялык релиздин ортосундагы трафик алмашууну сактап калуу. Мунун баарын атайын селектор аркылуу башкарабыз:

selector:
  app.kubernetes.io/name: myapp

Биздин эки "канарея" жана туруктуу жайгаштыруу ресурстары модулдарда бул белгини көрсөтөт. Эгерде бардыгы туура конфигурацияланган болсо, анда биздин Helm диаграммасынын картасынын канариялык версиясын жайылтуу учурунда, биз трафик жаңы орнотулган модулдарга багыттала турганын көрөбүз. Бул буйруктун туруктуу версиясы төмөнкүдөй болот:

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

Эми биздин канарея чыгарууну текшерип көрөлү. Канар версиясын жайылтуу үчүн биз эки нерсени эстешибиз керек. Учурдагы туруктуу версияны жаңыртпашыбыз үчүн релиздин аталышы башка болушу керек. Биз башка кодду жайгаштырып, ресурс тегдериндеги айырмачылыктарды аныкташыбыз үчүн версия жана теги ар түрдүү болушу керек.

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

Бул, чынында, баары! Эгер сиз кызматка пинг жөнөтсөңүз, канарлык жаңыртуу убакыттын бир бөлүгүн гана трафикти багыттаарын көрө аласыз.

Эгерде сиз сүрөттөлгөн логиканы камтыган жайылтууну автоматташтыруу куралдарын издеп жатсаңыз, анда карап көрүңүз жеткирүү боту жана GitHub'дагы рулду автоматташтыруу куралдары. Жогоруда сүрөттөлгөн ыкманы ишке ашыруу үчүн колдонулган Helm диаграммалары Githubда, бул жерде. Жалпысынан алганда, бул конкреттүү түшүнүктөр жана мисалдар менен канар версияларын жайылтууну автоматташтырууну практикада кантип ишке ашырууга теориялык сереп салуу болду.

Source: www.habr.com