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

Функция бутагы үчүн аттар мейкиндиги анын идентификатору (мисалы, тартуу сурамынын номери) жана кандайдыр бир префикс/постфикс (мисалы, -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
...

Жалпысынан мен жаздым 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 колдонмосун колдонуу менен конфигурациялар кластерге кошулат (жайгаштыруу).
Тартуу өтүнүчү башкы бутакка бириктирилген.

Сиз тартуу сурамында иштеп жатканыңызда, эски код үчүн ар бир жаңы ишке киргизүү учурдагы жайылтуу өчүрүлөт жана жаңы код үчүн жаңы жайылтуу чыгарылат. Бирок тартуу өтүнүчү башкы бутакка бириктирилгенде, башкы бутак гана курулат. Натыйжада, биз тартуу өтүнүчүн унутуп калганбыз жана анын 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 минутам.

Бул кандай иштейт

Иш жүзүндө, сизге керек болот:

ютуб обочолонгон чөйрөдө иштөө үчүн.
Minikube жергиликтүү түрдө Kubernetes кластерин көтөрөт.
kubectl — кластерди башкаруу үчүн буйрук сабынын интерфейси.

Биз жергиликтүү түрдө 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 бир нече жолу жана алар бир мүнөттүн ичинде жок кылынышы керек.

ыкмалар

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

Мастер бутагын үзгүлтүксүз интеграциялоо учурунда функция бутагын жок кылыңыз.
- Бул үчүн, сиз кайсы тартуу өтүнүчү курулуп жаткан милдеттенмеге тиешелүү экенин билишиңиз керек. Функция бутагынын аталыш мейкиндиги тартуу сурамынын идентификаторун - анын номерин же филиалдын аталышын камтыгандыктан, идентификатор дайыма тапшырмада көрсөтүлүшү керек.
- Мастер филиалдын курулуштары ишке ашпай жатат. Мисалы, сизде төмөнкү этаптар бар: долбоорду жүктөө, тесттерди жүргүзүү, долбоорду куруу, чыгаруу, билдирүүлөрдү жөнөтүү, акыркы тартуу өтүнүчүнүн өзгөчөлүк бутагын тазалоо. Эскертмени жөнөтүүдө куруу ишке ашпай калса, кластердеги бардык ресурстарды кол менен жок кылышыңыз керек болот.
- Тийиштүү контекстсиз, мастер түзүүдө функция бутактарын жок кылуу ачык-айкын эмес.
Вебхуктарды колдонуу (мисал).
- Бул сиздин мамилеңиз эмес болушу мүмкүн. Мисалы, в Jenkins, түтүктүн бир гана түрү өзүнүн конфигурацияларын баштапкы коддо сактоо мүмкүнчүлүгүн колдойт. Вебхуктарды колдонууда сиз аларды иштетүү үчүн өзүңүздүн скриптиңизди жазышыңыз керек. Бул скрипт Дженкинс интерфейсине жайгаштырылышы керек, аны сактоо кыйын.
Билдирүү жазыңыз Мурунку иш жана Kubernetes кластерин кошуңуз.
- Жазууга жана колдоого убакыт бөлүү.
- Оператор буга чейин окшош стилде иштейт, документтештирилет жана колдоого алынат.

Макалага көңүл бурганыңыз үчүн рахмат. Github боюнча долбоорго шилтеме.

Source: www.habr.com

Kubernetes кластериндеги эскирген функция бутагын алып салуу

Өзгөчөлүк бутактары жөнүндө көбүрөөк

жөнүн көрсөтүү

Кантип пайдалануу керек

Бул кандай иштейт

ыкмалар

Комментарий кошуу жокко жооп