Модель ресурсов Kubernetes (KRM) и как использовать YAML?
Здесь мы объясним, как YAML может упростить управление системой и автоматизацию большинства процессов, чтобы Kubernetes стал удобной рабочей системой.
Базовые модели Kubernetes: KRM и «все как код»
По словам соучредителя Kubernetes Брайана Гранта, Kubernetes очень удобен благодаря модели ресурсов Kubernetes Resource Model (KRM). Это способ создать декларативный файл конфигурации в удобочитаемом формате для определения желаемого состояния системы с помощью кода. Ключевым аспектом KRM являются унифицированные декларативные метаданные. Поэтому KRM часто выражается как YAML и декларирует основную идею о том, что все в Kubernetes — это YAML.
Аналогичная идея лежит в основе парадигмы «Все как код» (EaC, все как код). Согласно его принципам, вся ИТ-инфраструктура может быть настроена с помощью кода от конфигурации до систем безопасности. Это делает его декларативным, что позволяет сосредоточиться не на реализации отдельных функций, а на конечных целях и состояниях. Тем не менее, YAML важен для лучшего баланса при безупречном использовании этих технологий.
Кубернетес и YAML
Kubernetes называют ядром Linux 21 века. Эта идея сравнивает возможность поиска любой информации о системе через proc в Linux и через API в Kubernetes: первое — все файлы (файловые потоки), второе — все YAML. Вы можете получить информацию о любых частях системы и приложениях, реализованных в виде операторов Kubernetes и пользовательских ресурсов. Использование YAML значительно упрощает эти задачи.
На самом деле, тысячи проектов — от CNI ( Контейнерный сетевой интерфейс) и ServiceMesh до Security and Infrastructure — являются родными для Kubernetes в виде операторов Kubernetes и пользовательских ресурсов Kubernetes. Cilium, Istio, Gloo, Knative, ClickHouse и другими сервисами можно управлять и отслеживать нативно, просто изменяя и отслеживая файлы YAML. Это подтверждает, что Kubernetes и YAML тесно связаны и взаимозависимы.
Вот список плюсов использования файлов YAML:
- Люди легко их понимают. Файлы YAML гибкие и выразительные.
- Они просты в настройке и эксплуатации.
- Они легко переносятся с одного языка программирования на другой.
- Они совместимы с неотъемлемыми структурами данных гибких языков.
- Для облегчения использования универсальных инструментов файлы YAML имеют согласованную модель.
- Они способны к однопроходной обработке.
- Они просты в использовании, поэтому вам не придется вводить все аргументы в командной строке.
- Вы можете сделать техническое обслуживание. Для отслеживания изменений файлы YAML могут быть добавлены в систему управления версиями.
- Они адаптивны. YAML позволяет создавать более сложные структуры, чем в командной строке.
Почему важно обеспечить один и тот же тип с помощью YAML?
Такой же тип реализации был необходим всегда, и его важность только возрастает с популяризацией DevSecOps-подхода (Developer Security Operations). Теперь с кластером может работать много разных команд, и каждая из них должна иметь возможность видеть общую картину происходящего и четко ее понимать. Это необходимо для своевременного выполнения поставленных задач и согласованности действий всех ведомств.
Если точная реализация не обеспечена, специалисты разных отделов могут видеть только фрагменты информации об услугах и инфраструктуре без какого-либо согласования. Это усложняет как повседневную работу, так и отладку. Такие случаи недопустимы — все должны одинаково видеть, что происходит в инфраструктуре.
Пример из реальной жизни:
Допустим, команда разработчиков, эксплуатация, давно решает проблему: по какой-то причине в одном конкретном окружении приложение нормально работало в сети (окружении) , а в другом - не работало.
Один образ, одна настройка, все абсолютно идентично, но что-то не так. Через несколько часов они отчаялись и пошли к группе охраны. Выяснилось, что команда разработки/эксплуатации использовала стороннее коммерческое решение, которое для своей работы внедряет сторонние библиотеки в процессы, запущенные в контейнерах. И эти процессы блокировали то, что они считали неправильным поведением. Блокировку можно было увидеть только внутри памяти процесса и непосредственно в интерфейсе, который есть только у команды безопасности.
Теперь возникает один вопрос, т.е. « если что-то не работает в инфраструктуре, нужно идти в безопасность, а потом разбираться?» “. По сути, мы не должны практиковать это в реальной жизни, чтобы обращаться к охранникам с любой проблемой. Все, что происходит в инфраструктуре, должно быть одинаково прозрачно для всех.
Kubernetes — это фреймворк. Он разработан, чтобы максимально гибко создавать инфраструктуру для своих команд и процессов, в данном случае не только инфраструктуру, связанную с высокой доступностью, непосредственно с быстрым расширением услуг, но и со всеми аспектами, связанными с безсервисными нагрузками баз данных. , безопасность и другие.
YAML — это «дружественный» формат сериализации (преобразование одной формы в другую). Он не только имеет простой синтаксис и позволяет хранить данные в компактном и удобочитаемом виде, но и подходит для всех языков программирования. Это позволяет вам использовать его, чтобы гарантировать, что один и тот же тип дизайна будет понятным и удобным для всех разработчиков.
Kubernetes может быть намного сложнее, чем вы думаете
В большинстве менеджеров исходного кода (SCM), используемых компаниями, проекты размещаются несколькими способами:
- Ресурсы YAML предоставляются сервисом.
- Ресурсы YAML размещаются в соответствии с названием сервиса и его типом: Deployment, Service, Ingress и так далее.
- Ресурсы хранятся по категориям и подкатегориям.
Итак, ресурсы связаны. А соединения необходимы для поддержки и понимания устройства сервисов и других сущностей кластера, как и отсутствие связи — это может указывать на опечатки и ошибки. Но это требует поддержки и понимания огромного количества различных проектов с их логикой связи.
Пример:
kubectl -n namespace get all
Kubernetes, введите следующую команду. Из его описания кажется, что он вернет все ресурсы в этом пространстве имен.
Но это не так : команда видит только определенный набор ресурсов. Таким образом, вы получите частичное представление об указанном пространстве имен, если будете его использовать.
Как связать ресурсы?
Есть 3 выделенных способа связывания ресурсов — они будут полезны, если вы будете разбираться в чужом проекте или писать свой оператор Kubernetes со своими кастомными ресурсами:
- ссылка на владельца (UID)
- Селектор
- targetRef
1. ссылка владельца
Позволяет одному ресурсу ссылаться на своего «родителя» . Таким образом, изменение или удаление «родителя» влияет на всех потомков. Этот вариант используется, например, когда Deployment — «родительский» ReplicaSet, а ReplicaSet — «родительский» pod .
ownerReference активно использует GarbageCollector: если родитель удален, все ресурсы, связанные с ним в ownerReference, будут удалены. Для большего понимания удаление образа для контейнера в описательной модели также приведет к удалению ресурса, в котором хранятся связанные результаты сканирования и отчеты.
2. Селектор
Самый распространенный способ связать ресурсы между собой — с помощью селекторов и меток.
Пары ключ/значение, называемые метками, прикрепляются/прикрепляются к таким вещам, как модули. Хотя метки не предназначены для явного указания семантики основной системе, они предназначены для обозначения отличительных качеств объектов, которые имеют смысл и важны для пользователей.
3. целевая ссылка
Одним из способов организации связи является targetRef. Подразумевает указание версии API ресурса, его имени и типа ресурса.
Этот способ дает четкое представление обо всех отношениях, поэтому таргетинг (название может меняться в зависимости от реализации, но идея остается той же) считается лучшим для связывания ресурсов друг с другом.