Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Work In Progress as per 7/

...

9/2020

...

This page will go through the requirements for a Kubernetes installer based on RA-2.

...

The chosen runtime must be conformant with the Kubernetes Container Runtime Interface (CRI) and the Open Container Initiative (OCI) runtime spec.

FeatureAirshipKindKubeOneKubesprayOpenShift Origin (OKD)
Container RuntimeDockerDockerDockerDockerDocker

A list of some of the avaialble OCI runtimes and CRIs can be seen below.

...

The version support policy states that the most recent 3 minor releases (n-2) are supported. The reference implementation, and therefore the Kubernetes installer, must align with this policy.

FeatureAirshipKindKubeOneKubesprayOpenShift Origin (OKD)
Follow support policyYesYesYesYesYes

The specific version of Kubernetes (or more specifically, the tools that are installed) depends to the version of the installer used. Here it is assumed that the most recent installer release is used.

...

If the installer uses Kubespray, this can be configured through the `kubelet_custom_flags` variable.

FeatureAirshipKindKubeOneKubesprayOpenShift Origin (OKD)
Follow support policyConfigurableConfigurableConfigurable
Use Topology Manager PolicyConfigurableLikely configurableNot configurableConfigurableUnsure?

As seen in the above table, the support for changing the policy varies between installers. None of the installers change the policy by default, but there are varying levels of support available.

Where configurable, it is usually through specifying flags to be passed to kubelet similar to the argument shown above.  For the other cases there are limited control over both feature-gates and flags, which in some cases prevent setting the policy.


While Topoloy Manager (alongside the other two features) provides a level of NUMA awareness to the cluster, it should be noted that this doesn't include Hugepages.

Also, the scheduler is not topology aware, so any POD that fails to schedule due to the topology manager will remain in terminated state. This can be solved by utilizing a ReplicaSet or by running the POD as part of a deployment.