Skip to main content

Astra Control Center requirements

Contributors netapp-dbagwell
PDFs

Get started by verifying the readiness of your operational environment, application clusters, applications, licenses, and web browser. Ensure that your environment meets these requirements to deploy and operate Astra Control Center.

Supported host cluster Kubernetes environments

Astra Control Center has been validated with the following Kubernetes host environments:

Note Ensure that the Kubernetes environment you choose to host Astra Control Center meets the basic resource requirements outlined in the environment's official documentation.
Kubernetes distribution on host cluster Supported versions

Azure Kubernetes Service on Azure Stack HCI

Azure Stack HCI 21H2 and 22H2 with AKS 1.24.x and 1.25.x

Google Anthos

1.15 through 1.16 (See Google Anthos ingress requirements)

Kubernetes (Upstream)

1.26 to 1.28

Rancher Kubernetes Engine (RKE)

RKE 1.3 with Rancher Manager 2.6
RKE 1.4 with Rancher Manager 2.7
RKE 2 (v1.24.x) with Rancher 2.6
RKE 2 (v1.26.x) with Rancher 2.7

Red Hat OpenShift Container Platform

4.11 through 4.14

VMware Tanzu Kubernetes Grid Integrated Edition

1.16.x (See Host cluster resource requirements)

Host cluster resource requirements

Astra Control Center requires the following resources in addition to the environment's resource requirements:

Note These requirements assume that Astra Control Center is the only application running in the operational environment. If the environment is running additional applications, adjust these minimum requirements accordingly.

  • CPU extensions: The CPUs in all nodes of the hosting environment must have AVX extensions enabled.

  • Worker nodes: At least 3 worker nodes total, with 4 CPU cores and 12GB RAM each

  • VMware Tanzu Kubernetes Grid cluster requirements: When hosting Astra Control Center on a VMware Tanzu Kubernetes Grid (TKG) or Tanzu Kubernetes Grid Integrated Edition (TKGi) cluster, keep in mind the following considerations.

    • The default VMware TKG and TKGi configuration file token expires ten hours after deployment. If you use Tanzu portfolio products, you must generate a Tanzu Kubernetes Cluster configuration file with a non-expiring token to prevent connection issues between Astra Control Center and managed application clusters. For instructions, visit the VMware NSX-T Data Center Product Documentation.

    • Use the kubectl get nsxlbmonitors -A command to see if you already have a service monitor configured to accept ingress traffic. If one exists, you should not install MetalLB, because the existing service monitor will override any new load balancer configuration.

    • Disable the TKG or TKGi default storage class enforcement on any application clusters intended to be managed by Astra Control. You can do this by editing the TanzuKubernetesCluster resource on the namespace cluster.

    • Be aware of specific requirements for Astra Trident when you deploy Astra Control Center in a TKG or TKGi environment. For more information, see the Astra Trident documentation.

Service mesh requirements

A supported vanilla version of the Istio service mesh is strongly recommended to be installed on the Astra Control Center host cluster. Refer to supported releases for supported versions of Istio. Branded releases of Istio service mesh, such as OpenShift Service Mesh, are not validated with Astra Control Center.

To integrate Astra Control Center with the Istio service mesh installed on the host cluster, you must do the integration as part of the Astra Control Center installation process and not independent of this process.

Note Installing Astra Control Service without configuring a service mesh on the host cluster has potentially serious security implications.

Astra Trident requirements

Ensure that you meet the following Astra Trident requirements specific to the needs of your environment:

  • Minimum version for use with Astra Control Center: Astra Trident 23.01 or newer installed and configured

  • ONTAP configuration with Astra Trident:

    • Storage class: Configure at least one Astra Trident storage class on the cluster. If a default storage class is configured, ensure that it is the only storage class with the default designation.

    • Storage drivers and worker nodes: Ensure that you configure the worker nodes in your cluster with the appropriate storage drivers so that the pods can interact with the backend storage. Astra Control Center supports the following ONTAP drivers provided by Astra Trident:

      • ontap-nas

      • ontap-san

      • ontap-san-economy (app replication is not available with this storage class type)

      • ontap-nas-economy (snapshots and replication policies are not available with this storage class type)

Astra Control Provisioner

To use Astra Control Provisioner advanced storage functionality, you must install Astra Trident 23.10 or later and enable Astra Control Provisioner functionality.

Storage backends

Ensure that you have a supported backend with sufficient capacity.

  • Required storage backend capacity: At least 500GB available

  • Supported backends: Astra Control Center supports the following storage backends:

    • NetApp ONTAP 9.9.1 or newer AFF, FAS, and ASA systems

    • NetApp ONTAP Select 9.9.1 or newer

    • NetApp Cloud Volumes ONTAP 9.9.1 or newer

    • Longhorn 1.5.0 or newer

      • Requires the manual creation of a VolumeSnapshotClass object. Refer to the Longhorn documentation for instructions.

    • NetApp MetroCluster

      • Managed Kubernetes clusters must be in a stretch configuration.

    • Storage backends available with supported cloud providers

ONTAP licenses

To use Astra Control Center, verify that you have the following ONTAP licenses, depending on what you need to accomplish:

  • FlexClone

  • SnapMirror: Optional. Needed only for replication to remote systems using SnapMirror technology. Refer to SnapMirror license information.

  • S3 license: Optional. Needed only for ONTAP S3 buckets

To check whether your ONTAP system has the required licenses, refer to Manage ONTAP licenses.

NetApp MetroCluster

When you use NetApp MetroCluster as a storage backend, you need to do the following:

  • Specify an SVM management LIF as a backend option in the Astra Trident driver that you use

  • Ensure that you have the appropriate ONTAP license

To configure the MetroCluster LIF, refer to Astra Trident documentation for more information about each driver:

Image registry

You must have an existing private Docker image registry to which you can push Astra Control Center build images. You need to provide the URL of the image registry where you will upload the images.

Astra Control Center license

Astra Control Center requires an Astra Control Center license. When you install Astra Control Center, an embedded 90-day evaluation license for 4,800 CPU units is already activated. If you need more capacity or different evaluation terms, or want to upgrade to a full license, you can obtain a different evaluation license or full license from NetApp. You need a license to protect your applications and data.

You can try Astra Control Center by signing up for a free trial. You can sign up by registering here.

To set up the license, refer to use a 90-day evaluation license.

To learn more about how licenses work, refer to Licensing.

Networking requirements

Configure your operational environment to ensure Astra Control Center can communicate properly. The following networking configurations are required:

  • FQDN address: You must have an FQDN address for Astra Control Center.

  • Access to the internet: You should determine whether you have outside access to the internet. If you do not, some functionality might be limited, such as receiving monitoring and metrics data from NetApp Cloud Insights, or sending support bundles to the NetApp Support Site.

  • Port access: The operational environment that hosts Astra Control Center communicates using the following TCP ports. You should ensure that these ports are allowed through any firewalls, and configure firewalls to allow any HTTPS egress traffic originating from the Astra network. Some ports require connectivity both ways between the environment hosting Astra Control Center and each managed cluster (noted where applicable).

Note You can deploy Astra Control Center in a dual-stack Kubernetes cluster, and Astra Control Center can manage applications and storage backends that have been configured for dual-stack operation. For more information about dual-stack cluster requirements, see the Kubernetes documentation.
Source Destination Port Protocol Purpose

Client PC

Astra Control Center

443

HTTPS

UI / API access - Ensure this port is open in both directions between Astra Control Center and the system used to access Astra Control Center

Metrics consumer

Astra Control Center worker node

9090

HTTPS

Metrics data communication - ensure each managed cluster can access this port on the cluster hosting Astra Control Center (two-way communication required)

Astra Control Center

Hosted Cloud Insights service (https://www.netapp.com/cloud-services/cloud-insights/)

443

HTTPS

Cloud Insights communication

Astra Control Center

Amazon S3 storage bucket provider

443

HTTPS

Amazon S3 storage communication

Astra Control Center

NetApp AutoSupport (https://support.netapp.com)

443

HTTPS

NetApp AutoSupport communication

Astra Control Center

Managed Kubernetes cluster

443/6443
NOTE: The port that the managed cluster uses might vary depending on the cluster. Refer to the documentation from your cluster software vendor.

HTTPS

Communication with managed cluster - ensure this port is open both ways between the cluster hosting Astra Control Center and each managed cluster

Ingress for on-premises Kubernetes clusters

You can choose the type of network ingress Astra Control Center uses. By default, Astra Control Center deploys the Astra Control Center gateway (service/traefik) as a cluster-wide resource. Astra Control Center also supports using a service load balancer, if they are permitted in your environment. If you would rather use a service load balancer and you don't already have one configured, you can use the MetalLB load balancer to automatically assign an external IP address to the service. In the internal DNS server configuration, you should point the chosen DNS name for Astra Control Center to the load-balanced IP address.

Note The load balancer should use an IP address located in the same subnet as the Astra Control Center worker node IP addresses.

For more information, refer to Set up ingress for load balancing.

Google Anthos ingress requirements

When hosting Astra Control Center on a Google Anthos cluster, note that Google Anthos includes the MetalLB load balancer and the Istio ingress service by default, enabling you to simply use the generic ingress capabilities of Astra Control Center during installation. Refer to Configure Astra Control Center for details.

Supported web browsers

Astra Control Center supports recent versions of Firefox, Safari, and Chrome with a minimum resolution of 1280 x 720.

Additional requirements for application clusters

Keep in mind these requirements if you plan to use these Astra Control Center features:

What's next

View the quick start overview.