Прикладное взаимодействие с кластером Kubernetes осуществляется через компонент API Server. Так, например, работает консольная утилита kubectl.
Если мы хотим запустить в кластере Kubernetes сервис, то свои намерения API Server-у мы описываем не с помощью команд типа "запусти экземпляр сервиса", а декларативно, т. е. передаем API Server-у часть конфигурации, который описывает требуемое состояние. Далее контроллеры узнают об изменении этой части конфигурации и соответствующим образом реагируют.
Всю конфигурацию, а также описание состояние кластера, в Kubernetes для удобства и простоты разбили на набор описаний в виде объектов разных типов.
Объекты
Объекты (objects) – это хранящиеся внутри Kubernetes сущности. И Kubernetes их использует для представления состояния кластера.
Объекты могут описывать:
· какие сервисы должны быть запущены и их актуальный статус;
· какие вычислительные ресурсы (CPU и память) доступны сервисам;
· политики поведения, такие как политика рестартов, обновлений и т.д.
Изменения этих объектов — создание, удаление, обновление слушают различные контроллеры и производят реальные действия — запускают и тушат сервисы, перенастраивают сетевые политики, обновляют конфигурации балансеров и т. д.
Каждый объект хранит желаемое состояние или еще по-другому это называется спецификация, а также текущее актуальное состояние той части кластера, к которой они относятся.
Управление кластером и нагрузкой происходит через создание, изменение и удаление этих объектов. Для работы с объектами в API Server-е используется REST подход. То есть, каждому объекту соответствует ресурс в API и любые действия с объектами транслируются в действия с REST-ресурсами. И для создания ресурса нужно сделать POST запрос на URL коллекции, для получения ресурса GET на URL конкретного ресурса, для изменения — использовать метод PATCH, а удаления — метод DELETE. Поэтому иногда объекты называют еще ресурсами Kubernetes.
Для встроенных объектов обычно есть соответствующий встроенный контроллер. Например, объект типа Node описывает ноду кластера. И есть специальный встроенный в kube-controller-manager контроллер, который следит за доступностью ноды и помогает проводить такие операции, как ввод и вывод ноды из кластера.
Когда создаются объекты (ресурсы), то просто добавляется "кусок конфигурации". Если контроллеров, реагирующих на изменения объектов нет, то такие объекты просто так и останутся данными, которые хранятся в хранилище, и не будут иметь никакого эффекта в реальном мире.
Помимо встроенных объектов или ресурсов, Kubernetes позволяет добавлять пользовательские типы объектов (ресурсов). А также позволяет разрабатывать кастомные контроллеры сторонним разработчикам на изменения этих ресурсов. Это делает Kubernetes фреймворком, который легко можно расширять.
Когда пользователь работает с объектами Kubernetes, то обычно использует yaml формат описания объекта. Например, с помощью утилиты kubectl можно создавать, обновлять и удалять объекты. Описания объектов обычно хранят в yaml-файлах. Файлы с описанием объектов Kubernetes еще иногда называются манифестами Kubernetes. Как раз написанием таких файлов обычно занимается разработчик.
Каждый объект имеет ряд стандартных атрибутов:
· apiVersion – версия API, которая вместе с типом объекта однозначно определяет конкретную схему объекта. Версия API нужна для развития схемы типа объекта. Это позволяет в одной версии Kubernetes-а поддерживать несколько разных форматов для одного типа объекта, совмещая устаревший формат и новый. Таким образом не ломается обратная совместимость старых манифестов и добавляется поддержка новых.
· kind – тип объекта
· metadata – метаданные
· name - некоторый идентификатор объекта, по которому Kubernetes понимает, какой объект меняется, имя должно быть уникальным среди объектов этого типа
· labels, annotations - метки и аннотации. Мы их рассмотрим чуть позже.
· spec – спецификация желаемого состояния объекта. Для каждого типа объекта она своя.
· status - текущие состояние объекта. Обычно не используется в yaml манифестах и используется внутри Kubernetes контроллерами.
В рамках курса мы с вами познакомимся с рядом встроенных объектов и разберемся, как встроенные контроллеры реализуют работу с ними.
Ссылки:
Пространства имен
Внутри Kubernetes большая часть объектов относится к тому или иному пространству имен (namespace).
Пространство имен разграничивает наборы объектов друга от друга и помогает различным проектам, командам, пользователям использовать один кластер Kubernetes. Разграничение происходит за счет разных пространств для имен объектов. Имена объектов Kubernetes должны быть уникальными среди объектов соответствующего типа не в рамках всего кластера Kubernetes, а только в рамках namespace-а, к которому они относятся. Это помогает командам, работающим в одном кластере не задумываться и не переживать насчет пересечения имен.
Любая рабочая нагрузка: экземпляр сервиса, приложение или задача, имеет соответствующий ей объект Kubernetes, и этот объект находится в каком-то namespace-е. Поэтому получается, что любая рабочая нагрузка будет связана с каким-то пространством имен. И иногда даже говорят, что сервис запущен в namespace-е. Но крайне важно понимать, что это некоторое упрощение. Пространство имен — это абстракция, т.е. сервисы, запущенные на одной ноде, могут относиться к объектам Kubernetes, описывающим рабочую нагрузку, которые находятся в разных пространствах имен. И сервисы, относящиеся к одному пространству имен, могут быть, и обычно запущены на разных нодах. Т.е. пространства имен в общем случае не соотносятся с инфраструктурным слоем кластера.
Еще одна функция пространства имен — это система ограничений вычислительных ресурсов. Администратор кластера может выделить квоту на вычислительные ресурсы — память и CPU. Квота — это максимальное значение памяти и CPU, которое может использовать суммарно вся рабочая нагрузка, относящаяся к namespace-у.
Пространства имён также используется в системе прав и доступов. Например, можно настроить политику контроля таким образом, чтобы одна команда (или пользователь) не могли изменять или даже читать объекты из другого namespace-а. Это необходимо, чтобы команды или пользователи случайно, или намеренно не изменили объекты друг друга.
Пространства имён не могут быть вложенными, а каждый ресурс Kubernetes может находиться только в одном пространстве имён.
При удалении пространства имен происходит удаление всех объектов, которые находятся в нем.
Чаще всего в практике используют одну из следующих схем:
00001. одно пространство имен на одну команду;
00002. одно пространство имен на среду: prod, stage, qa;
00003. одно пространство имен на одно приложение;
Когда приложение небольшое и команда, которая работает над приложением одна, то логично использовать схему одно пространство имен на среду: prod, stage, qa. Когда команд становится несколько, и каждая работает над своим набором сервисов, тогда логично разбиение пространства имен по командам, т.е. одна команда — один namespace. А в случае крупных проектов, когда команд становится уже несколько десятков, обычно переходят к концепции одно приложение (автоматизированная система) - один namespace.
Ссылки:
Метки и селекторы
Многие контроллеры работают не с одним объектом, а с несколькими. Чтобы иметь возможность указывать набор объектов, с которыми они работают, без необходимости фиксировать конкретные идентификаторы в спецификациях, используется механизм меток и селекторов.
Метки (labels) – это значения типа ключ-значение, которые связаны с конкретным ресурсом (объектом) Kubernetes. Метки определяют атрибуты объектов, которые имеют смысл для человека. Они могут быть прикреплены к объекту в момент создания и описываются в атрибуте .metadata.labels. Либо изменены в реальном времени - удалены, добавлены и т.д. Рекомендуется использовать логические (или семантические) ключи в метках, например, {app: myapp, tier: frontend, phase: test, deployment: v3}.
Селекторы – это выражения, позволяющие выбрать объекты по меткам.
Есть два типа селекторов:
- основанные на совпадении (или не совпадении) меток (equality-based)
- основанные на наборах (set-based) фильтруют ключи в соответствии с набором значений. Поддерживаются три вида операторов: in, notin и exists.В yaml конфигурациях правила, основанные на совпадении меток, описываются в разделе matchLabels, а основанных на наборах - в matchExpressions
Не все объекты в Kubernetes поддерживают matchExpressions, для того, чтобы точно узнать, поддерживается или нет, необходимо посмотреть в документации к объекту в конкретной версии Kubernetes. В подавляющем большинстве случаев хватает селекторов, основанных на совпадении меток. Ссылки: метки и селекторы
Аннотации
Также к объектам в Kubernetes можно добавить метаданные. Такие клиенты, как инструменты и библиотеки, могут получить эти метаданные и использовать в своей работе. Метки можно использовать для выбора объектов и для поиска коллекций объектов, которые соответствуют определенным условиям. В отличие от них аннотации не используются для идентификации и выбора объектов. Аннотации - как и метки, являются коллекциями с наборами пар ключ-значение. Но в отличие от меток, там хранится значимая информация, которую используют инструменты или контроллеры для своей работы. Аннотации располагаются в атрибутах metadata.annotations.
Ссылки:
#devops #kubernetes #программирование #автоматизация
