Kubernetes beschten Praktiken. Mapping vun externen Servicer

Kubernetes beschten Praktiken. Schafen kleng Container
Kubernetes beschten Praktiken. Organisatioun vu Kubernetes mat Nummraum
Kubernetes beschten Praktiken. Validéiere Kubernetes Liveness mat Bereetschaft a Liveness Tester
Kubernetes beschten Praktiken. Ressource Ufroen a Limiten opzestellen
Kubernetes beschten Praktiken. Korrekt Ausschalten Ofschloss

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

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

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Kubernetes beschten Praktiken. Mapping vun externen Servicer

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

Ganz geschwënn weiderféieren...

Puer Annoncen 🙂

Merci datt Dir bei eis bleift. Hutt Dir eis Artikelen gär? Wëllt Dir méi interessant Inhalt gesinn? Ënnerstëtzt eis andeems Dir eng Bestellung maacht oder Frënn empfeelt, Cloud VPS fir Entwéckler vun $ 4.99, en eenzegaartegen Analog vun Entry-Level Serveren, dee vun eis fir Iech erfonnt gouf: Déi ganz Wourecht iwwer VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps vun $19 oder wéi een e Server deelt? (verfügbar mat RAID1 an RAID10, bis zu 24 Kären a bis zu 40GB DDR4).

Dell R730xd 2 Mol méi bëlleg an Equinix Tier IV Daten Zentrum zu Amsterdam? Nëmmen hei 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV vun $199 an Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vun $99! Liest iwwer Wéi bauen ech Infrastructure Corp. Klass mat der Benotzung vun Dell R730xd E5-2650 v4 Serveren Wäert 9000 Euro fir e Penny?

Source: will.com

Setzt e Commentaire