- Documentation
- Red Hat OpenShift Serverless
- Serving
- High availability configuration for Knative Serving
- High availability for Knative services overview history bug_report picture_as_pdf
- About OpenShift Serverless
- Installing OpenShift Serverless
- Preparing to install OpenShift Serverless
- Installing the OpenShift 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 OpenShift Serverless Functions
- Installing the OpenShift Serverless Logic Operator
- Installing the OpenShift Serverless Logic Knative Workflow plugin
- OpenShift 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
- Subscribing functions to CloudEvents
- Functions development reference guide
- Configuring functions
- Serving
- Getting started with Knative Serving
- Scalability and Performance
- Autoscaling
- Configuring OpenShift Serverless applications
- Debugging OpenShift Serverless applications
- Kourier and Istio ingresses
- Serving transport encryption
- Traffic splitting
- External and Ingress routing
- HTTP configuration
- Configuring access to Knative services
- Configuring kube-rbac-proxy resources for Serving
- Configuring burst and QPS for net-kourier
- Configuring custom domains for Knative services
- High availability configuration for Knative Serving
- Tuning serving configuration
- Configuring Queue Proxy resources
- Eventing
- Knative Eventing
- Event sources
- Event sinks
- Brokers
- Triggers
- Channels
- Subscriptions
- Event delivery
- Event discovery
- Tuning eventing configuration
- Configuring TLS encryption in Eventing
- Configuring kube-rbac-proxy resources for Eventing
- Using ContainerSource with OpenShift Service Mesh
- Using a sink binding with OpenShift Service Mesh
- Serverless Logic
- Knative CLI
- Observability
- Integrations
- Integrating Service Mesh with OpenShift Serverless
- Using Service Mesh to isolate network traffic with OpenShift Serverless
- Integrating OpenShift Serverless with the cost management service
- Integrating OpenShift Serverless with OpenShift Pipelines
- Using NVIDIA GPU resources with serverless applications
- Removing OpenShift 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.