Your web browser doesn't support some required capabilities.
This interactive demo works best with the latest version of Chrome, Firefox, or Safari.
An error occurred. Please reload the page or download again from the VMware Demo Library:
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Visit the VMware Demo Library
to get more demos!
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Unable to initialize the simulation player:
This demo file may be incomplete or damaged. Please reload the page or download again from the VMware Demo Library:
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Drive it with your mouse, your finger, or just use the arrow keys.
Use Learn mode to learn the demo. The orange boxes show where to click.
Use Present mode to hide the orange boxes and notes.
Click a Shortcut to jump to a specific part of the demo.
VMware
Cloud Foundation
Creating
a vSphere with Kubernetes Domain
Welcome
to this demonstration on creating a Virtual Infrastructure (VI) domain in
preparation for enabling vSphere with Kubernetes on VMware Cloud Foundation.
The first
step to deploying vSphere with Kubernetes is to stand up the underlying virtual
infrastructure. This
consists of the following high-level tasks:
With
Cloud Foundation, these steps are fully automated as part of the create domain
workflow. This
demonstration shows how these tasks are easily accomplished by the cloud
administrator quickly and efficiently.
We begin
at the SDDC Manager. From
the dashboard we see a summary of the components that make up our private cloud.
Navigating
to the hosts view, we see there are unassigned hosts in the cloud foundation
inventory. We will
use three of these hosts to create a new domain that will be used to host
vSphere with Kubernetes.
We begin
by choosing the type of storage.
vSAN is
the ideal storage platform for running vSphere with Kubernetes. It simplifies storage
allocation and speeds up infrastructure provisioning by eliminating
dependencies on external storage. vSAN also allows the storage capacity
in the domain to be easily scaled, along with CPU and memory as new servers are
added and removed.
Next, we
assign a name to the domain. We
will name the domain “wld01” and assigned it to our development team.
We also
provide a name for the vSphere cluster, in this example “wld01-clus01”.
Each
domain is managed by its own vCenter Server instance. In
Cloud Foundation, the vCenter Server instances for all domains run in
Enhanced-Linked Mode (ELM) and share a common Single-Sign On (SSO) domain. Here we provide the
network details and set the root user password for the new vCenter Server
Instance that will be deployed for this domain.
In Cloud
Foundation, Software-Defined Networking (SDN) is provided by VMware NSX. When creating a new
domain Cloud Administrators can choose to join the domain to an existing NSX-T
fabric, or to deploy a new NSX-T fabric. In
this example, this is the first VI Domain to be created as such we only see the
option to create a new NSX-T Fabric.
Here we
specify the VLAN ID, provide the IP addresses and fully qualified hostnames,
and set the admin password for the NSX-T Manager appliances that will
make up the NSX-T fabric.
When
using vSAN we are able to set the default vSAN Storage Policy for the cluster. Here we will accept the default
Failures to Tolerate value of 1. Due
to constraints in the demo environment we will not enable vSAN deduplication.
At the
host selection, we select the hosts to be assigned to the new domain. A minimum of 3 hosts are
required. This is acceptable for test and proof-of-concept deployments. For production
workloads, four hosts are recommended to ensure there is adequate redundancy to
support host maintenance and protect against unplanned hardware failures. In this example, we will
start with three hosts (esxi-6, esxi-7, esxi-8). We
will add a fourth host to the domain once our initial Kubernetes testing is
complete and just prior to putting the domain into production.
Three
license keys are required when creating a new domain, one for vSphere, vSAN and NSX-T. License keys must first
be added to the SDDC Manager after which they are available to be assigned in
the create domain workflow.
Notice
that the SDDC Manager calculates object names based on the input values
provided. Here we
see a summary of the names. You can review these names, and if desired go
back and modify the input parameters so the values more closely align with the
desired naming convention.
At the
review screen we are able to review the values for the new domain.
The SDDC
Manager invokes a workflow to automate the deployment of the new domain. The tasks being
automated include:
Typically,
it will take approximately 90 minutes to create the new domain.
Note that the time will vary based on the speed of the hosts and the size of
the cluster.
Here we
see the workflow has completed successfully.
We can
expand the workflow to view details about the underlying tasks. Here we see more than 100 separate
tasks were automated to orchestrate the creation of the new VI domain.
Returning
to the SDDC Manager dashboard, we now see the new domain listed under the
Workload Domains summary.
At the
domain details page we are able to view information about the new domain.
We see
the three hosts that were assigned to the domain.
We see
the three hosts have been configured into a single vSphere cluster
Under the
services tab we have links we can use to quickly connect to the vCenter web
client and NSX-T Manager UI.
At the
vSphere web client we see the vCenter Server inventory for both the Management
Domain and our new VI Domain.
We see
the vSphere cluster with the three hosts. Notice
that there are currently no workloads running inside the domain.
Note that
the vCenter Server Instance and NSX-T Manager appliances for this domain run
inside the Management Domain.
The local
storage on all three hosts has been claimed by vSAN and a single vSAN datastore
created for the cluster.
A Virtual
Distributed Switch was defined and the host’s management, vSAN, and vMotion
networks migrated to the distributed port groups.
From the
NSX Manager user interface we see the three NSX Manager appliances that make up
the NSX-T Fabric that was created for the new domain.
Navigating
to the Host Transport Nodes we are able to confirm that all three hosts have
been configured for NSX-T.
This
concludes this demonstration on creating a new VI Domain in preparation for
deploying vSphere with Kubernetes.
In this
demonstration we saw how the SDDC Manager makes it easy for Cloud
Administrators to stand-up new infrastructure by automating over 100 tasks in
order to create a new workload domain.
The automation included:
· Deploying
a new vCenter Server instance
· Creating
a vSphere cluster with at least three ESXi hosts
· Allocating
shared storage for the vSphere cluster
· Configuring
a Virtual Distributed Switch
· Deploying
NSX-T 3.0 and prepare the hosts in the cluster for use with NSX
Follow
along by completing the next demonstration on deploying an NSX Edge Cluster in
preparation for enabling vSphere with Kubernetes.
For more
information on VMware Cloud Foundation, visit our website at vmware.com/go/cloudfoundation.