It provides soft multi tenancy via namespaces. You can then use NetworkPolicy if the CNI supports it to manage what other stuff can communicate with the Pods in that namespace.
You can also schedule Pods on Nodes that are for a specific purpose (eg only used by a specific team or product) by using various scheduler stuff like taints and affinity/anti-affinity.
Or you can write a custom scheduler.
In general I feel like all the tools are there in Kubernetes to build a good multitenant experience but it's also just easier to run a number of clusters, especially if you're cloud hosting where the control plane is usually free and you pay only for the workers.
I'd say the amount of isolation to be sufficient, depends on the threat model. If you want some isolation but moderately trusted workloads (e.g. different departments in the same company) that's easier than the isolation required for "arbitrary customers can run any workload on a given cluster"
Multi-tenant, single cluster is tricky. You either need node pools per tenant, at which point why not run one cluster per tenant, or you need really good isolation of the workloads from the nodes, which requires PodSecurityPolicy or similar to prevent a breakout to the underlying node.
Also RBAC can be tricky in a multi-tenant setup as you need to be very careful with anything that would allow breakout to the underlying node or any cluster level rights.
You can also schedule Pods on Nodes that are for a specific purpose (eg only used by a specific team or product) by using various scheduler stuff like taints and affinity/anti-affinity.
Or you can write a custom scheduler.
In general I feel like all the tools are there in Kubernetes to build a good multitenant experience but it's also just easier to run a number of clusters, especially if you're cloud hosting where the control plane is usually free and you pay only for the workers.
I would though ask, what is sufficient isolation?