Service Level Agreement (SLA)

Version: 29 Jan 2024

This SLA establishes conditions and a method for measuring the level of service at a given time, defines the guaranteed level of service, and sets out penalties for violating the guaranteed level of service.

The level of service is measured based on monitoring data for individual cluster components grouped into availability types. Some availability types require enabling a special high availability mode of operation of components of the OpenShift cluster (elsewhere referred to as the High Availability mode, HA) to ensure a guaranteed level of service.

Specifications and operating conditions of components running in the High Availability mode:

The component is run in two or more instances to preserve availability in the case of a failure of a single instance
Enabling this mode requires additional computing resources
If there is more than one control plane node in the cluster, the High Availability mode is activated for all components by default
The HA mode can be turned off for individual components, such as authentication and monitoring, to reduce the cost of computing resources. However, we cannot guarantee the Service Level (SL) for such subsystems.
Control Plane — the cluster core — is considered running in the HA mode if it has at least three instances

Availability Types

To accurately identify types of degradations and the degree of their impact on the performance of services, we define several types of unavailability for which it is possible to set the parameters under the SLA.

Synthetic Availability

Synthetic availability is the availability of running applications in the cluster and cluster components that are not related to the availability of the cluster's Control Plane.

The SLA for Synthetic Availability is valid only if these basic conditions are met:

Cluster nodes continue to be available
There is network connectivity between nodes
The application continues to operate correctly

At the same time, applications keep on running that meet the following conditions:

The application itself caches DNS data
The application can operate with no scheduler or autoscaler running as well as with no ability to add/edit service endpoints
No kube-apiserver availability is required for the application to operate

This availability type does not require enabling the HA mode for components.

Router Availability

Router availability is the availability of ingress router and its components - incoming HTTP requests are delivered to end applications.

The router availability SLA does not cover the network availability that depends on the infrastructure.

This availability type requires enabling the HA mode for components.

Node Group Availability

In managed OpenShift, nodes are grouped together based on a purpose and managed as an integrated entity. All nodes in the group have the same metadata defined in the parameters of a NodeGroup resource based on labels, annotations, or taint fields. Such a group of nodes is called the Node Group.

Node Group Availability indicates that each Node Group has at least N-1 correctly functioning nodes, where N is the minimum number of nodes in NodeGroup as defined in the configuration.

The Node Group Availability SLA does not apply to cases when a node fails due to improper operation of an application installed by the customer.

This availability type does not require enabling the HA mode for components.

Control Plane Availability

Control plane availability indicates that the deployment process in the cluster is working, and self-healing processes are running. It formulates the availability level of the main control OpenShift components:

console
etcd
ingress
kube-apiserver
kube-controller-manager
kube-dns
kube-scheduler
oauth-server
openshift-apiserver
openshift-cluster-csi-drivers
openshift-cluster-node-tuning-operator
openshift-image-registry
openshift-kube-scheduler
openshift-multus
openshift-operator-lifecycle-manager
openshift-sdn
openshift-storage-operator
other components that the API depends on, such as Vertical Pod Autoscaler's admission controller

This availability type requires enabling the HA mode for components.

Monitoring and Autoscaling Availability

Monitoring and autoscaling availability means that monitoring and autoscaling are operating correctly. It defines the Prometheus availability level and auto-scaling capabilities of components and data sources:

Prometheus
Vertical Pod Autoscaler
Horizontal Pod Autoscaler

This availability type requires enabling the HA mode for components.

Extensions Availability

Extensions availability means that additional Kubernetes components could be available. It sets out the availability level of components not directly involved in delivering applications to the runtime environment and their operation in the cluster, such as addons from Stakater listed on Managed AddOns.

This availability type requires enabling the HA mode for components.

Common SLA Conditions for all Availability Types

Availability types do not apply to situations of complete lack of network connectivity between nodes or total inaccessibility of the cluster infrastructure.

The availability of each cluster component individually and of the availability type as a whole is determined by the best value obtained from multiple probing agents.

Guaranteed Level of Service

Availability Type	Non-Prod	Prod
Synthetic	99.0%	99.5%
Router	99.0%	99.5%
Node Group	99.0%	99.5%
Control Plane	99.0%	99.5%
Monitoring and Autoscaling	99.0%	99.5%
Extensions	99.0%	99.5%

Penalties for Violating the Service Level

Stakater shall pay the penalty at the Customer's request for violation of the SLA conditions. The amount of the penalty is determined as follows:

Penalty	Non-Prod	Prod
The maximum amount of penalty per month of service for violating the SLA	No more than 10% of the monthly cost of service	No more than 20% of the monthly cost of service

Stakater shall not be considered to have violated the SLA and shall not be deemed liable if the service level cannot be guaranteed for reasons beyond Stakater's control.

If the SLA is violated for multiple availability types for the same cluster simultaneously, only the highest penalty for the availability type shall be subject to payment.

Additional Sections

The following sections also applies to this SLA: