Kubernetes వనరులను నవీకరించడానికి అనేక ఎంపికలు ఉన్నాయి: వర్తింపజేయడం, సవరించడం, ప్యాచ్ చేయడం మరియు భర్తీ చేయడం. ప్రతి ఒక్కరు ఏమి చేస్తారు మరియు వాటిని ఎప్పుడు ఉపయోగించాలి అనే విషయంలో గందరగోళం ఉంది. దాన్ని గుర్తించండి.
ఉంటే "kubernetes apply vs replace" అనే పదబంధం ఉంది , ఇది సరైనది కాదు. "kubernetes apply vs ప్యాచ్" మొదటి లింక్ డాక్యుమెంటేషన్ kubectl patch, ఇది పోలికను కలిగి ఉండదు apply и patch. ఈ కథనం విభిన్న ఎంపికలను అలాగే ప్రతి ఒక్కటి సరైన ఉపయోగాన్ని పరిశీలిస్తుంది.
కుబెర్నెట్స్ రిసోర్స్ (సర్వీస్, డిప్లాయ్‌మెంట్, ఇన్‌గ్రెస్ మొదలైనవి) జీవితచక్రం సమయంలో, కొన్నిసార్లు మీరు ఈ వనరు యొక్క కొన్ని లక్షణాలను మార్చాలి, జోడించాలి లేదా తీసివేయాలి. ఉదాహరణకు, గమనికను జోడించండి, ప్రతిరూపాల సంఖ్యను పెంచండి లేదా తగ్గించండి.
కుబెర్నెటెస్ CLI
మీరు ఇప్పటికే CLI ద్వారా కుబెర్నెటెస్ క్లస్టర్‌లతో పని చేస్తుంటే, మీకు ఇప్పటికే తెలిసినవి apply и edit. జట్టు apply ఫైల్ నుండి రిసోర్స్ స్పెసిఫికేషన్‌ను చదివి, కుబెర్నెట్స్ క్లస్టర్‌కి "అప్‌సర్ట్" చేస్తుంది, అనగా. వనరు ఉనికిలో లేకుంటే దానిని సృష్టిస్తుంది మరియు అది ఉన్నట్లయితే దానిని నవీకరిస్తుంది. జట్టు edit API ద్వారా రిసోర్స్‌ని రీడ్ చేసి, ఆ తర్వాత రిసోర్స్ స్పెసిఫికేషన్‌ను స్థానిక ఫైల్‌కి వ్రాస్తుంది, అది టెక్స్ట్ ఎడిటర్‌లో తెరవబడుతుంది. మీరు ఫైల్‌ను సవరించి, సేవ్ చేసిన తర్వాత, kubectl API ద్వారా చేసిన మార్పులను తిరిగి పంపుతుంది, ఇది వనరులకు ఈ మార్పులను జాగ్రత్తగా వర్తింపజేస్తుంది.
అందరికీ ఆదేశాలు తెలియవు patch и replace. జట్టు patch రిసోర్స్ స్పెసిఫికేషన్ యొక్క భాగాన్ని మార్చడానికి మిమ్మల్ని అనుమతిస్తుంది, కమాండ్ లైన్‌లో మార్చబడిన భాగాన్ని మాత్రమే అందిస్తుంది. జట్టు replace అదే పని చేస్తుంది edit, కానీ ప్రతిదీ మాన్యువల్‌గా చేయాలి: మీరు రిసోర్స్ స్పెసిఫికేషన్ యొక్క ప్రస్తుత సంస్కరణను డౌన్‌లోడ్ చేసుకోవాలి, ఉదాహరణకు, ఉపయోగించి kubectl get -o yaml, దాన్ని సవరించండి, ఆపై ఉపయోగించండి replace మార్చబడిన స్పెసిఫికేషన్ ప్రకారం వనరును నవీకరించడానికి. జట్టు replace రిసోర్స్‌ని చదవడం మరియు భర్తీ చేయడం మధ్య ఏవైనా మార్పులు సంభవించినట్లయితే పని చేయదు.
కుబెర్నెటెస్ API
మీరు బహుశా పద్ధతుల గురించి తెలిసి ఉండవచ్చు CoreV1().Pods().Update(), replaceNamespacedService లేదా patch_namespaced_deployment, మీరు క్లస్టర్‌లతో పని చేస్తే కొన్ని ప్రోగ్రామింగ్ భాషను ఉపయోగించడం. లైబ్రరీ ఈ పద్ధతులను పద్ధతులను ఉపయోగించి HTTP అభ్యర్థనల ద్వారా నిర్వహిస్తుంది PUT и PATCH... ఇందులో update и replace వా డు PUTమరియు patch, అది ఎంత అల్పమైనదైనా, ఉపయోగిస్తుంది PATCH.
ఇది గమనించదగ్గ విలువ kubectl API ద్వారా క్లస్టర్‌లతో కూడా పని చేస్తుంది. వేరే పదాల్లో, kubectlఅనేది గో భాష కోసం క్లయింట్ లైబ్రరీ పైన ఒక రేపర్, ఇది ప్రామాణిక 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 దాని మార్పులను ట్రాక్ చేయడానికి ఉపయోగిస్తుంది, కాబట్టి కుబెర్నెట్స్ 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 విలీన ప్యాచ్ విధానం పాక్షిక కుబెర్నెట్స్ స్పెసిఫికేషన్‌ను ఇన్‌పుట్‌గా తీసుకుంటుంది మరియు వ్యూహాత్మక-విలీనం ప్యాచింగ్ విధానాన్ని పోలిన వస్తువులను విలీనం చేయడానికి మద్దతు ఇస్తుంది. రెండింటి మధ్య వ్యత్యాసం ఏమిటంటే ఇది పాడ్ స్పెసిఫికేషన్‌లోని కంటైనర్ శ్రేణితో సహా అర్రే రీప్లేస్‌మెంట్‌కు మాత్రమే మద్దతు ఇస్తుంది. దీనర్థం 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. ఉదాహరణకు, మీరు బహుళ మూలాధారాల ద్వారా అప్‌డేట్ చేయబడిన కౌంటర్‌తో కాన్ఫిగ్‌మ్యాప్‌ని కలిగి ఉన్నట్లయితే, రెండు మూలాధారాలు ఒకేసారి కౌంటర్‌ను అప్‌డేట్ చేయలేదని, దీని వలన అప్‌డేట్ కోల్పోయేలా చూసుకోవాలి. ప్రదర్శించడానికి, విధానాన్ని ఉపయోగించి సంఘటనల క్రమాన్ని ఊహించండి patch:
- A మరియు B API నుండి వనరు యొక్క ప్రస్తుత స్థితిని పొందుతాయి
- ప్రతి ఒక్కటి కౌంటర్‌ను ఒక్కొక్కటిగా పెంచడం ద్వారా స్థానికంగా స్పెసిఫికేషన్‌ను నవీకరిస్తుంది మరియు "అప్‌డేట్-బై" నోట్‌కి వరుసగా "A" లేదా "B"ని జోడించడం ద్వారా
- మరియు ఇది వనరును కొంచెం వేగంగా నవీకరిస్తుంది
- B వనరును నవీకరిస్తుంది
ఫలితంగా, నవీకరణ A పోతుంది. చివరి ఆపరేషన్ patch విజయాలు, కౌంటర్ రెండింటికి బదులుగా ఒకటితో పెంచబడుతుంది మరియు "అప్‌డేట్-బై" నోట్ విలువ "B"తో ముగుస్తుంది మరియు "A"ని కలిగి ఉండదు. అప్‌డేట్‌లు విధానాన్ని ఉపయోగించి పూర్తయినప్పుడు ఏమి జరుగుతుందో దానితో ఎగువన సరిపోల్చండి replace:
- A మరియు B API నుండి వనరు యొక్క ప్రస్తుత స్థితిని పొందుతాయి
- ప్రతి ఒక్కటి కౌంటర్‌ను ఒక్కొక్కటిగా పెంచడం ద్వారా స్థానికంగా స్పెసిఫికేషన్‌ను నవీకరిస్తుంది మరియు "అప్‌డేట్-బై" నోట్‌కి వరుసగా "A" లేదా "B"ని జోడించడం ద్వారా
- మరియు ఇది వనరును కొంచెం వేగంగా నవీకరిస్తుంది
- B రిసోర్స్‌ను అప్‌డేట్ చేయడానికి ప్రయత్నిస్తుంది, కానీ రిసోర్స్ వెర్షన్ స్పెసిఫికేషన్‌లో ఉన్నందున అప్‌డేట్ API ద్వారా తిరస్కరించబడింది
replaceకుబెర్నెటెస్‌లోని వనరు యొక్క ప్రస్తుత సంస్కరణతో సరిపోలడం లేదు ఎందుకంటే 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 సర్వర్ వైపు మరింత విస్తృతంగా మారుతుంది, వివిధ క్లయింట్‌ల కోసం యూనివర్సల్ సురక్షిత వనరుల నిర్వహణ ఇంటర్‌ఫేస్ కనిపిస్తుంది, ఉదాహరణకు, kubectl, Pulumi లేదా Terraform, GitOps, అలాగే క్లయింట్ లైబ్రరీలను ఉపయోగించి స్వీయ-వ్రాత స్క్రిప్ట్‌లు.
ఫలితాలు
క్లస్టర్‌లలో వనరులను అప్‌డేట్ చేయడానికి వివిధ మార్గాల గురించిన ఈ చిన్న అవలోకనం మీకు సహాయకారిగా ఉంటుందని నేను ఆశిస్తున్నాను. ఇది వర్తింపజేయడం మరియు భర్తీ చేయడం మాత్రమే కాదని తెలుసుకోవడం మంచిది; వర్తింపజేయడం, సవరించడం, ప్యాచ్ చేయడం లేదా భర్తీ చేయడం ద్వారా వనరును నవీకరించడం సాధ్యమవుతుంది. అన్నింటికంటే, సూత్రప్రాయంగా, ప్రతి విధానానికి దాని స్వంత అప్లికేషన్ ప్రాంతం ఉంటుంది. పరమాణు మార్పుల కోసం, భర్తీ చేయడం ఉత్తమం; లేకపోతే, మీరు దరఖాస్తు ద్వారా వ్యూహాత్మక-విలీన ప్యాచ్‌ని ఉపయోగించాలి. కనీసం, "kubernetes apply vs replace" కోసం శోధిస్తున్నప్పుడు మీరు Google లేదా StackOerflowని విశ్వసించలేరని మీరు అర్థం చేసుకుంటారని నేను ఆశిస్తున్నాను. కనీసం ఈ కథనం ప్రస్తుత సమాధానాన్ని భర్తీ చేసే వరకు.
మూలం: www.habr.com