Forem: Deepankur Singh Baliyan

Introduction to Multi-Tenancy in Kubernetes

Deepankur Singh Baliyan — Thu, 09 Dec 2021 09:44:01 +0000

What is multi-tenancy?

The idea of sharing a single instance of an application or of software among various tenants is called multi-tenancy. This approach is quite popular since the rise of cloud environments. Now, with the introduction of Kubernetes, developers and administrators require the same approach to be implemented on Kubernetes clusters. As that would provide better resource utilization, provide better management of underlying compute resources, and reduce cost.

This blog post will discuss various available approaches to introduce multi-tenancy in Kubernetes clusters and will try to draw a comparison between all of them.

Where multi-tenancy serves better?

Before even discussing multi-tenant architecture, one should know whether it is better to deploy a single Kubernetes cluster with multi-tenant support or should deploy multiple clusters, different for each tenant.

To begin with, there is no specific rule for this and most organizations decide this on the basis of ease of use, management etc. Deploying multiple clusters is simple as you don’t have to worry about following additional best practices such as auditing RBAC, setting up standard practice for users. Besides this, cost also plays an important role while making this decision. If cost is not an issue and you want simple architecture, deploy multiple clusters. Whereas, if your compute need is far less and you want to save some extra cost, multi-tenancy could be a better option. Some other factors also play a vital role such as the lifecycle of your cluster, if your need is only temporary, multi-cluster could be a viable option, as you don’t have to install anything else on your cluster.

One major drawback of having multiple clusters is the increased management overhead, specially for the large environments, it requires a lot of effort to keep every cluster updated, more security audits would be required as well. It is worth noting that while you may use a multi-cluster approach, you shouldn’t block future expansion around the multi-tenancy by making some little mistakes like deploying all applications in the same namespace.

Different approaches of multi-tenant architecture

Multi-tenancy in Kubernetes can be categorized in two broad terms:

Soft Isolation: In this, we have a single enterprise with different teams accessing the same cluster, this requires less amount of security overhead as users can trust each other.
Hard isolation: This is required where the Kubernetes is exposed to multiple enterprises with independent and completely untrusted users.

There are various approaches discussed in KubeCon Europe 2019 wherein every approach can be enlisted in either of the two mentioned above categories.

Source

The above-shown diagram outlines 4 different approaches to consume Kubernetes clusters in your environment.

Approach A This doesn’t provide an exact multi-tenant solution as it deploys different Kubernetes clusters. However, can be still considered as in this solution each tenant will receive a different Kubernetes cluster, which is completely isolated from any other compute resource. This can be implemented by using segregated VM providers like Amazon EC2, GCP compute instance, and vSphere VM’s.
Approach B This is one of the popular architecture, wherein segregation is based on namespaces. This provides soft isolation among different tenants. With this, tenants can only see, modify, and create objects within their namespace. Moreover, they can create policies for security and roles within their namespace. There are two major drawbacks in this approach, the principal one is shared master components like API server and the other one is the provisioning of Cluster scoped resources. The main work carried out for the development of this approach is done by Project HNC (hierarchical namespaces).
Approach C This approach provides a way to implement hard isolation among Kubernetes tenants who have no trust between them. This provides segregated master plane components for each tenant by creating a mini virtual cluster on the super Kubernetes cluster. Admins can also create custom resources in those virtual clusters as well. This is provided by projects like VirtualCluster and vCluster.
Approach D Different from all of the above approaches, this suggests that Kubernetes should provide the support for creating tenants out of the box. It is not yet developed, because of the efforts that it would require to modify the Kubernetes source code.

Comparison of various solutions

	VM based Segregation	Namespace based Segregation	Virtual Clusters
Isolation	Hard	Soft	Hard
Effective Resource Consumption	Less	High	High
Tenants can use all Native Kubernetes objects	Yes	No. Cluster scoped resources can’t be used	No. Resources that require underlying node information like DaemonSets can't be used
Availability	Ready	Still waiting for General Availability but production-ready.	Some solutions are available like vCluster but some are still waiting for General Availability like VirtualCluster
Additional overhead on Kubernetes	None	Very Little	Little to medium as it spins up a new control plane for each mini cluster.

Some use-cases for multi-tenancy in Kubernetes

SaaS Applications

Implementation of multi-tenancy can enable organizations to centrally manage the infrastructure for their multiple customers. This makes it easy for SaaS organizations to manage their infrastructure shared among different tenants.

Better Resource Utilization

Fewer clusters will be needed as multiple teams can share a single cluster. Thus, utilizing cluster resources more efficiently.

Conclusion

To conclude, multi-tenancy is an important aspect of Kubernetes which does not come out of the box, but can be implemented via various strategies. It can extend the usability of Kubernetes, helps to achieve better resource utilization, can save billing costs, and can also be important for the cluster administrators for managing various microservices in an efficient manner.

That's it folks. Hope you found this article helpful for getting started with multi-tenancy in Kubernetes. Do ask your queries and share your experience via Twitter.

References

Prometheus Definitive Guide Part I - Metrics and Use Cases

Deepankur Singh Baliyan — Fri, 12 Mar 2021 12:21:32 +0000

Prometheus is an open source metrics-based monitoring system. It has a multi-dimensional data model and has a strong query language to query that data model. This blog post will discuss monitoring in general and Prometheus from a beginner's point of view.

Monitoring in General

Monitoring is a process of collecting, analyzing and displaying useful information about a system. Monitoring should primarily cover:

Alerting: The primary goal of monitoring is to know when the system fails and generate an alert.
Debugging tools or techniques: Another goal for monitoring is collecting the information that helps debug a problem or failure.
Generating Trends: The data collected by a monitoring system can be used to generate trends which helps to adapt for the upcoming changes in the system.

Prometheus Architecture

Image credit: prometheus.io

The above figure depicts the detailed architecture of Prometheus. It contains one centralized monitoring server (Prometheus). All of the other components like the Alertmanager and Grafana provide extensibility to the main monitoring server. We will divide the architecture into four parts to understand it better.

The first part is the targets that generate the data. The Data can be exposed to Prometheus through client libraries and exporters. Client libraries can help you create & expose metrics from your application code, and exporters are being used when you can't change the application's source code. Prometheus uses various exporters to monitor third-party applications like an HTTP server or a database. You could find more details about the exposition format in the Exposition Formats document.

The second part is to find the targets and collect the data. Prometheus uses the service discovery mechanism to detect the targets in an environment. It supports integration with EC2, Consul, Kubernetes, and various other platforms to perform service discovery. The process of collecting the metrics is called scraping the targets.

The third part consists of storage. By default, Prometheus is configured to store data on a local disk. It can also integrate with various types of remote storage solutions for creating a more resilient solution.

The final part comprises alerting and visualization. The alerting rules can be configured in Prometheus, but a separate component called Alertmanager is needed to manage the alerts. For visualization, You can use PromQL to query the metrics and generate graphs in the Prometheus web UI. Along with these graphs, dashboards can be generated using tools like Grafana.

There are two ways in which a monitoring solution can collect the metrics — pull-based and push-based. Pull-based is more popular than the latter nowadays, as it doesn’t require any configurational changes in the entities being monitored. Prometheus server itself uses a pull-based mechanism. A push-based metrics collection can be achieved with a component called Pushgateway. You could find a brief detail about pull-based vs. push-based here.

Prometheus Metrics and Data Model

Prometheus stores all of its data in time series. Each time series consists of a metric, a unique set of labels, and a value for each timestamp. Metrics are the quantitative measurements of a system property. Labels are the key-value pairs associated with these metrics. Labels enable the filtering and aggregation of metrics through PromQL.

Deep diving further, metrics can be classified into four categories. To understand the metrics types better, we will be taking an example of a football match. We will define each metric type and then look at an example for it from our match.

Counter

For recording a value that is always increasing, a counter type metric gets used. For example, the total number of goals scored in a match. We can use a counter type metric to store it as this value doesn’t decrease.

Gauge

For a value that can increment as well as decrement, a gauge metric gets used. For example, possession of a ball in a football match can vary in the range of 0 to 100. It can increase or decrease with time as they play through the game.

Histogram

A histogram counts the frequency of occurrences of some sample values. It also provides information regarding the total values observed and their sum. For example, we can use a histogram to calculate how many players have completed the passes less than 10, 20, 30, 40, 50, 60, etc. Note that the 10, 20, 30, 40, 50, 60 series is pre-defined in a histogram.

MetricName	Value
player_completed_pass_bucket{le=10}	0
player_completed_pass_bucket{le=20}	2
player_completed_pass_bucket{le=30}	7
player_completed_pass_bucket{le=40}	14
player_completed_pass_bucket{le=50}	19
player_completed_pass_bucket{le=60}	22
player_completed_pass_bucket{le='Inf'}	22
player_completed_pass_count	22
player_completed_pass_sum	790

Summary

Summary type is similar to a histogram, as it also counts the frequency over sample values. Additionally, it provides information regarding the total values observed and their sum. Besides this, it adds a label by default to the base metric, i.e., quantile. Quantile tells how many percent values are behind this value. The general quantile which gets assigned to summary ranges from 0 to 1. It is recommended to use summary when you don't have a pre-defined list of buckets. A detailed comparison of Histogram and summary is given here.

Common Use-cases around Infrastructure Monitoring

So far, we have briefly covered Prometheus and metrics. Before concluding this post, let's have some hands-on experience as well. We will build some use-case around infrastructure monitoring like CPU/memory usage. We will skip the deployment of Prometheus for this post, but you can use a demo instance available here. One can also deploy their own demo instance using this Git repo.

We can query the data stored in Prometheus using PromQL queries. Queries can be executed through the expression browser in the Prometheus web UI. For this part, we will learn the basics while going through these use-cases.

CPU Usage

The metric which we are going to use is "node_cpu_seconds_total". This is a counter type metric, and it is used to calculate the seconds for which the CPU is running in a particular mode. CPU has various modes like iowait, idle, user, system, etc. As we are calculating usage, we will drop the idle mode. This is the reason our query looks like this:

sum by (cpu)(node_cpu_seconds_total{mode!="idle"})

We used the sum function to merge all CPU modes. It results in seconds for which the CPU was running since the beginning, but we need to know whether the CPU was busy or idle recently. To do that, we use the rate function, which calculates the growth rate for a counter.

sum by (cpu)(rate(node_cpu_seconds_total{mode!="idle"}[5m]))*100

The above-mentioned query will generate the growth rate for the past five minutes to determine how much computing power is being used by the CPU. As all CPU modes add up to 1, we multiplied our query by a hundred to get the result in a percentage.

Memory Usage

The following query can calculate the total percentage of used memory:

node_memory_Active_bytes/node_memory_MemTotal_bytes*100

This is very straightforward and uses the formula of "used divided by total and multiplied by 100".

Free Disk

Free disk usage is required to know when you need more space on your infrastructure nodes. Again, we will use the same memory usage approach, but the metric names will get changed.

node_filesystem_avail_bytes / node_filesystem_size_bytes *100

Conclusion

In this blog post, we discussed Prometheus and metrics. We looked at its architecture and ran some queries to get us started. In the next post of this Prometheus definitive guide series, we will cover PromQL query language in detail.
Hope you found this article helpful for getting started with Prometheus. Do ask your queries and share your experience via Twitter.

References

The official Prometheus documentation. Available at: https://prometheus.io/
Brazil B.(2018) Prometheus: Up & Running. O’Reilly
The official Prometheus blog available at: https://prometheus.io/blog/
Robust Perception demo installation. Available at: http://demo.robustperception.io:9090/consoles/index.html