- Plan Your Installation
- Install Tanzu Community Edition
- Microsoft Azure
- Headless Installation
- AWS Account Reference
- AWS Workload Cluster Template
- vSphere Account Reference
- vSphere Workload Cluster Template
- Azure Account Reference
- Azure Workload Cluster Template
- Docker-based Clusters on Windows
- Work with Packages
Local Path Storage
- Run Conformance Tests
- Scale Management Cluster
- Scale Workload Cluster
- Delete Management Cluster
- Delete Workload Cluster
- Uninstall the Tanzu CLI
- Upgrade kapp-controller version
- Connect to Cluster Nodes with SSH
- Create Persistent Volumes with Storage Classes
- Set Up vSphere CNS and Create a Storage Policy in vSphere
- Enable Volume Expansion for vSphere CSI
- Secure automated ingress on AWS
- Opinionated installation package
- Monitoring with Prometheus and Grafana on vSphere
- Monitoring with Prometheus and Grafana on Docker
- LDAP Integration on vSphere and NSX-ALB
- Create a Package Example
- Troubleshoot Clusters
- File a Bug or Feature
- Our Triage Process
- Getting Support
Reference for Azure account ¶
If you encounter issues deploying a cluster to Azure, review the following troubleshooting and reference content.
Network Security Groups on Azure ¶
If you do not specify a VNET when deploying a management cluster, the deployment process creates a new VNET along with the Network Security Groups (NSGs) required for the management cluster.
The following NSGs are required:
- One control plane NSG shared by the control plane nodes of all clusters, including the management cluster and the workload clusters that it manages.
- One worker NSG for each cluster, for the cluster’s worker nodes.
If you optionally create a VNET before deploying a management or workload clusters, Azure requires the following NSGs to be defined on their VNET.
- A subnet for the management cluster control plane node
- A Network Security Group on the control plane subnet with the following inbound security rules, to enable SSH and Kubernetes API server connections:
- Allow TCP over port 22 for any source and destination
- Allow TCP over port 6443 for any source and destination. Port 6443 is where the Kubernetes API is exposed on VMs in the clusters you create.
- A subnet and Network Security Group for the management cluster worker nodes.
For each workload cluster that you deploy later, you need to create a worker NSG named
<CLUSTER-NAME> is the name of the workload cluster.
This worker NSG must have the same VNET and region as its management cluster.
Microsoft Azure account ¶
Your Microsoft Azure account should have the following permissions and requirements:
- Permissions required to register an app. See Permissions required for registering an app in the Azure documentation.
- Sufficient public IP address quotas for your clusters, including the quota for Public IP Addresses - Standard, Public IP Addresses - Basic, and Static Public IP Addresses. A standard Azure account has a quota of 10 public IP addresses per region. Every Tanzu Community Edition cluster requires 2 Public IP addresses regardless of how many control plane nodes and worker nodes it has. For each Kubernetes Service object with type
LoadBalancer, 1 Public IP address is required.
- Run a DNS lookup on all
imageRepositoryvalues to find their CNAMEs.
- Sufficient VM core (vCPU) quotas for your clusters. A standard Azure account has a quota of 10 vCPU per region. Tanzu Community Edition clusters require 2 vCPU per node, which translates to:
devplan: 4 vCPU (1 main, 1 worker)
prodplan: 8 vCPU (3 main , 1 worker)
Each workload cluster:
devplan: 4 vCPU (1 main, 1 worker)
prodplan: 12 vCPU (3 main , 3 worker)
For example, assuming a single management cluster and all clusters with the same plan:
Plan Workload Clusters vCPU for Workload vCPU for Management Total vCPU Dev 1 4 4 8 5 20 24 Prod 1 12 8 20 5 60 68