PKS – Getting Started Part 1 Overview

/ vnuggets

Overview

Previously I have covered some of the basics in getting a Kubernetes cluster stood up and integrated with NSX-T together with demonstrating the concepts and integration between the two products. With this series of articles I want to introduce Enterprise PKS (Enterprise Pivotal Container Services) combined with vSphere and NSX-T and hopefully enable you to understand what it is, how it works and how it fits into the whole container space.

Note that is also an Essential PKS version which I will NOT be covering in this series.

What Is PKS?

Before I can dive into deploying a product it’s always a good idea to understand what it is and why you might need it. So, lets start off at the beginning and level set with some definitions.

Docker is an engine (aka a container runtime) that provides the ability to create and run software packages as images (known as containers) that include all libraries and settings that are required to run an application. Each image is standalone and lightweight and isolates the software within the container from the environment it runs on. This makes the application within the container run in the same way no matter where it is run.

Kubernetes is the management stack that sits over a container runtime. It provides a control plane for automating application deployment, scaling and management using container hosts and containers. Individual container hosts are brought together as a Kubernetes cluster allowing Kubernetes to orchestrate container actions such as re-deploy when a container fails and scale in/out.

PKS is the next level above Kubernetes. It is the management and control plane for multiple Kubernetes clusters allowing the deployment and lifecycle of Kubernetes environments to be controlled centrally. It uses Pivotals own container runtime and the VMware Harbor image registry as well as integrating with multiple cloud providers.

PKS is aimed squarely at those companies who wish to deploy, manage and lifecycle multiple Kubernetes environments using an enterprise grade solution.

How Does It Work?

Within PKS there are multiple components as shown below.

The Pivotal stack of components that make up PKS enable new Kubernetes clusters (and therefore container runtimes) to be deployed via API/CLI as well as the network infrastructure/constructs that they rely on in order to secure each environment. PKS leverages the same VMware Network Container Plugin for NSX-T that native Kubernetes does allowing new logical switches and routers to be spun up on demand.

The Pivotal VMs that sit on the management plane include Pivotal Operations Manager, Pivotal Bosh Director, Pivotal Container Service and optionally VMware Harbor Registry. Pivotal Operations Manager (or Ops Manager) is the VM that deploys all other management VMs so nothing can be achieved without this.

BOSH Director is the orchestrating component that controls VM deployment into the virtual infrastructure (in this case Kubernetes hosts), monitors existing deployments and repairs deployments as required using BOSH agents. It communicates to an infrastructure provider (in this case vSphere) and translates admin CLI tasks into endpoint API calls to achieve all of the above.

The PKS VM provides the PKS API that allows users to initiate requests to PKS in order to perform operations. This is done via a PKS CLI that can be installed on machines as required. Also embedded within this VM are multiple services that broker requests to BOSH Director and NSX-T as well as the UAA authentication service that allows users to authenticate with the PKS API.

Harbor Registry (optional) provides a secure location to store all required container images used, allowing you to push to and pull from the registry as required using the docker cli.

My Deployment Architecture

So lets look at what I am going to deploy in this series of articles. This diagram provides an overview.

The PKS control plane VMs have to sit on a network somewhere. They could be on an external network (VSS/VDS port group), a NSX-T logical switch (NAT’d) or a fully routable NSX-T logical switch (remember the boundaries of this article are VMware and NSX-T). I am fully embracing NSX-T for this deployment so all control plane and Kubernetes cluster VMs will sit on routable NSX-T logical switches.

For more information I highly recommend this 12min overview video (https://www.youtube.com/watch?time_continue=496&v=2g1KE5zdbRs).

Now that I’ve covered the basics my next article will cover getting the management stack up and running starting with ops manager and BOSH.