14 Miscellaneous #

In some cases you must configure the container runtime to use a proxy to pull container images.

The CRI-O runtime uses the system-wide proxy configuration, defined at /etc/sysconfig/proxy.

This file can be edited a number of ways. It can be pre-configured at build time via AutoYaST, as described in the AutoYaST documentation. On an existing system, the file can be edited via YaST by running yast2 proxy.

If preferred, it can alternatively be edited manually as described in the SUSE Knowledge Base article

Note

CRI-O and skuba both support four types of comma-separated entries in the NO_PROXY variable:

• An exact IP address (1.2.3.4)

• CIDR IP range (1.2.3.4/16)

• DNS domain name (eg.com matches www.eg.com and eg.com)

• Restricted DNS subdomain (.eg.com matches www.eg.com but not eg.com)

All standard programs should ignore unsupported values in that variable and continue to work (albeit without the configured proxy) when encountering an unsupported value.

Tip

Not all programs on all systems will respect CIDR ranges or restricted subdomains.

After you have configured the system proxy for your environment, restart the container runtime with:

systemctl restart crio

Important

The configuration example in this text uses VERSION 2 of the CRI-O registries configuration syntax. It is not compatible with the VERSION 1 syntax present in some upstream examples.

Please refer to: https://raw.githubusercontent.com/containers/image/master/docs/containers-registries.conf.5.md

Tip

You can create and deploy a custom registries.conf during the initial bootstrap of the cluster with skuba. Create the file <CLUSTER_NAME>/addons/containers/registries.conf and apply your changes there. This file will be rolled out during node bootstrapping and upgrading.

Every registry-related configuration needs to be done in the TOML file /etc/containers/registries.conf. After any change of this file, CRI-O needs to be restarted.

The configuration is a sequence of [[registry]] entries. For example, a single registry entry within that configuration could be added like this:

/etc/containers/registries.conf

[[registry]]
blocked = false
insecure = false
location = "example.net/bar"
prefix = "example.com/foo/images"
mirror = [
    { location = "example-mirror-0.local", insecure = false },
    { location = "example-mirror-1.local", insecure = true, mirror-by-digest-only = true }
]

[[registry]]
blocked = false
insecure = false
location = "example.net/mymirror"
prefix = "example.com/mirror/images"
mirror = [
    { location = "example-mirror-2.local", insecure = false, mirror-by-digest-only = true },
    { location = "example-mirror-3.local", insecure = true }
]
unqualified-search = false

Given an image name, a single [[registry]] TOML table is chosen based on its prefix field.

A prefix is mainly a user-specified image name and can have one of the following formats:

The user-specified image name must start with the specified prefix (and continue with the appropriate separator) for a particular [[registry]] TOML table to be considered. Only the TOML entry with the longest match is used.

As a special case, the prefix field can be missing. If so, it defaults to the value of the location field.

prefix = "example.com/foo"
location = "internal-registry-for-example.net/bar"

FlexVolume drivers are external (out-of-tree) drivers usually provided by a specific vendor. They are executable files that are placed in a predefined directory in the cluster on both worker and master nodes. Pods interact with FlexVolume drivers through the flexvolume in-tree plugin.

The vendor driver first has to be installed on each worker and master node in a Kubernetes cluster. On SUSE CaaS Platform 4, the path to install the drivers is /usr/lib/kubernetes/kubelet-plugins/volume/exec/.

If the drivers are deployed with DaemonSet, this will require changing the FlexVolume directory path, which is usually stored as an environment variable, for example for rook:

FLEXVOLUME_DIR_PATH=/usr/lib/kubernetes/kubelet-plugins/volume/exec/

For a general guide to the FlexVolume configuration, see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md

Warning

Modifying the file /etc/sysconfig/kubelet directly is not supported.

The changes made to this file will not persist through an update/upgrade of the software. Please follow the instructions below to change the configuration for kubelet persistently.

Note

This procedure does not override the default configuration but amends the changes from the "drop-in" configuration.

Please refer to: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

If you wish to modify the configuration for kubelet you must use the "drop-in" configuration feature of systemd. The steps need to be performed on each cluster node whose kubelet you wish to reconfigure.

This documentation page lists all the behavioral changes and API deprecations that will happen from Kubernetes 1.17 to 1.18. You will require this information when migrating to SUSE CaaS Platform 5.x shipping with Kubernetes 1.18.