Най-добрите практики на Kubernetes. Картографиране на външни услуги

Най-добри практики на Kubernetes. Създаване на малки контейнери
Най-добри практики на Kubernetes. Kubernetes организация с пространство от имена
Най-добри практики на Kubernetes. Проверка на изправността на Kubernetes с тестове за готовност и жизненост
Най-добри практики на Kubernetes. Задаване на заявки за ресурси и ограничения
Най-добри практики на Kubernetes. Правилно изключване Прекратяване

Ако сте като повечето хора, вероятно използвате ресурси, които работят извън вашия клъстер. Може би използвате API на Taleo, за да изпращате текстови съобщения или да анализирате изображения с помощта на API на Google Cloud Vision.

Ако използвате една и съща крайна точка на заявка от страна на сървъра във всичките си среди и не планирате да мигрирате сървърите си към Kubernetes, тогава е напълно добре да имате крайна точка на услуга точно във вашия код. Има обаче много други сценарии за развитие на събитията. В тази серия от най-добри практики на Kubernetes ще научите как да използвате вградените механизми на Kubernetes за откриване на услуги както вътре, така и извън клъстера.

Пример за обща външна услуга е база данни, работеща извън клъстер на Kubernetes. За разлика от облачните бази данни като Google Cloud Data Store или Google Cloud Spanner, които използват една крайна точка за целия достъп, повечето бази данни имат отделни крайни точки за различни обстоятелства.
Най-добрите практики за използване на традиционни бази данни като MySQL и MongoDB обикновено означават, че се свързвате с различни компоненти за различни среди. Можете да имате голяма машина за производствени данни и по-малка машина за тестовата среда. Всеки от тях ще има свой собствен IP адрес или име на домейн, но вероятно няма да искате да променяте кода си, когато преминавате от една среда в друга. Така че вместо да кодирате твърдо тези адреси, можете да използвате вграденото на Kubernetes откриване на външни услуги, базирано на DNS, по същия начин, както родните услуги на Kubernetes.

Да приемем, че работите с база данни MongoDB на Google Compute Engine. Ще останете в този хибриден свят, докато не успеете да го прехвърлите в клъстера.

За щастие можете да използвате статични услуги на Kubernetes, за да направите живота си малко по-лесен. В този пример създадох MongoDB сървър с помощта на Google Cloud Launcher. Тъй като е създаден в същата мрежа (или Kubernetes cluster VPC), достъпът до него се осъществява чрез високопроизводителен вътрешен IP адрес.

Това е настройката по подразбиране в Google Cloud, така че не е нужно да конфигурирате нищо. След като вече имате IP адрес, първата стъпка е да създадете услуга. Може да забележите, че няма селектори на под за тази услуга. Тоест създадохме услуга, която няма да знае къде да изпрати трафик. Това ще ви позволи ръчно да създадете обект на крайна точка, който ще получава трафик от тази услуга.

Следният пример на код показва, че крайните точки определят IP адреса за базата данни, използвайки същото име на mongo като услугата.

Kubernetes ще използва всички IP адреси, за да намери крайни точки, сякаш са обикновени Kubernetes Pods, така че сега можете да осъществите достъп до базата данни с обикновен низ за свързване към горното име mongodb://mongo. Изобщо не е необходимо да използвате IP адреси във вашия код.

Ако IP адресите се променят в бъдеще, можете просто да актуализирате вашите крайни точки с новия IP адрес и вашите приложения няма да трябва да бъдат модифицирани по никакъв допълнителен начин.

Ако използвате база данни, хоствана на хост на трета страна, вероятно е собствениците на хоста да са ви предоставили URI на унифициран ресурсен идентификатор, към който да се свържете. Така че, ако ви е даден IP адрес, можете просто да използвате предишния метод. Този пример показва, че имам две бази данни MongoDB, хоствани на mLab хост.

Едната е базата данни на разработчиците, а другата е производствената база данни. Низовете за връзка за тези бази данни изглеждат така - mLab ви предоставя динамичен URI и динамичен порт. Както виждате, те са различни.

За да се абстрахираме от това, нека използваме Kubernetes и се свържем с базата данни на разработчиците. Можете да създадете име на външна услуга на Kubernetes, което ще ви даде статична услуга, която ще препраща трафик към външната услуга.

Тази услуга ще извърши просто CNAME пренасочване на ниво ядро ​​с минимално въздействие върху производителността. Благодарение на това можете да използвате по-прост низ за свързване.

Но тъй като външното име използва CNAME пренасочване, то не може да извърши пренасочване на портове. Следователно това решение е приложимо само за статични портове и не може да се използва с динамични портове. Но mLab Free Tier дава на потребителя динамичен номер на порт по подразбиране и не можете да го промените. Това означава, че имате нужда от различни командни редове за връзка за dev и prod. Лошото е, че това ще изисква да кодирате твърдо номера на порта. И така, как да накарате препращането на порт да работи?

Първата стъпка е да получите IP адреса от URI. Ако стартирате nslookup, име на хост или ping URI, можете да получите IP адреса на базата данни. Ако услугата ви върне няколко IP адреса, тогава всички тези адреси могат да се използват в крайните точки на обекта.

Едно нещо, което трябва да имате предвид е, че IP URI могат да се променят без предупреждение, което ги прави доста рисковани за използване в прод. Използвайки този IP адрес, можете да се свържете с отдалечена база данни, без да посочвате порт. По този начин услугата Kubernetes извършва пренасочване на портове доста прозрачно.

Картографирането или картографирането на външни ресурси към вътрешни ви дава гъвкавостта да използвате тези услуги в рамките на клъстера в бъдеще, като минимизирате усилията за рефакторинг. Освен това улеснява управлението и предоставя представа какви външни услуги използва вашата компания.

Продължение съвсем скоро...

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com