Kui olete nagu enamik inimesi, kasutate tõenäoliselt ressursse, mis töötavad väljaspool teie klastrit. Võib-olla kasutate Taleo API-t tekstisõnumite saatmiseks või piltide analüüsimiseks Google Cloud Vision API abil.
Kui kasutate kõigis keskkondades sama serveripoolse päringu lõpp-punkti ega kavatse oma servereid Kubernetesesse üle viia, on täiesti hea, kui teenuse lõpp-punkt on teie koodis. Sündmuste arenguks on aga palju muid stsenaariume. Selles Kubernetese parimate tavade seerias saate teada, kuidas kasutada Kubernetese sisseehitatud mehhanisme, et avastada teenuseid nii klastris kui ka väljaspool.
Tavalise välisteenuse näide on väljaspool Kubernetese klastrit töötav andmebaas. Erinevalt pilvandmebaasidest, nagu Google Cloud Data Store või Google Cloud Spanner, mis kasutavad kogu juurdepääsu jaoks ühte lõpp-punkti, on enamikul andmebaasidel erinevate asjaolude jaoks eraldi lõpp-punktid.
Traditsiooniliste andmebaaside, nagu MySQL ja MongoDB, kasutamise parimad tavad tähendavad tavaliselt, et ühendate erinevate keskkondade jaoks erinevate komponentidega. Sul võib olla suur masin tootmisandmete jaoks ja väiksem masin testkeskkonna jaoks. Igal neist on oma IP-aadress või domeeninimi, kuid tõenäoliselt ei soovi te ühest keskkonnast teise liikudes oma koodi muuta. Nii et nende aadresside kõvakodeerimise asemel saate kasutada Kubernetese sisseehitatud DNS-põhist välisteenuse avastamist samamoodi nagu Kubernetese natiivseid teenuseid.
Oletame, et kasutate rakenduses Google Compute Engine MongoDB andmebaasi. Jääte sellesse hübriidmaailma kinni, kuni teil õnnestub see klastrisse üle kanda.
Õnneks saate oma elu lihtsustamiseks kasutada staatilisi Kubernetese teenuseid. Selles näites lõin Google Cloud Launcheri abil MongoDB serveri. Kuna see on loodud samas võrgus (või Kubernetese klastri VPC), pääseb sellele juurde suure jõudlusega sisemise IP-aadressi abil.
See on Google Cloudi vaikeseade, nii et te ei pea midagi seadistama. Nüüd, kui teil on IP-aadress, on esimene samm teenuse loomine. Võite märgata, et selle teenuse jaoks pole kausta valijaid. See tähendab, et lõime teenuse, mis ei tea, kuhu liiklust saata. See võimaldab teil käsitsi luua lõpp-punkti objekti, mis võtab selle teenuse liiklust vastu.
Järgmine koodinäide näitab, et lõpp-punktid määravad andmebaasi IP-aadressi, kasutades teenusega sama mongo nime.
Kubernetes kasutab lõpp-punktide leidmiseks kõiki IP-aadresse nii, nagu oleksid need tavalised Kubernetes Pods, nii et nüüd pääsete andmebaasile juurde ülaltoodud nimega mongodb://mongo lihtsa ühendusstringiga. IP-aadresse pole koodis üldse vaja kasutada.
Kui IP-aadressid tulevikus muutuvad, saate lihtsalt värskendada oma lõpp-punkte uue IP-aadressiga ja teie rakendusi ei ole vaja täiendavalt muuta.
Kui kasutate kolmanda osapoole hostis hostitud andmebaasi, on tõenäoline, et hosti omanikud on andnud teile ühenduse loomiseks ühtse ressursiidentifikaatori URI. Nii et kui teile on antud IP-aadress, võite lihtsalt kasutada eelmist meetodit. See näide näitab, et mul on mLabi hostis kaks MongoDB andmebaasi.
Üks on arendajate andmebaas ja teine tootmisandmebaas. Nende andmebaaside ühendusstringid näevad välja sellised – mLab pakub teile dünaamilise URI ja dünaamilise pordi. Nagu näete, on need erinevad.
Selle abstrakteerimiseks kasutage Kubernetesi ja loome ühenduse arendajate andmebaasiga. Saate luua välise Kubernetese teenuse nime, mis annab teile staatilise teenuse, mis edastab liikluse välisteenusele.
See teenus teostab lihtsa CNAME-edastuse kerneli tasemel, mõjutades jõudlust minimaalselt. Tänu sellele saate kasutada lihtsamat ühendusstringi.
Kuid kuna välisnimi kasutab CNAME-edastust, ei saa see pordi edastamist teostada. Seetõttu on see lahendus rakendatav ainult staatiliste portide jaoks ja seda ei saa kasutada dünaamiliste portidega. Kuid mLab Free Tier annab kasutajale vaikimisi dünaamilise pordinumbri ja te ei saa seda muuta. See tähendab, et vajate dev ja prod jaoks erinevaid ühenduse käsuridasid. Halb on see, et selleks peate pordi numbri kõvasti kodeerima. Kuidas siis pordiedastus tööle panna?
Esimene samm on IP-aadressi hankimine URI-st. Kui käivitate nslookupi, hostinime või URI pingi, saate andmebaasi IP-aadressi. Kui teenus tagastab teile mitu IP-aadressi, saab kõiki neid aadresse kasutada objekti lõpp-punktides.
Üks asi, mida meeles pidada, on see, et IP URI-d võivad ette teatamata muutuda, mistõttu on nende kasutamine tootmisprotsessis üsna riskantne. Seda IP-aadressi kasutades saate luua ühenduse kaugandmebaasiga ilma porti määramata. Seega teostab Kubernetese teenus pordi edastamist üsna läbipaistvalt.
Kaardistamine või väliste ressursside vastendamine sisemistega annab teile paindlikkuse kasutada neid teenuseid klastri sees tulevikus, minimeerides samal ajal ümbertöötlemise jõupingutusi. Samuti hõlbustab see haldamist ja annab ülevaate sellest, milliseid välisteenuseid teie ettevõte kasutab.
Jätkub peagi...
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com