Organizations are rapidly evolving tools and processes to better support DevOps cultures that aim to deliver applications and services at higher velocity. A byproduct of this evolution for VMware administrators is the need for increased collaboration with development teams and in many cases expansion of responsibility.
That responsibility can include maintaining application service levels in concert with the DevOps teams. vSphere has traditionally been a platform focused on infrastructure operations – providing a backbone of performance, security and reliability that businesses embrace. With the announcement of Project Pacific, VMware is tightly coupling Kubernetes with vSphere – enabling operations and development teams to collaborate in new ways.
Kubernetes and The VI Admin
Modern applications are also driving change for administrators. When applications were deployed as some variation of the LAMP stack – with application servers, web servers and databases deployed in just a few VMs – administrators could manually troubleshoot infrastructure issues and ensure platform availability and performance.
Applications are now being delivered as a myriad of discrete services that run in many form factors. They could be running in containers – as Kubernetes pods, directly as serverless functions, or as more traditional VMs. More and more, the application consists of a combination of these. This is the modern workload. Administrators need the ability to manage infrastructure, set policy, troubleshoot and monitor at the workload level rather than one VM at a time. Developers require the platform to be imbued with their preferred tooling – or they will look to public cloud for their services.
Modern Application Workload
Kubernetes Namespaces provide additional qualification to resource names and enable soft multi-tenant capability on a Kubernetes cluster. With Project Pacific, admins now have the ability to create Namespaces within vSphere. The vSphere Namespace is an abstraction onto which admins attach policy and then assign to development teams. More specifically, authentication and authorization for Namespaces are enabled through vSphere Single Sign-On and Administrators align Storage and Network policy with corresponding Kubernetes constructs through the Namespace. Administrators are able to create and manage these Namespaces directly through the vSphere Web Client.
vSphere Namespace Associates Policy with Modern Application Workload
Consider the scenario where a development team needs access to infrastructure for the development of an IOT application. They will create an automated pipeline for application development and testing. Test plans might include integration and scale testing. The availability and performance of this pipeline is critical to the productivity of the development team. The vSphere administrator can create a Namespace on vSphere. That Namespace would enable access for the IOT development team and would also assign storage policy that ensures high availability and performance for the pipeline. Resource controls would limit the possibility that scale testing might infringe on other teams sharing resources and network policy would enable appropriate Ingress/egress. The namespace policy could also enable access to applications deployed as Kubernetes custom resources or as externally managed VMs – with an appropriate resource consumption policy.
vSphere and Kubernetes Namespace Demo
The following product demo will show you how to create vSphere Namespaces and enable policy for your development teams. You will also see how Namespace policies are enforced through both vSphere and the embedded Kubernetes clusters.
