Hvis du er som folk flest, bruker du sannsynligvis ressurser som kjører utenfor klyngen din. Kanskje du bruker Taleo API til å sende tekstmeldinger, eller analyserer bilder ved hjelp av Google Cloud Vision API.
Hvis du bruker det samme forespørselsendepunktet på serversiden i alle miljøene dine og ikke planlegger å migrere serverne dine til Kubernetes, er det helt greit å ha et tjenesteendepunkt rett i koden din. Imidlertid er det mange andre scenarier for utvikling av hendelser. I denne Kubernetes Best Practices-serien lærer du hvordan du bruker de innebygde mekanismene til Kubernetes for å oppdage tjenester både i og utenfor klyngen.
Et eksempel på en vanlig ekstern tjeneste er en database som kjører utenfor en Kubernetes-klynge. I motsetning til skydatabaser som Google Cloud Data Store eller Google Cloud Spanner, som bruker ett enkelt endepunkt for all tilgang, har de fleste databaser separate endepunkter for forskjellige omstendigheter.
Beste praksis for bruk av tradisjonelle databaser som MySQL og MongoDB betyr vanligvis at du kobler til forskjellige komponenter for forskjellige miljøer. Du kan ha en stor maskin for produksjonsdata og en mindre maskin for testmiljøet. Hver av dem vil ha sin egen IP-adresse eller domenenavn, men du vil sannsynligvis ikke endre koden når du flytter fra ett miljø til et annet. Så i stedet for å hardkode disse adressene, kan du bruke Kubernetes' innebygde DNS-baserte eksterne tjenesteoppdagelse på samme måte som native Kubernetes-tjenester.
La oss si at du kjører en MongoDB-database på Google Compute Engine. Du vil sitte fast i denne hybridverdenen til du klarer å overføre den til klyngen.
Heldigvis kan du bruke statiske Kubernetes-tjenester for å gjøre livet ditt litt enklere. I dette eksemplet opprettet jeg en MongoDB-server ved hjelp av Google Cloud Launcher. Siden den er opprettet på samme nettverk (eller Kubernetes cluster VPC), får du tilgang til den ved hjelp av en intern IP-adresse med høy ytelse.
Dette er standardinnstillingen på Google Cloud, så du trenger ikke å konfigurere noe. Nå som du har en IP-adresse, er det første trinnet å opprette en tjeneste. Du vil kanskje legge merke til at det ikke er noen podvelgere for denne tjenesten. Det vil si at vi opprettet en tjeneste som ikke vil vite hvor de skal sende trafikk. Dette vil tillate deg å manuelt opprette et endepunktobjekt som vil motta trafikk fra denne tjenesten.
Følgende kodeeksempel viser at endepunktene bestemmer IP-adressen for databasen ved å bruke det samme mongonavnet som tjenesten.
Kubernetes vil bruke alle IP-adresser for å finne endepunkter som om de var vanlige Kubernetes Pods, så nå kan du få tilgang til databasen med en enkel tilkoblingsstreng til navnet ovenfor mongodb://mongo. Det er ikke nødvendig å bruke IP-adresser i koden din i det hele tatt.
Hvis IP-adressene endres i fremtiden, kan du ganske enkelt oppdatere endepunktene dine med den nye IP-adressen, og applikasjonene dine trenger ikke å endres på noen ekstra måte.
Hvis du bruker en database som er vert for en tredjepartsvert, er det sannsynlig at eierne av verten har gitt deg en Uniform Resource Identifier URI du kan koble til. Så hvis du har fått en IP-adresse, kan du ganske enkelt bruke den forrige metoden. Dette eksemplet viser at jeg har to MongoDB-databaser på en mLab-vert.
Den ene er utviklerdatabasen og den andre er produksjonsdatabasen. Tilkoblingsstrengene for disse databasene ser slik ut - mLab gir deg en dynamisk URI og en dynamisk port. Som du kan se, er de forskjellige.
For å abstrahere dette, la oss bruke Kubernetes og koble til utviklerdatabasen. Du kan opprette et eksternt Kubernetes-tjenestenavn, som vil gi deg en statisk tjeneste som videresender trafikk til den eksterne tjenesten.
Denne tjenesten vil utføre enkel CNAME-videresending på kjernenivå med minimal ytelsespåvirkning. Takket være dette kan du bruke en enklere tilkoblingsstreng.
Men fordi det eksterne navnet bruker CNAME-videresending, kan det ikke utføre portvideresending. Derfor kan denne løsningen kun brukes for statiske porter og kan ikke brukes med dynamiske porter. Men mLab Free Tier gir brukeren et dynamisk portnummer som standard, og du kan ikke endre det. Dette betyr at du trenger forskjellige tilkoblingskommandolinjer for dev og prod. Det dårlige er at dette vil kreve at du hardkode portnummeret. Så hvordan får du portvideresending til å fungere?
Det første trinnet er å få IP-adressen fra URI. Hvis du kjører nslookup, vertsnavn eller pinger URIen, kan du få IP-adressen til databasen. Hvis tjenesten returnerer flere IP-adresser til deg, kan alle disse adressene brukes ved endepunktene til objektet.
En ting å huske på er at IP-URI-er kan endres uten varsel, noe som gjør dem ganske risikable å bruke i prod. Ved å bruke denne IP-adressen kan du koble til en ekstern database uten å spesifisere en port. Dermed utfører Kubernetes-tjenesten portvideresending ganske transparent.
Kartlegging, eller kartlegging av eksterne ressurser til interne, gir deg fleksibiliteten til å bruke disse tjenestene innenfor klyngen i fremtiden, samtidig som refaktoriseringsarbeidet minimeres. Det gjør det også enklere å administrere og gi innsikt i hvilke eksterne tjenester din bedrift bruker.
Fortsettelse snart...
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com