Если вы похожи на большинство людей, то, скорее всего используете ресурсы, функционирующие за пределами вашего кластера. Возможно, вы используете 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 довольно прозрачно выполняет переназначение портов.
Маппинг, или сопоставление внешних ресурсов с внутренними, дает вам возможность гибко использовать эти службы внутри кластера в будущем при минимизации усилий по рефакторингу. Он также облегчает управление и дает понимание того, какими внешними сервисами пользуется ваша компания.
Va continua foarte curand...
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com