ingress-nginx-დან Envoy Gateway-ზე დაუნთაიმის გარეშე: 27 Ingress, 39 HTTPRoute
ingress-nginx გადამდგარია და Kubernetes-ის განახლებებს ბლოკავს. როგორ გადავიყვანეთ 16 საჯარო ჰოსტი Envoy Gateway-ზე: ახალი შესასვლელი ძველის გვერდით ავამუშავეთ და ბოლოს მხოლოდ მისამართი შევცვალეთ.
Optimacros-ში Kubernetes კლასტერი კომპანიის საჯარო მარკეტინგულ საიტებს ემსახურება. Community ingress-nginx 2026 წლის მარტში გადადგა, მისი ბოლო რელიზები კი Kubernetes-ის ვერსიას ზღუდავს: ერთი ხაზი 1.33-ზე ჩერდება, საბოლოო — 1.35-ზე. 1.36-მდე განახლება შესასვლელის შეცვლის გარეშე შეუძლებელი იყო.
შედეგი: 16 ჰოსტი გადავიდა Gateway API-ზე, 27 Ingress ობიექტი 39 HTTPRoute-ად იქცა, ძველ ქცევასთან არც ერთი განსხვავება და პროდაქშენი არ დაცემულა.
სქემა, რომელმაც გადასვლა უსაფრთხო გახადა
გასაღები მანიფესტებში კი არა, თანმიმდევრობაში იყო. ახალი შესასვლელი ძველის გვერდით თავისუფალ მისამართზე ირთვება და ბოლოს მხოლოდ მისამართი იცვლება.
- Envoy Gateway სათადარიგო მისამართზე, სანამ პროდაქშენი ingress-nginx-ზე რჩება.
- 16-ივე ჰოსტის შედარება ორივე მისამართზე.
- მისამართები ადგილებს იცვლის — თითოეულზე თითო ანოტაციით. ეს ერთადერთი მომენტია, როცა რაიმე გავლენაა.
- ძველი შესასვლელი სათადარიგო მისამართზე ცოცხალი რჩება, ასე რომ დაბრუნება ერთი ანოტაციაა.
შედარება არ ნიშნავს „გვერდი გაიხსნა“. ყოველ ჰოსტზე ვადარებდი პასუხის კოდს და რედირექტის კოდს Host სათაურით და SNI-ით ორივე მისამართზე ერთდროულად. დაემთხვა 16 16-დან.
ხაფანგი 1: კლასტერის დომენი ყოველთვის cluster.local არ არის
ამ კლასტერმა kubespray-დან არასტანდარტული დომენი მიიღო მემკვიდრეობით. ჩარტის ნაგულისხმევი მნიშვნელობით პროქსი-პოდი თავის xDS სერვერს არარსებულ სახელად ხსნიდა, NXDOMAIN-ს იღებდა და 1/2 Running-ში იყო გაჭედილი no healthy upstream-ით. cat /etc/resolv.conf ნებისმიერ პოდში ნამდვილ search დომენს აჩვენებს. იგივე დომენი ხვდება ჩარტის მიერ გენერირებული სერტიფიკატების SAN-ში, ამიტომ მნიშვნელობის შესწორება საკმარისი არ არის — სერტიფიკატებიც ხელახლა უნდა გაიცეს.
ხაფანგი 2: Helm hook რეფრეშით არ ეშვება ხელახლა
სერტიფიკატების გენერატორი pre-install და pre-upgrade hook-ია. თუ Application უკვე Synced-ია, Argo CD სამუშაოს ვერ ხედავს და არ უშვებს მას, ხოლო hook-ის ServiceAccount-იც შესრულების შემდეგ იშლება. ეს ნაკრები helm template-ით დავარენდერე, hook ანოტაციები მოვაშორე და ხელით გამოვიყენე.
ხაფანგი 3: basic auth მხოლოდ {SHA} ფორმატში
ingress-nginx apr1 ჰეშებს ინახავდა. Envoy Gateway-ის SecurityPolicy მათ უარყოფს unsupported htpasswd format: please use {SHA}-ით, ხოლო გასაღებს .htpasswd უნდა ერქვას. სადაც პაროლი ცნობილი იყო, ჰეში ხელახლა გამოვთვალე. სადაც მხოლოდ apr1 ჰეში არსებობდა, პაროლის აღდგენა შეუძლებელი იყო — მხოლოდ როტაცია. ძველი გასაღები ახლის გვერდით დავტოვე: სანამ ორივე ფორმატი ერთ Secret-შია, ორივე შესასვლელი მუშაობს და დაბრუნება ცოცხალი რჩება.
ხაფანგი 4: ანოტაციები პირდაპირი ანალოგის გარეშე
| ingress-nginx | Gateway API |
|---|---|
ssl-redirect |
ცალკე HTTPRoute :80 listener-ზე RequestRedirect-ით, სტატუსი 308, როგორც nginx-ში |
auth-type: basic |
SecurityPolicy.basicAuth ცალკე მარშრუტზე, თორემ პაროლს მთელ საიტზე მოითხოვენ |
rewrite-target regex-ით |
ხშირად ეს უბრალოდ პრეფიქსის შეცვლაა: ReplacePrefixMatch |
backend-protocol: HTTPS |
BackendTLSPolicy, რომელსაც სტაბილური CA სჭირდება |
| ბექენდის სახელიანი პორტი | backendRefs.port-ში მხოლოდ რიცხვები |
Argo CD-ის სერვერი ყოველ გაშვებაზე მეხსიერებაში ახალ სერტიფიკატს აგენერირებს, ასე რომ CA, საიდანაც BackendTLSPolicy-ს აგება შეიძლება, უბრალოდ არ არსებობს. გარე TLS ტერმინაციის მიღმა სტანდარტული პასუხია server.insecure=true, და ამავდროულად ძველი Ingress-იდან HTTPS ბექენდის ანოტაცია უნდა მოიხსნას.
ხაფანგი 5: ინვენტარიზაცია ტყუის, სანამ ქსელით არ შეამოწმებ
- რვა TLS საიდუმლოება ორი სერტიფიკატი აღმოჩნდა: ერთი wildcard ხუთ ასლად იდო სხვადასხვა სახელით და უკვე ფარავდა apex-ს.
- ორი მითითებული საიდუმლოება საერთოდ არ არსებობდა. ეს ჰოსტები წლების განმავლობაში ingress კონტროლერის fake სერტიფიკატს აბრუნებდა და ამას არავინ ამჩნევდა.
- ორი Ingress წაშლილი აპლიკაციის ნარჩენი იყო: არც DNS, არც Service, პროდაქშენზე 503. ისინი წავშალეთ და არ გადავიტანეთ.
წვრილმანები, რომლებმაც დრო შეჭამა
- kustomize-ის საქაღალდე მხოლოდ იმას იყენებს, რაც
resources:-შია ჩამოთვლილი. გვერდით დადებული ფაილი ჩუმად იგნორირდება. - Kyverno-ს პოლიტიკა, რომელიც Ingress-ის გაჩენისას TLS საიდუმლოებას აკლონირებდა, Gateway-ზე არ მუშაობს. საჭიროა ცალკე წესი და RBAC
gateways-ზე. - App-of-apps ზემოდან ქვემოთ ახლდება: შვილის რეფრეში, სანამ მშობელი ძველ რევიზიაზეა, არაფერს იძლევა.
- Gateway-დან სხვა namespace-ში მდებარე Secret-ზე მითითებას მფლობელის namespace-ში ReferenceGrant სჭირდება.
რა წავიღოთ
- ახალი შესასვლელი ძველის გვერდით აამუშავეთ და მხოლოდ მისამართი შეცვალეთ. მაშინ გადართვაც და დაბრუნებაც თითო ანოტაციაა.
- გადართვამდე ყოველ ჰოსტზე ორივე მისამართზე შეადარეთ პასუხისა და რედირექტის კოდები.
- შეამოწმეთ კლასტერის დომენი, სანამ რამეს დააყენებთ, რაც კლასტერის შიდა სახელებს ხსნის.
- TLS საიდუმლოებები იმას შეადარეთ, რასაც პროდაქშენი რეალურად აბრუნებს.
- ძველ შესასვლელს გადართვის დღეს ნუ წაშლით. ეს თქვენი დაბრუნებაა.