- 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
Deploy a Standalone Cluster to Azure ¶
Create Standalone Azure Clusters ¶
This section covers setting up a standalone cluster in Azure. A standalone cluster provides a workload cluster that is not managed by a centralized management cluster.
There are some prerequisites this process will assume. Refer to the
Prepare to Deploy a Cluster to Azure docs for instructions on accepting image licenses and preparing your Azure account.
Initialize the Tanzu Community Edition installer interface.
tanzu standalone-cluster create --ui
Choose Azure from the provider tiles.
Fill out the IaaS Provider section.
A: Your account’s Tenant ID.
B: Your Client ID.
C: Your Client secret.
D: Your Subscription ID.
E: The Azure Cloud in which to deploy. For example, “Public Cloud”, “US Government Cloud”, etc.
F: The region of Azure you’d like all networking, compute, etc to be created within.
G: The public key you’d like to use for your VM instances. This is how you’ll SSH into control plane and worker nodes.
H: Whether to use an existing
resource group or create a new one.
I: The existing resource group, or the name to provide the new resource group.
Fill out the VNET settings.
A: Whether to create a new
Virtual Network in Azure or use an existing one. If using an existing one, you must provide its VNET name. For initial deployments, it is recomended to create a new Virtual Network. This will ensure the installer takes care of all networking creation and configuration.
B: The Resource Group under which to create the VNET.
C: The name to use when creating a new VNET.
D: The CIDR block to use for this VNET.
E: The name for the control plane subnet.
F: The CIDR block to use for the control plane subnet.
G: Whether to deploy without a publicly accessible IP address. Access to the cluster will be limited to your Azure private network only. Various ways for connecting to your private cluster
Fill out the Standalone Cluster Settings.
A: Choose between Development profile with one control plane node, or Production, which features a highly-available three node control plane. Additionally, choose the instance type you’d like to use for control plane nodes.
B: Name the cluster. This is a friendly name that will be used to reference your cluster in the Tanzu CLI and
C: Whether to enable Cluster API’s machine health checks.
D: Choose whether you’d like to enable Kubernetes API server auditing.
If you would like additional metadata to be tagged in your soon-to-be-created Azure infrastructure, fill out the Metadata section.
Fill out the Kubernetes Network section.
A: Set the CIDR for Kubernetes Services (Cluster IPs). These are internal IPs that, by default, are only exposed and routable within Kubernetes.
B: Set the CIDR range for Kubernetes Pods. These are internal IPs that, by default, are only exposed and routable within Kubernetes.
C: Set a network proxy that internal traffic should egress through to access external network(s).
Fill out the Identity Management section.
A: Select whether you want to enable identity management. If this is off, certificates (via kubeconfig) are used to authenticate users. For most development scenarios, it is preferred to keep this off.
B: If identity management is on, choose whether to authenticate using
C: Fill out connection details for identity management.
Fill out the OS Image section.
A: The Azure image to use for Kubernetes host VMs. This list should populate based on known images uploaded by VMware. These images are publicly accessible for your use. Choose based on your preferred Linux distribution.
Skip the TMC Registration section.
Click the Review Configuration button.
For your record, the configuration settings have been saved to
Deploy the cluster.
If you experience issues deploying your cluster, visit the Troubleshooting documentation.
Set your kubectl context to the cluster.
kubectl config use-context <STANDALONE-CLUSTER-NAME>-admin@<STANDALONE-CLUSTER-NAME>
Validate you can access the cluster’s API server.
kubectl get nodes
The output will look similar to the following:
NAME STATUS ROLES AGE VERSION ip-10-0-1-133.us-west-2.compute.internal Ready <none> 123m v1.20.1+vmware.2 ip-10-0-1-76.us-west-2.compute.internal Ready control-plane,master 125m v1.20.1+vmware.2