My work-from-home workstation always has a VM or two running the test/dev environment for the tasks I’m working on at work. They are VBox instances provisioned/managed by Vagrant.
They are CentOS7 instances, each running a test database, usually a text editor, “tail -F” monitoring log output, and various daemons/services specific to my workplace’s internal infrastructure. The host system is running Slackware 15.0.
A variety of things: Books, movies, music, scientific journal publications, Slackware’s “current” branch with all past packages since 2009 (only half a TB though), All Slackbuild sources, an almost-complete crawl of CentOS 6 packages, large language models and datasets (almost 8TB now), an old TankNet archive, a few wikipedia dumps about two years apart, chat logs, archived email, a lot of smaller archives of niche interests … it’s something of a mess.
Docker and Kubernetes are popular mostly because the industry has broadly given up on release engineering. This means applications/services can have different and conflicting dependencies, so the only way they can run on the same physical host is by putting each in their own containers or VM instances, each with their specific dependencies.
The alternative is to have a platform with standard libraries, and to port applications to the platform, using the platform’s libraries as their dependencies, and thus avoid conflict. This requires effort and discipline, so of course it is not very popular, though it was the standard practice twenty years ago.
As far as I know the only Linux distribution which still follows the platform approach is Slackware. Applications which are ported to Slackware are guaranteed to work well together without conflicts, but not a lot of applications have been thus ported (Slackware only has about two thousand official packages, in all).