Containers were never meant to be "secure" and Kubernetes has nothing to do with security in general. Application level containerization solves 3 problems: 1- repeatable builds 2- software distribution 3- infrastructure mutability
Docker solves brilliantly all these problems: we can build software in controlled environments that we call images and the product is an image itself, that we can share by means of software catalogs called registries and that we can deploy the same way we can play CDs in a computer, without modifying the host system. Security was never meant to be a concern, it was never part of the plan, at least no more than running a process in an operating system. And containment systems are just a smart way to launch a process, that's it. They can't replace security functionalities beyond what is already provided by host OS.
Is this a fault? Would you blame a hammer for not being able to unscrew a cork?
NanoVMs CEO spends some time also making fun of "stripped down systems", accusing them of recklessly "ripping out components of a system that simply don't belong in the virtualized world of 2020", namely users, SSH logins and desktops. Again, there is a big misunderstanding here. Linux processes expect some facilities to be present at runtime, namely system calls to retrieve Process IDs and user IDs. But these facilities were merely retrofitted in containment systems to avoid processes crash upon syscall invocations. As all retrofitted functionalities, their implementation is barely beyond the dummy level. Therefore, we have PID 1 everywhere, no SSH logins and dummy users.
Now, Kubernetes. K8s is just a scheduler, an orchestrator. It has nothing to do with security, it is mainly concerned with resource optimal usage and container placement. And it is a fundamental component in microservice world, otherwise we would be paralized by operations at each deployment. "You spin up a linux box and call it a day - done". Seriously? Is this really the whole understanding of the world of operations? I've been in ops for 12 years and I'd never want to go back to the old bad days of 2008, where most of us managed an handful of servers and services and, yet, datacenter ops were at one with deployment ops. That was the very world of manual and error prone ops. Orchestration has been a bliss but requires a unit of scheduling. A container, in this case. But it may be a VM as well.
So, the saddest thing here is that NanoVMs could be a perfect replacement for containers while retaining the benefits of orchestration (as in Kubevirt, for example), but the CEO prefers to throw away the dirty water along with the baby for marketing hype.