Ak ste ako väčšina ľudí, pravdepodobne používate prostriedky, ktoré bežia mimo vášho klastra. Možno používate Taleo API na odosielanie textových správ alebo analyzovanie obrázkov pomocou Google Cloud Vision API.
Ak používate rovnaký koncový bod požiadaviek na strane servera vo všetkých svojich prostrediach a neplánujete migrovať svoje servery na Kubernetes, potom je úplne v poriadku mať koncový bod služby priamo vo svojom kóde. Existuje však mnoho ďalších scenárov vývoja udalostí. V tejto sérii osvedčených postupov Kubernetes sa naučíte, ako používať vstavané mechanizmy Kubernetes na objavovanie služieb vo vnútri aj mimo klastra.
Príkladom bežnej externej služby je databáza spustená mimo klastra Kubernetes. Na rozdiel od cloudových databáz, ako je Google Cloud Data Store alebo Google Cloud Spanner, ktoré používajú jeden koncový bod pre všetky prístupy, väčšina databáz má samostatné koncové body pre rôzne okolnosti.
Osvedčené postupy používania tradičných databáz, ako sú MySQL a MongoDB, zvyčajne znamenajú, že sa pripájate k rôznym komponentom pre rôzne prostredia. Môžete mať veľký stroj na produkčné dáta a menší stroj na testovacie prostredie. Každý z nich bude mať svoju vlastnú IP adresu alebo názov domény, ale pravdepodobne nebudete chcieť zmeniť svoj kód pri prechode z jedného prostredia do druhého. Takže namiesto pevného kódovania týchto adries môžete použiť vstavané zisťovanie externých služieb založené na DNS od Kubernetes rovnakým spôsobom ako natívne služby Kubernetes.
Povedzme, že máte spustenú databázu MongoDB na Google Compute Engine. Budete uviaznutí v tomto hybridnom svete, kým sa vám ho nepodarí preniesť do klastra.
Našťastie môžete použiť statické služby Kubernetes, ktoré vám uľahčia život. V tomto príklade som vytvoril server MongoDB pomocou služby Google Cloud Launcher. Keďže je vytvorený v rovnakej sieti (alebo Kubernetes cluster VPC), pristupuje sa k nemu pomocou vysokovýkonnej internej IP adresy.
Toto je predvolené nastavenie v službe Google Cloud, takže nemusíte nič konfigurovať. Teraz, keď máte IP adresu, prvým krokom je vytvorenie služby. Môžete si všimnúť, že pre túto službu neexistujú žiadne selektory pod. To znamená, že sme vytvorili službu, ktorá nebude vedieť, kam má posielať návštevnosť. To vám umožní manuálne vytvoriť objekt koncového bodu, ktorý bude prijímať návštevnosť z tejto služby.
Nasledujúci príklad kódu ukazuje, že koncové body určujú IP adresu databázy pomocou rovnakého mongo názvu ako služba.
Kubernetes použije všetky IP adresy na nájdenie koncových bodov, ako keby to boli bežné Kubernetes Pody, takže teraz môžete pristupovať k databáze pomocou jednoduchého pripájacieho reťazca k vyššie uvedenému názvu mongodb://mongo. Vo svojom kóde vôbec nie je potrebné používať IP adresy.
Ak sa adresy IP v budúcnosti zmenia, môžete jednoducho aktualizovať svoje koncové body pomocou novej adresy IP a vaše aplikácie nebude potrebné nijako dodatočne upravovať.
Ak používate databázu hosťovanú na hostiteľovi tretej strany, je pravdepodobné, že vlastníci hostiteľa vám poskytli identifikátor URI Uniform Resource Identifier, ku ktorému sa môžete pripojiť. Takže ak ste dostali IP adresu, môžete jednoducho použiť predchádzajúci spôsob. Tento príklad ukazuje, že mám dve databázy MongoDB hosťované na hostiteľovi mLab.
Jedna je databáza vývojárov a druhá je produkčná databáza. Reťazce pripojenia pre tieto databázy vyzerajú takto – mLab vám poskytuje dynamické URI a dynamický port. Ako vidíte, sú rôzne.
Aby sme to odstránili, použite Kubernetes a pripojte sa k databáze vývojárov. Môžete si vytvoriť názov externej služby Kubernetes, ktorý vám poskytne statickú službu, ktorá bude posielať návštevnosť do externej služby.
Táto služba bude vykonávať jednoduché preposielanie CNAME na úrovni jadra s minimálnym dopadom na výkon. Vďaka tomu môžete použiť jednoduchší spojovací reťazec.
Ale pretože externý názov používa presmerovanie CNAME, nemôže vykonávať presmerovanie portov. Preto je toto riešenie použiteľné len pre statické porty a nemožno ho použiť s dynamickými portami. Mlab Free Tier však dáva používateľovi predvolene dynamické číslo portu a nemôžete ho zmeniť. To znamená, že potrebujete rôzne príkazové riadky pripojenia pre dev a prod. Zlá vec je, že to bude vyžadovať, aby ste napevno zakódovali číslo portu. Ako teda zabezpečiť, aby presmerovanie portov fungovalo?
Prvým krokom je získanie IP adresy z URI. Ak spustíte nslookup, názov hostiteľa alebo ping na URI, môžete získať IP adresu databázy. Ak vám služba vráti niekoľko IP adries, všetky tieto adresy možno použiť na koncových bodoch objektu.
Jedna vec, ktorú treba mať na pamäti, je, že IP URI sa môžu zmeniť bez predchádzajúceho upozornenia, takže ich použitie v prod je dosť riskantné. Pomocou tejto adresy IP sa môžete pripojiť k vzdialenej databáze bez zadania portu. Služba Kubernetes teda preposielanie portov vykonáva celkom transparentne.
Mapovanie alebo mapovanie externých zdrojov na interné vám dáva flexibilitu pri používaní týchto služieb v rámci klastra v budúcnosti a zároveň minimalizuje úsilie o refaktoring. Tiež uľahčuje správu a poskytuje prehľad o tom, aké externé služby vaša spoločnosť používa.
Pokračovanie už čoskoro...
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com