Отладка сброса подключения к внешней базе данных Oracle в Kubernetes из-за ошибки connection reset by peer.

вопрос, связанный с этой проблемой. У нас есть приложение на Java, которое при запуске и входе пользователя создает долго живущее соединение с базой данных Oracle, которое остается активным в течение всего времени работы приложения (или POD в Kubernetes в данном случае).
Проблема в том, что через некоторое время, это может быть 30 минут, а может быть даже 2 дня, в логах появляется ошибка

[pool-16-thread-1] WARN  c.zaxxer.hikari.pool.ProxyConnection - HikariPool-2 - Connection oracle.jdbc.driver.T4CConnection@51f5db67 помечено как поврежденное из-за SQLSTATE(08006), ErrorCode(17002)
java.sql.SQLRecoverableException: Ошибка ввода/вывода: соединение сброшено удаленным хостом

что приводит к множеству последующих SQL-ошибок, потому что указанное активное соединение все еще пытается использовать разорванное соединение. Как оказалось, кажется, что сессия Hibernate создается, но никогда не очищается, как я полагаю, она всегда должна создавать новую сессию при взаимодействии с базой данных. Я указал на это нашим разработчикам, но не знаю, когда это будет исправлено.

В настоящее время мы пытаемся мигрировать приложение в Kubernetes, и для меня основная проблема заключается в том, почему это сброс соединения происходит в Kubernetes? Например, этого не происходит на обычной виртуальной машине, хотя приложение на Java то же самое.
Приложение масштабируется до 2 POD, и проблема иногда возникает только для одного POD, а иногда через 5-10 минут и на втором POD, так что это исключает сетевой сбой, потому что тогда это должно происходить на обоих POD одновременно, нет?
У меня нет представлений, куда еще смотреть, так как все журналы для Kubernetes и узлов ничего не говорят. Может быть, у кого-то есть идеи, где или как правильно отладить это? Со стороны базы данных Oracle они говорят, что также есть только ошибка потери соединения или что-то такое, и это все.

1. Настройка пула соединений:
   Во-первых, убедитесь, что ваша настройка пула соединений (в данном случае HikariCP) настроена на правильную обработку простоя соединений:

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

public class DatabaseConfig {
    public static HikariDataSource createDataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:oracle:thin:@your-oracle-host:1521:your-oracle-sid");
        config.setUsername("your-username");
        config.setPassword("your-password");
        config.setMaximumPoolSize(10); // Настройте в соответствии с вашими нуждами
        config.setConnectionTimeout(30000); // 30 секунд
        config.setIdleTimeout(600000); // 10 минут
        config.setMaxLifetime(1800000); // 30 минут

        // Эти настройки помогают управлять простоями соединений:
        config.setLeakDetectionThreshold(30000); // 30 секунд
        config.setMinimumIdle(5); // Держите не менее 5 соединений в простое

        return new HikariDataSource(config);
    }
}

IdleTimeout: Обеспечивает, чтобы соединения не оставались в простое неограниченно долго.
MaxLifetime: Заставляет пул обновлять соединения через некоторое время, чтобы избежать устаревших соединений.
LeakDetectionThreshold: Помогает обнаруживать утечки соединений, которые могут вызывать проблему.

2. Настройка сети Kubernetes:
   Проверьте сетевые политики: Убедитесь, что в Kubernetes нет ограничивающих сетевых политик, которые могут влиять на соединение.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-oracle-db
  namespace: your-app-namespace
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: <your-oracle-db-ip>/32
    ports:
    - protocol: TCP
      port: 1521

NAT и правила брандмауэра: Если используется облачный NAT или какой-либо брандмауэр, проверьте, не приводят ли настройки к сбросу соединений после простоя.

3. Логирование и мониторинг:
   Увеличьте журналирование: Включите подробное журналирование как для приложения, так и для сетевых компонентов в Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-java-app
spec:
  template:
    spec:
      containers:
      - name: your-java-app-container
        image: your-image
        env:
        - name: LOGGING_LEVEL
          value: "DEBUG"