Ако сте като повечето хора, вероятно използвате ресурси, които функционират извън вашия клъстер. Може би използвате API на Taleo за изпращане на текстови съобщения или анализирате изображения с API на Google Cloud Vision.
Ако използвате същата крайна точка — точка за приемане на заявки от сървъра във всички свои среди и не планирате да преместите сървърите си в Kubernetes, е съвсем нормално да имате крайна точка на услугата директно в кода си. Въпреки това, съществуват много други сценарии. В тази серия "Kubernetes Best Practices" ще научите как да използвате вградените механизми на Kubernetes за откриване на услуги както вътре, така и извън клъстера.
Като пример за широко използвана външна услуга може да се посочи база данни, работеща извън клъстера Kubernetes. За разлика от облачните бази данни, като Google Cloud Data Store или Google Cloud Spanner, които използват една крайна точка за всички видове достъп, повечето бази данни имат отделни крайни точки за различни обстоятелства.
Добра практика при използването на традиционни бази данни като MySQL и MongoDB обикновено предполага, че се свързвате с различни компоненти за различни среди. Може да имате мощна машина за продукционни данни и по-малка машина за тестова среда. Всяка от тях ще има собствен IP адрес или домейн, но определено не искате да променяте кода си, когато преминавате от една среда на друга. Затова вместо да кодировате директно тези адреси, можете да използвате вграденото в Kubernetes откритие на външни услуги на основата на DNS, точно както за нативни услуги на Kubernetes.
Представете си, че стартирате база данни MongoDB в Google Compute Engine. Ще се затворите в този хибриден свят, докато не успеете да я прехвърлите в клъстера.
За щастие, можете да използвате статични услуги в Kubernetes, за да си облекчите малко живота. В този пример създадох сървър MongoDB, използвайки Google Cloud Launcher. Тъй като е създаден в същата мрежа (или VPC на клъстера Kubernetes), достъпът до него се извършва чрез високопроизводителен вътрешен IP адрес.
В Google Cloud това е настройка по подразбиране, така че не е нужно да правите нищо. Сега, когато имате IP адрес, първата стъпка е създаването на услуга. Можете да забележите, че за тази услуга няма селектори на подове. Тоест, създали сме служба, която не знае къде да изпраща трафик. Това ще позволи на ръка да създадем обект на крайна точка, който ще получава трафик от тази услуга.
Следващият кодов пример показва, че крайните точки определят IP адрес за базата данни, използвайки същото име mongo, каквото е услугата.
Kubernetes ще използва всички IP адреси, за да намери крайните точки, сякаш са обикновени подове в Kubernetes, така че сега можете да получите достъп до базата данни с проста свързваща строка до посоченото име mongodb://mongo. При това няма нужда изобщо да използвате IP адреси в кода си.
Ако в бъдеще IP адресите се променят, можете просто да обновите крайните точки с новия IP адрес и няма нужда да изменяте приложенията по друг начин.
Ако използвате база данни, хоствана на трета страна, вероятно собствениците на хоста са ви предоставили унифициран идентификатор на ресурса URI за свързване. Така че, ако ви е даден IP адрес, можете просто да се възползвате от предишния метод. Този пример показва, че имам две MongoDB бази данни, хоствани на хоста mLab.
Едната е база данни за разработчици, а другата е базата данни за продукция. Стрингът за свързване за тези бази данни изглежда по следния начин – mLab ви предоставя динамичен URI и динамичен порт. Както виждате, те са различни.
За да абстрахираме от това, използваме Kubernetes и се свързваме с базата данни на разработчиците. Можете да създадете външно име на услугата Kubernetes, което ще ви предостави статична услуга, която ще пренасочва трафика към външната услуга.
Тази услуга ще извърши проста CNAME пренасочване на ядрото, което ще окаже минимално влияние на производителността. Благодарение на това можете да използвате по-проста строка за свързване.
Но тъй като външното име използва CNAME пренасочване, то не може да извърши преназначаване на портовете. Затова това решение е приложимо само за статични портове и не може да се използва с динамични портове. Безплатният mLab Free Tier по подразбиране предоставя на потребителя динамичен номер на порт, и не можете да го промените. Това означава, че за dev и prod са ви нужни различни команди за свързване. Лошото е, че ще е необходимо да зададете номера на порта в кода. Как да накарате пренасочването на портовете да работи?
Първата стъпка е да получите IP адреса от URI. Ако изпълните командата nslookup, хостимето или пингнете URI, можете да получите IP адреса на базата данни. Ако услугата ви върне няколко IP адреса, можете да използвате всички тези адреси в крайните точки на обекта.
Трябва да се помни, че IP адресите на URI могат да се променят без предварително уведомление, така че тяхното използване в prod е доста рисковано. С такъв IP адрес можете да се свържете с отдалечена база данни, без да посочвате порта. Така услугата Kubernetes прозрачно извършва пренасочване на портовете.
Мапингът, или съпоставянето на външни ресурси с вътрешни, ви дава възможност да използвате тези услуги гъвкаво в кластера в бъдеще, минимизирайки усилията за рефакторинг. Това също улеснява управлението и дава разбиране за това, какви външни услуги използва вашата компания.
Продължението ще бъде съвсем скоро…
Малко реклама 🙂
Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, , уникален аналог на entry-level сървъри, който е създаден от нас за вас: (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
