ProHoster > Блог > Захиргаа > Kubernetes кластер дахь хуучирсан функцийн салбарыг устгана уу

Kubernetes кластер дахь хуучирсан функцийн салбарыг устгана уу

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):

  1. Бид салбар руу шинэ амлалт өгдөг.
  2. Барилга дээр линтер ба/эсвэл туршилтыг явуулдаг.
  3. Kubernetes татах хүсэлтийн тохиргоо нь шууд үүсдэг (жишээлбэл, түүний дугаарыг бэлэн загварт орлуулсан).
  4. kubectl application-ийг ашигласнаар тохиргоонууд нь кластерт ордог (байршуулдаг).
  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.

Үзүүлэлт afterDaysWithoutDeploy хуучин нэрийн зайг арилгах шаардлагатай. Жишээлбэл, хэрэв нэрийн орон зай үүссэн бол 3 дня 1 час буцах ба параметрийг зааж өгнө 3 дня, энэ нэрийн зайг устгах болно. Нэрийн орон зай үүсгэсэн тохиолдолд эсрэгээр ажиллана 2 дня 23 часа буцах ба параметрийг зааж өгнө 3 дня, энэ нэрийн зайг арилгахгүй.

Өөр нэг параметр байна, энэ нь бүх нэрийн зайг хэр олон удаа сканнердаж, байршуулахгүйгээр хэдэн хоног шалгахыг хариуцдаг - CheckEveryMinutes. Анхдагчаар энэ нь тэнцүү байна 30 минутам.

Яаж энэ ажлыг хийдэг

Практикт танд хэрэгтэй болно:

  1. Docker тусгаарлагдсан орчинд ажиллах.
  2. Миникубе орон нутагт Kubernetes кластерийг өсгөх болно.
  3. кубектл - кластер удирдах командын мөрийн интерфейс.

Бид Кубернетес кластерыг орон нутагтаа өсгөдөг:

$ 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. Webhook ашиглах (жишээ нь).

    • Магадгүй энэ нь таны хандлага биш юм. Жишээлбэл, in Jenkins, зөвхөн нэг төрлийн дамжуулах хоолой нь тохиргоогоо эх кодонд хадгалах боломжийг дэмждэг. Webhook-г ашиглахдаа тэдгээрийг боловсруулахын тулд та өөрөө скрипт бичих хэрэгтэй. Энэ скриптийг арчлахад хэцүү Женкинсийн интерфейс дээр байрлуулах шаардлагатай болно.

  3. Бичих cronjob болон Kubernetes кластер нэмнэ.

    • Бичих, хадгалахад зарцуулсан цаг.
    • Оператор нь ижил төстэй хэв маягаар ажилладаг, баримтжуулсан, дэмжигдсэн байдаг.

Нийтлэлд анхаарлаа хандуулсанд баярлалаа. Github дээрх төслийн холбоос.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх