You have a Kubernetes cluster, now what?
Kubernetes has become the leading standard for container orchestration platforms. Most of you already have a cluster running somewhere that a development team uses. But, growing beyond that towards greater adoption and supporting multiple development teams can be challenging.
Management of cluster resources and user access are two areas that can quickly become a bottleneck to further adoption or lead to collisions between teams. Utilizing the right user interface can impact the ability to provide necessary support and provide developers with the resources they need when they need them. Supporting multiple teams can run the risk of unpredictable or ballooning costs if left unchecked.
By having a strategy to handle the growth and support of Kubernetes at your organization you can maximize the gains that can be achieved with its adoption while reducing confusion and implementation risk.
Choosing a Web Management Interface
Getting a visual representation of your resources in Kubernetes is the first step in providing a means both for developers and support staff to interact with the cluster beyond the command line tool kubectl. There are several representation tools to choose from, but consider what it will be used for and make sure it has the features you will need as more people are onboarded. One important required feature is the ability to integrate with other business applications and services e.g. LDAP. The ability to manage multiple clusters through one interface will also reduce complexity and confusion.
Rancher: More Than a Dashboard
“Rancher is a complete software stack for teams adopting containers. It addresses the operational and security challenges of managing multiple Kubernetes clusters, while providing DevOps teams with integrated tools for running containerized workloads.” – https://rancher.com/
Utilizing the Rancher management software provides more than a graphical interface. It provides capabilities in a single interface for future growth needs and integrates with several technologies commonly found in businesses today. Let’s take a look at a couple of capabilities that Rancher has that enables multiple development teams to work with Kubernetes.
Access Management for Developers
In order to effectively manage multiple people working in a Kubernetes cluster, Identity Access and Management (IAM) needs to be integrated into the platform. Rancher integrates with most IAM services out of the box.
Allowing developers to log in with their own credentials eliminates the need to share Kubernetes configuration files or tokens. Each user can download their own credentials through the web interface.
Combining users into groups and assigning them roles provides further management capabilities that lead to self-sufficiency for the development teams. By utilizing roles that map to IAM groups, individual access will no longer need to be managed by support staff.
Multiple Cluster Management
Rancher provides a single pane of glass for managing multiple Kubernetes clusters. You can create clusters, import clusters, and manage them through a single Rancher deployment. By utilizing a cloud provider, infrastructure management can also be included.
There are many reasons to need more clusters to support additional development teams, but it is important to note that adding additional clusters leads to increased costs of overhead, i.e. more management nodes. Thankfully, Kubernetes provides a native solution for maintaining separation between teams and resources without always needing another cluster: namespaces.
Namespaces
Namespaces are virtual clusters that provide segregation of Kubernetes resources and services. They let you set resource quotas to govern how much CPU and memory resources they can consume. They are the target for most service deployments in Kubernetes.
Adding additional teams can be as simple as giving them a namespace. They are also useful for enabling lifecycle management. Namespaces should be thought of as ephemeral and supporting a culture of deleting services or resources when not in use will also reduce capacity demands. Increasing capacity to support more namespaces is done by increasing the number of worker nodes in the cluster. Overcommitting namespace limits to the cluster will encourage refinement of these limits over time, which will improve overall cluster efficiency. This leads to a greater ROI by increasing usage while minimizing overhead costs.
Once multiple teams start using the cluster, it will become cumbersome for your support staff to manage all the namespaces. Providing a way for developers to manage their own namespaces will become essential. Rancher provides one more feature that addresses this, Projects, and makes scaling to multiple teams even easier.
Rancher Projects
Projects are a collection of namespaces. This may not seem like much, but it means minimal configuration is needed to achieve self-service capabilities that support multi-tenancy. Creating a project for each team and granting roles with permissions to manage namespaces and resources within that project will empower your developers with everything they will need to work in Kubernetes.
The only caveat is that namespaces need to be created through Rancher, or when using a kubectl-created resource, to have the appropriate project association annotations.
Projects have their own resource quotas which are applied to all of their namespaces. This makes forecasting and management of capacity easier. Providing development teams with the ability to create their own namespaces and freeing your support teams from needing to micro-manage resources needed for developers to work within Kubernetes will enable easy adoption across any organization and minimize support costs.
Beginning Your Journey
Taking the leap from your first Kubernetes cluster to wide-scale adoption should no longer be as challenging as you might have thought. By first deciding on a graphical interface that everyone will use, your journey towards wider adoption will begin. It will enable a standard support framework and provide increased awareness of your Kubernetes offerings. Through a tool like Rancher, you can utilize a single interface that can be used by support staff and developers to manage multiple types of clusters.
Next, you will need a way of addressing access control and integrating it with your existing IAM solutions. The authorization to manage resources in a Kubernetes cluster, or even to create new clusters, is something that needs to be implemented early to avoid collisions between teams.
Remember that namespaces are the lowest common denominator of Kubernetes when it comes to service delivery, not whole separate clusters. Maximizing the use of namespaces and minimizing the creation of additional clusters will greatly reduce costs.
Consider higher-level capabilities that support multi-tenancy, such as Rancher’s projects. By utilizing Rancher’s project feature, minimal configuration is needed to provide each team with the capabilities they need to be successful in Kubernetes, while also reducing support demands.
With a strategy to address the challenges of growing your Kubernetes usage to multiple developer teams, it is possible to manage the costs and risks of adoption.
