Hvis du ligner de fleste mennesker, bruger du sandsynligvis ressourcer, der fungerer uden for dit cluster. Måske bruger du Taleo API til at sende tekstbeskeder eller analyserer billeder med Google Cloud Vision API.
Hvis du bruger den samme endpoint — modtagelsespunkt for anmodninger på serversiden i alle dine miljøer, og ikke har planer om at flytte dine servere til Kubernetes, så er det helt normalt at have service-endpoint direkte i din kode. Men der er mange andre scenarier. I denne serie "Kubernetes Best Practices" vil du lære, hvordan du bruger de indbyggede mekanismer i Kubernetes til at opdage tjenester både inden i og uden for clusteret.
Et eksempel på en almindelig ekstern tjeneste kan være en database, der kører uden for Kubernetes-clusteret. I modsætning til cloud-databaser som Google Cloud Data Store eller Google Cloud Spanner, som bruger en enkelt endpoint til alle former for adgang, har de fleste databaser separate endpoints til forskellige omstændigheder.
Bedste praksis for brug af traditionelle databaser som MySQL og MongoDB indebærer normalt, at du forbinder til forskellige komponenter for forskellige miljøer. Du kan have en større maskine til produktionsdata og en mindre maskine til testmiljøet. Hver af dem vil have sin egen IP-adresse eller domænenavn, men du vil helt sikkert ikke ændre din kode, når du skifter fra et miljø til et andet. Derfor, i stedet for at hardkode disse adresser, kan du bruge den indbyggede Kubernetes service til at opdage eksterne tjenester baseret på DNS, ligesom du ville gøre med native Kubernetes-tjenester.
Lad os sige, at du kører en MongoDB database i Google Compute Engine. Du vil forblive fast i denne hybride verden, indtil du kan flytte den til et cluster.
Heldigvis kan du bruge statiske Kubernetes-tjenester til at lette din situation lidt. I dette eksempel har jeg oprettet en MongoDB-server ved hjælp af Google Cloud Launcher. Da den er bygget i det samme netværk (eller VPC i Kubernetes-clusteret), er adgangen til den via en højtydende intern IP-adresse.
I Google Cloud er dette standardindstillingen, så du behøver ikke at konfigurere noget. Nu hvor der er en IP-adresse, er det første skridt at oprette en tjeneste. Man kan bemærke, at der ikke er nogen pod-selektorer for denne tjeneste. Det betyder, at vi har oprettet en tjeneste, som ikke ved, hvor den skal sende trafik. Dette vil muliggøre, at vi manuelt kan oprette et endpoint-objekt, der vil modtage trafik fra denne tjeneste.
Det næste kodeeksempel viser, at endepunkterne definerer IP-adressen til databasen ved at bruge det samme navn mongo, som tjenesten gør.
Kubernetes vil bruge alle IP-adresser til at finde endepunkterne, som om de var almindelige Kubernetes-pods, så nu kan du få adgang til databasen med en simpel forbindelsesstreng til ovenstående navn mongodb://mongo. Hermed er der slet ikke behov for at bruge IP-adresser i din kode.
Hvis IP-adresserne ændrer sig i fremtiden, kan du blot opdatere endepunkterne med den nye IP-adresse, og dine applikationer behøver ikke ændres på nogen anden måde.
Hvis du bruger en database, der er hostet på en tredjepart, har værterne sandsynligvis givet dig et ensartet ressourceidentifier URI til forbindelse. Så hvis du har fået en IP-adresse, kan du blot bruge den tidligere nævnte metode. Dette eksempel viser, at jeg har to MongoDB-databaser hostet på mLab.
En af dem er udviklerdatabasen, og den anden er produktionsdatabasen. Forbindelsesstrengene til disse databaser ser således ud — mLab giver dig en dynamisk URI og en dynamisk port. Som du kan se, er de forskellige.
For at abstrahere fra dette bruger vi Kubernetes og forbinder til udviklerdatabasen. Du kan oprette et eksternt Kubernetes-tjenestenavn, som giver dig en statisk tjeneste, der vil omdirigere trafik til den eksterne tjeneste.
Denne tjeneste vil udføre en simpel CNAME-omdirigering på kernniveau, hvilket vil have minimal indflydelse på ydeevnen. Dette giver dig mulighed for at bruge en enklere forbindelsesstreng.
Men da det eksterne navn bruger en CNAME-omdirigering, kan det ikke udføre portomdirigering. Derfor er denne løsning kun anvendelig for statiske porte og kan ikke bruges med dynamiske porte. Den gratis mLab Free Tier giver som standard brugeren et dynamisk portnummer, og det kan du ikke ændre. Dette betyder, at du har brug for forskellige forbindelseskommandoer til dev og prod. Problemet er, at portnummeret derfor skal hårdkodes. Hvordan får man så portomdirigeringen til at fungere?
Det første skridt er at hente IP-adressen fra URI. Hvis du kører kommandoen nslookup, hostname eller pinger URI, kan du få IP-adressen til databasen. Hvis tjenesten returnerer flere IP-adresser, kan alle disse adresser benyttes i objektets endepunkter.
Det er vigtigt at huske, at IP-adresserne i URI kan ændre sig uden forudgående varsel, så det er ret risikabelt at bruge dem i prod. Med en sådan IP-adresse kan du oprette forbindelse til en fjerndatabase uden at angive en port. Således udfører Kubernetes-tjenesten portomdirigering ret gennemsigtigt.
Mapping, eller kortlægning af eksterne ressourcer til interne, giver dig mulighed for fleksibelt at bruge disse tjenester inden for klyngen i fremtiden med minimal refaktorering. Det letter også administrationen og giver indsigt i, hvilke eksterne tjenester din virksomhed bruger.
Fortsættelsen kommer snart…
Lidt reklame 🙂
Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
