Kubernetes კლასტერის განახლება შეფერხების გარეშე

განახლების პროცესი თქვენი Kubernetes კლასტერისთვის

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

ეს პოსტი არის 4 პოსტიანი სერიის ნაწილი:

1. ეს პოსტი.
2. კუბერნეტის კლასტერში პოდლების სწორი გამორთვა
3. პოდის დაგვიანებული დასრულება, როდესაც ის წაიშლება
4. როგორ ავიცილოთ თავიდან Kubernetes Cluster Downtime PodDisruptionBudgets-ის გამოყენებით

(დაახ. სერიის დარჩენილი სტატიების თარგმანს ველით უახლოეს მომავალში)

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

პრობლემის განსაზღვრა

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

ჩვენი მოგზაურობის დასაწყებად, ავიღოთ კონკრეტული მაგალითი. ვთქვათ, გვაქვს კუბერნეტის კლასტერი ორი კვანძისგან, რომელშიც აპლიკაცია გაშვებულია უკან მდებარე ორი პოდობით. Service:

დავიწყოთ ორი პოდით Nginx-ით და სერვისით, რომელიც მუშაობს ჩვენს ორ Kubernetes კლასტერულ კვანძზე.

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

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

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

ყველა კვანძის გადანაწილება კვანძიდან

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

მიუხედავად იმისა, რომ kubectl drain მშვენივრად შეასრულებს წიპწების გამოდევნას, არის კიდევ ორი ​​ფაქტორი, რამაც შეიძლება გამოიწვიოს გადინების ოპერაციის წარუმატებლობა:

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

შეფერხების თავიდან აცილება

ნებაყოფლობითი შეფერხებისგან შეფერხების შესამცირებლად, როგორიცაა კვანძზე გადინების ოპერაციიდან, Kubernetes გთავაზობთ მარცხის დამუშავების შემდეგ ვარიანტებს:

• მოხდენილი შეწყვეტა
• სასიცოცხლო ციკლის კაკვები
• PodDisruptionBudgets

სერიის დანარჩენ ნაწილში ჩვენ გამოვიყენებთ Kubernetes-ის ამ მახასიათებლებს, რათა შევამციროთ მიგრირებადი ჯიშების გავლენა. მთავარი იდეის გამარტივებისთვის, ჩვენ გამოვიყენებთ ჩვენს მაგალითს შემდეგი რესურსის კონფიგურაციით:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

ეს კონფიგურაცია მინიმალური მაგალითია Deployment, რომელიც მართავს nginx pods კლასტერში. გარდა ამისა, კონფიგურაცია აღწერს რესურსს Service, რომელიც შეიძლება გამოყენებულ იქნას კლასტერში nginx pods-ზე წვდომისთვის.

მთელი ციკლის განმავლობაში, ჩვენ განმეორებით გავაფართოვებთ ამ კონფიგურაციას ისე, რომ იგი საბოლოოდ მოიცავს ყველა იმ შესაძლებლობებს, რომლებსაც Kubernetes უზრუნველყოფს შეფერხების დროის შესამცირებლად.

Kubernetes კლასტერის განახლებების სრულად დანერგილი და გამოცდილი ვერსიისთვის AWS-ზე და მის ფარგლებს გარეთ ნულოვანი შეფერხებისთვის, ეწვიეთ Gruntwork.io.

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

• ნულოვანი შეფერხების განლაგება და მონაცემთა ბაზები
• Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?
• Tekton Pipeline - Kubernetes-ის მშობლიური მილსადენები
• დინამიური მოდულების აგება Nginx-ისთვის
• Hashicorp-ის კონსულის Kubernetes ავტორიზაციის შესავალი
• რას მოჰყვა მიგრაცია ClickHouse-დან ავტორიზაციის გარეშე ClickHouse-ში ავტორიზაციის მქონე?

წყარო: www.habr.com