Docker Compose ці Kubernetes: 0,7 секунды супраць аркестрацыі кластара

Docker Compose дастаткова для вытворчага сэрвісу на адным серверы, калі каманда прымае прастой пры адмове хоста і можа праводзіць рэлізы ў акно абслугоўвання. Калі сэрвіс павінен перажываць адмову вузла і абнаўляцца без прыпынення трафіку, з гэтых двух інструментаў больш прыдатны Kubernetes. Даследаванне разгортвання WordPress зафіксавала 0,7 секунды для стварэння Docker-кантэйнера і 6 секунд для Kubernetes Pod у выпрабаванні з Docker Desktop, Kubernetes і JMeter на ноўтбуку. Гэта замер стварэння асобных адзінак у пэўнай канфігурацыі, а не хуткасці ўсяго рэлізу або аднаўлення пасля аварыі.

Вытворчая інструкцыя Docker апісвае разгортванне Compose на адным серверы, асобны файл з вытворчымі наладамі і перастварэнне кантэйнера пры выпуску змен. Інструкцыя Kubernetes для вытворчага асяроддзя звязвае высокую даступнасць з рэплікамі кампанентаў кіравання, дастатковай колькасцю рабочых вузлоў і размеркаваннем нагрузкі. Таму мяжа выбару праходзіць праз патрабаванні да бесперапыннай працы і магчымасці каманды, а не праз хуткасць аднаго запуску.

Што азначае замер стварэння кантэйнера

Кароткі час стварэння можа быць карысным, калі трэба хутка дадаць асобны працэс. Але карыстальнік чакае адказу ад прыкладання, а не паведамлення пра тое, што кантэйнер або Pod ужо створаны. Пасля стварэння яшчэ патрэбныя запуск прыкладання, падключэнне да залежных сэрвісаў і гатоўнасць прымаць трафік. Таму гэты паказчык нельга падставіць замест часу разгортвання новай версіі.

У выпрабаванні выкарыстоўвалі WordPress і генератар нагрузкі JMeter, а абодва варыянты працавалі на ноўтбуку. Параўноўвалі стварэнне Docker-кантэйнера з стварэннем Kubernetes Pod; асобнага замеру хуткасці Docker Compose там няма. Pod уключае ўласны шлях стварэння і размяшчэння ў сістэме кіравання кластарам, таму розніца ў секундах апісвае менавіта тыя ўмовы эксперыменту. Для выбару вытворчай архітэктуры больш істотна, ці застануцца даступныя працоўныя копіі сэрвісу падчас збою або замены версіі.

Калі аднаго сервера дастаткова

Compose падыходзіць, калі нагрузка змяшчаецца на адным хосце, час ручнога аднаўлення прымальны, а выпускі можна планаваць. У вытворчай канфігурацыі можна змяніць парты і зменныя асяроддзя, прыбраць прывязку зыходнага кода з хоста і задаць палітыку перазапуску. Каманда падтрымлівае прыкладанне і сервер, не дадаючы да іх асобную плоскасць кіравання кластарам.

Палітыка перазапуску дапамагае, калі спыніўся кантэйнер і сам хост працуе. Калі недаступная машына, усе размешчаныя на ёй кампаненты губляюць гэтую пляцоўку адначасова. Таму ў рашэнне на адным серверы павінны ўваходзіць рэзервовыя копіі, спосаб аднавіць даныя і парадак вяртання прыкладання ў працу на іншым хосце. Compose не вырашае гэтыя задачы за каманду, але і статус вытворчага сэрвісу сам па сабе не патрабуе кластара.

Калі адмова вузла не павінна спыняць сэрвіс

Пераход да аркестрацыі становіцца абгрунтаваным, калі пасля страты машыны трафік павінен ісці да іншых працоўных копій. Механізмы самааднаўлення Kubernetes ствараюць замену Pod для захавання патрэбнай колькасці рэплік, пераразмяшчаюць нагрузку пасля недаступнасці вузла і выключаюць няспраўныя Pod з маршрутызацыі Service. Для гэтага ў кластары павінны быць даступныя іншыя вузлы з рэсурсамі для нагрузкі.

Колькасць рэплік сама па сабе не гарантуе ўстойлівасці да адмовы хоста: усе яны могуць апынуцца на адной машыне. Патрэбныя размяшчэнне копій на незалежных вузлах, працоўны шлях трафіку да іх і такая ж увага да базы даных ды сховішча. Калі база застаецца адзінай кропкай адмовы, працоўныя копіі вэб-сэрвісу не захаваюць увесь сэрвіс даступным. Для Compose пераключэнне паміж хостамі таксама можна арганізаваць асобнымі сродкамі, але іх прыйдзецца распрацаваць і падтрымліваць па-за яго звычайным сцэнарыем разгортвання на адным серверы.

Як частата рэлізаў змяняе выбар

Калі абнаўленні рэдкія і кароткі перапынак прымальны, перастварэнне патрэбнага кантэйнера праз Compose можа быць дастатковай працэдурай. Каманда ўсё адно павінна ведаць, калі новая версія гатовая прымаць запыты і як вярнуць папярэднюю пры няўдалым выпуску. Калі рэлізы частыя, ручное акно абслугоўвання пачынае ўплываць на даступнасць сэрвісу і час інжынераў.

Механізм Deployment у Kubernetes паступова замяняе старыя Pod новымі і дазваляе задаць, колькі копій можа быць недаступна падчас абнаўлення. Для выпуску без прыпынення трафіку прыкладанне павінна працаваць у некалькіх копіях, карэктна паведамляць пра гатоўнасць і мець дастаткова рэсурсаў для новай версіі побач са старой. Сам факт выкарыстання Kubernetes не робіць кожны рэліз бесперапынным; вынік залежыць ад гэтых умоў.

Матрыца выбару для каманды

Практычная мяжа бачная, калі супаставіць патрабаванні сэрвісу з працай, якую давядзецца выконваць штодня. Кожны з крытэрыяў паказвае асобную прычыну застацца на адным хосце або перайсці да кластара:

• Размяшчэнне. Адзін сервер і прадказальная нагрузка падтрымліваюць выбар Compose. Калі вылічальныя рэсурсы трэба размяркоўваць паміж некалькімі вузламі, Kubernetes дае механізм кіравання такой нагрузкай.
• Прастой. Калі пасля страты хоста прымальна аднавіць сэрвіс уручную, складанасць кластара можа не акупіцца. Калі абслугоўванне павінна працягвацца, патрэбныя незалежныя вузлы, рэплікі і маршрутызацыя да працоўных копій.
• Рэлізы. Запланаванае акно для абнаўлення добра спалучаецца з Compose. Патрабаванне часта выпускаць версіі без прыпынення трафіку робіць паступовае абнаўленне істотнай магчымасцю.
• Каманда. Невялікая каманда можа падтрымліваць адзін хост разам з прыкладаннем. Кластару патрэбныя адказныя за вузлы, сетку, доступ, сховішча, абнаўленні і рэагаванне на збоі — у самой камандзе або ў пастаўшчыка кіраванай платформы.

Гэта не парог паводле колькасці кантэйнераў. Некалькі звязаных сэрвісаў могуць працаваць на адным серверы, а нават невялікае прыкладанне можа мець жорсткае патрабаванне перажыць адмову вузла. Вызначальным становіцца наступства збою для карыстальніка і кошт забеспячэння патрэбнай даступнасці.

Рэальная цана адміністравання

Для Compose ў кошт уваходзяць падтрымка хоста, рэзервовыя копіі, ручныя выпускі і аднаўленне пасля адмовы. Калі вакол яго з’яўляюцца ўласныя скрыпты пераключэння, балансавальнік і механізмы паступовага рэлізу, трэба ўлічваць таксама іх распрацоўку і дзяжурства. Для Kubernetes дадаюцца рэсурсы кластара, наладка доступу і сеткі, абнаўленне кампанентаў, назіранне за іх станам і эксплуатацыя сховішча.

Кіраваная платформа можа ўзяць на сябе частку працы з плоскасцю кіравання і вузламі, але адказнасць за канфігурацыю прыкладання, яго даныя і паводзіны пры збоі застаецца. Таму для аднаго сервера з прымальным прастоем Compose — абгрунтаваны вытворчы выбар. Kubernetes апраўдвае дадатковую складанасць тады, калі патрабаванне перажыць адмову вузла або выпускаць версіі без перапынення трафіку ўжо існуе і каманда гатовая падтрымліваць адпаведную інфраструктуру.

Чытайце таксама:

• Make ці Pipedream: кожны крок супраць кожных 30 секунд выканання
• LangChain ці LlamaIndex: аркестрацыя супраць якасці пошуку ў RAG
• Carta ці Pulley: бясплатны старт супраць цаны ад $1200