Егер сіз көптеген адамдар сияқты болсаңыз, кластеріңізден тыс жұмыс істейтін ресурстарды пайдаланып жатқан боларсыз. Google Cloud Vision API арқылы мәтіндік хабарларды жіберу немесе кескіндерді талдау үшін Taleo API пайдалануыңыз мүмкін.
Егер сіз барлық орталарыңызда бірдей серверлік сұраудың соңғы нүктесін пайдалансаңыз және серверлеріңізді Kubernetes-ке көшіруді жоспарламасаңыз, кодыңызда қызмет көрсетудің соңғы нүктесінің болуы өте жақсы. Дегенмен, оқиғаларды дамытудың көптеген басқа сценарийлері бар. Осы Kubernetes үздік тәжірибелер сериясында сіз кластердің ішінде және одан тыс қызметтерді табу үшін Kubernetes-тің кірістірілген механизмдерін пайдалану жолын үйренесіз.
Жалпы сыртқы қызметтің мысалы Kubernetes кластерінен тыс жұмыс істейтін дерекқор болып табылады. Барлық кіру үшін бір соңғы нүктені пайдаланатын Google Cloud Data Store немесе Google Cloud Spanner сияқты бұлттық дерекқорлардан айырмашылығы, көптеген дерекқорларда әртүрлі жағдайлар үшін бөлек соңғы нүктелер болады.
MySQL және MongoDB сияқты дәстүрлі дерекқорларды пайдаланудың ең жақсы тәжірибелері әдетте әртүрлі орталар үшін әртүрлі құрамдастарға қосылуды білдіреді. Сізде өндіріс деректері үшін үлкен машина және сынақ ортасы үшін кішірек машина болуы мүмкін. Олардың әрқайсысының жеке IP мекенжайы немесе домен атауы болады, бірақ сіз бір ортадан екіншісіне ауысқан кезде кодты өзгерткіңіз келмейтін шығар. Сондықтан бұл мекенжайларды қатаң кодтаудың орнына, Kubernetes-тің кірістірілген DNS негізіндегі сыртқы қызметті табуын жергілікті Kubernetes қызметтері сияқты пайдалануға болады.
Сіз Google Compute Engine жүйесінде MongoDB дерекқорын іске қосып жатырсыз делік. Сіз оны кластерге көшіргенше осы гибридті әлемде тұрып қаласыз.
Бақытымызға орай, сіз өміріңізді жеңілдету үшін статикалық Kubernetes қызметтерін пайдалана аласыз. Бұл мысалда мен Google Cloud Launcher көмегімен MongoDB серверін жасадым. Ол бір желіде (немесе Kubernetes кластері VPC) жасалғандықтан, оған өнімділігі жоғары ішкі IP мекенжайы арқылы қол жеткізіледі.
Бұл Google Cloud жүйесіндегі әдепкі параметр, сондықтан ештеңені конфигурациялаудың қажеті жоқ. Енді сізде IP мекенжайы бар, бірінші қадам - қызметті жасау. Сіз бұл қызмет үшін подколь селекторлары жоқ екенін байқауыңыз мүмкін. Яғни, біз трафикті қайда жіберу керектігін білмейтін сервис жасадық. Бұл осы қызметтен трафикті қабылдайтын соңғы нүкте нысанын қолмен жасауға мүмкіндік береді.
Келесі код мысалы соңғы нүктелер қызметпен бірдей mongo атауын пайдаланып дерекқордың IP мекенжайын анықтайтынын көрсетеді.
Kubernetes соңғы нүктелерді табу үшін барлық IP мекенжайларын кәдімгі Kubernetes Pods сияқты пайдаланады, сондықтан енді дерекқорға жоғарыдағы mongodb://mongo атауына қарапайым қосылым жолы арқылы қол жеткізе аласыз. Кодыңызда IP мекенжайларын пайдаланудың қажеті жоқ.
Болашақта IP мекенжайлары өзгерсе, соңғы нүктелерді жаңа IP мекенжайымен жаңарта аласыз және қолданбаларды ешқандай қосымша жолмен өзгерту қажет болмайды.
Үшінші тарап хостында орналастырылған дерекқорды пайдалансаңыз, хост иелері қосылу үшін сізге Бірыңғай ресурс идентификаторының URI мекенжайын берген болуы мүмкін. Сондықтан сізге IP мекенжайы берілген болса, сіз жай ғана алдыңғы әдісті пайдалана аласыз. Бұл мысал менде mLab хостында орналастырылған екі MongoDB дерекқоры бар екенін көрсетеді.
Біреуі – әзірлеушілер базасы, екіншісі – өндірістік деректер базасы. Бұл дерекқорларға арналған қосылым жолдары келесідей көрінеді - mLab сізге динамикалық URI және динамикалық портты ұсынады. Көріп отырғаныңыздай, олар әртүрлі.
Мұны жою үшін Kubernetes қолданбасын қолданып, әзірлеушілер дерекқорына қосылайық. Сыртқы Kubernetes қызметінің атауын жасауға болады, ол сізге трафикті сыртқы қызметке бағыттайтын статикалық қызметті береді.
Бұл қызмет ең аз өнімділік әсерімен ядро деңгейінде қарапайым CNAME қайта жіберуді орындайды. Осының арқасында сіз қарапайым қосылым жолын пайдалана аласыз.
Бірақ сыртқы атау CNAME қайта бағыттауды пайдаланатындықтан, ол портты қайта жіберуді орындай алмайды. Сондықтан бұл шешім тек статикалық порттар үшін ғана жарамды және динамикалық порттармен бірге қолданыла алмайды. Бірақ mLab Free Tier пайдаланушыға әдепкі бойынша динамикалық порт нөмірін береді және оны өзгерте алмайсыз. Бұл сізге әзірлеуші және өнім үшін әртүрлі қосылым пәрмен жолдары қажет екенін білдіреді. Ең жаманы, бұл порт нөмірін қатты кодтауды талап етеді. Сонымен, портты қайта жіберуді жұмысқа қалай алуға болады?
Бірінші қадам - URI мекенжайынан IP мекенжайын алу. Егер nslookup, хост атын немесе URI пингін іске қоссаңыз, дерекқордың IP мекенжайын алуға болады. Егер қызмет сізге бірнеше IP мекенжайларын қайтарса, онда бұл мекенжайлардың барлығын нысанның соңғы нүктелерінде пайдалануға болады.
Есте сақтау керек нәрсе - IP URI-лер ескертусіз өзгертілуі мүмкін, бұл оларды өнімде пайдалану өте қауіпті етеді. Осы IP мекенжайын пайдаланып, қашықтағы дерекқорға портты көрсетпей қосылуға болады. Осылайша, Kubernetes қызметі портты қайта жіберуді өте ашық түрде орындайды.
Сыртқы ресурстарды ішкі ресурстармен салыстыру немесе салыстыру сізге болашақта осы қызметтерді кластер ішінде пайдалану икемділігін береді, сонымен бірге рефакторинг әрекеттерін азайтады. Ол сондай-ақ басқаруды жеңілдетеді және компанияңыздың қандай сыртқы қызметтерді пайдаланатыны туралы түсінік береді.
Жақында жалғасын табады...
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз,
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында
Ақпарат көзі: www.habr.com