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.
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.
High availability (HA) is available by default for the Knative Eventing eventing-controller
, eventing-webhook
, imc-controller
, imc-dispatcher
, and mt-broker-controller
components, which are configured to have two replicas each by default. You can change the number of replicas for these components by modifying the spec.high-availability.replicas
value in the KnativeEventing
custom resource (CR).
For Knative Eventing, the |
You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
The OpenShift Serverless Operator and Knative Eventing are installed on your cluster.
In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub → Installed Operators.
Select the knative-eventing
namespace.
Click Knative Eventing in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Eventing tab.
Click knative-eventing, then go to the YAML tab in the knative-eventing page.
Modify the number of replicas in the KnativeEventing
CR:
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
high-availability:
replicas: 3
You can also specify the number of replicas for a specific workload.
Workload-specific configuration overrides the global setting for Knative Eventing. |
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
high-availability:
replicas: 3
workloads:
- name: mt-broker-filter
replicas: 3
Verify that the high availability limits are respected:
$ oc get hpa -n knative-eventing
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
broker-filter-hpa Deployment/mt-broker-filter 1%/70% 3 12 3 112s
broker-ingress-hpa Deployment/mt-broker-ingress 1%/70% 3 12 3 112s
eventing-webhook Deployment/eventing-webhook 4%/100% 3 7 3 115s
High availability (HA) is available by default for the Knative broker implementation for Apache Kafka components kafka-controller
and kafka-webhook-eventing
, which are configured to have two each replicas by default. You can change the number of replicas for these components by modifying the spec.high-availability.replicas
value in the KnativeKafka
custom resource (CR).
You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
The OpenShift Serverless Operator and Knative broker for Apache Kafka are installed on your cluster.
In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub → Installed Operators.
Select the knative-eventing
namespace.
Click Knative Kafka in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Kafka tab.
Click knative-kafka, then go to the YAML tab in the knative-kafka page.
Modify the number of replicas in the KnativeKafka
CR:
apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
name: knative-kafka
namespace: knative-eventing
spec:
high-availability:
replicas: 3
A Pod Disruption Budget (PDB) is a standard feature of Kubernetes APIs that helps limit the disruption to an application when its pods need to be rescheduled for maintenance reasons.
Override the default PDB for a specific resource by modifying the minAvailable
configuration value in the KnativeEventing
custom resource (CR).
minAvailable
seting of 70%apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
name: knative-eventing
namespace: knative-eventing
spec:
podDisruptionBudgets:
- name: eventing-webhook
minAvailable: 70%
If you disable high-availability, for example, by changing the |