ConfigMap — Kubernetes’da maxfiy bo‘lmagan konfiguratsiya ma’lumotlarini workload kodidan va container image’dan ajratib saqlaydigan API obyekti. Unda kalit-qiymat juftliklari yoki konfiguratsiya fayliga o‘xshash matn bloklari bo‘ladi. Pod ConfigMap ma’lumotini environment variable, command argumenti yoki volume ichidagi fayl sifatida olishi mumkin.
Konfiguratsiyani ajratish
Image bir marta qurilib, development, test va production muhitlarida turli ConfigMap bilan ishlatiladi. Bu muhit nomi, feature flag, endpoint yoki log darajasini image’ni qayta qurmasdan o‘zgartirishga imkon beradi. Konfiguratsiya application versiyasi bilan mos kelishi kerak; ixtiyoriy qiymatlarni runtime’da almashtirish har doim xavfsiz emas.
apiVersion: v1
kind: ConfigMap
metadata:
name: catalog-config
data:
LOG_LEVEL: info
app.yaml: |
cache_ttl: 300
locale: uz-UZ
data maydonidagi qiymatlar UTF-8 matn ko‘rinishida saqlanadi. Binary ma’lumot uchun binaryData ishlatilishi mumkin, ammo katta artefakt yoki media fayl ConfigMap uchun mos emas.
Podga ulash usullari
| Usul | Xususiyati |
|---|---|
env |
Bitta kalitni environment variable qiladi |
envFrom |
Barcha mos kalitlarni environmentga chiqaradi |
| Volume | Kalitlarni fayl nomi sifatida mount qiladi |
| Argument | Environment yoki template orqali commandga uzatadi |
Environment variable process boshlanganda olinadi; ConfigMap keyin o‘zgarsa ishlab turgan process qiymati yangilanmaydi. Volume orqali berilgan fayllar kubelet sinxronlashidan keyin yangilanishi mumkin, ammo application faylni qayta o‘qimasa yangi konfiguratsiya ta’sir qilmaydi.
subPath orqali bitta fayl mount qilinganda avtomatik yangilanish xatti-harakati oddiy ConfigMap volume’dan farq qilishi mumkin. Platforma versiyasi hujjati shu sabab tekshiriladi.
Yangilash va rollout
Konfiguratsiya o‘zgarishi pod restartini talab qilsa, Deployment pod template annotation’iga ConfigMap hash’i yoziladi. Hash o‘zgarganda yangi ReplicaSet va rolling rollout boshlanadi. Bu qaysi pod qaysi konfiguratsiya bilan ishlayotganini aniq qiladi.
Immutable ConfigMap yangilanishni taqiqlaydi. Yangi nom, masalan catalog-config-v3, yaratiladi va workload reference’i almashtiriladi. Immutable obyekt tasodifiy tahrirni hamda control plane’dagi watch yukini kamaytirishi mumkin.
Nomlash va versiyalash
Bitta umumiy ConfigMap’ga o‘nlab mustaqil xizmat konfiguratsiyasini joylash coupling hosil qiladi. Har workload yoki mantiqiy konfiguratsiya to‘plamiga alohida obyekt beriladi. Namespace ConfigMap ko‘rinish chegarasini belgilaydi; pod odatda boshqa namespace’dagi ConfigMap’ni to‘g‘ridan-to‘g‘ri reference qilmaydi.
Manifest Git’da versiyalansa review va rollback osonlashadi. Lekin runtime’da operator qo‘lda o‘zgartirsa Git desired state bilan cluster holati orasida drift paydo bo‘ladi. GitOps controller bunday farqni qaytarishi mumkin.
Xavfsizlik chegarasi
ConfigMap Secret o‘rnini bosmaydi. Parol, API token, private key yoki boshqa maxfiy qiymat ConfigMap’da saqlanmaydi. Kubernetes API’dan ConfigMap o‘qish huquqi bo‘lgan foydalanuvchi uning barcha mazmunini ko‘rishi mumkin; environment va mounted fayl ham pod ichida ochiq bo‘ladi.
Maxfiy bo‘lmagan konfiguratsiyada ham ichki endpoint yoki feature flag operatsion ma’lumot hisoblanishi mumkin. RBAC faqat kerakli service account’ga access beradi, audit log esa kim o‘zgartirganini qayd etadi.
Validatsiya
Kubernetes ConfigMap qiymatining application uchun semantik to‘g‘riligini bilmaydi. cache_ttl: abc API tomonidan qabul qilinishi, lekin ilova boshlanmasligi mumkin. Application startup’da schema, type, range va majburiy kalitlarni tekshiradi; xato bo‘lsa tushunarli diagnostika beradi.
Admission policy ayrim umumiy qoidalarni tekshirishi mumkin, ammo xizmatga xos validatsiya CI yoki applicationda qoladi. Konfiguratsiya o‘zgarishi staging va canary orqali tekshirilsa katta rolloutdagi xato kamayadi.
Bog‘liq tushunchalar
Kubernetes, Secret, Pod, Environment variable, Volume, Deployment, GitOps