#Изменения в спецификациях

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

#Примечания к ограничениям

1. Если вы внесли настройки, связанные с расписанием, для текущего экземпляра, изменения в количестве реплик должны соответствовать текущей конфигурации расписания.
2. Рекомендуется масштабировать все узлы до одинаковой спецификации, так как увеличение емкости хранения одного Брокера может привести к неравномерному распределению. Емкость хранения на расширенном Брокере может быть переполнена, в то время как емкость хранения на других Брокерах может быть не полностью использована. В этом случае, возможно, потребуется мигрировать существующие данные для достижения сбалансированного распределения по новым дисковым пространствам. Это означает, что некоторые данные могут потребоваться перенести с оригинального Брокера на расширенный Брокер, что усложняет и добавляет операции по миграции данных. Чтобы избежать этих проблем, рекомендуется поддерживать равенство или как можно больший близость емкости хранения Брокеров при расширении кластера Kafka. Это обеспечит сбалансированное распределение данных и нагрузки, улучшая производительность и надежность кластера.
3. При изменении ресурсов CPU и памяти оценивайте на основе бизнес-требований и доступности ресурсов, чтобы избежать неудач расширения из-за слишком маленьких или слишком больших ресурсов, что может предотвратить нормальный запуск экземпляра.

#Процедура

# Установить спецификации экземпляра на cpu:300m, memory: 300Mi
kubectl -n <namespace> patch rdskafka <name> --type=merge --patch='{"spec": {"resources":{"limits":{"cpu": "2","memory":"4Gi"},"requests":{"cpu":"2", "memory":"4Gi"}}}}'

Подождите немного, и вы увидите соответствующие изменения в Спецификациях в топологии.