Parameters

The OpenShift version of the cluster on which the component is installed. We expect that most users will set this parameter to ${dynamic_facts:openshiftVersion}.

List of availability zone names. The list will be used when distributing MachineSets across zones (see [multiAZ]). The first item of this list will also be used to place a MachineSet without an explicit zone defined.

It’s suggested to define its values higher up the config hierarchy. Most probably the one of the cloud region.

A dictionary holding the default values applied to each machinesets.machine.openshift.io object created by this component.

The top level keys are the names of cloud providers as reported by the cluster fact ${facts:cloud}. The values can be everything that’s accepted in the spec field of a machinesets.machine.openshift.io object.

A dictionary holding the default values applied to each controlplanemachinesets.machine.openshift.io object created by this component.

The top level keys are the names of cloud providers as reported by the cluster fact ${facts:cloud}. The values can be everything that’s accepted in the spec field of a controlplanemachinesets.machine.openshift.io object.

This is the 12 character infrastructure ID given to a cluster by the OpenShift 4 installer. Use the following command to retrieve this from the cluster:

See also Get a clusters infrastructure ID as a fact.

The namespace where machine-api related objects should be created.

A dictionary holding the default values applied to the node.config.openshift.io object created by this component.

You can switch between cgroup v1 and cgroup v2, as needed, by editing the node.config object. For more information, see Enabling Linux control group version 2.

A dictionary of node groups to create on the cluster. It’s centered around the MachineSet CRD but also takes care of some additional aspects like zone distribution and auto scaling.

The top level key is the name of each set of machines. Each set of machines has the values described below.

If an entry has value null, no MachineSet is created for that entry. This allows users to remove entries in the hierarchy.

A dictionary of machine sets to create on the cluster. The resulting MachineSet object will have the key as the name and the value is merged into the resource.

The MachineSet will will have the namespace from machine_api_namespace applied.

The fields in this parameter can be used to configure OpenShift’s cluster autoscaling. See the upstream documentation for a detailed description.

A dictionary of machine config pools to create on the cluster. The resulting MachineConfigPool object will have the key prefixed with x- as the name and the value is merged into the resource.

Apart from the machine config pool, this dictionary can manage related resources through the following fields, that won’t be added to the MachineConfigPool object.

By default the component creates app, infra, and storage machine config pools, each of which extends the worker pool. Config pools can be removed by setting their dictionary value to null.

This parameter accepts a key-value dict where the values are of kind machineconfiguration.openshift.io/v1/MachineConfig. The resulting MachineConfig objects will have the keys, prefixed with 99x-, as the name and the values are merged into the resource.

Reference the upstream documentation on how to use machine config objects.

We add special support for defining file contents in the hierarchy with key storage.files.X.source.inline which isn’t part of the Ignition spec.

The resulting machine config for this example looks as follows:

This parameter accepts a key-value dict where the values are of kind machineconfiguration.openshift.io/v1/ContainerRuntimeConfig. The keys are resulting metadata.name and the values reflect the .spec field of ContainerRuntimeConfig.

This parameter accepts a key-value dict where the values are of kind machineconfiguration.openshift.io/v1/KubeletConfig. The keys are resulting metadata.name and the values reflect the .spec field of KubeletConfig.

See also: Managing the maximum number of pods per node

The namespace to create for oc debug node/<nodename>. This namespace is annotated to ensure that debug pods can be scheduled on any nodes.

Use oc debug node/<nodename> --to syn-debug-nodes to create the debug pods in the namespace.

This parameter will deploy a MachineConfig which configures a systemd service that sets up dummy interfaces for egress IPs on the nodes in each MachineConfigPool listed in field machineConfigPools. The component supports removal of MachineConfigPools by prefixing the pool with ~.

The systemd unit deployed by the script is configured to be executed after the node’s network is online but before the Kubelet starts. The systemd unit executes a script which reads the required egress interfaces and associated IPs from the configmap indicated in parameter shadowRangeConfigMap.

The script uses the file indicated in field nodeKubeconfig to fetch the ConfigMap from the cluster. If the default value is used, the script will use the node’s Kubelet kubeconfig to access the cluster. To ensure the Kubelet can access the configmap, users should ensure that a pod which mounts the ConfigMap is running on the node.

The script expects the ConfigMap to have a key matching each node name on which egress dummy interfaces should be configured.

This parameter allows configuring "static" node disruption policies. Node disruption policies allow customizing the actions that are executed when a MachineConfig change is applied. By default the machine config operator (MCO) will reboot nodes when a MachineConfig changes a file or a systemd unit. With node disruption policies, which are configured in the global machineconfigurations.operator.openshift.io/cluster resource, you can customize the MCO behavior when a file or systemd unit is changed.

The node disruption policies are configured via field spec.nodeDisruptionPolicy in the machineconfiguration.operator.openshift.io/cluster resource. That object has fields files, units and sshkey. Field files is a list. Each entry of files has fields path and actions. The list is indexable by field path of the entries. Field units is a list. Each entry of units has fields name and actions. The list is indexable by field name of the entries. Field sshkey is an object with field actions. Field actions defines the actions to take when the policy matches a change.

Actions are executed in the order that they appear in field actions. Currently, the following actions are supported:

The component expects parameter fields files and units to be dictionaries and treats the keys as values for field path and name for the files and units lists in the MachineConfiguration resource respectively. The values of each entry in files and units are used verbatim. The content of parameter field sshkey_actions is used verbatim as the contents of sshkey.actions.

The component has some validation and will reject obviously invalid configurations, such as a list of actions which contains Reboot or None together with other actions.

The component deploys an Espejote ManagedResource which collects node disruption policies from annotation openshift4-nodes.syn.tools/node-disruption-policies from all MachineConfig resources (except the rendered-* resources) and merges those values (which are expected to be string-encoded JSON) with the statically configured policies provided in this parameter. The contents of this parameter are deployed on the cluster in an Espejote JsonnetLibrary object.

The contents of each annotation are expected to be string-encoded JSON which contains a valid node disruption policy snippet. The expected top-level fields of the annotation contents are files, units or sshkey. The ManagedResource uses the same validation logic as the component to reject obviously invalid configurations provided via annotations.

Since there can only be one policy per file path and per systemd unit, the ManagedResource will collect each list of actions for a given path or unit and select the "most disruptive" list of actions.

Reboot is treated as the most disruptive action and has precedence over all other lists of actions. None is treated as the least disruptive action and all other lists of actions have precedence over None. Other lists of actions are merged together, since we can’t sensibly define an order of precedence for two lists of actions that are composed from the actions other than None or Reboot.

This parameter allows users to enable and configure alerts for node capacity management. The capacity alerts are disabled by default and can be enabled by setting the key capacityAlerts.enabled to true. Predictive alerts are disabled by default and can be enabled individually as shown below by setting ExpectClusterCpuUsageHigh.enabled to true.

The dictionary will be transformed into a PrometheusRule object by the component.

The component provides 10 alerts that are grouped in four groups. You can disable or modify each of these alert rules individually. The fields in these rules will be added to the final PrometheusRule, with the exception of expr. The expr field contains fields which can be used to tune the default alert rule. Alternatively, the default rule can be completely overwritten by setting the expr.raw field (see example below). See Resource Management for an explanation for every alert rule.

Nodes are grouped by machineSet if machineSets are in use on the cluster. If machineSets are not in use, nodes are grouped by node role instead. The component automatically determines whether to group by machineSets or node roles.

When grouping by node role, it is possible to further group the nodes by additional node labels by specifying capacityAlerts.groupByNodeLabels. When grouping by machineSets, there is no equivalent setting.

Example: