Is Namespace-As-A-Service the Evolution of Cluster-As-A-Service?

Choosing a Namespace-as-a-Service strategy will incur cost and development time upfront; cluster-as-a-service defers operational complexity and cost until cluster count grows. However, as cluster counts grow in large organizations, perhaps Namespace-as-a-Service is an evolution of Cluster-as-a-Service.

Kubernetes Cluster-As-A-Service (k8sCaaS)

Each user or team is provided with a cluster that they manage and control. They don’t undertake the installation and build process, which is automated, and depending on the level of development of the k8sCaaS service, additional standardized components and other necessary capabilities such as cluster access and storage are also provisioned. Once provisioned, the day-to-day operation of the cluster is undertaken by the user. The users have the equivalent of superuser access and the most or all of the responsibility for operational security. In some cases, there is oversight from a k8sCaaS team; in other cases, none.

Are All Kubernetes Ingresses the Same?

The simple answer is yes and no, but the real answer is more complicated. There has been a lot written on this topic, and I am taking a shot at making this area more understandable.

Before getting started, it's important that I point out a key fact. k8s Upstream does not provide an Ingress. Like components such as service load balancers and storage, it simply provides the API that the controller should consume to create the functionality described in the k8s resource. An Ingress consists of the controller watching k8s APIs and the proxy engine that is programmed by that controller to affect forwarding.