VMware 5V0-23.20 Practice Test - Questions Answers, Page 4

NCP provides the following functionalities:

Automatically creates an NSX-T Data Center logical topology for a Kubernetes cluster, and creates a separate logical network for each Kubernetes namespace.

Implements Kubernetes Ingress with NSX-T layer 7 load balancer

Connects Kubernetes pods to the logical network, and allocates IP and MAC addresses.

Supports network address translation (NAT) and allocates a separate SNAT IP for each Kubernetes namespace.Note:When configuring NAT, the total number of translated IPs cannot exceed 1000.

Implements Kubernetes network policies with NSX-T Data Center distributed firewall.

Implements Kubernetes service of type ClusterIP and service of type LoadBalancer.

The Cloud Native Storage for vSphere with Tanzu workflow is as follows:

1. A developer deploys a pod using the kubectl CLI.

2. The vSphere with Tanzu Cloud Native Storage-Container Storage Interface (CNS-CSI) reads this request from the control plane API server.

3. CNS-CSI informs the vCenter Server CNS of the need for a disk with storage class Gold.

4. CNS interfaces with SPBM for a suitable datastore that satisfies the Gold storage class (storage policy).

5. SPBM decides on a suitable datastore and interfaces with DRS for a suitable ESXi host.

6. Hostd on the ESXi host creates a First Class Disk (VMDK) on the datastore.

7. Spherelet on the ESXi host takes the created VMDK.

8. Spherelet mounts the VMDK to the vSphere Pod.

9. Spherelet reports the mount as a successful event to the control plane API server.

Fetch all Pods in all namespaces using kubectl get pods --all-namespaces

Pods

Shortcode = po

List one or more pods

kubectl get pod

Delete a pod

kubectl delete pod <pod_name>

Display the detailed state of a pods

kubectl describe pod <pod_name>

Create a pod

kubectl create pod <pod_name>

Execute a command against a container in a pod

kubectl exec <pod_name> -c <container_name> <command>

Get interactive shell on a a single-container pod

kubectl exec -it <pod_name> /bin/sh

Display Resource usage (CPU/Memory/Storage) for pods

kubectl top pod

Add or update the annotations of a pod

kubectl annotate pod <pod_name> <annotation>

Add or update the label of a pod

kubectl label pod <pod_name>

For a Supervisor Cluster that is configured with the vSphere networking stack, you can provide Layer 2 isolation for your Kubernetes workloads by creating Workload Networks and assigning them to namespaces. Workload Networks provide connectivity to Tanzu Kubernetes clusters in the namespace and are backed by distributed port groups on the switch that is connected to the hosts in the Supervisor Cluster.

The HAProxy virtual IP range where external services and DevOps users connect. In this configuration, HAProxy is deployed with two virtual NICs (Default configuration), one connected to the management network, and a second one connected to the Primary Workload Network. You must plan for allocating Virtual IPs on a separate subnet from the Primary Workload Network.

https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-1F885AAE-92FF-41E6-BF04-0F0FD4173BD9.html

This is the textbook answer, I know kubectl does give you some information.

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.

https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-1238AFD8-

232C-4EFC-BD54-796CB9F8C45F.html

Resource Name Description

configmaps The total number of ConfigMaps that can exist in the namespace.

persistentvolumeclaims The total number of PersistentVolumeClaims that can exist in the namespace.

pods The total number of Pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if .status.phase in (Failed, Succeeded) is true.

replicationcontrollers The total number of ReplicationControllers that can exist in the namespace.

resourcequotas The total number of ResourceQuotas that can exist in the namespace.

services The total number of Services that can exist in the namespace.

services.loadbalancers The total number of Services of type LoadBalancer that can exist in the namespace.

services.nodeports The total number of Services of type NodePort that can exist in the namespace.

secrets The total number of Secrets that can exist in the namespace.

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