From a sysadmin/config management side of things, and since I "dabble" with networking, I've always been rather jealous of the network appliances. All the serio

From a sysadmin/config management side of things, and since I "dabble" with networking, I've always been rather jealous of the network appliances. All the serious network devices had a single configuration file. Often the lines in the config file were equivalent to shell commands. For any network device, you could put the list of all the commands in notepad, as a script. But, if you exported the config file, it would look like a nicer version of your "script". With config management, be it puppet, chef, salt, ansible, you start to approach that. Except these only manage the resources you define. If your config management manages apache resources, and someone wandered in and installed nginx that's out of scope. If you've got a list of machine-local usernames that you want to exist, you might not thinking about ensuring that other usernames are absent. With kubernetes, it gets a bit closer. Let me preface that standing and running your own kubernetes cluster is a separate level of complexity, but once you have a k8s cluster, you can dump out a list of all resources (namespaces, pods, volumeclaims, ingress controllers, services...), modify that resulting file and apply it. Most people work in chunks, having a yaml file for each set of associated resources, or template those into a helm chart. With that, you can put all associated resources into a release, which you can delete and recreate as you desire. There's still lots of gotchas, especially around persistence. It's not uncommon to find an orphaned volume claim that prevents your release upgrade from continuing until you dig in with 3 coworkers watching you as you try to remember if it's safe to delete that or not.