Internetda (xizmat tarmog'i) va bu erda yana biri. Xayr! Lekin nega? Keyin, men o'z fikrimni bildirmoqchiman, agar xizmat ko'rsatish tarmoqlari 10 yil oldin, Docker va Kubernetes kabi konteyner platformalari paydo bo'lishidan oldin paydo bo'lsa yaxshi bo'lar edi. Mening nuqtai nazarim boshqalarga qaraganda yaxshiroq yoki yomonroq deb aytmayapman, lekin xizmat ko'rsatish tarmoqlari juda murakkab hayvonlar bo'lgani uchun, bir nechta nuqtai nazar ularni yaxshiroq tushunishga yordam beradi.
Men dotCloud platformasi haqida gapiraman, u yuzdan ortiq mikroservislar asosida qurilgan va minglab konteynerlashtirilgan ilovalarni qo'llab-quvvatlaydi. Men uni ishlab chiqish va ishga tushirishda qanday qiyinchiliklarga duch kelganimizni va xizmat tarmoqlari qanday yordam berishi mumkinligini (yoki yordam bera olmasligini) tushuntirib beraman.
DotCloud tarixi
Men dotCloud tarixi va ushbu platforma uchun arxitektura tanlovlari haqida yozganman, lekin tarmoq qatlami haqida ko'p gapirmadim. Agar siz o'qishga sho'ng'ishni xohlamasangiz dotCloud haqida qisqacha ma'lumot: bu PaaS platformasi-xizmat bo'lib, mijozlarga keng ko'lamli ma'lumotlarni qo'llab-quvvatlaydigan keng doiradagi ilovalarni (Java, PHP, Python...) ishga tushirish imkonini beradi. xizmatlar (MongoDB, MySQL, Redis...) va Heroku kabi ish jarayoni: Siz kodingizni platformaga yuklaysiz, u konteyner tasvirlarini yaratadi va ularni joylashtiradi.
Men sizga trafik dotCloud platformasiga qanday yo'naltirilganligini aytib beraman. Bu juda zo'r bo'lgani uchun emas (garchi tizim o'z vaqtida yaxshi ishlagan bo'lsa-da!), lekin birinchi navbatda, zamonaviy vositalar yordamida bunday dizaynni kamtarona jamoa qisqa vaqt ichida osonlik bilan amalga oshirishi mumkin, agar ularga bir guruh o'rtasida trafikni yo'naltirish usuli kerak bo'lsa. mikroservislar yoki bir qator ilovalar. Shunday qilib, siz variantlarni solishtirishingiz mumkin: agar siz hamma narsani o'zingiz ishlab chiqsangiz yoki mavjud xizmat ko'rsatish tarmog'idan foydalansangiz nima bo'ladi. Standart tanlov - uni o'zingiz qilish yoki sotib olish.
Xostlangan ilovalar uchun trafikni yo'naltirish
DotCloud-dagi ilovalar HTTP va TCP so'nggi nuqtalarini ochishi mumkin.
HTTP so'nggi nuqtalari yuk muvozanatlashtiruvchi klaster konfiguratsiyasiga dinamik ravishda qo'shilgan . Bu bugungi kunda resurslar nima qilayotganiga o'xshaydi Kubernetes va shunga o'xshash yuk balanslagichida .
Mijozlar HTTP so'nggi nuqtalariga tegishli domenlar orqali ulanadi, agar domen nomi dotCloud yuk balanslagichlariga ishora qilsa. Hech qanday maxsus narsa yo'q.
TCP so'nggi nuqtalari port raqami bilan bog'langan bo'lib, u keyinchalik muhit o'zgaruvchilari orqali o'sha stekdagi barcha konteynerlarga uzatiladi.
Mijozlar TCP so'nggi nuqtalariga tegishli xost nomi (masalan, gateway-X.dotcloud.com) va port raqami yordamida ulanishi mumkin.
Ushbu xost nomi "nats" server klasteriga (.ga aloqador emas) hal qilinadi ), bu kiruvchi TCP ulanishlarini to'g'ri konteynerga yo'naltiradi (yoki yuk balanslangan xizmatlarda to'g'ri konteynerlarga).
Agar siz Kubernetes bilan tanish bo'lsangiz, bu sizga Xizmatlarni eslatishi mumkin .
DotCloud platformasida shunga o'xshash xizmatlar yo'q edi : Oddiylik uchun xizmatlarga platformaning ichidan ham, tashqarisidan ham bir xil tarzda kirish mumkin edi.
Hammasi juda sodda tarzda tashkil etilgan: HTTP va TCP marshrutlash tarmoqlarining dastlabki ilovalari, ehtimol, har biri Python-ning bir necha yuz satrlari edi. Platforma o'sishi va qo'shimcha talablar paydo bo'lishi bilan takomillashtirilgan oddiy (men sodda deb aytaman) algoritmlar.
Mavjud kodni keng qamrovli refaktoring talab qilinmadi. Ayniqsa, muhit o'zgaruvchilari orqali olingan manzildan bevosita foydalanishi mumkin.
Bu zamonaviy xizmat ko'rsatish tarmog'idan qanday farq qiladi?
Cheklangan ko'rinish. Bizda TCP marshrutlash tarmog'i uchun hech qanday ko'rsatkichlar umuman yo'q edi. HTTP marshrutlash haqida gap ketganda, keyingi versiyalar xato kodlari va javob vaqtlari bilan batafsil HTTP ko'rsatkichlarini taqdim etdi, ammo zamonaviy xizmat ko'rsatish tarmoqlari, masalan, Prometey kabi o'lchovlarni yig'ish tizimlari bilan integratsiyani ta'minlovchi yanada uzoqroqqa boradi.
Ko'rinish nafaqat operatsion nuqtai nazardan (muammolarni bartaraf etishda yordam berish uchun), balki yangi xususiyatlarni chiqarishda ham muhimdir. Bu xavfsiz haqida и .
Marshrutlash samaradorligi ham cheklangan. DotCloud marshrutlash tarmog'ida barcha trafik maxsus marshrutlash tugunlari klasteridan o'tishi kerak edi. Bu potentsial ravishda bir nechta AZ (Mavjudlik zonasi) chegaralarini kesib o'tishni va kechikishni sezilarli darajada oshirishni anglatardi. Men har bir sahifada yuzdan ortiq SQL so'rovlarini amalga oshiruvchi va har bir so'rov uchun SQL serveriga yangi ulanishni ochadigan muammolarni bartaraf etish kodini eslayman. Mahalliy ishlayotganda sahifa bir zumda yuklanadi, lekin dotCloud-da yuklash uchun bir necha soniya kerak bo'ladi, chunki har bir TCP ulanishi (va keyingi SQL so'rovi) o'nlab millisekundlarni oladi. Bunday holda, doimiy ulanishlar muammoni hal qildi.
Zamonaviy xizmat ko'rsatish tarmoqlari bunday muammolarni hal qilishda yaxshiroqdir. Avvalo, ular ulanishlarning yo'naltirilganligini tekshiradilar manbada. Mantiqiy oqim bir xil: клиент → меш → сервис, lekin endi mash mahalliy ishlaydi va uzoq tugunlarda emas, shuning uchun ulanish клиент → меш mahalliy va juda tez (millisekundlar o'rniga mikrosoniyalar).
Zamonaviy xizmat ko'rsatish tarmoqlari, shuningdek, yukni muvozanatlashning aqlli algoritmlarini amalga oshiradi. Backendlarning sog'lig'ini kuzatish orqali ular tezroq backendlarga ko'proq trafik jo'natishlari mumkin, natijada umumiy ishlash yaxshilanadi.
Xavfsizlik ham yaxshiroq. DotCloud marshrutlash tarmog'i to'liq EC2 Classic-da ishladi va trafikni shifrlamadi (agar kimdir EC2 tarmoq trafigiga sniffer qo'yishga muvaffaq bo'lsa, siz allaqachon katta muammoga duch kelgansiz degan taxminga asoslanadi). Zamonaviy xizmat ko'rsatish tarmoqlari bizning barcha trafikimizni shaffof himoya qiladi, masalan, o'zaro TLS autentifikatsiyasi va keyingi shifrlash.
Platforma xizmatlari uchun trafikni yo'naltirish
OK, biz ilovalar orasidagi trafikni muhokama qildik, lekin dotCloud platformasining o'zi haqida nima deyish mumkin?
Platformaning o'zi turli funktsiyalar uchun mas'ul bo'lgan yuzga yaqin mikroservislardan iborat edi. Ba'zilari boshqalarning so'rovlarini qabul qildilar, ba'zilari esa boshqa xizmatlarga ulangan, ammo ulanishlarni o'zlari qabul qilmagan fon ishchilari edi. Har qanday holatda, har bir xizmat ulanishi kerak bo'lgan manzillarning so'nggi nuqtalarini bilishi kerak.
Ko'pgina yuqori darajadagi xizmatlar yuqorida tavsiflangan marshrutlash tarmog'idan foydalanishi mumkin. Aslida, dotCloud-ning yuzdan ortiq mikroxizmatlarining aksariyati dotCloud platformasining o'zida oddiy ilovalar sifatida joylashtirilgan. Ammo kam sonli past darajadagi xizmatlar (ayniqsa, ushbu marshrutlash tarmog'ini amalga oshiradiganlar) kamroq bog'liqliklar bilan oddiyroq narsaga muhtoj edilar (chunki ular ishlash uchun o'zlariga bog'liq bo'lolmaydilar - yaxshi eski tovuq va tuxum muammosi).
Ushbu past darajadagi, muhim vazifalarni bajaradigan xizmatlar to'g'ridan-to'g'ri bir nechta asosiy tugunlarda konteynerlarni ishga tushirish orqali o'rnatildi. Bunday holda standart platforma xizmatlaridan foydalanilmadi: bog'lovchi, rejalashtiruvchi va yuguruvchi. Agar siz zamonaviy konteyner platformalari bilan solishtirmoqchi bo'lsangiz, bu boshqaruv samolyotini boshqarishga o'xshaydi docker run vazifani Kubernetesga topshirish o'rniga, to'g'ridan-to'g'ri tugunlarda. Bu kontseptsiyada juda o'xshash , u foydalanadi yoki mustaqil klasterni yuklashda.
Ushbu xizmatlar oddiy va qo'pol tarzda oshkor qilingan: YAML faylida ularning nomlari va manzillari ko'rsatilgan; va har bir mijoz tarqatish uchun ushbu YAML faylining nusxasini olishi kerak edi.
Bir tomondan, bu juda ishonchli, chunki u Zookeeper kabi tashqi kalit/qiymat do'konini qo'llab-quvvatlashni talab qilmaydi (esda tuting, etcd yoki Konsul o'sha paytda mavjud emas edi). Boshqa tomondan, bu xizmatlarni ko'chirishni qiyinlashtirdi. Har safar ko'chirish amalga oshirilganda, barcha mijozlar yangilangan YAML faylini oladi (va potentsial qayta ishga tushirish). Juda qulay emas!
Keyinchalik, biz har bir mijoz mahalliy proksi-serverga ulangan yangi sxemani amalga oshirishni boshladik. Manzil va port o'rniga u faqat xizmatning port raqamini bilishi va u orqali ulanishi kerak localhost. Mahalliy proksi-server bu ulanishni boshqaradi va uni haqiqiy serverga uzatadi. Endi, orqa qismni boshqa mashinaga ko'chirish yoki masshtablashda, barcha mijozlarni yangilash o'rniga, faqat ushbu barcha mahalliy proksi-serverlarni yangilashingiz kerak; va qayta ishga tushirish endi talab qilinmaydi.
(Shuningdek, TLS ulanishlarida trafikni inkapsulyatsiya qilish va qabul qiluvchi tomonga boshqa proksi-serverni qo'yish, shuningdek, faqat ulanishlarni qabul qilish uchun sozlangan qabul qiluvchi xizmat ishtirokisiz TLS sertifikatlarini tekshirish rejalashtirilgan edi. localhost. Bu haqda keyinroq).
Bu juda o'xshash Airbnb dan, ammo muhim farq shundaki, SmartStack ishlab chiqarishga joriy qilingan va joylashtirilgan, dotCloud Docker bo'lganda dotCloud ichki marshrutlash tizimi to'xtatilgan.
Men shaxsan SmartStack-ni Istio, Linkerd va Consul Connect kabi tizimlarning o'tmishdoshlaridan biri deb hisoblayman, chunki ularning barchasi bir xil naqshga amal qiladi:
- Har bir tugunda proksi-serverni ishga tushiring.
- Mijozlar proksi-serverga ulanadi.
- Boshqaruv tekisligi proksi-server konfiguratsiyasini orqa uchlari o'zgarganda yangilaydi.
- ... Foyda!
Xizmat ko'rsatish tarmog'ining zamonaviy amalga oshirilishi
Agar bugungi kunda shunga o'xshash tarmoqni amalga oshirish kerak bo'lsa, biz shunga o'xshash printsiplardan foydalanishimiz mumkin. Masalan, xizmat nomlarini bo'sh joydagi manzillarga solishtirish orqali ichki DNS zonasini sozlang 127.0.0.0/8. Keyin klasterdagi har bir tugunda HAProxy-ni ishga tushiring, har bir xizmat manzilida (o'sha quyi tarmoqda) ulanishlarni qabul qiling. 127.0.0.0/8) va yukni tegishli orqa tomonlarga yo'naltirish/muvozanatlash. HAProxy konfiguratsiyasini boshqarish mumkin , sizga backend ma'lumotlarini etcd yoki Consul-da saqlashga va kerak bo'lganda yangilangan konfiguratsiyani HAProxy-ga avtomatik surishga imkon beradi.
Istio deyarli shunday ishlaydi! Ammo ba'zi farqlar bilan:
- Foydalanadi HAProxy o'rniga.
- Backend konfiguratsiyasini etcd yoki Consul oʻrniga Kubernetes API orqali saqlaydi.
- Xizmatlar 127.0.0.0/8 o'rniga ichki quyi tarmoqda (Kubernetes ClusterIP manzillari) manzillar ajratilgan.
- Mijoz va serverlar o'rtasida o'zaro TLS autentifikatsiyasini qo'shish uchun qo'shimcha komponent (Citadel) mavjud.
- O'chirish, taqsimlangan kuzatish, kanareykalarni joylashtirish va h.k. kabi yangi xususiyatlarni qo'llab-quvvatlaydi.
Keling, ba'zi farqlarni tezda ko'rib chiqaylik.
Elchi proksi
Elchi proksi Lyft tomonidan yozilgan [Uberning taksi bozoridagi raqobatchisi - taxminan. qator]. Bu ko'p jihatdan boshqa proksi-serverlarga o'xshaydi (masalan, HAProxy, Nginx, Traefik...), lekin Lyft o'zlarining proksilarini yozgan, chunki ular boshqa proksi-serverlarda etishmayotgan xususiyatlar kerak edi va mavjudni kengaytirish o'rniga yangisini yaratish oqilonaroq tuyuldi.
Elchi o'z-o'zidan ishlatilishi mumkin. Agar menda boshqa xizmatlarga ulanishi kerak bo'lgan maxsus xizmatim bo'lsa, men uni Envoy-ga ulanish uchun sozlashim mumkin, keyin esa ko'rinish kabi juda ko'p ajoyib qo'shimcha funktsiyalarga ega bo'lgan holda Envoy-ni boshqa xizmatlarning joylashuvi bilan dinamik ravishda sozlash va qayta sozlashim mumkin. Maxsus mijozlar kutubxonasi yoki kodga qo'ng'iroq izlarini kiritish o'rniga biz Envoyga trafik yuboramiz va u biz uchun o'lchovlarni to'playdi.
Lekin Elchi sifatida ham ishlashga qodir ma'lumotlar tekisligi (ma'lumotlar tekisligi) xizmat ko'rsatish tarmog'i uchun. Bu endi Envoy ushbu xizmat tarmog'i uchun sozlanganligini anglatadi boshqaruv tekisligi (boshqaruv samolyoti).
Boshqaruv samolyoti
Boshqaruv tekisligi uchun Istio Kubernetes API-ga tayanadi. Bu confd dan foydalanishdan unchalik farq qilmaydi, ma'lumotlar do'konidagi kalitlar to'plamini ko'rish uchun etcd yoki Konsulga tayanadi. Istio Kubernetes resurslari toʻplamini koʻrish uchun Kubernetes API’dan foydalanadi.
Bu va keyin: Shaxsan men buni foydali deb topdim qaysi o'qiydi:
Kubernetes API Server - bu API resurslari uchun saqlash, versiyalash, tekshirish, yangilash va semantikani taklif qiluvchi "soqov server".
Istio Kubernetes bilan ishlash uchun mo'ljallangan; va agar siz uni Kubernetesdan tashqarida ishlatmoqchi bo'lsangiz, Kubernetes API serverining (va etcd yordamchi xizmati) namunasini ishga tushirishingiz kerak.
Xizmat manzillari
Istio Kubernetes ajratgan ClusterIP manzillariga tayanadi, shuning uchun Istio xizmatlari ichki manzilni oladi (diapazonda emas) 127.0.0.0/8).
Istio'siz Kubernetes klasteridagi ma'lum bir xizmat uchun ClusterIP manziliga trafik kube-proksi tomonidan to'xtatiladi va proksi-serverning orqa tomoniga yuboriladi. Agar siz texnik tafsilotlarga qiziqsangiz, kube-proksi ClusterIP manziliga boradigan ulanishlarning maqsad IP manzillarini qayta yozish uchun iptables qoidalarini (yoki IPVS yuk balanslagichlarini, u qanday tuzilganiga qarab) o'rnatadi.
Istio Kubernetes klasteriga o'rnatilgandan so'ng, konteynerni kiritish orqali ma'lum bir iste'molchi yoki hatto butun nom maydoni uchun aniq yoqilmaguncha hech narsa o'zgarmaydi. sidecar maxsus podlarga. Ushbu konteyner Envoy nusxasini aylantiradi va boshqa xizmatlarga ketayotgan trafikni ushlab turish va bu trafikni Envoyga yo'naltirish uchun iptables qoidalari to'plamini o'rnatadi.
Kubernetes DNS bilan integratsiyalashganda, bu bizning kodimiz xizmat nomi bo'yicha ulanishi va hamma narsa "shunchaki ishlaydi" degan ma'noni anglatadi. Boshqacha qilib aytganda, bizning kodimiz kabi so'rovlarni chiqaradi http://api/v1/users/4242keyin api so'rovini hal qilish 10.97.105.48, iptables qoidalari 10.97.105.48 dan ulanishlarni to'xtatadi va ularni mahalliy Envoy proksi-serveriga yo'naltiradi va mahalliy proksi-server so'rovni haqiqiy backend API-ga yo'naltiradi. Voy!
Qo'shimcha burmalar
Istio shuningdek, mTLS (o'zaro TLS) orqali oxirigacha shifrlash va autentifikatsiyani ta'minlaydi. Komponent deb ataladi Citadel.
Bundan tashqari, komponent mavjud Mikser, qaysi Elchi talab qilishi mumkin har birining sarlavhalar, backend yuki va h.k. kabi turli omillarga qarab ushbu soʻrov boʻyicha maxsus qaror qabul qilishni soʻrang... (xavotir olmang: Mikserning ishlashini taʼminlashning koʻp yoʻllari bor va u ishlamay qolsa ham, Envoy ishlashda davom etadi. proksi sifatida yaxshi).
Va, albatta, biz ko'rinishni eslatib o'tdik: Elchi taqsimlangan kuzatuvni ta'minlashda juda ko'p ko'rsatkichlarni to'playdi. Mikroservislar arxitekturasida, agar bitta API so'rovi A, B, C va D mikroservislari orqali o'tishi kerak bo'lsa, tizimga kirgandan so'ng, taqsimlangan kuzatuv so'rovga noyob identifikator qo'shadi va ushbu identifikatorni ushbu mikroservislarning barchasiga quyi so'rovlar orqali saqlaydi. yozib olinadigan barcha tegishli qo'ng'iroqlar, kechikishlar va h.k.
Rivojlantiring yoki sotib oling
Istio murakkabligi bilan mashhur. Bundan farqli o'laroq, men ushbu xabarning boshida tasvirlab bergan marshrutlash tarmog'ini yaratish mavjud vositalar yordamida nisbatan oddiy. Xo'sh, buning o'rniga o'zingizning xizmat ko'rsatish tarmog'ingizni yaratish mantiqiymi?
Agar bizda kamtarona ehtiyojlar bo'lsa (bizga ko'rinish, elektron to'sar va boshqa nozikliklar kerak emas), unda fikrlar o'z vositamizni ishlab chiqishga keladi. Ammo agar biz Kubernetes-dan foydalansak, bunga ehtiyoj qolmasligi ham mumkin, chunki Kubernetes allaqachon xizmatlarni aniqlash va yuklarni muvozanatlash uchun asosiy vositalarni taqdim etadi.
Ammo agar bizda ilg'or talablar mavjud bo'lsa, unda xizmat ko'rsatish tarmog'ini "sotib olish" ancha yaxshi variant bo'lib tuyuladi. (Bu har doim ham "sotib olish" emas, chunki Istio ochiq manba, lekin biz uni tushunish, joylashtirish va boshqarish uchun hali ham muhandislik vaqtini sarflashimiz kerak.)
Istio, Linkerd yoki Consul Connectni tanlashim kerakmi?
Hozircha biz faqat Istio haqida gapirdik, ammo bu yagona xizmat ko'rsatish tarmog'i emas. Ommabop alternativ - , va yana ko'p narsalar mavjud .
Nima tanlash kerak?
Rostini aytsam, bilmayman. Ayni paytda men o'zimni bu savolga javob berishga qodir emasman. Bir necha bor bu vositalarni taqqoslash bilan va hatto .
Istiqbolli yondashuvlardan biri kabi vositadan foydalanishdir . U xizmat tarmoqlari tomonidan ochilgan API-larni soddalashtirish va birlashtirish uchun abstraktsiya qatlamini amalga oshiradi. Turli xil xizmat ko'rsatish tarmoqlarining o'ziga xos (va, mening fikrimcha, nisbatan murakkab) API-larini o'rganish o'rniga, biz SuperGloo-ning oddiy konstruksiyalaridan foydalanishimiz va biridan ikkinchisiga osongina o'tishimiz mumkin, go'yo bizda HTTP interfeyslari va backendlarni tavsiflovchi oraliq konfiguratsiya formati mavjud edi. Nginx, HAProxy, Traefik, Apache uchun haqiqiy konfiguratsiyani yaratish ...
Men Istio va SuperGloo bilan bir oz shug'ullandim va keyingi maqolada Istio yoki Linkerd-ni SuperGloo-dan foydalanib mavjud klasterga qanday qo'shishni va ikkinchisi ishni qanday bajarishini, ya'ni sizga o'tishga imkon berishini ko'rsatmoqchiman. konfiguratsiyalarni qayta yozmasdan bir xizmat tarmog'ini boshqasiga o'tkazish.
Manba: www.habr.com