Проблема одновременного взятия одной записи двумя подами — классическая ситуация гонки при обработке задач.

Решения:

Использовать транзакции с блокировкой записи (например, SELECT ... FOR UPDATE), чтобы один под блокировал запись на время обработки.
Добавить поле статуса и атомарно обновлять его — например, обновить статус с new на processing с условием, что статус был new. Если обновление прошло успешно, значит под получил задачу.

Пример SQL-запроса для атомарного захвата задачи:

UPDATE tasks
SET status = 'processing', worker_id = :pod_id
WHERE id = (
  SELECT id FROM tasks
  WHERE status = 'new'
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
RETURNING *;

Использовать механизмы очередей или брокеров сообщений (RabbitMQ, Kafka), чтобы задачи распределялись между подами без конфликтов.
Использовать уникальные индексы и обработку ошибок при попытке захвата — если два пода пытаются обновить запись, только один успешно.

Таким образом, ключ — обеспечить атомарность операции захвата задачи и исключить параллельную обработку одной записи.

Шедулер берёт записи из таблицы, два пода одновременно взяли одну запись — как решить проблему?