Custom Resource Definition, qisqacha CRD — Kubernetes APIga yangi resurs turini deklarativ ravishda qo‘shuvchi obyekt. Masalan, platforma Certificate, Database yoki Backup kabi domen obyektlarini standart Pod va Service singari kubectl orqali yaratish, kuzatish va ruxsat bilan boshqarish imkonini oladi. CRD faqat ma’lumot modeli va API endpointini yaratadi; resursning amaliy xatti-harakatini odatda alohida controller bajaradi.
API identifikatori
Custom resource group, version, kind va resource nomi bilan aniqlanadi. Masalan, databases.platform.example groupida v1 version, Database kind va databases plural nomi bo‘lishi mumkin. Namespaced scope obyektni namespace ichiga, Cluster scope esa butun clusterga tegishli qiladi.
spec foydalanuvchi istagan holatni ifodalaydi. status controller kuzatgan joriy holat, condition va sabablarni saqlaydi. Status uchun alohida subresource yoqilsa, controller statusni yangilaganda foydalanuvchining spec o‘zgarishini tasodifan bosib ketmaydi.
Schema
OpenAPI v3 schema maydon turi, majburiy xususiyat, enum, format va cheklovlarni belgilaydi. API server noto‘g‘ri obyektni storagega yozilishidan oldin rad etadi. Structural schema noma’lum maydonlarni pruning qilish va version conversion kabi Kubernetes imkoniyatlari uchun talab qilinadi.
spec:
group: platform.example
names:
kind: Database
plural: databases
scope: Namespaced
Schema faqat sintaksisni emas, API kontraktini ham anglatadi. Maydonni o‘chirish yoki ma’nosini o‘zgartirish mavjud manifest va controllerlarni buzishi mumkin. Default qiymat va validation qoidasi version strategiyasi bilan birga loyihalanadi.
Controller bilan ishlash
Controller custom resource hodisalarini kuzatib, actual holatni specga yaqinlashtiruvchi reconciliation loopni bajaradi. Database obyekti cloud database yaratishi, credential secretini bog‘lashi va tayyorlikni statusga yozishi mumkin. Reconcile idempotent bo‘lishi kerak, chunki bir xil obyekt qayta-qayta navbatga tushadi.
Finalizer tashqi resursni tozalash tugamaguncha custom resourceni yakuniy o‘chirishni kechiktiradi. Controller ishlamay qolsa noto‘g‘ri finalizer obyektni terminating holatida ushlab qolishi mumkin. Owner reference esa Kubernetes garbage collectorga bog‘liq ichki obyektlarni topishga yordam beradi.
Versiyalar va saqlash
CRD bir nechta served versionni ochishi, lekin faqat bittasini storage version sifatida saqlashi mumkin. Versionlar schema jihatdan farq qilsa conversion webhook bir ko‘rinishni boshqasiga aylantiradi. Yangi storage versionni belgilash eski obyektlarni avtomatik qayta yozmaydi; migratsiya alohida boshqariladi.
Boshqaruv xavflari
CRD yaratish cluster miqyosidagi huquqdir. Custom resource uchun RBAC group va resource bo‘yicha alohida belgilanadi. Juda katta status, tez-tez update yoki cheksiz obyekt soni API server va etcdga yuk beradi. Admission policy, quota va controller rate limit bu xavfni kamaytiradi.
CRDni o‘chirish unga tegishli barcha custom resourcelarni va saqlangan ma’lumotni yo‘qotishi mumkin. Shu sabab chart uninstall paytida CRDlar ko‘pincha oddiy resurslardan ehtiyotkorroq boshqariladi.
API dizayni
Custom resource implementation tafsilotini emas, foydalanuvchi istagini ifodalashi maqsadga muvofiq. Masalan, aniq Pod nomini specga majburiy yozdirish o‘rniga capacity va availability talabi beriladi, controller esa resurslarni tanlaydi. Statusdagi conditionlar type, status, reason, message va transition time bilan avtomatlashtirishga qulay bo‘ladi. Controller xatosini faqat logda qoldirish foydalanuvchiga kubectl orqali holatni tushunish imkonini bermaydi.
Printer column va scale subresource CLI hamda autoscaling integratsiyasini yaxshilaydi. Biroq har qulaylik APIning uzoq muddatli kontraktiga aylanadi. CRD schema va sample manifestlar controller kodi bilan bir repositoryda versionlanib, compatibility testi orqali tekshiriladi.
Bog‘liq tushunchalar
Kubernetes API, Custom resource, Controller, Operator, Reconciliation loop, Finalizer, Admission webhook