Mais segurança para o futuro: como navegar pelas instalações desconectadas do Red Hat OpenShift com o instalador baseado em agente

No cenário digital atual, a confiabilidade e a conformidade com a segurança são extremamente importantes. Para uma organização que lida com conectividade de Internet restrita ou desfavorável, a escolha de uma instalação padrão do Red Hat OpenShift e uma instalação desconectada, ou com isolamento, pode fazer toda a diferença. Uma instalação desconectada permite que as empresas estabeleçam e mantenham clusters do OpenShift em ambientes isolados, com foco na segurança e independentes, garantindo a infraestrutura robusta necessária para o sucesso em um mundo cada vez mais complexo.

Neste artigo, exploramos os benefícios e as principais considerações desse paradigma essencial de implantação e operação.

Métodos de instalação

Primeiro, analisaremos cada um dos métodos de instalação disponíveis para clusters do OpenShift autogerenciados.

Imagem 1: diferentes métodos de instalação

Infraestrutura provisionada pelo instalador (IPI)

O método de instalação IPI é um dos mais diretos. Ele é adequado para usuários que desejam uma experiência de instalação guiada e automatizada. No IPI, o OpenShift provisiona a infraestrutura, incluindo máquinas virtuais ou hardware físico. Normalmente, é usado com provedores de nuvem, mas também pode ser usado para instalações on-premise.

Assisted Installer (AI)

O Assisted Installer é uma ferramenta online interativa que realiza instalações do OpenShift. Essa é uma abordagem ideal para clusters com redes conectadas à Internet. Ele também fornece uma API RESTful para cenários avançados de automação e configuração. O AI também faz parte do Red Hat Advanced Cluster Management.

Instalador baseado em agente (ABI)

A instalação baseada em agente compreende uma ISO inicializável que contém o agente de detecção assistida e o serviço assistido. A instalação baseada em agente é um subcomando do instalador do OpenShift. Ela gera uma imagem ISO inicializável contendo todos os ativos necessários para implantar um cluster do OpenShift, com uma imagem de versão do OpenShift disponível. Essa abordagem é ideal para ambientes restritos, desconectados ou com isolamento.

Infraestrutura provisionada pelo usuário (UPI)

A UPI é um método de instalação flexível para usuários que preferem gerenciar sua própria infraestrutura, seja on-premise, em seus próprios data centers ou em provedores de nuvem pública. Com a UPI, os usuários são responsáveis pelo provisionamento de máquinas virtuais, armazenamento e componentes de rede, como um balanceador de carga. Depois que a infraestrutura for provisionada, o instalador pode ser usado para implantar o OpenShift na infraestrutura desejada.

Hosted Control Plane (HCP)

Os clusters do OpenShift podem ser implantados usando duas configurações de control planes diferentes: autônomos ou hospedados. A configuração autônoma usa máquinas virtuais ou físicas dedicadas para hospedar o control plane. Com os control planes hospedados para o OpenShift, você cria control planes como pods em um cluster de hospedagem sem a necessidade de máquinas virtuais ou físicas dedicadas para cada um deles. Consulte a documentação oficial e este artigo para obter mais informações.

O que é uma instalação desconectada?

Há diferentes tipos de instalação para diferentes cenários. É importante selecionar o método correto para seu caso de uso. Uma instalação desconectada do OpenShift é uma solução crucial para organizações e ambientes onde a conformidade, o controle e a confiabilidade da segurança são fundamentais e onde a conectividade direta com a Internet é restrita ou indesejável. Ela fornece a infraestrutura necessária para gerenciar e manter clusters do OpenShift em redes isoladas, com foco na segurança e independentes.

Restrita: desconectada

Ao operar em um ambiente desconectado, o cluster do OpenShift não tem conexão direta com a Internet, nem mesmo por meio de um proxy. Todo o conteúdo necessário de suporte ao ambiente deve ser espelhado localmente. A máquina que executa o conjunto de ferramentas oc deve ter acesso à Internet, direta ou indiretamente por um proxy, bem como acesso a um registro de imagens com a API do OpenShift.

Imagem 2: restrita – desconectada

Neste blog, nosso foco é a instalação baseada em agente para redes desconectadas/restritas, onde a conectividade com a Internet é possibilitada por meio do bastion host.

Restrita: isolada

De acordo com o RFC 4949, um "isolamento" ocorre quando dois sistemas não estão conectados fisicamente e nenhuma conexão lógica é automatizada. Os dados são transferidos manualmente por intervenção humana.

Imagem 3: restrita – isolada

Nesse caso, o cluster do OpenShift não tem conexão direta com a Internet, nem mesmo por meio de um proxy. Todo o conteúdo de suporte necessário ao ambiente é espelhado localmente. A máquina que executa a instalação tem acesso ao mirror registry e à API do OpenShift, mas não à Internet. Todo o conteúdo deve ser enviado em um pen drive, mídia ótica ou por outros meios "offline".

Se o bastion host não tiver uma conexão com a Internet, consulte esta seção da documentação oficial e siga as etapas adicionais para espelhar as imagens no disco. Depois, espelhe o arquivo das imagens no disco para um espelho que está além do escopo deste artigo.

Ferramentas necessárias para realizar uma instalação desconectada

Antes de começar a instalação real usando o instalador baseado em agente, vamos falar sobre as ferramentas necessárias para realizar uma instalação desconectada.

Mirror registry para o Red Hat OpenShift

Você pode espelhar as imagens necessárias para dar suporte à instalação do OpenShift e às atualizações subsequentes de soluções em um mirror registry de container que tenha suporte para Docker v2-2, como o Red Hat Quay. Se não tiver acesso a um registro de containers em grande escala, você pode usar o mirror registry para o Red Hat OpenShift, que é um registro de containers em pequena escala incluído nas subscrições do OpenShift.

Plugin de espelho do OpenShift Client (oc)

O comando oc-mirror é um plugin da interface de linha de comando (CLI) do OpenShift (oc) que pode ser usado para espelhar imagens. Você deve executar o oc-mirror em um sistema com conexão à Internet para fazer download do conteúdo necessário direto da fonte de origem.

Pré-requisitos para mirror registry

• Uma subscrição do OpenShift.
• Red Hat Enterprise Linux (RHEL) 8 ou 9 com Podman 3.4.2 ou superior e OpenSSL instalado.
• Nome de domínio totalmente qualificado para o serviço do Red Hat Quay, que deve ser resolvido por um servidor DNS.
• Dois ou mais vCPUs.
• 8 GB de RAM.
• Cerca de 17 GB para imagens de versão do OpenShift 4.13 ou cerca de 358 GB para imagens de versão do OpenShift 4.13 e imagens do Red Hat Operator para o OpenShift 4.13. Sugerimos até 1 TB ou mais para cada fluxo.

Tarefas de instalação

Assim que a VM do RHEL base for instalada, faça o download das seguintes ferramentas no bastion host:

• Podman 3.4.2 ou superior

$ sudo dnf install -y podman

• OpenShift Client (CLI oc) 

$ 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/

• Mirror registry

$ 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 mirror

$ 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/

Instalação do mirror registry

O mirror registry pode ser instalado com um único comando:

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

Por exemplo:

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

Uma instalação bem-sucedida do mirror registry retorna uma saída como esta:

[...]
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)

Verifique se o mirror registry pode ser acessado usando a URL fornecida pelas credenciais:

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

Por exemplo:

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

Como o mirror registry acompanha uma CA personalizada, você pode exportar a variável abaixo para acessar o registro com segurança:

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

Faça download do seu segredo de pull do OpenShift em https://console.redhat.com/openshift/downloads e salve o arquivo baixado como pull-secret.

Execute os comandos abaixo do seu diretório pessoal para configurar a autenticação do registro:

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

Usando a saída do comando anterior, ajuste o arquivo para incluir a autenticação de espelho local em ~/.docker/config.json:

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

Nesse ponto, um mirror registry é instalado e configurado. Para obter mais informações, consulte a  documentação oficial.

Espelhamento de imagens

Nesta seção, o plugin  oc mirror da CLI do OpenShift será usado para espelhar o conteúdo exigido para o mirror registry.

Em um ambiente desconectado, você pode espelhar um conjunto de imagens diretamente no mirror registry desejado.

Em um ambiente com isolamento, você precisa primeiro espelhar as imagens no disco e, depois, espelhar o arquivo das imagens no disco para um espelho.

Primeiro, crie um novo arquivo 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: {}

Um arquivo de amostra foi fornecido neste repositório. Para obter uma lista completa de opções para ajustar o arquivo de acordo com suas necessidades, consulte a documentação oficial.
 

Neste exemplo, o arquivo ImageSetConfiguration usa um back-end de armazenamento de registro (bastion.j9287.dynamic.ocentlc.com:8443/mirror/oc-mirror-metadata) e inclui todas as versões do OpenShift a partir de uma versão mínima de 4.13.17 até a mais recente no canal 4.13.18. A cada invocação do oc-mirror com essa configuração de conjunto de imagens, a versão mais recente do canal stable-4.13 é avaliada. Portanto, executar o oc-mirror em intervalos regulares garante que você receba automaticamente as versões mais recentes de imagens do OpenShift.

Quando o arquivo ImageSetConfiguration estiver pronto, execute o comando a seguir para espelhar o conteúdo para o registro. O tempo necessário para o processo de espelhamento varia dependendo da sua configuração e velocidade de conexão.

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

Por exemplo:

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

Os parâmetros opcionais --continue-on-error e --skip-missing podem ser úteis se você precisar ignorar erros.

Uma execução bem-sucedida do comando anterior exibe uma saída como esta:

[...]
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

Alguns arquivos são gerados pelo oc-mirror. Isso inclui o 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

O arquivo 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

E, finalmente, 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

Esses arquivos serão necessários posteriormente para configurar o mirror registry para instalação e direcionar os operadores e o serviço de atualização para usar o registro local.

Você também pode navegar até https://:8443 para acessar a interface de usuário do mirror registry.

Instalação baseada em agente

Com o mirror registry local instalado e configurado, podemos pensar na instalação do OpenShift usando o instalador baseado em agente. Até o momento em que este material foi escrito, o instalador baseado em agente era compatível com as seguintes plataformas:

• Bare metal
• vSphere
• nenhuma

A instalação baseada em agente usa uma ISO inicializável que contém o agente de descoberta assistida e o serviço assistido. Os dois são necessários para realizar a instalação do cluster, mas este último funciona em apenas um dos hosts. O subcomando openshift-install agent create image gera uma ISO efêmera com base nas entradas que você fornece.

No arquivo install-config.yaml , você deve incluir o segredo de pull e o pacote de confiança de certificado adicional do mirror registry local e o ImageContentSources apontando para o espelho local.

No arquivo agent-config.yaml , você deve incluir o parâmetro "rendezvousIP", que é o endereço IP do host que se tornará o nó de bootstrap temporário durante a instalação. O endereço IP precisa corresponder a um dos nós.

Para obter uma lista completa das etapas de preparação da instalação usando o instalador baseado em agente, clique neste link. Uma amostra de install-config.yaml e agent-config.yaml pode ser encontrada neste repositório.

Criação da ISO

Depois de ajustar os arquivos install-config.yaml e agent-config.yaml, é hora de criar a imagem ISO.

Primeiro, instale o pacote nmstate:

$ sudo dnf install /usr/bin/nmstatectl

Em seguida, faça o download do instalador do OpenShift. A versão do instalador precisa ser baixada para corresponder à versão do cluster que você planeja instalar. Neste artigo, estamos usando o OpenShift 4.13.17, então vamos instalá-lo primeiro e, depois, atualizar o cluster para 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 fim, crie a ISO:

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

Você verá uma saída semelhante a esta:

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

Dependendo da sua plataforma, você deve preparar os nós (baremetal ou VM) para o control plane e os nós de computação. Verifique se todos os nós do cluster estão sendo inicializados a partir da imagem ISO gerada.

Criação dos registros DNS

Você deve criar registros DNS para dois endereços IP estáticos no DNS. Em cada registro, <cluster_name> é o nome do cluster e <base_domain> é o domínio de base do cluster que você especifica ao instalar o cluster. Um registro DNS completo tem o formato: <component>.<cluster_name>.<base_domain>

VIP de API - api.<cluster_name>.<base_domain>

VIP de entrada - *.apps.<cluster_name>.<base_domain>

Criação de clusters do OpenShift

Você inicializará a imagem ISO em cada host do cluster, incluindo sua mídia virtual, USB inicializável e DVD.

Configure os nós para inicializar a partir da imagem ISO que você criou. Depois que todos os nós tiverem sido inicializados a partir da imagem ISO, você poderá monitorar a instalação usando o comando abaixo:

$ 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

Quando o processo de bootstrap for concluído, você poderá executar o comando a seguir para monitorar o progresso.

$ 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"

Depois de receber a mensagem de que a instalação foi concluída, você pode fazer login no cluster usando o comando oc e verificar a versão do cluster do OpenShift.

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

Para obter mais detalhes sobre o instalador baseado em agente, consulte a documentação oficial do OpenShift.

Você pode verificar a ImageContentSourcePolicy para confirmar se o cluster do OpenShift está recebendo imagens do mirror registry 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

Você precisa executar algumas configurações extras para remover todas as fontes de catálogo padrão, já que seu cluster não está conectado à Internet. Execute os comandos a seguir para aplicar patches no recurso OperatorHub e desabilitar o padrão CatalogSources:

$ 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

Crie um novo recurso CatalogSource apontando para o mirror registry local ao aplicar o CatalogSource.yaml da seção de espelhamento de imagens acima.

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/

Depois da aplicação, execute novamente as etapas de verificação tentadas 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

Neste ponto, os itens a seguir foram concluídos:

• Um novo cluster do OpenShift foi instalado usando o método de instalação baseada em agente.
• As imagens de instalação foram extraídas do mirror registry local em vez da Internet.
• O Operator Hub foi configurado para usar o mirror registry local.

Atualizações do OpenShift em ambientes desconectados

Na primeira parte do blog, espelhamos um registro local com duas versões do OpenShift 4.13.17 e 4.13.18 (consulte o conteúdo do arquivo ImageSetConfiguration ). Para clusters com acesso à Internet, a Red Hat oferece atualizações over-the-air (OTA) usando um OpenShift Update Service (OSUS) como um serviço hospedado localizado atrás de APIs públicas, mas, neste exemplo, nosso foco é o modo desconectado. O OSUS foi abordado em mais detalhes neste Guia de atualização do OpenShift para administração de clusters.

Há duas maneiras de atualizar o OpenShift em ambientes desconectados/com isolamento: sem o OpenShift Update Service Operator (OSUS) ou com o OpenShift Update Service Operator (OSUS).

Sem o OpenShift Update Service Operator (OSUS)

Primeiro, vejamos a opção mais simples de atualizar o cluster do OpenShift de 4.13.17 para 4.13.18. Execute os comandos abaixo em um notebook ou sistema com o comando oc disponível e que tenha uma conexão ativa de Internet:

$ 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

Pegue a saída do comando anterior e use-a para realizar o upgrade do cluster do OpenShift a partir do nó de bastion onde é possível acessar o OpenShift Cluster:

$ 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 obter mais informações sobre como atualizar o OpenShift, consulte a documentação oficial.

Com o OpenShift Update Service Operator (OSUS)

Para usar o OpenShift Update Service Operator (OSUS), você precisa configurar o acesso a um registro protegido, se o registro for diferente do usado para a instalação. Isso não se aplica a este artigo, porque usamos um mirror registry local.

Você também deve atualizar o segredo de pull do cluster global para acessar seu mirror registry se o registro for diferente daquele usado para a instalação. Isso não se aplica a este artigo, porque usamos um mirror registry local.

Para usar o OSUS, você deve primeiro instalar o OSUS Operator a partir do Operator Hub.

Em seguida, crie uma imagem de container de dados gráficos para o OpenShift Update Service. Essa etapa não é necessária no exemplo deste artigo, já que ele usou o oc mirror para espelhar as imagens e incluiu graph: true no arquivo ImageSetConfiguration durante o espelhamento.

Depois disso, instale a aplicação do OSUS e configure seus clusters para usar o OpenShift Update Service local. Use UpdateService.yaml para aplicar a configuração necessária. Por exemplo:

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

Depois que a aplicação OSUS estiver instalada, execute os comandos a seguir para fazer com que o CVO (Cluster Version Operator) extraia os dados gráficos do OSUS instalado localmente em vez da 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

Se erros de certificado retornarem ao executar o comando oc adm upgrade, verifique se você ativou um proxy em todo o cluster e configurou a CA para confiar no servidor de atualização.

Por fim, execute o procedimento de atualização conforme descrito na seção anterior. Consulte a documentação para saber mais sobre o OpenShift Update Service Operator.

Considerações finais

Este blog fornece instruções detalhadas sobre como usar ferramentas como o mirror registry e oc mirror para configurar um repositório local para instalações desconectadas/com isolamento. Com esse conhecimento, um administrador do OpenShift pode usar imagens espelhadas localmente não apenas para instalar  um cluster do OpenShift, mas também para realizar upgrades e atualizações.