Лучшие практики Kubernetes. Маппинг внешних сервисов

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate

Если вы похожи на большинство людей, то, скорее всего используете ресурсы, функционирующие за пределами вашего кластера. Возможно, вы используете 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. C помощью такого IP-адреса можно подключиться к удаленной базе данных, не указывая при этом порт. Таким образом, сервис Kubernetes довольно прозрачно выполняет переназначение портов.

Маппинг, или сопоставление внешних ресурсов с внутренними, дает вам возможность гибко использовать эти службы внутри кластера в будущем при минимизации усилий по рефакторингу. Он также облегчает управление и дает понимание того, какими внешними сервисами пользуется ваша компания.

Продолжение будет совсем скоро…

Немного рекламы 🙂

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Источник: habr.com