#Планирование инфра-узлов для хранилища логов

В этом руководстве объясняются аспекты планирования запуска плагинов хранилища Logging на выделенных инфраструктурных узлах Kubernetes.

#Цели

• Изоляция ресурсов: предотвращение конкуренции с рабочими нагрузками бизнеса.
• Обеспечение стабильности: снижение числа выселений и конфликтов при планировании.
• Упрощение управления: централизация инфраструктурных компонентов с едиными правилами планирования.

#Где настраивать размещение

• Для Alauda Container Platform Log Storage for Elasticsearch настройте размещение через spec.valuesOverride.ait/chart-alauda-log-center.global.nodeSelector и spec.valuesOverride.ait/chart-alauda-log-center.global.tolerations в Installation.
• Для Alauda Container Platform Log Storage for ClickHouse настройте размещение через Advanced Configuration в консоли или через spec.config.components.nodeSelector и spec.config.components.tolerations в Installation.

Не исправляйте с помощью патча сгенерированные ресурсы StatefulSets, Deployments или ClickHouseInstallation как стандартный способ размещения рабочих нагрузок хранилища Logging на инфра-узлах.

#Перед настройкой размещения

1. Спланируйте инфра-узлы в соответствии с Планирование узлов кластера.
2. Проверьте, использует ли ваше хранилище LocalVolume или другие PV с spec.nodeAffinity.
3. Убедитесь, что выбранные инфра-узлы могут удовлетворить как правила планирования, так и ограничения размещения хранилища.

#Проверка Local PV и nodeAffinity

Если ваши компоненты используют локальное хранилище (например, TopoLVM, local PV), проверьте, есть ли у PV поле spec.nodeAffinity. Если есть, выполните одно из следующих действий:

1. Добавьте все узлы, на которые ссылается pv.spec.nodeAffinity, в группу инфра-узлов, или
2. Выполните повторное развертывание компонентов, используя storage class без node affinity (например, Ceph/RBD).

Пример (Elasticsearch):

# 1) Получить PVC ES
kubectl get pvc -n cpaas-system | grep elastic

# 2) Проверить один PV
kubectl get pv elasticsearch-log-node-pv-192.168.135.243 -o yaml

Если PV показывает:

spec:
  local:
    path: /cpaas/data/elasticsearch/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - 192.168.135.243

Тогда данные Elasticsearch закреплены за узлом 192.168.135.243. Убедитесь, что этот узел входит в группу инфра-узлов, или выполните миграцию хранилища.

Этот же принцип применяется к любому компоненту хранилища Logging, который использует локальное хранилище, привязанное к узлу.

#Исторические узлы Kafka и ZooKeeper

По историческим причинам убедитесь, что узлы Kafka и ZooKeeper также помечены/tainted как infra:

kubectl get nodes -l kafka=true
kubectl get nodes -l zk=true
# Add the listed nodes into infra nodes as above

#Устранение неполадок

Распространенные проблемы и способы их решения:

Пример ошибки:

Events:
  Warning  FailedScheduling  2m  default-scheduler  0/3 nodes are available:
  3 node(s) had untolerated taint {node-role.kubernetes.io/infra: true}

Исправление: добавьте соответствующие tolerations в конфигурацию плагина и убедитесь, что выбранные инфра-узлы также удовлетворяют требуемым ограничениям размещения хранилища.