FAQ по работе и администрированию Kubernetes-кластера xdevice.ru
Подготовлено как практический рабочий материал для сопровождения и базового администрирования кластера.
Документ предназначен для того, чтобы дать команде понятную точку входа в базовые
вопросы эксплуатации Kubernetes-кластера xdevice.ru. Ниже собраны сведения о расположении манифестов, составе конфигурационных файлов, основных служебных компонентах, типовых командах kubectl, работе с логами, а также базовых действиях по перезапуску и управлению подами.
Данный FAQ представляет собой практическую памятку для специалистов, которые участвуют в сопровождении, базовом администрировании и диагностике Kubernetes-кластера xdevice.ru.
Документ не подменяет собой полную эксплуатационную документацию, однако позволяет быстро сориентироваться в структуре размещения конфигураций и в типовых административных действиях, которые чаще всего требуются при работе с кластером.
Основная задача материала - сократить время на поиск базовой информации и зафиксировать минимальный набор ориентиров: где искать манифесты, какие файлы отвечают за параметры развертывания, как посмотреть состояние объектов кластера, где читать логи и какие действия обычно применяются для перезапуска сервисов.
• Работа с конфигурацией и манифестами должна выполняться аккуратно, так как часть файлов содержит параметры среды, точки подключения и другие чувствительные данные.
• В ряде манифестов и файлов конфигурации могут находиться секреты, параметры инициализации root-аккаунта, пароли и токены. До любых изменений необходимо понимать, какой именно файл редактируется и на что он влияет.
• При выполнении команд через kubectl важно учитывать namespace. По умолчанию команда может отработать не в том пространстве имён, которое ожидается, поэтому при диагностике и административных действиях рекомендуется явно указывать namespace.
Основная конфигурация кластера и связанные с поставкой манифесты располагаются в домашнем каталоге пользователя rightech. Ниже приведены основные директории и краткое пояснение, для чего они используются.
Директория / путь | Назначение |
/home/rightech/deploy/xdev | Основные манифесты поставки. Здесь располагаются базовые материалы, связанные с основной конфигурацией платформы и развертыванием кластера. |
/home/rightech/deploy/actions | Манифесты дополнительных action-сервисов, которые не входят в основную поставку. В этих файлах также могут быть указаны конфигурационные параметры соответствующих сервисов. |
/home/rightech/manifests | Манифесты дополнительных сервисов, входящих в расширенную поставку, а также иные служебные компоненты, необходимые для работы кластера. |
Такое разделение полезно для практической работы: оно позволяет быстрее понять, где искать базовые манифесты платформы, а где - дополнительные или расширенные компоненты. При передаче знаний новой команде эту структуру удобно использовать как первый уровень навигации по инфраструктуре.
Кроме директорий, в рабочем контуре отдельно выделяются ключевые файлы и шаблоны манифестов, которые важно понимать хотя бы на базовом уровне.
Файл / шаблон | Краткое описание |
/home/rightech/deploy | Базовая рабочая директория, где размещаются файлы поставки и сопутствующие манифесты. |
host.yaml | Inventory-файл, использовавшийся при установке Kubernetes. |
rigtcar-db | Манифест для развертывания баз данных для rightcar с репликацией. В документе отдельно отмечено, что в нём хранится root-пароль от базы данных. |
rightech.yaml | Манифест установки платформы с указанием портов и включённых ingress-компонентов. |
secrets.dec.yaml | Файл с переменными платформы, включая параметры инициализации root-аккаунта и другие секреты. |
rightcar-*.yaml | Манифесты отдельных экземпляров rightcar. Содержат параметры подключения к базам данных и токены для взаимодействия с платформой. |
При работе с перечисленными файлами важно придерживаться осторожного подхода: любые изменения должны вноситься только после понимания связей между сервисами, зависимостями по базам данных и текущей схемой развертывания.
В исходной памятке также перечислены дополнительные сервисы и функции, связанные с расширенной поставкой и эксплуатацией кластера. Перечень ниже полезен как ориентир по составу среды.
• позиционирование по Wi-Fi;
• контроль скоростного режима в геозонах;
• scooters-rightech-handler;
• ric-geo-deptrans;
• xdevice-delivery-api;
• ingress;
• cert-manager;
• сбор и хранение логов.
На практике этот список помогает понять, что кластер обслуживает не только базовое приложение, но и ряд дополнительных сервисов и технических компонентов, обеспечивающих сетевую доступность, сертификаты, интеграционную логику и наблюдаемость.
Для повседневной диагностики и администрирования используется kubectl. Ключевой практический момент: по умолчанию kubectl может работать в стандартном namespace, поэтому при запуске команд рекомендуется явно указывать пространство имён, если работа ведётся не с дефолтным контуром.
Ниже перечислены команды, которые используются чаще всего. Они пригодятся для первичного осмотра кластера, анализа состояния подов и уточнения контекста при разборе инцидентов.
Команда | Для чего используется |
-n <namespace> | Работа в конкретном namespace. Используется как уточняющий параметр в командах kubectl. |
-A | Работа по всем namespace. Удобно для общего обзора состояния кластера. |
sudo kubectl get events --sort-by='{.lastTimestamp}' -A | Просмотр событий кластера с сортировкой по времени. |
sudo kubectl get nodes -o wide | Список нод с IP-адресами и расширенной информацией. |
sudo kubectl get po -A -o wide | Список подов по всем namespace с IP- адресами и дополнительными параметрами. |
sudo kubectl get pods -n rightech -o wide | grep <DEPLOYMENT_NAME> | Поиск подов по конкретному deployment внутри namespace rightech. |
sudo kubectl describe pod <pod-name> -n <namespace> | Подробное описание пода, включая состояние, события и связанную служебную информацию. |
Логи являются одним из основных источников информации при разборе проблем. Через kubectl можно смотреть как логи конкретного пода, так и поток логов deployment в реальном времени.
При этом в документе отдельно указано, что основные логи также собираются в Grafana. Это означает, что во многих случаях смотреть логи через интерфейс наблюдаемости удобнее, особенно если требуется более длинный период, фильтрация или сопоставление с другими метриками.
Команда | Назначение |
sudo kubectl -n <namespace> logs <pod-name> | Просмотр логов конкретного пода. |
sudo kubectl logs deployment/ric-web -n <namespace> -f | Просмотр логов deployment в режиме реального времени. |
Практически это означает следующее: для быстрой проверки можно начать с kubectl, а для более глубокого разбора инцидента или сопоставления событий удобнее использовать Grafana как основную точку анализа логов.
В рабочей эксплуатации нередко требуется перезапустить deployment, удалить отдельный зависший под или временно изменить количество реплик. Эти действия считаются базовыми и применяются как часть стандартного сопровождения.
При этом важно помнить, что любое вмешательство в работающий сервис желательно выполнять осознанно, понимая возможное влияние на доступность, текущие пользовательские сессии и фоновые процессы.
Действие / команда | Пояснение |
sudo kubectl rollout restart deployment <deployment> -n <namespace> | Перезапуск deployment штатным способом. |
sudo kubectl delete pod -n <namespace> ric-web-... | Удаление отдельного пода. После удаления Kubernetes обычно создаёт под заново. |
sudo kubectl scale deployment <pod-name> -n <namespace> --replicas=2 | Увеличение или уменьшение количества реплик deployment. |
sudo kubectl scale deployment ric-web -n rightech -- replicas=1 | Пример возврата количества реплик к одной. |
На практике масштабирование используется как для временного увеличения устойчивости сервиса под нагрузкой, так и для возврата к штатной схеме после выполнения работ.
Удаление отдельного пода - это простой и часто используемый способ инициировать его пересоздание в случае локального сбоя.
• При разборе инцидента начинать с определения namespace, события кластера и состояния подов.
• При необходимости детализации переходить к describe pod и просмотру логов.
• Для анализа истории и сопоставления событий использовать Grafana как дополнительный и часто более удобный инструмент.
• Перед изменением манифестов проверять, не содержит ли файл чувствительные параметры, секреты или токены.
• Использовать документ как рабочую шпаргалку для типовых действий, а при более сложных изменениях опираться на детальную эксплуатационную документацию и действующие регламенты.
Данный FAQ предназначен для того, чтобы упростить базовую навигацию по инфраструктуре xdevices.ru и зафиксировать минимально необходимый набор административных ориентиров.
В документе собраны ключевые точки: расположение манифестов, назначение ряда конфигурационных файлов, список часто используемых Kubernetes-команд, порядок работы с логами и базовые действия по управлению подами.
В расширенной редакции материал изложен более подробно, чтобы его было проще передавать клиентской команде как стартовую инструкцию для знакомства с текущим контуром сопровождения.