Pangkalahatang-ideya at paghahambing ng Ingress controllers para sa Kubernetes

Pangkalahatang-ideya at paghahambing ng Ingress controllers para sa Kubernetes

Kapag naglulunsad ng Kubernetes cluster para sa isang partikular na application, kailangan mong maunawaan kung ano mismo ang inilalagay ng application, negosyo, at mga developer sa mapagkukunang ito. Sa impormasyong ito, maaari kang magsimulang gumawa ng isang desisyon sa arkitektura at, sa partikular, pagpili ng isang partikular na Ingress controller, kung saan mayroon nang malaking bilang ngayon. Upang makakuha ng isang pangunahing ideya ng mga magagamit na pagpipilian nang hindi kinakailangang dumaan sa maraming mga artikulo / dokumentasyon, atbp., inihanda namin ang pangkalahatang-ideya na ito, kasama ang pangunahing (handa na sa produksyon) na mga controller ng Ingress.

Inaasahan namin na makakatulong ito sa mga kasamahan sa pagpili ng isang solusyon sa arkitektura - hindi bababa sa ito ay magiging isang panimulang punto para sa pagkuha ng mas detalyadong impormasyon at praktikal na mga eksperimento. Noong nakaraan, pinag-aralan namin ang iba pang mga katulad na materyales sa net at, kakatwa, hindi nakahanap ng isang solong higit pa o hindi gaanong kumpleto, at pinaka-mahalaga - nakabalangkas - pagsusuri. Kaya punan natin ang puwang na iyon!

criteria

Sa prinsipyo, upang makagawa ng isang paghahambing at makakuha ng anumang kapaki-pakinabang na resulta, kailangan mong maunawaan hindi lamang ang lugar ng paksa, ngunit mayroon ding isang tiyak na listahan ng mga pamantayan na magtatakda ng vector ng pananaliksik. Nang hindi nagkukunwaring pag-aralan ang lahat ng posibleng kaso ng paggamit ng Ingress / Kubernetes, sinubukan naming i-highlight ang pinaka-pangkalahatang mga kinakailangan para sa mga controllers - maging handa na sa anumang kaso kailangan mong pag-aralan ang lahat ng iyong mga detalye at detalye nang hiwalay.

Ngunit magsisimula ako sa mga katangian na naging pamilyar na ang mga ito ay ipinatupad sa lahat ng mga solusyon at hindi isinasaalang-alang:

  • dynamic na pagtuklas ng mga serbisyo (service discovery);
  • Pagwawakas ng SSL;
  • nagtatrabaho sa mga websocket.

Ngayon para sa mga punto ng paghahambing:

Mga suportadong protocol

Isa sa mga pangunahing pamantayan sa pagpili. Maaaring hindi gumana ang iyong software sa karaniwang HTTP, o maaaring mangailangan ito ng trabaho sa maraming protocol nang sabay-sabay. Kung hindi karaniwan ang iyong kaso, tiyaking isaalang-alang ang salik na ito para hindi mo na kailangang muling i-configure ang cluster sa ibang pagkakataon. Para sa lahat ng controller, nag-iiba ang listahan ng mga sinusuportahang protocol.

software sa core

Mayroong ilang mga pagkakaiba-iba ng mga application kung saan nakabatay ang controller. Ang mga sikat ay nginx, traefik, haproxy, envoy. Sa pangkalahatang kaso, maaaring wala itong gaanong epekto sa kung paano natatanggap at ipinadala ang trapiko, ngunit palaging kapaki-pakinabang na malaman ang mga potensyal na nuances at mga tampok ng kung ano ang "sa ilalim ng hood".

Pagruruta ng trapiko

Sa batayan ng kung ano ang posibleng gumawa ng desisyon tungkol sa direksyon ng trapiko sa isang partikular na serbisyo? Kadalasan ang mga ito ay host at landas, ngunit may mga karagdagang posibilidad.

Namespace sa loob ng isang cluster

Namespace (namespace) - ang kakayahang lohikal na hatiin ang mga mapagkukunan sa Kubernetes (halimbawa, sa entablado, produksyon, atbp.). May mga Ingress controller na dapat na naka-install nang hiwalay sa bawat namespace (at pagkatapos ay maaari itong magdirekta ng trapiko lamang sa mga pod ng espasyong ito). At mayroong mga (at ang kanilang malinaw na karamihan) na gumagana sa buong mundo para sa buong cluster - sa kanila ang trapiko ay nakadirekta sa anumang pod ng cluster, anuman ang namespace.

Mga sample para sa upstream

Paano nakadirekta ang trapiko sa malusog na mga pagkakataon ng aplikasyon, mga serbisyo? May mga opsyon na may aktibo at passive na mga pagsusuri, muling pagsubok, mga circuit breaker (Para sa higit pang mga detalye, tingnan, halimbawa, artikulo tungkol kay Istio), sariling pagpapatupad ng mga pagsusuri sa kalusugan (mga custom na pagsusuri sa kalusugan), atbp. Isang napakahalagang parameter kung mayroon kang mataas na mga kinakailangan para sa availability at napapanahong pag-alis ng mga nabigong serbisyo mula sa pagbabalanse.

Pagbabalanse ng mga algorithm

Mayroong maraming mga pagpipilian: mula sa tradisyonal bilog-robin sa exotic rdp-cookie, pati na rin ang mga indibidwal na tampok tulad ng malagkit na mga sesyon.

Pagpapatunay

Anong mga scheme ng pahintulot ang sinusuportahan ng controller? Basic, digest, oauth, external-auth - Sa tingin ko ay dapat pamilyar ang mga opsyong ito. Ito ay isang mahalagang criterion kung maraming developer (at/o pribado lang) na mga loop na naa-access sa pamamagitan ng Ingress.

Pamamahagi ng trapiko

Sinusuportahan ba ng controller ang mga karaniwang ginagamit na mekanismo ng pamamahagi ng trapiko gaya ng mga canary rollout (canary), A/B testing, traffic mirroring (mirroring / shadowing)? Ito ay talagang masakit na paksa para sa mga application na nangangailangan ng tumpak at tumpak na pamamahala ng trapiko para sa produktibong pagsubok, pag-debug ng mga bug ng produkto nang off-line (o may kaunting pagkawala), pagsusuri sa trapiko, at iba pa.

Bayad na subscription

Mayroon bang bayad na opsyon para sa controller, na may advanced na functionality at / o teknikal na suporta?

Graphical na interface ng gumagamit (Web UI)

Mayroon bang anumang GUI upang pamahalaan ang pagsasaayos ng controller? Pangunahin para sa "kahusayan" at / o para sa mga kailangang gumawa ng ilang mga pagbabago sa pagsasaayos ng Ingress'a, ngunit ang pagtatrabaho sa "raw" na mga template ay hindi maginhawa. Maaari itong maging kapaki-pakinabang kung gusto ng mga developer na magsagawa ng ilang mga eksperimento sa trapiko nang mabilis.

Pagpapatunay ng JWT

Ang pagkakaroon ng built-in na pagpapatunay ng mga JSON web token para sa pahintulot at pagpapatunay ng user hanggang sa pagtatapos ng aplikasyon.

Mga posibilidad para sa pagpapasadya ng config

Extensibility ng template sa kahulugan ng pagkakaroon ng mga mekanismo na nagbibigay-daan sa iyong magdagdag ng sarili mong mga direktiba, flag, atbp. sa mga karaniwang template ng configuration.

Mga pangunahing mekanismo ng proteksyon ng DDOS

Mga simpleng algorithm ng limitasyon sa rate o mas kumplikadong mga opsyon sa pag-filter ng trapiko batay sa mga address, whitelist, bansa, atbp.

Humiling ng bakas

Ang kakayahang subaybayan, subaybayan at i-debug ang mga kahilingan mula sa Ingresses hanggang sa mga partikular na serbisyo/pod, at sa perpektong pagitan din ng mga serbisyo/pod.

WAF

Suporta firewall ng application.

Mga Controller

Ang listahan ng mga controller ay nabuo batay sa opisyal na dokumentasyon ng Kubernetes ΠΈ talahanayan na ito. Ibinukod namin ang ilan sa mga ito mula sa pagsusuri dahil sa pagiging tiyak o mababang pagkalat (maagang yugto ng pag-unlad). Ang natitira ay tinalakay sa ibaba. Magsimula tayo sa isang pangkalahatang paglalarawan ng mga solusyon at magpatuloy sa isang talahanayan ng buod.

Ingress mula sa Kubernetes

Website: github.com/kubernetes/ingress-nginx
Lisensya: Apache 2.0

Ito ang opisyal na controller para sa Kubernetes at binuo ng komunidad. Malinaw na mula sa pangalan, ito ay batay sa nginx at kinumpleto ng ibang hanay ng mga plugin ng Lua na ginagamit upang ipatupad ang mga karagdagang feature. Dahil sa kasikatan ng nginx mismo at kaunting pagbabago dito kapag ginamit bilang controller, ang opsyon na ito ay maaaring ang pinakamadali at pinakamadaling i-configure para sa karaniwang engineer (na may karanasan sa web).

Ingress ng NGINX Inc.

Website: github.com/nginxinc/kubernetes-ingress
Lisensya: Apache 2.0

Ang opisyal na produkto ng mga developer ng nginx. May bayad na bersyon batay sa NGINX Plus. Ang pangunahing ideya ay isang mataas na antas ng katatagan, patuloy na pabalik na pagkakatugma, ang kawalan ng anumang mga extraneous na module at ang ipinahayag na pagtaas ng bilis (kumpara sa opisyal na controller), na nakamit dahil sa pagtanggi kay Lua.

Ang libreng bersyon ay makabuluhang nabawasan, kabilang ang kahit na inihambing sa opisyal na controller (dahil sa kakulangan ng parehong mga module ng Lua). Kasabay nito, ang binabayaran ay may medyo malawak na karagdagang pag-andar: mga real-time na sukatan, pagpapatunay ng JWT, aktibong pagsusuri sa kalusugan, at higit pa. Ang isang mahalagang bentahe sa NGINX Ingress ay ang buong suporta para sa trapiko ng TCP / UDP (at sa bersyon din ng komunidad!). Minus - kawalan tampok na pamamahagi ng trapiko, na, gayunpaman, "may pinakamataas na priyoridad para sa mga developer," ngunit nangangailangan ng oras upang maipatupad.

Kong Ingress

Website: github.com/Kong/kubernetes-ingress-controller
Lisensya: Apache 2.0

Produktong binuo ng Kong Inc. sa dalawang bersyon: komersyal at libre. Batay sa nginx, na pinalawig na may malaking bilang ng mga module ng Lua.

Sa una, ito ay nakatuon sa pagproseso at pagruruta ng mga kahilingan sa API, i.e. bilang isang API Gateway, ngunit sa ngayon ito ay naging ganap na Ingress controller. Mga pangunahing bentahe: maraming karagdagang mga module (kabilang ang mga mula sa mga third-party na developer) na madaling i-install at i-configure at sa tulong ng kung saan ang isang malawak na hanay ng mga karagdagang tampok ay ipinatupad. Gayunpaman, ang mga built-in na function ay nag-aalok na ng maraming posibilidad. Ginagawa ang pagsasaayos ng trabaho gamit ang mga mapagkukunan ng CRD.

Ang isang mahalagang tampok ng produkto - ang pagtatrabaho sa loob ng parehong contour (sa halip na cross-namespaced) ay isang kontrobersyal na paksa: para sa ilan ito ay mukhang isang kawalan (kailangan mong gumawa ng mga entity para sa bawat contour), at para sa isang tao ito ay isang tampok ( bΠΎMas mataas na antas ng paghihiwalay, bilang kung ang isang controller ay nasira, kung gayon ang problema ay limitado sa circuit lamang).

Traefik

Website: github.com/containous/traefik
Lisensya: MIT

Isang proxy na orihinal na nilikha upang gumana sa pagruruta ng kahilingan para sa mga microservice at ang kanilang dynamic na kapaligiran. Kaya, maraming kapaki-pakinabang na feature: pag-update ng configuration nang hindi nagre-reboot, suporta para sa maraming paraan ng pagbabalanse, web interface, pagpapasa ng sukatan, suporta para sa iba't ibang protocol, REST API, paglabas ng canary, at marami pang iba. Ang isa pang magandang tampok ay ang suporta para sa Let's Encrypt na mga certificate sa labas ng kahon. Ang kawalan ay upang maisaayos ang mataas na kakayahang magamit (HA), ang controller ay kailangang i-install at ikonekta ang sarili nitong KV storage.

HAProxy

Website: github.com/jcmoraisjr/haproxy-ingress
Lisensya: Apache 2.0

Matagal nang kilala ang HAProxy bilang proxy at traffic balancer. Bilang bahagi ng isang cluster ng Kubernetes, nag-aalok ito ng "malambot" na pag-update ng configuration (nang walang pagkawala ng trapiko), pagtuklas ng serbisyo batay sa DNS, dynamic na configuration gamit ang API. Maaari itong maging kaakit-akit na ganap na i-customize ang template ng config sa pamamagitan ng pagpapalit ng CM, pati na rin ang kakayahang gumamit ng mga function ng Sprig library dito. Sa pangkalahatan, ang pangunahing diin ng solusyon ay ang mataas na bilis, ang pag-optimize nito at ang kahusayan sa mga natupok na mapagkukunan. Ang bentahe ng controller ay ang suporta ng isang record number ng iba't ibang paraan ng pagbabalanse.

Manlalakbay

Website: github.com/appscode/voyager
Lisensya: Apache 2.0

Batay sa HAproxy controller, na nakaposisyon bilang isang unibersal na solusyon na sumusuporta sa malawak na hanay ng mga feature sa malaking bilang ng mga provider. Ang isang pagkakataon ay inaalok para sa pagbabalanse ng trapiko sa L7 at L4, at ang pagbabalanse ng TCP L4 na trapiko sa kabuuan ay matatawag na isa sa mga pangunahing tampok ng solusyon.

Tabas

Website: github.com/heptio/contour
Lisensya: Apache 2.0

Ang solusyon na ito ay hindi lamang batay sa Envoy: ito ay binuo ni magkasama kasama ang mga may-akda ng sikat na proxy na ito. Ang isang mahalagang tampok ay ang kakayahang paghiwalayin ang kontrol ng mga mapagkukunan ng Ingress gamit ang mga mapagkukunan ng IngressRoute CRD. Para sa mga organisasyong may maraming development team na gumagamit ng parehong cluster, nakakatulong ito na i-maximize ang seguridad ng pagtatrabaho sa trapiko sa mga kalapit na loop at protektahan sila mula sa mga error kapag binabago ang mga mapagkukunan ng Ingress.

Nag-aalok din ito ng pinahabang hanay ng mga paraan ng pagbabalanse (mayroong pag-mirror ng kahilingan, awtomatikong pag-uulit, paglilimita sa rate ng kahilingan, at marami pang iba), detalyadong pagsubaybay sa daloy ng trapiko at mga pagkabigo. Marahil para sa isang tao ay magiging isang makabuluhang disbentaha ang kakulangan ng suporta para sa malagkit na mga sesyon (bagaman ang trabaho ginagawa na).

Istio Ingress

Website: istio.io/docs/tasks/traffic-management/ingress
Lisensya: Apache 2.0

Isang komprehensibong solusyon sa mesh ng serbisyo na hindi lamang isang Ingress controller na namamahala sa papasok na trapiko mula sa labas, ngunit kinokontrol din ang lahat ng trapiko sa loob ng cluster. Sa ilalim ng hood, ang Envoy ay ginagamit bilang sidecar proxy para sa bawat serbisyo. Sa esensya, ito ay isang malaking kumbinasyon na "maaaring gumawa ng anuman", at ang pangunahing ideya nito ay ang maximum na kakayahang pamahalaan, pagpapalawak, seguridad at transparency. Gamit ito, maaari mong i-fine-tune ang pagruruta ng trapiko, i-access ang pahintulot sa pagitan ng mga serbisyo, pagbabalanse, pagsubaybay, paglabas ng canary, at marami pang iba. Magbasa nang higit pa tungkol kay Istio sa serye ng mga artikulo "Bumalik sa mga microservice kasama si Istio'.

Ambasador

Website: github.com/datawire/ambassador
Lisensya: Apache 2.0

Isa pang solusyon batay sa Envoy. Mayroon itong libre at komersyal na mga bersyon. Ito ay nakaposisyon bilang "ganap na katutubong sa Kubernetes", na nagdadala ng kaukulang mga pakinabang (mahigpit na pagsasama sa mga pamamaraan at entity ng K8s cluster).

Paghahambing ng talahanayan

Kaya, ang paghantong ng artikulo ay ang malaking talahanayan na ito:

Pangkalahatang-ideya at paghahambing ng Ingress controllers para sa Kubernetes

Naki-click ito para sa mas malapit na pagtingin, at available din sa format Google Sheets.

upang ibuod

Ang layunin ng artikulong ito ay magbigay ng mas kumpletong pag-unawa (gayunpaman, hindi kumpleto!) kung anong pagpipilian ang gagawin sa iyong partikular na kaso. Gaya ng dati, ang bawat controller ay may sariling mga pakinabang at disadvantages...

Ang klasikong Ingress mula sa Kubernetes ay mabuti para sa pagkakaroon at pagiging napatunayan nito, sapat na mayaman na mga tampok - sa pangkalahatang kaso, dapat itong "sapat para sa mga mata". Gayunpaman, kung mayroong tumaas na mga kinakailangan para sa katatagan, ang antas ng mga tampok at pag-unlad, dapat mong bigyang pansin ang Ingress na may NGINX Plus at isang bayad na subscription. Si Kong ang may pinakamayamang hanay ng mga plug-in (at, nang naaayon, ang mga pagkakataong ibinibigay nila), at sa bayad na bersyon ay mas marami pa sa kanila. Ito ay may sapat na pagkakataon upang gumana bilang isang API Gateway, dynamic na configuration batay sa mga mapagkukunan ng CRD, pati na rin ang mga pangunahing serbisyo ng Kubernetes.

Sa pagtaas ng mga kinakailangan para sa pagbabalanse at mga pamamaraan ng awtorisasyon, tingnan ang Traefik at HAProxy. Ito ay mga Open Source na proyekto, napatunayan sa paglipas ng mga taon, napaka-stable at aktibong umuunlad. Ilang taon nang lumabas ang contour, ngunit mukhang napakabata pa rin nito at mayroon lamang mga pangunahing feature na idinagdag sa ibabaw ng Envoy. Kung may mga kinakailangan para sa presensya / pag-embed ng WAF sa harap ng application, dapat mong bigyang pansin ang parehong Ingress mula sa Kubernetes o HAProxy.

At ang pinakamayaman sa mga tuntunin ng mga tampok ay ang mga produktong binuo sa ibabaw ng Envoy, lalo na ang Istio. Tila ito ay isang komprehensibong solusyon na "magagawa ang anumang bagay", na, gayunpaman, ay nangangahulugan din ng isang makabuluhang mas mataas na threshold ng pagpasok para sa pagsasaayos / paglulunsad / pangangasiwa kaysa sa iba pang mga solusyon.

Pinili at ginagamit pa rin namin ang Ingress mula sa Kubernetes bilang karaniwang controller, na sumasaklaw sa 80-90% ng mga pangangailangan. Ito ay lubos na maaasahan, madaling i-configure at palawakin. Sa pangkalahatan, sa kawalan ng mga partikular na kinakailangan, dapat itong angkop sa karamihan ng mga kumpol / aplikasyon. Sa parehong unibersal at medyo simpleng mga produkto, maaaring irekomenda ang Traefik at HAProxy.

PS

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Magdagdag ng komento