Kubernetesте ресурстарды жаңыртуу үчүн бир нече варианттар бар: колдонуу, түзөтүү, жамоо жана алмаштыруу. Ар бири эмне кылат жана аларды качан колдонуу керектиги боюнча башаламандык бар. Келгиле, аны аныктап көрөлү.
эгер "kubernetes apply vs replace" деген сөз айкашы жайгашкан , бул туура эмес. "kubernetes application vs patch" биринчи шилтемеси үчүн документация kubectl patch, бул салыштырууну камтыбайт apply и patch. Бул макалада ар кандай варианттарды, ошондой эле ар бирин туура колдонууну карайбыз.
Kubernetes ресурсунун (кызмат, жайылтуу, кирүү ж.б.) иштөө циклинин жүрүшүндө кээде бул ресурстун кээ бир касиеттерин өзгөртүү, кошуу же алып салуу керек болот. Мисалы, эскертүү кошуу, репликалардын санын көбөйтүү же азайтуу.
Kubernetes CLI
Эгер сиз CLI аркылуу Kubernetes кластерлери менен мурунтан эле иштеп жатсаңыз, сиз буга чейин таанышсыз apply и edit. Command apply файлдан ресурстун спецификациясын окуйт жана Kubernetes кластерине "жогорулатуу" жасайт, б.а. эгерде ал жок болсо, ресурсту түзөт жана бар болсо жаңылайт. Команда edit API аркылуу ресурсту окуйт, андан кийин ресурстун спецификациясын локалдык файлга жазат, андан кийин текст редакторунда ачылат. Файлды түзөтүп жана сактагандан кийин, kubectl API аркылуу киргизилген өзгөртүүлөрдү кайра жөнөтөт, ал бул өзгөртүүлөрдү ресурска кылдаттык менен колдонот.
Буйруктарды баары эле биле бербейт patch и replace. Command patch буйрук сабында өзгөртүлгөн бөлүгүн гана камсыз кылуу менен ресурстун спецификациясынын бир бөлүгүн өзгөртүүгө мүмкүндүк берет. Команда replace менен бирдей иштейт edit, бирок бардыгын кол менен жасоо керек: ресурстун спецификациясынын учурдагы версиясын жүктөп алышыңыз керек, мисалы, kubectl get -o yaml, түзөтүп, анан колдонуңуз replace өзгөртүлгөн спецификацияга ылайык ресурсту жаңыртуу. Команда replace ресурсту окуу менен алмаштыруунун ортосунда кандайдыр бир өзгөрүүлөр болсо иштебейт.
Kubernetes API
Сиз ыкмалары менен тааныш болсоңуз керек CoreV1().Pods().Update(), replaceNamespacedService же patch_namespaced_deployment, аркылуу кластерлер менен иштесеңиз кээ бир программалоо тилин колдонуу. Китепкана бул ыкмаларды методдорду колдонуу менен 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 под контейнердин спецификациясында жаңы чөйрө өзгөрмөлүүлүгү менен, ошол чөйрө өзгөрмөсүн алардын үстүнө жазуунун ордуна, учурдагы чөйрө өзгөрмөлөрүнө кошууга алып келет. Бул ыкманы колдонуу менен алып салуу үчүн, берилген спецификацияда параметр маанисин нөлгө мажбурлашыңыз керек. Кайсы команда 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, анын ичинде спецификациянын түзөтүлгөнгө чейин жана кийин кандай болгонуна көз салуу, ошондуктан сиз ресурстан касиеттерди жана массив элементтерин ачык эле алып салсаңыз болот. Сиз спецификацияда өзгөчөлүктүн маанисин нөлгө так коюшуңуз керек patchаны ресурстан алып салуу. Массив элементин стратегиялык бириктирүү жамаачы менен алып салуу татаалыраак, анткени ал бириктирүү директивасын колдонууну талап кылат. Көбүрөөк ылайыктуу альтернативалар үчүн төмөнкү жаңыртуу ыкмаларын караңыз.
Кардар китепканасында жогорудагы буйруктарга окшош жаңыртуу ыкмаларын ишке ашыруу үчүн kubectl, суроо-талаптарда белгилениши керек content-type в application/strategic-merge-patch+json. Эгерде сиз спецификациядагы касиеттерди алып салгыңыз келсе, алардын маанилерин так ушундай жол менен нөлгө коюуңуз керек. kubectl patch. Эгерде сиз массивдин элементтерин алып салышыңыз керек болсо, жаңыртуу спецификациясына бириктирүү директивасын кошушуңуз керек же жаңыртууларга башка ыкманы колдонушуңуз керек.
Жаңыртууларга башка ыкмалар
Kubernetes эки башка жаңыртуу ыкмасын колдойт: и . JSON бириктирүү патч ыкмасы киргизүү катары жарым-жартылай Kubernetes спецификациясын алат жана стратегиялык бириктирүү жамаачы ыкмасына окшош объекттерди бириктирүүнү колдойт. Экөөнүн ортосундагы айырма, ал массивди алмаштырууну гана колдойт, анын ичинде подспецификациядагы контейнер массиви. Бул JSON бириктирүү патчын колдонуп жатканда, кандайдыр бир контейнердин касиеттери өзгөргөн учурда бардык контейнерлер үчүн толук мүнөздөмөлөрдү беришиңиз керек дегенди билдирет. Ошентип, бул ыкма БОМдогу массивден элементтерди алып салуу үчүн пайдалуу. Буйрук сабында сиз колдонуп 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 ресурсту жаңылайт
Натыйжада А жаңыртылышы жоголот. Акыркы операция patch утат, эсептегич эки эмес, бир көбөйөт жана "жаңыртылган" нотасынын мааниси "В" менен аяктайт жана "А" ны камтыбайт. Келгиле, жаңыртуулар ыкманы колдонуу менен аткарылганда эмне болоору менен жогорудагыларды салыштырып көрөлү replace:
- A жана B API'ден ресурстун учурдагы абалын алышат
- Ар бири спецификацияны эсептегичти бирден көбөйтүү жана ошондой эле "жаңыланган" эскертүүсүнө тиешелүүлүгүнө жараша "A" же "B" кошуу менен жергиликтүү түрдө жаңыртат.
- Жана бул ресурсту бир аз тезирээк жаңыртат
- B ресурсту жаңыртууга аракет кылат, бирок жаңыртуу API тарабынан четке кагылган, анткени ресурстун версиясы спецификацияда
replaceКубернетестеги ресурстун учурдагы версиясына дал келбейт, анткени ресурстун версиясы А алмаштыруу операциясы менен көбөйтүлгөн.
Жогорудагы учурда, В ресурсту кайра алып, жаңы абалга өзгөртүүлөрдү киргизип, кайра аракет кылышы керек болот 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 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, ошондой эле кардар китепканаларын колдонуу менен өз алдынча жазылган скрипттер.
натыйжалары
Кластерлердеги ресурстарды жаңыртуунун ар кандай жолдоруна кыскача сереп салуу сизге пайдалуу болду деп үмүттөнөм. Бул жөн гана колдонуу менен алмаштыруу эмес экенин билүү жакшы; бул ресурсту колдонуу, түзөтүү, оңдоо же алмаштыруу аркылуу жаңыртууга болот. Анткени, негизинен, ар бир ыкма колдонуунун өзүнүн чөйрөсү бар. Атомдук өзгөрүүлөр үчүн алмаштыруу артык; антпесе, колдонуу аркылуу стратегиялык бириктирүү патчын колдонушуңуз керек. Жок дегенде, "kubernetes apply vs replace" деп издеп жатканда Google же StackOerflow'ка ишене албасыңызды түшүнөсүз деп күтөм. Жок дегенде, бул макала учурдагы жоопту алмаштырмайынча.
Source: www.habr.com