Skip to main content
AutoMQ BYOC (Bring Your Own Cloud) environments support deployment to managed Kubernetes platforms provided by AWS, Google Cloud, Azure, Alibaba Cloud, Huawei Cloud, and Tencent Cloud. This article introduces the basic concepts and constraints of deploying AutoMQ to Kubernetes platforms.
In this article, mentions of AutoMQ product service providers, AutoMQ service providers, and AutoMQ all specifically refer to AutoMQ HK Limited and its subsidiaries.

​
Constraints and Limitations

When deploying AutoMQ on Kubernetes, users need to follow the constraints and limitations outlined below. Improper user operations may lead to deployment and modification failures of the cluster.

​
Constraint 1: Users Must Provide a Dedicated Kubernetes Cluster that Meets the Requirements

AutoMQ requires a dedicated Kubernetes cluster that should not be shared with other application systems for the following reasons:
  • Network isolation risk in Kubernetes: AutoMQ is designed for high-throughput data transmission scenarios and demands high network throughput. Network isolation between different Pods within a Kubernetes cluster is not complete. AutoMQ requires an independent Kubernetes cluster to avoid interference with other business systems of the user.
  • Operations authorization isolation: The Kubernetes cluster where AutoMQ resides needs to provide operations authorization (granting AutoMQ service provider access to the cluster). AutoMQ requires an independent Kubernetes cluster to prevent unauthorized access by application systems.
Multiple AutoMQ instances can be deployed in one Kubernetes cluster. Share a Kubernetes cluster only among workloads in the same business domain and cloud network.

​
Constraint 2: Users Must Provide Dedicated Compute Capacity that Meets the Requirements

AutoMQ requires dedicated compute capacity. You can provide it through a managed node pool or an autoscaler such as Karpenter. The compute pool must permit the instance types and Availability Zones selected when you create an AutoMQ instance.
AutoMQ requires dedicated compute capacity. Provide a separate stable compute pool for Kubernetes system components.
  • Add an exclusive label and taint: To prevent other workloads from occupying resources on AutoMQ nodes, you can add a custom label such as node-type=automq and the taint dedicated=automq:NoSchedule. Use the corresponding node affinity and toleration in the SchedulingSpec.
  • Compliant Machine Types: The compute pool must permit the machine types supported by AutoMQ for the selected cloud provider. As of August 2026, the supported machine types are listed below:
  • Workload Identity Authorization Requirements: AutoMQ clusters need to access services such as object storage and cloud volumes during operation. Grant the required cloud permissions to the cloud identity or role associated with the AutoMQ workload ServiceAccount, and ensure that the authorization is not modified or revoked.
  • Zone (Subnet) Requirements: AutoMQ supports both single-zone and three-zone instances. The managed node pool or Karpenter NodePool must permit the Availability Zones selected for the instance.
Example: A user needs to create three AutoMQ instances, namely Instance 1 (Zone A), Instance 2 (Zone B), and Instance 3 (Zones A, B, and C). The compute pool requirements must permit Zone A, Zone B, and Zones A+B+C respectively.

​
SchedulingSpec

The Scheduling YAML field is optional. Use it when AutoMQ pods need to target dedicated Kubernetes nodes or tolerate taints on those nodes.

​
Supported fields

The YAML supports these root fields: Node affinity has these restrictions:
  • Configure at most one nodeSelectorTerm.
  • Each term can contain only non-empty matchExpressions.
  • Each expression must use the In operator and include a key and at least one value.
The following fields aren’t supported in the Scheduling YAML: nodeSelector, topologySpreadConstraints, matchFields, pod affinity, and pod anti-affinity.

​
Configure dedicated nodes

The following example applies to both managed node pools and Karpenter NodePools. Configure the compute pool to add:
  • Custom label: node-type=automq
  • Taint: dedicated=automq:NoSchedule
Enter this Scheduling YAML when you create the AutoMQ instance:
For a Karpenter NodePool, add the label and taint under spec.template, and ensure that spec.template.spec.requirements permits the instance types and Availability Zones selected in AutoMQ Console. Instead of adding a custom label, you can match a node pool label provided by your cloud provider’s managed Kubernetes service or node pool implementation. Label keys vary across cloud providers and implementations. Replace the key and value in matchExpressions above with the actual node pool label on the target nodes.

​
System-managed scheduling conditions

Don’t add these keys to matchExpressions:
  • node.kubernetes.io/instance-type
  • topology.kubernetes.io/zone
AutoMQ derives these conditions from the Instance type and Availability Zone fields in the creation form. A request containing either key in the Scheduling YAML is rejected. The load balancer subnets are also selected separately in the creation form. Select subnets that cover the workload Availability Zones; don’t place subnet IDs in the Scheduling YAML.

​
Troubleshoot pending pods

If AutoMQ pods remain pending, check:
  • The target nodes contain the label used by node affinity.
  • Every NoSchedule taint on the target nodes has a matching toleration.
  • The managed node pool or Karpenter NodePool permits the selected instance type and Availability Zones.
  • The compute pool hasn’t reached its resource limits and the cloud provider has capacity.
Use these commands to inspect the scheduling state:
For Karpenter, also inspect NodePool and NodeClaim status: