Kubernetes нь нөөцийг шинэчлэх хэд хэдэн сонголттой: хэрэглэх, засварлах, нөхөх, солих. Хүн бүр юу хийдэг, хэзээ ашиглах талаар эргэлзээтэй байдаг. Үүнийг олж мэдье.
бол "kubernetes apply vs replace" гэсэн хэллэг байрладаг , энэ нь зөв биш юм. "kubernetes application vs patch" гэсэн эхний холбоос нь баримт бичиг юм kubectl patch, үүнд харьцуулалтыг оруулаагүй болно apply и patch. Энэ нийтлэлд янз бүрийн сонголтууд, мөн тус бүрийг зөв ашиглах талаар авч үзэх болно.
Kubernetes нөөцийн ашиглалтын хугацаанд (үйлчилгээ, байршуулалт, нэвтрэлт гэх мэт) заримдаа та энэ нөөцийн зарим шинж чанарыг өөрчлөх, нэмэх эсвэл хасах шаардлагатай болдог. Жишээлбэл, тэмдэглэл нэмэх, хуулбарын тоог нэмэгдүүлэх эсвэл багасгах.
Kubernetes CLI
Хэрэв та CLI-ээр дамжуулан Kubernetes кластеруудтай аль хэдийн ажиллаж байгаа бол та аль хэдийн мэддэг болсон байна. apply и edit. Баг apply файлаас нөөцийн тодорхойлолтыг уншиж, Kubernetes кластер руу "дээшлэх" үйлдэл хийдэг, i.e. Хэрэв байхгүй бол нөөцийг үүсгэж, байгаа бол шинэчилнэ. Баг edit API-ээр дамжуулан эх сурвалжийг уншиж, дараа нь нөөцийн тодорхойлолтыг локал файлд бичиж, дараа нь текст засварлагчаар нээгддэг. Файлыг засварлаж хадгалсны дараа, kubectl API-ээр дамжуулан хийсэн өөрчлөлтүүдийг буцааж илгээх бөгөөд энэ нь эдгээр өөрчлөлтүүдийг нөөцөд сайтар хэрэгжүүлэх болно.
Хүн бүр тушаалуудыг мэддэггүй patch и replace. Баг 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 pod контейнерийн тодорхойлолтод орчны шинэ хувьсагчтай байгаа нь тухайн орчны хувьсагчийг дарж бичихийн оронд одоо байгаа орчны хувьсагчдад нэмэхэд хүргэдэг. Энэ аргыг ашиглан арилгахын тулд та өгсөн тодорхойлолтод параметрийн утгыг null болгох шаардлагатай. Аль баг 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, хийгдэж буй өөрчлөлтөд хамгийн сайн тохирох командыг сонгох. Монголбанкны шинж чанарыг нэмэх, өөрчлөх үед хоёр арга нь ойролцоогоор ижил байна. Тодорхойлолтын шинж чанарууд эсвэл массивын элементүүдийг устгах үед edit нэг удаагийн хөөргөх мэт аашилдаг apply, үүнд засварлахаас өмнө болон дараа нь техникийн үзүүлэлт ямар байсныг хянах, ингэснээр та нөөцөөс шинж чанар болон массивын элементүүдийг тодорхой устгах боломжтой. Тодорхойлолтод та өмчийн утгыг null гэж тодорхой тохируулах хэрэгтэй patchнөөцөөс устгах. Стратегийн нэгтгэх нөхөөсийг ашиглан массив элементийг устгах нь нэгтгэх удирдамжийг ашиглахыг шаарддаг тул илүү төвөгтэй байдаг. Илүү боломжит хувилбаруудыг доороос сайжруулах бусад аргуудыг үзнэ үү.
Үйлчлүүлэгчийн номын санд дээрх командуудтай ижил төстэй шинэчлэлтийн аргуудыг хэрэгжүүлэх kubectl, хүсэлтэд тохируулсан байх ёстой content-type в application/strategic-merge-patch+json. Хэрэв та тодорхойлолтод байгаа шинж чанаруудыг устгахыг хүсвэл ижил төстэй байдлаар тэдгээрийн утгыг null гэж тодорхой тохируулах хэрэгтэй. kubectl patch. Хэрэв та массивын элементүүдийг устгах шаардлагатай бол шинэчлэлтийн тодорхойлолтод нэгтгэх зааврыг оруулах эсвэл шинэчлэлтийн өөр аргыг ашиглах хэрэгтэй.
Шинэчлэлт хийх бусад аргууд
Kubernetes нь өөр хоёр шинэчлэлтийн аргыг дэмждэг: и . JSON нэгтгэх засварын арга нь хэсэгчилсэн Kubernetes тодорхойлолтыг оролт болгон авч, стратегийн нэгтгэх нөхөөсийн аргатай төстэй объектуудыг нэгтгэхийг дэмждэг. Энэ хоёрын ялгаа нь зөвхөн массивыг солих, түүний дотор pod тодорхойлолт дахь контейнер массивыг дэмждэгт оршино. Энэ нь JSON нэгтгэх нөхөөсийг ашиглахдаа аливаа контейнерийн шинж чанар өөрчлөгдөх тохиолдолд бүх контейнерт бүрэн техникийн үзүүлэлтүүдийг өгөх шаардлагатай гэсэн үг юм. Тиймээс энэ арга нь Монголбанкны массиваас элементүүдийг устгахад тустай. Тушаалын мөрөнд та JSON нэгтгэх нөхөөсийг ашиглан сонгож болно kubectl patch --type=merge. Kubernetes API-тай ажиллахдаа хүсэлтийн аргыг ашиглах хэрэгтэй PATCH болон суурилуулалт content-type в application/merge-patch+json.
JSON засварын арга нь нөөцийн хэсэгчилсэн тодорхойлолтыг өгөхийн оронд массивын элемент бүр нь нөөцөд хийгдэж буй өөрчлөлтийн тайлбарыг илэрхийлдэг массив болгон нөөцөд оруулахыг хүссэн өөрчлөлтийг ашигладаг. Энэ арга нь хийгдэж буй өөрчлөлтийг илэрхийлэх илүү уян хатан бөгөөд хүчирхэг арга боловч хэсэгчилсэн нөөцийн тодорхойлолтыг илгээхээс илүүтэйгээр хийгдэж буй өөрчлөлтүүдийг Кубернетийн бус форматаар тусад нь жагсаах зардал юм. 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нь Кубернетес дэх нөөцийн одоогийн хувилбартай таарахгүй байна, учир нь нөөцийн хувилбар нь А-ийн солих үйлдлээр нэмэгдсэн.
Дээрх тохиолдолд 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 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-д итгэж болохгүй гэдгийг ойлгох байх гэж найдаж байна. Наад зах нь энэ нийтлэл одоогийн хариултыг солих хүртэл.
Эх сурвалж: www.habr.com