Pokud jste jako většina lidí, pravděpodobně používáte prostředky, které běží mimo váš cluster. Možná používáte Taleo API k odesílání textových zpráv nebo k analýze obrázků pomocí Google Cloud Vision API.
Pokud ve všech svých prostředích používáte stejný koncový bod požadavku na straně serveru a neplánujete migraci serverů na Kubernetes, je naprosto v pořádku mít koncový bod služby přímo ve svém kódu. Existuje však mnoho dalších scénářů vývoje událostí. V této sérii Kubernetes Best Practices se dozvíte, jak používat vestavěné mechanismy Kubernetes k objevování služeb uvnitř i vně clusteru.
Příkladem běžné externí služby je databáze běžící mimo cluster Kubernetes. Na rozdíl od cloudových databází jako Google Cloud Data Store nebo Google Cloud Spanner, které pro veškerý přístup používají jeden koncový bod, má většina databází samostatné koncové body pro různé okolnosti.
Osvědčené postupy pro používání tradičních databází, jako je MySQL a MongoDB, obvykle znamenají, že se připojujete k různým komponentám pro různá prostředí. Můžete mít velký stroj pro produkční data a menší stroj pro testovací prostředí. Každý z nich bude mít svou vlastní IP adresu nebo název domény, ale pravděpodobně nebudete chtít měnit svůj kód při přechodu z jednoho prostředí do druhého. Takže místo pevného kódování těchto adres můžete použít vestavěné zjišťování externích služeb Kubernetes založené na DNS stejným způsobem jako nativní služby Kubernetes.
Řekněme, že provozujete databázi MongoDB na Google Compute Engine. V tomto hybridním světě uvíznete, dokud se vám ho nepodaří přenést do clusteru.
Naštěstí můžete použít statické služby Kubernetes, které vám usnadní život. V tomto příkladu jsem vytvořil server MongoDB pomocí Google Cloud Launcher. Protože je vytvořen ve stejné síti (nebo Kubernetes clusteru VPC), je k němu přistupováno pomocí vysoce výkonné interní IP adresy.
Toto je výchozí nastavení ve službě Google Cloud, takže nemusíte nic konfigurovat. Nyní, když máte IP adresu, je prvním krokem vytvoření služby. Můžete si všimnout, že pro tuto službu neexistují žádné selektory podů. To znamená, že jsme vytvořili službu, která nebude vědět, kam má posílat provoz. To vám umožní ručně vytvořit objekt koncového bodu, který bude přijímat provoz z této služby.
Následující příklad kódu ukazuje, že koncové body určují IP adresu databáze pomocí stejného mongo názvu jako služba.
Kubernetes použije všechny IP adresy k nalezení koncových bodů, jako by to byly běžné Kubernetes Pody, takže nyní můžete přistupovat k databázi pomocí jednoduchého připojovacího řetězce s výše uvedeným názvem mongodb://mongo. V kódu není vůbec potřeba používat IP adresy.
Pokud se IP adresy v budoucnu změní, můžete jednoduše aktualizovat své koncové body pomocí nové IP adresy a vaše aplikace nebude třeba nijak dále upravovat.
Pokud používáte databázi hostovanou na hostiteli třetí strany, je pravděpodobné, že vlastníci hostitele vám poskytli identifikátor URI Uniform Resource Identifier, ke kterému se můžete připojit. Pokud jste tedy dostali IP adresu, můžete jednoduše použít předchozí metodu. Tento příklad ukazuje, že mám dvě databáze MongoDB hostované na hostiteli mLab.
Jedna je databáze vývojářů a druhá je produkční databáze. Připojovací řetězce pro tyto databáze vypadají takto – mLab vám poskytuje dynamické URI a dynamický port. Jak vidíte, jsou různé.
Abychom to odstranili, použijme Kubernetes a připojte se k vývojářské databázi. Můžete vytvořit název externí služby Kubernetes, který vám poskytne statickou službu, která bude předávat provoz na externí službu.
Tato služba bude provádět jednoduché předávání CNAME na úrovni jádra s minimálním dopadem na výkon. Díky tomu můžete použít jednodušší spojovací řetězec.
Ale protože externí název používá přesměrování CNAME, nemůže provádět přesměrování portů. Proto je toto řešení použitelné pouze pro statické porty a nelze jej použít s dynamickými porty. Ale mLab Free Tier dává uživateli ve výchozím nastavení dynamické číslo portu a nemůžete ho změnit. To znamená, že pro dev a prod potřebujete různé příkazové řádky připojení. Špatná věc je, že to bude vyžadovat pevné zakódování čísla portu. Jak tedy zprovoznit přesměrování portů?
Prvním krokem je získání IP adresy z URI. Pokud spustíte nslookup, název hostitele nebo ping na URI, můžete získat IP adresu databáze. Pokud vám služba vrátí několik IP adres, pak všechny tyto adresy lze použít na koncových bodech objektu.
Jedna věc, kterou je třeba mít na paměti, je, že IP URI se mohou bez upozornění změnit, takže jejich použití v prod je značně riskantní. Pomocí této adresy IP se můžete připojit ke vzdálené databázi bez zadání portu. Služba Kubernetes tedy přesměrování portů provádí zcela transparentně.
Mapování nebo mapování externích zdrojů na interní vám dává flexibilitu při používání těchto služeb v rámci clusteru v budoucnu a zároveň minimalizuje úsilí o refaktoring. Usnadňuje také správu a poskytuje přehled o tom, jaké externí služby vaše společnost používá.
Pokračování již brzy...
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com