Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Kubernetes najbolje prakse. Izrada malih spremnika
Kubernetes najbolje prakse. Organizacija Kubernetesa s prostorom imena
Kubernetes najbolje prakse. Provjera živosti Kubernetesa pomoću testova spremnosti i živosti
Kubernetes najbolje prakse. Postavljanje zahtjeva za resursima i ograničenja
Kubernetes najbolje prakse. Ispravno isključivanje Prekini

Ako ste poput većine ljudi, vjerojatno koristite resurse koji se pokreću izvan vašeg klastera. Možda koristite Taleo API za slanje tekstualnih poruka ili analizu slika pomoću Google Cloud Vision API-ja.

Ako koristite istu krajnju točku zahtjeva na strani poslužitelja u svim svojim okruženjima i ne planirate migrirati svoje poslužitelje na Kubernetes, onda je savršeno u redu imati krajnju točku usluge u svom kodu. No, postoje i mnogi drugi scenariji razvoja događaja. U ovoj seriji najboljih praksi za Kubernetes naučit ćete kako koristiti ugrađene mehanizme Kubernetesa za otkrivanje usluga unutar i izvan klastera.

Primjer uobičajene vanjske usluge je baza podataka koja radi izvan Kubernetes klastera. Za razliku od baza podataka u oblaku kao što su Google Cloud Data Store ili Google Cloud Spanner, koje koriste jednu krajnju točku za sav pristup, većina baza podataka ima zasebne krajnje točke za različite okolnosti.
Najbolje prakse za korištenje tradicionalnih baza podataka kao što su MySQL i MongoDB obično znače da se povezujete s različitim komponentama za različita okruženja. Možete imati veliki stroj za proizvodne podatke i manji stroj za testno okruženje. Svaki od njih će imati vlastitu IP adresu ili naziv domene, ali vjerojatno nećete htjeti promijeniti svoj kod kada prelazite iz jednog okruženja u drugo. Dakle, umjesto tvrdog kodiranja ovih adresa, možete koristiti Kubernetesovo ugrađeno otkrivanje vanjske usluge temeljeno na DNS-u na isti način kao izvorne Kubernetes usluge.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Recimo da pokrećete MongoDB bazu podataka na Google Compute Engineu. Bit ćete zaglavljeni u ovom hibridnom svijetu dok ga ne uspijete prebaciti u klaster.

Srećom, možete koristiti statičke Kubernetes usluge kako biste malo olakšali svoj život. U ovom sam primjeru izradio MongoDB poslužitelj koristeći Google Cloud Launcher. Budući da je stvoren na istoj mreži (ili Kubernetes klaster VPC), pristupa mu se pomoću interne IP adrese visokih performansi.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Ovo je zadana postavka na Google Cloudu, tako da ne morate ništa konfigurirati. Sada kada imate IP adresu, prvi korak je kreiranje usluge. Možda ćete primijetiti da za ovu uslugu ne postoje birači podova. Odnosno, napravili smo servis koji neće znati kamo poslati promet. To će vam omogućiti da ručno stvorite objekt krajnje točke koji će primati promet od ove usluge.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Sljedeći primjer koda pokazuje da krajnje točke određuju IP adresu za bazu podataka koristeći isto mongo ime kao i usluga.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Kubernetes će koristiti sve IP adrese za pronalaženje krajnjih točaka kao da su obični Kubernetes Pods, tako da sada možete pristupiti bazi podataka s jednostavnim nizom veze na gornji naziv mongodb://mongo. U svom kodu uopće nema potrebe koristiti IP adrese.

Ako se IP adrese u budućnosti promijene, možete jednostavno ažurirati svoje krajnje točke s novom IP adresom i vaše aplikacije neće morati biti modificirane na bilo koji dodatni način.

Ako koristite bazu podataka smještenu na hostu treće strane, vjerojatno su vam vlasnici hosta dali Uniform Resource Identifier URI za povezivanje. Dakle, ako ste dobili IP adresu, možete jednostavno koristiti prethodnu metodu. Ovaj primjer pokazuje da imam dvije MongoDB baze podataka smještene na mLab hostu.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Jedna je baza podataka programera, a druga je proizvodna baza podataka. Nizovi veze za ove baze podataka izgledaju ovako - mLab vam daje dinamički URI i dinamički priključak. Kao što vidite, oni su različiti.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Da ovo apstrahiramo, upotrijebimo Kubernetes i povežimo se s bazom podataka programera. Možete stvoriti vanjski naziv usluge Kubernetes, koji će vam dati statičnu uslugu koja će proslijediti promet vanjskoj usluzi.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Ova će usluga izvesti jednostavno CNAME prosljeđivanje na razini jezgre s minimalnim utjecajem na performanse. Zahvaljujući tome možete koristiti jednostavniji povezni niz.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Ali budući da vanjski naziv koristi CNAME prosljeđivanje, ne može izvršiti prosljeđivanje porta. Stoga je ovo rješenje primjenjivo samo za statičke portove i ne može se koristiti s dinamičkim portovima. Ali mLab Free Tier daje korisniku dinamički broj porta prema zadanim postavkama i ne možete ga promijeniti. To znači da trebate različite naredbene retke za povezivanje za dev i prod. Loša stvar je što će to zahtijevati da kodirate broj porta. Dakle, kako natjerati prosljeđivanje porta da radi?

Prvi korak je dobivanje IP adrese iz URI-ja. Ako pokrenete nslookup, hostname ili ping URI, možete dobiti IP adresu baze podataka. Ako vam usluga vrati nekoliko IP adresa, tada se sve te adrese mogu koristiti na krajnjim točkama objekta.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Jedna stvar koju treba imati na umu je da se IP URI-ji mogu promijeniti bez prethodne najave, što ih čini prilično riskantnim za korištenje u prod. Pomoću ove IP adrese možete se povezati s udaljenom bazom podataka bez navođenja priključka. Dakle, usluga Kubernetes prilično transparentno obavlja port forwarding.

Kubernetes najbolje prakse. Mapiranje vanjskih usluga

Mapiranje, ili mapiranje vanjskih resursa u interne, daje vam fleksibilnost za korištenje ovih usluga unutar klastera u budućnosti, dok minimalizirate napore refaktoriranja. Također olakšava upravljanje i pruža uvid u to koje vanjske usluge vaša tvrtka koristi.

Nastavak uskoro...

Neki oglasi 🙂

Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, cloud VPS za programere od 4.99 USD, jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: Cijela istina o VPS (KVM) E5-2697 v3 (6 jezgri) 10GB DDR4 480GB SSD 1Gbps od 19 USD ili kako podijeliti poslužitelj? (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).

Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV od 199 USD u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o Kako izgraditi infrastrukturu corp. klase uz korištenje Dell R730xd E5-2650 v4 servera vrijednih 9000 eura za lipu?

Izvor: www.habr.com

Dodajte komentar