There are cases where developers may prefer to use tools on their laptops such as Lens Desktop to visualize resources and interact with Kubernetes clusters. The use of a desktop based app such as Lens can be a better user experience for developers over the Kubectl CLI.
In this blog, we will describe how Platform Teams can use Rafay’s Zero-Trust Access service to enable developers to use popular Kubernetes visualization apps to troubleshoot their applications. Watch a video showing how a developer can use Lens Desktop with Rafay's Zero Trust Kubectl Access service to securely and remotely access Kubernetes clusters.
Some of the key questions that platform teams have to think about very early on in their K8s journey are:
How many clusters should I have? What is the right number for my organization?
Should I set up dedicated or shared clusters for my application teams?
What are the governance controls that need to be in place?
The model that customers are increasingly adopting is to standardize on shared clusters as the default and create a dedicated cluster only when certain considerations are met.
A[Request for compute from Application teams] --> B[Evaluate against list of considerations] --> C[Dedicated or shared clusters];
A few example scenarios for which Platform teams often end up setting up dedicated clusters are:
Application has low latency requirements (target SLA/SLO is significantly different from others)
Application has specific requirements that are unique to it (e.g. GPU worker nodes, CNI plugin)
Based on Type of environment - ‘Prod’ has a dedicated clusters and 'Dev', 'Test' environments have shared clusters
With shared clusters (which is the most cost efficient and therefore the default model in most customer environments), there are certain challenges that platform teams have to solve for around security and operational efficiencies.