Etapas para atualizar o cluster mestre

Antes de começar, certifique-se de que você tenha o Operador ou função de acesso à plataforma de IAM do Administrador. Se você não tiver certeza de qual é a sua função de acesso, acesse Gerenciar → Acesso (IAM) → Usuários no console do IBM Cloud ou pergunte ao administrador da sua conta.

Se estiver em andamento uma rotação de certificados de uma autoridade certificadora (CA), a atualização principal fica bloqueada até que a rotação seja concluída. Verifique o status de qualquer rotação em andamento antes de começar.

Para atualizar a versão principal or secundária do Red Hat OpenShift mestre:

1. Revise as informações da versão do Red Hat OpenShift on IBM Cloud e faça quaisquer atualizações marcadas com Atualizar antes do principal.

2. Revise os Avisos úteis do Kubernetes, como avisos de descontinuação.

3. Verifique os complementos e plug-ins instalados em seu cluster para obter qualquer impacto que possa ser causado pela atualização da versão do cluster.

   • Verificando complementos

     1. Liste os complementos no cluster.

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. Verifique a versão do Red Hat OpenShift suportada para cada complemento que está instalado.

        ibmcloud oc addon-versions
        

     3. Se o complemento precisar ser atualizado para execução na versão do Red Hat OpenShift para a qual você deseja atualizar seu cluster, faça isso.

   • Verificando plug-ins

     1. No Catálogo do Helm, localize os plug-ins que você instalou no cluster.
     2. No menu lateral, expanda a seção Fontes e arquivo tar.
     3. Faça download e abra o código-fonte.
     4. Verifique os arquivos README.md ou RELEASENOTES.md para as versões suportadas.
     5. Se o plug-in precisar ser atualizado para execução na versão do Red Hat OpenShift para a qual você deseja atualizar seu cluster, atualize-o seguindo as instruções dele.

4. Atualize seu servidor de API e os componentes principais associados usando o console IBM Cloud ou executando o comando da CLI ibmcloud oc cluster master update.

5. Aguarde alguns minutos e, em seguida, confirme se a atualização está concluída. Revise a versão do servidor de API no painel de clusters do IBM Cloud ou execute ibmcloud oc cluster ls.

6. Instale a versão do oc cli que corresponde à versão do servidor da API que é executada no mestre. Kubernetes não é compatível com versões do cliente d oc que tenham uma diferença de duas ou mais versões em relação à versão do servidor (n ± 2). Para atualizar sua configuração local, execute ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID e, em seguida, verifique com oc version --client.

Quando a atualização do nó mestre estiver concluída, atualize seus nós de trabalho. O método depende do tipo de infraestrutura que você possui:

1. Atualização de nós de trabalho clássicos — utiliza uma atualização gradual controlada por um arquivo de atualização ( ConfigMap ) e pelo comando worker update .
2. Atualização dos nós de trabalho da VPC — Os nós de trabalho bare metal da VPC são atualizados no próprio ambiente usando worker reload; os nós de trabalho VSI da VPC devem usar worker replace --update. O procedimento de atualização contínua do ConfigMap ainda não é compatível com nós de trabalho da VPC.

Pré-requisitos

Antes de atualizar os nós de trabalho da sua infraestrutura clássica, execute as etapas pré-requisitos a seguir.

Durante uma atualização do nó de trabalho, o sistema operacional da máquina do nó de trabalho é reinstalado e todos os dados que não estiverem armazenados no armazenamento persistente são excluídos permanentemente. Verifique se todos os dados que você precisa manter estão armazenados fora do nó de trabalho antes de começar.

Se você tiver o Portworx instalado no seu cluster, é necessário atualizar a configuração do Portworx antes de atualizar os nós de trabalho.

Atualizando nós do trabalhador clássicos na CLI com um configmap

Use um “ ConfigMap ” para realizar uma atualização gradual dos seus nós de trabalho clássicos. O “ ConfigMap ” permite controlar quantos nós podem ficar indisponíveis ao mesmo tempo, por zona ou região. Se a regra padrão de indisponibilidade de 20% for aceitável para o seu cluster, você pode pular as etapas 3 e 4 (criação de ConfigMap ) e prosseguir diretamente para a etapa 5 para aplicar a atualização usando o comportamento padrão.

1. Conclua as etapas de pré-requisito.

2. Liste os nós do trabalhador disponíveis e anote o seu endereço IP privado.

   ibmcloud oc worker ls --cluster CLUSTER
   

3. Visualizar os rótulos de um nó do trabalhador. É possível localizar os rótulos de nó do trabalhador na seção Rótulos de sua saída da CLI. Cada rótulo consiste em um NodeSelectorKey e um NodeSelectorValue.

   oc describe node PRIVATE-WORKER-IP
   

   Exemplo de saída

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. Crie um mapa de configuração e defina as regras de indisponibilidade para seus nós do trabalhador. O ConfigMap suporta até 15 verificações nomeadas. Cada verificação tem como alvo um conjunto de nós de trabalho por meio de um rótulo e define a porcentagem máxima desses nós que podem ficar indisponíveis ao mesmo tempo. O exemplo a seguir mostra uma verificação de zona (zonecheck.json), uma verificação de região (regioncheck.json), uma verificação de alternativa padrão (defaultcheck.json) e um modelo para verificações personalizadas. Para cada verificação, escolha um dos rótulos dos nós de trabalho que você recuperou na etapa anterior para identificar os nós de destino.

   Para cada verificação, é possível configurar somente um valor para NodeSelectorKey e NodeSelectorValue. Para configurar regras para mais de uma região, zona ou outros rótulos de nó do trabalhador, crie uma nova verificação. Defina até 15 verificações em um mapa de configuração. Se você incluir mais verificações, apenas um nó do trabalhador será recarregado por vez até que todos os trabalhadores solicitados sejam atualizados.

   Exemplo

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   Opcional: o tempo limite em segundos para esperar a conclusão do dreno. A drenagem de um nó do trabalhador remove com segurança todos os pods existentes do nó do trabalhador e reagenda os pods em outros nós do trabalhador no cluster. Os valores aceitos são números inteiros no intervalo de 1 a 180. O valor padrão é 30.

   zonecheck.json e regioncheck.json

   Duas verificações que definem uma regra para um conjunto de nós do trabalhador que você pode identificar com o NodeSelectorKey especificado e NodeSelectorValue. O zonecheck.json identifica nós do trabalhador com base no rótulo de zona e o regioncheck.json usa o rótulo de região que é incluído em cada nó do trabalhador durante o fornecimento. No exemplo, 30% de todos os nós do trabalhador que têm dal13 como rótulo de zona e 20% de todos os nós do trabalhador em us-south podem ficar indisponíveis durante a atualização.

   defaultcheck.json

   Se você não criar um mapa de configuração ou se o mapa estiver configurado incorretamente, o padrão Kubernetes será aplicado. Por padrão, somente 20% dos nós do trabalhador no cluster podem estar indisponíveis de cada vez. É possível substituir o valor padrão, incluindo a verificação padrão em seu mapa de configuração. No exemplo, todo nó do trabalhador que não é especificado nas verificações de zona e região (dal13 ou us-south) pode ficar indisponível durante a atualização.

   MaxUnavailablePercentage

   O número máximo de nós que podem ficar indisponíveis para uma chave e um valor de rótulo especificados, que são especificados como uma porcentagem. Um nó do trabalhador está indisponível durante o processo de implementação, recarregamento ou provisionamento. Os nós do trabalhador enfileirados são bloqueados de atualização se excedem qualquer porcentagem máxima indisponível definida.

   NodeSelectorKey

   A chave de rótulo do nó do trabalhador para o qual você deseja configurar uma regra. É possível configurar regras para os rótulos padrão que são fornecidos pela IBM, bem como nos rótulos de nó do trabalhador que você criou. Se quiser incluir uma regra para nós do trabalhador que pertencem a um conjunto de trabalhadores, será possível usar o rótulo ibm-cloud.kubernetes.io/machine-type.

   NodeSelectorValue

   O valor do rótulo que o nó do trabalhador deve ter para ser considerado para a regra que você define.

5. Crie o mapa de configuração em seu cluster.

   oc apply -f <filepath/configmap.yaml>
   

6. Verifique se o mapa de configuração foi criado.

   oc get configmap --namespace kube-system
   

7. Atualize os nós do trabalhador.

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. Opcional: verifique os eventos que são acionados pelo mapa de configuração e quaisquer erros de validação que ocorrem. Os eventos podem ser revisados na seção Eventos de sua saída da CLI.

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. Confirme se a atualização está concluída, revisando a versão do Kubernetes de seus nós do trabalhador.

   oc get nodes
   

10. Verifique se você não tem nós de trabalhador duplicados. Às vezes, clusters mais antigos listam nós de trabalho duplicados com um NotReady status após uma atualização. Para remover duplicatas, consulte Resolução de problemas.

Atualizando nós do trabalhador clássicos no console

Depois de configurar o ConfigMap pela primeira vez, você poderá atualizar os nós de trabalho usando o console IBM Cloud. O console respeita as regras de indisponibilidade que você definiu no ConfigMap.

1. Conclua as etapas pré-requisitos e [configure um ConfigMap](#worker-up-configmap) para controlar como seus nós de trabalho são atualizados.
2. No menu do console IBM Cloud , clique em Contêineres > Clusters.
3. Na página Clusters, clique em seu cluster.
4. Na guia Nós do trabalhador, selecione a caixa de seleção para cada nó do trabalhador que você deseja atualizar. Uma barra de ação é exibida sobre a linha de cabeçalho da tabela.
5. Na barra de ação, clique em Atualizar.

Se você tiver o Portworx instalado no seu cluster, será necessário reiniciar os pods Portworx nos nós de trabalho atualizados. Para obter mais informações, consulte Limitações do Portworx.

Pré-requisitos

Antes de atualizar os nós de trabalho da infraestrutura da sua VPC, execute as etapas pré-requisitos a seguir.

Para os trabalhadores do VPC VSI, o nó de trabalho é excluído e substituído por um novo nó. Para os usuários de bare metal do VPC, o nó é recarregado no próprio local. Em ambos os casos, os dados que não estão armazenados em um meio de armazenamento persistente são excluídos permanentemente. Verifique se todos os dados que você precisa manter estão armazenados fora do nó de trabalho antes de começar.

Se você tiver um Portworx e implantado no seu cluster, siga as etapas para atualizar os nós de trabalho da VPC com volumes d Portworx, em vez de seguir as etapas descritas nesta página.

Atualizações de firmware durante a reinicialização do trabalhador bare metal do VPC

Ao reiniciar um nó de trabalho bare metal da VPC, a infraestrutur IBM Cloud verifica automaticamente se há alguma atualização de firmware pendente para esse servidor e a aplica como parte do processo de reinicialização. Não é necessário realizar nenhuma ação adicional para iniciar a atualização do firmware.

Leve em consideração os seguintes pontos ao reinicializar um nó de trabalho bare metal da VPC:

Tempo de recarga prolongado

Se uma atualização de firmware for aplicada durante a recarga, o tempo total de recarga pode aumentar significativamente — em 30 minutos ou mais — além da duração normal da recarga. Planeje seus intervalos de manutenção de acordo com isso.

Não há visibilidade prévia das atualizações pendentes

Não é possível saber se há uma atualização de firmware pendente para um nó de trabalho antes de você emitir o comando de recarga.

Risco de perda de dados

Assim como em todas as reinicializações de instâncias bare metal do VPC, os dados nos discos locais são excluídos durante a reinicialização, independentemente de ser aplicada uma atualização de firmware. Faça backup de todos os dados que não estejam armazenados em um dispositivo de armazenamento persistente antes de recarregar.

Falha na recarga devido à atualização do firmware

Em alguns casos, uma atualização de firmware pode falhar, o que faz com que o nó de trabalho entre em um estado “ reload_failed ” (Failed to reload worker) com o detalhe de status The infrastructure firmware update has failed. (P4056). Se isso ocorrer:

1. Aguarde alguns minutos e, em seguida, tente recarregar novamente executando o comando ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID .
2. Se o erro persistir após 2 a 3 tentativas, abra um IBM Cloud caso de suporte.

Antes de Iniciar

• Acesse o seu Red Hat OpenShift cluster.
• Verifique se todos os dados que você precisa manter estão armazenados em um armazenamento persistente fora do nó de trabalho. Os dados armazenados exclusivamente no nó de trabalho são perdidos e não podem ser recuperados.
• Certifique-se de que você tenha o Operador ou função de acesso à plataforma IAM do Administrador. Se você não tiver certeza de qual é a sua função de acesso, acesse Gerenciar → Acesso (IAM) → Usuários no console do IBM Cloud ou pergunte ao administrador da sua conta.

Para atualizar as versões

1. Liste os nós do trabalhador disponíveis e anote o seu endereço IP privado.

   1. Liste os conjuntos de trabalhadores disponíveis em seu cluster.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. Liste os nós do trabalhador no conjunto de trabalhadores. Observe o **ID** e o **IP privado**.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. Obtenha os detalhes para um nó do trabalhador. Na saída, observe a zona e o ID de VLAN privada e pública para clusters clássicos ou o ID de sub-rede para clusters VPC.
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Liste os tipos disponíveis na zona.

   ibmcloud oc flavors --zone <zone>
   

3. Crie um nó do trabalhador com o novo tipo de máquina.

   1. Crie um conjunto de trabalhadores com o número de nós do trabalhador que você deseja substituir.
      • Clusters clássicos:

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • Clusters VPC do , geração 2:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. Verifique se o conjunto de trabalhadores foi criado.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. Inclua a zona em seu conjunto de trabalhadores que você recuperou anteriormente. Ao incluir uma zona, os nós do trabalhador que estão definidos em seu conjunto de trabalhadores são provisionados na zona e considerados para planejamento futuro de carga de trabalho. Se você desejar distribuir seus nós do trabalhador entre várias zonas, escolha uma localização multizona [clássica](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) ou [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc).
       * Clusters clássicos:
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * Clusters de VPC:
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. Aguarde até que os nós do trabalhador sejam implementados. Quando o estado do nó do trabalhador muda para Normal, a implementação está concluída.

   ibmcloud oc worker ls --cluster CLUSTER
   

5. Remova o antigo conjunto de trabalhadores. Se você estiver cancelando uma instância Classic bare metal (cobrada mensalmente), será cobrado pelo mês inteiro, mesmo que o cancelamento ocorra no meio do mês. Os recursos do VPC, incluindo os de bare metal, são cobrados por hora.

   1. Remova o conjunto de trabalhadores com o tipo de máquina antigo. A remoção de um conjunto de trabalhadores remove todos os nós do trabalhador no conjunto em todas as zonas. Esse processo pode levar alguns minutos para ser concluído.

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. Verifique se o conjunto de trabalhadores foi removido.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. Verifique se os nós do trabalhador foram removidos de seu cluster.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. Repita essas etapas para atualizar outros conjuntos de trabalhadores ou nós do trabalhador independentes para diferentes tipos.

Gerenciando atualizações automáticas para Fluentd

Ao criar uma configuração de criação de log para uma origem em seu cluster para encaminhá-lo para um servidor externo, um componente Fluentd é criado em seu cluster. Para mudar as configurações de filtro ou criação de log, o componente Fluentd deve estar na versão mais recente. Por padrão, as atualizações automáticas para o componente são ativadas.

Para executar os comandos a seguir, é necessário ter a função de acesso à plataforma IAM “ IBM Cloud ”(Administrador) para o cluster.

É possível gerenciar atualizações automáticas do componente Fluentd das maneiras a seguir.

• Verifique se as atualizações automáticas estão ativadas executando o ibmcloud oc logging autoupdate get --cluster CLUSTER comando.
• Desative as atualizações automáticas executando o comando ibmcloud oc logging autoupdate disable .
• Se as atualizações automáticas estiverem desativadas, mas for necessário mudar sua configuração, você terá duas opções:
  • Ativar as atualizações automáticas para os seus pods do Fluentd.

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * Forçar uma atualização única quando usar um comando de criação de log que inclua a opção `--force-update`. Seus pods serão atualizados para a versão mais recente do componente Fluentd, mas o Fluentd não será atualizado automaticamente daqui em diante.
          Exemplo de comando
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

Gerenciando atualizações automáticas para ALBs do Ingress

Controle quando o componente do balanceador de carga do aplicativo (ALB) do Ingress é atualizado. Para obter informações sobre como manter os ALBs atualizados, consulte Gerenciando o ciclo de vida do ALB do Ingress.