$ oc get machinehealthcheck -n openshift-machine-api
Use the following procedures to update a cluster in a disconnected environment without access to the OpenShift Update Service.
You must have the oc
command-line interface (CLI) tool installed.
You must provision a local container image registry with the container images for your update, as described in Mirroring OKD images.
You must have access to the cluster as a user with admin
privileges.
See Using RBAC to define and apply permissions.
You must have a recent etcd backup in case your update fails and you must restore your cluster to a previous state.
You have updated all Operators previously installed through Operator Lifecycle Manager (OLM) to a version that is compatible with your target release. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See Updating installed Operators for more information on how to check compatibility and, if necessary, update the installed Operators.
You must ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see Preparing to update a cluster with manually maintained credentials.
If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the update process. If minAvailable
is set to 1 in PodDisruptionBudget
, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the PodDisruptionBudget
field can prevent the node drain.
If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the update process. If |
During the update process, nodes in the cluster might become temporarily unavailable. In the case of worker nodes, the machine health check might identify such nodes as unhealthy and reboot them. To avoid rebooting such nodes, pause all the MachineHealthCheck
resources before updating the cluster.
Install the OpenShift CLI (oc
).
To list all the available MachineHealthCheck
resources that you want to pause, run the following command:
$ oc get machinehealthcheck -n openshift-machine-api
To pause the machine health checks, add the cluster.x-k8s.io/paused=""
annotation to the MachineHealthCheck
resource. Run the following command:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
The annotated MachineHealthCheck
resource resembles the following YAML file:
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
Resume the machine health checks after updating the cluster. To resume the check, remove the pause annotation from the
|
In order to update a cluster in a disconnected environment using the oc adm upgrade
command with the --to-image
option, you must reference the sha256 digest that corresponds to your targeted release image.
Run the following command on a device that is connected to the internet:
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
For {OCP_RELEASE_VERSION}
, specify the version of OKD to which you want to update, such as 4.10.16
.
For {ARCHITECTURE}
, specify the architecture of the cluster, such as x86_64
, aarch64
, s390x
, or ppc64le
.
sha256:a8bfba3b6dddd1a2fbbead7dac65fe4fb8335089e4e7cae327f3bad334add31d
Copy the sha256 digest for use when updating your cluster.
Update the disconnected cluster to the OKD version that you downloaded the release images for.
If you have a local OpenShift Update Service, you can update by using the connected web console or CLI instructions instead of this procedure. |
You mirrored the images for the new release to your registry.
You applied the release image signature ConfigMap for the new release to your cluster.
The release image signature config map allows the Cluster Version Operator (CVO) to ensure the integrity of release images by verifying that the actual image signatures match the expected signatures. |
You obtained the sha256 digest for your targeted release image.
You installed the OpenShift CLI (oc
).
You paused all MachineHealthCheck
resources.
Update the cluster:
$ oc adm upgrade --allow-explicit-upgrade --to-image <defined_registry>/<defined_repository>@<digest>
Where:
<defined_registry>
Specifies the name of the mirror registry you mirrored your images to.
<defined_repository>
Specifies the name of the image repository you want to use on the mirror registry.
<digest>
Specifies the sha256 digest for the targeted release image, for example, sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92
.
|
Setting up container registry repository mirroring enables you to perform the following tasks:
Configure your OKD cluster to redirect requests to pull images from a repository on a source image registry and have it resolved by a repository on a mirrored image registry.
Identify multiple mirrored repositories for each target repository, to make sure that if one mirror is down, another can be used.
Repository mirroring in OKD includes the following attributes:
Image pulls are resilient to registry downtimes.
Clusters in disconnected environments can pull images from critical locations, such as quay.io, and have registries behind a company firewall provide the requested images.
A particular order of registries is tried when an image pull request is made, with the permanent registry typically being the last one tried.
The mirror information you enter is added to the /etc/containers/registries.conf
file on every node in the OKD cluster.
When a node makes a request for an image from the source repository, it tries each mirrored repository in turn until it finds the requested content. If all mirrors fail, the cluster tries the source repository. If successful, the image is pulled to the node.
Setting up repository mirroring can be done in the following ways:
At OKD installation:
By pulling container images needed by OKD and then bringing those images behind your company’s firewall, you can install OKD into a data center that is in a disconnected environment.
After OKD installation:
If you did not configure mirroring during OKD installation, you can do so postinstallation by using any of the following custom resource (CR) objects:
ImageDigestMirrorSet
(IDMS). This object allows you to pull images from a mirrored registry by using digest specifications. The IDMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails.
ImageTagMirrorSet
(ITMS). This object allows you to pull images from a mirrored registry by using image tags. The ITMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails.
ImageContentSourcePolicy
(ICSP). This object allows you to pull images from a mirrored registry by using digest specifications. The ICSP CR always falls back to the source registry if the mirrors do not work.
Using an |
Each of these custom resource objects identify the following information:
The source of the container image repository you want to mirror.
A separate entry for each mirror repository you want to offer the content requested from the source repository.
For new clusters, you can use IDMS, ITMS, and ICSP CRs objects as desired. However, using IDMS and ITMS is recommended.
If you upgraded a cluster, any existing ICSP objects remain stable, and both IDMS and ICSP objects are supported. Workloads using ICSP objects continue to function as expected. However, if you want to take advantage of the fallback policies introduced in the IDMS CRs, you can migrate current workloads to IDMS objects by using the oc adm migrate icsp
command as shown in the Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring section that follows. Migrating to IDMS objects does not require a cluster reboot.
If your cluster uses an |
You can create postinstallation mirror configuration custom resources (CR) to redirect image pull requests from a source image registry to a mirrored image registry.
Access to the cluster as a user with the cluster-admin
role.
Configure mirrored repositories, by either:
Setting up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.
Using a tool such as skopeo
to copy images manually from the source repository to the mirrored repository.
For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL) 7 or RHEL 8 system, use the skopeo
command as shown in this example:
$ skopeo copy --all \
docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
docker://example.io/example/ubi-minimal
In this example, you have a container image registry that is named example.io
with an image repository named example
to which you want to copy the ubi9/ubi-minimal
image from registry.access.redhat.com
. After you create the mirrored registry, you can configure your OKD cluster to redirect requests made of the source repository to the mirrored repository.
Create a postinstallation mirror configuration CR, by using one of the following examples:
Create an ImageDigestMirrorSet
or ImageTagMirrorSet
CR, as needed, replacing the source and mirrors with your own registry and repository pairs and images:
apiVersion: config.openshift.io/v1 (1)
kind: ImageDigestMirrorSet (2)
metadata:
name: ubi9repo
spec:
imageDigestMirrors: (3)
- mirrors:
- example.io/example/ubi-minimal (4)
- example.com/example/ubi-minimal (5)
source: registry.access.redhat.com/ubi9/ubi-minimal (6)
mirrorSourcePolicy: AllowContactingSource (7)
- mirrors:
- mirror.example.com/redhat
source: registry.example.com/redhat (8)
mirrorSourcePolicy: AllowContactingSource
- mirrors:
- mirror.example.com
source: registry.example.com (9)
mirrorSourcePolicy: AllowContactingSource
- mirrors:
- mirror.example.net/image
source: registry.example.com/example/myimage (10)
mirrorSourcePolicy: AllowContactingSource
- mirrors:
- mirror.example.net
source: registry.example.com/example (11)
mirrorSourcePolicy: AllowContactingSource
- mirrors:
- mirror.example.net/registry-example-com
source: registry.example.com (12)
mirrorSourcePolicy: AllowContactingSource
1 | Indicates the API to use with this CR. This must be config.openshift.io/v1 . |
2 | Indicates the kind of object according to the pull type:
|
3 | Indicates the type of image pull method, either:
|
4 | Indicates the name of the mirrored image registry and repository. |
5 | Optional: Indicates a secondary mirror repository for each target repository. If one mirror is down, the target repository can use the secondary mirror. |
6 | Indicates the registry and repository source, which is the repository that is referred to in an image pull specification. |
7 | Optional: Indicates the fallback policy if the image pull fails:
|
8 | Optional: Indicates a namespace inside a registry, which allows you to use any image in that namespace. If you use a registry domain as a source, the object is applied to all repositories from the registry. |
9 | Optional: Indicates a registry, which allows you to use any image in that registry. If you specify a registry name, the object is applied to all repositories from a source registry to a mirror registry. |
10 | Pulls the image registry.example.com/example/myimage@sha256:… from the mirror mirror.example.net/image@sha256:.. . |
11 | Pulls the image registry.example.com/example/image@sha256:… in the source registry namespace from the mirror mirror.example.net/image@sha256:… . |
12 | Pulls the image registry.example.com/myimage@sha256 from the mirror registry example.net/registry-example-com/myimage@sha256:… . |
Create an ImageContentSourcePolicy
custom resource, replacing the source and mirrors with your own registry and repository pairs and images:
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
name: mirror-ocp
spec:
repositoryDigestMirrors:
- mirrors:
- mirror.registry.com:443/ocp/release (1)
source: quay.io/openshift-release-dev/ocp-release (2)
- mirrors:
- mirror.registry.com:443/ocp/release
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
1 | Specifies the name of the mirror image registry and repository. |
2 | Specifies the online registry and repository containing the content that is mirrored. |
Create the new object:
$ oc create -f registryrepomirror.yaml
After the object is created, the Machine Config Operator (MCO) drains the nodes for ImageTagMirrorSet
objects only. The MCO does not drain the nodes for ImageDigestMirrorSet
and ImageContentSourcePolicy
objects.
To check that the mirrored configuration settings are applied, do the following on one of the nodes.
List your nodes:
$ oc get node
NAME STATUS ROLES AGE VERSION
ip-10-0-137-44.ec2.internal Ready worker 7m v1.30.3
ip-10-0-138-148.ec2.internal Ready master 11m v1.30.3
ip-10-0-139-122.ec2.internal Ready master 11m v1.30.3
ip-10-0-147-35.ec2.internal Ready worker 7m v1.30.3
ip-10-0-153-12.ec2.internal Ready worker 7m v1.30.3
ip-10-0-154-10.ec2.internal Ready master 11m v1.30.3
Start the debugging process to access the node:
$ oc debug node/ip-10-0-147-35.ec2.internal
Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`
Change your root directory to /host
:
sh-4.2# chroot /host
Check the /etc/containers/registries.conf
file to make sure the changes were made:
sh-4.2# cat /etc/containers/registries.conf
The following output represents a registries.conf
file where postinstallation mirror configuration CRs were applied. The final two entries are marked digest-only
and tag-only
respectively.
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
short-name-mode = ""
[[registry]]
prefix = ""
location = "registry.access.redhat.com/ubi9/ubi-minimal" (1)
[[registry.mirror]]
location = "example.io/example/ubi-minimal" (2)
pull-from-mirror = "digest-only" (3)
[[registry.mirror]]
location = "example.com/example/ubi-minimal"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.example.com"
[[registry.mirror]]
location = "mirror.example.net/registry-example-com"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.example.com/example"
[[registry.mirror]]
location = "mirror.example.net"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.example.com/example/myimage"
[[registry.mirror]]
location = "mirror.example.net/image"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.example.com"
[[registry.mirror]]
location = "mirror.example.com"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.example.com/redhat"
[[registry.mirror]]
location = "mirror.example.com/redhat"
pull-from-mirror = "digest-only"
[[registry]]
prefix = ""
location = "registry.access.redhat.com/ubi9/ubi-minimal"
blocked = true (4)
[[registry.mirror]]
location = "example.io/example/ubi-minimal-tag"
pull-from-mirror = "tag-only" (5)
1 | Indicates the repository that is referred to in a pull spec. |
2 | Indicates the mirror for that repository. |
3 | Indicates that the image pull from the mirror is a digest reference image. |
4 | Indicates that the NeverContactSource parameter is set for this repository. |
5 | Indicates that the image pull from the mirror is a tag reference image. |
Pull an image to the node from the source and check if it is resolved by the mirror.
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
If the repository mirroring procedure does not work as described, use the following information about how repository mirroring works to help troubleshoot the problem.
The first working mirror is used to supply the pulled image.
The main registry is only used if no other mirror works.
From the system context, the Insecure
flags are used as fallback.
The format of the /etc/containers/registries.conf
file has changed recently. It is now version 2 and in TOML format.
Using an ImageContentSourcePolicy
(ICSP) object to configure repository mirroring is a deprecated feature. This functionality is still included in OKD and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.
ICSP objects are being replaced by ImageDigestMirrorSet
and ImageTagMirrorSet
objects to configure repository mirroring. If you have existing YAML files that you used to create ImageContentSourcePolicy
objects, you can use the oc adm migrate icsp
command to convert those files to an ImageDigestMirrorSet
YAML file. The command updates the API to the current version, changes the kind
value to ImageDigestMirrorSet
, and changes spec.repositoryDigestMirrors
to spec.imageDigestMirrors
. The rest of the file is not changed.
Because the migration does not change the registries.conf
file, the cluster does not need to reboot.
For more information about ImageDigestMirrorSet
or ImageTagMirrorSet
objects, see "Configuring image registry repository mirroring" in the previous section.
Access to the cluster as a user with the cluster-admin
role.
Ensure that you have ImageContentSourcePolicy
objects on your cluster.
Use the following command to convert one or more ImageContentSourcePolicy
YAML files to an ImageDigestMirrorSet
YAML file:
$ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>
where:
<file_name>
Specifies the name of the source ImageContentSourcePolicy
YAML. You can list multiple file names.
--dest-dir
Optional: Specifies a directory for the output ImageDigestMirrorSet
YAML. If unset, the file is written to the current directory.
For example, the following command converts the icsp.yaml
and icsp-2.yaml
file and saves the new YAML files to the idms-files
directory.
$ oc adm migrate icsp icsp.yaml icsp-2.yaml --dest-dir idms-files
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml
Create the CR object by running the following command:
$ oc create -f <path_to_the_directory>/<file-name>.yaml
where:
<path_to_the_directory>
Specifies the path to the directory, if you used the --dest-dir
flag.
<file_name>
Specifies the name of the ImageDigestMirrorSet
YAML.
Remove the ICSP objects after the IDMS objects are rolled out.
You can scope the mirrored image catalog at the repository level or the wider registry level. A widely scoped ImageContentSourcePolicy
resource reduces the number of times the nodes need to reboot in response to changes to the resource.
To widen the scope of the mirror image catalog in the ImageContentSourcePolicy
resource, perform the following procedure.
Install the OKD CLI oc
.
Log in as a user with cluster-admin
privileges.
Configure a mirrored image catalog for use in your disconnected cluster.
Run the following command, specifying values for <local_registry>
, <pull_spec>
, and <pull_secret_file>
:
$ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry
where:
is the local registry you have configured for your disconnected cluster, for example, local.registry:5000
.
is the pull specification as configured in your disconnected registry, for example, redhat/redhat-operator-index:v4.17
is the registry.redhat.io
pull secret in .json
file format. You can download the pull secret from Red Hat OpenShift Cluster Manager.
The oc adm catalog mirror
command creates a /redhat-operator-index-manifests
directory and generates imageContentSourcePolicy.yaml
, catalogSource.yaml
, and mapping.txt
files.
Apply the new ImageContentSourcePolicy
resource to the cluster:
$ oc apply -f imageContentSourcePolicy.yaml
Verify that oc apply
successfully applied the change to ImageContentSourcePolicy
:
$ oc get ImageContentSourcePolicy -o yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}}
...
After you update the ImageContentSourcePolicy
resource, OKD deploys the new settings to each node and the cluster starts using the mirrored repository for requests to the source repository.