Priority Classes for Critical CN2 Components

CN2 Components Overview

CN2 components provide critical networking functionality to Kubernetes clusters. Most CN2 clusters contain a dedicated set of nodes where cluster-related services do not share the same resources with user applications. In managed clusters like Amazon Elastic Kubernetes Service (EKS), the default environment configuration doesn’t support the same resource isolation. During times when cluster components and services are competing for compute resources, kube-scheduler should prioritize core CN2 components’ access to resources.

CN2 Implementation

CN2 release 23.2 introduces the PriorityClass object. A PriorityClass lets you map a priority, in the form of an integer value, to a priority class name. The higher the value, the higher the priority. By default, the cn2-deployer controllers use Kubernetes' built-in high-priority classes:

• system-cluster-critical: For config and control pods.

• system-node-critical: For vRouter pods.

The cn2-deployer uses these default priority classes when you apply CN2 manifests. We strongly recommend that you use these classes because they have the highest priority value. This means that kube-scheduler prioritizes these pods for scheduling, maintenance, and access to resources.

You may restrict usage of high-priority classes to a specific list of namespaces. This custom list of namespaces must include contrail, contrail-system, and contrail-deploy or else you are not able to deploy essential CN2 resources. Alternatively, you can create a custom PriorityClass and enter the name of the custom class in the priorityClassName field of the common section of a CN2 custom resource manifest.

The following example is a common section of a CN2 manifest.