mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Created Cri-O default capabilities section
This commit is contained in:
@@ -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
42
modules/create-crio-default-capabilities.adoc
Normal 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.
|
||||
Reference in New Issue
Block a user