د کبرنیټ مناسب پرتله کول پلي کول ، ځای په ځای کول او پیچ کول

Kubernetes د سرچینو تازه کولو لپاره ډیری اختیارونه لري: پلي کول ، ترمیم کول ، پیچ کول او ځای په ځای کول. پدې اړه ګډوډي شتون لري چې هر یو څه کوي او کله یې وکاروي. راځئ چې دا معلومه کړو.

که په ګوګل کې لټون وکړئ د "kubernetes Apply vs replace" جمله موقعیت لري StackOverflow ته ځواب، کوم چې سم نه دی. کله چې لټون کول "kubernetes apply vs patch" لومړی لینک د دې لپاره اسناد دي kubectl patchپه کوم کې چې پرتله کول شامل نه دي apply и patch. دا مقاله به مختلف انتخابونه وګوري، او همدارنګه د هر یو مناسب استعمال.

د Kubernetes سرچینې د ژوند دورې په جریان کې (خدمت، ځای پرځای کول، ننوتل، او نور)، ځینې وختونه تاسو اړتیا لرئ چې د دې سرچینې ځینې ملکیتونه بدل کړئ، اضافه کړئ یا لرې کړئ. د مثال په توګه، یو نوټ اضافه کړئ، د نقلونو شمیر زیات یا کم کړئ.

Kubernetes CLI

که تاسو دمخه د CLI له لارې د Kubernetes کلسترونو سره کار کوئ ، تاسو دمخه ورسره آشنا یاست apply и edit. ټیم apply د فایل څخه د سرچینې توضیحات لولي او د کوبرنیټس کلستر ته "اپسرټ" جوړوي، د بیلګې په توګه. سرچینه رامینځته کوي که چیرې شتون ونلري او دا تازه کوي که شتون ولري. ټیم 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, i.e. د موجودو سرچینو رامینځته کول او د موجودو تازه کول په بشپړ ډول د کوډ اړخ کار کوي kubectl. هڅې روانې دي د منطق لیږد په اړه apply د API اړخ ته، مګر دا لاهم په بیټا کې دی. زه به لاندې نور تفصیل لیکم.

په ډیفالټ پیچ

غوره کارول patch، که تاسو غواړئ سرچینه تازه کړئ. دا څنګه د مراجعینو کتابتونونه دواړه د Kubernetes API په سر کې کار کوي او kubectl (د حیرانتیا خبره نده، ځکه چې دا د مراجعینو کتابتون لپاره یو ریپر دی، نږدې ژباړن).

ستراتیژیک کار وکړئ

ټول ټیمونه kubectl apply, edit и patch طریقه وکاروئ PATCH په HTTP کې د موجوده سرچینې تازه کولو غوښتنه کوي. که تاسو په ډیر تفصیل سره د قوماندې پلي کولو ته پام وکړئ ، نو دا ټول طریقه کاروي ستراتیژیک یوځای کول د سرچینو تازه کولو لپاره، که څه هم قومانده patch کیدای شي نورې لارې وکاروئ (لاندې په دې اړه نور). د ستراتیژیک انضمام پیچ کولو طریقه هڅه کوي چې چمتو شوي توضیحات د موجوده توضیحاتو سره یوځای کولو سره "دا سم ترلاسه کړي". په ځانګړې توګه، دا هڅه کوي چې دواړه توکي او سرې سره یوځای کړي، پدې معنی چې بدلونونه اضافي وي. د مثال په توګه، کمانډ چلول patch د پوډ کانټینر مشخصاتو کې د نوي چاپیریال متغیر سره ، د دې لامل کیږي چې د چاپیریال متغیر په اوسني چاپیریال متغیرونو کې د دوی د لیکلو پرځای اضافه شي. د دې طریقې په کارولو سره د لرې کولو لپاره، تاسو باید په چمتو شوي مشخصاتو کې د پیرامیټر ارزښت null ته مجبور کړئ. کوم ټیمونه kubectl ایا د تازه کولو لپاره کارول غوره دي؟

که تاسو په کارولو سره خپل منابع جوړ او اداره کړي kubectl apply، کله چې تازه کول دا غوره ده چې تل وکاروئ kubectl applyنو داسې kubectl کولی شي تنظیمات اداره کړي او له غوښتنلیک څخه غوښتنلیک ته غوښتل شوي بدلونونه په سمه توګه تعقیب کړي. ګټه تل کارول apply دا دی چې دا د مخکینۍ پلي شوي توضیحاتو تعقیب ساتي، دا اجازه ورکوي چې پوه شي کله چې د ځانګړتیاوو ملکیتونه او سرې عناصر په ښکاره ډول لیرې شوي. دا تاسو ته اجازه درکوي چې وکاروي apply د ملکیتونو او صفاتو عناصرو لرې کولو لپاره، پداسې حال کې چې یو نورمال ستراتیژیک انضمام به کار ونکړي. ټیمونه edit и patch یادداشتونه تازه مه کوئ kubectl apply د دې بدلونونو تعقیبولو لپاره کاروي ، نو کوم بدلونونه چې تعقیب شوي او د کوبرنیټس 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 جزوي توضیحات اخلي او د ستراتیژیک-ضمیمه پیچ کولو طریقې ته ورته شیانو ادغام ملاتړ کوي. د دواړو ترمینځ توپیر دا دی چې دا یوازې د صف بدلولو ملاتړ کوي ، پشمول د پوډ مشخصاتو کې د کانټینر صف. دا پدې مانا ده چې کله د JSON ادغام پیچ وکاروئ ، تاسو اړتیا لرئ د ټولو کانټینرونو لپاره بشپړ مشخصات چمتو کړئ که چیرې د کوم کانټینر ملکیت بدل شي. نو دا طریقه په BOM کې د صف څخه د عناصرو لرې کولو لپاره ګټوره ده. د کمانډ لاین کې تاسو کولی شئ د 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 سرچینه تازه کوي

د پایلې په توګه، 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 په 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 د سرور اړخ کې به خورا پراخه شي ، د نړیوال خوندي سرچینې مدیریت انٹرفیس به د مختلف پیرودونکو لپاره څرګند شي ، د مثال په توګه ، کیوبیکل ، پلومي یا ټیرفارم ، ګیټوپس ، او همدارنګه د پیرودونکي کتابتونونو په کارولو سره پخپله لیکل شوي سکریپټونه.

پایلې

زه امید لرم چې په کلسترونو کې د سرچینو تازه کولو لپاره د مختلف لارو لنډه کتنه ستاسو لپاره ګټوره وه. دا ښه ده چې پوه شئ چې دا یوازې د بدلولو په مقابل کې پلي کول ندي؛ دا ممکنه ده چې د پلي کولو، ایډیټ کولو، پیچ یا بدلولو په کارولو سره سرچینې تازه کړئ. په هرصورت، په اصولو کې، هر طریقه د خپل غوښتنلیک ساحه لري. د اټومي بدلونونو لپاره، ځای په ځای کول غوره دي؛ که نه نو، تاسو باید د پلي کولو له لارې ستراتیژیک-ضمیمه پیچ وکاروئ. لږترلږه، زه تمه لرم چې تاسو پوه شئ چې تاسو په ګوګل یا StackOerflow باور نشئ کولی کله چې د "kubernetes apply vs replace" لټون کوئ. لږترلږه تر هغه چې دا مقاله اوسنی ځواب بدل کړي.

سرچینه: www.habr.com