Эскертүү котормо: Weaveworks компаниясынын бул серепи эң популярдуу тиркемелерди жайылтуу стратегияларын сунуштайт жана эң алдыңкы стратегияларды Kubernetes Flagger оператору аркылуу кантип ишке ашырууга болорун көрсөтөт. Ал жөнөкөй тилде жазылган жана визуалдык диаграммаларды камтыйт, ал тургай башталгыч инженерлерге маселени түшүнүүгө мүмкүндүк берет.
Диаграмма алынган Контейнер чечимдеринде жасалган жайылтуу стратегиялары
Бүгүнкү күндө булуттагы жергиликтүү тиркемелерди иштеп чыгуудагы эң чоң көйгөйлөрдүн бири - жайылтууну тездетүү. Микросервистерге болгон мамиледе, иштеп чыгуучулар толугу менен модулдук тиркемелер менен иштешет жана иштеп чыгышат, бул ар кандай командаларга бир эле учурда код жазууга жана колдонмого өзгөртүүлөрдү киргизүүгө мүмкүндүк берет.
Кыскараак жана тез-тез жайгаштыруу төмөнкү артыкчылыктарга ээ:
- Базарга чыгуу убактысы кыскарды.
- Жаңы функциялар колдонуучуларга тезирээк жетет.
- Колдонуучунун пикири иштеп чыгуу тобуна тезирээк жетет. Бул команда функцияларды кошуп, маселелерди тезирээк чече алат дегенди билдирет.
- Иштеп чыгуучунун моралдык маанайы жогорулайт: иштеп чыгууда көбүрөөк функциялар менен иштөө кызыктуураак.
Бирок релиздердин жыштыгы өскөн сайын, тиркеменин ишенимдүүлүгүнө же колдонуучу тажрыйбасына терс таасирин тийгизүү мүмкүнчүлүгү да көбөйөт. Мына ошондуктан операциялар жана DevOps командалары үчүн процесстерди куруу жана жайылтуу стратегияларын продукт жана колдонуучулар үчүн тобокелдиктерди азайткан жол менен башкаруу маанилүү. (Сиз CI/CD түтүктөрүн автоматташтыруу жөнүндө көбүрөөк биле аласыз .)
Бул постто биз Kubernetes'те ар кандай жайгаштыруу стратегияларын, анын ичинде жайылтууларды жана канарларды чыгаруу жана алардын вариациялары сыяктуу өркүндөтүлгөн ыкмаларды талкуулайбыз.
Жайгаштыруу стратегиялары
Максатыңызга жараша колдоно турган жайгаштыруу стратегияларынын бир нече түрлөрү бар. Мисалы, сиз андан аркы тестирлөө үчүн белгилүү бир чөйрөгө, же колдонуучулардын/кардарлардын бир бөлүгүнө өзгөртүүлөрдү киргизишиңиз керек болушу мүмкүн же функцияны жасоодон мурун чектелген колдонуучу сынагыңыз керек болушу мүмкүн. коомдук.
Rolling (акырындык менен, "токолотуу" жайылтуу)
Бул Кубернетестеги стандарттуу жайгаштыруу стратегиясы. Ал акырындык менен, биринин артынан бири, жаңы версиясы бар поддондорду тиркеменин эски версиясы менен алмаштырат - кластердин токтоп калуусу жок.
Кубернетес жаңы поддондор иштөөгө даяр болгуча күтөт (аларды колдонуп текшерүү ), эскилерин жыйноодон мурун. Эгер көйгөй жаралса, бул жылма жаңыртуу бүткүл кластерди токтотпостон токтотулушу мүмкүн. Жайгаштыруу түрүн сүрөттөгөн YAML файлында жаңы сүрөт эски сүрөттү алмаштырат:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Толуктоо жаңыртуу параметрлери манифест файлында көрсөтүлүшү мүмкүн:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Кайра түзүү
Жайгаштыруунун бул эң жөнөкөй түрүндө, эски кабыктар бир эле учурда жок кылынат жана жаңылары менен алмаштырылат:
Тиешелүү манифест төмөнкүдөй көрүнөт:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Көк/Жашыл (көк-жашыл жайылтуулар)
Көк-жашыл жайгаштыруу стратегиясы (кээде кызыл/кара деп да аталат) тиркеменин эски (жашыл) жана жаңы (көк) версияларын бир убакта жайылтууну камтыйт. Эки версияны тең жайгаштыргандан кийин, кадимки колдонуучулар жашыл версияга кире алышат, ал эми көк версия QA командасы үчүн өзүнчө кызмат же түз порт багыттоо аркылуу тесттерди автоматташтыруу үчүн жеткиликтүү:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Көк (жаңы) версия текшерилип, анын релизине бекитилгенден кийин, кызмат ага өтөт, ал эми жашыл (эски) версия бүктөлөт:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Канария (канареяларды жайгаштыруу)
Canary rollouts көк-жашыл rollouts окшош, бирок жакшыраак башкаруу жана пайдалануу бар этап-этабы менен мамиле кылуу. Бул түрү бир нече ар кандай стратегияларды камтыйт, анын ичинде "жашыруун" ишке киргизүү жана A/B тестирлөө.
Бул стратегия, адатта, тиркеменин арткы бөлүгүндө кандайдыр бир жаңы функцияларды сынап көрүү зарылчылыгы болгондо колдонулат. Бул ыкманын маңызы эки дээрлик бирдей серверди түзүү болуп саналат: бири дээрлик бардык колдонуучуларды тейлейт, ал эми экинчиси жаңы функциялар менен колдонуучулардын кичинекей чакан тобун гана тейлейт, андан кийин алардын ишинин натыйжалары салыштырылат. Эгер баары катасыз кетсе, жаңы версия акырындык менен бүт инфраструктурага жайылтылат.
Бул стратегияны бир гана Kubernetes аркылуу ишке ашырууга мүмкүн болсо да, эски подкачкаларды жаңыларына алмаштыруу, Istio сыяктуу тейлөө тармагын колдонуу алда канча ыңгайлуу жана жөнөкөй.
Мисалы, сизде Gitте эки башка манифест болушу мүмкүн: 0.1.0 теги менен кадимки манифест жана 0.2.0 теги менен канариялык манифест. Istio виртуалдык шлюз манифестиндеги салмактарды өзгөртүү менен, сиз бул эки жайгаштыруу ортосундагы трафиктин бөлүштүрүлүшүн көзөмөлдөй аласыз:
Istio аркылуу канарларды жайгаштырууну ишке ашыруу боюнча этап-этабы менен колдонмону караңыз . (Эскертүү. котормо.: Биз ошондой эле Istio тилине канареяларды чыгаруу жөнүндө материалды котордук .)
Weaveworks Flagger менен Canary Deployments
сизге оңой жана эффективдүү канарейкаларды башкарууга мүмкүндүк берет.
Flagger автоматтары алар менен иштейт. Ал трафикти багыттоо жана которуштуруу үчүн Istio же AWS App Mesh, ал эми натыйжаларды талдоо үчүн Prometheus метрикасын колдонот. Мындан тышкары, канарларды жайгаштыруу анализи кабыл алуу сыноолорун, жүктөө тесттерин жана башка текшерүүлөрдүн башка түрлөрүн жүргүзүү үчүн веб-укуктар менен толукталышы мүмкүн.
Kubernetes жайылтуусунун жана зарыл болсо, подкасттарды горизонталдуу масштабдатуусунун (HPA) негизинде Flagger объекттердин топтомун түзөт (Kubernetes жайылтуулары, ClusterIP кызматтары жана Istio же App Mesh виртуалдык кызматтары) канарларды жайылтууларды талдоо жана ишке ашыруу үчүн:
Башкаруу циклин ишке ашыруу (башкаруу цикли),Flagger трафикти акырындык менен canary серверине которот, ошол эле учурда ийгиликтүү HTTP сурамдарынын пайызы, сурамдын орточо узактыгы жана поддондун ден соолугу сыяктуу негизги көрсөткүчтөрдү өлчөйт. KPI (Негизги Performance Indicators) талдоосунун негизинде канар өсөт же кулайт жана анализдин натыйжалары Slackте жарыяланат. Бул процесстин сүрөттөлүшүн жана демонстрациясын материалдан тапса болот .
Караңгы (жашыруун) же A/B жайылтуулары
Жашыруун жайгаштыруу - бул канарлык стратегиянын дагы бир вариациясы (айтмакчы, Flagger менен да иштей алат). Жашыруун жана канареялык жайгаштыруулардын ортосундагы айырмачылык, жашыруун жайгаштыруу канарларды жайгаштыруу сыяктуу арткы эмес, фронт менен иштешет.
Бул жайылтуулардын дагы бир аталышы A/B тести. Жаңы функцияны бардык колдонуучуларга жеткиликтүү кылуунун ордуна, ал алардын чектелген бөлүгүнө гана сунушталат. Адатта, бул колдонуучулар пионердик тестерлер экенин билишпейт (ошондуктан "жашыруун жайылтуу" термини).
Функционалдык которгучтарды колдонуу (функцияны которуштуруу) жана башка инструменттер аркылуу колдонуучулардын жаңы функция менен кантип иштешерин, алар бул функция менен алектенип жатабы же жаңы колдонуучу интерфейсин чаташтырабы же жокпу, жана башка көрсөткүчтөрдү көзөмөлдөй аласыз.
Flagger жана A/B жайгаштыруу
Салмакка негизделген маршрутизациядан тышкары, Flagger трафикти HTTP параметрлеринин негизинде канар серверине багыттай алат. A/B тестирлөөсүндө, колдонуучулардын белгилүү бир сегментине багытталган HTTP аталыштарын же кукилерди колдоно аласыз. Бул серверге сеансты байланыштырууну талап кылган frontend тиркемелеринде өзгөчө эффективдүү (сеанстын жакындыгы). Көбүрөөк маалыматты Flagger документтеринен тапса болот.
Автор ыраазычылыгын билдирет , Weaveworks инженери (жана Flaggerдин жаратуучусу), бул укмуштуудай жайылтуу үлгүлөрү үчүн.
Котормочудан PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com