Calico Ready-ში იყო შეცდომების გარეშე, ყოველი ახალი პოდი კი ნახევარი წუთი მიუწვდომელი იყო

Optimacros-ის bare-metal კლასტერზე Kubernetes-ის მრავალსაფეხურიანი განახლებისას Calico ჯერ 3.29.5-დან 3.31.7-მდე უნდა აგვეყვანა. განახლება სანიმუშოდ გამოიყურებოდა: ახალი CRD-ები და RBAC აფსტრიმიდან, ახალი იმიჯები, ყველა calico-node 1/1 Ready-ში, ClusterInformation ახალ ვერსიას აჩვენებდა, Felix-ის ლოგებში არც ერთი ERROR. არსებული პოდები ერთმანეთს ესაუბრებოდნენ, DNS მუშაობდა, ingress — ასევე.

და მაინც რაღაც არ იყო რიგზე.

ტესტი, რომელმაც ეს დაიჭირა

CNI-ის ნებისმიერი ცვლილების შემდეგ ერთ კონკრეტულ შემოწმებას ვატარებ: ახალი პოდი ნოდ A-ზე, მეორე ნოდ B-ზე და ვზომავ, რამდენ ხანში გაივლის მათ შორის პირველი მოთხოვნა.

s=$(date +%s); until kubectl exec nt-src -- wget -qO- -T1 http://$IP:8080/ >/dev/null 2>&1; do :; done
echo "$(( $(date +%s)-s ))s"

ეს 15-დან 42 წამამდე გრძელდებოდა მას შემდეგ, რაც სამიზნე პოდი უკვე Ready იყო. განახლებამდე — 1–2 წამი. health-check-ები და smoke-ტესტები არსებულ პოდებზე გადიოდა: ძველი პოდების ენდპოინტები დიდი ხნის წინ იყო დაპროგრამებული. შეფერხებას მხოლოდ ახალი ენდპოინტი აჩენს.

ციკლი ERROR-ის გარეშე

ვორკერებზე Felix-ის ლოგებში იყო ხაზი, რომელიც თავიდან უგულებელვყავი, რადგან warning დონეზეა:

Applying XDP BPF actions did not succeed, will retry with resync... error=failed to remove XDP program from lo

ნოდების მიხედვით — ხუთ წუთში 250–470-ჯერ Debian 13-იან ყველა ვორკერზე და ნულჯერ მასტერებზე, სხვა ოს-ითა და ბირთვით. Calico-ს წინა ვერსიამ loopback-ზე xdpgeneric პროგრამა დატოვა, ახალი კი ამ ბირთვზე მის მოხსნას ვერ ახერხებდა. ყოველი წარუმატებელი მცდელობა dataplane-ის სრულ resync-ს აყენებდა რიგში. ახალი ენდპოინტები მხოლოდ resync-ებს შორის მოკლე პაუზებში პროგრამირდებოდა — და ყოველი ახალი პოდი ათეულობით წამს შავ ხვრელში ატარებდა.

რატომ იყო XDP-ის გამორთვა უსაფრთხო

Calico XDP-ს მხოლოდ untracked და prefilter პოლიტიკებისთვის იყენებს. ამ კლასტერში NetworkPolicy საერთოდ არ იყო, ამიტომ XDP სასარგებლოს არაფერს აკეთებდა, სამაგიეროდ აქტიურად აზიანებდა. შეკეთება — ერთი ხაზი:

kubectl patch felixconfiguration default --type=merge -p '{"spec":{"xdpEnabled":false}}'

წამებში შეცდომების მთვლელი ყველა ნოდზე ნულამდე ჩამოვიდა, ახალი პოდების ტესტი კი 1–2 წამს დაუბრუნდა. ძველი პროგრამა lo-ზე რჩება — ის ადრეც იქ იყო და არაფერს ფილტრავს. დაბრუნება — იგივე პატჩი true-თი, და ამ ბირთვებზე ციკლი მაშინვე ბრუნდება.

გადაწყვეტილებას გადახედვის ტრიგერი აქვს: doNotTrack ან host-endpoint პოლიტიკების დანერგვამდე, რომლებსაც XDP სჭირდებათ, და Calico-ს შემდეგ minor-ზე, რომელიც DaemonSet-ს მაინც გარდაქმნის.

დასკვნები

• „calico-node Ready, ERROR არ არის” ქსელის ჯანმრთელობა არ არის. Felix შეიძლება warning დონეზე ბეჯითად ვარდებოდეს.
• CNI-ის ნებისმიერი ცვლილების შემდეგ შეამოწმე ახალი პოდი ↔ ახალი პოდი ნოდებს შორის, ტაიმერით. ხელახლა გამოყენებული პოდები ენდპოინტების პროგრამირების შეფერხებას სრულად მალავენ.
• warning-ები ნოდების მიხედვით დათვალე. ციკლი, რომელიც მხოლოდ ერთ ოს-ზე ან ბირთვზეა, მიზეზზე ძლიერი მინიშნებაა.
• გამოუყენებელი ფუნქციაც მომუშავე კოდია. თუ XDP არც ერთ პოლიტიკას არ ემსახურება, მისი გამორთვით გაუმართაობის კლასს უფასოდ აშორებ.