புரோஹோஸ்டர் > Блог > நிர்வாகம் > குபெர்னெட்ஸ் கிளஸ்டரில் உள்ள காலாவதியான அம்சக் கிளையை அகற்றுதல்

குபெர்னெட்ஸ் கிளஸ்டரில் உள்ள காலாவதியான அம்சக் கிளையை அகற்றுதல்

குபெர்னெட்ஸ் கிளஸ்டரில் உள்ள காலாவதியான அம்சக் கிளையை அகற்றுதல்

வாழ்த்துக்கள்! அம்ச கிளை (அதாவது வரிசைப்படுத்து முன்னோட்டம், மறுஆய்வு பயன்பாடு) - இது முதன்மைக் கிளை மட்டும் பயன்படுத்தப்படும் போது, ​​ஆனால் ஒரு தனிப்பட்ட 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 applyஐப் பயன்படுத்தி, க்ளஸ்டரில் உள்ளமைவுகள் சேர்க்கப்படுகின்றன (வரிசைப்படுத்தல்).
  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.

அளவுரு பிறகுDays WithoutDeploy பழைய பெயர்வெளிகளை நீக்க வேண்டும். எடுத்துக்காட்டாக, பெயர்வெளி உருவாக்கப்பட்டால் 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

கருத்தைச் சேர்