I guess there are a couple of misunderstandings on your side.
in any time the next upgrade from Debian (Buster) to the next version.
The next Debian version is called Bullseye. We expect a release from Debian side mid of 2021
I think the so call next kernel, will occur.
A Linux kernel is something different than a Debian Version like Buster or Bullseye. There are multiple kernel release during a life cycle of a Debain version. There are released time by time https://en.wikipedia.org/wiki/Kernel_(operating_system)
What is the best way for an end user of DietPie like me to deal with this?
No need to rush. We still have users, running Debian Stretch where Buster was released 1,5 years back.
Does this mean that after installing the next DietPie Version and all the software/servers again that they will run again?
A DietPi version has nothing to do with Debian Release or a Kernel Release. DietPi is some set of scripts on top of an operation system. Officially DietPi supports Debian Stretch and Buster. Unofficially, Bullseye should be working as well already. Stretch support will be dropped as soon as Bullseye will be released. But this doesn’t mean Stretch systems will stop to operate. They simply will not receive DietPi script updates anymore from DietPi side.
I guess there will be an upgrade soon after?
DietPi will not force or offer Destro upgrades. Something the user would need to take care. An example how this could look like from Stretch to Buster https://dietpi.com/forum/t/qbittorrent-version-shipping-with-dietpi/2326/9
But as already said. Nothing to rush.
Is there an function within DietPi which simplifies the transition (backup and restore) of configurations, …?
dietpi-backup provides full system backup. It’s not intend for single config files. It always will save your entire system. Restoring a Buster backup on a Bullseye system, will downgrade your system back to Buster
I dont know, but would Docker ease the transition?
Something to check with Docker what and how it is possible
I dont know if its possible to run all the programs in different containers and if it does make sense.
Depends on the availability of Docker images for your applications.