Even just for Kubernetes administration, it’s probably good to keep tabs on Linux, especially technologies like cgroups, even if your nodes are managed.
Bare metal on Kubernetes is a PITA though to set up. For extremely small scale stuff in private labs, okay, that takes half an hour, but as soon as you are on the Internet, maybe have a couple rented bare metal machines, it gets nasty. For ingresses, you'll usually need to set up MetalLB which requires acquisition of a range of IP addresses and it only is capable of running one server (the "speaker") as the one and only entrypoint for all traffic. Not to mention you cannot have roles such as "internet-exposed node" and "not internet-exposed node", since MetalLB wants to run on all nodes.
Also, a Kubernetes environment will need at least four separate network ranges - a network for the Pod IPs, a network for cluster IPs of services, one for the nodes themselves and if you want to expose stuff to the Internet you need a fifth one that holds the public-routed IPs. This is really funny if you are in a corporate environment that uses all three of the historic private ranges (10.0.0.0/8,172.16.0.0/12,192.168.0.0/16), good luck carving out ranges that do not result in routing conflicts.
Mesosphere DC/OS was more usable in that regard as it had pre-defined the roles of nodes, included the load balancer as part of the platform and had only two IP ranges (node-internal and whatever the public IPs of the public nodes were)... whereas it's clear that the only designed/supported way to run a major Kubernetes deployment is to use a fully-managed Kubernetes provider. Everything else is a world of undocumented, spurious-bug-filled stuff and incomplete documentation.
I think you are misunderstanding the previous comment. I read it as Kubernetes being so complicated (I enjoy it, but that's another discussion) to operate is making the regular bare metal operation more appealing. So people might choose the well understood bare metal over Kubernetes.
> I can't help but think this trend will damage shared knowledge in the long run.
is an understatement. There will be a few people in the know on how to run "the cloud", and lots and lots of people consuming their services, at bewildering premiums.
I often skip the really in-depth kernel articles, since it makes no difference to anything I do if Linux gets a new slab allocator or whatever, but still find my subscription valuable for hearing about new project releases, as well as these deep project dives.
We don't even run any Linux ourselves at my current employer. Pods and lambdas and databases-as-a-service.
I can't help but think this trend will damage shared knowledge in the long run.