mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
217 lines
12 KiB
Plaintext
217 lines
12 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
[id="updating-restricted-network-cluster"]
|
|
= Updating a restricted network cluster
|
|
include::_attributes/common-attributes.adoc[]
|
|
:context: updating-restricted-network-cluster
|
|
|
|
toc::[]
|
|
|
|
You can update a restricted network {product-title} cluster by using the `oc` command-line interface (CLI) or using the OpenShift Update Service.
|
|
|
|
== Updating a restricted network cluster using the CLI
|
|
|
|
You can update a restricted network {product-title} cluster by using the `oc` command-line interface (CLI).
|
|
|
|
A restricted network environment is the one in which your cluster nodes cannot access the internet. For this reason, you must populate a registry with the installation images. If your registry host cannot access both the internet and the cluster, you can mirror the images to a file system that disconnected from that environment and then bring that host or removable media across that gap. If the local container registry and the cluster are connected to the mirror registry's host, you can directly push the release images to the local registry.
|
|
|
|
If multiple clusters are present within the restricted network, mirror the required release images to a single container image registry and use that registry to update all the clusters.
|
|
|
|
=== Prerequisites
|
|
|
|
* Have access to the internet to obtain the necessary container images.
|
|
* Have write access to a container registry in the restricted-network environment to push and pull images. The container registry must be compatible with Docker registry API v2.
|
|
* You must have the `oc` command-line interface (CLI) tool installed.
|
|
* Have access to the cluster as a user with `admin` privileges.
|
|
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
|
|
* Have a recent xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your update fails and you must xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
|
|
* 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, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see _Upgrading clusters with manually maintained credentials_ for xref:../installing/installing_aws/manually-creating-iam.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-aws[AWS], xref:../installing/installing_azure/manually-creating-iam-azure.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-azure[Azure], or xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-gcp[GCP].
|
|
//STS is not currently supported in a restricted network environment, but the following bullet can be uncommented when that changes.
|
|
//* If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being upgraded to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[_Upgrading an OpenShift Container Platform cluster configured for manual mode with STS_].
|
|
* If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade 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.
|
|
|
|
[id="updating-restricted-network-mirror-host"]
|
|
=== Preparing your mirror host
|
|
|
|
Before you perform the mirror procedure, you must prepare the host to retrieve content
|
|
and push it to the remote location.
|
|
|
|
include::modules/cli-installing-cli.adoc[leveloffset=+3]
|
|
|
|
// this file doesn't exist, so I'm including the one that should pick up more changes from Clayton's PR - modules/installation-adding-mirror-registry-pull-secret.adoc[leveloffset=+1]
|
|
|
|
include::modules/installation-adding-registry-pull-secret.adoc[leveloffset=+3]
|
|
|
|
[id="update-mirror-repository_updating-restricted-network-cluster"]
|
|
=== Mirroring the {product-title} image repository
|
|
|
|
You must mirror container images onto a mirror registry before you can update a cluster in a restricted network environment. You can also use this procedure in unrestricted networks to ensure your clusters only use container images that have satisfied your organizational controls on external content.
|
|
|
|
There are two supported methods for mirroring images onto a mirror registry:
|
|
|
|
* Using the oc-mirror OpenShift CLI (`oc`) plugin
|
|
|
|
* Using the oc adm release mirror command
|
|
|
|
Choose one of the following supported options.
|
|
|
|
include::modules/update-mirror-repository-oc-mirror.adoc[leveloffset=+3]
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* xref:../installing/disconnected_install/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
|
|
|
|
include::modules/update-mirror-repository.adoc[leveloffset=+3]
|
|
|
|
include::modules/machine-health-checks-pausing.adoc[leveloffset=+2]
|
|
|
|
include::modules/update-restricted.adoc[leveloffset=+2]
|
|
|
|
include::modules/images-configuration-registry-mirror.adoc[leveloffset=+2]
|
|
|
|
include::modules/generating-icsp-object-scoped-to-a-registry.adoc[leveloffset=+2]
|
|
|
|
[id="additional-resources_security-container-signature"]
|
|
[role="_additional-resources"]
|
|
== Additional resources
|
|
|
|
* xref:../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[Using Operator Lifecycle Manager on restricted networks]
|
|
|
|
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine Config Overview]
|
|
|
|
[id="update-restricted-network-cluster-update-service"]
|
|
== Updating a restricted network cluster using the OpenShift Update Service
|
|
|
|
include::modules/update-service-overview.adoc[leveloffset=+2]
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* xref:../updating/understanding-upgrade-channels-release.adoc#understanding-upgrade-channels_understanding-upgrade-channels-releases[Understanding upgrade channels and releases]
|
|
|
|
For clusters with internet accessibility, Red Hat provides over-the-air updates through an {product-title} update service as a hosted service located behind public APIs. However, clusters in a restricted network have no way to access public APIs for update information.
|
|
|
|
To provide a similar update experience in a restricted network, you can install and configure the OpenShift Update Service locally so that it is available within a disconnected environment.
|
|
|
|
The following sections describe how to provide over-the-air updates for your disconnected cluster and its underlying operating system.
|
|
|
|
[id="update-service-prereqs"]
|
|
=== Prerequisites
|
|
|
|
* For more information on installing Operators, see xref:../operators/user/olm-installing-operators-in-namespace.adoc#olm-installing-operators-in-namespace[Installing Operators in your namespace].
|
|
|
|
[id="registry-configuration-for-update-service"]
|
|
=== Configuring access to a secured registry for the OpenShift update service
|
|
|
|
If the release images are contained in a secure registry, complete the steps in xref:../registry/configuring-registry-operator.adoc#images-configuration-cas_configuring-registry-operator[Configuring additional trust stores for image registry access] along with following changes for the update service.
|
|
|
|
The OpenShift Update Service Operator needs the config map key name `updateservice-registry` in the registry CA cert.
|
|
|
|
.Image registry CA config map example for the update service
|
|
[source,yaml]
|
|
----
|
|
apiVersion: v1
|
|
kind: ConfigMap
|
|
metadata:
|
|
name: my-registry-ca
|
|
data:
|
|
updateservice-registry: | <1>
|
|
-----BEGIN CERTIFICATE-----
|
|
...
|
|
-----END CERTIFICATE-----
|
|
registry-with-port.example.com..5000: | <2>
|
|
-----BEGIN CERTIFICATE-----
|
|
...
|
|
-----END CERTIFICATE-----
|
|
----
|
|
<1> The OpenShift Update Service Operator requires the config map key name updateservice-registry in the registry CA cert.
|
|
<2> If the registry has the port, such as `registry-with-port.example.com:5000`, `:` should be replaced with `..`.
|
|
|
|
include::modules/images-update-global-pull-secret.adoc[leveloffset=+2]
|
|
|
|
[id="update-service-install"]
|
|
=== Installing the OpenShift Update Service Operator
|
|
|
|
To install the OpenShift Update Service, you must first install the OpenShift Update Service Operator by using the {product-title} web console or CLI.
|
|
|
|
[NOTE]
|
|
====
|
|
For clusters that are installed on restricted networks, also known as disconnected clusters, Operator Lifecycle Manager by default cannot access the Red Hat-provided OperatorHub sources hosted on remote registries because those remote sources require full internet connectivity. For more information, see xref:../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[Using Operator Lifecycle Manager on restricted networks].
|
|
====
|
|
|
|
include::modules/update-service-install-web-console.adoc[leveloffset=+2]
|
|
|
|
include::modules/update-service-install-cli.adoc[leveloffset=+2]
|
|
|
|
include::modules/update-service-graph-data.adoc[leveloffset=+2]
|
|
|
|
[id="update-service-mirror-release_updating-restricted-network-cluster"]
|
|
=== Mirroring the {product-title} image repository
|
|
|
|
You must mirror container images onto a mirror registry before you can update a cluster in a restricted network environment. You can also use this procedure in unrestricted networks to ensure your clusters only use container images that have satisfied your organizational controls on external content.
|
|
|
|
There are two supported methods for mirroring images onto a mirror registry:
|
|
|
|
* Using the oc-mirror OpenShift CLI (`oc`) plugin
|
|
|
|
* Using the oc adm release mirror command
|
|
|
|
Choose one of the following supported options.
|
|
|
|
//The module below is being used twice in this assembly, so this instance needs to have a unique context set in order for its ID to be unique. In the future, if and when the two main sections of this webpage are split into their own assemblies/pages, the context attributes below can be removed.
|
|
|
|
:!context:
|
|
:context: osus-restricted-network-cluster
|
|
|
|
include::modules/update-mirror-repository-oc-mirror.adoc[leveloffset=+3]
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* xref:../installing/disconnected_install/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]
|
|
|
|
:!context:
|
|
:context: updating-restricted-network-cluster
|
|
|
|
include::modules/update-service-mirror-release.adoc[leveloffset=+3]
|
|
|
|
[id="update-service-create-service"]
|
|
=== Creating an OpenShift Update Service application
|
|
|
|
You can create an OpenShift Update Service application by using the {product-title} web console or CLI.
|
|
|
|
include::modules/update-service-create-service-web-console.adoc[leveloffset=+3]
|
|
|
|
include::modules/update-service-create-service-cli.adoc[leveloffset=+3]
|
|
|
|
[NOTE]
|
|
====
|
|
The policy engine route name must not be more than 63 characters based on RFC-1123. If you see `ReconcileCompleted` status as `false` with the reason `CreateRouteFailed` caused by `host must conform to DNS 1123 naming convention and must be no more than 63 characters`, try creating the Update Service with a shorter name.
|
|
====
|
|
|
|
include::modules/update-service-configure-cvo.adoc[leveloffset=+3]
|
|
|
|
[NOTE]
|
|
====
|
|
See xref:../networking/enable-cluster-wide-proxy.adoc#nw-proxy-configure-object[Enabling the cluster-wide proxy] to configure the CA to trust the update server.
|
|
====
|
|
|
|
[id="update-service-delete-service"]
|
|
=== Deleting an OpenShift Update Service application
|
|
|
|
You can delete an OpenShift Update Service application by using the {product-title} web console or CLI.
|
|
|
|
include::modules/update-service-delete-service-web-console.adoc[leveloffset=+3]
|
|
|
|
include::modules/update-service-delete-service-cli.adoc[leveloffset=+3]
|
|
|
|
[id="update-service-uninstall"]
|
|
=== Uninstalling the OpenShift Update Service Operator
|
|
|
|
To uninstall the OpenShift Update Service, you must first delete all OpenShift Update Service applications by using the {product-title} web console or CLI.
|
|
|
|
include::modules/update-service-uninstall-web-console.adoc[leveloffset=+3]
|
|
|
|
include::modules/update-service-uninstall-cli.adoc[leveloffset=+3]
|