Tanzu Kubernetes Grid make it very simple to upgrade Kubernetes clusters , without impacting availability of control plane and also ensures rolling update for worker nodes.we just need to run two commands to upgrade Tanzu Kubernetes Grid: “tkg upgrade management-cluster” and tkg upgrade cluster CLI commands to upgrade clusters that we deployed with Tanzu Kubernetes Grid 1.0.0. In this blog post we will upgrade Tanzu Kubernetes Grid from version 1.0.0 to 1.1.0

Pre-Requisite

In this post we are going to upgrade TKG from version 1.0.0 to version 1.1.0 and to start upgrading we need to download the new versions of “TKG” client cli , Base OS Image Template and API server load balancer.

1. Download and Install new version of “TKG” cli on your client VM
   1. Download and upload For Linux – VMware Tanzu Kubernetes Grid CLI 1.1.0 Linux.
   2. Unzip using
      1. #gunzip tkg-linux-amd64-v1.1.0-vmware.1.gz
   3. unzip file named will be tkg-linux-amd64-v1.1.0-vmware.1
   4. move and rename to “tkg” using
      1. #mv ./tkg-linux-amd64-v1.1.0-vmware.1 /usr/local/bin/tkg
   5. Make it executable using
      1. #chmod +x /usr/local/bin/tkg
   6. Run #tkg version , this should show updated version of “tkg cli” client command line
   7. 
2. Download the new version
   1. Download OVA for Node VMs: photon-3-kube-v1.18.2-vmware.1.ova
   2. Download OVA for LB VMs: photon-3-haproxy-v1.2.4-vmware.1.ova
   3. Once download,Deploy these OVA using “Deploy OVF template” on vSphere
   4. When OVA deployment completed, right click the VM and select “Template” and click on “Convert to Template”
   5. 

Upgrade TKG Management Cluster

As you know management cluster is a purpose-built for operating the Tanzu platform and managing the lifecycle of Tanzu Kubernetes clusters. so we need to first upgrade Tanzu Management Cluster before we upgrade our Kubernetes clusters.This is the most seamless upgrade of Kubernetes cluster, i have ever done, so let’s get in to:

1. First list TKG management cluster which are running in my environment using, command will display the information of tkg management clusters
   1. #tkg get management Cluster
   2. 
2. Once got the name of management cluster , run below command to proceed with upgrade
   1. #tkg upgrade management-cluster <management-cluster-name>
   2. 
   3. Upgrade process first upgrades the Cluster API providers for vSphere, then it upgrades the K8s version in control plane and worker node of management cluster.
   4. 
3. if everything goes fine, it should take less than 30 minutes to complete the upgrade process of management plane.
   1. 
4. Now if you run #tkg get cluster –include-management-cluster , it should show upgraded version of management cluster.
   1. 

Upgrade Tanzu Kubernetes Cluster

Now since our management plane is upgraded. lets go ahead and upgrade Tanzu Kubernetes Clusters.

1. Here also process is same as we did for management cluster run below command to proceed with upgrade
   1. #tkg upgrade cluster <cluster-name>
   2. 
   3. if the cluster is not running in”default” namespace, specify “–namespace” option (when TKG is part of vSphere7 with Kubernetes)
   4. the upgrade process will upgrade Kubernetes version across your control and worker virtual machines.
   5. Once done , you must see successful upgrade of Kubernetes clusters.
   6. 
2. Now login with your credential and see the Kubernetes version your cluster is running.
   1. 

This completes the upgrade process, such an easy process of upgrading Kubernetes clusters without impacting availability of cluster.

This blog post helps you to create Tanzu Kubernetes Grid  Clusters running on either VMware Cloud on AWS and/or vSphere 6.7 Update 3 infrastructure.

NOTE – Tanzu Kubernetes Grid Plus is the only supported version on VMware Cloud on AWS. you can deploy Kubernetes clusters on your VMC clusters using Tanzu Kubernetes Grid Plus. Please refer to KB 78173 for detailed support matrix. 

Pre-requisite

On your vSphere/VMware Cloud on AWS instance ensure that you have the following objects in place:

•  A resource pool in which to deploy the Tanzu Kubernetes Grid Instance (TKG)
• A VM folder in which to collect the Tanzu Kubernetes Grid VMs (TKG)
• Create a network segment with DHCP enabled
• Firewall rules on compute segment.
• This is not must but i prefer a Linux based Virtual Machine called “cli-vm” which we will be using as a “Bootstrap Environment” to install Tanzu Kubernetes Grid CLI binaries for Linux

Installing Kubectl

Kubectl is a command line tool for controlling Kubernetes clusters that we will use for managing/controlling k8 cluster deployed by TKG . To install latest version of Kubectl follow below steps on “cli-vm”:

#curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
#chmod +x kubectl
#mv kubectl /usr/local/bin

Installing Docker

Docker is a daemon-based container engine which allows us to deploy applications inside containers, since my VM is Cent OS , i started the docker service , to start docker service , follow below steps on cli-vm:

#systemctl start docker
#systemctl enable docker

To view the status of the daemon, run the following command:

#systemctl status docker

Install Tanzu Kubernetes Grid CLI

To use Tanzu Kubernetes Grid, you download and run the Tanzu Kubernetes Grid CLI on local system, in our case we will install on our “cli-vm”

• Get the tkg cli binary from GA build page like:
  • For Linux platforms, download tkg-linux-amd64-v1.0.0_vmware.1.gz.
  • For Mac OS platforms, download tkg-darwin-amd64-v1.0.0_vmware.1.gz.
• Unzip the file:
  • gunzip ./tkg-linux-amd64-v1.0.0_vmware.1.gz
  • Copy the unzip binary to /usr/local/bin:
  • chmod +x . /tkg-linux-amd64-v1.0.0_vmware.1
  • mv ./tkg-linux-amd64-v1.0.0_vmware.1 /usr/local/bin/tkg
• Check tkg env is ready:
  • # tkg version
    Client:
    Version: v1.0.0
    Git commit: 60f6fd5f40101d6b78e95a33334498ecca86176e
• /root/.tkg folder will be auto created for tkg config file

Create an SSH Key Pair

In order for Tanzu Kubernetes Grid VMs to run tasks in vSphere, you must provide the public key part of an SSH key pair to Tanzu Kubernetes Grid when you deploy the management cluster. You can use a tool such as ssh-keygen to generate a key pair.

• On the machine on which you will run the Tanzu Kubernetes Grid CLI, run the following ssh-keygen command.
  • #ssh-keygen -t rsa -b 4096 -C “email@example.com“
• At the prompt
  • Enter file in which to save the key (/root/.ssh/id_rsa):
  •  press Enter to accept the default.
• Enter and repeat a password for the key pair.
• Open the file .ssh/id_rsa.pub in a text editor copy and paste it when you deploy the management cluster.

Import OVA & Create Template in VC

Before we can deploy a Tanzu Kubernetes Grid management cluster or Tanzu Kubernetes clusters to vSphere, we must provide a base OS image template to vSphere. Tanzu Kubernetes Grid creates the management cluster and Tanzu Kubernetes cluster node VMs from this template. Tanzu Kubernetes Grid provides a base OS image template in OVA format for you to import into vSphere. After importing the OVA, you must convert the VM into a vSphere VM template

• Export TKG needs 2 ova, which are photon-3-v1.17.3+vmware.2.ova and photon-3-capv-haproxy-v0.6.3+vmware.1.ova.
• Convert above both ova vms to templates and put them to vm folder.
• Here are high level steps:
  • In the vSphere Client, right-click on cluster & select Deploy OVF template.
  • Choose Local file, click the button to upload files, and navigate to the photon-3-v1.17.3_vmware.2.ova file on your local machine.
  • Follow the on screen instruction to deploy VM from the OVA template.
    • choose the appliance name
    • choose the destination datacenter or folder
    • choose the destination host, cluster, or resource pool
    • Accept EULA
    • Select the disk format and datastore
    • Select the network for the VM to connect to
    • Click Finish to deploy the VM

    • Right-click on the VM, select Template and click on Convert to Template

  • Follow the same step for proxy OVA – photon-3-capv-haproxy-v0.6.3+vmware.1.ova

Installing TKG Management Cluster

Once pre-work is done , follow below steps to create Tanzu Management cluster:

• On the machine on which you downloaded and installed the Tanzu Kubernetes Grid CLI, run the following command
  • #tkg init –ui
• if your cli vm running X11 desktop then it will open browser with loop back IP , if not you can setup using putty on your windows desktop , like this:
  • 
• Once you have successfully opened the connection, open you web browser and navigate to http://127.0.0.1:8081 and you should be seeing below page
  • 
• Enter your IAAS provider details where TKG can create K8s cluster and in this case we need to enter VMC vCenter Server information and then click “Connect” button, you will get notification etc accept all and then “connect button” becomes “connected” from here you just need to select the details about where do you want to deploy TKG, here fill the Datacenter and SSH Key which we created in previous steps.
  • 
• Select Development or Production Flavour and specify an instance type, then give the K8s Management Cluster a name and select API server Load Balancer (specify the HA Proxy VM Template, which we have uploaded in previous step)
  • 
• Select Resource Pool(TKG), VM Folder(TKG) and WorkloadDatastore
  • 
• Select Network Name and leave the other as default
  • 
• Select the K8s PhotonOS Template , this is the VM template that we uploaded in previous steps.
  • 
• Review all settings to ensure they match as per your selection and then click on “Deploy Management Cluster” , which will begin the deployment process….
  • 
• This takes around 5 to 6 minutes to complete the entire process of setting up TKG management cluster and once the Management Cluster has been deployed, you can go close the web browser and go back to your SSH session and stop the TKG UI rendering.
  • 
• you can verify that all pods are up & running by running the command:
  • #kubectl get pods -A
  • 

Deploy Tanzu Kubernetes workload Cluster

so let’s deploy Tanzu Kubernetes Cluster as  we have completed Tanzu Kubernetes grid Management cluster, we can use the “TKG” CLI to deploy Tanzu Kubernetes clusters from your management cluster to vSphere/VMware Cloud on AWS.Run the following command to deploy TKG Cluster called “avnish” or any other name you wish to use.

• #tkg create cluster avnish –plan=dev

above command will deploy a Tanzu Kubernetes cluster with the minimum default configuration.I am also deploying another cluster by specifying few more parameters

Deploy High Available Kubernetes Cluster

This command will deploy high available kubernetes cluster.

• #tkg create cluster my-cluster –plan dev –controlplane-machine-count 3 –worker-machine-count 5
  • 

• Once the TKG Cluster is up and running , we can run the following commands to get cluster information and credentials:

  • #tkg get clusters
  • #tkg get credential <clustername>
  • 
• To get the context of TKG clusters , run normal Kubernetes commands:
  • #kubectl config get-contexts
  • #kubectl config use-context avnish-admin@avnish
  • 
• To get the kubernetes node details , run kubernetes commands…
  • 

Scale TKG Clusters

After we create a Tanzu Kubernetes cluster, we can scale it up or down by increasing or reducing the number of node VMs that it contains.

• Scale up – Scale a cluster, use the
  • #tkg scale cluster
  • to change the number of control plane nodes  –controlplane-machine-count 
  • to change the number of worker nodes –worker-machine-count
  • 
  • 
  • 

Installing Octant on TKG Clusters

Octant is an open source developer-centric web interface for Kubernetes that lets you inspect a Kubernetes cluster and its applications, it is simple to install and easy to use.

• Here is  more information on Installation and configuration
• you need to install octant on your cli VM and then proxy it so that you can open its web interface.
  • 

This completes the installation and configuration of Tanzu Kubernetes grid, once you have management cluster ready, go ahead and deploy containerised applications on these clusters. TKG gives lots of flexibility of deploying , scaling and managing multiple TKG workload cluster and can be given based on department/projects.

In  continuation to  my PKS installation, we are now going to install and configure the PKS Control Plane which provides a frontend API that will be used by Cloud Operators and Platform Operators to very easily interact with PKS for provisioning and managing (create, delete, list, scale up/down) Kubernetes Clusters.

Once a Kubernetes cluster has been successfully provisioned through PKS by Cloud Operations , the operators will need to  provide  the external hostname of the K8S Cluster and the Kubectl configuration file to their developers and then developers can  start consuming this newly provisioned K8s clusters and deploying applications without knowing simplicity/complexity of PKS/NSX-T.

Previous Posts of this series for your reference is here:

• Getting Started with VMware PKS & NSX-T
• Deploy VMware PKS – Part1
• Deploy VMware PKS – Part2

Download PKS

First of all download PKS from Pivotal Network , file will have extension .pivotal.

Installation Procedure

To import the PKS Tile, go to the home page of Ops Manager and click “Import a Product” and select the PKS package to begin the import process in to ops manager , it takes some time since this is a 4+GB appliance.

Once the PKS Tile has been successfully imported, go ahead and click on the “plus” sign to add the PKS Tile which will make it available for us to start configuring. After that, Click the orange Pivotal Container Service tile to start the configuration process.

Assign AZ and Networks

• Here we will place the PKS API vm in the Management AZ and on the PKS Management Network that we have created on dvs in previous posts.
• Choose Network which PKS API VM will use to connect to Network , in our case it is management network.
• First time installation of PKS does not apply “Service Network” but we need to choose a network , for this installation i have created a NSX-T LS called “k8s” for Service network and i can use this in future, you can also create or specify “pks-mgmt” as this does not apply on new installation.
• 

Configure PKS API

• Generate a wild card certificate for PKS API by selecting Generate RSA Certificate and create a DNS record.
• Worker VM Max in Flight:  This makes sure how many instances of a component (non-canary worker) can start simultaneously when a cluster is created or resized. The variable defaults to 1 , which means that only one component starts at a time.
• 

Create Plans

Basically a plan defines a set of resource types used for deploying clusters. You can configure up to three plans in GUI. You must configure Plan 1.

• Create multiple plans based on your needs like you can have master either 1 or 3.
• you can choose to deploy number of worker VMs for each cluster and as per documentation worker nodes upto 200 has been tested but this number can go beyond 200 but sizing needs to be planned based on the other factors (like application and its requirement etc)
• Availability Zone – Select one or more AZs for the Kubernetes clusters deployed by PKS for Master and same setting you need to configure for worker nodes and if you choose multiple AZ , then equal number of worker node will get deployed across AZs
• Errand VM Type – select the size of the VM that contains the errand. The smallest instance may be sufficient, as the only errand running on this VM is the one that applies the Default Cluster App YAML configuration.
• To allow users to create pods with privileged containers, select the Enable Privileged Containers – Use with caution because privileged containers is a container running as privileged essentially disables the security mechanisms provided by Docker and allows code to run on the underlying system.
• Disable DenyEscalatingExec – This will disable Admission Control.
  • 

Create Plan 2 and Plan3 or just choose Inactive and create them later but remember PKS does not support changing the number of master/etcd nodes for plans with existing deployed clusters.

Configure Kubernetes Cloud Provider (IAAS Provider)

Here you will configure your IAAS where all these VMs will get deployed and in my case this is vSphere based cloud but now PKS supports forAWS, GCP and Azure.

• Enter vCenter Details like Name , Credentials , data store names etc..

Configure PKS Logging

• Logging is optional and can be configured with vRealize Log Insight , for my Lab i am leaving it default.
• To enable clusters to drain app logs to sinks using SYSLOG://, select the Enable Sink Resources checkbox.
• 

Configure Networking for Kubernetes Clusters

NSX Manager Super User Principal Identity Certificate – As per NSX-T documentation , a principal can be an NSX-T component or a third-party application such open stack or PKS. With a principal identity, a principal can use the identity name to create an object and ensure that only an entity with the same identity name can modify or delete the object (except Enterprise Admin). A principal identity can only be created or deleted using the NSX-T API. However, you can view principal identities through the NSX Manager UI.

We will have to create a user id and that user, id PKS API uses the NSX Manager superuser principal identity to communicate with NSX-T to create, delete, and modify networking resources for Kubernetes cluster nodes. Follow the steps here to create it.

• Choose NSX-T as  Networking Interface
• Specify NSX Manager hostname and generate the certificate as per above step.
• 
• Pods IP Block ID – Here enter the UUID of the IP block to be used for Kubernetes pods. PKS allocates IP addresses for the pods when they are created in Kubernetes. every time a namespace is created in Kubernetes, a subnet from this IP block is allocated.
• Nodes IP Block ID – Here enter the UUID of the IP block to be used for Kubernetes nodes. PKS allocates IP addresses for the nodes when they are created in Kubernetes. The node networks are created on a separate IP address space from the pod networks.
• 
• T0 Router ID – Here enter the  T0 router UUID.
• 
• Floating IP Pool ID – Here enter the ID that you created for load balancer VIPs. PKS uses these floating IP pool to allocate IP addresses to the load balancers created for each of the clusters. The load balancer routes the API requests to the master nodes and the data plane.
• 
• Node DNS – Specify Node DNS Server Name , ensure Nodes are reachable to DNS servers.
• vSphere Cluster Names – Here enter a comma-separated list of the vSphere clusters where you will deploy Kubernetes clusters. The NSX-T pre-check errand uses this field to verify that the hosts from the specified clusters are available in NSX-T
• HTTP/HTTPS Proxy – Optional
• 

Configure User Account and Authentication (UAA)

Before users can log in and use the PKS CLI, you must configure PKS API access with UAA. You use the UAA Command Line Interface (UAAC) to target the UAA server and request an access token for the UAA admin user. If your request is successful, the UAA server returns the access token. The UAA admin access token authorizes you to make requests to the PKS API using the PKS CLI and grant cluster access to new or existing users.

• Leaving setting default with some timer changes
• 

Monitoring

You can monitor kubernetes cluster and pods using VMware Wavefront , which i will be covering in a separate post.

• For now leave it default.

Usage Data

VMware’s Customer Experience Improvement Program (CEIP) and the Pivotal Telemetry Program (Telemetry)  program.

• choose based in your preference.

Errands

Errands are scripts that run at designated points during an installation.

• Since we are running PKS with NSX-T , we must need to verify our NSX-T configuration.
• 

Resource Config for PKS VM

Edit resources used by the Pivotal Container Service job and if there are timeouts while accessing PKS API VM , use high resource VM Type , for this LAB i am going with Default.

• Leave it default.
• 

Missing Stemcell

A stemcell is a versioned Operating System image wrapped with IaaS specific packaging.A typical stemcell contains a bare minimum OS skeleton with a few common utilities pre-installed, a BOSH Agent, and a few configuration files to securely configure the OS by default. For example: with vSphere, the official stemcell for Ubuntu Trusty is an approximately 500MB VMDK file.

Click on missing stemcell link which will take you to StemCell Library. Here you can see PKS requires stemcell 170.15 , since i have already downloaded thats the reason it is showing 170.25 in the deployed section but in new installation cases it will show none  deployed. Click IMPORT STEMCELL and choose a stemcell which can be downloaded from Here to import.

Apply Changes

Return to Ops Manager installation Dashboard and click on “Review Pending Changes” and finally “Apply Changes” , this will go ahead and deploy PKS API VM at your IAAS location which you have chosen while configuring PKS tile.

and if the configuration of the tile is correct , around after 30 minute , you will see a successful message that deployment has been completed , which gives very nice feeling that your hard work  and dedication resulting success (for me it failed couple of time because of storage/network and resource issues).

To identify which VM has been deployed , you can check custom attributes or go back to  the Installation Dashboard, click the PKS tile then go to the Status tab. Here we can see the IP address of our PKS API , also notice CID which is VM name in vCenter inventory. also you can see the health of the PKS VM.

This completes the PKS VM deployment procedure. in the next post we will deploy kubernetes Cluster.

In this part I will begin PKS installation by deploying Pivotal Ops Manager which basically provides a management interface (UI/API) for Platform Operators to manage the complete lifecycle of both BOSH and PKS starting from install then going to patch and upgrade.

To refer other posts of this series are here:

Getting Started with VMware PKS & NSX-T

Deploy VMware PKS – Part1

In addition, you can also deploy new application services using Ops Manager Tiles like adding an Enterprise-class Container Registry like VMware Harbor which can then be configured to work with PKS.

Installing OpsManager

• Download the Pivotal Cloud Foundry Ops Manager for vSphere  .OVA file from Pivotal Network. Use the dropdown menu to select the supported Ops Manager release and ensure that you have checked “Compatibility Matrix” and accordingly download supported version,

• Once Downloaded , Log into vCenter using the vSphere Web Client or HTML5 Client to deploy the Ops Manager OVA.
• Choose your Management cluster , appropriate network and other OVA deployment options , i am not going to cover OVA deployment procedure here. Only at customize template , enter below details:
  • Admin Password: A default password for the user “ubuntu”.
    • If you do not enter a password, Ops Manager will not boot up.
  • Custom hostname: The hostname for the Ops Manager VM, in My example opsmgr.corp.local.
  • DNS: One or more DNS servers for the Ops Manager VM.
  • Default Gateway: The default gateway for Ops Manager.
  • IP Address: The IP address of the Ops Manager network interface.
  • NTP Server: The IP address of one or more NTP servers for Ops Manager.
  • Netmask: The network mask for Ops Manager.
• Create a DNS entry for the IP address that you used for Ops Manager ,which we will use in next steps. use this DNS NAME/IP address and browse on a browser , which will take you to Authentication System for initial authentication setup and for our setup, i will use “Internal Authentication” for this Lab. Click on “Internal Authentication”
  • 
• Next, you will be prompted to create a new admin user which we will use to manage BOSH. Once you have successfully created the user, go ahead and login with the new user account
  • 
• Once you are logged into Ops Manager, you can see that the BOSH Tile is already there but is showing as un-configured (orange colour denotes un-configured) which means BOSH has not yet been deployed yet. Go ahead and click on the tile to begin the configuration to deploy BOSH.
  • 

Before starting Bosh Tile configuration , we need to prepare NSX Manager, listed below procedure for:

Generating and Registering the NSX Manager Certificate for PKS

The NSX Manager CA certificate is used to authenticate PKS with NSX Manager. You create an IP-based, self-signed certificate and register it with the NSX Manager.By default, the NSX Manager includes a self-signed API certificate with its hostname as the subject and issuer. PKS Ops Manager requires strict certificate validation and expects the subject and issuer of the self-signed certificate to be either the IP address or fully qualified domain name (FQDN) of the NSX Manager. That’s the reason, we need to regenerate the self-signed certificate using the FQDN of the NSX Manager in the subject and issuer field and then register the certificate with the NSX Manager using the NSX API.

• Create a file for the certificate request parameters named “nsx-cert.cnf” in a linux VM where openssl tool is installed.
• Write below content in to the file which we create in above step.
  • 
• Export the NSX_MANAGER_IP_ADDRESS and NSX_MANAGER_COMMONNAME environment variables using the IP address of your NSX Manager and the FQDN of the NSX Manager host.
  • 
• Using openssl tool generate the certificate by running below command:
  • 
• Verify the certificate by running command as below:
  • ~$ openssl x509 -in nsx.crt -text -noout and ensure SAN has DNS name and IP addresses.
  • 
• Import this Certificate in NSX Manager , go to System -> Trust -> Certificates and click on Import -> Import Certificate
  • 
• Ensure that Certificate looks like this in your NSX Manager.
  • 
• Next is to Register the certificate with NSX Manager using below procedure , first the ID of the certificate from gui.
  • 
• Run the below command (in to your API client ) to register the certificate using below command replace “CERTIFICATE-ID” with your certificate ID.
  • export CERTIFICATE_ID=”CERTIFICATE-ID” curl –insecure -u admin:’ADMIN-PASSWORD’ -X \
    POST “https://$NSX_MANAGER_IP_ADDRESS/api/v1/node/services/http?action=apply_certificate&certificate_id=$CERTIFICATE_ID&#8221;

Now let’s configure BOSH tile , which will deploy BOSH based on our input parameters.

Configure BOSH Tile to Deploy BOSH Director

Click on the tile. It will open the tile’s setting tab with the vCenter Config parameters page.

• vCenter Config 
  • Name: a unique meaning full name
  • vCenter Host: The hostname of the vCenter.
  • vCenter Username: Username for above VC with create and delete privileges for virtual machines (VMs) and folders.
  • vCenter Password: the password of above VC.
  • Datacenter Name: Exact name of data center object in vCenter
  • Virtual Disk Type: Select “Thin” or “Thick”
  • Ephemeral Datastore Names: The names of the data stores that store ephemeral VM disks deployed by Ops Manager , you can specify many data stores by using comma.
  • Persistent Datastore Names (comma delimited): The names of the datastores that store persistent VM disks deployed by Ops Manager.
  • To deploy BOSH as well as the PKS Control Plane VMs, Ops Manager will go ahead and upload a Stemcell VM ( A VM Template that PKS) and it will clone from that image for both PKS Management VMs as well as base K8S VMs.
  • 
• NSX-T Config 
  • Choose NSX Networking and Select NSX-T 
  • NSX Address: IP/DNS Name for NSX-T Manager.
  • NSX Username and NSX Password: NSX-T credential
  • NSX CA Cert: Open the NSX CA Cert that you generated in above section and copy/paste its content to this field.
• • 
•  Other Config
  • VM Folder: The vSphere datacenter folder where Ops Manager places VMs.
  • Template Folder: The vSphere folder where Ops Manager places stemcells(templates).
  • Disk path Folder: The vSphere datastore folder where Ops Manager creates attached disk images. You must not nest this folder.
  • And Click on “Save”.
  • 
• Director Config
  • For Director config , i have put in few details like:
    • NTP Server Details
    • Enable VM Resurrector Plugin
    • Enable Post Deploy Scripts
    • Recreate all VMs (optional)
  • 
• Availability Zone    
  • Availability zones are defined at a vSphere Cluster level. These AZs will then be used by BOSH director to determine where to deploy the PKS Management VMs as well as the Kubernetes VMs.Multiple Availability Zones allow you to provide high-availability across data centers. for this demonstration i have created two AZs, one for Management and one for my Compute.
• Create Network
  • Since i am using dvs for my PKS management component , we need to specify those details in to this segment and make sure you select the Management AZ which is the vSphere Cluster where BOSH and PKS Control Plane VM will be deployed.

• Assign AZs and Networks 
  • In this section,  Define the AZ and networking placement settings for the PKS Management VM.Singleton Availability Zone – The Ops Manager Director installs in this Availability Zone.

• Security & Syslog
  • This section i am leaving default , if required for your deployment , pls refer documentation.
• Resource Config
  • As per in part 1 sizing , the BOSH director vm by default allocates 2 vCPUs, 8GB memory, 64GB disk and also has a persistent disk of 50GB and Each of the four Compilation VMs uses 4 vCPUs, 4GB memory, 16GB disk each. For my lab deployment i have changed it to suite to my lab resources.Bosh director needs minimum of 8 GB Memory to run , so choose options accordingly.

• Review Pending Changes and Apply Changes 
  • With all the input completed, return to the Installation Dashboard view by clicking Installation Dashboard at the top of the window. The BOSH Director tile will now have a green bar indicating all the required parameters have been entered. Next we click REVIEW PENDING CHANGES and Apply Changes

• Monitor Installation and Finish
  • 
  • If all the inputs are right then you will see that your installation is successful

After you login to your vCenter , you will see a new powered on VM in your  inventory that starts with vm-UUID which is the BOSH VM. Ops Manager uses vSphere Custom Attributes to add additional metadata fields to identify the various VMs it can deploy, you can check what type of VM this is by simply looking at the deployment, instance_group or job property. In this case, we can see its been noted as p-bosh.

and this completes Ops Manager and BOSH deployment , next post we will install PKS tile.