In the previous blog post we spoke about the fact that Kubernetes is “just another thing to manage”. That is the case for cloud architects and operators that are responsible for providing Kubernetes as an endpoint within the clouds they are managing. Alongside other cloud services that the business needs.
In this blog post we will look at the most common use cases that are relevant for cloud architects to consider when creating cloud services that provide Kubernetes to the consumers of the cloud platform.
One thing to point out is the fact that these use cases are specifically targeted for enabling and managing Kubernetes within a cloud operating model. Managing, configuring and operating Kubernetes clusters is still a task for Kubernetes operators. The goals for cloud architects is enable them to do their job and deliver a friction-less experience when it comes to using Kubernetes.
1. Provisioning Kubernetes clusters
The ability to provision Kubernetes clusters is typically the first service that needs to be created.The result of such a service is a Kubernetes endpoint. That endpoint can then be used to deploy new container applications on top of or to start developing new container applications.
After provisioning there should be the ability to modify the Kubernetes cluster configuration. To add / remove nodes, to apply Role Based Access Control, to modify network and storage attributes, etc.
This should provide Kubernetes operators with the ability to control and manage the Kubernetes clusters.
For more information on this look at the post “vSphere with Kubernetes, vRealize Automation, and Tanzu…A Perfect Match!”
2. Deploying container based applications on top of Kubernetes clusters
The purpose of Kubernetes clusters is to run container applications. Cloud architects should be able to incorporate those into the services catalog for cloud users to consume these applications.
Basically a cloud service deploying a container application needs to have the location of the container image(s) and the Kubernetes cluster where this needs to be deployed to.
The cloud service can be defined restrictive. Meaning the cloud app will be deployed to a Kubernetes location that has been defined by the cloud administrator. Or the cloud user has the ability to configure which app is deployed to a certain Kubernetes cluster of choice.
All of this of course depends on the amount of flexibility that the cloud user is given through self-service by the cloud operator.
3. Integrating Kubernetes with GitOps
There is currently an evolution taking place within Cloud Operations. With the adoption of DevOps practices also comes the evolution to adopt developer practices. GitOps is becoming the new way to get cloud and infrastructure services into production. For more information read this blog post about GitOps and the cloud operating model.
For that there needs to be an integration with all infrastructure and application components, including Kubernetes. Creating infrastructure pipelines with Kubernetes is nowadays a must have. Having the ability to do that makes sure the cloud can be used to deploy workloads to both virtual machines and container instances.
4. Monitoring Kubernetes infrastructure
Another use case that we need to look into from a cloud perspective is the monitoring of Kubernetes stacks. When Kubernetes becomes an integrated component into the cloud services there needs to be a way for cloud administrators to monitor the Kubernetes stack from top to bottom.
There is however a distinction between monitoring from an application perspective or monitoring it from an application perspective. Typically the cloud administrator is responsible for making sure the Kubernetes clusters are deployed and managed. The developers and platform engineers are typically responsible for running and managing the container applications that run on top of the Kubernetes stack.
Different objectives when it comes to monitoring the Kubernetes stack and observing the applications then run on top of it. For more information about this read the blog post “Kubernetes Observability & Monitoring in the Cloud”
5. Financial insight for Kubernetes
Something that is often forgotten is the ability to provide insight into the Kubernetes stack from a cost perspective. It become more important to provide financial insight as organizations adopt Kubernetes and move towards a cloud operating model.
The person or team consuming the infrastructure and application resources need to be the ones that pay for the those resources. Or at least there needs to be show back to make people aware of the costs associated with their consumption.
Financial Operations (FinOps) is more and more becoming a relevant topic when people adopt a cloud operating model. So definitely something cloud architects need to provide the right solutions to provide the financial insight for the consumption of Kubernetes.
For more information on this look at the blog post from CloudHealth on how to make Kubernetes cost allocation easy.
Hopefully this blog post has given you some ideas how to provide Kubernetes services towards your consumers of the cloud platform. As your cloud platform evolves there will be more use cases and cloud services that apply to Kubernetes. And with the evolution of Kubernetes we will see more and more adoption within IT organization of the Kubernetes stack. To learn more about Kubernetes join the VMware Kubernetes Academy.
