Kubernetes ၏ သင့်လျော်သော နှိုင်းယှဉ်မှုကို အသုံးပြုခြင်း၊ အစားထိုးခြင်းနှင့် Patch

Kubernetes တွင် အရင်းအမြစ်များကို အပ်ဒိတ်လုပ်ရန် ရွေးချယ်စရာများစွာ ရှိသည်- အသုံးပြုရန်၊ တည်းဖြတ်ခြင်း၊ ပြင်ဆင်ခြင်းနှင့် အစားထိုးခြင်း တစ်ခုချင်းစီက ဘာတွေလုပ်သလဲ၊ ဘယ်အချိန်သုံးရမယ်ဆိုတာနဲ့ ပတ်သက်ပြီး ရှုပ်ထွေးမှုတွေ ရှိနေပါတယ်။ အဖြေရှာကြည့်ရအောင်။

လျှင် Google မှာရှာပါ။ "kubernetes apply vs replace" ဟူသော စကားစုသည် တည်ရှိသည်။ StackOverflow ကို အကြောင်းပြန်ပါ။မမှန်ပါ။ ရှာဖွေသောအခါ "kubernetes apply vs patch" ၏ ပထမလင့်ခ်သည် စာရွက်စာတမ်းများအတွက် ဖြစ်သည်။ kubectl patchနှိုင်းယှဉ်မှု မပါဝင်ပါ။ apply и patch. ဤဆောင်းပါးတွင် မတူညီသောရွေးချယ်မှုများအပြင် တစ်ခုချင်းစီ၏ သင့်လျော်သောအသုံးပြုမှုကို ကြည့်ရှုပါမည်။

Kubernetes ရင်းမြစ် (ဝန်ဆောင်မှု၊ အသုံးချမှု၊ သွင်းမှု၊ စသည်ဖြင့်) ၏ဘဝသံသရာအတွင်း တစ်ခါတစ်ရံတွင် သင်သည် ဤအရင်းအမြစ်၏ ဂုဏ်သတ္တိအချို့ကို ပြောင်းလဲရန်၊ ထည့်ရန် သို့မဟုတ် ဖယ်ရှားရန် လိုအပ်သည်။ ဥပမာအားဖြင့်၊ ပုံတူအရေအတွက်ကို တိုးရန် သို့မဟုတ် လျှော့ချရန် မှတ်စုတစ်ခုထည့်ပါ။

Kubernetes CLI

အကယ်၍ သင်သည် CLI မှတစ်ဆင့် Kubernetes အစုအဝေးများနှင့် အလုပ်လုပ်နေပါက၊ သင်နှင့် ရင်းနှီးပြီးသားဖြစ်သည်။ apply и edit. အသင်းအဖွဲ့ apply ဖိုင်မှ အရင်းအမြစ်သတ်မှတ်ချက်ကို ဖတ်ပြီး Kubernetes အစုအဝေးသို့ "upsert" ပြုလုပ်သည်။ မရှိလျှင် ရင်းမြစ်ကို ဖန်တီးပြီး ရှိလျှင် ၎င်းကို အပ်ဒိတ်လုပ်ပါ။ အသင်းအဖွဲ့ edit API မှတစ်ဆင့် အရင်းအမြစ်တစ်ခုကို ဖတ်ပြီး အရင်းအမြစ်သတ်မှတ်ချက်ကို စာသားတည်းဖြတ်မှုတွင် ဖွင့်ထားသည့် ဒေသဖိုင်တစ်ခုသို့ ရေးသည်။ ဖိုင်ကို တည်းဖြတ်ပြီး သိမ်းဆည်းပြီးနောက်၊ kubectl ဤပြောင်းလဲမှုများကို အရင်းအမြစ်သို့ ဂရုတစိုက် အသုံးချမည့် API မှတဆင့် ပြုလုပ်ထားသော အပြောင်းအလဲများကို ပြန်လည်ပေးပို့ပါမည်။

အမိန့်တွေကို လူတိုင်းမသိကြပါဘူး။ patch и replace. အသင်းအဖွဲ့ patch command line ပေါ်ရှိ ပြောင်းလဲထားသော အပိုင်းကိုသာ ပံ့ပိုးပေးသည့် အရင်းအမြစ်သတ်မှတ်ချက်၏ အစိတ်အပိုင်းကို ပြောင်းလဲနိုင်စေပါသည်။ အသင်းအဖွဲ့ replace အတူတူအလုပ်လုပ်ပါတယ်။ editသို့သော် အရာအားလုံးကို ကိုယ်တိုင်လုပ်ဆောင်ရန် လိုအပ်သည်- ဥပမာအားဖြင့်၊ အရင်းအမြစ်သတ်မှတ်ချက်၏ လက်ရှိဗားရှင်းကို သင်ဒေါင်းလုဒ်လုပ်ရန် လိုအပ်သည်၊ kubectl get -o yamlတည်းဖြတ်ပါ၊ ထို့နောက် အသုံးပြုပါ။ replace ပြောင်းလဲထားသော သတ်မှတ်ချက်များအရ အရင်းအမြစ်တစ်ခုကို အပ်ဒိတ်လုပ်ရန်။ အသင်းအဖွဲ့ replace ဖတ်ရှုခြင်းနှင့် အရင်းအမြစ်ကို အစားထိုးခြင်းကြားတွင် အပြောင်းအလဲတစ်စုံတစ်ရာ ဖြစ်ပေါ်ပါက အလုပ်မဖြစ်ပါ။

Kubernetes API

နည်းလမ်းတွေကို သင် ရင်းနှီးပြီးသား ဖြစ်နိုင်ပါတယ်။ CoreV1().Pods().Update(), replaceNamespacedService သို့မဟုတ် patch_namespaced_deploymentဆင့်ပြွတ်နှင့်အလုပ်လုပ်လျှင် Kubernetes API အတွက် client library ပရိုဂရမ်းမင်းဘာသာစကားအချို့ကို အသုံးပြု. စာကြည့်တိုက်သည် နည်းလမ်းများကို အသုံးပြု၍ HTTP တောင်းဆိုမှုများမှတစ်ဆင့် ဤနည်းလမ်းများကို ကိုင်တွယ်သည်။ PUT и PATCH... ဘယ်မှာလဲ update и replace အသုံးပြုသည် PUTနှင့် patchဘယ်လောက်ပဲအသေးအဖွဲဖြစ်ပါစေ၊ သုံးပါတယ်။ PATCH.

ထိုသို့သတိပြုရကျိုးနပ်သည် kubectl API မှတစ်ဆင့် အစုအဖွဲ့များနှင့်လည်း လုပ်ဆောင်သည်။ တစ်နည်းပြောရရင်တော့, kubectlစံ API စွမ်းရည်များအပြင် စံ API စွမ်းရည်များအပြင် ပိုမိုကျစ်လစ်ပြီး ဖတ်ရလွယ်ကူသောပုံစံဖြင့် ညွှန်ကြားချက်များပေးဆောင်နိုင်စေမည့် Go language အတွက် ကလိုင်းယင့်ဒစ်ဂျစ်တိုက်၏ထိပ်တွင် ထုပ်ပိုးထားသည်။ ဥပမာအားဖြင့်၊ သင်သတိပြုမိပြီးသားဖြစ်နိုင်သကဲ့သို့၊ နည်းလမ်း apply ယခင်စာပိုဒ်တွင် အထက်ဖော်ပြပါ မရှိခဲ့ပါ။ လောလောဆယ် (မေလ 2020 ခုနှစ်၊ အနီးစပ်ဆုံး ဘာသာပြန်သူ) ယုတ္တိဗေဒအားလုံး kubectl apply, i.e. မရှိသောအရင်းအမြစ်များကို ဖန်တီးခြင်းနှင့် ရှိပြီးသားအရာများကို အပ်ဒိတ်လုပ်ခြင်း၊ ကုဒ်ဘက်တွင် လုံးဝအလုပ်လုပ်သည်။ kubectl. ကြိုးပမ်းဆောင်ရွက်လျက်ရှိသည်။ လော့ဂျစ်လွှဲပြောင်းမှုအပေါ် apply API ဘက်သို့၊ သို့သော်၎င်းသည် beta တွင်ရှိနေဆဲဖြစ်သည်။ အောက်မှာ အသေးစိတ်ရေးပေးပါမယ်။

မူရင်းအတိုင်း Patch လုပ်ပါ။

အကောင်းဆုံးသုံးတယ်။ patchအရင်းအမြစ်ကို မွမ်းမံလိုပါက၊ ဤသည်မှာ Kubernetes API ၏ထိပ်တွင် ကလိုင်းယင့်စာကြည့်တိုက်နှစ်ခုလုံး အလုပ်လုပ်ပုံဖြစ်သည်။ kubectl (အံ့သြစရာမဟုတ်ပါ၊ ၎င်းသည် client library အတွက် wrapper တစ်ခုဖြစ်သောကြောင့်၊ အနီးစပ်ဆုံး ဘာသာပြန်သူ).

ဗျူဟာကျကျ လုပ်ဆောင်ပါ။

အသင်းအားလုံး kubectl apply, edit и patch နည်းလမ်းကို အသုံးပြု PATCH HTTP တောင်းဆိုချက်များတွင် ရှိပြီးသားရင်းမြစ်တစ်ခုကို အပ်ဒိတ်လုပ်ပါ။ သင်ပိုမိုအသေးစိတ်သော command များကိုအကောင်အထည်ဖော်ခြင်းတွင်အသေးစိတ်လေ့လာပါက၊ ၎င်းတို့အားလုံးသည်ချဉ်းကပ်မှုကိုအသုံးပြုပါ။ ဗျူဟာ-ပေါင်းစည်းမှု ဖာထေးမှု အရင်းအမြစ်များကို မွမ်းမံရန် အမိန့်ပေးသော်လည်း၊ patch အခြားနည်းလမ်းများကို အသုံးပြုနိုင်ပါသည်။ မဟာဗျူဟာမြောက် ပေါင်းစည်းရေး ချဉ်းကပ်မှု ချဉ်းကပ်မှုသည် ပံ့ပိုးပေးထားသော သတ်မှတ်ချက်ကို ရှိပြီးသား သတ်မှတ်ချက်များနှင့် ပေါင်းစည်းခြင်းဖြင့် "မှန်ကန်စေရန်" ကြိုးပမ်းသည်။ ပို၍တိကျသည်မှာ၊ ၎င်းသည် အရာဝတ္ထုများနှင့် array နှစ်ခုလုံးကို ပေါင်းစပ်ရန် ကြိုးစားသည်၊ ဆိုလိုသည်မှာ ပြောင်းလဲမှုများသည် ပေါင်းထည့်ရန် ဖြစ်နိုင်သည်။ ဥပမာအားဖြင့်၊ command ကို run ပါ။ patch pod container specification တွင်ရှိသော ပတ်ဝန်းကျင် variable အသစ်တစ်ခုဖြင့်၊ ၎င်းတို့ကို overwrite လုပ်မည့်အစား ရှိပြီးသား environment variable များထဲသို့ ပတ်ဝန်းကျင် variable ကို ပေါင်းထည့်သွားစေသည်။ ဤချဉ်းကပ်နည်းကို အသုံးပြု၍ ဖယ်ရှားရန်၊ ပေးထားသော သတ်မှတ်ချက်တွင် ပါရာမီတာတန်ဖိုးအား null အဖြစ် အတင်းအကျပ် ခိုင်းစေရမည်။ ဘယ်အသင်းတွေလဲ။ kubectl အပ်ဒိတ်လုပ်ရာတွင် အသုံးပြုရန် အကောင်းဆုံးဖြစ်ပါသလား။

သင့်အရင်းအမြစ်များကို ဖန်တီးပြီး စီမံခန့်ခွဲပါက၊ kubectl applyအပ်ဒိတ်လုပ်တဲ့အခါ အမြဲတမ်းသုံးတာက ပိုကောင်းပါတယ်။ kubectl applyသို့ kubectl ဖွဲ့စည်းမှုပုံစံကို စီမံခန့်ခွဲနိုင်ပြီး တောင်းဆိုထားသော အပြောင်းအလဲများကို အပလီကေးရှင်းမှ အက်ပ်တစ်ခုသို့ မှန်ကန်စွာ ခြေရာခံနိုင်သည်။ အားသာချက် အမြဲသုံးပါ။ apply သတ်မှတ်ချက်ဂုဏ်သတ္တိများနှင့် array ဒြပ်စင်များကို ရှင်းရှင်းလင်းလင်း ဖယ်ရှားလိုက်သည့်အခါတွင် ၎င်းသည် ယခင်က အသုံးပြုထားသော သတ်မှတ်ချက်တစ်ခုအား ခြေရာခံထားခြင်းဖြစ်သည်။ ဒါကို သုံးနိုင်ရမယ်။ apply ပုံမှန်ဗျူဟာမြောက် ပေါင်းစည်းခြင်း အလုပ်မဖြစ်သော်လည်း ဂုဏ်သတ္တိများနှင့် array အစိတ်အပိုင်းများကို ဖယ်ရှားရန်။ သင်း edit и patch အဲဒါကို မှတ်စုမွမ်းမံပါ။ kubectl apply ၎င်း၏ပြောင်းလဲမှုများကို ခြေရာခံရန်အသုံးပြုသည်၊ ထို့ကြောင့် Kubernetes API မှတဆင့် ခြေရာခံပြီး ပြုလုပ်ထားသည့် မည်သည့်ပြောင်းလဲမှုမဆို၊ ညွှန်ကြားချက်များမှတစ်ဆင့် ပြုလုပ်သည် edit и patchနောက်ဆက်တွဲ အမိန့်များကို မမြင်နိုင်ပါ။ apply, ဒါကဖြစ်ပါသည် apply input specification တွင်မပေါ်ပါက ၎င်းတို့ကို ဖယ်ရှားမည်မဟုတ်ပါ။ apply (စာတမ်းက ဒီလိုဆိုတယ်။ edit и patch အသုံးပြုထားသော မှတ်စုများကို အပ်ဒိတ်လုပ်ပါ။ applyဒါပေမယ့် လက်တွေ့မှာတော့ မဟုတ်ဘူး)။

အမိန့်ကို မသုံးရင် apply, အဖြစ်သုံးနိုင်သည်။ editနှင့် patchအပြောင်းအလဲပြုလုပ်ရာတွင် အသင့်လျော်ဆုံး command ကိုရွေးချယ်ပါ။ BOM ဂုဏ်သတ္တိများကိုပေါင်းထည့်ခြင်းနှင့်ပြောင်းလဲသောအခါ၊ ချဉ်းကပ်မှုနှစ်ခုလုံးသည်အကြမ်းဖျင်းတူညီသည်။ သတ်မှတ်ချက်ဂုဏ်သတ္တိများ သို့မဟုတ် array အစိတ်အပိုင်းများကို ဖျက်သည့်အခါ edit တစ်ကြိမ်တည်း ပစ်လွှတ်ခြင်းကဲ့သို့ ပြုမူသည်။ applyတည်းဖြတ်ခြင်းမပြုမီနှင့် မည်သို့မည်ပုံ သတ်မှတ်ချက်ကို ခြေရာခံခြင်း အပါအဝင်၊ ထို့ကြောင့် သင်သည် အရင်းအမြစ်တစ်ခုမှ ဂုဏ်သတ္တိများနှင့် ခင်းကျင်းထားသော အစိတ်အပိုင်းများကို ရှင်းရှင်းလင်းလင်း ဖယ်ရှားနိုင်သည်။ သတ်မှတ်ချက်များအတွက် ပိုင်ဆိုင်မှုတန်ဖိုးကို null အဖြစ် ပြတ်သားစွာ သတ်မှတ်ရန် လိုအပ်သည်။ patchအရင်းအမြစ်မှဖယ်ရှားရန်။ ပေါင်းစပ်လမ်းညွှန်ချက်များကို အသုံးပြုရန်လိုအပ်သောကြောင့် ဗျူဟာမြောက်ပေါင်းစပ်ပြင်ဆင်မှုကို အသုံးပြုသည့် array element တစ်ခုကို ဖယ်ရှားခြင်းသည် ပိုမိုရှုပ်ထွေးပါသည်။ ပိုမိုရရှိနိုင်သော အခြားရွေးချယ်စရာများအတွက် အောက်တွင် အခြားသော အဆင့်မြှင့်နည်းလမ်းများကို ကြည့်ပါ။

အထက်ဖော်ပြပါ ညွှန်ကြားချက်များနှင့် အလားတူပြုမူသော ကလိုင်းယင့်စာကြည့်တိုက်ရှိ အပ်ဒိတ်နည်းလမ်းများကို အကောင်အထည်ဖော်ရန် kubectlတောင်းဆိုချက်များ၌ သတ်မှတ်သင့်သည်။ content-type в application/strategic-merge-patch+json. သတ်မှတ်ချက်တစ်ခုရှိ ဂုဏ်သတ္တိများကို ဖယ်ရှားလိုပါက၊ အလားတူနည်းဖြင့် ၎င်းတို့၏ တန်ဖိုးများကို null အဖြစ် ပြတ်သားစွာ သတ်မှတ်ရန် လိုအပ်ပါသည်။ kubectl patch. array အစိတ်အပိုင်းများကို ဖယ်ရှားရန် လိုအပ်ပါက၊ သင်သည် အပ်ဒိတ်သတ်မှတ်ချက်တွင် ပေါင်းစည်းရန် ညွှန်ကြားချက်များ ထည့်သွင်းသင့်သည် သို့မဟုတ် အပ်ဒိတ်များအတွက် ကွဲပြားခြားနားသော ချဉ်းကပ်မှုကို အသုံးပြုပါ။

အပ်ဒိတ်များအတွက် အခြားနည်းလမ်းများ

Kubernetes သည် အခြားသော အပ်ဒိတ်နည်းလမ်းနှစ်ခုကို ပံ့ပိုးသည်- JSON ပေါင်းစပ်ပြင်ဆင်မှု и JSON patch. JSON ပေါင်းစည်းမှု ဖာထေးမှု ချဉ်းကပ်မှုတွင် ထည့်သွင်းမှုအဖြစ် Kubernetes သတ်မှတ်ချက် တစ်စိတ်တစ်ပိုင်းကို ရယူပြီး မဟာဗျူဟာမြောက် ပေါင်းစည်းမှု ဖာထေးခြင်းချဉ်းကပ်မှုကဲ့သို့ အရာဝတ္ထုများကို ပေါင်းစည်းခြင်းကို ပံ့ပိုးပေးပါသည်။ ၎င်းတို့နှစ်ခုကြား ခြားနားချက်မှာ pod specification ရှိ container array အပါအဝင် array အစားထိုးခြင်းကိုသာ ပံ့ပိုးပေးနိုင်ခြင်း ဖြစ်သည်။ ဆိုလိုသည်မှာ JSON ပေါင်းစည်းမှု patch ကိုအသုံးပြုသည့်အခါ၊ ကွန်တိန်နာအားလုံး၏ ပိုင်ဆိုင်မှုပြောင်းလဲမှုရှိပါက ကွန်တိန်နာအားလုံးအတွက် သတ်မှတ်ချက်အပြည့်အစုံကို ပေးဆောင်ရန် လိုအပ်ပါသည်။ ထို့ကြောင့် ဤနည်းလမ်းသည် BOM ရှိ array တစ်ခုမှ အစိတ်အပိုင်းများကို ဖယ်ရှားရန်အတွက် အသုံးဝင်ပါသည်။ command line တွင် JSON merge patch ကို အသုံးပြု၍ သင်ရွေးချယ်နိုင်သည်။ kubectl patch --type=merge. Kubernetes API နှင့် အလုပ်လုပ်သောအခါ၊ သင်သည် တောင်းဆိုမှုနည်းလမ်းကို အသုံးပြုသင့်သည်။ PATCH နှင့်တပ်ဆင်ခြင်း။ content-type в application/merge-patch+json.

အရင်းအမြစ်တစ်ခု၏ တစ်စိတ်တစ်ပိုင်းသတ်မှတ်ချက်ကို ပေးဆောင်မည့်အစား JSON ဖာထေးမှုချဉ်းကပ်မှုသည် အရင်းအမြစ်အတွက် သင်ပြုလုပ်လိုသော အပြောင်းအလဲများကို အခင်းအကျင်းတစ်ခုအဖြစ် ပေးဆောင်ရာတွင် အသုံးပြုသည်၊ ၎င်းတွင် ခင်းကျင်းမှု၏ဒြပ်စင်တစ်ခုစီသည် ရင်းမြစ်အတွက် ပြုလုပ်ထားသည့်ပြောင်းလဲမှု၏ဖော်ပြချက်အား ကိုယ်စားပြုသည့် JSON patch ချဉ်းကပ်မှုဖြစ်သည်။ ဤချဉ်းကပ်မှုသည် ပြောင်းလဲမှုများကို ဖော်ပြရန် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိပြီး အစွမ်းထက်သောနည်းလမ်းတစ်ခုဖြစ်သော်လည်း၊ တစ်စိတ်တစ်ပိုင်း အရင်းအမြစ်သတ်မှတ်ချက်ကို ပေးပို့ခြင်းထက် သီးခြား၊ Kubernetes မဟုတ်သော ဖော်မတ်ဖြင့် ပြုလုပ်ထားသည့် အပြောင်းအလဲများကို စာရင်းပြုစုခြင်းဖြင့် ကုန်ကျစရိတ်ဖြင့် ဆောင်ရွက်ပါသည်။ IN kubectl JSON patch ကို အသုံးပြု၍ သင်ရွေးချယ်နိုင်သည်။ kubectl patch --type=json. Kubernetes API ကိုအသုံးပြုသောအခါ၊ ဤချဉ်းကပ်မှုသည် တောင်းဆိုမှုနည်းလမ်းကို အသုံးပြု၍ လုပ်ဆောင်သည်။ PATCH နှင့်တပ်ဆင်ခြင်း။ content-type в application/json-patch+json.

ယုံကြည်စိတ်ချစွာ အစားထိုးအသုံးပြုရန် လိုအပ်ပါသည်။

အချို့သောကိစ္စများတွင်၊ အရင်းအမြစ်ကိုဖတ်ရှုသည့်အချိန်နှင့် အပ်ဒိတ်လုပ်သည့်အချိန်ကြားတွင် အရင်းအမြစ်တစ်ခုသို့ အပြောင်းအလဲများပြုလုပ်ထားခြင်းမရှိကြောင်း သေချာစေရန်လိုအပ်ပါသည်။ တစ်နည်းဆိုရသော် အပြောင်းအလဲများအားလုံး ဖြစ်တည်လာရန် သေချာစေသင့်သည်။ အနုမြူဗုံး. ဤကိစ္စတွင်၊ အရင်းအမြစ်များကိုမွမ်းမံရန်သင်အသုံးပြုသင့်သည်။ replace. ဥပမာအားဖြင့်၊ သင့်တွင် ရင်းမြစ်များစွာဖြင့် အပ်ဒိတ်လုပ်ထားသော ကောင်တာတစ်ခုပါရှိသော ConfigMap တစ်ခုရှိပါက၊ ရင်းမြစ်နှစ်ခုသည် ကောင်တာကို တစ်ချိန်တည်းတွင် မွမ်းမံခြင်းမရှိသည့်အတွက် အပ်ဒိတ်ကို ဆုံးရှုံးသွားစေရန် သေချာစေသင့်သည်။ သရုပ်ပြရန်၊ ချဉ်းကပ်မှုကို အသုံးပြု၍ အဖြစ်အပျက်များ၏ အပိုင်းကို စိတ်ကူးကြည့်ပါ။ patch:

• A နှင့် B သည် API မှ အရင်းအမြစ်၏ လက်ရှိအခြေအနေကို ရယူသည်။
• တစ်ခုချင်းစီက ကောင်တာတစ်ခုစီကို တိုးပြီး "မွမ်းမံထားသော" မှတ်စုသို့ "A" သို့မဟုတ် "B" အသီးသီးထည့်ခြင်းဖြင့် စက်တွင်းရှိ သတ်မှတ်ချက်ကို အပ်ဒိတ်လုပ်သည်
• ၎င်းသည် အရင်းအမြစ်ကို အနည်းငယ် ပိုမြန်အောင် update လုပ်သည်။
• B သည် အရင်းအမြစ်ကို အပ်ဒိတ်လုပ်သည်။

ရလဒ်အနေနဲ့ update A ပျောက်သွားပါတယ်။ နောက်ဆုံးလည်ပတ်မှု patch အနိုင်ရသည်၊ ကောင်တာသည် နှစ်ခုအစား တစ်ခုဖြင့် တိုးလာပြီး "updated-by" မှတ်စု၏တန်ဖိုးသည် "B" ဖြင့်အဆုံးသတ်ကာ "A" မပါဝင်ပါ။ ချဉ်းကပ်မှုကို အသုံးပြု၍ အပ်ဒိတ်များ ပြီးသောအခါတွင် မည်သို့ဖြစ်မည်ကို အထက်ဖော်ပြပါနှင့် နှိုင်းယှဉ်ကြည့်ကြပါစို့ replace:

• A နှင့် B သည် API မှ အရင်းအမြစ်၏ လက်ရှိအခြေအနေကို ရယူသည်။
• တစ်ခုချင်းစီက ကောင်တာတစ်ခုစီကို တိုးပြီး "မွမ်းမံထားသော" မှတ်စုသို့ "A" သို့မဟုတ် "B" အသီးသီးထည့်ခြင်းဖြင့် စက်တွင်းရှိ သတ်မှတ်ချက်ကို အပ်ဒိတ်လုပ်သည်
• ၎င်းသည် အရင်းအမြစ်ကို အနည်းငယ် ပိုမြန်အောင် update လုပ်သည်။
• B သည် အရင်းအမြစ်ကို အပ်ဒိတ်လုပ်ရန် ကြိုးစားသော်လည်း အရင်းအမြစ်ဗားရှင်းသည် သတ်မှတ်ချက်တွင် ရှိနေသောကြောင့် အပ်ဒိတ်ကို API မှ ပယ်ချခဲ့သည်။ replace အရင်းအမြစ်၏ဗားရှင်းကို A ၏အစားထိုးလုပ်ဆောင်ချက်ဖြင့် တိုးမြှင့်ထားသောကြောင့် Kubernetes ရှိ အရင်းအမြစ်၏ လက်ရှိဗားရှင်းနှင့် မကိုက်ညီပါ။

အထက်ပါအခြေအနေမျိုးတွင် B သည် အရင်းအမြစ်ကို ပြန်လည်ရယူရန်၊ ပြည်နယ်အသစ်သို့ ပြောင်းလဲမှုများ ပြုလုပ်ပြီး ထပ်မံကြိုးစားရမည်ဖြစ်သည်။ replace. ၎င်းသည် ကောင်တာအား နှစ်ခုဖြင့် တိုးစေမည်ဖြစ်ပြီး အဆုံးတွင် "မွမ်းမံပြင်ဆင်ထားသော" မှတ်စုတွင် "AB" ပါဝင်မည်ဖြစ်သည်။

အထက်ဖော်ပြပါ ဥပမာက အကောင်အထည်ဖော်တဲ့အခါမှာ ဆိုလိုတာပါ။ replace သယံဇာတ တစ်ခုလုံးကို လုံးဝ အစားထိုးသွားပြီ။ Specification တွေအတွက် သုံးပါတယ်။ replace၊ တစ်စိတ်တစ်ပိုင်းဖြစ်ရမည်၊ သို့မဟုတ် အပိုင်းများကဲ့သို့ မဖြစ်ရပါ။ apply၊ ဒါပေမယ့် ဖြည့်စွက်မှု အပါအဝင် ပြီးပြည့်စုံပါတယ်။ resourceVersion သတ်မှတ်ချက် metadata ထဲသို့။ မဖွင့်ရသေးရင် resourceVersion သို့မဟုတ် သင်ပေးသောဗားရှင်းသည် လက်ရှိမဟုတ်ပါ၊ အစားထိုးမှုကို ပယ်ချပါမည်။ ဒါကြောင့် အကောင်းဆုံးနည်းလမ်းကို အသုံးပြုပါ။ replace - အရင်းအမြစ်ကိုဖတ်ပါ၊ အပ်ဒိတ်လုပ်ပြီးချက်ချင်းအစားထိုးပါ။ အသုံးပြုခြင်း။ kubectl၊ ၎င်းသည် ဤကဲ့သို့သောပုံပေါ်နိုင်သည်-

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

အောက်ဖော်ပြပါ command နှစ်ခုကို ဆက်တိုက်လုပ်ဆောင်ပြီး အောင်မြင်စွာ လုပ်ဆောင်မည်ဖြစ်သောကြောင့်၊ deployment.yaml ပစ္စည်းမပါဝင်ပါ။ .metadata.resourceVersion

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

ဤသည်မှာ အထက်တွင်ပြောခဲ့သည့်အတိုင်း ဆန့်ကျင်နေပုံရပေသည်၊ ဆိုလိုသည်မှာ၊ "ထပ်လောင်း resourceVersion သတ်မှတ်ချက် မက်တာဒေတာထဲသို့။" ထိုသို့ပြောခြင်းသည် မှားသလား၊ မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် အကယ်၍ မဟုတ်ပါ။ kubectl သင်မသတ်မှတ်ထားသော သတိပေးချက်များ resourceVersion၊ အရင်းအမြစ်မှ ၎င်းကိုဖတ်ပြီး သင်သတ်မှတ်ထားသော သတ်မှတ်ချက်သို့ ပေါင်းထည့်ကာ ၎င်းကို လုပ်ဆောင်မှသာ လုပ်ဆောင်မည်ဖြစ်သည်။ replace. အဏုမြူဓာတ်ကို မှီခိုအားထားလျှင် ၎င်းသည် အန္တရာယ်ရှိနိုင်သောကြောင့် မှော်ပညာသည် ဘေးဘက်တွင် လုံးဝအလုပ်လုပ်သည်။ kubectlAPI နှင့်အလုပ်လုပ်သော client libraries ကိုအသုံးပြုသောအခါ၎င်းကိုသင်မှီခိုမနေသင့်ပါ။ ဤကိစ္စတွင် သင်သည် လက်ရှိ ရင်းမြစ်သတ်မှတ်ချက်ကို ဖတ်ရန်၊ ၎င်းကို အပ်ဒိတ်လုပ်ပြီး လုပ်ဆောင်ရန် လိုအပ်သည်။ PUT တောင်းဆိုချက်ကို။

ဖာထေးမှု မလုပ်နိုင်ဘူး - အစားထိုးလုပ်တယ်။

တစ်ခါတစ်ရံတွင် သင်သည် API မှ မကိုင်တွယ်နိုင်သော အပြောင်းအလဲအချို့ ပြုလုပ်ရန် လိုအပ်သည်။ ဤကိစ္စများတွင်၊ သင်သည် ၎င်းအား ဖျက်ပစ်ပြီး ပြန်လည်ဖန်တီးခြင်းဖြင့် အရင်းအမြစ်ကို အစားထိုးရန် အတင်းအကြပ် လုပ်ဆောင်နိုင်သည်။ ဒါကိုသုံးပြီး ပြီးသွားတယ်။ kubectl replace --force. ညွှန်ကြားချက်ကို လုပ်ဆောင်ခြင်းသည် အရင်းအမြစ်များကို ချက်ချင်းဖယ်ရှားပြီး ၎င်းတို့ကို ပံ့ပိုးပေးထားသော သတ်မှတ်ချက်များမှ ပြန်လည်ဖန်တီးသည်။ API တွင် "force replace" handler မရှိပါ။ API မှတဆင့် ၎င်းကိုလုပ်ဆောင်ရန်အတွက် လုပ်ဆောင်ချက်နှစ်ခုလုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ပထမဦးစွာ သင်သည် ၎င်းအတွက် သတ်မှတ်ပေးခြင်းဖြင့် အရင်းအမြစ်ကို ဖျက်ပစ်ရန် လိုအပ်သည်။ gracePeriodSeconds သုည (0) နှင့် propagationPolicy "နောက်ခံ" တွင် ပြီးနောက် ဤအရင်းအမြစ်ကို လိုချင်သောသတ်မှတ်ချက်များဖြင့် ပြန်လည်ဖန်တီးပါ။

သတိပေးချက်- ဤချဉ်းကပ်မှုသည် အန္တရာယ်ရှိနိုင်ပြီး သတ်မှတ်မထားသော အခြေအနေသို့ ဦးတည်သွားနိုင်သည်။

ဆာဗာဘက်တွင် လျှောက်ထားပါ။

အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း Kubernetes developer များသည် logic ကိုအကောင်အထည်ဖော်ရန် လုပ်ဆောင်နေပါသည်။ 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 ဆာဗာဘက်တွင် ပိုမိုကျယ်ပြန့်လာမည်ဖြစ်ပြီး၊ မတူညီသော clients များအတွက် universal secure resource management interface ပေါ်လာပါမည်။

ရလဒ်များကို

အစုအဖွဲ့များရှိ အရင်းအမြစ်များကို အပ်ဒိတ်လုပ်ရန် မတူညီသောနည်းလမ်းများ၏ အတိုချုံးသုံးသပ်ချက်သည် သင့်အတွက် အထောက်အကူဖြစ်မည်ဟု မျှော်လင့်ပါသည်။ ၎င်းသည် အစားထိုးခြင်းကို အသုံးချရုံသာမက၊ အသုံးချမှု၊ တည်းဖြတ်မှု၊ ဖာထေးမှု သို့မဟုတ် အစားထိုးမှုတို့ကို အသုံးပြု၍ ရင်းမြစ်တစ်ခုကို အပ်ဒိတ်လုပ်ရန် ဖြစ်နိုင်ကြောင်း သိရှိရခြင်းမှာ ကောင်းပါတယ်။ ပြီးနောက်ရှိသမျှတို့, မူအရ, တစ်ခုချင်းစီကိုချဉ်းကပ်မှု၎င်း၏ကိုယ်ပိုင်အသုံးချဧရိယာရှိသည်။ အက်တမ်ပြောင်းလဲမှုများအတွက်၊ အစားထိုးခြင်းသည် ပိုကောင်းသည်၊ သို့မဟုတ်ပါက သင်သည် အသုံးချမှုမှတစ်ဆင့် ဗျူဟာမြောက်-ပေါင်းစည်းမှု patch ကို အသုံးပြုသင့်သည်။ အနည်းဆုံးတော့ "kubernetes Apply vs replace" ကိုရှာတဲ့အခါ Google သို့မဟုတ် StackOerflow ကို မယုံနိုင်ဘူးလို့ မင်းနားလည်ဖို့ ငါမျှော်လင့်ပါတယ်။ အနည်းဆုံး ဤဆောင်းပါးသည် လက်ရှိအဖြေကို အစားထိုးသည့်အချိန်အထိဖြစ်သည်။

source: www.habr.com