AKS ვერ ჩამოტვირთავს სურათს VPN-ის მიღმა არსებული კერძო registry-დან
kubelet ჩამოტვირთავს node-ის ქსელით და არა pod-ის VPN-ით. გადაწყვიტეთ node-ის მარშრუტებით, node-ის DNS-ით, ყოველი endpoint-ით, რომელსაც ჩამოტვირთვა ეხება, შემდეგ TLS და იდენტობა.
თქვენი ლეპტოპი სურათს უპრობლემოდ იწერს, მაგრამ pod რჩება ImagePullBackOff-ში. კორპორატიული VPN კლიენტის sidecar-ად გაშვების წინადადება არ დაგეხმარებათ, რადგან ჩამოტვირთვა კონტეინერის შექმნამდე ხდება: kubelet node-ზე არსებულ container runtime-ს სთხოვს სურათის მოტანას, ხოლო runtime node-ის ქსელურ namespace-ს იყენებს.
ოპერაციების რიგი განსაზღვრავს შრეს
ჯერ სახელის გარჩევა ხდება, შემდეგ დაკავშირება, ავთენტიფიკაცია და შრეების ჩამოტვირთვა, და მხოლოდ ამის შემდეგ ირთვება კონტეინერი. ყველაფერი, რასაც pod VPN-ით აკეთებს, ამ რიგის შემდეგ ხდება, ამიტომ კლასტერში მომუშავე გვირაბი ჩამოტვირთვის მტკიცებულება არ არის.
ამიტომ ქეშირებული სურათი დამაჯერებელი სიცრუეა: კვირების წინ ჩამოტვირთული სურათის node კვლავ აწვდის მას, deployment ჯანსაღად გამოიყურება, ხოლო ხარვეზი მხოლოდ მაშინ ჩნდება, როცა მგეგმავი replica-ს ახალ node-ზე ათავსებს. scale-up ან node-ის შეცვლა მიზეზი არ არის, არამედ გამომწვევი.
სამი პირობა განსაზღვრავს შეკეთებას
ხელმისაწვდომობა ეყრდნობა მარშრუტიზაციას, სახელების გარჩევას და endpoint-ების ერთობლიობას. თუ node-ის subnet ვერ უზრუნველყოფს registry-ის ქსელამდე მარშრუტს, ვერც ერთი credential დაგეხმარებათ. თუ სახელი არ გაირჩევა node-ის DNS-ით, კავშირი არ დაიწყება. თუ მხოლოდ manifest ეწვდება, ხოლო blob არა, ჩამოტვირთვა შუაში ჩავარდება.
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
მხოლოდ VNet peering არ იძლევა gateway transit-ის ყველა კონფიგურაციას და ერთმიმართულებიანი მარშრუტი სამუშაო მარშრუტი არ არის. node-ს სჭირდება მხარდაჭერილი გზა განზრახული VPN gateway-ით, ხოლო registry-ის მხარეს დაბრუნების მარშრუტი node-ის subnet-ამდე.
წაიკითხეთ ხარვეზი, სანამ გადაწყვეტას აირჩევთ
დაიწყეთ pod-ის მოვლენებით და იმ node-ით, სადაც ის დაჯდა, თქვენი რეალური სახელებით: kubectl describe pod app-example -n team-example და kubectl get pod app-example -n team-example -o wide. მოვლენის ტექსტი გამოყოფს გაურჩეველ hostname-ს timeout-ისგან, სერტიფიკატის უარყოფას დაკარგული სურათისგან, და ავტორიზაციის წარუმატებლობას ყველა მათგანისგან.
ავთენტიფიკაცია ყველაზე გადაჭარბებული ბერკეტია. imagePullSecret runtime-ს registry-ის credential-ებს აძლევს; ის არ ამონტაჟებს მარშრუტს, არ ცვლის node-ის resolver-ს და არ აქცევს არასანდო სერტიფიკატს ნამდვილად. თუ მოვლენა ამბობს, რომ ჩამოტვირთვა არ იყო ავტორიზებული, შეხედეთ იდენტობის არეს; თუ ამბობს, რომ კავშირი გასტანა, credential-ები უმნიშვნელოა.
Kubernetes-ის სურათების დოკუმენტაცია ჩამოტვირთვის ქცევისა და კერძო registry-ების credential-ების წყაროა, და ღირს მისი ერთხელ წაკითხვა ქსელის შეცვლამდე, რადგან ავთენტიფიკაციასა და ტრანსპორტს შორის ზღვარს ნათელს ხდის.
ააშენეთ გზა pod-ის ქვეშ
იმუშავეთ ამ რიგით. ჯერ დაამარშრუტეთ node-ის ქსელი: დაადასტურეთ, რომ subnet-ს აქვს მხარდაჭერილი გზა registry-ის ქსელამდე, შეამოწმეთ node-ზე მოქმედი მარშრუტები, ორივე მხარის უსაფრთხოების წესები და registry-ის მხარეს დაბრუნების მარშრუტი.
შემდეგ გახსენით სახელი node-ის კონტექსტიდან. node-ის resolver არ არის pod-ის DNS კონფიგურაცია და pod-ში წარმატება host runtime-ის მტკიცებულება არ არის. გამოიყენეთ მართული კერძო DNS მუდმივი hosts ჩანაწერის ნაცვლად; ჩანაწერი ცოცხლობს node-ის შეცვლამდე და შემდეგ ჩუმად ქრება.
შემდეგ დაამტკიცეთ ყოველი endpoint. registry-ს შეუძლია კლიენტს ცალკე ავთენტიფიკაციის სერვისი და ცალკე blob საცავი მისცეს. manifest-ამდე მისვლა თითქმის არაფერს ამტკიცებს შრეებზე. ბოლოს დაასრულეთ TLS და ავტორიზაცია: სერტიფიკატი, რომელიც ძალაშია registry-ის სახელისთვის და სანდოა მხარდაჭერილი node-ის კონფიგურაციით, პლუს ჩამოტვირთვის იდენტობა, შეზღუდული ამ რეპოზიტორიის კითხვით.
შეამოწმეთ node-ზე, რომელიც ხელით არ შეგიკეთებიათ
ნამდვილი ტესტია ახალი ჩამოტვირთვა და ყველა შრის სრული გადმოწერა შესაფერის node-ზე, სასურველია scale-ით ან შეცვლით შექმნილზე. ეს მოიცავს ყველა pool-ს, რომელსაც workload შეიძლება განთავსდეს, მათ შორის დავიწყებულებს. ერთ node-ზე ხელით შეკეთება განლაგების მოდელი არ არის და შემდეგი autoscale მოვლენა ამ ხარვეზს იპოვის.
კლასტერის ხელახლა შექმნა სხვა VNet-ში შეიძლება გზა შეცვალოს, მაგრამ ეს ბოლო საშუალებაა და არა პირველი დიაგნოსტიკური ნაბიჯი. შეადარეთ არსებული node-ის ქსელი საჭირო კერძო მარშრუტს და მხარდაჭერილ AKS ქსელურ კონტროლებს მიგრაციის შეთავაზებამდე, და გაშვების შემდეგ აპლიკაციის კავშირი ცალკე შემოწმებად შეინახეთ: pod-ის საუბარი backend-თან სხვა შემოწმებაა, ვიდრე node-ის მიერ სურათის ჩამოტვირთვა.