కస్టమైజ్ చేయడానికి సంక్షిప్త పరిచయం

గమనిక. అనువాదం.: ఏడు ముద్రిత పుస్తకాల (ప్రధానంగా VMware vSphereలో) రచయిత/సహ రచయిత అయిన ITలో విస్తృతమైన అనుభవం ఉన్న ఇంజనీర్ అయిన స్కాట్ లోవ్ ఈ కథనాన్ని రాశారు. అతను ఇప్పుడు క్లౌడ్ కంప్యూటింగ్ మరియు కుబెర్నెట్స్‌లో ప్రత్యేకత కలిగిన దాని VMware అనుబంధ సంస్థ Heptio (2016లో కొనుగోలు చేయబడింది) కోసం పని చేస్తున్నాడు. సాంకేతికతను ఉపయోగించి కుబెర్నెట్స్ కోసం కాన్ఫిగరేషన్ మేనేజ్‌మెంట్‌కు టెక్స్ట్ సంక్షిప్త మరియు సులభంగా అర్థం చేసుకోగలిగే పరిచయంగా పనిచేస్తుంది అనుకూలీకరించు, ఇది ఇటీవల K8లలో భాగమైంది.

కస్టమైజ్ అనేది వినియోగదారులను "వివిధ ప్రయోజనాల కోసం సరళమైన, టెంప్లేట్-రహిత YAML ఫైల్‌లను అనుకూలీకరించడానికి అనుమతిస్తుంది, అసలు YAML చెక్కుచెదరకుండా మరియు ఉపయోగించదగినది" (వివరణ నేరుగా నుండి తీసుకోబడింది GitHubలో రిపోజిటరీని అనుకూలీకరించండి) Kustomize నేరుగా అమలు చేయబడుతుంది లేదా Kubernetes 1.14 ప్రకారం, ఉపయోగించబడవచ్చు kubectl -k దాని కార్యాచరణను యాక్సెస్ చేయడానికి (కుబెర్నెటెస్ 1.15 నాటికి, ప్రత్యేక బైనరీ kubectlలో నిర్మించిన సామర్థ్యాల కంటే కొత్తది). (గమనిక. అనువాదం.: మరియు ఇటీవల విడుదలతో కుబెర్నెట్స్ 1.16 అనుకూలీకరించండి ద్వారా మద్దతు kubeadm యుటిలిటీలో కూడా ఉంది.) ఈ పోస్ట్‌లో, నేను కస్టమైజ్ యొక్క ప్రాథమికాలను పాఠకులకు పరిచయం చేయాలనుకుంటున్నాను.

దాని సరళమైన రూపంలో/అనువర్తనంలో, kustomize అనేది కేవలం వనరుల సమాహారం (కుబెర్నెట్స్ ఆబ్జెక్ట్‌లను నిర్వచించే YAML ఫైల్‌లు: విస్తరణలు, సేవలు మొదలైనవి) మరియు ఆ వనరులకు చేయవలసిన మార్పుల కోసం సూచనల జాబితా. మేక్‌లో ఉన్న ఇన్‌స్ట్రక్షన్ సెట్‌ని ఉపయోగిస్తుంది Makefile, మరియు డాకర్ నుండి సూచనల ఆధారంగా కంటైనర్‌ను నిర్మిస్తుంది Dockerfile,ఉపయోగాలను అనుకూలీకరించండి kustomization.yaml వనరుల సమితికి వినియోగదారు ఎలాంటి మార్పులు చేయాలనుకుంటున్నారు అనే దాని గురించి సూచనలను నిల్వ చేయడానికి.

ఇక్కడ ఒక ఉదాహరణ ఫైల్ ఉంది kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

నేను ఫైల్‌లోని అన్ని ఫీల్డ్‌ల గురించి మాట్లాడటానికి ప్రయత్నించను. kustomization.yaml (దీని గురించి బాగా రాశారు ఇక్కడ), కానీ నేను ఒక నిర్దిష్ట ఉదాహరణకి సంక్షిప్త వివరణ ఇస్తాను:

• ఫీల్డ్ resources ఏది (ఏ వనరులు) కస్టమైజ్ మారుతుందో సూచిస్తుంది. ఈ సందర్భంలో, ఇది ఫైల్‌లలో వనరుల కోసం చూస్తుంది deployment.yaml и service.yaml మీ డైరెక్టరీలో (అవసరమైతే మీరు పూర్తి లేదా సంబంధిత మార్గాలను పేర్కొనవచ్చు).
• ఫీల్డ్ namePrefix నిర్దిష్ట ఉపసర్గను జోడించమని కస్టమైజ్‌ని నిర్దేశిస్తుంది (ఈ సందర్భంలో - dev-) ఆపాదించడానికి name ఫీల్డ్‌లో నిర్వచించబడిన అన్ని వనరులు resources. అందువలన, విస్తరణ కలిగి ఉంటే name అర్థంతో nginx-deployment, అనుకూలీకరించండి అది చేస్తుంది dev-nginx-deployment.
• ఫీల్డ్ namespace అన్ని వనరులకు ఇచ్చిన నేమ్‌స్పేస్‌ను జోడించమని కస్టమైజ్‌ని నిర్దేశిస్తుంది. ఈ సందర్భంలో, విస్తరణ మరియు సేవ నేమ్‌స్పేస్‌లోకి వస్తాయి development.
• చివరగా, ఫీల్డ్ commonLabels అన్ని వనరులకు జోడించబడే లేబుల్‌ల సమితిని కలిగి ఉంటుంది. మా ఉదాహరణలో, kustomize పేరుతో వనరులకు లేబుల్‌ని కేటాయిస్తుంది environment మరియు అర్థం development.

వినియోగదారు చేస్తే kustomize build . ఫైల్‌తో డైరెక్టరీలో kustomization.yaml మరియు అవసరమైన వనరులు (అంటే ఫైల్‌లు deployment.yaml и service.yaml), తర్వాత అవుట్‌పుట్ వద్ద పేర్కొన్న మార్పులతో కూడిన వచనాన్ని అందుకుంటుంది kustomization.yaml.

గమనిక. అనువాదం.: కస్టమైజ్ యొక్క “సరళమైన” ఉపయోగంపై ప్రాజెక్ట్ డాక్యుమెంటేషన్ నుండి ఇలస్ట్రేషన్

మార్పులు చేయవలసి వస్తే అవుట్‌పుట్ దారి మళ్లించబడుతుంది:

kustomize build . > custom-config.yaml

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

kustomize build . | kubectl apply -f -

కస్టమైజ్ ఫీచర్‌లను దీని ద్వారా కూడా యాక్సెస్ చేయవచ్చు kubectl -k (కుబెర్నెటెస్ వెర్షన్ 1.14 నుండి). అయితే, స్వతంత్ర kustomize ప్యాకేజీ ఇంటిగ్రేటెడ్ kubectl ప్యాకేజీ కంటే వేగంగా నవీకరించబడుతుందని గుర్తుంచుకోండి (కనీసం ఇది Kubernetes 1.15 విడుదల విషయంలో అయినా).

పాఠకులు ఇలా అడగవచ్చు: "మీరు ఫైల్‌లను నేరుగా సవరించగలిగితే ఈ సంక్లిష్టత ఎందుకు?" గొప్ప ప్రశ్న. మా ఉదాహరణలో, నిజానికి చెయ్యవచ్చు ఫైళ్లను సవరించండి deployment.yaml и service.yaml నేరుగా, కానీ వారు వేరొకరి ప్రాజెక్ట్ యొక్క ఫోర్క్ అయితే? ఫైల్‌లను నేరుగా మార్చడం వలన మూలం/మూలానికి మార్పులు చేసినప్పుడు ఫోర్క్‌ను రీబేస్ చేయడం కష్టం (అసాధ్యం కాకపోతే). kustomizeని ఉపయోగించడం వలన ఫైల్‌లో ఈ మార్పులను కేంద్రీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది kustomization.yaml, ఒరిజినల్ ఫైల్‌లను అలాగే ఉంచి, అవసరమైతే అసలు ఫైల్‌లను రీబేస్ చేయడం సులభతరం చేస్తుంది.

కస్టమైజ్ యొక్క ప్రయోజనాలు మరింత సంక్లిష్టమైన వినియోగ సందర్భాలలో స్పష్టంగా కనిపిస్తాయి. పై ఉదాహరణలో kustomization.yaml మరియు వనరులు ఒకే డైరెక్టరీలో ఉన్నాయి. ఏది ఏమైనప్పటికీ, బేస్ కాన్ఫిగరేషన్ మరియు దాని యొక్క అనేక వైవిధ్యాలు ఉన్న సందర్భాలలో వినియోగానికి కస్టమైజ్ మద్దతు ఇస్తుంది, దీనిని ఇలా కూడా పిలుస్తారు విస్తరణలు. ఉదాహరణకు, ఒక వినియోగదారు నేను ఉదాహరణగా ఉపయోగించిన nginx కోసం డిప్లాయ్‌మెంట్ మరియు సర్వీస్‌ని తీసుకోవాలని కోరుకున్నారు మరియు ఆ ఫైల్‌ల డెవలప్‌మెంట్, స్టేజింగ్ మరియు ప్రొడక్షన్ వెర్షన్‌లను (లేదా వేరియంట్‌లు) సృష్టించాలి. దీన్ని చేయడానికి, అతనికి పైన పేర్కొన్న అతివ్యాప్తులు మరియు వాస్తవానికి, ప్రాథమిక వనరులు అవసరం.

అతివ్యాప్తులు మరియు అంతర్లీన వనరుల ఆలోచనను వివరించడానికి (ఆధార వనరులు), డైరెక్టరీలు క్రింది నిర్మాణాన్ని కలిగి ఉన్నాయని అనుకుందాం:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

ఫైల్‌లో base/kustomization.yaml ఫీల్డ్‌ని ఉపయోగించే వినియోగదారులు resources kustomize చేర్చవలసిన వనరులను కేవలం ప్రకటించండి.

ప్రతి ఫైల్‌లో overlays/{dev,staging,prod}/kustomization.yaml వినియోగదారులు ఫీల్డ్‌లోని బేస్ కాన్ఫిగరేషన్‌ను సూచిస్తారు resources, ఆపై నిర్దిష్ట మార్పులను సూచించండి ఇచ్చిన పర్యావరణం. ఉదాహరణకు, ఫైల్ overlays/dev/kustomization.yaml ముందు ఇచ్చిన ఉదాహరణ లాగా ఉండవచ్చు:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ఈ సందర్భంలో ఫైల్ overlays/prod/kustomization.yaml పూర్తిగా భిన్నంగా ఉండవచ్చు:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

వినియోగదారు అమలు చేసినప్పుడు kustomize build . జాబితాలో overlays/dev, kustomize డెవలప్‌మెంట్ ఎంపికను రూపొందిస్తుంది. మీరు పరిగెత్తితే kustomize build . జాబితాలో overlays/prod - మీరు ఉత్పత్తి ఎంపికను పొందుతారు. మరియు ఇవన్నీ - అసలు ఎటువంటి మార్పులు చేయకుండా (బేస్) ఫైల్‌లు, అన్నీ డిక్లరేటివ్ మరియు నిర్ణయాత్మక మార్గంలో ఉంటాయి. మీరు బేస్ కాన్ఫిగరేషన్ మరియు ఓవర్‌లే డైరెక్టరీలను నేరుగా వెర్షన్ నియంత్రణకు అప్పగించవచ్చు, ఈ ఫైల్‌ల ఆధారంగా మీరు ఎప్పుడైనా కావలసిన కాన్ఫిగరేషన్‌ను పునరుత్పత్తి చేయవచ్చని తెలుసుకోవడం.

గమనిక. అనువాదం.: కస్టమైజ్‌లో ఓవర్‌లేలను ఉపయోగించడం గురించి ప్రాజెక్ట్ డాక్యుమెంటేషన్ నుండి ఇలస్ట్రేషన్

అనుకూలీకరించవచ్చు మరింత ఈ వ్యాసంలో కవర్ చేయబడిన దానికంటే ఎక్కువ. అయితే, ఇది మంచి పరిచయం అవుతుందని ఆశిస్తున్నాను.

అదనపు వనరులు

కస్టమైజ్ గురించి చాలా మంచి కథనాలు మరియు ప్రచురణలు ఉన్నాయి. నేను ప్రత్యేకంగా ఉపయోగకరంగా భావించిన కొన్ని ఇక్కడ ఉన్నాయి:

• కస్టమైజ్‌ని ఉపయోగించి విభిన్న పరిసరాల ఉత్పత్తి/పరీక్ష కోసం బేస్ YAML కాన్ఫిగర్‌ని మార్చండి;
• కస్టమైజ్ — కుబెర్నెట్స్‌లో టెంప్లేటింగ్ చేయడానికి సరైన మార్గం;
• అనుకూలీకరించడం ఉపయోగించి కుబెర్నెటెస్ వస్తువుల డిక్లరేటివ్ మేనేజ్‌మెంట్;
• అనుకూలీకరించుతో అప్‌స్ట్రీమ్ హెల్మ్ చార్ట్‌లను అనుకూలీకరించడం.

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

ఈ మెటీరియల్‌ని మెరుగుపరచడానికి మీకు ఏవైనా ప్రశ్నలు లేదా సూచనలు ఉంటే, నేను ఎల్లప్పుడూ అభిప్రాయానికి సిద్ధంగా ఉంటాను. మీరు నన్ను ఇక్కడ సంప్రదించవచ్చు Twitter లేదా కుబెర్నెటెస్ స్లాక్ ఛానెల్. కస్టమైజ్‌తో మీ మానిఫెస్ట్‌లను సవరించడం ఆనందించండి!

అనువాదకుని నుండి PS

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

• «కుబెర్నెట్స్‌లో నడుస్తున్న అప్లికేషన్‌ల డెవలపర్‌ల కోసం సాధనాలు";
• «కుబెర్నెటెస్ 1.14: ప్రధాన ఆవిష్కరణల అవలోకనం";
• «ఆమ్‌స్టర్‌డామ్‌లో హెల్మ్ సమ్మిట్ 2019 యొక్క ఐదు ప్రధాన ఫలితాలు";
• «కుబెర్నెట్స్ - హెల్మ్ కోసం ప్యాకేజీ మేనేజర్‌కి ఆచరణాత్మక పరిచయం".

మూలం: www.habr.com