Якщо ви схожі на більшість людей, то, швидше за все, використовуєте ресурси, що функціонують за межами вашого кластера. Можливо, ви використовуєте API Taleo для надсилання текстових повідомлень або аналізуєте зображення за допомогою API Google Cloud Vision.
Якщо ви використовуєте ту саму кінцеву точку endpoint — точку прийому запитів на стороні сервера у всіх своїх середовищах і не плануєте переносити свої сервери в Kubernetes, то цілком нормально мати endpoint сервісу прямо у вашому коді. Проте є безліч інших сценаріїв розвитку подій. У цій серії «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-адреса, перший крок полягає у створенні сервісу. Можна зауважити, що для цього сервісу немає ніяких селекторів подів. Тобто ми створили службу, яка не знатиме, куди надсилати трафік. Це дозволить вручну створити endpoint об'єкт, який і отримуватиме трафік від цього сервісу.
Наступний приклад коду показує, що кінцеві точки визначають 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, hostname або пропінгувати 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