openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Created Cri-O default capabilities section

Browse Source
This commit is contained in:
subhtk
2024-07-16 19:29:16 +05:30
committed by openshift-cherrypick-robot
parent febc984f20
commit 7aa065f272
2 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
machine_configuration/machine-configs-custom.adoc
View File

@@ -12,5 +12,6 @@ Besides managing `MachineConfig` objects, the MCO manages two custom resources (
include::modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc[leveloffset=+1]
include::modules/create-a-containerruntimeconfig-crd.adoc[leveloffset=+1]
include::modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc[leveloffset=+1]
include::modules/create-crio-default-capabilities.adoc[leveloffset=+1]

42
modules/create-crio-default-capabilities.adoc Normal file
View File

@@ -0,0 +1,42 @@
// Module included in the following assemblies:
//
// * machine_configuration/machine-configs-custom.adoc
:_mod-docs-content-type: CONCEPT
[id="create-crio-default-capabilities_{context}"]
= Creating a drop-in file for the default CRI-O capabilities
You can change some of the settings associated with the {product-title} CRI-O runtime for the nodes associated with a specific machine config pool (MCP). By using a controller custom resource (CR), you set the configuration values and add a label to match the MCP. The MCO then rebuilds the `crio.conf` and `default.conf` configuration files on the associated nodes with the updated values.
Earlier versions of {product-title} included specific machine configs by default. If you updated to a later version of {product-title}, those machine configs were retained to ensure that clusters running on the same {product-title} version have the same machine configs.
You can create multiple `ContainerRuntimeConfig` CRs, as needed, with a limit of 10 per cluster. For the first `ContainerRuntimeConfig` CR, the MCO creates a machine config appended with `containerruntime`. With each subsequent CR, the controller creates a `containerruntime` machine config with a numeric suffix. For example, if you have a `containerruntime` machine config with a `-2` suffix, the next `containerruntime` machine config is appended with `-3`.
If you want to delete the machine configs, delete them in reverse order to avoid exceeding the limit. For example, delete the `containerruntime-3` machine config before you delete the `containerruntime-2` machine config.
[NOTE]
====
If you have a machine config with a `containerruntime-9` suffix and you create another `ContainerRuntimeConfig` CR, a new machine config is not created, even if there are fewer than 10 `containerruntime` machine configs.
====
.Example of multiple ContainerRuntimeConfig CRs
[source,terminal]
----
$ oc get ctrcfg
----
.Example output
[source,terminal]
----
NAME AGE
ctr-overlay 15m
ctr-level 5m45s
----
.Example showing multiple containerruntime related system configs
[source,terminal]
----
$ cat /proc/1/status | grep Cap
$ capsh --decode=<decode_CapBnd_value> <1>
----
<1> Replace `<decode_CapBnd_value>` with the specific value you want to decode.