VMware 5V0-23.20 - VMware vSphere with Tanzu Specialist

Create an example pod spec with the details about the private registry.

apiVersion: v1

kind: Pod

metadata:

name:

namespace:

spec:

containers:

- name: private-reg-container

image: //:

imagePullSecrets:

- name:

Replace  with the name of the pod workload.

Replace  with the Kubernetes namespace in the cluster where the pod will be created. This must be the same Kubernetes namespace where the Registry Service image pull secret is stored in the Tanzu Kubernetes cluster (such as the default namespace).

Replace  with the IP address for the embedded Harbor Registry instance running on the Supervisor Cluster.

Replace with the vSphere Namespace where the target Tanzu Kubernetes is provisioned.

Replace  with an image name of your choice.

Replace  with an appropriate version of the image, such as "latest".

Replace  with the name of the Registry Service image pull secret that you created previously.

Enabling Harbor Image Registry

The vSphere administrator uses the vSphere Client to enable Harbor. To enable this component, select a cluster, select Configure > Namespaces > Image Registry, and click ENABLE HARBOR:

• A VM Storage Policy is required to allocate storage for the Harbor pods.

• An IP Address, based on the ingress CIDR range, is allocated for the Harbor management interface.

• After a few minutes, Harbor is deployed and running. 184

NSX Container Plugin (NCP) runs as a pod on the control plane VMs. It listens for requests for network objects to the API server and interfaces with the NSX Manager to create, update, or delete those objects:

• A request to create a namespace results in a new NSX segment.

• A request to deploy a pod results in a segment port request and IP assignment.

• A request to create a service results in a new virtual server.

• A request to create a network policy results in a new distributed firewall rule.

kubectl get tanzukubernetesreleases

List available Tanzu Kubernetes releases.

kubectl get tkr

Short form version of the preceding command.

kubectl get tkr v1.17.8---vmware.1-tkg.1.5417466 -o yaml

Provides details on the named Tanzu Kubernetes release.

VMware Tanzu distributes Kubernetes software versions as Tanzu Kubernetes releases. To consume these releases, you configure a vSphere Content Library and synchronize the available releases. You can do so using a subscription-based model, or on-demand. If you want to provision Tanzu Kubernetes in an internet restricted environment, you can create a local library and manually import the releases.

Text Description automatically generated

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.

Authenticating Using kubectl

In vSphere with Tanzu, authentication is performed using vCenter Single Sign-On. You run the command kubectl vsphere login to authenticate a user through vCenter Single Sign-On to Kubernetes clusters.

kubectl vsphere login --server -u

The --insecure-skip-tls-verify flag is required if the certificate presented by the vSphere with Tanzu control plane is not trusted by the client machine. The control plane is signed by the vCenter Server VMware CA by default. You can replace the control plane certificate with a trusted certificate if needed. Alternatively, install the vCenter Server VMware CA root certificate into your client machine to remove the need for the --insecure-skip-tls-verify flag.