Ha hasonlít a legtöbb emberre, valószínűleg olyan erőforrásokat használ, amelyek a klaszteren kívül működnek. Lehet, hogy a Taleo API-t használja szöveges üzenetek küldésére, vagy a Google Cloud Vision API segítségével elemzi a képeket.
Ha ugyanazt az endpoint végpontot használja - a szerver oldali kérésfeldolgozás helyét az összes környezetében, és nem tervezi a szerverek Kubernetes-be való áthelyezését, akkor teljesen normális, hogy a szolgáltatás végpontja a kódjában van. Azonban számos egyéb forgatókönyv létezik. A "Kubernetes Legjobb Gyakorlatok" sorozatban megtudhatja, hogyan használhatja a Kubernetes beépített mechanizmusait a szolgáltatások felfedezésére, akár a klaszteren belül, akár kívül.
Példaként említhetjük egy széles körben használt külső szolgáltatást, amely egy adatbázis, amely a Kubernetes klaszteren kívül működik. A Google Cloud Data Store vagy a Google Cloud Spanner esetében, amelyek egyetlen végpontot használnak minden hozzáférési módhoz, a legtöbb adatbázisnak külön végpontjai vannak különböző körülmények esetén.
A hagyományos adatbázisok, mint a MySQL és MongoDB használatának legjobb gyakorlata általában azt javasolja, hogy különböző komponensekhez csatlakozzon a különböző környezetekhez. Lehet, hogy egy nagy gépe van a termelési adatokhoz, és egy kisebb a tesztkörnyezethez. Mindegyiknek saját IP címe vagy domain neve lesz, de valószínűleg nem szeretné megváltoztatni a kódját, amikor egyik környezetről a másikra vált. Ezért a címek keménykódolása helyett használhatja a Kubernetes beépített szolgáltatásait a külső szolgáltatások DNS alapú felfedezésére, pontosan úgy, ahogyan a Kubernetes natív szolgáltatásai esetében is.
Tegyük fel, hogy MongoDB adatbázist futtat a Google Compute Engine-en. Ebben a hibrid világban ragad meg, amíg nem sikerül áthelyezni a klaszterre.
Szerencsére használhat statikus Kubernetes szolgáltatásokat, hogy egy kicsit megkönnyítse a dolgát. Ebben a példában létrehoztam egy MongoDB szervert a Google Cloud Launcher használatával. Mivel ugyanabban a hálózatban (vagy a Kubernetes klaszter VPC-jében) készült, hozzáférése nagy teljesítményű belső IP címmel történik.
A Google Cloud-ban ez az alapértelmezett beállítás, így nem kell semmit konfigurálni. Most, hogy van IP-cím, az első lépés egy szolgáltatás létrehozása. Észreveheti, hogy ehhez a szolgáltatáshoz nincsenek pod kiválasztók. Ez azt jelenti, hogy létrehoztunk egy szolgáltatást, amely nem tudja, hová küldje a forgalmat. Ez lehetővé teszi, hogy manuálisan hozzon létre egy endpoint objektumot, amely megkapja a forgalmat a szolgáltatásból.
A következő kódrészlet azt mutatja, hogy a végpontok az IP-címet a mongo nevű adatbázis számára határozzák meg, amely megegyezik a szolgáltatás nevével.
A Kubernetes az összes IP-címet használni fogja a végpontok megtalálásához, mintha azok szokásos Kubernetes podok lennének, így most egy egyszerű kapcsolati sorral érheti el az adatbázist a fent említett névvel mongodb://mongo. Ezzel egyáltalán nem szükséges IP-címeket használnia a kódjában.
Ha a jövőben az IP-címek megváltoznak, egyszerűen frissítheti a végpontokat az új IP-címmel, és az alkalmazásait nem kell külön módosítani.
Ha harmadik fél által hosztolt adatbázist használ, valószínűleg a hoszt tulajdonosai egy egységes erőforrás-azonosítót (URI) adtak meg a csatlakozáshoz. Tehát ha IP-címet kapott, egyszerűen használhatja a korábbi módszert. Ez a példa azt mutatja, hogy két MongoDB adatbázisom van, amelyet az mLab hosztol.
Az egyik a fejlesztői adatbázis, a másik pedig a termelési adatbázis. Ezek kapcsolatainak sora a következőképpen néz ki — az mLab dinamikus URI-t és dinamikus portot biztosít. Ahogy látja, ezek különböznek.
Ennek elkerülésére a Kubernetes-t használjuk, és csatlakozunk a fejlesztői adatbázishoz. Létrehozhat egy külső Kubernetes szolgáltatásnevet, amely statikus szolgáltatást biztosít, ami átirányítja a forgalmat egy külső szolgáltatásra.
Ez a szolgáltatás egy egyszerű CNAME átirányítást hajt végre a kernel szinten, ami minimális hatással lesz a teljesítményre. Ennek köszönhetően egyszerűbb kapcsolati sort használhat.
Mivel a külső név CNAME-átirányítást használ, nem tud portokat újraolvasni. Ezért ez a megoldás csak statikus portokra alkalmazható, és nem használható dinamikus portokkal. Az ingyenes mLab Free Tier alapértelmezetten dinamikus portszámot biztosít a felhasználónak, és ezt nem lehet megváltoztatni. Ez azt jelenti, hogy a dev és prod esetében különböző csatlakozási parancssorok szükségesek. Sajnos ez azt is jelenti, hogy a portszámot keményen kell kódolni. Hogyan lehet tehát működésbe helyezni a portátirányítást?
Az első lépés a IP-cím megszerzése az URI-ból. Ha végrehajtja az nslookup parancsot, hostname-t vagy pingel egy URI-t, megkaphatja az adatbázis IP-címét. Ha a szolgáltatás több IP-címet ad vissza, akkor mindezeket a címeket felhasználhatja az objektum végpontjaiban.
Fontos megjegyezni, hogy az URI IP-címek bármikor előzetes értesítés nélkül megváltozhatnak, ezért elég kockázatos őket használnia a prod környezetben. Az ilyen IP-cím segítségével csatlakozhat egy távoli adatbázishoz anélkül, hogy megadná a portot. Így a Kubernetes szolgáltatás viszonylag áttetszően hajtja végre a portátirányítást.
A leképezés, vagyis a külső erőforrások belső erőforrásokkal való összekapcsolása lehetővé teszi, hogy ezeket a szolgáltatásokat a klaszterben rugalmasan használja a jövőben, minimalizálva a refaktoráláshoz szükséges erőfeszítéseket. Ez megkönnyíti a kezelésüket és megértést ad arról, hogy a vállalata milyen külső szolgáltatásokat használ.
A folytatás hamarosan érkezik...
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
