This PoC test plan and evaluation process focuses on demonstrating functional operation, capabilities, and features of the Tanzu Advanced product suite.
IMPORTANT - This pre-sales offering does not consider all best practices and recommendations for production or extended pilot use. VMware strongly encourages Customers to thoroughly review all publicly available product documentation and engage with the Professional Services Organization and Partners before going forward with any production design decisions. The PoC evaluation system is not the appropriate platform for intensive and lengthy performance testing and evaluation.
This guide is for cloud architects, engineers, administrators, and developers whose organization has an interest integrating Tanzu Advanced components and platform into their multi-cloud strategy and environments.
NOTE: BEFORE PROCEEDING TO THE TEST CASES, READ THIS SECTION IN ITS ENTIRETY AS IT INCLUDES PREPARATIONS AND PREREQUISITES REQUIRED TO SUCCESSFULLY RUN THE TEST CASES.
The test approach bases the test scenarios and executing the test procedures from the perspective of standard operations and developments roles. System user accounts or groups of users map to symbolizing roles defined within the vSphere 7 with Tanzu platform and Kubernetes clusters. Following user authentication, a user’s role association determines his/her level of authorization and entitlements while interacting with the interfaces and system resources.
vSphere 7 with Tanzu integrates with vCenter Single Sign-On (SSO), which is an authentication broker and security token exchange infrastructure, for authenticating system users and authorizing access to system resources. vCenter SSO supports multiple identity sources including local domain, Active Directory, and LDAP. Securing access control for vSphere 7 with Kubernetes requires applying privilege policies at multiple layers in the stack. Executing this test plan requires establishing user accounts and groups in the vCenter SSO local domain and/or linked identity source(s). The following image provides a conceptual representation of how the test plan organizes users and groups membership.
Additional information on configuring Identify Sources for vCenter Server with vCenter Single Sign-On is available on VMware Docs.
As a vSphere administrator, the primary interface for interacting with the vSphere with Kubernetes platform is the vSphere Client. At a high level, vSphere Administrators’ responsibilities involve configuring a Supervisor Cluster and namespaces, where DevOps engineers can deploy Kubernetes workloads. vSphere Administrators should have excellent knowledge about the vSphere and NSX-T technologies, and basic understanding about Kubernetes.
Test cases involving the vSphere administrator role require at least one (1) user account that is either a member of the vCenter SSO, Administrators group or mapped to a vCenter role with the following privileges and permissions for the participating vSphere cluster(s).
- Namespaces.Modify cluster-wide configuration or Namespaces.Modify namespace configuration
- Profile-driven storage. Profile-driven storage view and update
- vSphere Tagging.Create vSphere Tag on the root vCenter Server instance
- vSphere Tagging.Create vSphere Tag Category on the root vCenter Server instance
- vSphere Tagging.Assign and Unassign vSphere Tag on the root vCenter Server instance
- Content Library.Create subscribed library or Content Library.Create local library
- Datastore.Allocate space on the destination datastore
For additional details, reference Authentication for vSphere with Kubernetes
A DevOps engineer might be a Kubernetes developer and an application owner, a Kubernetes administrator, or combine functions of both. A DevOps engineer uses kubectl commands to deploy vSphere Pods and Tanzu Kubernetes clusters within existing namespaces on the Supervisor Cluster. Typically, a DevOps engineer does not need to be an expert on vSphere and NSX-T but has basic understanding about these technologies and the vSphere 7 with Kubernetes platform to interact with the vSphere administrators more efficiently.
Test cases involving the DevOps engineer role require at least one (1) user account. The recommendation is to create a group such as one named DevOps in the identity source and add individual user accounts as members to the group. After enabling a vSphere cluster as a Supervisor cluster and creating a namespace, the vSphere administrator will have the ability to entitle the DevOps engineer with namespace-level permissions. There are two types of permissions, edit and view. This test plan requires the DevOps engineer to maintain edit permissions across namespaces. With the namespace edit permission entitlement, the DevOps engineer will automatically receive cluster-admin privileges for all TKG cluster deployed within the namespace, respectively.
Application developers translate business and product objectives into application code. They administer the application development life cycle through CI/CD pipeline automation and an assortment of product integrations. They connect to a Tanzu Kubernetes cluster and use kubectl commands or other tools such as Helm or Jenkins to deploy workloads, including pods, services, load balancers, and other resources.
Test cases involving the application developer role require at least two (2) user accounts. The recommendation is to create two (2) groups such as DevTeamA and DevTeamB in the identity source and add individual user accounts as members to the groups. After the DevOps engineer deploys a TKG cluster, the DevOps engineer will have the ability to entitle the application developer with permissions to the TKG cluster through standard Kubernetes RBAC policies.
NOTE: BEFORE PROCEEDING TO THE TEST CASES, READ THIS SECTION IN ITS ENTIRETY AS IT INCLUDES PREPARATIONS AND PREREQUISITES REQUIRED TO SUCCESSFULLY RUN THE TEST CASES.
The test cases within this document assume that the installation of vSphere 7 with Tanzu, NSX-T, Cloud Services like Tanzu Mission Control (TMC), Tanzu Service Mesh (TSM), Tanzu Observability (TO), and Tanzu Applicaiton Catalog (TAC) are complete and deployed to an infrastructure prepared according to the requirements detailed in the "VMware vSphere 7 with Tanzu PoC Prerequisites and Preparations Guide." Additionally, it assumes that the Customer engaged with a VMware Systems Engineer for the vSphere 7 with Tanzu PoC design and installation. The following subsections identify the environment expectations, software and tools required for effectively conducting the test and evaluation process.
For the deployed vSphere 7 with Tanzu PoC environment, populate the following table with the system components’ version and build number.
| Software Product | Version | Build |
|---|---|---|
| VMware Cloud Foundation | 4.2.1 | x |
| VMware vSphere ESXi | 7.0.1d | x |
| VMware vCenter | 7.0.1d | x |
| VMware NSX-T | 3.1.0 | x |
| vRealize Operations Manager | x | x |
| vRealize LogInsight | x | x |
This project contains a Dockerfile that comes with preconfigured CLIs like kubectl, tanzu, kubectl-vshpere, ... to provide a pre-built and configured environment that makes executing the provided test cases easier (Called here as Local Management Container).To be able to connect with a Kubernetes Cluster copy/download that Kubernetes Cluster's kubeconfig to a file located in config/kube.conf inside this project structure (This file should not be checked into a public source repository). When running the Local Management Container from the supplied make file the kubeconfig will be automatically mapped/copied to the running continer and allow for kubectl commands to your Kubernetes Cluster.
make buildmake rebuildmake runmake joinmake startmake stop| Test Case ID | Test Case Description |
|---|---|
| SC01-TC01 | Enable a vSphere Cluster for Kubernetes Workloads |
| SC01-TC02 | Create and Configure a Supervisor Cluster Namespace(s) with RBAC |
| SC01-TC03 | Create and Configure a Supervisor Cluster Namespace(s) with Resource Limitations |
| SC01-TC04 | Supervisor Cluster Control Plane Access and Logging |
| Test Case ID | Test Case Description |
|---|---|
| SC02-TC01 | Provision a Tanzu Kubernetes Cluster Using the Tanzu Kubernetes Grid Service |
| SC02-TC02 | Apply RBAC to a Tanzu Kubernetes Grid Cluster and Granting Developer Access |
| SC02-TC03 | Use Pod Security Policies with a Tanzu Kubernetes Cluster(s) |
| SC02-TC04 | Using vSphere with Tanzu as a Management Cluster with Tanzu Mission Control (TMC) |
| SC02-TC05 | Attaching and Detaching Tanzu Kubernetes Clusters with Tanzu Mission Control (TMC) |
| SC02-TC06 | Configure Guest Workload Cluster for Logging with Tanzu Extension of Fluentbit |
| SC02-TC07 | Creating Consistent and Secure Build Images for Applications |
| SC02-TC08 | Service Mesh Lifecycle Management |
| SC02-TC09 | CaaS control plane shall provide support for canary releases - app with 2 versions |
| SC02-TC10 | Application Network Traffic Routing (Layer 7) |
| SC02-TC11 | Delegated DNS for Applications hosted on Tanzu Kubernetes Clusters |
| SC02-TC12 | Traffic Management inside Kubernetes Networking |
| SC02-TC13 | Tanzu Kubernetes Cluster Ingress with NSX-ALB |