Mysql 5.7 innodb_buffer_pool_size - zero I/O?
Your ulimit -a report indicates Open Files is limited by the OS to 1024.
From your OS Command Prompt, ulimit -n 32000 would increase this limit dynamically.
Shutdown then restart your instance would make the additional file handles available and reduce opened_tables, opened_table_definitions, opened_files.
For this change to persist over OS restarts, follow this url - https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/

but use 32000 rather than 500000 used in their example.

Suggestions to consider for your my.cnf [mysqld] section
Rate Per Second - RPS
innodb_lru_scan_depth=100  # from 1024 to conserve 90% of CPU cycles used every second for the function
innodb_buffer_pool_dump_pct=90  # from 25 (percent) to reduce warmup bp time required
innodb_io_capacity=2000  # from 2500 to extend life of your NVME device
read_buffer_size=192K  # from 1M to reduce handler_read_rnd_next RPS of 160,774

REMOVE innodb_io_capacity_max to allow MySQL to
auto calc the max as innodb_io_capacity*2
Many more opportunities exist to improve your configuration.  View profile, Network profile for contact and free downloadable Utility Scripts to assist with performance tuning, specifically our findfragtables.sql will be helpful.
Monitoring SHOW GLOBAL STATUS LIKE 'innodb_data_reads'; divided by uptime for read rate per second should be your primary consideration for when you need more RAM to support your innodb_buffer_pool.  The provided SHOW GLOBAL STATUS data indicates RPS of 16.  Many people are OK with up to 100 RPS.  Less RPS is desirable, when funds are available. 0 RPS is likely unnecessary due to the way innodb only ages out of RAM the least recently used data.