VMware 5V0-23.20 VMware vSphere with Tanzu Specialist Exam Practice Test

vSphere Pods are only supported on Supervisor Clusters that use NSX-T Data Center as their networking stack.

Resource Management. vSphere DRS handles the placement of vSphere Pods on the Supervisor Cluster.

If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster. NetworkPolicies are an application-centric construct which allow you to specify how a pod is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections.

A Supervisor Cluster namespace is a combination of resource allocations and permissions set within the Supervisor Cluster. When you create a Supervisor Namespace, you’ll assign who has access to use it, and how many of the ESXi cluster’s resources you can use (much like a resource pool).

When you enabled the Workload Management components, you created a special Kubernetes cluster called the “Supervisor Cluster”. You can continue to deploy virtual machines in this cluster, and you can also deploy kubernetes pods as a “pod vm” which is basically a container with some special wrapping so they are better isolated, like a virtual machine is.

External HTTP(S) Load Balancing is a proxy-based Layer 7 load balancer that enables you to run and scale your services behind a single external IP address.

When vSphere with Tanzu converts storage policies that you assign to namespaces into Kubernetes storage classes, it changes all upper case letters into lower case and replaces spaces with dashes (-). To avoid confusion, use lower case and no spaces in the VM storage policy names.

Storage Policy Based Management is a vCenter Server service that supports provisioning of persistent volumes and their backing virtual disks according to storage requirements described in a storage policy.

The Workload Network, such as TKGS-VLAN1000, is where the Tanzu Kubernetes clusters run.

A workload network is a network construct that is used by supervisor control plane VMs and vSphere namespaces:

• The workload network is supported by a vSphere Distributed Switch port group.

• An IP range is defined to allocate an IP address for VMs attached to the workload network.

• A primary workload network must be selected.

• The supervisor control plane VMs attach to the primary workload networks port group.

A workload network can be used by multiple namespaces. A namespace can be assigned only one workload network.

The Network Service has been extended to support the vSphere Distributed Switch (vDS). Start by configuring the switch with appropriate portgroups. Management will carry traffic between vCenter and the Kubernetes Control Plane (Supervisor Cluster control plane). As we will see in a moment, not having the built in Load Balancing capability of NSX means you will need to deploy your own load balancer externally from the cluster. We will give you a choice of integrated load balancers. The first one we support is HAProxy.

The Management network will also carry traffic between the supervisor cluster nodes and HAProxy. The Frontend network will carry traffic to the Load Balancer virtual interfaces. It must be routable from any device that will be a client for your cluster. Developers will use this to issue kubectl commands to the Supervisor cluster or their TKG clusters. You can have one or more Workload networks.

The primary Workload network will connect the cluster interfaces of the Supervisor cluster. Namespaces can be defined with their own Workload network allowing for isolation between development teams assigned different Namespaces. The Namespace assigned Workload Networks will connect the TKG cluster nodes in that Namespace.