> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Requirements, supported platforms, and machine types for deploying AutoMQ BYOC on managed Kubernetes.

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.

<Info>
  In this article, mentions of AutoMQ product service providers, AutoMQ service providers, and AutoMQ all specifically refer to AutoMQ HK Limited and its subsidiaries.
</Info>

## 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.

<Tip>
  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.
</Tip>

### 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.

<Tip>
  AutoMQ requires dedicated compute capacity. Provide a separate stable compute pool for Kubernetes system components.
</Tip>

* **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](#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:

| **Cloud Provider**<br /> | **Allowed Machine Types List**<br />                                                                          |
| ------------------------ | ------------------------------------------------------------------------------------------------------------- |
| AWS                      | `r6in.large`, `r6i.large`, `m7g.xlarge`, `m7g.2xlarge`, `c6g.2xlarge`, `m7g.4xlarge`, `m6g.medium`            |
| Google Cloud             | `n4d-standard-2`, `n4d-highmem-2`, `n4a-highmem-1`, `n4a-standard-2`, `n4d-standard-4`                        |
| Azure                    | `Standard_D4as_v5`, `Standard_D4s_v4`, `Standard_E2as_v5`                                                     |
| Alibaba Cloud            | `ecs.r7.large`, `ecs.r6.large`, `ecs.u1-c1m8.large`, `ecs.u1-c1m2.2xlarge`, `ecs.g8y.xlarge`, `ecs.r8y.large` |
| Huawei Cloud             | `c6ne.xlarge.4`, `m7.large.8`, `m7n.large.8`                                                                  |
| Tencent Cloud            | `SA5.2XLARGE16`, `SA5.4XLARGE32`, `SA5.LARGE16`, `S6.LARGE16`, `S6.2XLARGE16`, `SA4.2XLARGE16`                |

* **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.

<Tip>
  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.
</Tip>

## 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:

| Field         | Supported configuration                                                                              |
| ------------- | ---------------------------------------------------------------------------------------------------- |
| `affinity`    | `nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchExpressions[]` |
| `tolerations` | A list of standard Kubernetes toleration objects                                                     |

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:

```yaml theme={null}
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: node-type
              operator: In
              values:
                - automq
tolerations:
  - key: dedicated
    operator: Equal
    value: automq
    effect: NoSchedule
```

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:

```bash theme={null}
kubectl get nodes \
  -L node-type,node.kubernetes.io/instance-type,topology.kubernetes.io/zone
kubectl describe pod <pod-name> --namespace <automq-namespace>
```

For Karpenter, also inspect NodePool and NodeClaim status:

```bash theme={null}
kubectl get nodepools,nodeclaims
```