Kubernetes-ის სათანადო შედარება Apply, Replace and Patch

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

თუ მოძებნეთ Google-ში ფრაზა "kubernetes ვრცელდება vs შეცვლის" მდებარეობს პასუხი StackOverflow-ზე, რაც არ არის სწორი. ძიებისას "kubernetes application vs patch" პირველი ბმული არის დოკუმენტაცია kubectl patch, რომელიც არ შეიცავს შედარებას apply и patch. ეს სტატია განიხილავს სხვადასხვა ვარიანტს, ისევე როგორც თითოეული მათგანის სწორად გამოყენებას.

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

Kubernetes CLI

თუ უკვე მუშაობთ Kubernetes კლასტერებთან CLI-ის საშუალებით, უკვე იცნობთ apply и edit. გუნდი apply კითხულობს რესურსის სპეციფიკაციას ფაილიდან და აკეთებს "upsert"-ს Kubernetes კლასტერში, ე.ი. ქმნის რესურსს, თუ ის არ არსებობს და განაახლებს მას, თუ ის არსებობს. გუნდი edit კითხულობს რესურსს API-ის საშუალებით, შემდეგ წერს რესურსის სპეციფიკაციას ადგილობრივ ფაილში, რომელიც შემდეგ იხსნება ტექსტურ რედაქტორში. ფაილის რედაქტირების და შენახვის შემდეგ, kubectl გამოგიგზავნით შესრულებულ ცვლილებებს API-ის მეშვეობით, რომელიც ყურადღებით გამოიყენებს ამ ცვლილებებს რესურსზე.

ყველამ არ იცის ბრძანებები patch и replace. გუნდი patch საშუალებას გაძლევთ შეცვალოთ რესურსის სპეციფიკაციის ნაწილი, ბრძანების სტრიქონზე მხოლოდ შეცვლილი ნაწილის მიწოდებით. გუნდი replace მუშაობს ისევე, როგორც edit, მაგრამ ყველაფერი უნდა გაკეთდეს ხელით: თქვენ უნდა ჩამოტვირთოთ რესურსის სპეციფიკაციის მიმდინარე ვერსია, მაგალითად, გამოყენებით kubectl get -o yaml, შეცვალეთ, შემდეგ გამოიყენეთ replace რესურსის განახლება შეცვლილი სპეციფიკაციის მიხედვით. გუნდი replace არ იმუშავებს, თუ რაიმე ცვლილება მოხდა რესურსის წაკითხვასა და ჩანაცვლებას შორის.

Kubernetes API

თქვენ ალბათ იცნობთ მეთოდებს CoreV1().Pods().Update(), replaceNamespacedService ან patch_namespaced_deployment, თუ თქვენ მუშაობთ კლასტერებთან მეშვეობით კლიენტის ბიბლიოთეკა Kubernetes API-სთვის ზოგიერთი პროგრამირების ენის გამოყენებით. ბიბლიოთეკა ამუშავებს ამ მეთოდებს HTTP მოთხოვნის მეშვეობით მეთოდების გამოყენებით PUT и PATCH. ამ შემთხვევაში, update и replace გამოყენება PUTხოლო patch, რაც არ უნდა ტრივიალური იყოს, იყენებს PATCH.

აღსანიშნავია, რომ kubectl ასევე მუშაობს კლასტერებთან API-ის საშუალებით. Სხვა სიტყვებით, kubectlარის შეფუთვა კლიენტის ბიბლიოთეკის თავზე Go ენისთვის, რომელიც დიდწილად უზრუნველყოფს ქვებრძანებების უფრო კომპაქტური და წასაკითხი ფორმით მიწოდების შესაძლებლობას სტანდარტული API შესაძლებლობების გარდა. მაგალითად, როგორც უკვე შენიშნეთ, მეთოდი apply ზემოთ არ იყო ნახსენები წინა პუნქტში. ამჟამად (2020 წლის მაისი, დაახლ. მთარგმნელი) მთელი ლოგიკა kubectl apply, ე.ი. არარსებული რესურსების შექმნა და არსებულის განახლება, მუშაობს მთლიანად კოდის მხარეს kubectl. მიმდინარეობს ძალისხმევა ლოგიკის გადაცემაზე apply API მხარეს, მაგრამ ის ჯერ კიდევ ბეტა რეჟიმშია. დაწვრილებით ქვემოთ დავწერ.

პატჩი ნაგულისხმევად

საუკეთესოდ გამოყენებული patch, თუ გსურთ რესურსის განახლება. ასე მუშაობს ორივე კლიენტის ბიბლიოთეკა Kubernetes API-ს თავზე და kubectl (გასაკვირი არ არის, რადგან ეს არის შეფუთვა კლიენტის ბიბლიოთეკისთვის, დაახლ. მთარგმნელი).

იმუშავეთ სტრატეგიულად

ყველა გუნდი kubectl apply, edit и patch გამოიყენეთ მეთოდი PATCH HTTP-ში ითხოვს არსებული რესურსის განახლებას. თუ უფრო დეტალურად ჩავუღრმავდებით ბრძანებების განხორციელებას, მაშინ ყველა მათგანი იყენებს მიდგომას სტრატეგიული შერწყმის შეკეთება რესურსების განახლება, თუმცა ბრძანება patch შეიძლება გამოიყენოს სხვა მიდგომები (დაწვრილებით ამის შესახებ ქვემოთ). სტრატეგიული შერწყმის შესწორების მიდგომა ცდილობს „სწორად მიიჩნიოს“ მიწოდებული სპეციფიკაციის არსებულ სპეციფიკაციასთან შერწყმის გზით. უფრო კონკრეტულად, ის ცდილობს დააკავშიროს როგორც ობიექტები, ასევე მასივები, რაც იმას ნიშნავს, რომ ცვლილებები მიდრეკილია დანამატისკენ. მაგალითად, ბრძანების გაშვება patch ახალი გარემოს ცვლადი pod კონტეინერის სპეციფიკაციაში, იწვევს გარემოს ცვლადის დამატებას არსებულ გარემოს ცვლადებში, ვიდრე მათი გადაწერა. ამ მიდგომის გამოყენებით წასაშლელად, თქვენ უნდა აიძულოთ პარამეტრის მნიშვნელობა გაუქმდეს მოცემულ სპეციფიკაციაში. რომელი გუნდი kubectl უმჯობესია გამოიყენოთ განახლებისთვის?

თუ თქვენ ქმნით და მართავთ თქვენს რესურსებს გამოყენებით kubectl apply, განახლებისას უმჯობესია ყოველთვის გამოიყენოთ kubectl applyდან kubectl შეუძლია მართოს კონფიგურაცია და სწორად აკონტროლოს მოთხოვნილი ცვლილებები აპლიკაციიდან აპლიკაციამდე. უპირატესობა ყოველთვის გამოიყენეთ apply არის ის, რომ ის თვალყურს ადევნებს ადრე გამოყენებულ სპეციფიკაციას, რაც საშუალებას აძლევს მას იცოდეს, როდის არის აშკარად ამოღებული სპეციფიკაციის თვისებები და მასივის ელემენტები. ეს საშუალებას გაძლევთ გამოიყენოთ apply თვისებებისა და მასივის ელემენტების ამოღება, მაშინ როცა ნორმალური სტრატეგიული შერწყმა არ იმუშავებს. გუნდები edit и patch არ განაახლოთ შენიშვნები, რომ kubectl apply იყენებს მის ცვლილებებს თვალყურის დევნებისთვის, ამიტომ ნებისმიერი ცვლილება, რომელიც თვალყურს ადევნებს და კეთდება Kubernetes API-ს მეშვეობით, მაგრამ კეთდება ბრძანებების მეშვეობით edit и patch, უხილავი შემდგომი ბრძანებებისთვის applyანუ, apply არ შლის მათ მაშინაც კი, თუ ისინი არ ჩანს შეყვანის სპეციფიკაციაში apply (დოკუმენტაციაში ნათქვამია edit и patch განაახლეთ გამოყენებული შენიშვნები apply, მაგრამ პრაქტიკაში - არა).

თუ არ იყენებთ ბრძანებას apply, შეიძლება გამოყენებულ იქნას როგორც editდა patch, აირჩიეთ ბრძანება, რომელიც საუკეთესოდ შეეფერება განხორციელებულ ცვლილებას. BOM თვისებების დამატებისა და შეცვლისას, ორივე მიდგომა დაახლოებით ერთნაირია. სპეციფიკაციის თვისებების ან მასივის ელემენტების წაშლისას edit იქცევა როგორც ერთჯერადი გაშვება apply, მათ შორის, თვალყურის დევნება, თუ როგორი იყო სპეციფიკაცია მის რედაქტირებამდე და მის შემდეგ, ასე რომ თქვენ შეგიძლიათ აშკარად ამოიღოთ თვისებები და მასივის ელემენტები რესურსიდან. თქვენ მკაფიოდ უნდა დააყენოთ საკუთრების მნიშვნელობა null-ის მითითებაში patchრომ ამოიღოთ იგი რესურსიდან. მასივის ელემენტის ამოღება სტრატეგიული შერწყმის შესწორების გამოყენებით უფრო რთულია, რადგან ის მოითხოვს შერწყმის დირექტივების გამოყენებას. იხილეთ განახლების სხვა მიდგომები ქვემოთ უფრო ეფექტური ალტერნატივებისთვის.

განახლების მეთოდების დანერგვა კლიენტის ბიბლიოთეკაში, რომლებიც იქცევიან ზემოთ მოცემული ბრძანებების მსგავსად kubectl, უნდა იყოს მითითებული მოთხოვნებში content-type в application/strategic-merge-patch+json. თუ გსურთ ამოიღოთ თვისებები სპეციფიკაციაში, თქვენ უნდა დააყენოთ მათი მნიშვნელობები null-ზე ანალოგიურად. kubectl patch. თუ თქვენ გჭირდებათ მასივის ელემენტების წაშლა, უნდა შეიტანოთ გაერთიანების დირექტივები განახლების სპეციფიკაციაში ან გამოიყენოთ განახლებების სხვა მიდგომა.

განახლებების სხვა მიდგომები

Kubernetes მხარს უჭერს განახლების ორ სხვა მიდგომას: JSON შერწყმის პაჩი и JSON პაჩი. JSON შერწყმის პაჩი მიდგომა იღებს Kubernetes-ის ნაწილობრივ სპეციფიკაციას, როგორც შეყვანის სახით და მხარს უჭერს ობიექტების შერწყმას სტრატეგიული შერწყმის შესწორების მიდგომის მსგავსი. ამ ორს შორის განსხვავება ისაა, რომ ის მხოლოდ მხარს უჭერს მასივის ჩანაცვლებას, მათ შორის კონტეინერის მასივს pod სპეციფიკაციაში. ეს ნიშნავს, რომ JSON შერწყმის პაჩის გამოყენებისას, თქვენ უნდა მიაწოდოთ ყველა კონტეინერის სრული სპეციფიკაციები, თუ რომელიმე კონტეინერის რაიმე თვისება შეიცვლება. ასე რომ, ეს მიდგომა სასარგებლოა ელემენტების ამოსაღებად მასივიდან BOM-ში. ბრძანების სტრიქონზე შეგიძლიათ აირჩიოთ JSON შერწყმის პაჩი გამოყენებით kubectl patch --type=merge. Kubernetes API-სთან მუშაობისას უნდა გამოიყენოთ მოთხოვნის მეთოდი PATCH და მონტაჟი content-type в application/merge-patch+json.

JSON პაჩი მიდგომა, ვიდრე რესურსის ნაწილობრივი სპეციფიკაციის მიწოდებას, იყენებს მასივის სახით რესურსში შესატანი ცვლილებების მიწოდებას, რომელშიც მასივის თითოეული ელემენტი წარმოადგენს რესურსში განხორციელებული ცვლილების აღწერას. ეს მიდგომა უფრო მოქნილი და მძლავრი გზაა განხორციელებული ცვლილებების გამოხატვისთვის, მაგრამ განხორციელებული ცვლილებების ცალკე, არა Kubernetes ფორმატში ჩამოთვლის ფასად, ვიდრე ნაწილობრივი რესურსის სპეციფიკაციის გაგზავნა. IN kubectl შეგიძლიათ აირჩიოთ JSON პაჩი გამოყენებით kubectl patch --type=json. Kubernetes API-ის გამოყენებისას, ეს მიდგომა მუშაობს მოთხოვნის მეთოდის გამოყენებით PATCH და მონტაჟი content-type в application/json-patch+json.

ჩვენ გვჭირდება ნდობა - გამოიყენეთ ჩანაცვლება

ზოგიერთ შემთხვევაში, თქვენ უნდა დარწმუნდეთ, რომ რესურსში არანაირი ცვლილება არ განხორციელდება რესურსის წაკითხვის მომენტსა და მის განახლებას შორის. სხვა სიტყვებით რომ ვთქვათ, თქვენ უნდა დარწმუნდეთ, რომ ყველა ცვლილება იქნება ატომური. ამ შემთხვევაში, თქვენ უნდა გამოიყენოთ რესურსების განახლებისთვის replace. მაგალითად, თუ თქვენ გაქვთ ConfigMap მრიცხველით, რომელიც განახლებულია მრავალი წყაროთ, დარწმუნებული უნდა იყოთ, რომ ორი წყარო ერთდროულად არ განაახლებს მრიცხველს, რაც იწვევს განახლების დაკარგვას. საჩვენებლად, წარმოიდგინეთ მოვლენების თანმიმდევრობა მიდგომის გამოყენებით patch:

• A და B იღებენ რესურსის მიმდინარე მდგომარეობას API-დან
• თითოეული ლოკალურად განაახლებს სპეციფიკაციას მრიცხველის ერთით გაზრდით და ასევე "A" ან "B"-ის დამატებით "განახლებული" შენიშვნაში.
• და ის განაახლებს რესურსს ცოტა უფრო სწრაფად
• B აახლებს რესურსს

შედეგად, განახლება A იკარგება. ბოლო ოპერაცია patch იგებს, მრიცხველი იზრდება ერთით, ნაცვლად ორისა, ხოლო "განახლებული" შენიშვნის მნიშვნელობა მთავრდება "B"-ით და არ შეიცავს "A"-ს. მოდით შევადაროთ ზემოაღნიშნული იმას, რაც ხდება, როდესაც განახლებები კეთდება მიდგომის გამოყენებით replace:

• A და B იღებენ რესურსის მიმდინარე მდგომარეობას API-დან
• თითოეული ლოკალურად განაახლებს სპეციფიკაციას მრიცხველის ერთით გაზრდით და ასევე "A" ან "B"-ის დამატებით "განახლებული" შენიშვნაში.
• და ის განაახლებს რესურსს ცოტა უფრო სწრაფად
• B ცდილობს რესურსის განახლებას, მაგრამ განახლება უარყოფილია API-ს მიერ, რადგან რესურსის ვერსია არის სპეციფიკაციაში replace არ ემთხვევა Kubernetes-ის რესურსის ამჟამინდელ ვერსიას, რადგან რესურსის ვერსია გაიზარდა A-ს ჩანაცვლების ოპერაციით.

ზემოაღნიშნულ შემთხვევაში, B-ს მოუწევს ხელახლა მოიტანოს რესურსი, შეიტანოს ცვლილებები ახალ მდგომარეობაში და სცადო ხელახლა replace. ეს გამოიწვევს მრიცხველის XNUMX-ით გაზრდას და შენიშვნა "განახლებული" ბოლოს "AB"-ს მოიცავს.

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

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

აღსანიშნავია, რომ შემდეგი ორი ბრძანება, რომლებიც შესრულებულია თანმიმდევრულად, წარმატებით შესრულდება, რადგან deployment.yaml არ შეიცავს ქონებას .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

როგორც ჩანს, ეს ეწინააღმდეგება ზემოთ ნათქვამს, ე.ი. " დასძინა resourceVersion სპეციფიკაციის მეტამონაცემებში." არასწორია ამის თქმა? არა, ასე არ არის, რადგან თუ kubectl შენიშნავს, რომელიც არ დააკონკრეტეთ resourceVersion, წაიკითხავს მას რესურსიდან და დაამატებს თქვენ მიერ მითითებულ სპეციფიკაციას და მხოლოდ ამის შემდეგ შეასრულებს replace. იმის გამო, რომ ეს პოტენციურად საშიშია, თუ ატომურობას დაეყრდნობით, ჯადოქრობა მთლიანად გვერდით მუშაობს kubectl, თქვენ არ უნდა დაეყრდნოთ მას კლიენტის ბიბლიოთეკების გამოყენებისას, რომლებიც მუშაობენ API-სთან. ამ შემთხვევაში თქვენ მოგიწევთ წაიკითხოთ რესურსის მიმდინარე სპეციფიკაცია, განაახლოთ და შემდეგ შეასრულოთ PUT მოთხოვნა.

თქვენ არ შეგიძლიათ გააკეთოთ პატჩი - ჩვენ ვაკეთებთ ჩანაცვლებას

ზოგჯერ საჭიროა გარკვეული ცვლილებების შეტანა, რომელთა დამუშავება შეუძლებელია API-ით. ამ შემთხვევაში, თქვენ შეგიძლიათ აიძულოთ რესურსის შეცვლა მისი წაშლით და ხელახლა შექმნით. ეს კეთდება გამოყენებით kubectl replace --force. ბრძანების გაშვება დაუყოვნებლივ შლის რესურსებს და შემდეგ ხელახლა ქმნის მათ მოწოდებული სპეციფიკაციებიდან. API-ში არ არის „force change“ დამმუშავებელი და იმისათვის, რომ ეს გააკეთოთ API-ს მეშვეობით, თქვენ უნდა შეასრულოთ ორი ოპერაცია. პირველ რიგში, თქვენ უნდა წაშალოთ რესურსი მისი დაყენებით gracePeriodSeconds ნულამდე (0) და propagationPolicy "ფონში" და შემდეგ ხელახლა შექმენით ეს რესურსი სასურველი სპეციფიკაციით.

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

მიმართეთ სერვერის მხარეს

როგორც ზემოთ აღინიშნა, Kubernetes-ის დეველოპერები მუშაობენ ლოგიკის განხორციელებაზე apply საქართველოს kubectl Kubernetes API-ში. ლოგიკა apply ხელმისაწვდომია Kubernetes 1.18 მეშვეობით kubectl apply --server-side ან API-ის საშუალებით მეთოდის გამოყენებით PATCH с content-type application/apply-patch+YAML.

შენიშვნა: JSON ასევე მოქმედებს YAML, ასე რომ თქვენ შეგიძლიათ გაგზავნოთ სპეციფიკაცია JSON-ად, თუნდაც content-type ნება application/apply-patch+yaml.

გარდა ამ ლოგიკისა kubectl ყველასთვის ხელმისაწვდომი ხდება API-ის საშუალებით, apply სერვერის მხარეს, თვალყურს ადევნებს ვინ არის პასუხისმგებელი სპეციფიკაციის ველებზე, რითაც იძლევა უსაფრთხო მრავალჯერად წვდომას მისი უკონფლიქტო რედაქტირებისთვის. სხვა სიტყვებით რომ ვთქვათ, თუ apply სერვერის მხარეს უფრო ფართოდ გავრცელდება, უნივერსალური უსაფრთხო რესურსების მართვის ინტერფეისი გამოჩნდება სხვადასხვა კლიენტებისთვის, მაგალითად, kubectl, Pulumi ან Terraform, GitOps, ისევე როგორც თვითნაწერი სკრიპტები კლიენტის ბიბლიოთეკების გამოყენებით.

შედეგები

ვიმედოვნებ, რომ კლასტერებში რესურსების განახლების სხვადასხვა გზების ეს მოკლე მიმოხილვა თქვენთვის სასარგებლო იყო. კარგია იცოდეთ, რომ ეს არ არის მხოლოდ გამოყენება და ჩანაცვლება; შესაძლებელია რესურსის განახლება განაცხადის, რედაქტირების, დაყენების ან ჩანაცვლების გამოყენებით. ყოველივე ამის შემდეგ, პრინციპში, თითოეულ მიდგომას აქვს საკუთარი გამოყენების სფერო. ატომური ცვლილებებისთვის, ჩანაცვლება სასურველია; წინააღმდეგ შემთხვევაში, თქვენ უნდა გამოიყენოთ სტრატეგიული შერწყმის პატჩი განაცხადის საშუალებით. სულ მცირე, მე ველი, რომ გესმით, რომ არ შეგიძლიათ ენდოთ Google-ს ან StackOerflow-ს, როდესაც ეძებთ "kubernetes application vs change". ყოველ შემთხვევაში, სანამ ეს სტატია არ შეცვლის ამჟამინდელ პასუხს.

წყარო: www.habr.com