kubernetes что такое namespace
Знакомство с Kubernetes. Часть 10: Неймспейсы (namespaces)
Jul 2, 2018 07:02 · 515 words · 3 minute read kubernetes
Kubernetes поддерживает несколько виртуальных кластеров, работающих в одном и том же физическом кластере. Эти виртуальные кластеры называются пространствами имен или неймспейсами (namespaces). Давайте разберемся!
Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.
Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:
и выполним команду:
Для второго неймспейса создадим файл с тем же содержимым, но заменим слова “development” на “production” и применим его:
Убедимся, что неймспейсы успешно создались:
Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:
Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):
После выполнения этих двух команд к конфигурационном файле
/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:
Лучшие практики 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». Давайте рассмотрим простой YAML-файл, предназначенный для создания pod. Можно заметить, что в нем нет никакого упоминания о пространстве имен.
Если примените kubectl для запуска этого файла, он создаст модуль mypod в текущем активном пространстве имен. Это будет пространство имен по умолчанию, пока вы его не измените. Существует 2 способа сообщить Kubernetes, в каком пространстве имен вы хотите создать свой ресурс. Первый способ — это использование флага пространства имен при создании ресурса.
Второй способ заключается в указании пространства имен в декларации YAML.
Если вы укажете пространство имен в YAML, то ресурс всегда будет создаваться в этом пространстве. Если вы попытаетесь использовать другое пространство имен при использовании флага пространства имен, то команда завершится ошибкой. Теперь, если вы попытаетесь найти свой pod, то не сможете этого сделать.
Это происходит потому, что все команды выполняются вне текущего активного пространства имен. Чтобы найти свой pod, вам нужно использовать флаг пространства имен, однако это быстро надоедает, особенно если вы работаете разработчиком в группе, которая использует свое собственное пространство имен и не хочет и использовать такой флаг для каждой отдельной команды. Давайте посмотрим, как это можно исправить.
Из коробки ваше активное пространство имен носит название default. Если вы не уточните пространство имен в YAML ресурса, то все команды Kubernetes будут использовать это активное default namespace. К сожалению, попытка управлять активным пространством имен с помощью kubectl может окончиться неудачей. Однако существует очень хороший инструмент под названием Kubens, который намного упрощает этот процесс. Когда вы запускаете команду kubens, то видите все пространства имен с подсвеченным активным пространством имен.
Это означает, что вам не нужен флаг пространства имен, чтобы увидеть 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: знакомство, часть 1 – архитектура и основные компоненты, обзор
На текущем проекте у нас имеется API-бекенд для мобильных приложений на PHP Yii-фреймворке, который работает на стандартном LEMP – Linux/NGINX/PHP-FPM/MySQL.
Пришла пора и нам разбивать этот монолит на микросервисы, для управления которыми будет использоваться Kubernetes (AWS EKS).
В этом и последующих постах серии – знакомство с основными компонентами и архитектурой Kubernetes, ручное создание кластера и работа с AWS EKS.
Ниже достаточно кратко рассматривается общая архитектура, основные компоненты и понятия Kubernetes, а в следующих – перейдём к более практическим примерам, понемногу углубляюсь в детали и расширяя кругозор экосистемы Kubernetes.
В посте добавлено достаточно много ссылок до материалы, но основная проблема при поиске документации/примеров по Kubernetes – это то, что изменения появляются часто и быстро, а потому любые примеры и документация быстро устаревают – имейте это ввиду.
Архитектура – обзор
Общая схема K8s кластера выглядит так:
Или более простая схема:
Кластер состоит из одной или более Master Node, и одной или более Worker Node.
Master Node
Сервисы, работающие на Master-ноде называются “Kubernetes Control Plane” (кроме etcd ), при этом сам Master используется только для административных задач, тогда как реальные контейнеры с вашими сервисами будут запущены на Worker Node.
Kubernetes core services aka Kubernetes Control Plane
На Master Node работают три основных компонента, которые обеспечивают работу всех компонентов системы:
Key:value хранилище, используемое Kubernetes для управления конфигурациями и service discovery.
Кроме того, в нём хранится текущее (current) состояние системы, и желаемое (desired), например – после деплоймента.
Если K8s находит отличия в etcd между состояниями current и desired – он выполняет необходимые изменения.
Worker Node
Worker Node (ранее – minion) – виртуальная или физическая машина, на которой имеются компоненты Kubernetes для запуска Pod (см. Pod).
На Worker Node-ах работают два компонента:
Взаимодействие компонтентов
Например, при создании нового pod-а – процесс выглядит так:
Абстракции Kubernetes
Выше мы говорили о более-менее “осязаемых” вещах, таких как виртуальные машины, сети, IP-адреса и прочее.
Но сам Kubernetes являет собой один большой кусок… абстракции, “накладываемой” на виртуальную или физическую инфрастуктуру.
Соответственно, в K8s имеется множество собственных объектов, являющихся абстрактными, или логическими, компонентами Kubernetes.
Pod – основная логическая единица Kubernetes.
По сути своей, под является такой себе абстракцией виртуальной машины внутри Kunbernetes-кластера: у него есть свой приватный IP, имя хоста, общие данные на дисках (см. Volumes).
Pod является юнитом деплоймента (см. Deployment), и “внутри” этой “машины” запускаются один или более контейнеров, связанных общим назначением, и представляющих собой логическое приложение (состоящее из одного или более процессов/контейнеров).
Каждый под предзначен для запуска и обслуживания единственного экземпляра приложения: если вы хотите выполнить горизонтальное масштабирование приложения – вы должны использовать различные поды, по одному на каждый инстанс приложения.
Такая группа нод (Replicated Pods) управляется контроллером (см. Controllers).
При этом сами контейнеры не являются объектами Kubernetes и не управляются им: Kubernetes управляет подами, но контейнеры внутри этого пода используют общее сетевое пространство имён, включая IP адреса и порты, и могут обращаться друг к другу через localhost (потому как под == логическая виртуальная машина).
Пример шаблона для создания пода может выглядеть так:
Services
Сервисы – это, в первую очередь, про сеть внутри кластера и обеспечение доступа к подам из мира – они позволяют выполнять коммуникацию между различными компонентами внутри и снаружи приложения.
По сути, сервисы – точно такие же объекты Kubernetes, как Pod, ReplicaSets, DaemonSet, при этом вы можете представлять себе сервис как ещё один виртуальный сервер в ноде.
Например, сервисы можно условно обозначить так:
Тут пользователь приходит к приложению через один сервис, и попадает на фронтенд, затем сам фронтенд через два других сервиса взаимодействует с двумя сервисами бекенда, которые, в свою очередь, через ещё один сервис – общаются с серверов баз данных.
ClusterIP
Открывает доступ к сервису через внутренний IP кластера. Таким образом – сервис будет доступен только внутри самого класетра.
Является типом по-умолчанию.
NodePort
Увидеть подсети можно с помощью kubeadm config view :
Kubernetes для чайников: установка, настройка и основы
Содержание:
Контейнеризация приложений — один из главных трендов современных IT-разработок. Однако, у контейнеров есть один существенный недостаток для массового потребителя — сложная настройка масштабирования.
Решением стали автоматические системы управления контейнеризацией, наиболее популярной из которых является Kubernetes. Это программное обеспечение с открытым исходным кодом от компании Google завоевало признание благодаря сочетанию гибкости, безопасности и мощности.
Cтатья «Kubernetes для чайников» поможет разобраться как устроена платформа управления контейнеризацией, как установить ПО и для чего его можно использовать в дальнейшем. Она будет полезна как для начинающих пользователей Kubernetes, так и для профильных IT-специалистов.
История создания
Проект Kubernetes (сокращенно K8s) вырос из системы управления кластерами Borg. Внутренний продукт поискового гиганта Google получил название в честь кибер-рассы боргов из легендарного сериала «Звездный путь».
Команде разработчиков Google Borg была поставлена масштабная задача — создать открытое программное обеспечение для оркестрирования* контейнеров, которое станет вкладом Google в развитие мировых IT-технологий. Приложение было написано на основе языка Go.
* Под «оркестрированием» подразумевается автоматизированное управление связанными сущностями — контейнерами или виртуальными машинами.
На этапе разработки K8s назвался Project Seven («Проект «Седьмая»). Это было прямой отсылкой к персонажу «Звездного пути» Seven of Nine («Седьмая-из-девяти») — андроиду-боргу, сумевшему вернуть себе человечность. Позже проект получил имя «Кубернетес», от греческого слова κυβερνήτης, которое означает «управляющий», «рулевой» или «кормчий».
В 2014 году общественности представили исходные коды, а годом позже появилась первая версия программы Kubernetes 1.0. В дальнейшем все права на продукт были переданы некоммерческому фонду Cloud Native Computing Foundation (CNCF), куда входят Google, The Linux Foundation и ряд крупнейших технологических корпораций.
Как работает технология
Принципы устройства
Основы работы K8s – применение декларативного подхода. От разработчика требуется указать, чего необходимо достичь, а не способы достижения.
Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.
Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.
Основные задачи Kubernetes
Преимущества K8s
Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.
Основные компоненты
Схема взаимодействия основных компонентов K8s
Node (Нода)
Ноды или узлы — виртуальные или физические машины, на которых разворачивают и запускают контейнеры. Совокупность нод образует кластер Kubernetes.
Первая запущенная нода или мастер-нода непосредственно управляет кластером, используя для этого менеджер контроллеров (controller manager) и планировщик (scheduler). Она ответственна за интерфейс взаимодействия с пользователями через сервер API и содержит в себе хранилище «etcd» с конфигурацией кластера, метаданными и статусами объектов.
Namespace (Пространство имен)
Объект, предназначенный для разграничения ресурсов кластера между командами и проектами. Пространства имен — несколько виртуальных кластеров, запущенные на одном физическом.
Pod (Под)
Первичный объект развертывания и основной логический юнит в K8s. Поды — набор из одного и более контейнеров для совместного развертывания на ноде.
Группировка контейнеров разных типов требуется в том случае, когда они взаимозависимы и должны запускаться в одной ноде. Это позволяет увеличить скорость отклика во время взаимодействия. Например, это могут быть контейнеры, хранящие веб-приложение и сервис для его кэширования.
ReplicaSet (Набор реплик)
Объект, отвечающий за описание и контроль за несколькими экземплярами (репликами) подов, созданных на кластере. Наличие более одной реплики позволяет повысить устойчивость от отказов и масштабирование приложение. На практике ReplicaSet создается с использованием Deployment.
ReplicaSet является более продвинутой версией предыдущего способа организации создания реплик (репликации) в K8s – Replication Controller.
Deployment (Развертывание)
Объект, в котором хранится описание подов, количество реплик и алгоритм их замены в случае изменения параметров. Контроллер развертывания позволяет выполнять декларативные обновления (с помощью описания нужного состояния) на таких объектах, как ноды и наборы реплик.
StatefulSet (Набор состояния)
Как и другие объекты, например — ReplicaSet или Deployment, Statefulset позволяет развертывать и управлять одним или несколькими подами. Но в отличие от них, идентификаторы подов имеют предсказуемые и сохраняемые при перезапуске значения.
DaemonSet (Набор даемона)
Объект, который отвечает за то, чтобы на каждой отдельной ноде (или ряде выбранных) запускался один экземпляр выбранного пода.
Job/CronJob (Задания/Задания по расписанию)
Объекты для регулировки однократного или регулярного запуска выбранных подов и контроля завершения их работы. Контроллер Job отвечает за однократный запуск, CronJob — за запуск нескольких заданий по расписанию.
Label/Selector (Метки/Селекторы)
Метки предназначены для маркировки ресурсов. Позволяют упростить групповые манипуляции с ними. Селекторы позволяют выбирать/фильтровать объекты на основе значения меток.
По факту, метки и селекторы не являются самостоятельными объектами Kubernetes, но без них система не сможет полноценно функционировать.
Service (Сервис)
Средство для публикации приложения как сетевого сервиса. Используется, в том числе, для балансировки трафика/нагрузки между подами.
Процесс установки
Установка Kubernetes, рассмотренная ниже, предполагает наличие одного (или более) серверов с операционной системой Centos 7 или Ubuntu 16.04.
Затем открыть «/etc/fstab» с правами root и удалить соответствующую команде строчку «#/swapfile».
Проект Kubernetes действует на основе контейнеров Docker, существенно расширяя их функциональность. Логично, что начинать работу Kubernetes следует именно с установки Docker.
Проще всего остановить выбор на версии, добавленной на текущий момент в репозитории. Ее протестировали разработчики Kubernetes и она работает наиболее стабильно.
Установка контейнеров на Ubuntu 16.04
Чтобы установить Docker на Ubuntu 16.04, необходимо выполнить следующие команды с правами суперпользователя:
Если требуется работать с более новыми версиями контейнеров, запустите команды:
Установка контейнеров в CentOS 7
Для установки Docker на Centos, в консоли нужно выполнить команды:
Установка kubeadm, kubelet и kubectl в Ubuntu
Для работы с Kubernetes понадобится установить компоненты kubeadm, kubelet и kubectl. Эти утилиты понадобятся для создания управления кластером Kubernetes.
В Ubuntu эти компоненты можно установить следующим способом:
Установка kubeadm, kubelet и kubectl в CentOS
В CentOS 7 компоненты устанавливаются следующим образом:
Обращаем внимание! Команда setenforce 0 позволит получить корректный доступ контейнеров к файловой системе хоста. Последняя необходима для функционирования сети у подов.
Нужно убедиться, что «kubelet» и «docker» пользуются одним и тем же драйвером «cgroup». В этом может помочь команда:
Настройка Kubernetes
Инициализация кластера
Нужно указать сервер, на котором установлен K8s (он будет первичным — там будут запускаться остальные операции) и выполнить инициализацию кластера:
Обращаем внимание! Опция «—pod-network-cidr» задает адрес виртуальной сети подов и может отличаться, в зависимости от используемого сетевого плагина.
В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.
При выполнении команды в консоли, есть вероятность появления ошибок или предупреждений. Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production».
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к первичному хосту. Команда может отличаться, в зависимости от структуры кластера. Ее нужно сохранить на будущее.
После выполнения этой команды система выведет примерный результат:
Остается выполнить следующие команды от имени пользователя, который будет управлять кластером:
Настройка CNI
Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.
Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.
Чтобы установить Flannel, выполните в терминале команду:
В выводе будут отображены имена всех созданных ресурсов.
Добавление узлов (нод) в кластер
Чтобы добавить новые ноды в существующий кластер, требуется выполнить следующий алгоритм:
Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.
Если команда не была сохранена, то можно ее составить повторно.
Получение токена авторизации кластера ( )
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
Вывод должен быть примерно таков:
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
Вывод будет примерно таков:
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
Будет получен примерно такой вывод:
Для ввода IPv6-адреса в параметр « : », адрес должен быть заключен в квадратные скобки. Например:
Дополнительные настройки
В дефолтной конфигурации мастер-нода не запускает контейнеры, так как занимается отслеживанием состояния кластера и перераспределением ресурсов. Ввод данной команды даст возможность запускать контейнеры на мастере, собенно, если кластер содержит лишь одну ноду:
Проверка работоспособности кластера
Проверить, что кластер запустился и правильно работает, можно так:
Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.
Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.
Заключение
Несмотря на кажущуюся сложность настройки, K8s стоит времени, потраченного на его изучение. Kubernetes — наиболее совершенный на сегодня инструмент оркестрирования контейнеров. Он позволяет не только автоматизировать процесс развертывания, но и максимально упрощает дальнейший процесс работы с массивами контейнеров.
С помощью этого краткого руководства начать работу с K8s сможет даже начинающий пользователь. В дальнейшей работе с платформой поможет подробная официальная документация, доступная, в том числе, на русском языке.