Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Pratîkên çêtirîn ên Kubernetes. Afirandina konteynerên piçûk
Pratîkên çêtirîn ên Kubernetes. Rêxistina Kubernetes bi navan
Pratîkên çêtirîn ên Kubernetes. Bi Testên Amadekarî û Zindîtiya Kubernetes Liveness verastkirin
Pratîkên çêtirîn ên Kubernetes. Sazkirina daxwazên çavkaniyê û sînorên
Pratîkên çêtirîn ên Kubernetes. Girtina Rast Biqede

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

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Предположим, что вы запускаете базу данных MongoDB в Google Compute Engine. Вы застрянете в этом гибридном мире до того момента, пока вам не удастся перенести ее в кластер.

К счастью, вы можете использовать статические сервисы Kubernetes, чтобы хоть немного облегчить себе жизнь. В этом примере я создал сервер MongoDB, используя Google Cloud Launcher. Так как он создан в той же сети (или VPC кластера Kubernetes), то доступ к нему осуществляется с помощью высокопроизводительного внутреннего IP-адреса.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

В Google Cloud это настройка по умолчанию, так что вам не надо ничего настраивать. Теперь, когда есть IP-адрес, первый шаг заключается в создании сервиса. Можно заметить, что для этого сервиса нет никаких селекторов подов. То есть мы создали службу, которая не будет знать, куда посылать трафик. Это позволит вручную создать endpoint объект, который и будет получать трафик от данного сервиса.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Следующий пример кода показывает, что конечные точки определяют IP-адрес для базы данных, используя то же самое имя mongo, что и сервис.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Kubernetes будет использовать все IP-адреса, чтобы найти конечные точки, как если бы они были обычными подами Kubernetes, так что теперь вы можете получить доступ к базе данных с помощью простой строки подключения к вышеуказанному имени mongodb://mongo. При этом вообще нет необходимости использовать IP-адреса в вашем коде.

Если же в будущем IP-адреса изменятся, можно просто обновить конечные точки с помощью нового IP-адреса, и ваши приложения не нужно будет изменять каким-то дополнительным образом.

Если вы используете базу данных, размещенную на стороннем хосте, то, скорее всего, владельцы хоста предоставили вам для подключения унифицированный идентификатор ресурса URI. Так что если вам дали IP-адрес, можно просто воспользоваться предыдущим методом. Данный пример показывает, что у меня имеются две базы данных MongoDB, размещенные на хосте mLab.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Один из них — это база данных разработчиков, а другая – БД продакшена. Строки подключения для этих баз данных выглядят следующим образом — mLab предоставляет вам динамический URI и динамический порт. Как видите, они разные.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Чтобы абстрагироваться от этого, используем Kubernetes и подключимся к базе данных разработчиков. Вы можете создать внешнее имя сервиса Kubernetes, что предоставит вам статичный сервис, который будет перенаправлять трафик внешнему сервису.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Этот сервис выполнит простую CNAME переадресацию на уровне ядра, что окажет минимальное влияние на производительность. Благодаря этому вы можете использовать более простую строку подключения.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Но поскольку внешнее имя использует перенаправление CNAME, оно не может выполнить переназначение портов. Поэтому данное решение применимо только для статических портов и не может использоваться с динамическими портами. Но бесплатный mLab Free Tier по умолчанию предоставляет пользователю динамический номер порта, и вы не можете это изменить. Это означает, что для dev и prod вам нужны разные командные строки соединения. Плохо то, что при этом понадобится жестко закодировать номер порта. Так как же заставить работать переназначение портов?

Первый шаг — это получение IP-адреса из URI. Если выполнить команду nslookup, hostname или пропинговать URI, можно получить IP-адрес базы данных. Если при этом сервис возвращает вам несколько IP-адресов, то все эти адреса можно использовать в конечных точках объекта.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

Нужно помнить, что IP-адреса URI могут измениться без предварительного уведомления, так их довольно рискованно использовать в prod. C помощью такого IP-адреса можно подключиться к удаленной базе данных, не указывая при этом порт. Таким образом, сервис Kubernetes довольно прозрачно выполняет переназначение портов.

Pratîkên çêtirîn ên Kubernetes. Nexşeya karûbarên derveyî

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

Di demek nêzîk de dê berdewam bike...

Hin reklam 🙂

Spas ji bo ku hûn bi me re bimînin. Ma hûn ji gotarên me hez dikin? Ma hûn dixwazin naveroka balkêştir bibînin? Piştgiriya me bikin bi danîna fermanek an pêşniyarkirina hevalan, ewr VPS ji bo pêşdebiran ji 4.99 $, analogek bêhempa ya pêşkêşkerên asta têketinê, ku ji hêla me ve ji bo we hatî vedîtin: Tevahiya rastiyê di derbarê VPS (KVM) E5-2697 v3 (6 Cores) 10 GB DDR4 480 GB SSD 1Gbps ji 19 $ an çawa serverek parve dike? (bi RAID1 û RAID10, heta 24 core û heya 40 GB DDR4 peyda dibe).

Dell R730xd 2x erzantir li navenda daneya Equinix Tier IV li Amsterdam? Tenê li vir 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ji 199$ li Hollanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ji $99! Li ser bixwînin Meriv çawa pargîdaniya binesaziyê ava dike. pola bi karanîna serverên Dell R730xd E5-2650 v4 bi nirxek 9000 euro ji bo quruşek?

Source: www.habr.com

Add a comment