కుబెర్నెటెస్ క్లస్టర్‌లో కాలం చెల్లిన ఫీచర్ శాఖను తొలగిస్తోంది

వందనాలు! ఫీచర్ శాఖ (అకా డిప్లాయ్ ప్రివ్యూ, రివ్యూ యాప్) - ఇది మాస్టర్ బ్రాంచ్ మాత్రమే కాకుండా, ఒక్కో ప్రత్యేక URLకి పుల్ రిక్వెస్ట్ చేసినప్పుడు. ఉత్పత్తి వాతావరణంలో కోడ్ పనిచేస్తుందో లేదో మీరు తనిఖీ చేయవచ్చు; ఇతర ప్రోగ్రామర్లు లేదా ఉత్పత్తి నిపుణులకు ఫీచర్ చూపబడుతుంది. మీరు పుల్ రిక్వెస్ట్‌లో పని చేస్తున్నప్పుడు, పాత కోడ్ కోసం ప్రతి కొత్త కమిట్ కరెంట్ డిప్లాయ్ తొలగించబడుతుంది మరియు కొత్త కోడ్ కోసం కొత్త డిప్లాయ్ రూపొందించబడుతుంది. మీరు పుల్ అభ్యర్థనను మాస్టర్ బ్రాంచ్‌లో విలీనం చేసినప్పుడు ప్రశ్నలు తలెత్తవచ్చు. మీకు ఇకపై ఫీచర్ బ్రాంచ్ అవసరం లేదు, కానీ కుబెర్నెట్స్ వనరులు ఇప్పటికీ క్లస్టర్‌లో ఉన్నాయి.

ఫీచర్ శాఖల గురించి మరింత

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

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

ఫీచర్ బ్రాంచ్ కోసం, నేమ్‌స్పేస్ దాని ఐడెంటిఫైయర్‌తో సృష్టించబడుతుంది (ఉదాహరణకు, పుల్ రిక్వెస్ట్ నంబర్) మరియు ఒక రకమైన ప్రిఫిక్స్/పోస్ట్‌ఫిక్స్ (ఉదాహరణకు, -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

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

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

ఫీచర్ బ్రాంచ్‌లను క్లస్టర్‌లో ఎలా అమలు చేయాలనే దాని గురించి మీరు చదువుకోవచ్చు ఇక్కడ и ఇక్కడ.

ప్రేరణ

నిరంతర ఏకీకరణతో ఒక సాధారణ పుల్ అభ్యర్థన జీవితచక్రాన్ని చూద్దాం (continuous integration):

1. మేము బ్రాంచ్‌కి కొత్త కమిట్‌ను పుష్ చేస్తాము.
2. బిల్డ్‌లో, లింటర్లు మరియు/లేదా పరీక్షలు అమలు చేయబడతాయి.
3. కుబెర్నెట్స్ పుల్ అభ్యర్థన కాన్ఫిగరేషన్‌లు ఫ్లైలో ఉత్పత్తి చేయబడతాయి (ఉదాహరణకు, దాని సంఖ్య పూర్తయిన టెంప్లేట్‌లో చేర్చబడుతుంది).
4. kubectl అప్లైని ఉపయోగించి, క్లస్టర్‌కు కాన్ఫిగరేషన్‌లు జోడించబడతాయి (డిప్లాయ్).
5. పుల్ అభ్యర్థన మాస్టర్ బ్రాంచ్‌లో విలీనం చేయబడింది.

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

ఎలా ఉపయోగించాలో

దిగువ ఆదేశంతో ప్రాజెక్ట్‌ను ఇన్‌స్టాల్ చేయండి:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

కింది కంటెంట్‌తో ఫైల్‌ను సృష్టించండి మరియు దీని ద్వారా ఇన్‌స్టాల్ చేయండి kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

పరామితి namespaceSubstring ఇతర నేమ్‌స్పేస్‌ల నుండి పుల్ అభ్యర్థనల కోసం నేమ్‌స్పేస్‌లను ఫిల్టర్ చేయడం అవసరం. ఉదాహరణకు, క్లస్టర్ కింది నేమ్‌స్పేస్‌లను కలిగి ఉంటే: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, అప్పుడు తొలగింపు అభ్యర్థులు ఉంటారు habr-back-end-pr-17, habr-back-end-pr-33.

పరామితి తర్వాత రోజులు వితౌట్ డిప్లాయ్ పాత నేమ్‌స్పేస్‌లను తొలగించాల్సిన అవసరం ఉంది. ఉదాహరణకు, నేమ్‌స్పేస్ సృష్టించబడితే 3 дня 1 час తిరిగి, మరియు పరామితి సూచిస్తుంది 3 дня, ఈ నేమ్‌స్పేస్ తొలగించబడుతుంది. నేమ్‌స్పేస్ సృష్టించబడితే అది కూడా వ్యతిరేక దిశలో పనిచేస్తుంది 2 дня 23 часа తిరిగి, మరియు పరామితి సూచిస్తుంది 3 дня, ఈ నేమ్‌స్పేస్ తొలగించబడదు.

మరొక పరామితి ఉంది, అన్ని నేమ్‌స్పేస్‌లను ఎంత తరచుగా స్కాన్ చేయాలి మరియు విస్తరణ లేకుండా రోజులపాటు తనిఖీ చేయాలనే దాని బాధ్యత - ప్రతి నిమిషాలు తనిఖీ చేయండి. డిఫాల్ట్‌గా ఇది సమానంగా ఉంటుంది 30 минутам.

ఎలా పని చేస్తుంది

ఆచరణలో, మీకు ఇది అవసరం:

1. డాకర్ వివిక్త వాతావరణంలో పని చేయడం కోసం.
2. మినీకుబే స్థానికంగా కుబెర్నెటీస్ క్లస్టర్‌ను పెంచుతుంది.
3. kubectl — క్లస్టర్ నిర్వహణ కోసం కమాండ్ లైన్ ఇంటర్‌ఫేస్.

మేము స్థానికంగా కుబెర్నెట్స్ క్లస్టర్‌ను పెంచుతాము:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

పేర్కొనవచ్చు kubectl డిఫాల్ట్‌గా స్థానిక క్లస్టర్‌ని ఉపయోగించండి:

$ kubectl config use-context minikube
Switched to context "minikube".

ఉత్పత్తి వాతావరణం కోసం కాన్ఫిగరేషన్‌లను డౌన్‌లోడ్ చేయండి:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

ఉత్పత్తి కాన్ఫిగరేషన్‌లు పాత నేమ్‌స్పేస్‌లను తనిఖీ చేయడానికి కాన్ఫిగర్ చేయబడినందున మరియు మా కొత్తగా పెరిగిన క్లస్టర్‌లో వాటిని కలిగి లేనందున, మేము పర్యావరణ వేరియబుల్‌ని భర్తీ చేస్తాము IS_DEBUG న true. ఈ విలువతో పరామితి afterDaysWithoutDeploy అనేది పరిగణనలోకి తీసుకోబడదు మరియు నేమ్‌స్పేస్‌లు విస్తరించకుండా రోజుల తరబడి తనిఖీ చేయబడవు, సబ్‌స్ట్రింగ్ సంభవించినందుకు మాత్రమే (-pr-).

మీరు ఆన్‌లో ఉంటే Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

మీరు ఆన్‌లో ఉంటే macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

ప్రాజెక్ట్‌ను ఇన్‌స్టాల్ చేస్తోంది:

$ kubectl apply -f stale-feature-branch-production-configs.yml

క్లస్టర్‌లో వనరు కనిపించిందని తనిఖీ చేస్తోంది StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

క్లస్టర్‌లో ఆపరేటర్ కనిపించారని మేము తనిఖీ చేస్తాము:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

మీరు దాని లాగ్‌లను చూస్తే, అది వనరులను ప్రాసెస్ చేయడానికి సిద్ధంగా ఉంది StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

మేము రెడీమేడ్‌ను ఇన్‌స్టాల్ చేస్తాము fixtures (క్లస్టర్ వనరులను మోడలింగ్ చేయడానికి సిద్ధంగా ఉన్న కాన్ఫిగరేషన్‌లు) వనరు కోసం StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

కాన్ఫిగరేషన్‌లు సబ్‌స్ట్రింగ్‌తో నేమ్‌స్పేస్‌ల కోసం శోధించాలని సూచిస్తున్నాయి -pr- ఒకసారి లోపలికి 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

ఆపరేటర్ ప్రతిస్పందించారు మరియు నేమ్‌స్పేస్‌లను తనిఖీ చేయడానికి సిద్ధంగా ఉన్నారు:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

ఇన్‌స్టాల్ చేయండి fixtures, రెండు నేమ్‌స్పేస్‌లను కలిగి ఉంది (project-pr-1, project-pr-2) మరియు వాటిని deployments, services, ingress, మరియు మొదలైనవి:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

పైన ఉన్న అన్ని వనరులు విజయవంతంగా సృష్టించబడ్డాయని మేము తనిఖీ చేస్తాము:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

మేము చేర్చినప్పటి నుండి debug, నేమ్‌స్పేస్‌లు project-pr-1 и project-pr-2, కాబట్టి పరామితిని పరిగణనలోకి తీసుకోకుండా అన్ని ఇతర వనరులను వెంటనే తొలగించవలసి ఉంటుంది afterDaysWithoutDeploy. ఇది ఆపరేటర్ లాగ్‌లలో చూడవచ్చు:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

మీరు వనరుల లభ్యతను తనిఖీ చేస్తే, అవి స్టేటస్‌లో ఉంటాయి Terminating (తొలగింపు ప్రక్రియ) లేదా ఇప్పటికే తొలగించబడింది (కమాండ్ అవుట్‌పుట్ ఖాళీగా ఉంది).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

మీరు సృష్టి ప్రక్రియను పునరావృతం చేయవచ్చు fixtures అనేక సార్లు మరియు వారు ఒక నిమిషంలో తొలగించబడ్డారని నిర్ధారించుకోండి.

ప్రత్యామ్నాయాలు

క్లస్టర్‌లో పనిచేసే ఆపరేటర్‌కు బదులుగా ఏమి చేయవచ్చు? అనేక విధానాలు ఉన్నాయి, అవన్నీ అసంపూర్ణమైనవి (మరియు వాటి లోపాలు ఆత్మాశ్రయమైనవి), మరియు ప్రతి ఒక్కరూ ఒక నిర్దిష్ట ప్రాజెక్ట్ కోసం ఏది ఉత్తమమో స్వయంగా నిర్ణయిస్తారు:

1. మాస్టర్ బ్రాంచ్ యొక్క నిరంతర ఇంటిగ్రేషన్ బిల్డ్ సమయంలో ఫీచర్ బ్రాంచ్‌ను తొలగించండి.

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

2. వెబ్‌హుక్స్ ఉపయోగించడం (ఒక ఉదాహరణ).

   • ఇది మీ విధానం కాకపోవచ్చు. ఉదాహరణకు, లో జెంకిన్స్, ఒక రకమైన పైప్‌లైన్ మాత్రమే దాని కాన్ఫిగరేషన్‌లను సోర్స్ కోడ్‌లో సేవ్ చేసే సామర్థ్యానికి మద్దతు ఇస్తుంది. వెబ్‌హూక్‌లను ఉపయోగిస్తున్నప్పుడు, వాటిని ప్రాసెస్ చేయడానికి మీరు మీ స్వంత స్క్రిప్ట్‌ను వ్రాయాలి. ఈ స్క్రిప్ట్‌ను జెంకిన్స్ ఇంటర్‌ఫేస్‌లో ఉంచాలి, ఇది నిర్వహించడం కష్టం.

3. రాయడానికి క్రోంజాబ్ మరియు కుబెర్నెట్స్ క్లస్టర్‌ను జోడించండి.

   • రచన మరియు మద్దతు కోసం సమయాన్ని వెచ్చిస్తారు.
   • ఆపరేటర్ ఇప్పటికే ఇదే శైలిలో పని చేస్తున్నారు, డాక్యుమెంట్ చేయబడింది మరియు మద్దతు ఉంది.

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

మూలం: www.habr.com