ప్రోహోస్టర్ > బ్లాగ్ > పరిపాలన > వెర్ఫ్‌కు 3-మార్గం విలీనం: స్టెరాయిడ్స్‌పై హెల్మ్‌తో కుబెర్నెటెస్‌కు విస్తరణ

వెర్ఫ్‌కు 3-మార్గం విలీనం: స్టెరాయిడ్స్‌పై హెల్మ్‌తో కుబెర్నెటెస్‌కు విస్తరణ

మనం (మరియు మనం మాత్రమే కాదు) చాలా కాలంగా ఎదురుచూస్తున్నది జరిగింది: వర్ఫ్, అప్లికేషన్‌లను రూపొందించడానికి మరియు వాటిని కుబెర్నెట్‌లకు డెలివరీ చేయడానికి మా ఓపెన్ సోర్స్ యుటిలిటీ, ఇప్పుడు 3-వే విలీన ప్యాచ్‌లను ఉపయోగించి మార్పులను వర్తింపజేయడానికి మద్దతు ఇస్తుంది! దీనికి అదనంగా, ఈ వనరులను పునర్నిర్మించకుండా ఇప్పటికే ఉన్న K8s వనరులను హెల్మ్ విడుదలలలోకి స్వీకరించడం సాధ్యమవుతుంది.

వెర్ఫ్‌కు 3-మార్గం విలీనం: స్టెరాయిడ్స్‌పై హెల్మ్‌తో కుబెర్నెటెస్‌కు విస్తరణ

ఇది చాలా చిన్నది అయితే, మేము ఉంచుతాము WERF_THREE_WAY_MERGE=enabled — మేము విస్తరణను పొందుతాము kubectl apply", ఇప్పటికే ఉన్న హెల్మ్ 2 ఇన్‌స్టాలేషన్‌లకు అనుకూలంగా ఉంటుంది మరియు ఇంకా కొంచెం ఎక్కువ.

అయితే సిద్ధాంతంతో ప్రారంభిద్దాం: సరిగ్గా 3-మార్గం-విలీన ప్యాచ్‌లు అంటే ఏమిటి, వాటిని రూపొందించే విధానంతో వ్యక్తులు ఎలా వచ్చారు మరియు కుబెర్నెట్స్ ఆధారిత మౌలిక సదుపాయాలతో CI/CD ప్రక్రియలలో అవి ఎందుకు ముఖ్యమైనవి? మరియు దాని తర్వాత, werfలో 3-మార్గం-విలీనం ఏమిటి, డిఫాల్ట్‌గా ఏ మోడ్‌లు ఉపయోగించబడతాయి మరియు దానిని ఎలా నిర్వహించాలో చూద్దాం.

3-మార్గం-విలీన ప్యాచ్ అంటే ఏమిటి?

కాబట్టి, YAML మానిఫెస్ట్‌లలో వివరించిన వనరులను కుబెర్నెట్‌లుగా మార్చే పనితో ప్రారంభిద్దాం.

వనరులతో పని చేయడానికి, Kubernetes API కింది ప్రాథమిక కార్యకలాపాలను అందిస్తుంది: సృష్టించడం, ప్యాచ్ చేయడం, భర్తీ చేయడం మరియు తొలగించడం. వారి సహాయంతో క్లస్టర్‌కు వనరుల యొక్క సౌకర్యవంతమైన నిరంతర రోల్‌అవుట్‌ను నిర్మించడం అవసరం అని భావించబడుతుంది. ఎలా?

అత్యవసర kubectl ఆదేశాలు

కుబెర్నెట్స్‌లో వస్తువులను నిర్వహించడానికి మొదటి విధానం ఏమిటంటే, ఆ వస్తువులను సృష్టించడానికి, సవరించడానికి మరియు తొలగించడానికి kubectl అత్యవసర ఆదేశాలను ఉపయోగించడం. సరళంగా చెప్పాలంటే:

  • జట్టు kubectl run మీరు విస్తరణ లేదా ఉద్యోగాన్ని అమలు చేయవచ్చు: 
    kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
  • జట్టు kubectl scale - ప్రతిరూపాల సంఖ్యను మార్చండి: 
    kubectl scale --replicas=3 deployment/mysql
  • మరియు అందువలన న.

ఈ విధానం మొదటి చూపులో సౌకర్యవంతంగా అనిపించవచ్చు. అయితే సమస్యలు ఉన్నాయి:

  1. అది కష్టం ఆటోమేట్.
  2. ఎలా ఆకృతీకరణను ప్రతిబింబిస్తాయి Git లో? క్లస్టర్‌లో జరుగుతున్న మార్పులను ఎలా సమీక్షించాలి?
  3. ఎలా అందించాలి పునరుత్పత్తి పునఃప్రారంభంలో కాన్ఫిగరేషన్లు?
  4. ...

అప్లికేషన్ మరియు ఇన్‌ఫ్రాస్ట్రక్చర్‌ను కోడ్‌గా (IaC; లేదా కూడా నిల్వ చేయడానికి ఈ విధానం సరిగ్గా సరిపోదని స్పష్టమైంది. GitOps మరింత ఆధునిక ఎంపికగా, కుబెర్నెట్స్ పర్యావరణ వ్యవస్థలో ప్రజాదరణ పొందింది). కాబట్టి, ఈ ఆదేశాలు kubectlలో మరింత అభివృద్ధిని పొందలేదు.

కార్యకలాపాలను సృష్టించండి, పొందండి, భర్తీ చేయండి మరియు తొలగించండి

ప్రాథమిక తో సృష్టి ఇది చాలా సులభం: మానిఫెస్ట్‌ను ఆపరేషన్‌కు పంపండి create kube api మరియు వనరు సృష్టించబడింది. మానిఫెస్ట్ యొక్క YAML ప్రాతినిధ్యం Gitలో నిల్వ చేయబడుతుంది మరియు ఆదేశాన్ని ఉపయోగించి సృష్టించబడుతుంది kubectl create -f manifest.yaml.

С తొలగింపు కూడా సులభం: అదే ప్రత్యామ్నాయం manifest.yaml Git నుండి జట్టుకు kubectl delete -f manifest.yaml.

ఆపరేషన్ replace వనరును పునఃసృష్టించకుండా, పూర్తిగా కొత్త దానితో వనరుల కాన్ఫిగరేషన్‌ను భర్తీ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. దీనర్థం వనరుకు మార్పు చేయడానికి ముందు, ఆపరేషన్‌తో ప్రస్తుత సంస్కరణను ప్రశ్నించడం తార్కికం get, దాన్ని మార్చండి మరియు ఆపరేషన్‌తో అప్‌డేట్ చేయండి replace. kube apiserver నిర్మించబడింది ఆశావాద లాకింగ్ మరియు, శస్త్రచికిత్స తర్వాత ఉంటే get వస్తువు మార్చబడింది, ఆపై ఆపరేషన్ replace అది పని చేయదు.

Gitలో కాన్ఫిగరేషన్‌ను నిల్వ చేయడానికి మరియు భర్తీని ఉపయోగించి దాన్ని నవీకరించడానికి, మీరు ఆపరేషన్ చేయాలి get, Git నుండి కాన్ఫిగరేషన్‌ను మనం అందుకున్న దానితో విలీనం చేసి, అమలు చేయండి replace. డిఫాల్ట్‌గా, kubectl మిమ్మల్ని ఆదేశాన్ని ఉపయోగించడానికి మాత్రమే అనుమతిస్తుంది kubectl replace -f manifest.yamlపేరు manifest.yaml — ఇప్పటికే పూర్తిగా సిద్ధం చేయబడిన (మా విషయంలో, విలీనం చేయబడిన) మానిఫెస్ట్ ఇన్‌స్టాల్ చేయాలి. వినియోగదారు విలీన మానిఫెస్ట్‌లను అమలు చేయాల్సిన అవసరం ఉందని తేలింది మరియు ఇది సామాన్యమైన విషయం కాదు...

అయినప్పటికీ గమనించదగ్గ విషయం manifest.yaml మరియు Gitలో నిల్వ చేయబడుతుంది, ఆబ్జెక్ట్‌ను సృష్టించడం లేదా దాన్ని నవీకరించడం అవసరమా కాదా అని మేము ముందుగానే తెలుసుకోలేము - ఇది తప్పనిసరిగా వినియోగదారు సాఫ్ట్‌వేర్ ద్వారా చేయాలి.

మొత్తం: మేము నిరంతర రోల్‌అవుట్‌ని నిర్మించగలము కోడ్ మరియు అనుకూలమైన CI/CDతో పాటు మౌలిక సదుపాయాల కాన్ఫిగరేషన్ Gitలో నిల్వ చేయబడిందని నిర్ధారిస్తూ, సృష్టించడం, భర్తీ చేయడం మరియు తొలగించడం మాత్రమే ఉపయోగించాలా?

సూత్రప్రాయంగా, మనం... దీని కోసం మీరు విలీన చర్యను అమలు చేయాలి మానిఫెస్టోలు మరియు కొన్ని రకాల బైండింగ్:

  • క్లస్టర్‌లో వస్తువు ఉనికిని తనిఖీ చేస్తుంది,
  • ప్రారంభ వనరుల సృష్టిని నిర్వహిస్తుంది,
  • దాన్ని నవీకరిస్తుంది లేదా తొలగిస్తుంది.

నవీకరించేటప్పుడు, దయచేసి గమనించండి వనరు మారవచ్చు చివరి నుండి get మరియు స్వయంచాలకంగా ఆశావాద లాకింగ్ కేసును నిర్వహిస్తుంది - పునరావృత నవీకరణ ప్రయత్నాలు చేయండి.

అయినప్పటికీ, వనరులను నవీకరించడానికి kube-apiserver మరొక మార్గాన్ని అందించినప్పుడు చక్రాన్ని ఎందుకు తిరిగి ఆవిష్కరించాలి: ఆపరేషన్ patch, వివరించిన కొన్ని సమస్యల నుండి వినియోగదారుకు ఉపశమనం కలిగించేది ఏది?

ప్యాచ్

ఇప్పుడు మనం పాచెస్‌కి వస్తాము.

కుబెర్నెట్స్‌లో ఇప్పటికే ఉన్న వస్తువులకు మార్పులను వర్తింపజేయడానికి ప్యాచ్‌లు ప్రాథమిక మార్గం. ఆపరేషన్ patch ఇది ఇలా పనిచేస్తుంది:

  • kube-apiserver వినియోగదారు JSON ఫారమ్‌లో ప్యాచ్‌ని పంపాలి మరియు ఆబ్జెక్ట్‌ను పేర్కొనాలి,
  • మరియు apiserver స్వయంగా వస్తువు యొక్క ప్రస్తుత స్థితితో వ్యవహరిస్తుంది మరియు దానిని అవసరమైన రూపానికి తీసుకువస్తుంది.

ఈ సందర్భంలో ఆశావాద లాకింగ్ అవసరం లేదు. ఈ ఆపరేషన్ రీప్లేస్ చేయడం కంటే ఎక్కువ డిక్లరేటివ్‌గా ఉంటుంది, అయితే మొదట ఇది వేరే విధంగా అనిపించవచ్చు.

ఈ విధంగా:

  • ఒక ఆపరేషన్ ఉపయోగించి create Git నుండి మానిఫెస్ట్ ప్రకారం మేము ఒక వస్తువును సృష్టిస్తాము,
  • సహాయంతో delete - ఆబ్జెక్ట్ ఇకపై అవసరం లేకపోతే తొలగించండి,
  • సహాయంతో patch — మేము వస్తువును మారుస్తాము, దానిని Gitలో వివరించిన రూపంలోకి తీసుకువస్తాము.

అయితే, దీన్ని చేయడానికి, మీరు సృష్టించాలి సరైన పాచ్!

హెల్మ్ 2: 2-వే-మెర్జ్‌లో ప్యాచ్‌లు ఎలా పని చేస్తాయి

మీరు మొదట విడుదలను ఇన్‌స్టాల్ చేసినప్పుడు, హెల్మ్ ఆపరేషన్ చేస్తుంది create చార్ట్ వనరుల కోసం.

ప్రతి వనరు కోసం హెల్మ్ విడుదలను నవీకరిస్తున్నప్పుడు:

  • మునుపటి చార్ట్ మరియు ప్రస్తుత చార్ట్ వెర్షన్ నుండి రిసోర్స్ వెర్షన్ మధ్య ప్యాచ్‌ను పరిగణిస్తుంది,
  • ఈ ప్యాచ్ వర్తిస్తుంది.

మేము దీనిని ప్యాచ్ అని పిలుస్తాము 2-మార్గం విలీనం ప్యాచ్, ఎందుకంటే దాని సృష్టిలో 2 మానిఫెస్టోలు ఉన్నాయి:

  • మునుపటి విడుదల నుండి వనరుల మానిఫెస్ట్,
  • ప్రస్తుత వనరు నుండి వనరు మానిఫెస్ట్.

ఆపరేషన్ను తీసివేసేటప్పుడు delete kube apiserverలో మునుపటి విడుదలలో ప్రకటించబడిన వనరుల కోసం పిలుస్తారు, కానీ ప్రస్తుత దానిలో ప్రకటించబడలేదు.

2 వే విలీన ప్యాచ్ విధానంలో సమస్య ఉంది: ఇది దారి తీస్తుంది క్లస్టర్‌లోని వనరు యొక్క వాస్తవ స్థితి మరియు Gitలోని మానిఫెస్ట్‌తో సమకాలీకరించబడలేదు.

ఒక ఉదాహరణతో సమస్య యొక్క ఉదాహరణ

  • Gitలో, ఒక చార్ట్ ఫీల్డ్‌లో మానిఫెస్ట్‌ను నిల్వ చేస్తుంది image విస్తరణ విషయాలు ubuntu:18.04.
  • వినియోగదారు ద్వారా kubectl edit ఈ ఫీల్డ్ విలువను మార్చింది ubuntu:19.04.
  • హెల్మ్ చార్ట్‌ను మళ్లీ అమలు చేస్తున్నప్పుడు ప్యాచ్‌ను రూపొందించదు, ఎందుకంటే ఫీల్డ్ image విడుదల యొక్క మునుపటి సంస్కరణలో మరియు ప్రస్తుత చార్ట్‌లో ఒకే విధంగా ఉన్నాయి.
  • తిరిగి విస్తరణ తర్వాత image అవశేషాలు ubuntu:19.04, చార్ట్ చెప్పినప్పటికీ ubuntu:18.04.

మేము డీసింక్రొనైజేషన్ పొందాము మరియు డిక్లరేటివ్‌ని కోల్పోయాము.

సమకాలీకరించబడిన వనరు అంటే ఏమిటి?

సాధారణంగా, పూర్తి నడుస్తున్న క్లస్టర్‌లోని రిసోర్స్ మానిఫెస్ట్ మరియు Git నుండి మానిఫెస్ట్ మధ్య సరిపోలికను పొందడం అసాధ్యం. ఎందుకంటే నిజమైన మానిఫెస్ట్‌లో సేవా ఉల్లేఖనాలు/లేబుల్‌లు, అదనపు కంటైనర్‌లు మరియు ఇతర డేటా ఉండవచ్చు, అవి కొన్ని కంట్రోలర్‌ల ద్వారా డైనమిక్‌గా వనరు నుండి జోడించబడతాయి మరియు తీసివేయబడతాయి. మేము ఈ డేటాను Gitలో ఉంచలేము మరియు కోరుకోము. అయినప్పటికీ, మేము Gitలో స్పష్టంగా పేర్కొన్న ఫీల్డ్‌లు రోల్ అవుట్ అయిన తర్వాత తగిన విలువలను పొందాలని మేము కోరుకుంటున్నాము.

ఇది చాలా సాధారణమైనదిగా మారుతుంది సమకాలీకరించబడిన వనరు నియమం: రిసోర్స్‌ను రోల్ అవుట్ చేస్తున్నప్పుడు, మీరు Git నుండి మానిఫెస్ట్‌లో స్పష్టంగా పేర్కొన్న ఫీల్డ్‌లను మాత్రమే మార్చవచ్చు లేదా తొలగించవచ్చు (లేదా మునుపటి సంస్కరణలో పేర్కొనబడ్డాయి మరియు ఇప్పుడు తొలగించబడ్డాయి).

3-మార్గం విలీనం ప్యాచ్

ప్రధానమైన ఆలోచన 3-మార్గం విలీనం ప్యాచ్: మేము Git నుండి మానిఫెస్ట్ యొక్క చివరి అప్లైడ్ వెర్షన్ మరియు Git నుండి మానిఫెస్ట్ యొక్క టార్గెట్ వెర్షన్ మధ్య ప్యాచ్‌ను రూపొందిస్తాము, రన్నింగ్ క్లస్టర్ నుండి మానిఫెస్ట్ యొక్క ప్రస్తుత వెర్షన్‌ను పరిగణనలోకి తీసుకుంటాము. ఫలిత ప్యాచ్ తప్పనిసరిగా సమకాలీకరించబడిన వనరు నియమానికి అనుగుణంగా ఉండాలి:

  • లక్ష్య సంస్కరణకు జోడించబడిన కొత్త ఫీల్డ్‌లు ప్యాచ్‌ని ఉపయోగించి జోడించబడతాయి;
  • చివరిగా వర్తించిన సంస్కరణలో గతంలో ఉన్న ఫీల్డ్‌లు మరియు లక్ష్య సంస్కరణలో లేనివి ప్యాచ్‌ని ఉపయోగించి రీసెట్ చేయబడతాయి;
  • మానిఫెస్ట్ యొక్క లక్ష్య సంస్కరణకు భిన్నంగా ఉన్న ఆబ్జెక్ట్ యొక్క ప్రస్తుత సంస్కరణలోని ఫీల్డ్‌లు ప్యాచ్‌ని ఉపయోగించి నవీకరించబడతాయి.

ఈ సూత్రంపైనే ఇది పాచెస్‌ను ఉత్పత్తి చేస్తుంది kubectl apply:

  • మానిఫెస్ట్ యొక్క చివరి అనువర్తిత సంస్కరణ ఆబ్జెక్ట్ యొక్క ఉల్లేఖనంలో నిల్వ చేయబడుతుంది,
  • లక్ష్యం - పేర్కొన్న YAML ఫైల్ నుండి తీసుకోబడింది,
  • ప్రస్తుతము నడుస్తున్న క్లస్టర్ నుండి.

ఇప్పుడు మేము సిద్ధాంతాన్ని క్రమబద్ధీకరించాము, మేము వెర్ఫ్‌లో ఏమి చేసామో మీకు చెప్పాల్సిన సమయం వచ్చింది.

werfకు మార్పులను వర్తింపజేయడం

మునుపు, హెల్మ్ 2 వంటి వెర్ఫ్ 2-వే-మెర్జ్ ప్యాచ్‌లను ఉపయోగించింది.

మరమ్మత్తు పాచ్

కొత్త రకం ప్యాచ్‌లకు మారడానికి - 3-వే-మెర్జ్ - మేము మొదటి దశ అని పిలవబడే వాటిని పరిచయం చేసాము మరమ్మత్తు పాచెస్.

అమలు చేస్తున్నప్పుడు, ప్రామాణిక 2-మార్గం-విలీన ప్యాచ్ ఉపయోగించబడుతుంది, అయితే werf అదనంగా ఒక ప్యాచ్‌ను ఉత్పత్తి చేస్తుంది, అది Gitలో వ్రాయబడిన దానితో వనరు యొక్క వాస్తవ స్థితిని సమకాలీకరించగలదు (అటువంటి ప్యాచ్ పైన వివరించిన అదే సమకాలీకరించబడిన వనరు నియమాన్ని ఉపయోగించి సృష్టించబడుతుంది) .

డీసింక్రొనైజేషన్ సంభవించినట్లయితే, విస్తరణ ముగింపులో వినియోగదారు సంబంధిత సందేశంతో హెచ్చరికను అందుకుంటారు మరియు వనరును సమకాలీకరించబడిన ఫారమ్‌కు తీసుకురావడానికి తప్పనిసరిగా వర్తించాల్సిన ప్యాచ్. ఈ ప్యాచ్ ప్రత్యేక ఉల్లేఖనంలో కూడా రికార్డ్ చేయబడింది werf.io/repair-patch. ఇది వినియోగదారు చేతులు అని భావించబడుతుంది сам ఈ ప్యాచ్‌ని వర్తింపజేస్తుంది: werf దీన్ని అస్సలు వర్తించదు.

మరమ్మత్తు ప్యాచ్‌లను రూపొందించడం అనేది 3-మార్గం-విలీన సూత్రం ఆధారంగా పాచెస్‌ల సృష్టిని నిజంగా పరీక్షించడానికి మిమ్మల్ని అనుమతించే తాత్కాలిక కొలత, అయితే ఈ ప్యాచ్‌లను స్వయంచాలకంగా వర్తించవద్దు. ప్రస్తుతానికి, ఈ ఆపరేటింగ్ మోడ్ డిఫాల్ట్‌గా ప్రారంభించబడింది.

కొత్త విడుదలల కోసం మాత్రమే 3-మార్గం-విలీన ప్యాచ్

డిసెంబర్ 1, 2019 నుండి, werf యొక్క బీటా మరియు ఆల్ఫా వెర్షన్‌లు ప్రారంభమవుతాయి అప్రమేయంగా వెర్ఫ్ ద్వారా రూపొందించబడిన కొత్త హెల్మ్ విడుదలలకు మాత్రమే మార్పులను వర్తింపజేయడానికి పూర్తి స్థాయి 3-మార్గం-విలీన ప్యాచ్‌లను ఉపయోగించండి. ఇప్పటికే ఉన్న విడుదలలు 2-మార్గం-విలీనం + మరమ్మతు ప్యాచ్‌ల విధానాన్ని ఉపయోగించడం కొనసాగిస్తాయి.

ఈ ఆపరేటింగ్ మోడ్‌ను సెట్ చేయడం ద్వారా స్పష్టంగా ప్రారంభించవచ్చు WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ఇప్పుడు.

వ్యాఖ్య: ఫీచర్ అనేక విడుదలలలో werf లో కనిపించింది: ఆల్ఫా ఛానెల్‌లో ఇది వెర్షన్‌తో సిద్ధంగా ఉంది v1.0.5-alpha.19, మరియు బీటా ఛానెల్‌లో - తో v1.0.4-బీటా.20.

అన్ని విడుదలల కోసం 3-మార్గం-విలీన ప్యాచ్

డిసెంబర్ 15, 2019 నుండి, werf యొక్క బీటా మరియు ఆల్ఫా వెర్షన్‌లు అన్ని విడుదలలకు మార్పులను వర్తింపజేయడానికి డిఫాల్ట్‌గా పూర్తి 3-మార్గం-విలీన ప్యాచ్‌లను ఉపయోగించడం ప్రారంభించాయి.

ఈ ఆపరేటింగ్ మోడ్‌ను సెట్ చేయడం ద్వారా స్పష్టంగా ప్రారంభించవచ్చు WERF_THREE_WAY_MERGE_MODE=enabled ఇప్పుడు.

రిసోర్స్ ఆటోస్కేలింగ్‌తో ఏమి చేయాలి?

కుబెర్నెటీస్‌లో 2 రకాల ఆటోస్కేలింగ్ ఉన్నాయి: HPA (క్షితిజ సమాంతర) మరియు VPA (నిలువు).

క్షితిజసమాంతర స్వయంచాలకంగా ప్రతిరూపాల సంఖ్యను ఎంచుకుంటుంది, నిలువు - వనరుల సంఖ్య. ప్రతిరూపాల సంఖ్య మరియు వనరుల అవసరాలు రెండూ రిసోర్స్ మానిఫెస్ట్‌లో పేర్కొనబడ్డాయి (రిసోర్స్ మానిఫెస్ట్ చూడండి). spec.replicas లేదా spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

సమస్య: వినియోగదారు ఒక చార్ట్‌లో వనరును కాన్ఫిగర్ చేస్తే అది వనరుల కోసం నిర్దిష్ట విలువలను నిర్దేశిస్తే లేదా ప్రతిరూపాలు మరియు ఆటోస్కేలర్‌లు ఈ వనరు కోసం ప్రారంభించబడితే, ప్రతి డిప్లాయ్‌మెంట్ వెర్ఫ్ ఈ విలువలను చార్ట్ మానిఫెస్ట్‌లో వ్రాసిన దానికి రీసెట్ చేస్తుంది. .

సమస్యకు రెండు పరిష్కారాలు ఉన్నాయి. ప్రారంభించడానికి, చార్ట్ మానిఫెస్ట్‌లో ఆటోస్కేల్ చేయబడిన విలువలను స్పష్టంగా పేర్కొనకుండా ఉండటం ఉత్తమం. ఈ ఎంపిక కొన్ని కారణాల వల్ల సరిపోకపోతే (ఉదాహరణకు, ప్రారంభ వనరుల పరిమితులను మరియు చార్ట్‌లోని ప్రతిరూపాల సంఖ్యను సెట్ చేయడం సౌకర్యంగా ఉంటుంది), అప్పుడు werf క్రింది ఉల్లేఖనాలను అందిస్తుంది:

  • werf.io/set-replicas-only-on-creation=true
  • werf.io/set-resources-only-on-creation=true

అటువంటి ఉల్లేఖనం ఉన్నట్లయితే, werf ప్రతి విస్తరణలో సంబంధిత విలువలను రీసెట్ చేయదు, కానీ వనరు ప్రారంభంలో సృష్టించబడినప్పుడు మాత్రమే వాటిని సెట్ చేస్తుంది.

మరిన్ని వివరాల కోసం, ప్రాజెక్ట్ డాక్యుమెంటేషన్ చూడండి తక్కువ hPa и VPA.

3-మార్గం-విలీనం ప్యాచ్‌ను ఉపయోగించడాన్ని నిషేధించండి

వినియోగదారు ప్రస్తుతం పర్యావరణ వేరియబుల్‌ని ఉపయోగించి werfలో కొత్త ప్యాచ్‌ల వినియోగాన్ని నిషేధించవచ్చు WERF_THREE_WAY_MERGE_MODE=disabled. అయితే, ప్రారంభం మార్చి 1, 2020 నుండి, ఈ నిషేధం వర్తించదు. మరియు 3-మార్గం-విలీన ప్యాచ్‌లను ఉపయోగించడం మాత్రమే సాధ్యమవుతుంది.

వెర్ఫ్‌లో వనరుల స్వీకరణ

3-మార్గం-విలీన ప్యాచ్‌లతో మార్పులను వర్తింపజేసే పద్ధతిని మాస్టరింగ్ చేయడం వల్ల క్లస్టర్‌లో ఉన్న వనరులను హెల్మ్ విడుదలలో స్వీకరించడం వంటి లక్షణాన్ని వెంటనే అమలు చేయడానికి మాకు అనుమతి ఉంది.

హెల్మ్ 2కి సమస్య ఉంది: మీరు మొదటి నుండి ఈ వనరుని పునఃసృష్టించకుండా క్లస్టర్‌లో ఇప్పటికే ఉన్న మానిఫెస్ట్‌లను చార్ట్‌కు జోడించలేరు (చూడండి. #6031, #3275) విడుదల కోసం ఇప్పటికే ఉన్న వనరులను అంగీకరించమని మేము వెర్ఫ్‌కి నేర్పించాము. దీన్ని చేయడానికి, మీరు నడుస్తున్న క్లస్టర్ నుండి వనరు యొక్క ప్రస్తుత సంస్కరణపై ఉల్లేఖనాన్ని ఇన్‌స్టాల్ చేయాలి (ఉదాహరణకు, ఉపయోగించి kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

ఇప్పుడు వనరును చార్ట్‌లో వివరించాలి మరియు తదుపరిసారి werf తగిన పేరుతో విడుదలను అమలు చేసినప్పుడు, ఇప్పటికే ఉన్న వనరు ఈ విడుదలలోకి అంగీకరించబడుతుంది మరియు దాని నియంత్రణలో ఉంటుంది. అంతేకాకుండా, విడుదల కోసం రిసోర్స్‌ను అంగీకరించే ప్రక్రియలో, అదే 3-వే-మెర్జ్ ప్యాచ్‌లు మరియు సింక్రొనైజ్డ్ రిసోర్స్ రూల్‌ని ఉపయోగించి verf రన్నింగ్ క్లస్టర్ నుండి రిసోర్స్ యొక్క ప్రస్తుత స్థితిని చార్ట్‌లో వివరించిన స్థితికి తీసుకువస్తుంది.

వ్యాఖ్య: అమరిక WERF_THREE_WAY_MERGE_MODE వనరుల స్వీకరణను ప్రభావితం చేయదు - స్వీకరణ విషయంలో, 3-మార్గం-విలీన ప్యాచ్ ఎల్లప్పుడూ ఉపయోగించబడుతుంది.

వివరాలు - లో డాక్యుమెంటేషన్.

ముగింపులు మరియు భవిష్యత్తు ప్రణాళికలు

ఈ కథనం తర్వాత 3-మార్గం-విలీన ప్యాచ్‌లు అంటే ఏమిటో మరియు అవి వాటి వద్దకు ఎందుకు వచ్చాయో స్పష్టంగా అర్థమైందని నేను ఆశిస్తున్నాను. వెర్ఫ్ ప్రాజెక్ట్ అభివృద్ధి యొక్క ఆచరణాత్మక దృక్కోణం నుండి, వారి అమలు హెల్మ్-వంటి విస్తరణను మెరుగుపరచడానికి మరొక అడుగు. హెల్మ్ 2ని ఉపయోగిస్తున్నప్పుడు తరచుగా తలెత్తే కాన్ఫిగరేషన్ సింక్రొనైజేషన్‌తో ఉన్న సమస్యల గురించి ఇప్పుడు మీరు మరచిపోవచ్చు. అదే సమయంలో, ఇప్పటికే డౌన్‌లోడ్ చేయబడిన కుబెర్నెట్స్ వనరులను స్వీకరించే కొత్త ఉపయోగకరమైన ఫీచర్ హెల్మ్ విడుదలకు జోడించబడింది.

గో టెంప్లేట్‌ల వినియోగం వంటి హెల్మ్-వంటి విస్తరణలతో ఇంకా కొన్ని సమస్యలు మరియు సవాళ్లు ఉన్నాయి, వీటిని మేము పరిష్కరిస్తాము.

వనరుల నవీకరణ పద్ధతులు మరియు స్వీకరణ గురించి సమాచారాన్ని కూడా ఇక్కడ చూడవచ్చు ఈ డాక్యుమెంటేషన్ పేజీ.

హెల్మ్ 3

ప్రత్యేకంగా గమనించదగినది విడుదల చేసింది మరొక రోజు హెల్మ్ యొక్క కొత్త ప్రధాన వెర్షన్ - v3 - ఇది 3-వే-మెర్జ్ ప్యాచ్‌లను కూడా ఉపయోగిస్తుంది మరియు టిల్లర్‌ను తొలగిస్తుంది. హెల్మ్ యొక్క కొత్త వెర్షన్ అవసరం వలస వాటిని కొత్త విడుదల నిల్వ ఫార్మాట్‌లోకి మార్చడానికి ఇప్పటికే ఉన్న ఇన్‌స్టాలేషన్‌లు.

వెర్ఫ్, దాని భాగానికి, ప్రస్తుతం టిల్లర్‌ను ఉపయోగించకుండా వదిలించుకుంది, 3-వే-మెర్జ్‌కి మార్చబడింది మరియు జోడించబడింది ఇంకా చాలా, ఇప్పటికే ఉన్న హెల్మ్ 2 ఇన్‌స్టాలేషన్‌లకు అనుకూలంగా ఉంటూనే (మైగ్రేషన్ స్క్రిప్ట్‌లు అమలు చేయవలసిన అవసరం లేదు). అందువల్ల, హెల్మ్ 3కి వెర్ఫ్ మారే వరకు, హెల్మ్ 3 కంటే హెల్మ్ 2 యొక్క ప్రధాన ప్రయోజనాలను వెర్ఫ్ వినియోగదారులు కోల్పోరు (వెర్ఫ్ కూడా వాటిని కలిగి ఉన్నారు).

అయినప్పటికీ, హెల్మ్ 3 కోడ్‌బేస్‌కు వెర్ఫ్ మారడం అనివార్యం మరియు సమీప భవిష్యత్తులో జరుగుతుంది. బహుశా ఇది werf 1.1 లేదా werf 1.2 కావచ్చు (ప్రస్తుతం, werf యొక్క ప్రధాన వెర్షన్ 1.0; werf సంస్కరణ పరికరం గురించి మరింత సమాచారం కోసం, చూడండి ఇక్కడ) ఈ సమయంలో, హెల్మ్ 3 స్థిరీకరించడానికి సమయం ఉంటుంది.

PS

మా బ్లాగులో కూడా చదవండి:

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి