> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # Clusters > Group nodes into high-availability clusters for automatic application failover and data replication when hardware failures occur. A cluster is a group of nodes that work together to provide high availability (HA) and data replication for your edge workloads. When you deploy an application to a cluster, Edge Infrastructure Services selects a primary node to run the application and replicates its data across the other nodes. If the primary node fails, another node in the cluster takes over automatically, minimizing downtime without requiring manual intervention. Clusters require the EVE-k (EVE-OS Kubevirt) image. They are not available on EVE-OS KVM images. In the Edge Intelligence Platform Console, open **Infrastructure > Fleet > Clusters** to create and manage clusters. ## One Cluster Object Every cluster runs Kubernetes (k3s) on your edge nodes. Edge Infrastructure Services uses it to place application instances, replicate storage, and fail workloads over between nodes. What differs between clusters is whether the cluster's native Kubernetes surface is exposed to you: * A cluster without Kubernetes access runs application instances only. The **Mode** column in the Clusters list shows it as **Edge Node Cluster**. * A cluster with Kubernetes access also lets you deploy GitOps and Helm workloads and use `kubectl`, on the same nodes and at the same time as application instances. The **Mode** column shows it as **K8s Cluster**. * An imported cluster is an external Kubernetes cluster that you adopt for GitOps and Helm delivery only. It has no ZEDEDA edge nodes and never runs application instances. The **Mode** column shows it as **Imported K8s Cluster**. You turn on Kubernetes access with the **Enable Kubernetes Access** setting, either when you create a cluster or later on the cluster detail page. Enabling it is permanent: there is no action in the console or the API that turns it off. The ZEDEDA Edge Kubernetes Service features (GitOps repositories, Helm charts, the Kubernetes dashboard, and the cluster shell) are available on any cluster that has Kubernetes access. ### Created and imported clusters compared | Capability | Cluster you create | Imported cluster | | - | - | - | | Runs application instances | Yes. | No. | | Add or replace nodes | Yes. | No. | | Upgrade EVE-OS on the cluster | Yes, through ZCLI. | No. | | Enable Kubernetes access | Yes, at creation or later. One-way. | Not applicable. Kubernetes access is always on. | | GitOps, Helm, dashboard, cluster shell | Yes, after Kubernetes access is enabled. | Yes. | | Load balancer | Yes, after Kubernetes access is enabled. | No. | | Delete | Yes. | Yes, from the same list. | A load balancer is an opt-in setting for a cluster with Kubernetes access, configured through the ZEDEDA API only. The API accepts one configuration with a network interface and an IP address range (CIDR) for the load balancer to hand out. On a cluster without Kubernetes access, the request is rejected rather than stored. The console does not currently expose this setting. ## Cluster Topologies Edge Infrastructure Services supports three high-availability cluster configurations. You can also create a single-node cluster, with or without Kubernetes access. On a single node, storage replication is degraded: the cluster works, but it has no redundancy until you add nodes. ### Three-node HA Three nodes of equal status form the cluster. All three nodes participate in workload execution, high availability, and data replication. A three-node cluster provides a proper quorum for cluster decisions, which is the classic three-node HA model. ![Three-node HA cluster diagram showing three equal nodes connected for high availability and data replication.](https://mintcdn.com/zededa/nH470gZ2VKSQBZu8/new-ui/infrastructure-services/node-clusters/images/3-node-cluster.gif?s=70f11a973c8d8e29f18d79f87434a48d) ### Two-node HA with a tie-breaker Two primary nodes handle workloads and data replication. A third node is designated as the tie-breaker. The tie-breaker node does not have an app, network instance, or volume instance. The tie-breaker node is still connected to the same network as the non-tie-breaker nodes. The tie-breaker node does not have to be the same hardware as the others. It can have lower CPU, lower memory, lower network bandwidth, and lower performance. The tie-breaker node enables cluster availability if one of the non-tie-breaker nodes fails. You must tag the tie-breaker node with `tie-breaker:true` before cluster creation. You cannot assign this tag after you create the cluster. ![Two-node HA cluster diagram showing two primary nodes and one tie-breaker node connected through a shared Layer 2 network.](https://mintcdn.com/zededa/nH470gZ2VKSQBZu8/new-ui/infrastructure-services/node-clusters/images/2-node-tiebreaker-cluster.gif?s=b53c268d0be8482b3eebbd914c8d0170) ### Two-node HA with a witness Two server nodes handle workloads and data replication. Instead of a third node, an etcd-only witness provides the third quorum vote. The witness runs on the seed node. It is not a Kubernetes node, does not appear in the cluster's node list, and hosts no workloads. Use this model when a site has only two nodes and no hardware for a tie-breaker. While both nodes are members, applications run on the non-seed node. If a node fails permanently, you can reset the quorum so that the surviving node becomes the seed and runs the cluster on its own until you add a replacement node. Applications on a two-node HA cluster always use preferred node affinity, so they can fail over between the two nodes. You select this model with the **Enable two-node HA** setting when you create a cluster with exactly two nodes, or when you add a second node to a single-node cluster. You cannot turn two-node HA off after the cluster uses it. The only way to leave the scheme is to delete the cluster. See [Create Clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/create-node-clusters.md#two-node-ha-with-a-witness-prerequisites) and [Manage Two-Node HA](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md#manage-two-node-ha). ## Automatic Application Migration When you deploy an application to a cluster, Edge Infrastructure Services automatically selects one node as primary and assigns it responsibility for running the application, managing volumes, and handling network configurations. If the primary node becomes unavailable, the application migrates to another node in the cluster automatically. Your applications require no configuration changes. You can deploy existing applications to clusters without modification. Edge Infrastructure Services continuously tracks application status across all nodes. When an application migrates, Edge Infrastructure Services updates the application status and metrics to reflect the new placement. ## In This Section > [card] [Create clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/create-node-clusters.md) > > Configure cluster identity, select nodes, and set up the cluster network interface. > [card] [Manage clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md) > > View cluster status, update cluster settings, replace a failed node, and delete clusters. > [card] [App instance failover in clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/node-cluster-failover.md) > > Understand how applications fail over during planned maintenance and unexpected node outages.