Hvis du er som de fleste mennesker, bruger du sandsynligvis ressourcer, der kører uden for din klynge. Måske bruger du Taleo API til at sende tekstbeskeder eller analysere billeder ved hjælp af Google Cloud Vision API.
Hvis du bruger det samme server-side request endpoint i alle dine miljøer og ikke planlægger at migrere dine servere til Kubernetes, så er det helt fint at have et service endpoint lige i din kode. Der er dog mange andre scenarier for udviklingen af begivenheder. I denne Kubernetes Best Practices-serie lærer du, hvordan du bruger de indbyggede mekanismer i Kubernetes til at opdage tjenester både i og uden for klyngen.
Et eksempel på en almindelig ekstern tjeneste er en database, der kører uden for en Kubernetes-klynge. I modsætning til cloud-databaser som Google Cloud Data Store eller Google Cloud Spanner, der bruger et enkelt slutpunkt til al adgang, har de fleste databaser separate slutpunkter til forskellige omstændigheder.
Bedste praksis for brug af traditionelle databaser såsom MySQL og MongoDB betyder normalt, at du opretter forbindelse til forskellige komponenter til forskellige miljøer. Du kan have en stor 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 sandsynligvis ikke ændre din kode, når du flytter fra et miljø til et andet. Så i stedet for at hardkode disse adresser, kan du bruge Kubernetes' indbyggede DNS-baserede eksterne serviceopdagelse på samme måde som native Kubernetes-tjenester.
Lad os sige, at du kører en MongoDB-database på Google Compute Engine. Du vil sidde fast i denne hybridverden, indtil det lykkes dig at overføre den til klyngen.
Heldigvis kan du bruge statiske Kubernetes-tjenester til at gøre dit liv lidt lettere. I dette eksempel oprettede jeg en MongoDB-server ved hjælp af Google Cloud Launcher. Da det er oprettet på det samme netværk (eller Kubernetes cluster VPC), tilgås det ved hjælp af en højtydende intern IP-adresse.
Dette er standardindstillingen på Google Cloud, så du behøver ikke at konfigurere noget. Nu hvor du har en IP-adresse, er det første skridt at oprette en tjeneste. Du bemærker muligvis, at der ikke er nogen pod-vælgere til denne tjeneste. Det vil sige, at vi skabte en tjeneste, der ikke ved, hvor den skal sende trafik. Dette giver dig mulighed for manuelt at oprette et slutpunktsobjekt, der vil modtage trafik fra denne tjeneste.
Følgende kodeeksempel viser, at endepunkterne bestemmer IP-adressen for databasen ved at bruge det samme mongo-navn som tjenesten.
Kubernetes vil bruge alle IP-adresser til at finde endepunkter, 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. Der er ingen grund til at bruge IP-adresser i din kode overhovedet.
Hvis IP-adresser ændres i fremtiden, kan du blot opdatere dine endepunkter med den nye IP-adresse, og dine applikationer skal ikke ændres på nogen yderligere måde.
Hvis du bruger en database, der er hostet på en tredjepartsvært, er det sandsynligt, at ejerne af værten har givet dig en Uniform Resource Identifier URI at oprette forbindelse til. Så hvis du har fået en IP-adresse, kan du blot bruge den tidligere metode. Dette eksempel viser, at jeg har to MongoDB-databaser hostet på en mLab-vært.
Den ene er udviklerdatabasen og den anden er produktionsdatabasen. Forbindelsesstrengene for disse databaser ser sådan ud - mLab giver dig en dynamisk URI og en dynamisk port. Som du kan se, er de forskellige.
For at abstrahere dette væk, lad os bruge Kubernetes og oprette forbindelse til udviklerdatabasen. Du kan oprette et eksternt Kubernetes-tjenestenavn, som giver dig en statisk tjeneste, der videresender trafik til den eksterne tjeneste.
Denne tjeneste vil udføre simpel CNAME-videresendelse på kerneniveau med minimal præstationspåvirkning. Takket være dette kan du bruge en enklere forbindelsesstreng.
Men fordi det eksterne navn bruger CNAME-videresendelse, kan det ikke udføre portvideresendelse. Derfor er denne løsning kun anvendelig til statiske porte og kan ikke bruges med dynamiske porte. Men mLab Free Tier giver brugeren et dynamisk portnummer som standard, og du kan ikke ændre det. Det betyder, at du har brug for forskellige forbindelseskommandolinjer til dev og prod. Den dårlige ting er, at dette vil kræve, at du hardkode portnummeret. Så hvordan får du port forwarding til at fungere?
Det første trin er at få IP-adressen fra URI'en. Hvis du kører nslookup, værtsnavn eller pinger URI'en, kan du få databasens IP-adresse. Hvis tjenesten returnerer flere IP-adresser til dig, kan alle disse adresser bruges ved objektets endepunkter.
En ting at huske på er, at IP URI'er kan ændres uden varsel, hvilket gør dem ret risikable at bruge i prod. Ved at bruge denne IP-adresse kan du oprette forbindelse til en ekstern database uden at angive en port. Således udfører Kubernetes-tjenesten portvideresendelse ganske gennemsigtigt.
Kortlægning, eller kortlægning af eksterne ressourcer til interne, giver dig fleksibiliteten til at bruge disse tjenester i klyngen i fremtiden, mens refaktoriseringsindsatsen minimeres. Det gør det også nemmere at administrere og give indsigt i, hvilke eksterne services din virksomhed bruger.
Fortsættes meget snart...
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com