🥇Kubernetes кластеріндегі ескірген мүмкіндік тармағын жою

Сәлем! Ерекшелік тармағы (алдын ала қарауды орналастыру, қолданбаны қарап шығу) - бұл тек негізгі тармақ ғана емес, сонымен қатар бірегей URL мекенжайына әрбір тарту сұрауы да орналастырылған кезде. Кодтың өндіріс ортасында жұмыс істейтінін тексеруге болады; мүмкіндікті басқа бағдарламашыларға немесе өнім мамандарына көрсетуге болады. Тарту сұрауында жұмыс істеп жатқанда, ескі код үшін әрбір жаңа қабылдау ағымдағы орналастыру жойылады және жаңа код үшін жаңа орналастыру шығарылады. Басты тармаққа тарту сұрауын біріктірген кезде сұрақтар туындауы мүмкін. Сізге енді мүмкіндік тармағы қажет емес, бірақ Kubernetes ресурстары әлі де кластерде.

Мүмкіндік тармақтары туралы толығырақ

Kubernetes-те мүмкіндік тармақтарын жасаудың бір тәсілі аттар кеңістігін пайдалану болып табылады. Қысқаша айтқанда, өндіріс конфигурациясы келесідей:

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

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

Мүмкіндік тармағы үшін аттар кеңістігі оның идентификаторымен (мысалы, тарту сұрауының нөмірі) және префикс/постфикстің қандай да бір түрімен (мысалы, -пр-):

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
...

Жалпы, мен жаздым Kubernetes операторы (кластер ресурстарына рұқсаты бар қолданба), Github сайтындағы жобаға сілтеме. Ол ескі мүмкіндік тармақтарына жататын аттар кеңістіктерін жояды. Kubernetes жүйесінде аттар кеңістігін жойсаңыз, сол аттар кеңістігіндегі басқа ресурстар да автоматты түрде жойылады.

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

Мүмкіндік тармақтарын кластерге енгізу жолы туралы оқуға болады осында и осында.

Мотивация

Үздіксіз интеграциясы бар әдеттегі тарту сұрауының өмірлік циклін қарастырайық (continuous integration):

Біз филиалға жаңа міндеттеме береміз.
Құрылымда линтерлер және/немесе сынақтар орындалады.
Kubernetes тарту сұрауының конфигурациялары жылдам жасалады (мысалы, оның нөмірі дайын үлгіге кірістіріледі).
kubectl application көмегімен конфигурациялар кластерге қосылады (орналастыру).
Тарту сұрауы негізгі тармаққа біріктірілген.

Тарту сұрауында жұмыс істеп жатқанда, ескі код үшін әрбір жаңа қабылдау ағымдағы орналастыру жойылады және жаңа код үшін жаңа орналастыру шығарылады. Бірақ тарту сұрауы негізгі тармаққа біріктірілгенде, тек негізгі тармақ құрастырылады. Нәтижесінде біз тарту сұрауын ұмытып кеткеніміз және оның Kubernetes ресурстары әлі де кластерде екені белгілі болды.

Қалай пайдалануға болады

Төмендегі пәрмен арқылы жобаны орнатыңыз:

$ 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.

Параметр afterDaysWithoutDeploy ескі аттар кеңістігін жою қажет. Мысалы, аттар кеңістігі жасалса 3 дня 1 час кері және параметр көрсетеді 3 дня, бұл аттар кеңістігі жойылады. Ол сондай-ақ аттар кеңістігі жасалса, қарама-қарсы бағытта жұмыс істейді 2 дня 23 часа кері және параметр көрсетеді 3 дня, бұл аттар кеңістігі жойылмайды.

Тағы бір параметр бар, ол барлық аттар кеңістігін қаншалықты жиі сканерлеуге және орналастырусыз күндерді тексеруге жауап береді - CheckEveryMinutes. Әдепкі бойынша ол тең 30 минутам.

Бұл қалай жұмыс істейді

Іс жүзінде сізге қажет:

Докер оқшауланған ортада жұмыс істеуге арналған.
Миникубе жергілікті жерде Кубернетес кластерін көтереді.
кубектл — кластерді басқаруға арналған командалық жол интерфейсі.

Біз жергілікті жерде Kubernetes кластерін көтереміз:

$ 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 бірнеше рет және олардың бір минут ішінде жойылғанына көз жеткізіңіз.

Баламалар

Кластерде жұмыс істейтін оператордың орнына не істеуге болады? Бірнеше тәсілдер бар, олардың барлығы жетілмеген (және олардың кемшіліктері субъективті) және әркім белгілі бір жоба үшін не жақсы екенін өзі шешеді:

Негізгі тармақты үздіксіз біріктіру құру кезінде мүмкіндік тармағын жойыңыз.
- Бұл әрекетті орындау үшін, сіз қандай тарту сұрауы жасалып жатқан міндеттемеге қатысты екенін білуіңіз керек. Мүмкіндік тармақтарының аттар кеңістігінде тарту сұрауының идентификаторы - оның нөмірі немесе тармақтың атауы болғандықтан, идентификатор әрқашан тапсырмада көрсетілуі керек.
- Негізгі филиал құрастыру сәтсіз аяқталуда. Мысалы, сізде келесі кезеңдер бар: жобаны жүктеп алу, сынақтарды орындау, жобаны құру, шығарылым жасау, хабарландырулар жіберу, соңғы тарту сұрауының мүмкіндік тармағын тазалау. Хабарландыруды жіберу кезінде құрастыру сәтсіз болса, кластердегі барлық ресурстарды қолмен жоюға тура келеді.
- Тиісті мәтінмәнсіз негізгі құрастырылымдағы мүмкіндік тармақтарын жою анық емес.
Вебхуктарды пайдалану (мысал).
- Бұл сіздің көзқарасыңыз болмауы мүмкін. Мысалы, в Дженкинс, конфигурацияларды бастапқы кодта сақтау мүмкіндігін конфигурацияның тек бір түрі ғана қолдайды. Вебхуктарды пайдаланған кезде оларды өңдеу үшін өзіңіздің сценарийіңізді жазуыңыз қажет. Бұл сценарий Дженкинс интерфейсіне орналастырылуы керек, оны сақтау қиын.
Жазыңыз Кронжоб және Kubernetes кластерін қосыңыз.
- Жазу және қолдау көрсетуге уақыт бөлу.
- Оператор қазірдің өзінде ұқсас стильде жұмыс істейді, құжатталған және қолдау көрсетіледі.

Мақалаға назар аударғаныңызға рахмет. Github сайтындағы жобаға сілтеме.

Ақпарат көзі: www.habr.com

Kubernetes кластеріндегі ескірген мүмкіндік тармағын жою

Мүмкіндік тармақтары туралы толығырақ

Мотивация

Қалай пайдалануға болады

Бұл қалай жұмыс істейді

Баламалар

пікір қалдыру Жауапты болдырмау