blog

Spring Boot Kubernetes Mijoz

NEXTREE.

• 7 min read
Spring Boot Kubernetes Mijoz

Kirish

Kubernetesni boshqarayotganda, bunday fikrlar paydo bo'lishi tabiiydir. “Hozirgi klasterda Podlar odatiy ishlayotganligini, har bir Podning holatini bir nazar bilan to'plash mumkin bo'lsa, yaxshi bo'lardi.” Dastlab bu savol oddiy qiziqish sifatida boshlanadi, lekin boshqarilayotgan serverlar soni ko'paygan sayin, har kuni takrorlanadigan operatorlarning muammosiga aylanishi mumkin.

Bunday talablarni hal qiladigan narsa Kubernetes mijoz kutubxonasi edi. Spring Boot dasturida Kubernetes klasterining holatini bevosita kuzatish va o'zgarishlarga real vaqt rejimida javob berish imkonini beruvchi kutubxona. Bu oddiygina “tashqaridan klasterni kuzatish” vositasi emas, balki dasturiy ta'minotning o'zi klasterning bir qismi bo'lib, birga nafas olishni ta'minlaydigan ko'prik vazifasini bajaradi.

Ushbu maqolada men haqiqiy loyihada Spring Boot ga Kubernetes mijozini joriy qilganimda tuzgan joriy qilish motivi, harakat qilish tamoyili, va ishga tushirish muhitida albatta ko'rib chiqish kerak bo'lgan xavfsizlikka oid e'tibor zaruratlarini tartib bilan bayon etmoqchiman.

Kirish motivi

Bu texnologiyani qidirishga sabab bo'lgan narsa operatsion avtomatlashtirish va server holatini yig'ish zaruriyatidir. Hozirda ishtirok etayotgan loyihada 100 dan ortiq server ishlamoqda va kelajakda bu son yanada ortishi kutilmoqda. Faqat raqamlar ko'paymoqda degani emas, balki bitta operatorning barcha serverlarning holatini miyasi bilan tasavvur qilishi endi mumkin bo'lmaydigan darajaga yetmoqda.

Ilgari usul bilan klaster holatini tekshirish uchun bevosita Shell ga kirish va kubectl buyruqlarini bajarish yoki ArgoCD ga alohida kirish zarurati bor edi. Kubectl get pods dan boshlash jarayoni — bu jarayonning o'zida to'qnashuvga javob berish vaqtini kamaytiradigan omil deb o'ylashim tobora kuchaymoqda.

Mavjud GitOps muhitining cheklovlari

Men Spring Boot orqali JGit yordamida GitOps muhitini o'zgartirgan edim va ArgoCD Sync'ni ishga tushirish orqali serverning ConfigMap, Deployment va boshqalar kabi pod sozlamalarini boshqarardim.

Lekin barcha serverlar bir xil muhitga ega emas va tarqatish jarayonida tarmoq yoki devor (firewall) muammolari tufayli vaqt-vaqti bilan inson xatolari yuzaga kelgan. ConfigMap'dagi bitta kalit farq qilsa yoki ma'lum bir muhitda tasvirni tortish (pull) muvaffaqiyatsiz bo'lsa, bular misolidir. Git'da o'zgarishlar to'g'ri aks etgan bo'lsa ham, klasterning haqiqiy holati har doim boshqacha bo'lishi mumkinligi bilan har safar duch kelamiz.

Buning natijalarida pod normal ravishda ishga tushmaydi yoki Pod rasm yoki ConfigMap bilan bog'liq muammolar yuzaga kelganda tezda aniqlanmaydigan holatlar ko'p uchraydi. Nihoyat, “Gitga tatbiq etilgan, lekin operatsiyaga aks etmagan” holatlarning to'planishi boshlanadi va buni hal qilish uchun operatorning qo'lda tekshirish jarayoni ko'payib boradi.

Kutilayotgan harakat

Kubernetes mijoz kutubxonasini Spring Bootga qo'llash, ilovaning o'zini klasterni faol ravishda kuzatish va g'ayrioddiy vaziyatlarga javob berishga imkon beradi. Mening kutayotgan ish harakati aniq.

  • ConfigMap o'zgarishi kutilgan tomonga muvofiq bo'lmasa, ushbu ma'lumotlarni boshqaruvchi serverga darhol xabar beradi.

  • Pod odatda muvaffaqiyatli ishlamaganida, turli muayyan holatlar tufayli triggerni ishga tushirib, xabardor qiladi.

Nihoyat, asosiy narsa inson shaxsan tekshirishi kerak bo'lgan jarayonlarni avtomatlashtirishdir, bu esa inson xatolari tufayli muammolarni oldini olishga imkon beradi. Bu shunchaki "qulaylikka" bog'liq emas, balki muammolarni aniqlashga sarflanadigan vaqtni (MTTD) qisqartirish bilan bog'liq operatsion infratuzilma ahamiyatiga ega.

Qanday ishlaydi — prinsipi

Aslida Kubernetes mijoz kutubxonasi bajaradigan ish asosiy jihatdan oddiy. kube-apiserver'ning REST API'sini dasturchilar uchun qulay qilib owraplaydigan qopqoqdir. Pod ro'yxatini so'rash uchun bitta kod qatorini yozsangiz, kutubxona ichida API Serverga HTTP GET so'rovi yuboriladi va javob Java obyektiga aylantiriladi.

Ya'ni, odatda terminalda kiritadigan kubectl get pods bilan bir xil jarayon, kutubxona chaqiruvining bitta qatori bilan o'zgaradi. Farqi shundaki, natijani inson ko'radigan matn emas, balki PodList kabi Java ob'ekti sifatida olamiz, va bu ob'ektni to'g'ridan-to'g'ri biznes mantiqiga uzatishimiz mumkin.

API Server ulanish ma'lumotlari qayerdan keladi?

Bu yerda savol tug'iladi. “API Serverning manzili yoki autentifikatsiya ma'lumotlarini ishlab chiquvchi to'g'ridan-to'g'ri sozlashi kerakmi?” Javobi ‘yo'q’. Ilova Kubernetes klasteridagi Podga tarqatilganda, ya'ni bir xil klaster ichida bajarilganda, Kubernetes zarur barcha ulanish ma'lumotlarini avtomatik ravishda kiritadi.

Aniqrog'i, quyidagi uchta narsa avtomatik ravishda tayyorlanadi. API Serverning IP manzili KUBERNETES_SERVICE_HOST va KUBERNETES_SERVICE_PORT deb nomlanuvchi muhit o'zgaruvchilari orqali kiritiladi. Mijoz kutubxonasi bu ma'lumotlarni o'z-o'zidan o'qiydi va ulanishni tashkil qiladi, shuning uchun ishlab chiquvchi nuqtai nazaridan aslida quyidagi bitta qator bilan sozlash tugaydi.

ApiClient mijoz = new KubernetesClientBuilder().build();

Bu bir qatorning imkoniyati shundaki, kutubxona “Men hozirda klaster ichidamimanmi?” savolini avtomatik ravishda hal qiladi va agar ichida bo'lsa, ichki-klaster sozlamalarini, aks holda esa ~/.kube/config kontekstini foydalanib ulanishni tashkil etadi. Mahalliy ishlab chiqish muhitida va ishga tushirish muhitida bir xil kodning ishlashining sababi shunda.

Hozirgi o'zgarishlarni aniqlash — Watch va Informer

Hozirgi o'zgarishlarni aniqlashni qo'llab-quvvatlaydi. Oddiy so'rovdan tashqari, Watch deb nomlangan funksiyani ishlatganda, HTTP oqim usuli orqali klasterning voqealarini real vaqt rejimida qabul qilish mumkin. Pod qo'shilganda yoki o'chirilganda, ConfigMap yangilanganda darhol javob beradigan mantiqni amalga oshirish mumkin.

Watch asosan uzoq davom etuvchi HTTP ulanishidir. Bir marta so'rov yuborilganida, ulanish saqlanib qoladi va hodisalar sodir bo'lganida JSON qatorlari bo'yicha ma'lumotlar oqib keladi. Shuning uchun Spring Bootda ishlatilganda, alohida ip yoki asinxron kontekstda ishlatish odatiy holdir.

Ishlab chiqarish muhitida bu yerda bir qadam oldinga boradigan Informer naqshidan foydalaniladi. Informer dastlab List API orqali to'liq holatini olib, keyin Watch orqali o'zgarishlarni qabul qilib, mahalliy keshni saqlaydi. Ya'ni doimo “klasterning eng so'nggi holati” ga yaqin bo'lgan suratni xotirada saqlaydi va so'rovlar API Serverga borishmagan holda, to'g'ridan-to'g'ri keshdan javob oladi.

Ushbu tuzilmaning afzalliklari ikkita. Birinchidan, API serverga bo'ladigan yukni sezilarli darajada kamaytirish mumkin. Ikkinchidan, har doim eng so'nggi holatini tezda ko'rish mumkin. Biznes mantiqidan qaraganda, “Pod ro'yxatini ber” deb so'raganingizda, Informer keshdan darhol javob qaytaradi.

Xulosa qilib aytganda, Bir martalik sinxronlashuv → REST chaqiruv, Oddiy o'zgarishlarni aniqlash → Watch, Operatsion holatini kuzatish → Informer Uchta foydalanish namunalarini vaziyatga moslab tanlashingiz mumkin.

Mijozlarning hayot tsiklini boshqarish

KubernetesClient obyekti ichida HTTP ulanishlar havzasi saqlanadi, shuning uchun har bir so'rovda yangi yaratish va ishlatish samarali emas. Men @Configuration sinfida yakka bo'lib ro'yxatdan o'tkazdim va dastur tugatish vaqtida close() chaqirilishi uchun @PreDestroy yoki DisposableBeanni birga amalga oshirdim. Bu kichik farq yig'ilganda ulanishlarni yo'qotish va zombi iplarning sababi bo'lishi mumkin, shuning uchun dastlab struktura yaratishda e'tibor berish yaxshidir.

Xavfsizlik jihatidan e'tibor berish kerak bo'lgan jihatlar

Qulaylik darajasi yuqori bo'lsa ham, noto'g'ri ishlatilganda uning ta'siri katta bo'lishi mumkinligini boshlanishidan anglash kerak. Ishlab chiqarish muhiti bo'yicha eng ko'p uchraydigan xatolar va ularni oldini olish uchun minimal qo'llanma orqali tartibga solishni taklif etdim.

RBAC

Engashayotgan eng keng tarqalgan xato – ilovaga ortiqcha huquqlar berishdir. RBAC (Rolga asoslangan kirish boshqaruvi) sozlamalarini tashkil etishda tez rivojlanayotganingizda, barcha huquqlarni ruxsat berish yoki cluster-admin rolini shunchaki bog'lash holatlari bo'ladi. Rivojlanish bosqichida “avval ishlashini ko‘raylik” degan fikr bilan davom etish oson, lekin bu sozlamaning bevosita ishlashga o‘tishi kutilganidan ko‘proq sodir bo‘ladi.

Bu bilan Pod o'g'irlangan taqdirda hujumchining klasterga to'liq kirishiga olib keladigan jiddiy vaziyat yuzaga kelishi mumkin. Kontainer tasvirlaridagi xavfsizlik zaifliklari, bog'lanish kutubxonalari RCE yoki oddiy SSRF voqeasi butun klasterning buzilishiga olib kelishi mumkin.

Amalga oshirilishi kerak bo'lgan resurslar va harakatlar (get, list, watch) faqat aniq ruxsat berilishi va imkon qadar ClusterRole'dan ko'ra ma'lum bir nomli joyga qo'llaniladigan Role'den foydalanish tavsiya etiladi. Har bir yangi funksiyani qo'shganingizda, "Bu funktsiyaga haqiqatan ham qo'shimcha ruxsatlar kerakmi?" degan savolni avval berish odati eng kuchli mudofaa chizig'ini tashkil qiladi.

ServiceAccount tokenlarini boshqarish

ServiceAccount tokenlarini boshqarishda ehtiyot bo'lish kerak. Asosan Kubernetes har bir Podga ServiceAccount tokenlarini avtomatik ravishda o'rnatadi. Bu, Kubernetes APIga muhtoj bo'lmagan Podlar ham tokenlarni o'rnatilishiga olib kelishini anglatadi. Ya'ni, klaster ichidagi har bir Pod potentsial kirish nuqtasi bo'lishi mumkin.

Buni oldini olish uchun API ga kirish talab qilinmaydigan Pod uchun automountServiceAccountToken: false sozlamasini aniq qo'shish orqali ortiqcha tokenlarning oshkor bo'lishini oldini olish zarur. Bu, ServiceAccount darajasida ham, Pod spesifikatsiyasi darajasida ham sozlanishi mumkin, shuning uchun imkon qadar ikkalasini ham qo'llab-quvvatlash tavsiya etiladi.

Tashakkur jurnal va xabarnoma

Oxirgi marta, huquqni o'zini nazorat qilishdan tashqari “kim nima qilganini” yozib qo'yish ham muhimdir. Kubernetes audit log funksiyasini standart taqdim etadi, shuning uchun bizning ilovamizdan foydalanuvchi ServiceAccount ni maqsadli doiradan tashqarida chaqiruvlarni amalga oshirishini muntazam tekshirish jarayonini operatsion rutinga kiritish yaxshi bo'ladi. Huquq bir marta o'rnatilib qolishi emas, balki tekshirish va qaytadan ko'rib chiqish ham birga bo'lishi kerak va shunda u haqiqatan ham ma'noga ega bo'ladi.

Xulosa

Kubernetes mijozini Spring Boot-da ishlatish, ilovaning faqat klaster ustida ishlashini bosqichdan olib, klasterni faol ravishda tan olish va foydalanish darajasiga ko'tarilishidir. Oldin, «platforma buni o'z-o'zidan qilishiga ishonardik» deb, tashqariga topshirilgan operatsiyaning bir qismini ilova kodiga olib kelib, birga mas'uliyatni olish shakliga aylanadi.

Avtomatlashtirilgan operatsion vositalar yoki platformalar yaratishda kuchli tanlov bo'lib, lekin noto'g'ri ishlatilganda xavfsizlik xavflari ham katta, shuning uchun ruxsatlarni o'rnatinganda ehtiyotkorlik bilan yondoshish yaxshidir. Quvvat ta'minlangan bo'lsa, asosiy sozlamalar va sozlama tekshiruvlariga e'tibor berish muhim deb o'ylayman.

Shaxsiy ravishda, ushbu kiritish orqali eng katta olgan narsam, "ilovalar va infratuzilma chegaralari tobora noaniq bo'lib bormoqda" degan his. Oldin infratuzilma jamoasi hududi deb o'ylagan klaster holatini kuzatish endi bizning xizmat kodimizning bir qismi bo'lib, tabiiy ravishda ko'rib chiqilishi kerak. Va bu o'zgarish, operator uchun tezroq javob berishga, foydalanuvchi uchun esa qisqaroq nosozlik vaqtiga olib keladi.

Manba materiallar

Bang

Site footer