Not to jump too far down this hole here, but the only difference between an Ansible playbook, a Dockerfile, and postgresql.conf is format (indeed you're probably pretty likely to somehow jam a postgresql.conf file into your configuration-as-code tool, diminishing the distinction even further). The whole impetus behind configuration-as-code and containerization was to avoid having to bother at all with the host OS; my argument here is that we would've been a lot better off just figuring out how to configure--for example--postgresql.conf on Alpine Linux rather than inventing Docker and Kubernetes.
But! I will admit Kubernetes is handy for stuff like specifying scaling properties... but I mostly feel like conflating the two things ("configuring services" and "configuring cloud providers") was an oops.
Virtualizing hardware and running extra copies of the kernel has a small overhead.
I'm not sure it matters for the majority of companies but it has a measurable impact for the gigantic ones.
Afaik containization was rooted in the ability to run multi tenant servers without semi trusted apps overstepping their bounds. See Google Borg and Facebook Tupperware (iirc they started as chroot automation and expanded)
Some stuff like Java have ran in a runtime level container long before OS containers so it seems a bit redundant there, but still facilities having conflicting versions of the runtime installed.
