Kubernetes qo'llash, almashtirish va yamoqlarni to'g'ri taqqoslash

Kubernetes resurslarni yangilash uchun bir nechta variantga ega: qo'llash, tahrirlash, tuzatish va almashtirish. Har birining nima qilishi va ularni qachon ishlatishi haqida chalkashliklar mavjud. Keling, buni aniqlaylik.

agar Googleda qidiring "kubernetes amal va almashtirish" iborasi joylashgan StackOverflow-ga javob bering, bu to'g'ri emas. Qidirayotganda "kubernetes apply vs patch" birinchi havolasi hujjatdir kubectl patch, bu taqqoslashni o'z ichiga olmaydi apply и patch. Ushbu maqolada turli xil variantlar, shuningdek, har biridan to'g'ri foydalanish ko'rib chiqiladi.

Kubernetes resursining hayot aylanishi davomida (xizmat, joylashtirish, kirish va h.k.) ba'zan siz ushbu resursning ayrim xususiyatlarini o'zgartirishingiz, qo'shishingiz yoki olib tashlashingiz kerak bo'ladi. Masalan, eslatma qo'shing, nusxalar sonini oshiring yoki kamaytiring.

Kubernetes CLI

Agar siz allaqachon CLI orqali Kubernetes klasterlari bilan ishlayotgan bo'lsangiz, siz allaqachon tanishsiz. apply и edit. Jamoa apply fayldan manba spetsifikatsiyasini o'qiydi va Kubernetes klasteriga "yuqori" qiladi, ya'ni. resurs mavjud bo'lmasa, uni yaratadi va agar mavjud bo'lsa, uni yangilaydi. Jamoa edit API orqali resursni o'qiydi, so'ngra resurs spetsifikatsiyasini mahalliy faylga yozadi, keyin esa matn muharririda ochiladi. Faylni tahrirlash va saqlashdan so'ng, kubectl API orqali kiritilgan o'zgarishlarni qaytarib yuboradi, bu o'zgarishlarni resursga ehtiyotkorlik bilan qo'llaydi.

Hamma ham buyruqlarni bilmaydi patch и replace. Jamoa patch buyruq satrida faqat o'zgartirilgan qismini ta'minlab, resurs spetsifikatsiyasining bir qismini o'zgartirishga imkon beradi. Jamoa replace bilan bir xil ishlaydi edit, lekin hamma narsa qo'lda bajarilishi kerak: siz resurs spetsifikatsiyasining joriy versiyasini yuklab olishingiz kerak, masalan, kubectl get -o yaml, tahrirlang, keyin foydalaning replace resursni o'zgartirilgan spetsifikatsiyaga muvofiq yangilash. Jamoa replace resursni o'qish va almashtirish o'rtasida har qanday o'zgarishlar bo'lsa, ishlamaydi.

Kubernetes API

Ehtimol, siz usullar bilan tanishsiz CoreV1().Pods().Update(), replaceNamespacedService yoki patch_namespaced_deployment, orqali klasterlar bilan ishlasangiz Kubernetes API uchun mijozlar kutubxonasi ba'zi dasturlash tillaridan foydalanish. Kutubxona ushbu usullarni usullardan foydalangan holda HTTP so'rovlari orqali boshqaradi PUT и PATCH. Bu holda, update и replace foydalanish PUTva patch, qanchalik ahamiyatsiz bo'lmasin, foydalanadi PATCH.

Shuni ta'kidlash kerak kubectl API orqali klasterlar bilan ham ishlaydi. Boshqa so'zlar bilan aytganda, kubectlGo tili uchun mijozlar kutubxonasining yuqori qismidagi oʻram boʻlib, u asosan standart API imkoniyatlariga qoʻshimcha ravishda kichik buyruqlarni yanada ixcham va oʻqilishi mumkin boʻlgan shaklda taqdim etish imkoniyatini beradi. Misol uchun, siz allaqachon payqaganingizdek, usul apply oldingi bandda yuqorida aytilmagan. Hozirda (2020 yil may, taxminan. tarjimon) barcha mantiq kubectl apply, ya'ni. mavjud bo'lmagan resurslarni yaratish va mavjudlarini yangilash, butunlay kod tomonida ishlaydi kubectl. Harakat qilinmoqda mantiqiy uzatish bo'yicha apply API tomoniga, lekin u hali ham beta-versiyada. Quyida batafsilroq yozaman.

Yamoq sukut bo'yicha

Eng yaxshi ishlatilgan patch, agar siz resursni yangilamoqchi bo'lsangiz. Ikkala mijoz kutubxonasi ham Kubernetes API ustida shunday ishlaydi va kubectl (bu ajablanarli emas, chunki u mijozlar kutubxonasi uchun o'ram, taxminan. tarjimon).

Strategik ishlang

Barcha jamoalar kubectl apply, edit и patch usulidan foydalaning PATCH mavjud resursni yangilash uchun HTTP so'rovlarida. Agar siz buyruqlarni bajarishni batafsilroq o'rgansangiz, ularning barchasi yondashuvdan foydalanadi strategik birlashma tuzatish buyruq bo'lsa-da, resurslarni yangilash uchun patch boshqa yondashuvlardan foydalanishi mumkin (quyida bu haqda batafsilroq). Strategik birlashma tuzatish yondashuvi taqdim etilgan spetsifikatsiyani mavjud spetsifikatsiya bilan birlashtirish orqali "to'g'ri" qilishga harakat qiladi. Aniqroq qilib aytganda, u ob'ektlar va massivlarni birlashtirishga harakat qiladi, ya'ni o'zgarishlar qo'shimcha bo'ladi. Masalan, buyruqni ishga tushirish patch pod konteyner spetsifikatsiyasida yangi muhit o'zgaruvchisi bilan ushbu muhit o'zgaruvchisini ularni qayta yozish o'rniga mavjud muhit o'zgaruvchilariga qo'shilishiga olib keladi. Ushbu yondashuv yordamida olib tashlash uchun siz taqdim etilgan spetsifikatsiyada parametr qiymatini nullga majburlashingiz kerak. Qaysi jamoalar kubectl Yangilash uchun foydalanish yaxshiroqmi?

Agar siz o'z resurslaringizni ishlatib yaratsangiz va boshqarsangiz kubectl apply, yangilashda har doim foydalanish yaxshidir kubectl applyuchun kubectl konfiguratsiyani boshqarishi va ilovadan ilovaga so'ralgan o'zgarishlarni to'g'ri kuzatishi mumkin edi. Afzallik har doim foydalaning apply u ilgari qo'llanilgan spetsifikatsiyani kuzatib boradi va spetsifikatsiya xususiyatlari va massiv elementlari qachon aniq o'chirilganligini bilish imkonini beradi. Bu sizga foydalanish imkonini beradi apply xususiyatlar va massiv elementlarini olib tashlash uchun, oddiy strategik birlashma esa ishlamaydi. Jamoalar edit и patch eslatmalarni yangilamang kubectl apply uning o'zgarishlarini kuzatish uchun foydalanadi, shuning uchun Kubernetes API orqali kuzatiladigan va amalga oshiriladigan, ammo buyruqlar orqali amalga oshiriladigan har qanday o'zgarishlar edit и patch, keyingi buyruqlar uchun ko'rinmas apply, ya'ni apply uchun kirish spetsifikatsiyasida ko'rinmasa ham, ularni olib tashlamaydi apply (Hujjatlarda shunday deyilgan edit и patch foydalanilgan eslatmalarni yangilash apply, lekin amalda - yo'q).

Agar siz buyruqni ishlatmasangiz apply, sifatida ishlatilishi mumkin edit, va patch, amalga oshirilayotgan o'zgartirishga eng mos keladigan buyruqni tanlash. BOM xususiyatlarini qo'shish va o'zgartirishda ikkala yondashuv ham taxminan bir xil bo'ladi. Spetsifikatsiya xususiyatlarini yoki massiv elementlarini o'chirishda edit bir martalik ishga tushirish kabi harakat qiladi apply, jumladan, spetsifikatsiya tahrirlangandan oldin va keyin qanday boʻlganligini kuzatish, shuning uchun siz manbadan xususiyatlar va massiv elementlarini aniq olib tashlashingiz mumkin. Spetsifikatsiyada xossa qiymatini nolga aniq belgilashingiz kerak patchuni resursdan olib tashlash uchun. Strategik birlashma tuzatish yordamida massiv elementini olib tashlash ancha murakkab, chunki u birlashtirish direktivalaridan foydalanishni talab qiladi. Muqobilroq alternativalar uchun quyida boshqa yangilash yondashuvlariga qarang.

Mijoz kutubxonasida yuqoridagi buyruqlarga o'xshash yangilash usullarini amalga oshirish uchun kubectl, so'rovlarda o'rnatilishi kerak content-type в application/strategic-merge-patch+json. Agar siz spetsifikatsiyadagi xususiyatlarni o'chirmoqchi bo'lsangiz, ularning qiymatlarini xuddi shunday tarzda aniq belgilashingiz kerak. kubectl patch. Agar siz massiv elementlarini olib tashlashingiz kerak bo'lsa, yangilanish spetsifikatsiyasiga birlashma ko'rsatmalarini kiritishingiz yoki yangilanishlarga boshqa yondashuvdan foydalanishingiz kerak.

Yangilanishlarga boshqa yondashuvlar

Kubernetes yana ikkita yangilash yondashuvini qo'llab-quvvatlaydi: JSON birlashtirish patchi и JSON patch. JSON birlashma tuzatish usuli kirish sifatida qisman Kubernetes spetsifikatsiyasini oladi va strategik birlashma tuzatish usuliga o'xshash ob'ektlarni birlashtirishni qo'llab-quvvatlaydi. Ularning orasidagi farq shundaki, u faqat massivni almashtirishni qo'llab-quvvatlaydi, shu jumladan pod spetsifikatsiyasidagi konteyner massivi. Bu shuni anglatadiki, JSON birlashma patchidan foydalanganda, agar biron bir konteyner xususiyati o'zgargan bo'lsa, barcha konteynerlar uchun to'liq texnik xususiyatlarni taqdim etishingiz kerak. Shunday qilib, bu yondashuv BOMdagi massivdan elementlarni olib tashlash uchun foydalidir. Buyruqlar satrida JSON birlashma yamog'idan foydalanib tanlashingiz mumkin kubectl patch --type=merge. Kubernetes API bilan ishlashda siz so'rov usulidan foydalanishingiz kerak PATCH va o'rnatish content-type в application/merge-patch+json.

JSON yamoq yondashuvi resursning qisman spetsifikatsiyasini taqdim etish o‘rniga, resursga kiritmoqchi bo‘lgan o‘zgarishlarni massiv sifatida taqdim etishdan foydalanadi, bunda massivning har bir elementi resursga kiritilgan o‘zgartirish tavsifini ifodalaydi. Ushbu yondashuv amalga oshirilayotgan o'zgarishlarni ifodalashning yanada moslashuvchan va kuchli usuli bo'lib, lekin qisman manba spetsifikatsiyasini jo'natish o'rniga, amalga oshirilayotgan o'zgarishlarni alohida, Kubernetdan tashqari formatda sanab o'tish evaziga. IN kubectl yordamida JSON patchini tanlashingiz mumkin kubectl patch --type=json. Kubernetes API-dan foydalanganda ushbu yondashuv so'rov usuli yordamida ishlaydi PATCH va o'rnatish content-type в application/json-patch+json.

Bizga ishonch kerak - almashtirishdan foydalaning

Ba'zi hollarda, resurs o'qilgan vaqt va yangilangan vaqt oralig'ida resursga hech qanday o'zgartirish kiritilmaganligiga ishonch hosil qilishingiz kerak. Boshqacha qilib aytganda, barcha o'zgarishlar bo'lishiga ishonch hosil qilishingiz kerak atom. Bunday holda, resurslarni yangilash uchun siz foydalanishingiz kerak replace. Misol uchun, agar sizda bir nechta manbalar tomonidan yangilangan hisoblagichga ega ConfigMap bo'lsa, ikkita manba bir vaqtning o'zida hisoblagichni yangilamasligiga ishonch hosil qilishingiz kerak, bu esa yangilanishning yo'qolishiga olib keladi. Ko'rsatish uchun yondashuvdan foydalangan holda voqealar ketma-ketligini tasavvur qiling patch:

• A va B API dan resursning joriy holatini oladi
• Ularning har biri hisoblagichni bittaga oshirish va “yangilangan” eslatmasiga mos ravishda “A” yoki “B” qo‘shish orqali spetsifikatsiyani mahalliy ravishda yangilaydi.
• Va u resursni biroz tezroq yangilaydi
• B resursni yangilaydi

Natijada A yangilanishi yo'qoladi. Oxirgi operatsiya patch g'alaba qozonadi, hisoblagich ikkita o'rniga bittaga oshiriladi va "yangilangan" yozuvining qiymati "B" bilan tugaydi va "A" ni o'z ichiga olmaydi. Keling, yuqoridagilarni yondashuv yordamida yangilanishlar amalga oshirilganda nima sodir bo'lishini solishtiraylik replace:

• A va B API dan resursning joriy holatini oladi
• Ularning har biri hisoblagichni bittaga oshirish va “yangilangan” eslatmasiga mos ravishda “A” yoki “B” qo‘shish orqali spetsifikatsiyani mahalliy ravishda yangilaydi.
• Va u resursni biroz tezroq yangilaydi
• B resursni yangilashga harakat qiladi, lekin yangilanish API tomonidan rad etiladi, chunki resurs versiyasi spetsifikatsiyada. replace Kubernetesdagi resursning joriy versiyasiga mos kelmaydi, chunki resurs versiyasi A ning almashtirish operatsiyasi bilan oshirilgan.

Yuqoridagi holatda B resursni qayta olib, yangi holatga o'zgartirish kiritishi va qaytadan urinib ko'rishi kerak bo'ladi replace. Bu hisoblagichning ikkiga ko'payishiga va "yangilangan" yozuvining oxirida "AB" ni qo'shishiga olib keladi.

Yuqoridagi misol bajarilayotganda shuni anglatadi replace Butun resurs butunlay almashtirildi. Spetsifikatsiya uchun foydalaniladi replace, qisman yoki qisman bo'lmasligi kerak apply, lekin to'liq, shu jumladan qo'shimcha resourceVersion spetsifikatsiya metama'lumotlariga. Agar siz yoqmagan bo'lsangiz resourceVersion yoki siz taqdim etgan versiya joriy emas, almashtirish rad etiladi. Shuning uchun foydalanish uchun eng yaxshi yondashuv replace – resursni o‘qing, uni yangilang va darhol almashtiring. Foydalanish kubectl, bu shunday ko'rinishi mumkin:

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

Shuni ta'kidlash kerakki, ketma-ket bajarilgan quyidagi ikkita buyruq muvaffaqiyatli bajariladi, chunki deployment.yaml mulkni o'z ichiga olmaydi .metadata.resourceVersion

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

Bu yuqorida aytilganlarga ziddek tuyuladi, ya'ni. "qo'shish resourceVersion spetsifikatsiya metama'lumotlariga." Buni aytish noto'g'rimi? Yo'q, unday emas, chunki agar kubectl siz belgilamagan xabarlar resourceVersion, u uni manbadan o'qiydi va siz ko'rsatgan spetsifikatsiyaga qo'shadi va shundan keyingina uni amalga oshiradi replace. Agar siz atomiklikka tayansangiz, bu potentsial xavfli bo'lgani uchun, sehr butunlay yon tomonda ishlaydi kubectl, API bilan ishlaydigan mijozlar kutubxonalaridan foydalanganda unga tayanmasligingiz kerak. Bunday holda siz joriy resurs spetsifikatsiyasini o'qib chiqishingiz, uni yangilashingiz va keyin bajarishingiz kerak bo'ladi PUT iltimos.

Siz yamoqni qila olmaysiz - biz almashtirishni amalga oshiramiz

Ba'zan siz API tomonidan boshqarilmaydigan ba'zi o'zgarishlarni kiritishingiz kerak bo'ladi. Bunday hollarda siz manbani o'chirish va qayta yaratish orqali almashtirishga majbur qilishingiz mumkin. Bu yordamida amalga oshiriladi kubectl replace --force. Buyruqni ishga tushirish resurslarni darhol olib tashlaydi va keyin ularni taqdim etilgan spetsifikatsiyadan qayta yaratadi. APIda "majburiy almashtirish" ishlov beruvchisi yo'q va buni API orqali amalga oshirish uchun siz ikkita operatsiyani bajarishingiz kerak. Avval siz manbani sozlash orqali o'chirishingiz kerak gracePeriodSeconds nolga (0) va propagationPolicy "Fon" da, so'ngra ushbu resursni kerakli spetsifikatsiya bilan qayta yarating.

Ogohlantirish: Bu yondashuv potentsial xavfli va aniqlanmagan holatga olib kelishi mumkin.

Server tomonida murojaat qiling

Yuqorida aytib o'tilganidek, Kubernetes ishlab chiquvchilari mantiqni amalga oshirish ustida ishlamoqda apply dan kubectl Kubernetes API-da. Mantiq apply Kubernetes 1.18 orqali mavjud kubectl apply --server-side yoki usul yordamida API orqali PATCH с content-type application/apply-patch+YAML.

Eslatma: JSON YAML ham amal qiladi, shuning uchun spetsifikatsiyani JSON sifatida yuborishingiz mumkin content-type bo'ladi application/apply-patch+yaml.

Bu mantiqdan tashqari kubectl API orqali hamma uchun mavjud bo'ladi, apply server tomonida spetsifikatsiyadagi maydonlar uchun kim mas'ul ekanligini kuzatib boradi va shu bilan uni ziddiyatsiz tahrirlash uchun xavfsiz bir nechta kirish imkonini beradi. Boshqacha aytganda, agar apply server tomonida keng tarqalgan bo'lib, turli mijozlar uchun universal xavfsiz resurslarni boshqarish interfeysi paydo bo'ladi, masalan, kubectl, Pulumi yoki Terraform, GitOps, shuningdek, mijoz kutubxonalari yordamida o'z-o'zidan yozilgan skriptlar.

natijalar

Umid qilamanki, klasterlardagi resurslarni yangilashning turli usullari haqida qisqacha sharh siz uchun foydali bo'ldi. Bu shunchaki qo'llash va almashtirish emasligini bilish yaxshi, balki qo'llash, tahrirlash, tuzatish yoki almashtirish orqali resursni yangilash mumkin. Axir, printsipial jihatdan, har bir yondashuv o'z qo'llash sohasiga ega. Atom o'zgarishlari uchun almashtirish afzalroqdir; aks holda, ilova orqali strategik birlashma yamog'idan foydalanishingiz kerak. Hech bo'lmaganda, "kubernetes apply vs replace" so'zlarini qidirishda Google yoki StackOerflow'ga ishonish mumkin emasligini tushunishingizni kutaman. Hech bo'lmaganda ushbu maqola joriy javobni almashtirmaguncha.

Manba: www.habr.com