As jy soos die meeste mense is, gebruik jy waarskynlik hulpbronne wat buite jou groepering loop. Miskien gebruik jy die Taleo API om teksboodskappe te stuur, of analiseer prente met die Google Cloud Vision API.
As jy dieselfde bediener-kant versoek eindpunt in al jou omgewings gebruik en nie van plan is om jou bedieners na Kubernetes te migreer nie, dan is dit heeltemal goed om 'n diens eindpunt reg in jou kode te hê. Daar is egter baie ander scenario's vir die ontwikkeling van gebeure. In hierdie Kubernetes Beste Praktyke-reeks sal jy leer hoe om die ingeboude meganismes van Kubernetes te gebruik om dienste binne en buite die groepering te ontdek.
'n Voorbeeld van 'n algemene eksterne diens is 'n databasis wat buite 'n Kubernetes-kluster loop. Anders as wolkdatabasisse soos Google Cloud Data Store of Google Cloud Spanner, wat 'n enkele eindpunt vir alle toegang gebruik, het die meeste databasisse aparte eindpunte vir verskillende omstandighede.
Beste praktyke vir die gebruik van tradisionele databasisse soos MySQL en MongoDB beteken gewoonlik dat jy aan verskillende komponente vir verskillende omgewings koppel. Jy kan 'n groot masjien hê vir produksiedata en 'n kleiner masjien vir die toetsomgewing. Elkeen van hulle sal sy eie IP-adres of domeinnaam hê, maar jy sal waarskynlik nie jou kode wil verander wanneer jy van een omgewing na 'n ander beweeg nie. Dus, in plaas daarvan om hierdie adresse te hardkodeer, kan jy Kubernetes se ingeboude DNS-gebaseerde eksterne diensontdekking op dieselfde manier as inheemse Kubernetes-dienste gebruik.
Kom ons sê jy bestuur 'n MongoDB-databasis op Google Compute Engine. Jy sal in hierdie hibriede wêreld vassit totdat jy dit regkry om dit na die groep oor te dra.
Gelukkig kan jy statiese Kubernetes-dienste gebruik om jou lewe 'n bietjie makliker te maak. In hierdie voorbeeld het ek 'n MongoDB-bediener geskep met Google Cloud Launcher. Aangesien dit op dieselfde netwerk (of Kubernetes-kluster VPC) geskep is, word dit verkry deur 'n hoëprestasie-interne IP-adres te gebruik.
Dit is die verstekinstelling op Google Cloud, so jy hoef niks op te stel nie. Noudat u 'n IP-adres het, is die eerste stap om 'n diens te skep. Jy sal dalk agterkom dat daar geen peulkiesers vir hierdie diens is nie. Dit wil sê, ons het 'n diens geskep wat nie sal weet waarheen om verkeer te stuur nie. Dit sal jou toelaat om met die hand 'n eindpuntvoorwerp te skep wat verkeer van hierdie diens sal ontvang.
Die volgende kodevoorbeeld wys dat die eindpunte die IP-adres vir die databasis bepaal deur dieselfde mongo-naam as die diens te gebruik.
Kubernetes sal alle IP-adresse gebruik om eindpunte te vind asof dit gewone Kubernetes-peule is, so nou kan jy toegang tot die databasis kry met 'n eenvoudige verbindingstring na die bogenoemde naam mongodb://mongo. Dit is glad nie nodig om IP-adresse in jou kode te gebruik nie.
As IP-adresse in die toekoms verander, kan jy eenvoudig jou eindpunte bywerk met die nuwe IP-adres en jou toepassings hoef nie op enige bykomende manier gewysig te word nie.
As jy 'n databasis gebruik wat op 'n derdeparty-gasheer gehuisves word, is dit waarskynlik dat die eienaars van die gasheer jou voorsien het van 'n Uniform Resource Identifier URI om mee te koppel. As u dus 'n IP-adres gegee het, kan u eenvoudig die vorige metode gebruik. Hierdie voorbeeld wys dat ek twee MongoDB-databasisse het wat op 'n mLab-gasheer gehuisves word.
Een is die ontwikkelaar databasis en die ander is die produksie databasis. Die verbindingstringe vir hierdie databasisse lyk so - mLab bied jou 'n dinamiese URI en 'n dinamiese poort. Soos jy kan sien, is hulle anders.
Om dit weg te abstraheer, kom ons gebruik Kubernetes en koppel aan die ontwikkelaardatabasis. Jy kan 'n eksterne Kubernetes-diensnaam skep, wat vir jou 'n statiese diens sal gee wat verkeer na die eksterne diens sal aanstuur.
Hierdie diens sal eenvoudige CNAME-aanstuur op kernvlak uitvoer met minimale prestasie-impak. Danksy dit kan jy 'n eenvoudiger verbindingstring gebruik.
Maar omdat die eksterne naam CNAME-aanstuur gebruik, kan dit nie poortaanstuur doen nie. Daarom is hierdie oplossing slegs van toepassing op statiese poorte en kan nie met dinamiese poorte gebruik word nie. Maar mLab Free Tier gee die gebruiker by verstek 'n dinamiese poortnommer en jy kan dit nie verander nie. Dit beteken dat u verskillende verbindingsbevellyne benodig vir dev en prod. Die slegte ding is dat dit sal vereis dat jy die poortnommer hardkodeer. So, hoe kry jy hawe-aanstuur aan die werk?
Die eerste stap is om die IP-adres van die URI te verkry. As jy nslookup, gasheernaam of die URI ping, kan jy die IP-adres van die databasis kry. As die diens verskeie IP-adresse aan jou terugstuur, kan al hierdie adresse by die eindpunte van die voorwerp gebruik word.
Een ding om in gedagte te hou, is dat IP-URI's sonder kennisgewing kan verander, wat dit redelik riskant maak om in prod te gebruik. Deur hierdie IP-adres te gebruik, kan u aan 'n afgeleë databasis koppel sonder om 'n poort te spesifiseer. Die Kubernetes-diens voer dus poortaanstuur redelik deursigtig uit.
Kartering, of kartering van eksterne hulpbronne na interne, gee jou die buigsaamheid om hierdie dienste in die toekoms binne die groepering te gebruik, terwyl herfaktoreringspogings tot die minimum beperk word. Dit maak dit ook makliker om te bestuur en insig te gee in watter eksterne dienste jou maatskappy gebruik.
Word binnekort vervolg...
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com