Kubernetes has become the de facto platform for running containerized workloads. Kubernetes brings a set of APIs for managing applications that can work with multiple infrastructure/cloud providers. Whether you want to deploy a containerized application on vSphere, AWS, or Azure, as long as Kubernetes is deployed in these environments, the API being used to request a container deployment stays the same. This helps application development teams tremendously. Instead of learning about various individual APIs offered by the cloud/infrastructure provider, or understanding the differences and maintaining separate deployment stacks for each cloud provider, Application Development teams now only need to learn a single API. This very feature in Kubernetes also provides portability of workloads across multiple clouds.
The reason Kubernetes can provide this singular API and work across multiple clouds is because of its architecture—it's designed to be extensible. Kubernetes defines various plug-ins/interfaces for common infrastructure tasks like defining compute, attaching storage, creating a load balancer, etc.; and the Kubernetes community works to ensure most major cloud/infrastructure providers are supported within these plug-ins/interfaces.
While Kubernetes simplifies how application developers use infrastructure to manage apps, maintaining and managing Kubernetes runtime itself can be a daunting task. Just imagine trying to figure out all the plug-ins/interfaces and tools needed to deploy a cluster on any given cloud provider.
A day in the life of a platform operations team managing Kubernetes
Figuring out and integrating all the plug-ins/drivers/interfaces needed to bring a Kubernetes cluster up and running is a non-trivial task. Imagine repeating the process every time a cluster is requested. The challenge on Day 0 for platform teams is to efficiently roll out secure, “batteries included” Kubernetes clusters that can be deployed (if necessary) across multiple clouds.
Once deployed, anyone who has access to the Kubernetes platform can start deploying objects and consume resources in the cloud/infrastructure provider. Additionally, the right level of access to the Kubernetes clusters is critical. Kubernetes has role-based access control that can be used to provide the right level of access. However, by default, Kubernetes depends on an authentication plug-in to authenticate users from an enterprise identity.
On Day 1, how do the platform teams hand over access to the Kubernetes platform to the right application development teams authenticated by enterprise identity services like active directory/LDAP? Or how do application development teams get self-service access to the Kubernetes platform that has been deployed?
As application development teams get access to Kubernetes and start deploying applications, platform teams do not have much visibility into what kind of containers are being deployed, how much compute/storage is being consumed by these workloads, and what kind of traffic is being exposed via micro-services. On Day 2, platform teams need a way to define enterprise-wide policies around container images, network, security, etc. that can be applied in a blanket mode across all the Kubernetes clusters automatically.
At the same time, when an issue is reported for any application that is deployed, do the teams have full-stack visibility into key metrics that will help them debug a problem or send warning messages before an issue is detected?
Moreover, the Kubernetes community releases upgrades and patches pretty frequently (Day n), so can the platform teams upgrade/patch/backup their clusters automatically?
How Tanzu for Kubernetes Operations helps
Tanzu for Kubernetes Operations helps enterprises manage, secure, and monitor Kubernetes clusters across clouds.
On Day 0, Tanzu for Kubernetes Operations provides automation to deploy Kubernetes clusters in minutes on any given cloud provider. It does this with the right set of plug-ins required for various cloud environments and secure instances to bring up the clusters. It also offers the ability to attach pre-existing clusters. (E.g, various cloud provider environments like vSphere and AWS can be added as infrastructure endpoints, and Kubernetes clusters with various nodes, versions, configurations can be deployed in minutes.)
On Day 1, platform teams can integrate their identity and map users/groups to clusters at the right level of access control. DevOps teams and application developers can log-in to the console and get self-service access to the Kubernetes API they have been pre-allocated. For example, active directory identity can be federated and a sser/group from active directory can be given Cluster admin access to a group of clusters across the cloud. When the end users log in, they can only access the clusters they have been allocated to.
On Day 2, platform teams can define enterprise-wide policies that can be applied to clusters across multiple cloud environments and Tanzu for Kubernetes operations will automate the process of applying the policy at each cluster. For example, as an organization, an image policy can be defined that will not allow any containers to be downloaded from a public registry like Docker Hub.
On Day 3, Tanzu for Kubernetes Operations provides full-stack metrics monitoring, including application, platform, and infrastructure.
On Day n and beyond, clusters can be automatically upgraded to newer versions, backups can be created, as well as the ability to restore clusters.
Links to additional resources to learn more about Tanzu for Kubernetes Operations
Watch this video to see Tanzu for Kubernetes Operations in Action:
Want to get hands-on experience with Tanzu for Kubernetes Operations? Try out a lab here:
https://pathfinder.vmware.com/v3/path/tko_path
Want to become certified on Tanzu for Kubernetes Operations? Take the free course:
https://modernapps.ninja/course/intrototko_tk5598/
Not running Containers or Kubernetes but want to find a path?
A lot of organizations today are thinking of moving their virtual machine-based workloads to containers and eventually manage them using Kubernetes. Application Transformer for VMware Tanzu, part of Tanzu for Kubernetes Operations can help discover applications within your vSphere-based footprint that can be containerized. It can recognize more than 200+ types of applications and dependencies, create a plan, and automatically build container images of existing workloads.
Checkout this blog to learn more about Application Transformer for VMware Tanzu.
