Kubernetes (K8s) originated as an open source platform to automate the deployment, management and scaling of the containerized applications across multiple clusters of hosts. However, over the last few years, Kubernetes has developed from being used just for container orchestration. Enterprises have started using Kubernetes more as a platform for implementing enterprise applications in a cloud-native matter. Despite the type of cloud in use (public/private), Kubernetes offers the developers a common set of tools with which they can build the application.
Enterprise Kubernetes Stack
As enterprises start making use of Kubernetes to build their applications, there will be multiple Kubernetes clusters running within the enterprise. As the number grows, the enterprise will start to realize the importance of a platform team to manage multiple clusters. The responsibility of this platform team is to provide operational governance and management to the clusters across the entire enterprise.
Bringing in Kubernetes for the entire enterprise gives the organization the flexibility to choose and define their stack using certified components. Let’s take a detailed look into the Enterprise Kubernetes Stack and discuss the components in detail.
⦁ Infrastructure
In order to run enterprise applications built on Kubernetes, you need an infrastructure setup. Infrastructure is the base layer in the stack. For the infrastructure, enterprises need to decide on the Compute, Storage and Network to be used. There are lots of choices available for enterprises from cloud servers to databases to use for their Kubernetes workloads. Talk about the leading infrastructure providers and cloud providers, everyone in today’s IT world offer support for Kubernetes for enterprises.
⦁ Kubernetes Distribution
Similar to any open source project (take Linux as an example), there are always different distributions that are made available in the market with additional features and capabilities. Every distribution is released to cater to a specific audience of users and it’s obvious that different users will prefer to stay on different distributions. Kubernetes is no different!
Since the introduction in 2014, there are several companies offering different distributions of Kubernetes. Before deploying Kubernetes in your enterprise, it’s important that you choose the right vendor and understand their offering clearly. The different types of vendors are –
⦁ Vendors offering battle tested version of Kubernetes (e.g., RedHat, Docker Community Edition)
⦁ Vendors who prefer to stay close to the recent release (e.g., cloud providers, Canonical and Rancher Labs, VMWare Kubernetes Engine, Pivotal Container Services, etc.,)
⦁ Vendors who are closest to the recent release (SAP, Weaveworks)
⦁ Vendors offering a battle-tested version to enterprises but additionally offer the flexibility to use any version of Kubernetes from their respective management platform.
⦁ Build and Version Control
Kubernetes improves the efficiency of the developers by providing one-click deployment capabilities. It also offers a simple build mechanism with which developers can build and publish their applications. Kubernetes integrates with version control and continuous delivery tools seamlessly. Organizations can take advantage of build tools like Jenkins to push the changes to clusters, and version control tools like Git to drive the different changes. The advantage of the build and version control capability of Kubernetes is that DevOps teams no longer have to focus on infrastructure management. They can focus their efforts on managing the applications.
⦁ Image Registry
The next item in the stack that you need to decide on top of the Kubernetes is the image registry. Image registry is the central registry where then application images will be stored. If you are running containerized applications on top of Kubernetes, the image registry plays a major role and it’s important that the Kubernetes clusters have access to an image registry. It’s important to choose an image registry solution with the security features that allow enterprises to store their confidential application images. The image registry should also have the capability to scan and make sure only valid/trusted application images are stored and deployed in the production environments.
⦁ Ingress
With Kubernetes, you will need an Ingress that will restrict the incoming traffic to the Kubernetes cluster. Kubernetes has the capability to automatically load balance the inbound requests (Layer 7 load-balancing) to the application inside the cluster. There are various choices of Ingress available and making the right choice will play a major role in providing advanced capabilities like end-to-end encryption.
⦁ Kubernetes Logging
Logging helps users to understand what is going on within the system. In this context, having a logging mechanism in place helps the developer to know what is happening within the cluster. If there are any issues identified, developers can debug the problem and monitor the activity within the cluster to identify the cause of the problem. In the case of Kubernetes for the enterprise, the log collection, aggregation, and reporting need to be aggregated between the Kubernetes cluster and the application workloads. These metrics have to be collected and shared with the teams and individuals.
⦁ Kubernetes Monitoring
A Kubernetes cluster actually might look like a single device, but it’s not in reality. Kubernetes cluster is a set of independent nodes and services that are connected together. Therefore, as important as it becomes to log what’s happening in the system, it’s important to keep an eye on the entire cluster. Similar to logging, you must use tools to monitor the cluster components and the different applications that are running within the cluster components. There are different offerings for monitoring Kubernetes from Rancher while the most used tool is Prometheus and Grafana. Similar to logging, these metrics have to be collected and shared to respective teams within the enterprise.
⦁ Kubernetes Enterprise Security
As the number of Kubernetes deployments is on the rise, it’s important for the enterprise to have the security measures in place to avoid any unauthorized access. Though Kubernetes offers basic security capabilities, it’s an important responsibility for the system administrators to add additional layers of security. The Kubernetes API service is the best entry point for hackers to get into the cluster. The API is normally exposed after every deployment (due to management purposes). Similarly, there are other services like the Kubelet API that is unauthenticated and are exposed to the external world which can be easily accessed by the hackers.
To overcome these security vulnerabilities, administrators can take advantage of different tools such as Project Calico, Kube-Bench, Twistlock, Aqua Security, NeuVector, Kops etc., to add necessary security measures. For instance, the Aqua Security tool offers native K8s capabilities while offering additional runtime protection and network security controls.
⦁ Application Management
The main purpose of running Kubernetes in the enterprise is to manage the applications that are running. This requires separate integration with different tools to manage the state of the application, security aspects, diagnose and troubleshoot problems, monitor and log the application diagnostics, maintain audit logs and other aspects of the application.
Wrapping Up
In summary, if you are to enable Kubernetes in your enterprise, it’s important that the enterprise needs a lot more across the entire stack than just the Kubernetes itself. Kubernetes can be implemented across any infrastructure. When implemented correctly, Kubernetes offers scalability by scaling the cluster horizontally when needed and later scaling down, workload portability by allowing users to run workloads on a public or private cloud or on a dedicated data centre and high-availability through load balancing and traffic routing.