Лучшие практики Kubernetes. Организация Kubernetes с пространством имен

Лучшие практики Kubernetes. Создание небольших контейнеров

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

Давайте рассмотрим, как пространство имен namespace облегчает управление ресурсами Kubernetes. Итак, что же такое пространство имен? Namespace можно рассматривать как виртуальный кластер внутри вашего кластера Kubernetes. Вы можете иметь несколько изолированных друг от друга пространств имен внутри одного кластера Kubernetes. Они реально могут помочь вам и вашим командам с организацией, безопасностью и даже производительностью системы.

В большинстве дистрибутивов Kubernetes кластер «выходит из коробки» с пространством имен, имеющим название «default». На самом деле существует три пространства имен, с которыми Kubernetes имеет дело: default, kube-system и kube-public. В настоящее время Kube- public используется не так уж часто.

Не трогать пространство имен kube – хорошая идея, особенно в такой управляемой системе, как Google Kubernetes Engine. Она использует пространство имен «default» как место, в котором создаются ваши сервисы и приложения. В нем нет абсолютно ничего особенного, за исключением того, что Kubernetes «из коробки» настроен на его использование, и вы не можете его удалить. Это отлично подходит для начала работы и систем с небольшой производительностью, но я бы не рекомендовал использовать default namespace в больших prod-системах. В последнем случае одна команда разработчиков может легко переписать чужой код и нарушить работу другой команды, даже не осознавая этого.

Поэтому следует создать несколько пространств имен и использовать их для сегментации ваших услуг в управляемые звенья. Пространство имен можно создать с помощью одной команды. Если вы хотите создать пространство имен с именем test, то используйте команду $ kubectl create namespace test или просто создайте YAML-файл и используйте его, как любой другой ресурс Kubernetes.

Просмотреть все пространства имен можно с помощью команды $ kubectl get namespace.

После ее выполнения вы увидите три встроенных пространства имен и новое пространство имен под названием «test». Давайте рассмотрим простой YAML-файл, предназначенный для создания pod. Можно заметить, что в нем нет никакого упоминания о пространстве имен.

Если примените kubectl для запуска этого файла, он создаст модуль mypod в текущем активном пространстве имен. Это будет пространство имен по умолчанию, пока вы его не измените. Существует 2 способа сообщить Kubernetes, в каком пространстве имен вы хотите создать свой ресурс. Первый способ — это использование флага пространства имен при создании ресурса.

Второй способ заключается в указании пространства имен в декларации YAML.

Если вы укажете пространство имен в YAML, то ресурс всегда будет создаваться в этом пространстве. Если вы попытаетесь использовать другое пространство имен при использовании флага пространства имен, то команда завершится ошибкой. Теперь, если вы попытаетесь найти свой pod, то не сможете этого сделать.

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

Из коробки ваше активное пространство имен носит название default. Если вы не уточните пространство имен в YAML ресурса, то все команды Kubernetes будут использовать это активное default namespace. К сожалению, попытка управлять активным пространством имен с помощью kubectl может окончиться неудачей. Однако существует очень хороший инструмент под названием Kubens, который намного упрощает этот процесс. Когда вы запускаете команду kubens, то видите все пространства имен с подсвеченным активным пространством имен.

Для переключения активного пространства имен на пространство имен test вы просто запускаете команду $ kubens test. Если после этого снова ввести команду $ kubens, можно увидеть, что теперь выделено новое активное пространство имен – test.

Это означает, что вам не нужен флаг пространства имен, чтобы увидеть pod в пространстве имен test.

Таким образом пространства имен скрыты друг от друга, но не изолированы друг от друга. Сервис из одного namespace может довольно легко общаться с сервисом в другом пространстве имен, что часто бывает очень полезно. Возможность коммуникации между разными пространствами имен означает, что сервис ваших разработчиков может взаимодействовать с сервисом другой dev-команды в другом пространстве имен.

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

К счастью, это легко обойти, используя развернутую форму DNS-адреса. Сервисы в Kubernetes выставляют свои конечные точки, используя общий шаблон DNS. Это выглядит примерно так:

Как правило, вам просто нужно имя сервиса, и DNS автоматически определит полный адрес.

Однако если вам нужно получить доступ к сервису в другом пространстве имен, просто используйте имя службы плюс имя пространства имен:

Например, если вы хотите подключиться к базе данных сервиса в тестовом пространстве имен, вы можете использовать базу адресов database.test

Если же вы хотите подключиться к базе данных сервиса в пространстве имен prod, вы используете database.prod.

Если вы действительно хотите изолировать и ограничить доступ к пространству имен, Kubernetes позволяет сделать это с помощью сетевых политик Kubernetes Network Policies. Об этом я расскажу в следующей серии.

Мне часто задают вопрос, сколько пространств имен нужно создавать и для каких целей? Что же представляет собой управляемый фрагмент данных?

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

Представьте, что вы являетесь частью небольшой команды, которая работает над разработкой 5-10 микросервисов и вы легко можете собрать всех разработчиков в одной комнате. В данной ситуации имеет смысл запускать все prod-сервисы в пространстве имен default. Конечно, для большего простора действий вы можете использовать 2 пространства имен — отдельно для prod и dev. И вероятнее всего, вы тестируете свою разработку на локальном компьютере с помощью чего-то наподобие Minikube.

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

По мере того, как каждый из членов команды получает представление о том, как работает система в целом, координировать каждое изменение со всеми остальными разработчиками становится все труднее и труднее. Попытка раскрутить полный стек на вашем локальном компьютере с каждым днем становится сложнее.

В крупных компаниях разработчики вообще не знают, кто конкретно над чем работает. Команды общаются с помощью сервисных контрактов или используют технологию Service mesh, которая добавляет над сетью уровень абстракции, типа инструмента конфигурации Istio. Попытка запустить весь стек локально просто невозможна.Я настоятельно рекомендую использовать в Kubernetes такую платформу непрерывной доставки (CD), как Spinnaker. Итак, наступает момент, когда каждой команде определенно нужно собственное пространство имен. Каждая команда даже может выбрать несколько пространств имен для среды dev и среды prod.

Наконец, существуют крупные предпринимательские компании, в которых одна группа разработчиков даже не знает о существовании других групп. Такая компания может вообще нанять сторонних разработчиков, которые взаимодействуют с через хорошо документированные API. В каждой такой группе имеется несколько команд и несколько микросервисов. В этом случае необходимо использовать все инструменты, о которых я говорил ранее.

Программисты не должны развертывать сервисы вручную и не должны иметь доступа к пространствам имен, которые их не касаются. На данном этапе целесообразно иметь несколько кластеров для уменьшения «радиуса взрыва» плохо настроенных приложений, для упрощения процессов биллинга и управления ресурсами.

Таким образом, правильное использование пространств имен вашей организацией позволяют сделать Kubernetes более управляемым, контролируемым, безопасным и гибким.

Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness

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

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные 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