Jos olet kuten useimmat ihmiset, käytät todennäköisesti klusterisi ulkopuolella olevia resursseja. Ehkä käytät Taleo-sovellusliittymää tekstiviestien lähettämiseen tai kuvien analysointiin Google Cloud Vision -sovellusliittymän avulla.
Jos käytät samaa palvelinpuolen pyyntöpäätepistettä kaikissa ympäristöissäsi etkä aio siirtää palvelimiasi Kubernetesiin, on täysin hyvä, että koodissasi on palvelun päätepiste. Tapahtumien kehittymiselle on kuitenkin monia muita skenaarioita. Tässä Kubernetesin parhaiden käytäntöjen sarjassa opit käyttämään Kubernetesin sisäänrakennettuja mekanismeja palveluiden löytämiseen sekä klusterin sisällä että sen ulkopuolella.
Esimerkki yleisestä ulkoisesta palvelusta on Kubernetes-klusterin ulkopuolella toimiva tietokanta. Toisin kuin pilvitietokannat, kuten Google Cloud Data Store tai Google Cloud Spanner, jotka käyttävät yhtä päätepistettä kaikille pääsyille, useimmilla tietokannoilla on erilliset päätepisteet eri olosuhteita varten.
Parhaat käytännöt perinteisten tietokantojen, kuten MySQL ja MongoDB, käyttöön tarkoittavat yleensä yhteyden muodostamista eri komponentteihin eri ympäristöissä. Sinulla voi olla suuri kone tuotantotiedoille ja pienempi kone testiympäristöön. Jokaisella niistä on oma IP-osoite tai verkkotunnus, mutta et todennäköisesti halua muuttaa koodiasi siirtyessäsi ympäristöstä toiseen. Joten näiden osoitteiden koodaamisen sijaan voit käyttää Kubernetesin sisäänrakennettua DNS-pohjaista ulkoista palvelun etsintää samalla tavalla kuin alkuperäisiä Kubernetes-palveluita.
Oletetaan, että käytät MongoDB-tietokantaa Google Compute Enginessä. Olet jumissa tässä hybridimaailmassa, kunnes onnistut siirtämään sen klusteriin.
Onneksi voit käyttää staattisia Kubernetes-palveluita helpottaaksesi elämääsi. Tässä esimerkissä loin MongoDB-palvelimen Google Cloud Launcherin avulla. Koska se on luotu samassa verkossa (tai Kubernetes-klusterin VPC:ssä), sitä käytetään tehokkaan sisäisen IP-osoitteen avulla.
Tämä on oletusasetus Google Cloudissa, joten sinun ei tarvitse määrittää mitään. Nyt kun sinulla on IP-osoite, ensimmäinen askel on luoda palvelu. Saatat huomata, että tälle palvelulle ei ole pod-valitsijoita. Eli loimme palvelun, joka ei tiedä minne lähettää liikennettä. Tämän avulla voit luoda manuaalisesti päätepisteobjektin, joka vastaanottaa liikennettä tästä palvelusta.
Seuraava koodiesimerkki osoittaa, että päätepisteet määrittävät tietokannan IP-osoitteen käyttämällä samaa mongo-nimeä kuin palvelu.
Kubernetes käyttää kaikkia IP-osoitteita päätepisteiden etsimiseen ikään kuin ne olisivat tavallisia Kubernetes Podeja, joten nyt voit käyttää tietokantaa yksinkertaisella yhteysmerkkijonolla yllä olevaan nimeen mongodb://mongo. IP-osoitteita ei tarvitse käyttää koodissasi ollenkaan.
Jos IP-osoitteet muuttuvat tulevaisuudessa, voit yksinkertaisesti päivittää päätepisteesi uudella IP-osoitteella, jolloin sovelluksiasi ei tarvitse muuttaa millään muulla tavalla.
Jos käytät tietokantaa, jota isännöi kolmannen osapuolen isäntä, on todennäköistä, että isännän omistajat ovat antaneet sinulle Uniform Resource Identifier -URI:n yhteyden muodostamista varten. Joten jos sinulle on annettu IP-osoite, voit käyttää edellistä menetelmää. Tämä esimerkki osoittaa, että minulla on kaksi MongoDB-tietokantaa isännöitynä mLab-isännässä.
Toinen on kehittäjätietokanta ja toinen tuotantotietokanta. Näiden tietokantojen yhteysmerkkijonot näyttävät tältä - mLab tarjoaa sinulle dynaamisen URI:n ja dynaamisen portin. Kuten näet, ne ovat erilaisia.
Ota tämä pois käyttämällä Kubernetesia ja muodostamalla yhteys kehittäjätietokantaan. Voit luoda ulkoisen Kubernetes-palvelun nimen, joka antaa sinulle staattisen palvelun, joka välittää liikenteen ulkoiseen palveluun.
Tämä palvelu suorittaa yksinkertaisen CNAME-edelleenohjauksen ytimen tasolla ilman, että se vaikuttaa suorituskykyyn. Tämän ansiosta voit käyttää yksinkertaisempaa yhteysmerkkijonoa.
Mutta koska ulkoinen nimi käyttää CNAME-välitystä, se ei voi suorittaa portin edelleenohjausta. Siksi tämä ratkaisu soveltuu vain staattisiin portteihin, eikä sitä voida käyttää dynaamisten porttien kanssa. Mutta mLab Free Tier antaa käyttäjälle oletuksena dynaamisen porttinumeron, etkä voi muuttaa sitä. Tämä tarkoittaa, että tarvitset eri yhteyskomentorivit deville ja prod:lle. Huono asia on, että tämä edellyttää portin numeron kovakoodausta. Joten miten saat portin edelleenlähetyksen toimimaan?
Ensimmäinen askel on saada IP-osoite URI:sta. Jos suoritat nslookupin, isäntänimen tai ping-kutsut URI:n, saat tietokannan IP-osoitteen. Jos palvelu palauttaa sinulle useita IP-osoitteita, kaikkia näitä osoitteita voidaan käyttää kohteen päätepisteissä.
Yksi asia on pidettävä mielessä, että IP-URI:t voivat muuttua ilman ennakkoilmoitusta, mikä tekee niistä melko riskialtista käyttää tuotannossa. Käyttämällä tätä IP-osoitetta voit muodostaa yhteyden etätietokantaan porttia määrittämättä. Siten Kubernetes-palvelu suorittaa porttiohjauksen melko läpinäkyvästi.
Kartoitus tai ulkoisten resurssien yhdistäminen sisäisiin antaa sinulle joustavuutta käyttää näitä palveluita klusterin sisällä tulevaisuudessa ja minimoi samalla uudelleenjärjestelyponnistelut. Se helpottaa myös yrityksesi käyttämien ulkoisten palveluiden hallintaa ja näkemistä.
Jatkuu pian...
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com