Dacă ești ca majoritatea oamenilor, este probabil să folosești resurse care funcționează dincolo de clusterul tău. Poate folosești API-ul Taleo pentru a trimite mesaje text sau analizezi imagini folosind API-ul Google Cloud Vision.
Dacă folosești același endpoint — punct de primire a cererilor pe partea serverului în toate mediile tale și nu plănuiești să îți muți serverele în Kubernetes, atunci este perfect normal să ai endpoint-ul serviciului direct în codul tău. Totuși, există multe alte scenarii posibile. În această serie de „Cele mai bune practici Kubernetes” vei învăța cum să folosești mecanismele încorporate Kubernetes pentru a descoperi servicii atât în interiorul, cât și în exteriorul clusterului.
Ca exemplu de serviciu extern comun, putem menționa o bază de date care funcționează în afara clusterului Kubernetes. Spre deosebire de bazele de date în cloud, cum ar fi Google Cloud Data Store sau Google Cloud Spanner, care folosesc un singur endpoint pentru toate tipurile de acces, majoritatea bazelor de date au endpoint-uri separate pentru diferite circumstanțe.
Practicile avansate pentru utilizarea bazelor de date tradiționale, precum MySQL și MongoDB, stipulează de obicei că te conectezi la diferite componente pentru diferite medii. Poate ai o mașină mare pentru datele de producție și una mai mică pentru mediul de testare. Fiecare dintre acestea va avea propria adresă IP sau nume de domeniu, dar cu siguranță nu vrei să îți schimbi codul atunci când treci de la un mediu la altul. De aceea, în loc să codifici în mod fix aceste adrese, poți folosi serviciul încorporat în Kubernetes pentru descoperirea serviciilor externe bazate pe DNS, exact ca și pentru serviciile native Kubernetes.
Presupunem că îți rulezi baza de date MongoDB în Google Compute Engine. Vei rămâne prins în această lume hibridă până când vei reuși să o muți în cluster.
Din fericire, poți folosi serviciile statice Kubernetes pentru a-ți ușura puțin viața. În acest exemplu, am creat un server MongoDB folosind Google Cloud Launcher. Deoarece a fost creat în aceeași rețea (sau VPC a clusterului Kubernetes), accesul la el se face printr-o adresă IP internă de înaltă performanță.
În Google Cloud, aceasta este setarea implicită, așa că nu trebuie să faceți nimic. Acum, când există o adresă IP, primul pas este crearea unui serviciu. Este de observat că pentru acest serviciu nu sunt selectori de pod-uri. Cu alte cuvinte, am creat un serviciu care nu va ști unde să trimită traficul. Aceasta va permite crearea manuală a unui obiect endpoint, care va primi traficul de la acest serviciu.
Următorul exemplu de cod arată că endpoint-urile definesc adresa IP pentru baza de date, folosind același nume mongo ca și serviciul.
Kubernetes va folosi toate adresele IP pentru a găsi endpoint-urile, ca și cum ar fi pod-uri Kubernetes obișnuite, astfel încât acum puteți accesa baza de date folosind o simplă linie de conectare către numele menționat mai sus mongodb://mongo. Astfel, nu este necesar să folosiți adrese IP în codul dumneavoastră.
Dacă în viitor adresele IP se vor schimba, puteți actualiza pur și simplu endpoint-urile cu noua adresă IP, iar aplicațiile dumneavoastră nu vor necesita modificări suplimentare.
Dacă folosiți o bază de date găzduită pe un host terț, este probabil ca proprietarii host-ului să vă fi oferit un identificator unificat de resursă URI pentru conectare. Așadar, dacă vi s-a dat o adresă IP, puteți folosi pur și simplu metoda anterioară. Acest exemplu arată că am două baze de date MongoDB, găzduite pe host-ul mLab.
Una dintre ele este baza de date pentru dezvoltatori și cealaltă este baza de date pentru producție. liniile de conectare pentru aceste baze de date arată astfel — mLab vă oferă un URI dinamic și un port dinamic. După cum vedeți, sunt diferite.
Pentru a te abstrae de aceasta, folosim Kubernetes și ne conectăm la baza de date pentru dezvoltatori. Puteți crea un nume de serviciu extern Kubernetes, care vă va oferi un serviciu static, ce va redirecționa traficul către un serviciu extern.
Acest serviciu va efectua o redirecționare CNAME simplă la nivel de kernel, ceea ce va avea un impact minim asupra performanței. Datorită acestui lucru, puteți utiliza o linie de conectare mai simplă.
Dar deoarece numele extern utilizează o redirecționare CNAME, nu poate realiza o remapare a porturilor. Prin urmare, această soluție este aplicabilă doar pentru porturi statice și nu poate fi utilizată cu porturi dinamice. Totuși, mLab Free Tier oferă utilizatorului un număr de port dinamic, și nu puteți schimba acest lucru. Aceasta înseamnă că aveți nevoie de diferite șiruri de conectare pentru dev și prod. Problema este că va trebui să codificați în mod fix numărul de port. Așadar, cum faceți să funcționeze remaparea porturilor?
Primul pas este obținerea adresei IP din URI. Dacă rulați comanda nslookup, hostname sau faceți ping la URI, puteți obține adresa IP a bazei de date. Dacă serviciul vă returnează mai multe adrese IP, puteți folosi toate aceste adrese în punctele finale ale obiectului.
Trebuie să rețineți că adresele IP ale URI-urilor se pot schimba fără preaviz, ceea ce le face destul de riscante pentru utilizarea în prod. Cu o astfel de adresă IP, puteți să vă conectați la o bază de date de la distanță, fără a specifica un port. Astfel, serviciul Kubernetes realizează destul de transparent remaparea porturilor.
Maparea, sau asocierea resurselor externe cu cele interne, vă oferă flexibilitate pentru utilizarea acestor servicii în interiorul clusterului în viitor, minimizând eforturile de refactorizare. De asemenea, facilitează gestionarea și oferă o înțelegere a serviciilor externe utilizate de compania dvs.
Continuarea va veni foarte curând…
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
