mirror of https://github.com/status-im/consul.git
49 lines
3.5 KiB
Plaintext
49 lines
3.5 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Consul on Kubernetes Control Plane Architecture
|
||
description: >-
|
||
When running on Kubernetes, Consul’s control plane architecture does not change significantly. Server agents are deployed as a StatefulSet with a persistent volume, while client agents can run as a k8s DaemonSet with an exposed API port or be omitted with Consul Dataplanes.
|
||
---
|
||
|
||
# Architecture
|
||
|
||
This topic describes the architecture, components, and resources associated with Consul deployments to Kubernetes. Consul employs the same architectural design on Kubernetes as it does with other platforms, but Kubernetes provides additional benefits that make operating a Consul cluster easier. Refer to [Consul Architecture](/docs/architecture) for more general information on Consul's architecture.
|
||
|
||
> **For more specific guidance:**
|
||
> - For guidance on datacenter design, refer to [Consul and Kubernetes Reference Architecture](/consul/tutorials/kubernetes-production/kubernetes-reference-architecture).
|
||
> - For step-by-step deployment guidance, refer to [Consul and Kubernetes Deployment Guide](/consul/tutorials/kubernetes-production/kubernetes-deployment-guide).
|
||
> - For non-Kubernetes guidance, refer to the standard [production deployment guide](/consul/tutorials/production-deploy/deployment-guide).
|
||
|
||
## Server Agents
|
||
|
||
The server agents are deployed as a `StatefulSet` and use persistent volume
|
||
claims to store the server state. This also ensures that the
|
||
[node ID](/docs/agent/config/config-files#node_id) is persisted so that servers
|
||
can be rescheduled onto new IP addresses without causing issues. The server agents
|
||
are configured with
|
||
[anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
|
||
rules so that they are placed on different nodes. A readiness probe is
|
||
configured that marks the pod as ready only when it has established a leader.
|
||
|
||
A Kubernetes `Service` is registered to represent the servers and exposes ports that are required to communicate to the Consul server pods.
|
||
The servers utilize the DNS address of this service to join a Consul cluster, without requiring any other access to the Kubernetes cluster. Additional consul servers may also utilize non-ready endpoints which are published by the Kubernetes service, so that servers can utilize the service for joining during bootstrap and upgrades.
|
||
|
||
Additionally, a **PodDisruptionBudget** is configured so the Consul server
|
||
cluster maintains quorum during voluntary operational events. The maximum
|
||
unavailable is `(n/2)-1` where `n` is the number of server agents.
|
||
|
||
-> **Note:** Kubernetes and Helm do not delete Persistent Volumes or Persistent
|
||
Volume Claims when a
|
||
[StatefulSet is deleted](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#stable-storage),
|
||
so this must done manually when removing servers.
|
||
|
||
## Consul Dataplane
|
||
|
||
By default, Consul on Kubernetes uses an alternate service mesh configuration that injects sidecars without client agents. _Consul Dataplane_ manages Envoy proxies and leaves responsibility for other functions to the orchestrator, which removes the need to run client agents on every node.
|
||
|
||
|
||
|
||
Refer to [Simplified Service Mesh with Consul Dataplanes](/docs/connect/dataplane) for more information.
|
||
|
||
Consul Dataplane is the default proxy manager in Consul on Kubernetes 1.14 and later. If you are on Consul 1.13 or older, refer to [upgrading to Consul Dataplane](/docs/k8s/upgrade#upgrading-to-consul-dataplanes) for specific upgrade instructions.
|