Кога стартувате кластер Kubernetes за одредена апликација, треба да разберете што претставува самата апликација, бизнисот и програмерите за овој ресурс. Со овие информации, можете да започнете да донесувате архитектонска одлука и, особено, да изберете специфичен контролер Ingress, од кои денес веќе има голем број. Со цел да се добие основна идеја за достапните опции без да мора да поминете низ многу написи / документација итн., го подготвивме овој преглед, вклучувајќи ги главните (подготвени за производство) контролери за влез.
Се надеваме дека ќе им помогне на колегите во изборот на архитектонско решение - барем ќе стане почетна точка за добивање подетални информации и практични експерименти. Претходно, проучувавме други слични материјали на мрежата и, чудно е доволно, не најдовме ниту еден повеќе или помалку целосен, и што е најважно - структуриран - преглед. Па да ја пополниме таа празнина!
критериуми
Во принцип, за да направите споредба и да добиете некој корисен резултат, треба да ја разберете не само предметната област, туку и да имате специфична листа на критериуми што ќе го постават векторот на истражувањето. Без да се преправаме дека ги анализираме сите можни случаи на користење на Ingress / Kubernetes, се обидовме да ги истакнеме најопштите барања за контролорите - бидете подготвени дека во секој случај ќе треба да ги проучите сите ваши специфики и детали одделно.
Но, ќе започнам со карактеристиките кои станаа толку познати што се имплементирани во сите решенија и не се разгледуваат:
- динамично откривање на услуги (откривање на услуги);
- SSL завршување;
- работа со веб-сокети.
Сега за точките за споредба:
Поддржани протоколи
Еден од основните критериуми за избор. Вашиот софтвер може да не работи на стандарден HTTP или може да бара работа на повеќе протоколи одеднаш. Ако вашиот случај е нестандарден, не заборавајте да го земете предвид овој фактор за да не морате подоцна да го реконфигурирате кластерот. За сите контролери, листата на поддржани протоколи варира.
софтвер во основата
Постојат неколку варијации на апликации на кои се базира контролорот. Популарни се nginx, traefik, haproxy, envoy. Во општ случај, можеби нема многу влијание врз начинот на кој сообраќајот се прима и пренесува, но секогаш е корисно да се знаат потенцијалните нијанси и карактеристики на она што е „под хаубата“.
Рутирање на сообраќајот
Врз основа на тоа што е можно да се донесе одлука за насоката на сообраќајот кон одредена услуга? Обично тоа се домаќин и патека, но има дополнителни можности.
Именски простор во кластер
Простор со имиња (именски простор) - способност за логично разделување на ресурсите во Кубернетес (на пример, на сцена, продукција итн.). Постојат Ingress контролери кои мора да се инсталираат посебно во секој именски простор (и потоа може да го насочува сообраќајот само до мешунките на овој простор). Има и такви (и нивното јасно мнозинство) кои работат на глобално ниво за целиот кластер - во нив сообраќајот е насочен кон кој било дел од кластерот, без оглед на именскиот простор.
Примероци за возводно
Како сообраќајот е насочен кон здрави примероци од апликацијата, услугите? Постојат опции со активни и пасивни проверки, повторувања, прекинувачи (За повеќе детали, видете, на пример, ), сопствени имплементации на здравствени проверки (прилагодени здравствени проверки) итн. Многу важен параметар ако имате високи барања за достапност и навремено отстранување на неуспешните услуги од балансирање.
Алгоритми за балансирање
Постојат многу опции: од традиционалните до егзотичното , како и индивидуалните карактеристики како .
Автентикација
Кои шеми за авторизација ги поддржува контролорот? Basic, digest, oauth, external-auth - мислам дека овие опции треба да бидат познати. Ова е важен критериум ако има многу програмери (и/или само приватни) циклуси до кои се пристапува преку Ingress.
Дистрибуција на сообраќај
Дали контролорот поддржува такви најчесто користени механизми за дистрибуција на сообраќајот како што се пуштање на канари (канари), тестирање A/B, пресликување на сообраќајот (отсликување / засенчување)? Ова е навистина болна тема за апликации кои бараат прецизно и прецизно управување со сообраќајот за продуктивно тестирање, дебагирање грешки на производот офлајн (или со минимална загуба), анализа на сообраќајот итн.
Платена претплата
Дали има платена опција за контролорот, со напредна функционалност и/или техничка поддршка?
Графички кориснички интерфејс (Web UI)
Дали има некој GUI за управување со конфигурацијата на контролорот? Главно за „практично“ и/или за оние кои треба да направат некои промени во конфигурацијата Ingress'a, но работата со „суровини“ шаблони е незгодно. Може да биде корисно ако програмерите сакаат да спроведат некои експерименти со сообраќајот во лет.
JWT валидација
Присуство на вградена валидација на веб-токени JSON за авторизација и валидација на корисникот до крајната апликација.
Можности за прилагодување на конфигурацијата
Проширливост на шаблоните во смисла да имате механизми кои ви дозволуваат да додавате свои директиви, знаменца итн. на стандардните конфигурациски шаблони.
Основни механизми за заштита на DDOS
Едноставни алгоритми за ограничување на стапката или посложени опции за филтрирање сообраќај врз основа на адреси, бели листи, земји итн.
Побарајте трага
Способност за следење, следење и дебагирање на барањата од Ingresses до специфични услуги/подови, а идеално е и помеѓу услугите/подовите.
WAF
Поддршка .
Контролори
Списокот на контролори е формиран врз основа на и . Некои од нив ги исклучивме од прегледот поради специфичноста или ниската преваленца (рана фаза на развој). Останатото се дискутира подолу. Да почнеме со општ опис на решенијата и да продолжиме со сумарна табела.
Влез од Кубернетес
Веб страна:
Лиценца: Apache 2.0
Ова е официјалниот контролер за Kubernetes и се развива од заедницата. Очигледно од името, тој се заснова на nginx и е надополнет со различен сет на Lua приклучоци кои се користат за имплементација на дополнителни функции. Поради популарноста на самиот nginx и минималните модификации на него кога се користи како контролер, оваа опција може да биде најлесна и најлесна за конфигурирање за просечниот инженер (со веб искуство).
Ingress од NGINX Inc.
Веб страна:
Лиценца: Apache 2.0
Официјален производ на програмерите nginx. Има платена верзија врз основа на . Главната идеја е високо ниво на стабилност, постојана компатибилност наназад, отсуство на какви било надворешни модули и декларирана зголемена брзина (во споредба со официјалниот контролер), постигната поради отфрлањето на Луа.
Бесплатната верзија е значително намалена, вклучително дури и во споредба со официјалниот контролер (поради недостаток на истите модули Lua). Во исто време, платената има прилично широка дополнителна функционалност: метрика во реално време, валидација на JWT, активни здравствени проверки и многу повеќе. Важна предност во однос на NGINX Ingress е целосната поддршка за сообраќајот TCP / UDP (и во верзијата на заедницата исто така!). Минус - функција за дистрибуција на сообраќај, која, сепак, „има најголем приоритет за програмерите“, но потребно е време да се имплементира.
Конг Влез
Веб страна:
Лиценца: Apache 2.0
Производ развиен од Kong Inc. во две верзии: комерцијална и бесплатна. Врз основа на nginx, кој е проширен со голем број модули Lua.
Првично, тој беше фокусиран на обработка и рутирање на барања за API, т.е. како API Gateway, но во моментот тој стана полноправен Ingress контролер. Главни предности: многу дополнителни модули (вклучувајќи ги и оние од трети лица програмери) кои се лесни за инсталирање и конфигурирање и со помош на кои се имплементира широк опсег на дополнителни функции. Сепак, вградените функции веќе нудат многу можности. Конфигурацијата на работата се врши со користење на CRD ресурси.
Важна карактеристика на производот - работењето во иста контура (наместо вкрстен простор) е контроверзна тема: за некои тоа ќе изгледа како недостаток (мора да произведувате ентитети за секоја контура), а за некого тоа е карактеристика ( боПоголемо ниво на изолација, како ако еден контролер е скршен, тогаш проблемот е ограничен само на колото).
Траефик
Веб страна:
Лиценца: MIT
Прокси кој првично беше создаден да работи со рутирање на барања за микросервисите и нивната динамична средина. Оттука, многу корисни функции: ажурирање на конфигурацијата без воопшто да се рестартира, поддршка за голем број методи за балансирање, веб-интерфејс, проследување метрика, поддршка за различни протоколи, REST API, изданија на канари и многу повеќе. Друга убава карактеристика е поддршката за Let's Encrypt сертификати надвор од кутијата. Недостаток е што за да се организира висока достапност (HA), контролорот ќе треба да инсталира и поврзе сопствено складирање KV.
HAProxy
Веб страна:
Лиценца: Apache 2.0
HAProxy одамна е познат како прокси и сообраќаен балансер. Како дел од кластерот Kubernetes, нуди „меко“ ажурирање на конфигурацијата (без губење на сообраќај), откривање на услуги базирано на DNS, динамична конфигурација со помош на API. Може да биде привлечно целосното прилагодување на шаблонот за конфигурација со замена на CM, како и можноста за користење на функциите на библиотеката Sprig во него. Генерално, главниот акцент на решението е на големата брзина, неговата оптимизација и ефикасноста во потрошените ресурси. Предноста на контролорот е поддршката на рекорден број на различни методи за балансирање.
Војаџер
Веб страна:
Лиценца: Apache 2.0
Врз основа на HAproxy контролер, кој е позициониран како универзално решение кое поддржува широк опсег на функции на голем број провајдери. Се нуди можност за балансирање на сообраќајот на L7 и L4, а балансирањето на сообраќајот TCP L4 како целина може да се нарече една од клучните карактеристики на решението.
Контура
Веб страна:
Лиценца: Apache 2.0
Ова решение не се заснова само на Envoy: тоа беше развиено од заеднички со авторите на овој популарен прокси. Важна карактеристика е способноста да се одвои контролата на ресурсите на Ingress со користење на ресурсите на IngressRoute CRD. За организации со многу развојни тимови кои го користат истиот кластер, ова помага да се зголеми безбедноста на работата со сообраќајот во соседните циклуси и да се заштитат од грешки при менување на ресурсите на Ingress.
Исто така, нуди проширен сет на методи за балансирање (постои пресликување на барања, автоматско повторување, ограничување на стапката на барања и многу повеќе), детално следење на протокот на сообраќај и неуспеси. Можеби за некој ќе биде значаен недостаток недостатокот на поддршка за лепливи сесии (иако работата ).
Истио Ингрес
Веб страна:
Лиценца: Apache 2.0
Сеопфатно сервисно мрежно решение кое не е само контролер Ingress кој управува со дојдовниот сообраќај однадвор, туку го контролира и целиот сообраќај во кластерот. Под хаубата, Envoy се користи како полномошник за секоја услуга. Во суштина, ова е голем комбинат кој „може да направи сè“, а неговата главна идеја е максимална управливост, проширување, безбедност и транспарентност. Со него, можете фино да го прилагодите насочувањето на сообраќајот, да пристапите до овластување помеѓу услугите, балансирањето, следењето, ослободувањата на канари и многу повеќе. Прочитајте повеќе за Истио во серијата написи "".
амбасадорот
Веб страна:
Лиценца: Apache 2.0
Друго решение засновано на Envoy. Има бесплатни и комерцијални верзии. Тој е позициониран како „целосно мајчин на Кубернетес“, што ги носи соодветните предности (тесна интеграција со методите и ентитетите на кластерот K8s).
Табела за споредување
Значи, кулминацијата на статијата е оваа огромна табела:
Може да се кликне за поблизок приказ, а достапен е и во формат .
да резимираме
Целта на оваа статија е да обезбеди поцелосно разбирање (сепак, во никој случај не е исцрпно!) за тоа каков избор да се направи во вашиот конкретен случај. Како и обично, секој контролер има свои предности и недостатоци…
Класичниот Ingress од Kubernetes е добар за неговата достапност и докажаност, доволно богати карактеристики - во општ случај, треба да биде „доволно за очи“. Меѓутоа, ако има зголемени барања за стабилност, ниво на карактеристики и развој, треба да обрнете внимание на Ingress со NGINX Plus и платена претплата. Конг има најбогат сет на приклучоци (и, соодветно, можностите што ги даваат), а во платената верзија има уште повеќе од нив. Има многу можности за работа како API Gateway, динамична конфигурација базирана на CRD ресурси, како и основни услуги на Kubernetes.
Со зголемени барања за методи за балансирање и авторизација, погледнете ги Traefik и HAProxy. Станува збор за проекти со отворен код, докажани низ годините, многу стабилни и активно се развиваат. Contour е излезен веќе неколку години, но сè уште изгледа премногу младо и има само основни карактеристики додадени на врвот на Envoy. Ако има барања за присуство / вградување на WAF пред апликацијата, треба да обрнете внимание на истиот Ingress од Kubernetes или HAProxy.
А најбогати според карактеристиките се производите изградени на врвот на Envoy, особено Istio. Се чини дека е сеопфатно решение кое „може да направи сè“, што, сепак, значи и значително повисок влезен праг за конфигурација / лансирање / администрација од другите решенија.
Избравме и сè уште користиме Ingress од Kubernetes како стандарден контролер, кој покрива 80-90% од потребите. Тој е доста сигурен, лесен за конфигурирање и проширување. Општо земено, во отсуство на специфични барања, треба да одговара на повеќето кластери / апликации. Од истите универзални и релативно едноставни производи, може да се препорачаат Traefik и HAProxy.
PS
Прочитајте и на нашиот блог:
- „Назад кон микросервисите со Истио“: , , ;
- «";
- «".
Извор: www.habr.com