Ha Ön is olyan, mint a legtöbb ember, valószínűleg olyan erőforrásokat használ, amelyek a klaszteren kívül futnak. Talán a Taleo API-t használja szöveges üzenetek küldésére vagy képek elemzésére a Google Cloud Vision API segítségével.
Ha ugyanazt a kiszolgálóoldali kérésvégpontot használja minden környezetben, és nem tervezi a kiszolgálók Kubernetes-be való áttelepítését, akkor teljesen rendben van, ha egy szolgáltatási végpont közvetlenül a kódban található. Az események alakulására azonban számos más forgatókönyv is létezik. Ebben a Kubernetes bevált gyakorlatai sorozatban megtudhatja, hogyan használhatja a Kubernetes beépített mechanizmusait a fürtön belüli és kívüli szolgáltatások felfedezéséhez.
Egy gyakori külső szolgáltatás például egy Kubernetes-fürtön kívül futó adatbázis. Ellentétben az olyan felhőalapú adatbázisokkal, mint a Google Cloud Data Store vagy a Google Cloud Spanner, amelyek egyetlen végpontot használnak minden hozzáféréshez, a legtöbb adatbázisnak külön végpontjai vannak a különböző körülményekhez.
A hagyományos adatbázisok, például a MySQL és a MongoDB használatára vonatkozó legjobb gyakorlatok általában azt jelentik, hogy a különböző környezetekhez különböző összetevőkhöz kell csatlakozni. Lehet egy nagy gép a termelési adatokhoz és egy kisebb gép a tesztkörnyezethez. Mindegyiknek saját IP-címe vagy tartományneve lesz, de valószínűleg nem akarja megváltoztatni a kódot, amikor egyik környezetből a másikba költözik. Így ezeknek a címeknek a kemény kódolása helyett használhatja a Kubernetes beépített DNS-alapú külső szolgáltatás-felderítését, ugyanúgy, mint a natív Kubernetes-szolgáltatásokat.
Tegyük fel, hogy MongoDB adatbázist futtat a Google Compute Engine-en. Addig ragadsz ebben a hibrid világban, amíg nem sikerül átvinned a klaszterbe.
Szerencsére statikus Kubernetes-szolgáltatásokat használhat, hogy egy kicsit megkönnyítse az életét. Ebben a példában létrehoztam egy MongoDB szervert a Google Cloud Launcher segítségével. Mivel ugyanazon a hálózaton (vagy Kubernetes-fürt VPC-n) hozták létre, nagy teljesítményű belső IP-címmel érhető el.
Ez a Google Cloud alapértelmezett beállítása, így nem kell semmit konfigurálnia. Most, hogy van IP-címe, az első lépés egy szolgáltatás létrehozása. Észreveheti, hogy ehhez a szolgáltatáshoz nincsenek pod-választók. Vagyis létrehoztunk egy szolgáltatást, amely nem fogja tudni, hogy hova küldje a forgalmat. Ez lehetővé teszi, hogy manuálisan hozzon létre egy végpont objektumot, amely forgalmat fogad ebből a szolgáltatásból.
A következő kódpélda azt mutatja, hogy a végpontok az adatbázis IP-címét ugyanazzal a mongo névvel határozzák meg, mint a szolgáltatás.
A Kubernetes az összes IP-címet felhasználja a végpontok megtalálásához, mintha azok szokványos Kubernetes Pod-ok lennének, így mostantól egy egyszerű kapcsolati karakterlánccal érheti el az adatbázist a mongodb://mongo névvel. Egyáltalán nem szükséges IP-címeket használni a kódban.
Ha az IP-címek a jövőben megváltoznak, egyszerűen frissítheti a végpontjait az új IP-címmel, és az alkalmazásait nem kell semmilyen további módon módosítani.
Ha harmadik féltől származó gazdagépen tárolt adatbázist használ, akkor valószínűleg a gazdagép tulajdonosai egy egységes erőforrás-azonosító URI-t adtak meg a csatlakozáshoz. Tehát ha kapott IP-címet, egyszerűen használhatja az előző módszert. Ez a példa azt mutatja, hogy két MongoDB adatbázisom van egy mLab gazdagépen.
Az egyik a fejlesztői adatbázis, a másik a termelési adatbázis. Ezeknek az adatbázisoknak a kapcsolati karakterláncai így néznek ki – az mLab dinamikus URI-t és dinamikus portot biztosít. Mint látható, különböznek egymástól.
Ennek kivonásához használjuk a Kuberneteset, és csatlakozzunk a fejlesztői adatbázishoz. Létrehozhat egy külső Kubernetes szolgáltatásnevet, amely egy statikus szolgáltatást ad, amely továbbítja a forgalmat a külső szolgáltatáshoz.
Ez a szolgáltatás egyszerű CNAME-továbbítást hajt végre a kernel szintjén, minimális teljesítményhatással. Ennek köszönhetően egyszerűbb kapcsolati karakterláncot használhat.
De mivel a külső név CNAME továbbítást használ, nem tud porttovábbítást végrehajtani. Ezért ez a megoldás csak statikus portokra alkalmazható, dinamikus portokkal nem használható. De az mLab Free Tier alapértelmezés szerint dinamikus portszámot ad a felhasználónak, és azt nem módosíthatja. Ez azt jelenti, hogy különböző kapcsolódási parancssorokra van szüksége a dev és a prod számára. A rossz dolog az, hogy ehhez meg kell kódolnia a portszámot. Tehát hogyan lehet működésbe hozni a porttovábbítást?
Az első lépés az IP-cím beszerzése az URI-ból. Ha az nslookup-ot, a gazdagépnevet vagy az URI-t pingeli, akkor megkaphatja az adatbázis IP-címét. Ha a szolgáltatás több IP-címet ad vissza, akkor ezek a címek mindegyike használható az objektum végpontjain.
Egy dolog, amit szem előtt kell tartani, az az, hogy az IP URI-k értesítés nélkül változhatnak, ami meglehetősen kockázatossá teszi őket a gyártás során. Ezzel az IP-címmel port megadása nélkül csatlakozhat egy távoli adatbázishoz. Így a Kubernetes szolgáltatás meglehetősen átláthatóan végzi a porttovábbítást.
A külső erőforrások leképezése vagy belső erőforrásokra való leképezése rugalmasságot biztosít Önnek, hogy a jövőben a fürtön belül használja ezeket a szolgáltatásokat, miközben minimálisra csökkenti az átalakítási erőfeszítéseket. Ezenkívül megkönnyíti a kezelést, és betekintést nyújt abba, hogy a vállalat milyen külső szolgáltatásokat vesz igénybe.
Folytatás hamarosan...
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com