- Documentation
- Red Hat OpenShift Serverless
- Serving
- Configuring high availability for Knative services
- High availability for Knative services overview history
- About Serverless
- Installing Serverless
- Preparing to install OpenShift Serverless
- Installing the Serverless Operator
- Installing the Knative CLI
- Installing Knative Serving
- Installing Knative Eventing
- Configuring Knative for Apache Kafka
- Configuring kube-rbac-proxy resources for Knative for Apache Kafka
- Configuring Serverless Functions
- Serverless upgrades
- Functions
- Getting started with functions
- Creating functions
- Running functions locally
- Deploying functions
- Building functions
- Listing existing functions
- Invoking functions
- Deleting functions
- Building and deploying functions on the cluster
- Connecting an event source to a function
- Functions development reference guide
- Configuring functions
- Serving
- Getting started with Knative Serving
- Autoscaling
- Configuring Serverless applications
- Traffic splitting
- External and Ingress routing
- Configuring access to Knative services
- Configuring kube-rbac-proxy resources for Serving
- Configuring custom domains for Knative services
- Configuring high availability for Knative services
- Eventing
- Knative CLI
- Observability
- Integrations
- Removing Serverless
High availability for Knative services
High availability (HA) is a standard feature of Kubernetes APIs that helps to ensure that APIs stay operational if a disruption occurs. In an HA deployment, if an active controller crashes or is deleted, another controller is readily available. This controller takes over processing of the APIs that were being serviced by the controller that is now unavailable.
HA in OpenShift Serverless is available through leader election, which is enabled by default after the Knative Serving or Eventing control plane is installed. When using a leader election HA pattern, instances of controllers are already scheduled and running inside the cluster before they are required. These controller instances compete to use a shared resource, known as the leader election lock. The instance of the controller that has access to the leader election lock resource at any given time is called the leader.