Cluster management
This page explains concepts associated with HashiCorp-managed clusters and self-managed clusters. The page also describes how the types of clusters function differently in HCP Consul deployments.
Background
You may be familiar with clusters in other contexts, but a cluster in HCP Consul refers to the group of Consul servers that participate in a datacenter's Raft quorum. Consul servers are deployed in a cluster with either three or five voting members in a typical production scenario, although single server deployments are possible for testing and development purposes.
For more information about Consul servers and how they work, refer to the following concepts in the Consul documentation:
- Consul architecture describes the overall role Consul servers play in a deployment
- Consensus protocol describes how servers elect leaders to product quorums through the Raft protocol
- Fault tolerance describes how the number of Consul servers impact network resiliency
Management types
HCP Consul supports two types of cluster management: HashiCorp-managed clusters and self-managed clusters.
When HCP Consul initially launched, its offerings were synonymous with HashiCorp-managed clusters. The HCP platform was the interface used to create, manage, access, and delete clusters operated by HashiCorp on your behalf. Now, the management plane service supports linking clusters that you manage yourself to HCP Consul, enabling you to view and access them from a central location alongside every cluster on your network.
You can deploy any combination of HashiCorp-managed and self-managed clusters side-by-side in an HCP Consul organization. The decision to use one approach to cluster management over the other ultimately depends on your network's specific needs.
HashiCorp-managed clusters
A HashiCorp-managed cluster is a set of one to three Consul servers that are installed, bootstrapped, and configured by HashiCorp, and hosted in a HashiCorp-managed environment. You can create a HashiCorp-managed cluster in either an AWS or Azure environment. Because we are responsible for the initial setup process, using HashiCorp-managed clusters removes much of the initial operating burden associated with implementing Consul in your service network. We are also responsible for maintaining the hardware and ensuring its availability, freeing up your time and resources for other network operations.
When you use HashiCorp-managed clusters, we deploy and maintain the control plane but you are still responsible for operating the data plane. This includes hosting and maintaining your services in your preferred environment, as well as registering them with Consul. To enable communication between HashiCorp-managed control plane and services in the data plane, you must create a HashiCorp Virtual Network (HVN) and peer your HVN to AWS or Azure. To learn more about the process for each cloud environment, refer to Create and manage an HVN for AWS or Create and manage an HVN for Azure.
The following diagrams describe the architecture for connections between HashiCorp-managed clusters and dataplane components hosted in a user-managed environment:
When deploying a HashiCorp-managed cluster, the cluster tier and cluster size you select affect the cluster's functionality and the number of service instances it can support.
Self-managed clusters
A self-managed cluster is a set of Consul servers that you install, host, and maintain yourself. This type of cluster management provides more personalized control over the bootstrapping process and the configurations that secure your cluster. It also enables you to connect HCP Consul to networks that are not based in AWS or Azure, including on-prem and bare metal deployments.
When you use self-managed clusters, you are responsible for securing and operating your network. HCP Consul supports both VM and Kubernetes deployments. Kubernetes users have the option to use either Helm or the consul-k8s CLI to manage clusters and link them to HCP. Refer to Link self-managed clusters overview for more information.