Правилно сравнение на Kubernetes Apply, Replace и Patch

Kubernetes има няколко опции за актуализиране на ресурси: прилагане, редактиране, корекция и замяна. Има объркване относно това какво прави всеки от тях и кога да ги използва. Нека да го разберем.

ако търсене в Google се намира фразата „kubernetes apply vs replace“. отговор на StackOverflow, което не е правилно. При търсене „kubernetes apply 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 няма да работи, ако настъпят промени между четенето и подмяната на ресурса.

API на Kubernetes

Вероятно сте запознати с методите 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 използва за проследяване на промените си, така че всички промени, които се проследяват и правят чрез API на Kubernetes, но се правят чрез команди edit и patch, невидим за следващите команди applyТова означава, че apply не ги премахва, дори ако не се появяват във входната спецификация за apply (Документацията казва това edit и patch правете актуализации на използваните бележки apply, но на практика - не).

Ако не използвате командата apply, може да се използва като editИ patch, като изберете командата, която най-добре отговаря на извършваната промяна. Когато добавяте и променяте свойства на BOM, двата подхода са приблизително еднакви. При изтриване на свойства на спецификация или елементи на масив edit се държи като еднократно стартиране apply, включително проследяване каква е била спецификацията преди и след редактирането й, така че можете изрично да премахнете свойства и елементи на масив от ресурс. Трябва изрично да зададете стойността на свойството на нула в спецификацията за 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

В някои случаи трябва да сте сигурни, че не са направени промени в даден ресурс между момента, в който ресурсът е прочетен, и когато е актуализиран. С други думи, трябва да сте сигурни, че всички промени ще бъдат атомен. В този случай, за да актуализирате ресурсите, които трябва да използвате 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. Това ще накара брояча да се увеличи с две и бележката „актуализирано от“ да включва „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 няма манипулатор за „принудителна замяна“ и за да направите това чрез API, трябва да извършите две операции. Първо трябва да изтриете ресурса, като настроите за него gracePeriodSeconds до нула (0) и propagationPolicy във „Фон“ и след това създайте отново този ресурс с желаната спецификация.

Предупреждение: Този подход е потенциално опасен и може да доведе до недефинирано състояние.

Приложете от страната на сървъра

Както бе споменато по-горе, разработчиците на Kubernetes работят върху внедряването на логиката apply на kubectl в API на Kubernetes. Логики 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 apply vs replace“. Поне докато тази статия не замени текущия отговор.

Източник: www.habr.com