kubernetes-specialist - Ресурсы и доступ в Kubernetes

Когда звать

• Когда контейнер в Kubernetes падает, не проходит readiness или упирается в ресурсы.
• Когда нужно подготовить манифесты с отдельным ServiceAccount и ограниченным сетевым доступом.

Что охватывает Kubernetes Specialist

Kubernetes Specialist описывает подготовку ресурсов кластера и разбор проблем работающего приложения. В прочитанном файле версии 1.1.1 есть Deployments, StatefulSets, DaemonSets, Jobs, сетевые правила, постоянное хранилище и Helm. Для агента это набор требований к манифестам и проверкам, а не готовый кластер.

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

Какие манифесты требует автор

Для каждого контейнера инструкция требует requests и limits, liveness и readiness probes. В примере также указаны namespace, постоянные labels, отдельный ServiceAccount и конкретный тег образа. Использовать latest для рабочего окружения запрещено.

Раздел RBAC показывает связку ServiceAccount, Role и RoleBinding. Пример выдаёт только чтение перечисленных ConfigMaps. Смысл задания агенту здесь в том, чтобы перечислить необходимые ресурсы и действия, а не назначить широкую роль ради исчезновения ошибки доступа.

Сетевой пример начинается с запрета входящего и исходящего трафика, после чего разрешает отдельное соединение между приложениями. Прежде чем переносить такой шаблон, нужно составить список нужных сетевых связей. Сам файл NetworkPolicy не объяснит, какие внешние зависимости есть у вашего приложения.

Как разбираются сбои

После изменения workload исходник предлагает смотреть завершение rollout, состояние pod и подробное описание ресурса. Для упавшего контейнера отдельно показано чтение предыдущих логов через --previous. Это помогает не потерять сообщение, появившееся до перезапуска.

Автор также перечисляет проверку использования ресурсов и аудит прав сервисной учётной записи. Если выкладка неудачна, в файле есть пример отката. Наличие этой команды в инструкции не является разрешением агенту менять ваш рабочий кластер: контекст и область действий нужно задать отдельно.

В справочниках есть Helm charts, конфигурация и Secrets, CSI-хранилища, операторы и CRD. Для более сложных задач перечислены service mesh, GitOps, подбор размеров нагрузки и несколько кластеров. Мы проверили ссылки на эти темы в основном файле, но не заявляем испытание всех сценариев.

Пример безопасной стартовой задачи

Попросите: «Разберите существующий Deployment без применения изменений. Покажите отсутствующие проверки здоровья, права ServiceAccount и причины выбора лимитов. Подготовьте YAML и план проверки в тестовом namespace». На выходе должны быть манифесты, необходимые RBAC-объекты, сетевые правила и пояснения к решениям.

Автор требует декларативного YAML и запрещает хранить учётные данные в ConfigMap. В примере Secrets подключаются по ссылке; значения секретов в карточку или запрос добавлять не требуется.

Проверены SKILL.md и MIT-лицензия одного коммита. Установка коллекции и работа с кластером не выполнялись; Codex не проверен. Общую цепочку сборки и выпуска описывает DevOps Engineer.