Mejor protección para el futuro: análisis de las instalaciones desconectadas de Red Hat OpenShift con el instalador basado en agentes

En el panorama digital actual, la confiabilidad y el cumplimiento de las normas de seguridad son más importantes que nunca. Para una empresa que tiene una conectividad a Internet restringida o poco efectiva, elegir entre una instalación de Red Hat OpenShift estándar y una desconectada o aislada puede ser una decisión revolucionaria. Las instalaciones desconectadas permiten que las empresas establezcan y mantengan clústeres de OpenShift en entornos aislados, centrados en la seguridad y autónomos, lo que garantiza una infraestructura sólida, necesaria para el éxito en un mundo cada vez más complejo.

En este artículo, se analizan las ventajas y los aspectos más importantes de este paradigma esencial de implementación y funcionamiento.

Métodos de instalación

Primero, veamos cada uno de los métodos de instalación disponibles para los clústeres de OpenShift autogestionados.

Imagen 1: Diferentes métodos de instalación

Infraestructura preparada por el instalador (IPI)

El método de instalación IPI es uno de los más sencillos. Es ideal para los usuarios que buscan una experiencia guiada y automatizada. Con él, OpenShift prepara la infraestructura, incluidas las máquinas virtuales y el hardware físico. Por lo general, se usa con proveedores de nube, pero también se puede usar para las instalaciones locales.

Instalador asistido (AI)

El instalador asistido es una herramienta interactiva y basada en la web para realizar instalaciones de OpenShift. Es el enfoque perfecto para los clústeres con redes conectadas a Internet. También proporciona una API de RESTful para los casos de automatización y configuración avanzada. El método AI también forma parte de Red Hat Advanced Cluster Management.

Instalador basado en agentes (ABI)

La instalación basada en agentes comprende una ISO de arranque que contiene el agente de descubrimiento y el servicio asistidos. Es un subcomando del instalador de OpenShift. Genera una imagen ISO de arranque que contiene todos los recursos necesarios para implementar un clúster con una imagen disponible de una versión de OpenShift. Este enfoque es ideal para los entornos aislados, desconectados o restringidos.

Infraestructura preparada por el usuario (UPI)

El un método flexible para los usuarios que prefieren gestionar su propia infraestructura, ya sea en las instalaciones, en sus centros de datos o en los proveedores de nube pública. Con él, los usuarios son los responsables de preparar las máquinas virtuales, el almacenamiento y los elementos de red, por ejemplo, un equilibrador de carga. Una vez que se preparó la infraestructura, se puede usar el instalador para implementar OpenShift en la infraestructura que se eligió.

Plano de control alojado (HCP)

Los clústeres de OpenShift se pueden implementar utilizando dos configuraciones de plano de control diferentes: independientes o alojados. La configuración independiente usa máquinas virtuales o físicas exclusivas para alojar el plano de control. Con los planos de control alojados para OpenShift, puede crear planos como pods en un clúster de alojamiento sin la necesidad de utilizar máquinas virtuales o físicas exclusivas para cada uno. Consulte la documentación oficial de HCP y este artículo para obtener más información.

Instalaciones desconectadas

Hay diferentes tipos de instalación para distintos casos. Es importante que elija el método adecuado para su caso práctico. Una instalación desconectada de OpenShift es una solución fundamental para las empresas y los entornos en los cuales el cumplimiento de las normas de seguridad, el control y la confiabilidad son primordiales, y la conectividad directa a Internet es restringida o no es deseable. Proporciona la infraestructura necesaria para gestionar y mantener los clústeres de OpenShift en redes aisladas, centradas en la seguridad y autónomas.

Restringido: desconectado

Cuando se opera dentro de un entorno desconectado, el clúster de OpenShift no tiene conexión directa a Internet, ni siquiera a través de un proxy. Todo el contenido esencial para el funcionamiento del entorno debe duplicarse de forma local. La máquina que ejecuta  el conjunto de herramientas oc debe tener acceso a Internet, de forma directa o indirecta a través de un proxy, así como acceso a un registro de imágenes junto con la API de OpenShift.

Imagen 2: Restringido: desconectado

En esta publicación del blog, nos centramos en el método de instalación basada en agentes para redes desconectadas o restringidas, en las cuales la conectividad a Internet es posible a través del host bastión.

Restringido: aislado

Según el documento RFC 4949, un aislamiento se da cuando dos sistemas no están conectados físicamente y no está automatizada ninguna conexión lógica. Los datos se transfieren manualmente con intervención humana.

Imagen 3: Restringido: aislado

En este caso, el clúster de OpenShift no tiene conexión directa a Internet, ni siquiera a través de un proxy. Todo el contenido esencial para el funcionamiento del entorno se duplica de forma local. La máquina que ejecuta la instalación tiene acceso al registro duplicado y a la API de OpenShift, pero NO tiene acceso a Internet de ninguna forma. Todo el contenido debe enviarse en una memoria USB, medios ópticos u otros medios sin conexión a Internet.

Si el host bastión no tiene conexión a Internet, consulte la sección de la documentación oficial a fin de realizar pasos adicionales para duplicar el conjunto de imágenes en el disco y luego duplicar ese archivo en un dispositivo de duplicación. Estas instrucciones no se incluyen en el artículo.

Herramientas que se requieren para realizar una instalación desconectada

Antes de comenzar a utilizar el instalador basado en agentes, analicemos las herramientas necesarias para realizar la instalación desconectada.

Registro duplicado para Red Hat OpenShift

Puede duplicar las imágenes requeridas para respaldar la instalación de OpenShift y las actualizaciones posteriores del producto en un registro duplicado de contenedores que admita Docker v2-2, como Red Hat Quay. Si no tiene acceso a un registro de contenedores de gran tamaño, puede usar el registro duplicado para Red Hat OpenShift, que es uno más pequeño que se incluye con las suscripciones de OpenShift.

Complemento duplicado de OpenShift Client (oc)

El comando oc-mirror es un complemento de la interfaz de línea de comandos (CLI) de OpenShift (oc) que se puede usar para duplicar imágenes. Debe ejecutarlo desde un sistema con conexión a Internet para descargar el contenido que se necesita de la fuente de origen.

Requisitos previos para el registro duplicado

• Una suscripción a OpenShift
• Red Hat Enterprise Linux 8 o 9 con Podman 3.4.2 o las versiones posteriores y la herramienta OpenSSL instalada
• Nombre de dominio completamente calificado para el servicio Red Hat Quay, que debe resolverse a través de un servidor DNS.
• Dos o más vCPU
• 8 GB de RAM
• Aproximadamente 17 GB para las imágenes de OpenShift 4.13 o cerca de 358 GB para las imágenes de OpenShift 4.13 y las de Red Hat Operator de OpenShift 4.13, y se sugiere hasta 1 TB o más para cada flujo (stream).

Tareas de instalación

Una vez que se haya instalado la máquina virtual base de Red Hat Enterprise Linux, descargue estas herramientas en el host bastión:

• Podman 3.4.2 o una versión posterior

$ sudo dnf install -y podman

• OpenShift Client (oc CLI) 

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
$ tar --extract --file openshift-client-linux.tar.gz
$ chmod +x oc
$ sudo mv oc /usr/local/bin/

• Registro duplicado

$ wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
$ tar --extract --file mirror-registry.tar.gz
$ chmod +x mirror-registry

• oc duplicado

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/oc-mirror.tar.gz
$ tar --extract --file oc-mirror.tar.gz
$ chmod +x oc-mirror
$ sudo mv oc-mirror /usr/local/bin/

Instalación del registro duplicado

El registro duplicado se puede instalar con un solo comando:

$ ./mirror-registry install --quayHostname<hostname fqdn> \
--quayRoot /root/ocpmirror

Por ejemplo:

$ sudo mirror-registry install \
--quayHostname bastion.j9287.dynamic.opentlc.com \
--quayRoot /root/ocpmirror

Si el registro duplicado se instaló con éxito, verá un resultado como este:

[...]
INFO[2023-10-31 11:17:28] Quay installed successfully, config data is stored in /root/ocpmirror
INFO[2023-10-31 11:17:28] Quay is available at https://bastion.j9287.dynamic.opentlc.com:8443 with credentials (init, 7HFdq385A9EG0ngVWo4cKeDtxRzp621N)

Compruebe que se pueda acceder al registro duplicado mediante la URL que proporcionaron las credenciales:

$ podman login -u init -p <password generated by installer> \
https://<hostname fqdn>:8443 \
--tls-verify=false

Por ejemplo:

$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \ https://bastion.j9287.dynamic.opentlc.com:8443 \
--tls-verify=false

Debido a que el registro duplicado viene con una autoridad de certificación personalizada, puede exportar esta variable para acceder al registro de forma segura:

$ export SSL_CERT_DIR=/root/ocpmirror/quay-rootCA/
$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \
https://bastion.j9287.dynamic.opentlc.com:8443

Descargue el secreto de extracción de OpenShift de https://console.redhat.com/openshift/downloadsy guarde el archivo con el nombre pull-secret.

Ejecute estos comandos desde su directorio principal para configurar la autenticación del registro:

$ cat pull-secret | jq . > pull-secret.json
$ mkdir .docker ; cp pull-secret.json ~/.docker/config.json
$ echo -n 'init:7HFdq385A9EG0ngVWo4cKeDtxRzp621N' | \
base64 -w0

Con el resultado del comando anterior, ajuste el archivo para incluir la autenticación de duplicación local en ~/.docker/config.json:

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "[email protected]"
 },

A esta altura del proceso, se instala y se configura un registro duplicado. Para obtener más información, consulte la documentación oficial.

Duplicación de imágenes

En esta sección, se usará el complemento oc mirror de la CLI de OpenShift para duplicar el contenido requerido en el registro duplicado.

En un entorno desconectado, puede duplicar un conjunto de imágenes directamente en el registro duplicado de destino.

En un entorno aislado, debe duplicar el conjunto de imágenes en el disco y luego duplicar esto en un dispositivo de duplicación.

Primero, cree un archivo nuevo para ImageSetConfiguration:

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
 registry:
   imageURL: bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata # Local mirror registry URL
   skipTLS: false
mirror:
 platform:
   channels:
   - name: stable-4.13    # Version of OpenShift to be mirrored
     minVersion: 4.13.17  # Minimum version of OpenShift to be mirrored
     maxVersion: 4.13.18  # Maximum version of OpenShift to be mirrored
     shortestPath: true
     type: ocp
   graph: true   # Useful when updating in disconnected setup with OSUS operator
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 # Operators catalog to mirror
 additionalImages:
 - name: registry.redhat.io/ubi8/ubi:latest
 helm: {}

En este repositorio, se ofrece un archivo como ejemplo. Para obtener una lista completa de las opciones para ajustar este archivo según sus necesidades, consulte la documentación oficial.
 

Para este ejemplo, el archivo ImageSetConfiguration usa un backend de almacenamiento de registro (bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata) e incluye todas las versiones de OpenShift a partir de la versión 4.13.17 hasta la más reciente, 4.13.18, que está disponible en el canal. En cada invocación de oc-mirror con esta configuración de conjunto de imágenes, se evalúa la última versión del canal stable-4.13, por lo que ejecutar oc-mirror a intervalos regulares garantiza que reciba automáticamente las últimas versiones de Imágenes de OpenShift.

Una vez que el archivo ImageSetConfiguration esté listo, ejecute el siguiente comando para duplicar el contenido en el registro. El tiempo que se requiere para este proceso varía según su configuración y la velocidad de conexión.

$ oc mirror --config=imageset-config.yaml \
docker://<hostname fqdn>:8443 

Por ejemplo:

$ oc mirror --config=imageset-config.yaml \  docker://bastion.j9287.dynamic.opentlc.com:8443

Los parámetros opcionales --continue-on-error y --skip-missing pueden ser útiles si necesita ignorar los errores.

Una ejecución exitosa del comando anterior muestra un resultado como este:

[...]
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.17-x86_64
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.18-x86_64
Writing image mapping to oc-mirror-workspace/results-1698872844/mapping.txt
Writing UpdateService manifests to oc-mirror-workspace/results-1698872844
Writing CatalogSource manifests to oc-mirror-workspace/results-1698872844
Writing ICSP manifests to oc-mirror-workspace/results-1698872844

Algunos archivos se generan con oc-mirror, como updateService:

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

El archivo ImageContentSourcePolicy:

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
 name: release-0
spec:
 repositoryDigestMirrors:
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

Y, por último, CatalogSource:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc

Estos archivos se utilizarán más adelante para configurar el registro duplicado para la instalación y para indicar a los operadores y al servicio de actualización que usen el registro local.

También puede explorar https://:8443 para iniciar sesión en la interfaz de usuario del registro duplicado.

Instalación basada en agentes

Una vez instalado y configurado el registro duplicado local, podemos analizar la instalación de OpenShift mediante el instalador basado en agentes. En el momento de la redacción, este instalador admite las siguientes plataformas:

• Servidor dedicado (bare metal)
• vSphere
• Ninguna

La instalación basada en agentes utiliza una ISO de arranque que contiene el agente de descubrimiento asistido y el servicio asistido. Ambos son necesarios para llevar a cabo la instalación del clúster, pero el último se ejecuta solo en uno de los hosts. El subcomando openshift-install agent create image genera una ISO efímera que se basa en las entradas que proporcione.

En el archivo install-config.yaml , debe incluir el secreto de extracción, el conjunto de confianza de certificado adicional del registro duplicado local y el archivo ImageContentSources que señala la duplicación local.

En el archivo agent-config.yaml , debe incluir el parámetro "rendezvousIP", que es la dirección IP del host que se convertirá en el nodo de arranque temporal durante la instalación. Esta dirección IP debe coincidir con uno de los nodos.

Para obtener una lista completa de los pasos de preparación de la instalación con el instalador basado en agentes, consulte este enlace. Puede encontrar un ejemplo de install-config.yaml y de agent-config.yaml en este repositorio.

Creación de la ISO

Después de ajustar los archivos install-config.yaml y agent-config.yaml, debe crear la imagen ISO.

Primero, instale el paquete nmstate:

$ sudo dnf install /usr/bin/nmstatectl

Luego, descargue el instalador de OpenShift. La versión de este instalador debe descargarse para que coincida con la versión del clúster que desea instalar. En este caso, usaremos Openshift 4.13.17, por lo que primero se instalará y después actualizaremos el clúster a la versión 4.13.18.

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.13.17/openshift-install-linux.tar.gz
$ tar --extract --file openshift-install-linux.tar.gz
$ chmod +x openshift-install
$ sudo mv openshift-install /usr/local/bin/

Por último, cree la ISO:

$ openshift-install agent create image --dir <directory>

Aparecerá un resultado similar al este:

INFO Configuration has 3 master replicas and 3 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.94.21
INFO Extracting base ISO from release payload    
INFO Base ISO obtained from release and cached at [/root/.cache/agent/image_cache/coreos-x86_64.iso]
INFO Consuming Install Config from target directory
INFO Consuming Agent Config from target directory

Debe preparar los nodos de servidor dedicado (bare metal) o de máquina virtual para el plano de control y los nodos informáticos en función de la plataforma que utilice. Asegúrese de que todos los nodos del clúster se inicien desde la imagen ISO que generó.

Creación de los registros DNS

Debe crear los registros para dos direcciones IP estáticas en DNS. En cada uno, se especifica <cluster_name> el nombre y <base_domain> es el dominio base cuando instala el clúster. Un registro DNS completo tiene esta forma: <component>.<cluster_name>.<base_domain>

Dirección IP virtual de API: api.<cluster_name>.<base_domain>

Dirección IP virtual de entrada: *.apps.<cluster_name>.<base_domain>

Creación de clústeres de OpenShift

Deberá arrancar la imagen ISO en cada host del clúster, que incluye a los medios virtuales, el USB de arranque y el DVD.

Configure los nodos para que arranquen desde la imagen ISO que creó. Después de esto, puede controlar la instalación con el siguiente comando:

$ openshift-install agent wait-for bootstrap-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is ready for install                
INFO Cluster validation: All hosts in the cluster are ready to install.
INFO Preparing cluster for installation
INFO Cluster installation in progress
INFO Bootstrap configMap status is complete      
INFO cluster bootstrap is complete

Una vez que se completa el proceso, puede ejecutar este comando para supervisar el progreso.

$ openshift-install agent wait-for install-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is installed                        
INFO Install complete!                           
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/root/auth/kubeconfig 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.j9287.dynamic.opentlc.com
INFO Login to the console with user: "kubeadmin", and password: "HR377-xxxxx-yyyyy-ynxGC"

Cuando reciba el mensaje de que la instalación se completó, puede iniciar sesión en el clúster con el comando oc y comprobar la versión del clúster de OpenShift.

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        False         11m     Cluster version is 4.13.17

Para obtener más información sobre el instalador basado en agentes, consulte la documentación oficial de OpenShift.

Puede comprobar el archivo ImageContentSourcePolicy para confirmar que el clúster de OpenShift está recibiendo las imágenes desde el registro duplicado local:

$ oc get imagecontentsourcepolicy
NAME             AGE
image-policy-0   18h
image-policy-1   18h
$ oc describe imagecontentsourcepolicy image-policy-0 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   Source:  quay.io/openshift-release-dev/ocp-v4.0-art-dev
$ oc describe imagecontentsourcepolicy image-policy-1 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   Source:  quay.io/openshift-release-dev/ocp-release

Debe realizar una configuración adicional para eliminar todas las fuentes de catálogo predeterminadas, ya que su clúster no está conectado a Internet. Ejecute estos comandos para aplicar parches en el recurso OperatorHub para deshabilitar los archivos CatalogSourcespredeterminados:

$ oc get catsrc -A
NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     32m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     32m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     32m
openshift-marketplace   redhat-operators      Red Hat Operators     grpc   Red Hat     32m
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
operatorhub.config.openshift.io/cluster patched
$ oc get catsrc -A
No resources found

Cree un nuevo recurso CatalogSource que señale al registro duplicado local mediante la aplicación de CatalogSource.yaml desde la sección anterior.

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc
 
$ oc apply -f ./oc-mirror-workspace/results-1698872844/

$ oc apply -f ./oc-mirror-workspace/results-1698872844/release-signatures/

Una vez que se aplique, vuelva a realizar los pasos de verificación que se indicaron anteriormente:

$ oc get po -n openshift-marketplace
NAME                                    READY   STATUS    RESTARTS   AGE
marketplace-operator-7bc7549555-4ckdm   1/1     Running   0          48m
redhat-operator-index-t4cgd             1/1     Running   0          75s

$ oc get catsrc -A
NAMESPACE               NAME                    DISPLAY   TYPE   PUBLISHER   AGE
openshift-marketplace   redhat-operator-index             grpc               82s

A esta altura del proceso, esto es lo que se ha llevado a cabo:

• Implementación de un clúster nuevo de OpenShift con el método de instalación basada en agentes
• Extracción de las imágenes de instalación desde el registro duplicado local en lugar de Internet
• Configuración de OperatorHub para usar el registro duplicado local

Actualizaciones de OpenShift en entornos desconectados

En la primera parte de la publicación del blog, duplicamos un registro local con dos versiones de OpenShift: 4.13.17 y 4.13.18 (consulte el contenido del archivo ImageSetConfiguration ). Para los clústeres con acceso a Internet, Red Hat proporciona actualizaciones inalámbricas con OpenShift Update Service (OSUS) como un servicio alojado que se ubica detrás de las API públicas, pero para este ejemplo nos centramos en el modo desconectado. En la guía para la actualización de OpenShift para la administración de clústeres, se ofrece información más detallada sobre OSUS.

Hay dos métodos para actualizar OpenShift en entornos desconectados o aislados: sin el operador de OpenShift Update Service o con el operador de OpenShift Update Service.

Sin el operador de OpenShift Update Service

Primero, veamos la opción más sencilla para actualizar el clúster de OpenShift desde la versión 4.13.17 a 4.13.18. Ejecute estos comandos desde una computadora portátil o un sistema con el comando oc disponible que tenga una conexión a Internet activa:

$ export OCP_RELEASE_VERSION=4.13.18
$ export ARCHITECTURE=x86_64
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c

Utilice el resultado del comando anterior para actualizar el clúster de OpenShift desde el nodo bastión con el cual puede acceder él:

$ oc adm upgrade --allow-explicit-upgrade \
--to-image quay.io/openshift-release-dev/ocp-release@sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c
Requested update to 4.13.18

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        True          78m     Working towards 4.13.18: 106 of 843 done (12% complete), waiting up to 40 minutes on etcd, kube-apiserver

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.18   True        False         5m25s   Cluster version is 4.13.18

Para obtener más información sobre la actualización de OpenShift, consulte la documentación oficial.

Con el operador de OpenShift Update Service

Para usar el operador de OSUS, debe configurar el acceso a un registro protegido, siempre y cuando el registro sea distinto al que se usa para la instalación. Este método no aplica para lo que se describe en este artículo, ya que usamos un registro duplicado local.

También debe actualizar el secreto de extracción del clúster global para acceder a su registro duplicado, si es diferente al que se usa para la instalación. Este método no aplica para lo que se describe en este artículo, ya que usamos un registro duplicado local.

Para usar OSUS, primero debe instalar el operador desde OperatorHub.

Luego, cree una imagen de contenedor de datos de gráficos para OpenShift Update Service. Este paso no es necesario para el ejemplo que se muestra en este artículo, ya que utilizamos oc mirror para duplicar las imágenes e incluimos graph: true en el archivo ImageSetConfiguration durante la duplicación.

Una vez hecho esto, instale la aplicación OSUS y configure los clústeres para usar el servicio OpenShift Update Service local. Utilice el archivo UpdateService.yaml para realizar la configuración necesaria. Por ejemplo:

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

Una vez que se instaló la aplicación OSUS, ejecute estos comandos para que el Cluster Version Operator (CVO) extraiga los datos de gráfico del OSUS que se instaló de manera local en vez de hacerlo de Internet.

$ export NAMESPACE=openshift-update-service
$ export NAME=update-service-oc-mirror
$ export POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
$ export PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
$ oc patch clusterversion version -p $PATCH --type merge

Si la ejecución del comando oc adm upgrade arroja errores de certificado, asegúrese de haber habilitado un proxy para todo el clúster y configure la autoridad de certificación para que confíe en el servidor de actualización.

Por último, realice el procedimiento de actualización como se describe en la sección anterior. Consulte la documentación para obtener más información sobre el operador de OpenShift Update Service.

Reflexiones finales

En esta publicación del blog, se brindaron instrucciones detalladas sobre la forma de usar herramientas, como el registro duplicado y oc mirror, para configurar un repositorio local para instalaciones desconectadas o aisladas. Con este conocimiento, un administrador de OpenShift puede usar imágenes duplicadas de forma local no solo para  instalar un clúster de OpenShift, sino también para implementar actualizaciones y mejoras.