Ingress კონტროლერების მიმოხილვა და შედარება Kubernetes-ისთვის

კონკრეტული აპლიკაციისთვის Kubernetes კლასტერის გაშვებისას, თქვენ უნდა გესმოდეთ, რას უქმნის თავად აპლიკაცია, ბიზნესი და დეველოპერები ამ რესურსს. ამ ინფორმაციის საშუალებით შეგიძლიათ დაიწყოთ არქიტექტურული გადაწყვეტილების მიღება და, კერძოდ, კონკრეტული Ingress კონტროლერის არჩევა, რომლის რაოდენობაც დღეს უკვე დიდია. იმისათვის, რომ მივიღოთ ძირითადი წარმოდგენა ხელმისაწვდომი ვარიანტების შესახებ მრავალი სტატიის/დოკუმენტაციის გავლის გარეშე და ა.შ., ჩვენ მოვამზადეთ ეს მიმოხილვა, მათ შორის ძირითადი (წარმოებისთვის მზად) Ingress კონტროლერები.

ვიმედოვნებთ, რომ ის დაეხმარება კოლეგებს არქიტექტურული გადაწყვეტის არჩევაში - ყოველ შემთხვევაში, ის გახდება ამოსავალი წერტილი უფრო დეტალური ინფორმაციის მოპოვებისა და პრაქტიკული ექსპერიმენტებისთვის. ადრე ჩვენ შევისწავლეთ სხვა მსგავსი მასალები ქსელში და, რაც არ უნდა უცნაური იყოს, ვერ ვიპოვეთ ერთი მეტ-ნაკლებად სრული და რაც მთავარია - სტრუქტურირებული - მიმოხილვა. მოდით, შეავსოთ ეს ხარვეზი!

კრიტერიუმები

პრინციპში, იმისათვის, რომ გააკეთოთ შედარება და მიიღოთ რაიმე სასარგებლო შედეგი, თქვენ უნდა გესმოდეთ არა მხოლოდ საგანი, არამედ გქონდეთ კრიტერიუმების კონკრეტული ჩამონათვალი, რომელიც განსაზღვრავს კვლევის ვექტორს. Ingress / Kubernetes-ის გამოყენების ყველა შესაძლო შემთხვევის გაანალიზების გარეშე, ჩვენ შევეცადეთ გამოვყოთ ყველაზე ზოგადი მოთხოვნები კონტროლერებისთვის - მოემზადეთ, რომ ნებისმიერ შემთხვევაში მოგიწევთ ცალ-ცალკე შეისწავლოთ თქვენი ყველა სპეციფიკა და დეტალი.

მაგრამ დავიწყებ იმ მახასიათებლებით, რომლებიც იმდენად ნაცნობი გახდა, რომ ისინი დანერგილია ყველა გადაწყვეტაში და არ განიხილება:

• სერვისების დინამიური აღმოჩენა (სერვისის აღმოჩენა);
• SSL შეწყვეტა;
• ვებსოკეტებთან მუშაობა.

ახლა შედარებისთვის:

მხარდაჭერილი ოქმები

შერჩევის ერთ-ერთი ფუნდამენტური კრიტერიუმი. თქვენი პროგრამული უზრუნველყოფა შეიძლება არ იმუშაოს სტანდარტულ HTTP-ზე, ან შეიძლება მოითხოვოს ერთდროულად რამდენიმე პროტოკოლზე მუშაობა. თუ თქვენი საქმე არასტანდარტულია, აუცილებლად გაითვალისწინეთ ეს ფაქტორი, რათა მოგვიანებით არ მოგიწიოთ კლასტერის ხელახალი კონფიგურაცია. ყველა კონტროლერისთვის, მხარდაჭერილი პროტოკოლების სია განსხვავდება.

პროგრამული უზრუნველყოფა ბირთვში

არსებობს აპლიკაციების რამდენიმე ვარიაცია, რომლებზეც დაფუძნებულია კონტროლერი. პოპულარულია nginx, traefik, haproxy, envoy. ზოგადად, მას შეიძლება არ ჰქონდეს დიდი გავლენა იმაზე, თუ როგორ ხდება ტრაფიკის მიღება და გადაცემა, მაგრამ ყოველთვის სასარგებლოა ვიცოდეთ პოტენციური ნიუანსები და მახასიათებლები იმის შესახებ, თუ რა არის „ქუდის ქვეშ“.

მოძრაობის მარშრუტიზაცია

რის საფუძველზეა შესაძლებელი გადაწყვეტილების მიღება კონკრეტულ სერვისზე მოძრაობის მიმართულების შესახებ? ჩვეულებრივ, ეს არის მასპინძელი და ბილიკი, მაგრამ არსებობს დამატებითი შესაძლებლობები.

სახელთა სივრცე კლასტერში

სახელთა სივრცე (სახელთა სივრცე) - Kubernetes-ში რესურსების ლოგიკურად გაყოფის შესაძლებლობა (მაგალითად, სცენაზე, წარმოება და ა.შ.). არის Ingress კონტროლერები, რომლებიც ცალკე უნდა იყოს დაინსტალირებული თითოეულ სახელთა სივრცეში (და შემდეგ მას შეუძლია ტრაფიკის მართვა მხოლოდ ამ სივრცის ბუჩქებამდე). და არის ისეთებიც (და მათი აშკარა უმრავლესობა), რომლებიც მუშაობენ გლობალურად მთელი კლასტერისთვის - მათში ტრაფიკი მიმართულია კლასტერის ნებისმიერ ნაწილზე, სახელების სივრცის მიუხედავად.

ნიმუშები ზემოთ ნაკადისთვის

როგორ არის მიმართული ტრაფიკი აპლიკაციის, სერვისების ჯანსაღ მაგალითებზე? არსებობს პარამეტრები აქტიური და პასიური შემოწმებით, განმეორებით, ამომრთველებით (დამატებითი ინფორმაციისთვის იხილეთ, მაგალითად, სტატია ისტიოს შესახებ), ჯანმრთელობის შემოწმების საკუთარი განხორციელებები (საბაჟო ჯანმრთელობის შემოწმებები) და ა.შ. ძალიან მნიშვნელოვანი პარამეტრი, თუ თქვენ გაქვთ მაღალი მოთხოვნები ხელმისაწვდომობისა და წარუმატებელი სერვისების დაბალანსებიდან დროული ამოღების შესახებ.

დაბალანსების ალგორითმები

ბევრი ვარიანტია: ტრადიციულიდან მრგვალი რობინ ეგზოტიკამდე rdp-ქუქი, ისევე როგორც ინდივიდუალური მახასიათებლები, როგორიცაა წებოვანი სესიები.

ავთენტიფიკაცია

რა ავტორიზაციის სქემებს უჭერს მხარს კონტროლერი? ძირითადი, დაიჯესტი, oauth, გარე ავტორიტეტი - ვფიქრობ, ეს ვარიანტები ნაცნობი უნდა იყოს. ეს მნიშვნელოვანი კრიტერიუმია, თუ არსებობს მრავალი დეველოპერის (და/ან უბრალოდ პირადი) მარყუჟი, რომლებზეც წვდომა ხდება 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 მოდულების არარსებობის გამო). ამავდროულად, ფასიანს აქვს საკმაოდ ფართო დამატებითი ფუნქციონირება: რეალურ დროში მეტრიკა, 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 ბიბლიოთეკის ფუნქციების გამოყენების შესაძლებლობა. ზოგადად, გადაწყვეტის ძირითადი აქცენტი კეთდება მაღალ სიჩქარეზე, მის ოპტიმიზაციაზე და მოხმარებულ რესურსებში ეფექტურობაზე. კონტროლერის უპირატესობა არის სხვადასხვა დაბალანსების მეთოდების რეკორდული რაოდენობის მხარდაჭერა.

Voyager

საიტი: github.com/appscode/voyger
ლიცენზია: Apache 2.0

დაფუძნებულია HAproxy კონტროლერზე, რომელიც პოზიციონირებულია, როგორც უნივერსალური გადაწყვეტა, რომელიც მხარს უჭერს ფუნქციების ფართო სპექტრს პროვაიდერების დიდ რაოდენობაზე. შემოთავაზებულია L7 და L4 ტრაფიკის დაბალანსების შესაძლებლობა და მთლიანობაში TCP L4 ტრაფიკის დაბალანსება შეიძლება ეწოდოს გადაწყვეტის ერთ-ერთ მთავარ მახასიათებელს.

კონტური

საიტი: github.com/heptio/contour
ლიცენზია: Apache 2.0

ეს გამოსავალი არ არის დაფუძნებული მხოლოდ ენვოისზე: ის შეიმუშავა ერთობლივად ამ პოპულარული პროქსის ავტორებთან. მნიშვნელოვანი მახასიათებელია Ingress-ის რესურსების კონტროლის გამოყოფის შესაძლებლობა IngressRoute CRD რესურსების გამოყენებით. ორგანიზაციებისთვის, რომლებსაც აქვთ მრავალი განვითარების გუნდი, რომლებიც იყენებენ იმავე კლასტერს, ეს ხელს უწყობს მეზობელ მარყუჟებში ტრაფიკთან მუშაობის უსაფრთხოების მაქსიმიზაციას და მათ დაცვას შეცდომებისგან Ingress რესურსების შეცვლისას.

ის ასევე გვთავაზობს დაბალანსების მეთოდების გაფართოებულ კომპლექტს (არსებობს მოთხოვნების ასახვა, ავტომატური გამეორება, მოთხოვნების სიჩქარის შეზღუდვა და მრავალი სხვა), ტრაფიკის ნაკადის დეტალური მონიტორინგი და წარუმატებლობა. შესაძლოა, ვინმესთვის მნიშვნელოვანი ნაკლი იქნება წებოვანი სესიების მხარდაჭერის არარსებობა (თუმცა სამუშაო უკვე მიმდინარეობს).

ისტიო ინგრესი

საიტი: istio.io/docs/tasks/traffic-management/ingress
ლიცენზია: Apache 2.0

ყოვლისმომცველი სერვისული ქსელის გადაწყვეტა, რომელიც არა მხოლოდ Ingress კონტროლერია, რომელიც მართავს შემომავალ ტრაფიკს გარედან, არამედ აკონტროლებს მთელ ტრაფიკს კლასტერში. ქუდის ქვეშ, Envoy გამოიყენება როგორც გვერდითი კარის პროქსი თითოეული სერვისისთვის. არსებითად, ეს არის დიდი კომბაინი, რომელსაც „ყველაფრის გაკეთება შეუძლია“ და მისი მთავარი იდეაა მაქსიმალური მართვადიობა, გაფართოება, უსაფრთხოება და გამჭვირვალობა. მასთან ერთად შეგიძლიათ დაარეგულიროთ ტრაფიკის მარშრუტი, წვდომა მიიღოთ ავტორიზაცია სერვისებს შორის, დაბალანსება, მონიტორინგი, კანარის გამოშვება და მრავალი სხვა. წაიკითხეთ მეტი ისტიოს შესახებ სტატიების სერიაში "დაუბრუნდით მიკროსერვისებს Istio-სთან ერთად".

საგანგებო და სრულუფლებიანი ელჩი

საიტი: github.com/datawire/ambassador
ლიცენზია: Apache 2.0

კიდევ ერთი გამოსავალი, რომელიც დაფუძნებულია Envoy-ზე. მას აქვს უფასო და კომერციული ვერსიები. ის პოზიციონირებულია, როგორც "სრულად მშობლიური Kubernetes", რაც მოაქვს შესაბამისი უპირატესობების (მჭიდრო ინტეგრაცია K8s კლასტერის მეთოდებთან და ერთეულებთან).

შედარება მაგიდა

ასე რომ, სტატიის კულმინაცია არის ეს უზარმაზარი ცხრილი:

მას შეუძლია დააწკაპუნოს უფრო ახლო სანახავად და ასევე ხელმისაწვდომია ფორმატში Google Sheets.

შეჯამება

ამ სტატიის მიზანია უფრო სრულყოფილი გაგება (თუმცა, არავითარ შემთხვევაში ამომწურავი!) იმის შესახებ, თუ რა არჩევანი უნდა გააკეთოთ თქვენს კონკრეტულ შემთხვევაში. როგორც ყოველთვის, თითოეულ კონტროლერს აქვს თავისი დადებითი და უარყოფითი მხარეები…

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-ის რჩევები და ხრიკები: წვდომა დეველოპერ საიტებზე".

წყარო: www.habr.com