Yleiskatsaus ja vertailu Kubernetesin Ingress-ohjaimista

Yleiskatsaus ja vertailu Kubernetesin Ingress-ohjaimista

Kun käynnistät Kubernetes-klusterin tietylle sovellukselle, sinun on ymmärrettävä, mitä itse sovellus, yritys ja kehittäjät tuovat tälle resurssille. Näillä tiedoilla voit aloittaa arkkitehtonisen päätöksen tekemisen ja erityisesti tietyn Ingress-ohjaimen valitsemisen, jota on jo nyt paljon. Saadaksemme peruskäsityksen käytettävissä olevista vaihtoehdoista ilman, että sinun tarvitsee käydä läpi paljon artikkeleita / dokumentaatiota jne., olemme laatineet tämän yleiskatsauksen, joka sisältää tärkeimmät (tuotantovalmis) Ingress-ohjaimet.

Toivomme sen auttavan kollegoita arkkitehtonisen ratkaisun valinnassa - siitä tulee ainakin lähtökohta tarkemman tiedon ja käytännön kokeilujen hankkimiselle. Aiemmin tutkimme muita samankaltaisia ​​materiaaleja verkosta, ja kummallista kyllä, emme löytäneet ainuttakaan enemmän tai vähemmän täydellistä ja mikä tärkeintä - jäsenneltyä - arvostelua. Täytetään siis tämä aukko!

kriteerit

Periaatteessa vertailun tekemiseksi ja hyödyllisten tulosten saamiseksi sinun on ymmärrettävä aihealueen lisäksi myös erityinen luettelo kriteereistä, jotka määrittävät tutkimusvektorin. Teeskentelemättä analysoida kaikkia mahdollisia Ingress / Kubernetesin käyttötapauksia, yritimme korostaa yleisimpiä ohjaimia koskevia vaatimuksia - varaudu siihen, että joudut joka tapauksessa tutkimaan kaikki yksityiskohdat ja tiedot erikseen.

Mutta aloitan ominaisuuksista, jotka ovat tulleet niin tutuiksi, että ne otetaan käyttöön kaikissa ratkaisuissa eikä niitä oteta huomioon:

  • dynaaminen palveluiden etsiminen (palveluiden löytäminen);
  • SSL irtisanominen;
  • websockettien kanssa työskenteleminen.

Nyt vertailukohtiin:

Tuetut protokollat

Yksi perusvalinnan kriteereistä. Ohjelmistosi ei välttämättä toimi tavallisessa HTTP:ssä tai se saattaa vaatia useiden protokollien käyttöä samanaikaisesti. Jos kotelosi on epästandardi, muista ottaa tämä tekijä huomioon, jotta sinun ei tarvitse määrittää klusteria myöhemmin uudelleen. Kaikkien ohjainten tuettujen protokollien luettelo vaihtelee.

ohjelmisto ytimessä

On olemassa useita muunnelmia sovelluksista, joihin ohjain perustuu. Suosittuja ovat nginx, traefik, haproxy, envoy. Yleisesti ottaen sillä ei välttämättä ole paljoakaan vaikutusta siihen, miten liikennettä vastaanotetaan ja välitetään, mutta on aina hyödyllistä tietää mahdolliset vivahteet ja ominaisuudet "konepellin alla".

Liikenteen reititys

Minkä perusteella on mahdollista tehdä päätös liikenteen suunnasta tiettyyn palveluun? Yleensä nämä ovat isäntä ja polku, mutta myös muita mahdollisuuksia on.

Nimiavaruus klusterin sisällä

Nimiavaruus (nimiavaruus) - kyky jakaa loogisesti resursseja Kubernetesissa (esimerkiksi lavalla, tuotannossa jne.). On Ingress-ohjaimia, jotka on asennettava erikseen jokaiseen nimiavaruuteen (ja sitten se voi ohjata liikennettä vain tämän tilan paloihin). Ja on niitä (ja niiden selvä enemmistö), jotka toimivat globaalisti koko klusterin osalta - niissä liikenne ohjataan mihin tahansa klusterin ryhmään nimiavaruudesta riippumatta.

Näytteitä ylävirtaan

Miten liikenne ohjataan sovelluksen, palvelujen terveisiin esiintymiin? Vaihtoehtoja on aktiivisella ja passiivisella tarkistuksella, uudelleenyrityksellä, katkaisijalla (Katso lisätietoja esim. artikkeli Istiosta), terveystarkastusten omat toteutukset (mukautetut terveystarkastukset) jne. Erittäin tärkeä parametri, jos sinulla on korkeat vaatimukset saatavuudelle ja epäonnistuneiden palvelujen oikea-aikaiselle poistamiselle tasapainotuksesta.

Tasapainotusalgoritmit

Vaihtoehtoja on monia: perinteisestä pyöreä robin eksoottiseen rdp-eväste, sekä yksittäisiä ominaisuuksia, kuten tahmeat istunnot.

todennus

Mitä valtuutusjärjestelmiä rekisterinpitäjä tukee? Perus, digest, oauth, ulkoinen todennus – mielestäni näiden vaihtoehtojen pitäisi olla tuttuja. Tämä on tärkeä kriteeri, jos Ingressin kautta käytetään monia kehittäjäsilmukoita (ja/tai vain yksityisiä).

Liikenteen jakelu

Tukeeko ohjain sellaisia ​​yleisesti käytettyjä liikenteenjakomekanismeja, kuten canary rollouts (canary), A/B-testaus, liikenteen peilaus (peilaus/varjostus)? Tämä on todella kipeä aihe sovelluksille, jotka vaativat tarkkaa ja tarkkaa liikenteenhallintaa tuottavaan testaukseen, tuotevirheiden korjaamiseen offline-tilassa (tai minimaalisella tappiolla), liikenneanalyysiin ja niin edelleen.

Maksullinen tilaus

Onko ohjaimelle maksullinen vaihtoehto, jossa on edistyneitä toimintoja ja/tai tekninen tuki?

Graafinen käyttöliittymä (verkkokäyttöliittymä)

Onko olemassa graafista käyttöliittymää ohjaimen kokoonpanon hallintaan? Pääasiassa "kätevyydelle" ja/tai niille, jotka joutuvat tekemään joitain muutoksia Ingress'a-kokoonpanoon, mutta "raaka"-mallien kanssa työskentely on hankalaa. Siitä voi olla hyötyä, jos kehittäjät haluavat tehdä joitain kokeiluja liikenteestä lennossa.

JWT validointi

Sisäänrakennettu JSON-verkkotunnusten validointi käyttäjän valtuutusta ja validointia varten loppusovellukseen.

Mahdollisuudet asetusten mukauttamiseen

Mallin laajennettavuus siinä mielessä, että sinulla on mekanismeja, joiden avulla voit lisätä omia käskyjä, lippuja jne. vakiokonfiguraatiomalleihin.

DDOS-suojausmekanismit

Yksinkertaiset nopeusrajoitusalgoritmit tai monimutkaisemmat liikenteen suodatusvaihtoehdot, jotka perustuvat osoitteisiin, sallittuihin listoihin, maihin jne.

Pyydä jälkiä

Mahdollisuus valvoa, seurata ja virheenkorjaus Ingressien pyyntöjä tiettyihin palveluihin / podeihin ja ihanteellisesti myös palveluiden / podien välillä.

WAF

Tukea sovelluksen palomuuri.

Ohjaimet

Lista valvojista muodostettiin sen perusteella virallinen Kubernetes-dokumentaatio и tämä taulukko. Jätimme osan niistä pois tarkastelusta spesifisyyden tai alhaisen esiintyvyyden vuoksi (varhainen kehitysvaihe). Loput käsitellään alla. Aloitetaan ratkaisujen yleisellä kuvauksella ja jatketaan yhteenvetotaulukolla.

Sisääntulo Kubernetesilta

Kotisivu: github.com/kubernetes/ingress-nginx
Lisenssi: Apache 2.0

Tämä on Kubernetesin virallinen ohjain, ja sitä kehittää yhteisö. Ilmeisesti nimestä se perustuu nginxiin ja sitä täydentävät erilaiset Lua-laajennukset, joita käytetään lisäominaisuuksien toteuttamiseen. Itse nginxin suosion ja sen vähäisten muutosten vuoksi, kun sitä käytetään ohjaimena, tämä vaihtoehto voi olla helpoin ja helpoin määrittää tavalliselle insinöörille (verkkokokemuksella).

Ingress by NGINX Inc.

Kotisivu: github.com/nginxinc/kubernetes-ingress
Lisenssi: Apache 2.0

Nginx-kehittäjien virallinen tuote. Sillä on maksullinen versio, joka perustuu NGINX Plus. Pääideana on korkea vakaus, jatkuva yhteensopivuus taaksepäin, ulkoisten moduulien puuttuminen ja ilmoitettu lisääntynyt nopeus (verrattuna viralliseen ohjaimeen), joka saavutettiin Luan hylkäämisen vuoksi.

Ilmainen versio on huomattavasti pienempi, myös verrattuna viralliseen ohjaimeen (samojen Lua-moduulien puuttumisen vuoksi). Samaan aikaan maksullisessa on melko laaja lisätoiminto: reaaliaikaiset mittarit, JWT-validointi, aktiiviset terveystarkastukset ja paljon muuta. Tärkeä etu NGINX Ingressiin verrattuna on täysi tuki TCP / UDP-liikenteelle (ja myös yhteisöversiossa!). Miinus - poissaolo liikenteen jakeluominaisuus, joka kuitenkin "on kehittäjille korkein prioriteetti", mutta sen käyttöönotto vie aikaa.

Kong Ingress

Kotisivu: github.com/Kong/kubernetes-ingress-controller
Lisenssi: Apache 2.0

Tuotteen on kehittänyt Kong Inc. kahdessa versiossa: kaupallinen ja ilmainen. Perustuu nginxiin, jota on laajennettu suurella määrällä Lua-moduuleja.

Aluksi se keskittyi API-pyyntöjen käsittelyyn ja reitittämiseen, ts. API-yhdyskäytävänä, mutta tällä hetkellä siitä on tullut täysimittainen Ingress-ohjain. Tärkeimmät edut: monet lisämoduulit (mukaan lukien kolmansien osapuolien kehittäjät), jotka on helppo asentaa ja konfiguroida ja joiden avulla toteutetaan laaja valikoima lisäominaisuuksia. Sisäänrakennetut toiminnot tarjoavat kuitenkin jo monia mahdollisuuksia. Työn konfigurointi tehdään CRD-resurssien avulla.

Tärkeä tuotteen ominaisuus - saman ääriviivan sisällä työskentely (ristinimiavaruuden sijaan) on kiistanalainen aihe: joillekin se vaikuttaa haitalta (joille on tuotettava kokonaisuudet jokaiselle ääriviivalle), ja jollekin se on ominaisuus ( bоSuurempi eristyksen taso, kuten jos yksi ohjain on rikki, ongelma rajoittuu pelkästään piiriin).

Traefik

Kotisivu: github.com/containous/traefik
Lisenssi: MIT

Välityspalvelin, joka luotiin alun perin toimimaan mikropalveluiden ja niiden dynaamisen ympäristön pyyntöreitityksen kanssa. Tästä syystä monia hyödyllisiä ominaisuuksia: kokoonpanon päivittäminen ilman uudelleenkäynnistystä, tuki useille tasapainotusmenetelmille, verkkokäyttöliittymä, mittareiden edelleenlähetys, tuki eri protokollille, REST API, kanarian julkaisut ja paljon muuta. Toinen mukava ominaisuus on tuki Let's Encrypt -sertifikaateille heti valmiina. Haittapuolena on, että korkean käytettävyyden (HA) järjestämiseksi ohjaimen on asennettava ja liitettävä oma KV-tallennus.

HAProxy

Kotisivu: github.com/jcmoraisjr/haproxy-ingress
Lisenssi: Apache 2.0

HAProxy on pitkään tunnettu välityspalvelimena ja liikenteen tasapainottajana. Osana Kubernetes-klusteria se tarjoaa "pehmeän" kokoonpanopäivityksen (ilman liikenteen menetystä), DNS-pohjaisen palvelun etsinnän ja dynaamisen konfiguroinnin API:n avulla. Voi olla houkuttelevaa mukauttaa konfigurointimalli kokonaan korvaamalla CM, samoin kuin mahdollisuus käyttää siinä olevia Sprig-kirjastotoimintoja. Yleisesti ottaen ratkaisun pääpaino on suuressa nopeudessa, sen optimoinnissa ja kulutettujen resurssien tehokkuudessa. Säätimen etuna on tuki ennätysmäärälle erilaisia ​​tasapainotusmenetelmiä.

Matkaaja

Kotisivu: github.com/appscode/voyager
Lisenssi: Apache 2.0

Perustuu HAproxy-ohjaimeen, joka on sijoitettu universaaliksi ratkaisuksi, joka tukee monenlaisia ​​ominaisuuksia useilla palveluntarjoajilla. Tarjotaan mahdollisuus L7- ja L4-liikenteen tasapainottamiseen, ja TCP L4 -liikenteen tasapainottamista kokonaisuutena voidaan kutsua yhdeksi ratkaisun avainominaisuuksista.

Muoto

Kotisivu: github.com/heptio/contour
Lisenssi: Apache 2.0

Tämä ratkaisu ei perustu pelkästään Envoyyn: sen on kehittänyt yhteisesti tämän suositun välityspalvelimen tekijöiden kanssa. Tärkeä ominaisuus on kyky erottaa Ingress-resurssien ohjaus IngressRoute CRD -resurssien avulla. Organisaatioille, joissa on useita kehitystiimejä, jotka käyttävät samaa klusteria, tämä auttaa maksimoimaan naapurisilmukoiden liikenteen kanssa työskentelyn turvallisuuden ja suojaamaan niitä virheiltä, ​​kun muutetaan Ingress-resursseja.

Se tarjoaa myös laajennetun joukon tasapainotusmenetelmiä (on pyyntöjen peilaus, automaattinen toisto, pyyntöjen taajuuden rajoittaminen ja paljon muuta), yksityiskohtaisen liikennevirran ja vikojen seurannan. Ehkä jollekin se on merkittävä haittapuoli tahmeiden istuntojen tuen puute (vaikka työ jo käynnissä).

Istio Ingress

Kotisivu: istio.io/docs/tasks/traffic-management/ingress
Lisenssi: Apache 2.0

Kattava palveluverkkoratkaisu, joka ei ole vain Ingress-ohjain, joka hallitsee tulevaa liikennettä ulkopuolelta, vaan ohjaa myös kaikkea klusterin sisäistä liikennettä. Konepellin alla Envoyta käytetään sivuvaunun välityspalvelimena jokaiselle palvelulle. Pohjimmiltaan tämä on iso yhdistelmä, joka "tekee mitä tahansa", ja sen pääideana on maksimaalinen hallittavuus, laajennettavuus, turvallisuus ja läpinäkyvyys. Sen avulla voit hienosäätää liikenteen reititystä, käyttöoikeuksia palveluiden välillä, tasapainotusta, valvontaa, kanarian julkaisuja ja paljon muuta. Lue lisää Istiosta artikkelisarjasta "Takaisin mikropalveluihin Istion kanssa'.

Lähettilääksi

Kotisivu: github.com/datawire/ambassador
Lisenssi: Apache 2.0

Toinen ratkaisu, joka perustuu Envoyyn. Siitä on ilmaisia ​​ja kaupallisia versioita. Se on sijoitettu "täysin natiiviksi Kubernetesille", mikä tuo vastaavat edut (tiukka integraatio K8s-klusterin menetelmien ja kokonaisuuksien kanssa).

vertailutaulukko

Joten artikkelin huipentuma on tämä valtava taulukko:

Yleiskatsaus ja vertailu Kubernetesin Ingress-ohjaimista

Sitä voi klikata lähempää katsomista varten, ja se on saatavana myös muodossa Google-arkkia.

Yhteenvetona

Tämän artikkelin tarkoituksena on tarjota täydellisempi käsitys (ei kuitenkaan missään nimessä tyhjentävä!) siitä, mikä valinta sinun tapauksessasi kannattaa tehdä. Kuten tavallista, jokaisella ohjaimella on omat etunsa ja haittansa…

Klassinen Kubernetesin Ingress on hyvä saatavuutensa ja todistetusti, riittävän rikkaiden ominaisuuksiensa vuoksi - yleensä sen pitäisi olla "riittää silmille". Jos vakaudelle, ominaisuuksien tasolle ja kehitykselle on kuitenkin kohonneita vaatimuksia, sinun tulee kiinnittää huomiota Ingressiin, jossa on NGINX Plus ja maksullinen tilaus. Kongilla on rikkain joukko laajennuksia (ja vastaavasti niiden tarjoamat mahdollisuudet), ja maksullisessa versiossa niitä on vielä enemmän. Sillä on runsaasti mahdollisuuksia toimia API-yhdyskäytävänä, CRD-resursseihin perustuva dynaaminen konfigurointi sekä Kubernetes-peruspalvelut.

Kun tasapainotus- ja valtuutusmenetelmiä koskevat vaatimukset ovat lisääntyneet, katso Traefik ja HAProxy. Nämä ovat avoimen lähdekoodin projekteja, jotka ovat osoittautuneet vuosien varrella, erittäin vakaita ja aktiivisesti kehittyviä. Contour on ollut ulkona nyt pari vuotta, mutta se näyttää edelleen liian nuorelta ja siihen on lisätty Envoyn päälle vain perusominaisuuksia. Jos sovelluksen edessä on WAF:n läsnäolo / upottaminen, sinun tulee kiinnittää huomiota samaan Kubernetesin tai HAProxyn sisääntuloon.

Ja ominaisuuksiltaan rikkaimpia ovat Envoyn päälle rakennetut tuotteet, erityisesti Istio. Vaikuttaa siltä, ​​että se on kattava ratkaisu, joka "voi tehdä mitä tahansa", mikä kuitenkin tarkoittaa myös huomattavasti korkeampaa pääsykynnystä konfigurointiin / käynnistämiseen / hallintaan kuin muut ratkaisut.

Olemme valinneet ja käytämme edelleen Kubernetesin Ingressiä vakioohjaimeksi, joka kattaa 80-90 % tarpeista. Se on melko luotettava, helppo konfiguroida ja laajentaa. Yleisesti ottaen erityisvaatimusten puuttuessa sen pitäisi sopia useimpiin klustereihin/sovelluksiin. Samoista yleisistä ja suhteellisen yksinkertaisista tuotteista voidaan suositella Traefikia ja HAProxya.

PS.

Lue myös blogistamme:

Lähde: will.com

Lisää kommentti