Skip to content

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: