Ingress կարգավորիչների ակնարկ և համեմատություն Kubernetes-ի համար

Հատուկ հավելվածի համար Kubernetes կլաստերը գործարկելիս դուք պետք է հասկանաք, թե ինչ են ներկայացնում հենց հավելվածը, բիզնեսը և մշակողները այս ռեսուրսին: Այս տեղեկատվության շնորհիվ կարող եք սկսել ճարտարապետական ​​որոշում կայացնել և, մասնավորապես, ընտրել կոնկրետ Ingress կարգավորիչ, որն այսօր արդեն մեծ թիվ է կազմում։ Առանց բազմաթիվ հոդվածների / փաստաթղթերի և այլնի միջով անցնելու անհրաժեշտության հիմնական պատկերացում կազմելու համար, մենք պատրաստել ենք այս ակնարկը, ներառյալ հիմնական (արտադրության պատրաստ) Ingress կարգավորիչները:

Հուսով ենք, որ դա կօգնի գործընկերներին ճարտարապետական ​​լուծում ընտրելու հարցում. համենայնդեպս այն կդառնա ավելի մանրամասն տեղեկատվություն ստանալու և գործնական փորձերի մեկնարկային կետ: Նախկինում մենք ուսումնասիրել էինք նմանատիպ այլ նյութեր ցանցում և, որքան էլ տարօրինակ է, չգտանք ոչ մի քիչ թե շատ ամբողջական, և ամենակարևորը` կառուցվածքային ակնարկ: Այսպիսով, եկեք լրացնենք այդ բացը:

Չափանիշներ

Սկզբունքորեն, համեմատություն անելու և որևէ օգտակար արդյունք ստանալու համար հարկավոր է հասկանալ ոչ միայն առարկայական ոլորտը, այլև ունենալ չափանիշների կոնկրետ ցանկ, որոնք կսահմանեն հետազոտության վեկտորը: Չհավակնելով վերլուծել Ingress/Kubernetes-ի օգտագործման բոլոր հնարավոր դեպքերը, մենք փորձեցինք ընդգծել կարգավորիչներին ներկայացվող ամենաընդհանուր պահանջները. պատրաստ եղեք, որ ամեն դեպքում ստիպված կլինեք առանձին ուսումնասիրել ձեր բոլոր առանձնահատկություններն ու մանրամասները:

Բայց ես կսկսեմ բնութագրերից, որոնք այնքան ծանոթ են դարձել, որ դրանք ներդրված են բոլոր լուծումներում և հաշվի չեն առնվում.

• ծառայությունների դինամիկ հայտնաբերում (ծառայության հայտնաբերում);
• SSL դադարեցում;
• աշխատել վեբ վարդակների հետ:

Հիմա համեմատության կետերի մասին.

Աջակցվող արձանագրություններ

Ընտրության հիմնարար չափանիշներից մեկը. Ձեր ծրագրաշարը կարող է չաշխատել ստանդարտ HTTP-ի վրա կամ կարող է պահանջել աշխատել միանգամից մի քանի արձանագրությունների վրա: Եթե ​​ձեր գործը ոչ ստանդարտ է, համոզվեք, որ հաշվի առեք այս գործոնը, որպեսզի հետագայում ստիպված չլինեք վերակազմավորել կլաստերը: Բոլոր կարգավորիչների համար աջակցվող արձանագրությունների ցանկը տարբեր է:

ծրագրային ապահովման հիմքում

Կան հավելվածների մի քանի տարբերակներ, որոնց վրա հիմնված է վերահսկիչը: Հայտնի են nginx, traefik, haproxy, envoy: Ընդհանուր դեպքում, դա կարող է մեծ ազդեցություն չունենալ երթևեկության ընդունման և փոխանցման վրա, բայց միշտ օգտակար է իմանալ «կափարիչի տակ» եղածի հնարավոր նրբությունները և առանձնահատկությունները:

Երթևեկության երթուղի

Ինչի՞ հիման վրա է հնարավոր որոշում կայացնել դեպի կոնկրետ ծառայություն երթևեկության ուղղության վերաբերյալ: Սովորաբար սա հյուրընկալող և ուղի է, բայց կան լրացուցիչ հնարավորություններ:

Անվանատարածք կլաստերի մեջ

Անվանատարածք (անունների տարածություն) - Kubernetes-ում ռեսուրսները տրամաբանորեն բաժանելու ունակություն (օրինակ, բեմում, արտադրություն և այլն): Կան Ingress կարգավորիչներ, որոնք պետք է առանձին տեղադրվեն յուրաքանչյուր անվանատարածքում (և այնուհետև այն կարող է ուղղորդել երթևեկությունը միայն այս տարածության պատյաններին): Եվ կան այնպիսիք (և նրանց հստակ մեծամասնությունը), որոնք աշխատում են գլոբալ ամբողջ կլաստերի համար. դրանցում երթևեկությունը ուղղվում է դեպի կլաստերի ցանկացած պատիճ՝ անկախ անվանատարածքից:

Նմուշներ վերին հոսանքների համար

Ինչպե՞ս է տրաֆիկը ուղղորդվում դեպի հավելվածի, ծառայությունների առողջ օրինակներ: Կան ակտիվ և պասիվ ստուգումներ, կրկնվող փորձեր, անջատիչներ (Լրացուցիչ մանրամասների համար տե՛ս, օրինակ, հոդված Իստիոյի մասին), մաքսային առողջության ստուգումներ և այլն: Շատ կարևոր պարամետր, եթե դուք ունեք բարձր պահանջներ անհասանելիության և չհաջողված ծառայությունների հավասարակշռումից ժամանակին հեռացնելու համար:

Հավասարակշռման ալգորիթմներ

Կան բազմաթիվ տարբերակներ՝ ավանդականից կլոր ռոբին դեպի էկզոտիկ rdp-cookie, ինչպես նաև անհատական ​​հատկանիշներ, ինչպիսիք են կպչուն նիստեր.

Նույնականացմանը

Թույլտվության ի՞նչ սխեմաներ է աջակցում վերահսկիչը: Հիմնական, digest, oauth, external-auth - Կարծում եմ, որ այս տարբերակները պետք է ծանոթ լինեն: Սա կարևոր չափանիշ է, եթե կան բազմաթիվ մշակողների (և/կամ պարզապես մասնավոր) հանգույցներ, որոնց հասանելի են Ingress-ի միջոցով:

Երթևեկության բաշխում

Արդյո՞ք վերահսկիչն աջակցում է երթևեկության բաշխման այնպիսի սովորաբար օգտագործվող մեխանիզմներին, ինչպիսիք են դեղձանիկի տեղադրումը (դեղձանիկ), A/B թեստավորումը, երթևեկության հայելավորումը (հայելապատում/ստվերում): Սա իսկապես ցավոտ թեմա է այն հավելվածների համար, որոնք պահանջում են երթևեկության ճշգրիտ և ճշգրիտ կառավարում արդյունավետ փորձարկման, արտադրանքի սխալների վրիպազերծման առանց ցանցի (կամ նվազագույն կորստի), երթևեկության վերլուծության և այլնի համար:

Վճարովի բաժանորդագրություն

Կարգավորիչի համար կա՞ վճարովի տարբերակ՝ առաջադեմ ֆունկցիոնալությամբ և/կամ տեխնիկական աջակցությամբ:

Գրաֆիկական ինտերֆեյս (Web UI)

Կա՞ որևէ GUI՝ վերահսկիչի կազմաձևումը կառավարելու համար: Հիմնականում «հարմարավետության» և/կամ նրանց համար, ովքեր պետք է որոշ փոփոխություններ կատարեն Ingress'a կոնֆիգուրացիայի մեջ, բայց «հում» կաղապարների հետ աշխատելն անհարմար է: Դա կարող է օգտակար լինել, եթե ծրագրավորողները ցանկանում են որոշակի փորձեր կատարել երթևեկության հետ:

JWT վավերացում

JSON վեբ նշանների ներկառուցված վավերացման առկայություն՝ օգտատիրոջ թույլտվության և վերջնական հավելվածի վավերացման համար:

Կազմաձևման հարմարեցման հնարավորություններ

Կաղապարի ընդարձակելիություն՝ մեխանիզմներ ունենալու իմաստով, որոնք թույլ են տալիս ավելացնել ձեր սեփական հրահանգները, դրոշները և այլն ստանդարտ կազմաձևման կաղապարներին:

Հիմնական DDOS պաշտպանության մեխանիզմներ

Փոխարժեքի սահմանափակման պարզ ալգորիթմներ կամ երթևեկության զտման ավելի բարդ տարբերակներ՝ հիմնված հասցեների, սպիտակ ցուցակների, երկրների և այլնի վրա:

Պահանջել հետք

Ingresses-ի հարցումները վերահսկելու, հետևելու և վրիպազերծելու ունակությունը դեպի հատուկ ծառայություններ / պատյաններ, և իդեալականորեն նաև ծառայությունների / պատյանների միջև:

WAF

Աջակցություն հավելվածի firewall.

Կարգավորիչներ

Վերահսկողների ցուցակը կազմվել է հիման վրա պաշտոնական Kubernetes փաստաթղթեր и այս աղյուսակը. Մենք դրանցից մի քանիսը բացառեցինք վերանայումից՝ սպեցիֆիկության կամ ցածր տարածվածության պատճառով (զարգացման վաղ փուլ): Մնացածը քննարկվում են ստորև: Սկսենք լուծումների ընդհանուր նկարագրությունից և շարունակենք ամփոփ աղյուսակով։

Ներխուժում Կուբերնետեսից

Կայք: github.com/kubernetes/ingress-nginx
Լիցենզիա՝ Apache 2.0

Սա Kubernetes-ի պաշտոնական վերահսկիչն է և մշակվում է համայնքի կողմից: Ակնհայտ է, որ անունից այն հիմնված է nginx-ի վրա և լրացվում է Lua հավելումների այլ հավաքածուով, որն օգտագործվում է լրացուցիչ գործառույթներ իրականացնելու համար: Ինքնին nginx-ի հանրաճանաչության և որպես կարգավորիչ օգտագործելու դեպքում դրա նվազագույն փոփոխությունների պատճառով այս տարբերակը կարող է լինել ամենահեշտ և հասկանալի կարգավորելը սովորական ինժեների կողմից (վեբ փորձով):

Ingress կողմից NGINX Inc.

Կայք: github.com/nginxinc/kubernetes-ingress
Լիցենզիա՝ Apache 2.0

Nginx մշակողների պաշտոնական արտադրանքը: Ունի վճարովի տարբերակ՝ հիմնված NGINX Plus. Հիմնական գաղափարը կայունության բարձր մակարդակն է, մշտական ​​հետամնաց համատեղելիությունը, որևէ կողմնակի մոդուլների բացակայությունը և հայտարարված բարձրացված արագությունը (համեմատած պաշտոնական վերահսկիչի հետ), որը ձեռք է բերվել Lua-ի մերժման պատճառով:

Անվճար տարբերակը զգալիորեն կրճատվել է, ներառյալ նույնիսկ պաշտոնական վերահսկիչի հետ համեմատած (նույն Lua մոդուլների բացակայության պատճառով): Միևնույն ժամանակ, վճարովին ունի բավականին լայն լրացուցիչ գործառույթ՝ իրական ժամանակի չափումներ, JWT վավերացում, ակտիվ առողջական ստուգումներ և այլն: NGINX Ingress-ի նկատմամբ կարևոր առավելությունը TCP / UDP տրաֆիկի ամբողջական աջակցությունն է (և համայնքային տարբերակում նույնպես): Մինուս - բացակայություն երթևեկության բաշխման առանձնահատկությունը, որը, այնուամենայնիվ, «ավելի առաջնահերթություն ունի մշակողների համար», բայց դրա իրականացման համար ժամանակ է պահանջվում:

Կոնգ Ինգրես

Կայք: github.com/Kong/kubernetes-ingress-controller
Լիցենզիա՝ Apache 2.0

Ապրանքը մշակվել է Kong Inc. երկու տարբերակով՝ կոմերցիոն և անվճար։ Հիմնված է nginx-ի վրա, որն ընդլայնվել է մեծ թվով Lua մոդուլներով:

Սկզբում այն ​​կենտրոնացած էր API հարցումների մշակման և ուղղորդման վրա, այսինքն. որպես API Gateway, բայց այս պահին այն դարձել է Ingress-ի լիարժեք վերահսկիչ: Հիմնական առավելությունները. բազմաթիվ լրացուցիչ մոդուլներ (ներառյալ երրորդ կողմի մշակողների), որոնք հեշտ են տեղադրվում և կարգավորվում, և որոնց օգնությամբ ներդրվում է լրացուցիչ հնարավորությունների լայն շրջանակ: Այնուամենայնիվ, ներկառուցված գործառույթներն արդեն առաջարկում են բազմաթիվ հնարավորություններ: Աշխատանքի կոնֆիգուրացիան կատարվում է CRD ռեսուրսների միջոցով:

Արտադրանքի կարևոր առանձնահատկությունը՝ նույն ուրվագծում աշխատելը (խաչաձև անվանատարածքի փոխարեն) վիճելի թեմա է. բоՄեկուսացման ավելի մեծ մակարդակ, ինչպես եթե մեկ կարգավորիչ կոտրված է, ապա խնդիրը սահմանափակվում է միայն միացումով):

Թրաեֆիկ

Կայք: github.com/containous/traefik
Լիցենզիա՝ MIT

Պրոքսի, որն ի սկզբանե ստեղծվել է միկրոծառայությունների և դրանց դինամիկ միջավայրի հարցումների երթուղավորման հետ աշխատելու համար: Հետևաբար, շատ օգտակար առանձնահատկություններ՝ կոնֆիգուրացիայի թարմացում՝ ընդհանրապես առանց վերագործարկման, մեծ թվով հավասարակշռման մեթոդների աջակցություն, վեբ ինտերֆեյս, չափումների վերահասցեավորում, տարբեր արձանագրությունների աջակցություն, REST API, դեղձանիկների թողարկումներ և շատ ավելին: Մեկ այլ լավ հատկանիշ է Let's Encrypt վկայականների աջակցությունը առանց տուփի: Թերությունն այն է, որ բարձր հասանելիություն (HA) կազմակերպելու համար կարգավորիչը պետք է տեղադրի և միացնի իր սեփական KV պահեստը:

HAProxy

Կայք: github.com/jcmoraisjr/haproxy-ingress
Լիցենզիա՝ Apache 2.0

HAProxy-ն վաղուց հայտնի է եղել որպես վստահված անձ և երթևեկության հավասարակշռող: Որպես Kubernetes կլաստերի մի մաս, այն առաջարկում է «փափուկ» կազմաձևման թարմացում (առանց երթևեկի կորստի), ծառայության հայտնաբերում, որը հիմնված է DNS-ի վրա, դինամիկ կոնֆիգուրացիա՝ օգտագործելով API: Կարող է գրավիչ լինել ամբողջովին հարմարեցնել կազմաձևման ձևանմուշը՝ փոխարինելով CM-ը, ինչպես նաև դրանում Sprig գրադարանի գործառույթներն օգտագործելու հնարավորությունը: Ընդհանուր առմամբ, լուծման հիմնական շեշտը դրվում է բարձր արագության, դրա օպտիմալացման և սպառված ռեսուրսների արդյունավետության վրա: Կարգավորիչի առավելությունը հավասարակշռման տարբեր մեթոդների ռեկորդային քանակի աջակցությունն է:

Ուղեվոր

Կայք: github.com/appscode/voyager
Լիցենզիա՝ Apache 2.0

Հիմնված է HAproxy կարգավորիչի վրա, որը դիրքավորված է որպես ունիվերսալ լուծում, որն աջակցում է մեծ թվով պրովայդերների հնարավորությունների լայն շրջանակի: Առաջարկվում է L7 և L4 երթևեկությունը հավասարակշռելու հնարավորություն, իսկ TCP L4 տրաֆիկի հավասարակշռումը որպես ամբողջություն կարելի է անվանել լուծման հիմնական հատկանիշներից մեկը:

Եզրագիծը

Կայք: github.com/heptio/contour
Լիցենզիա՝ Apache 2.0

Այս լուծումը հիմնված է ոչ միայն Envoy-ի վրա, այն մշակվել է համատեղ այս հանրաճանաչ վստահված անձի հեղինակների հետ։ Կարևոր առանձնահատկությունն է IngressRoute CRD ռեսուրսների միջոցով Ingress ռեսուրսների վերահսկումը առանձնացնելու հնարավորությունը: Միևնույն կլաստերը օգտագործող բազմաթիվ զարգացման թիմեր ունեցող կազմակերպությունների համար սա օգնում է առավելագույնի հասցնել հարևան օղակների երթևեկության հետ աշխատելու անվտանգությունը և պաշտպանել նրանց սխալներից Ingress ռեսուրսները փոխելիս:

Այն նաև առաջարկում է հավասարակշռման մեթոդների ընդլայնված շարք (կա հարցումների արտացոլում, ավտոմատ կրկնում, հարցումների արագության սահմանափակում և շատ ավելին), երթևեկության հոսքի և խափանումների մանրամասն մոնիտորինգ: Թերևս ինչ-որ մեկի համար դա էական թերություն կլինի կպչուն նիստերի աջակցության բացակայությունը (չնայած աշխատանք արդեն ընթացքի մեջ է).

Իստիո Ինգրես

Կայք: istio.io/docs/tasks/traffic-management/ingress
Լիցենզիա՝ Apache 2.0

Ծառայությունների ցանցի համապարփակ լուծում, որը ոչ միայն Ingress վերահսկիչ է, որը կառավարում է մուտքային երթևեկությունը դրսից, այլ նաև վերահսկում է կլաստերի ներսում գտնվող ողջ երթևեկությունը: Կափարիչի տակ Envoy-ն օգտագործվում է որպես յուրաքանչյուր ծառայության համար որպես կողային վստահված անձ: Ըստ էության, սա մեծ կոմբինատ է, որը «կարող է անել ամեն ինչ», և դրա հիմնական գաղափարը առավելագույն կառավարելիությունն է, ընդարձակելիությունը, անվտանգությունը և թափանցիկությունը: Դրա միջոցով դուք կարող եք կարգավորել երթևեկության երթուղին, մուտք գործել ծառայությունների միջև թույլտվություն, հավասարակշռում, մոնիտորինգ, դեղձանիկների թողարկում և շատ ավելին: Կարդալ ավելին Istio-ի մասին հոդվածների շարքում»Վերադարձ դեպի միկրոսերվիսներ Istio-ով.

Դեսպան

Կայք: github.com/datawire/ambassador
Լիցենզիա՝ Apache 2.0

Մեկ այլ լուծում՝ հիմնված Էնվոյի վրա. Այն ունի անվճար և կոմերցիոն տարբերակներ։ Այն դիրքավորվում է որպես «լիովին բնիկ Kubernetes-ի համար», ինչը բերում է համապատասխան առավելություններ (սերտ ինտեգրում K8s կլաստերի մեթոդների և սուբյեկտների հետ):

Համեմատության աղյուսակ

Այսպիսով, հոդվածի գագաթնակետը այս հսկայական աղյուսակն է.

Այն կարելի է սեղմել ավելի մոտ դիտելու համար և հասանելի է նաև ձևաչափով Google աղյուսակներ.

To ամփոփել

Այս հոդվածի նպատակն է ավելի ամբողջական պատկերացում տալ (սակայն, ոչ մի դեպքում սպառիչ), թե ինչ ընտրություն կատարել ձեր կոնկրետ դեպքում: Ինչպես միշտ, յուրաքանչյուր կարգավորիչ ունի իր առավելություններն ու թերությունները…

Kubernetes-ի դասական Ingress-ը լավ է իր հասանելիությամբ և ապացուցվածությամբ, բավական հարուստ հատկություններով. ընդհանուր դեպքում այն ​​պետք է լինի «բավական աչքերի համար»: Այնուամենայնիվ, եթե կայունության, հնարավորությունների և զարգացման մակարդակի պահանջներ են ավելացել, ապա պետք է ուշադրություն դարձնեք Ingress-ին NGINX Plus-ով և վճարովի բաժանորդագրությամբ: Կոնգը ունի պլագինների ամենահարուստ հավաքածուն (և, համապատասխանաբար, նրանց ընձեռած հնարավորությունները), իսկ վճարովի տարբերակում դրանք ավելի շատ են։ Այն ունի մեծ հնարավորություններ աշխատելու որպես API Gateway, դինամիկ կոնֆիգուրացիա՝ հիմնված CRD ռեսուրսների, ինչպես նաև հիմնական Kubernetes ծառայությունների վրա:

Հավասարակշռման և թույլտվության մեթոդների նկատմամբ պահանջների ավելացմամբ՝ նայեք Traefik-ին և HAProxy-ին: Սրանք բաց կոդով նախագծեր են, որոնք ապացուցված են տարիների ընթացքում, շատ կայուն և ակտիվորեն զարգացող: Contour-ը թողարկվել է արդեն մի քանի տարի, բայց այն դեռ շատ երիտասարդ տեսք ունի և Envoy-ի վրա ավելացվել է միայն հիմնական գործառույթները: Եթե ​​հավելվածի առջև WAF-ի առկայության / ներդրման պահանջներ կան, ապա պետք է ուշադրություն դարձնեք նույն Ingress-ին Kubernetes-ից կամ HAProxy-ից:

Իսկ հատկանիշներով ամենահարուստը Envoy-ի վրա կառուցված ապրանքներն են, հատկապես Իստիոն: Թվում է, թե այն համապարփակ լուծում է, որը «կարող է անել ամեն ինչ», ինչը, այնուամենայնիվ, նաև նշանակում է կազմաձևման / գործարկման / կառավարման համար զգալիորեն ավելի բարձր մուտքի շեմ, քան մյուս լուծումները:

Մենք ընտրել և օգտագործում ենք Ingress-ը Kubernetes-ից որպես ստանդարտ կարգավորիչ, որը ծածկում է կարիքների 80-90%-ը: Այն բավականին հուսալի է, հեշտ է կարգավորել և ընդլայնել: Ընդհանուր առմամբ, հատուկ պահանջների բացակայության դեպքում այն ​​պետք է համապատասխանի կլաստերների / հավելվածների մեծամասնությանը: Նույն ունիվերսալ և համեմատաբար պարզ արտադրանքներից կարելի է առաջարկել Traefik և HAProxy:

PS

Կարդացեք նաև մեր բլոգում.

• «Վերադառնալ միկրոսերվիսներին Istio-ով». մաս 1 (ներածություն հիմնական հատկանիշներին), մաս 2 (երթուղի, երթևեկության վերահսկում), մաս 3 (նույնականացում և թույլտվություն);
• «Kubernetes-ի խորհուրդներ և հնարքներ. հատուկ սխալի էջեր NGINX Ingress-ում";
• «Kubernetes-ի խորհուրդներ և հնարքներ. մուտք դեպի մշակող կայքեր.

Source: www.habr.com