Hook — Helm release lifecycleining ma’lum nuqtasida maxsus Kubernetes resursini yaratishga xizmat qiladigan mexanizmdir. Hook database migration, o‘rnatishdan oldingi tekshiruv, post-upgrade ish yoki chart testini bajarishi mumkin. U oddiy templatega annotation qo‘shish orqali belgilanadi, lekin hook resursining lifecycle qoidalari release tarkibidagi odatiy resurslardan farq qiladi.
Hook turlari
helm.sh/hook annotationi bajarilish nuqtasini ko‘rsatadi. pre-install asosiy resurslar yaratilishidan oldin, post-install ulardan keyin ishlaydi. Xuddi shunday pre-upgrade, post-upgrade, pre-delete, post-delete va test turlari mavjud. Bitta resurs bir nechta vergul bilan ajratilgan turga tegishli bo‘lishi mumkin.
metadata:
annotations:
helm.sh/hook: pre-upgrade
helm.sh/hook-weight: "-5"
helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
Weight kichik sondan katta songa qarab tartibni boshqaradi. Bir xil weightli hooklar kind va nom bo‘yicha barqaror tartibda ishlanishi mumkin, ammo mantiqni tasodifiy nomlashga bog‘lash to‘g‘ri emas.
Bajarilish modeli
Helm hook manifestini render qiladi, resursni yaratadi va Job yoki Pod kabi bajariladigan tur uchun tayyor yoki tugallangan holatni kutadi. Hook failure upgrade yoki installni muvaffaqiyatsiz qilishi mumkin. –wait, –atomic va timeout tanlovi yakuniy xatti-harakatga ta’sir etadi.
Hook asosiy release resource setining oddiy a’zosi sifatida boshqarilmaydi. Uninstall paytida u avtomatik o‘chmasligi mumkin. Delete policy yoki Job TTL belgilanmasa, eski Job va loglar clusterda to‘planadi. before-hook-creation avvalgi bir xil nomli resursni yangi bajarilish oldidan olib tashlaydi.
Idempotent ishlar
Upgrade qayta urinish, rollback yoki operator amali sabab hook bir necha marta bajarilishi mumkin. Database migration joriy schema versiyasini tekshirishi va allaqachon bajarilgan bosqichni xavfsiz tanishi kerak. Faqat “bir marta ishlaydi” taxminiga tayangan script duplicate yozuv yoki yarim migratsiya qoldiradi.
Uzoq migration deployment timeoutidan oshishi mumkin. Bunday ishni release hookiga bog‘lashdan oldin lock, resume, backup va failure recovery modeli belgilanadi. Applicationning eski va yangi versiyasi migration oralig‘ida schema bilan mos ishlashi ham zarur.
Xavfsizlik va kuzatuv
Hook ko‘pincha keng RBAC huquqi yoki maxfiy credential talab qiladi. Uning ServiceAccounti faqat zarur namespace va resource verbiga cheklanadi. Chart contributor template orqali cluster-admin huquqida kod bajara olmasligi uchun chart manbasi va render natijasi review qilinadi.
Job statusi, exit code, event va log release bilan bog‘lanadi. Hook o‘chirilishidan oldin diagnostika kerak bo‘lsa log tashqi tizimga uzatiladi. Muvaffaqiyat faqat process exit code emas; bajarilgan migration yoki tekshiruvning yakuniy holati aniq o‘lchanadi.
Rollback bilan munosabat
Upgrade hooki tashqi tizimda side effect yaratgan bo‘lsa Helm rollback uning teskarisini avtomatik bajarmaydi. pre-rollback va post-rollback hooklar mavjud, lekin kompensatsiya xavfsiz va oldindan sinovdan o‘tgan bo‘lishi kerak. Data migrationni ko‘r-ko‘rona reverse qilish yangi yozuvlarni yo‘qotishi mumkin. Ba’zan backward-compatible schema saqlab, applicationni oldingi revisionga qaytarish to‘g‘riroq bo‘ladi.
Hook nomi har revisionda o‘zgarsa before-hook-creation eski Jobni topolmaydi. Deterministik nom, delete policy va TTL birgalikda resurs to‘planishini boshqaradi. Debug uchun retention kerak bo‘lsa muvaffaqiyatsiz hook va muvaffaqiyatli hook siyosati alohida tanlanadi.
Test hook release sog‘lomligini foydalanuvchi chaqiradigan amal orqali tasdiqlashi mumkin.
Bog‘liq tushunchalar
Helm, Helm chart, Kubernetes Job, Release lifecycle, Database migration, RBAC, Idempotency