Приложение Kubernetes извлекает сообщения Pub/Sub и записывает их в Filestore; один под не может обрабатывать сообщения в реальном времени, и сообщения накапливаются. Обработка интенсивно использует ввод-вывод. Как следует масштабировать обработку?

Приложение интенсивно использует ввод-вывод, поэтому масштабирование на основе ЦП (kubectl autoscale) может быть неэффективным, так как нагрузка на ЦП может быть низкой, даже если приложение перегружено. Автомасштабирование кластера (cluster autoscaling) масштабирует узлы, а не поды, и не решает проблему задержки обработки сообщений внутри подов. Метрика subscription/pushrequestlatencies показывает задержку запросов, но не напрямую количество необработанных сообщений. Метрика subscription/numundeliveredmessages напрямую отражает количество сообщений, ожидающих обработки, что является идеальным показателем для масштабирования, когда поды не справляются с потоком данных. Это позволяет динамически увеличивать количество подов, когда очередь сообщений растет, и уменьшать, когда она сокращается, обеспечивая обработку в реальном времени.