3 ms·

> Am I crazy for thinking that this misses the whole point of the technology? Multi-cluster is not an accidental evolution. It was largely inevitable. Kubernet

> Am I crazy for thinking that this misses the whole point of the technology? Multi-cluster is not an accidental evolution. It was largely inevitable. Kubernetes has no hard tenancy concept (no, cobbling together a pile of namespaces and feature encrustations and calling it "tenancy" doesn't count). Instead people simulate tenancy with multiple clusters, because that isolates a particular API server's data completely. While early attention and nerd glamour may have attached to the idea of workload consolidation, the true nexus of value these days is the API itself. This will probably remain true even while people are being burned by multi-cluster waste. There will be some movement to one of the various I-can't-believe-it's-not-multi-cluster solutions that are currently swirling around. Vendors of all sizes will be standing by to sell their take on the Kubernetes of Kubernetes.

dharmab 5y ago
To clarify- Kubernetes as typically configured has strong multitenancy for API access control. However, other aspects of multitenancy such as memory, CPU (including cross-container data leakage), network, disk/filesystem are implementation dependent. The most common implementations (i.e. on Linux with Docker or containerd) provide generally weak or no control over each of these aspects. Some (Kata Container, Firecracker) have stronger controls, and some (Windows Server Containers) have even fewer controls. But for complete separation, either separate worker node groups with very strict, limited API access or separate clusters are needed.