Atualizando clusters, nós do trabalhador e componentes do cluster

Atualizando o mestre

Como sei quando devo atualizar o mestre?

Você é notificado no console, nos anúncios e na CLI quando as atualizações estão disponíveis Também é possível verificar periodicamente a página de versões suportadas

Quantas versões atrás da mais recente o master pode estar?

Você pode atualizar o servidor da API apenas para a versão imediatamente superior à versão atual (n+1).

Meus nós de trabalho podem rodar uma versão mais recente do que a do mestre?

Os nós do trabalhador não podem executar uma versão mais recente do Kubernetes major.minor do que a principal. Além disso, os nós do trabalhador podem estar apenas uma versão atrás da versão principal (n-1). Primeiro, atualize o principal para a versão mais recente do Kubernetes. Em seguida, atualize os nós do trabalhador em seu cluster.

Os nós do trabalhador podem executar versões de correção mais recentes do que o mestre, como as versões de correção que são específicas para nós do trabalhador para atualizações de segurança.

Como as atualizações de patch são aplicadas?

Por padrão, as atualizações de correção para o mestre são aplicadas automaticamente ao longo do curso de vários dias, portanto, uma versão de correção principal pode ser mostrada como disponível antes de ser aplicada ao seu mestre. A automação de atualização também ignora clusters que estão em um estado não funcional ou têm operações atualmente em andamento. Ocasionalmente, a IBM pode desativar as atualizações automáticas para um fix pack de mestre específico, como uma correção que é necessária somente se um mestre for atualizado de uma versão secundária para outra. Em qualquer um desses casos, você pode verificar as informações de versão em Red Hat OpenShift on IBM Cloud para avaliar qualquer impacto potencial e optar por usar com segurança o comando ibmcloud oc cluster master update por conta própria, sem esperar que a atualização automática seja aplicada.

Diferentemente do mestre, deve-se atualizar seus trabalhadores para cada versão de correção.

O que acontece durante a atualização do mestre?

Seu mestre está altamente disponível com três pods do mestre de réplica. Os pods principais têm uma atualização contínua, durante a qual apenas um pod está indisponível por vez. Duas instâncias estão funcionando para que seja possível acessar e mudar o cluster durante a atualização. Os nós do trabalhador, apps e recursos continuam a ser executados.

Posso reverter a atualização?

Não, não é possível reverter um cluster para uma versão anterior após o processo de atualização acontecer. Certifique-se de usar um cluster de teste e siga as instruções para tratar de problemas potenciais antes de atualizar seu principal de produção.

Qual processo devo seguir para atualizar o mestre?

O diagrama a seguir mostra o processo que é possível usar para atualizar seu mestre.

Atualizando nós do trabalhador clássicos

Você observa que uma atualização está disponível para os nós do trabalhador em um cluster de infraestrutura clássica. O que isso significa? Como as atualizações de segurança e as correções são colocadas no lugar para o servidor de API e outros componentes principais, deve-se ter certeza de que os nós do trabalhador permaneçam sincronizados. É possível fazer dois tipos de atualizações: atualizar apenas a versão de correção ou atualizar a versão major.minor com a versão de correção.

• Correção: uma atualização de correção de nó do trabalhador inclui correções de segurança. É possível atualizar o nó do trabalhador clássico para a correção mais recente usando os comandos ibmcloud oc worker reload ou update. Tenha em mente que o comando update também atualizará o nó do trabalhador para a mesma versão major.minor que a versão de correção principal e mais recente, se uma atualização de versão major.minor também estiver disponível.
• Major.minor: uma atualização major.minor move a versão do Kubernetes do nó do trabalhador para a mesma versão do mestre. Esse tipo de atualização geralmente inclui mudanças na API do Kubernetes ou em outros comportamentos para os qual seu cluster deve ser preparado. Lembre-se de que seus nós do trabalhador podem ser apenas uma versão atrás da versão master (n-1). É possível atualizar o nó do trabalhador clássico para a mesma correção usando o comando ibmcloud oc worker update.

Para obter mais informações, consulte Tipos de atualização.

É uma boa prática rotacionar os certificados CA sempre que você atualizar os nós de trabalho, pois a etapa mais longa da rotação de certificados inclui recarregar ou substituir os nós de trabalho.

O que acontece com meus aplicativos durante uma atualização?

Se executar apps como parte de uma implementação em nós do trabalhador que você atualizar, os apps serão reprogramados em outros nós do trabalhador no cluster. Esses nós do trabalhador podem estar em um conjunto de trabalhadores diferente ou, se você tiver nós do trabalhador independentes, os apps poderão estar planejados em nós do trabalhador independentes. Para evitar tempo de inatividade para seu app, deve-se assegurar que você tenha capacidade suficiente no cluster para transportar a carga de trabalho.

Como posso controlar quantos nós de trabalho ficam fora do ar ao mesmo tempo durante uma atualização ou recarga?

Se você precisar que todos os nós do trabalhador estejam funcionando, considere redimensionar seu conjunto de trabalhadores ou incluir nós do trabalhador independentes para incluir mais nós do trabalhador. Será possível remover os nós do trabalhador adicionais depois que a atualização for concluída.

Além disso, é possível criar um mapa de configuração do tipo “ Kubernetes ” que especifique o número máximo de nós de trabalho que podem ficar indisponíveis ao mesmo tempo, como, por exemplo, durante uma atualização. Os nós do trabalhador são identificados pelos rótulos de nó do trabalhador. É possível usar rótulos fornecidos pela IBM ou rótulos customizados que você incluiu no nó do trabalhador.

As regras do mapa Kubernetes de configuração são usadas apenas para atualizar os nós de trabalho. Essas regras não afetam recargas do nó do trabalhador, o que significa que o recarregamento ocorre imediatamente quando solicitado.

E se eu optar por não definir um mapa de configuração?

Quando o mapa de configuração não está definido, o padrão é usado. Por padrão, no máximo 20% de todos os nós do trabalhador em cada cluster podem ficar indisponíveis durante o processo de atualização.

Atualizando nós do trabalhador de VPC

Você percebe que há uma atualização disponível para seus nós de trabalho em um cluster VPC. O que isso significa? Como as atualizações de segurança e as correções são colocadas no lugar para o servidor de API e outros componentes principais, deve-se ter certeza de que os nós do trabalhador permaneçam sincronizados. É possível fazer dois tipos de atualizações: atualizar apenas a versão de correção ou atualizar a versão major.minor com a versão de correção.

Se o Portworx estiver implementado no cluster, siga as etapas para atualizar nós do trabalhador da VPC com volumes Portworx.

É uma boa prática rotacionar os certificados CA sempre que você atualizar os nós de trabalho, pois a etapa mais longa da rotação de certificados inclui recarregar ou substituir os nós de trabalho.

Se você tiver o OpenShift Data Foundation implementado em seu cluster, siga as etapas para atualizar os nós do trabalhador VPC com o OpenShift Data Foundation.

• Correção: uma atualização de correção de nó do trabalhador inclui correções de segurança. Para os usuários de máquinas físicas (bare metal) do VPC, é possível aplicar o patch mais recente usando o comando ibmcloud oc worker reload . Para os trabalhadores de instâncias de servidor virtual (VPC), use o comando ibmcloud oc worker replace .
• Major.minor: uma atualização major.minor move a versão do Kubernetes do nó do trabalhador para a mesma versão do mestre. Esse tipo de atualização geralmente inclui mudanças na API do Kubernetes ou em outros comportamentos para os qual seu cluster deve ser preparado. Lembre-se de que seus nós de trabalho só podem estar uma versão atrás da versão mestre (n-1). Você pode atualizar o nó de trabalho da VPC para o mesmo patch usando o comando ibmcloud oc worker replace com a opção --update .

O que acontece com meus aplicativos durante uma atualização?

Se executar apps como parte de uma implementação em nós do trabalhador que você atualizar, os apps serão reprogramados em outros nós do trabalhador no cluster. Estes nós do trabalhador podem estar em um conjunto de trabalhadores diferente. Para evitar tempo de inatividade do seu aplicativo, é preciso garantir que haja capacidade suficiente no cluster para suportar a carga de trabalho, por exemplo, redimensionando seus conjuntos de workers. Para obter mais informações, consulte Incluindo nós do trabalhador em clusters Classic ou Incluindo nós do trabalhador em clusters VPC..

O que acontece com meu nó de trabalho durante uma atualização?

O seu nó do trabalhador da VPC é substituído por remover o nó do trabalhador antigo e provisionar um novo nó do trabalhador que é executado na correção atualizada ou major.minor. O nó do trabalhador de substituição é criado na mesma zona, no mesmo conjunto de trabalhadores e com o mesmo tipo do nó do trabalhador excluído. No entanto, o nó do trabalhador de substituição é designado a um novo endereço IP privado e perde quaisquer rótulos ou contaminações customizadas que você aplicou ao nó do trabalhador antigo (rótulos e contaminações do conjunto de trabalhadores ainda são aplicados ao nó do trabalhador de substituição).

E se eu substituir vários nós de trabalho ao mesmo tempo?

Se você substituir vários nós do trabalhador ao mesmo tempo, eles serão excluídos e substituídos simultaneamente, não um por um. Certifique-se de que você tenha capacidade suficiente em seu cluster para remarcar suas cargas de trabalho antes de substituir os nós do trabalhador.

E se um nó de trabalho substituto não for criado?

Um nó do trabalhador de substituição não será criado se ele não tiver o rebalanceamento automático ativado.

Atualizando tipos (tipos de máquina)

Antes de Iniciar:

• Acesse o seu Red Hat OpenShift cluster.
• Dados no nó do trabalhador são excluídos. Considere armazenar seus dados no armazenamento persistente fora do nó do trabalhador.
• Certifique-se de que você tenha o Operador ou função de acesso à plataforma IAM do Administrador.

Para atualizar os tipos:

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 nó do trabalhador antigo. Nota: se você estiver removendo um tipo que é faturado mensalmente (como bare metal), você será cobrado pelo mês inteiro.

   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.

Como os conjuntos de trabalhadores têm a capacidade reduzida?

Quando o número de nós do trabalhador em um conjunto de trabalhadores é reduzido, como durante uma atualização do nó do trabalhador ou com o comando ibmcloud oc worker-pool resize, os nós do trabalhador são priorizados para exclusão com base em várias propriedades, incluindo estado, funcionamento e versão.

Essa lógica de prioridade não é relevante para o complemento do escalador automático..

A tabela a seguir mostra a ordem na qual os nós do trabalhador são priorizados para exclusão

É possível executar o comando ibmcloud oc worker ls para visualizar todas as propriedades do nó do trabalhador listada na tabela

Atualizando componentes do cluster

Seu cluster do Red Hat OpenShift on IBM Cloud é fornecido com componentes, como o Ingress, que são instalados automaticamente ao provisionar o cluster. Por padrão, esses componentes são atualizados automaticamente pela IBM. No entanto, é possível desativar as atualizações automáticas para alguns componentes e atualizá-las manualmente separadamente dos nós principal e do trabalhador.

Quais componentes padrão posso atualizar separadamente do cluster?

Opcionalmente, é possível desativar atualizações automáticas para os componentes a seguir:

• Fluentd para criação de log
• Balanceador de carga do aplicativo Ingress (ALB)

Existem componentes que não posso atualizar separadamente do cluster?

Sim. O cluster é implementado com os componentes gerenciados e recursos associados a seguir que não podem ser alterados, exceto para escalar pods ou editar configmaps para determinados benefícios de desempenho. Se você tentar mudar um desses componentes de implementação, suas configurações originais serão restauradas em um intervalo regular quando elas forem atualizadas com o cluster mestre. No entanto, observe que os recursos que você cria que estão associados a esses componentes, como políticas de rede do Calico que você cria para serem implementadas pelos componentes de implementação do Calico, não são atualizados.

• Componentes do calico
• Componentes do coredns
• ibm-cloud-provider-ip
• ibm-file-plugin
• ibm-keepalived-watcher
• ibm-master-proxy
• ibm-storage-watcher
• Componentes do kubernetes-dashboard
• metrics-server
• Componentes olm-operator e catalog (1.16 e mais recente)
• vpn

Posso instalar outros plug-ins ou complementos além dos componentes padrão?

Sim. O Red Hat OpenShift on IBM Cloud oferece outros plug-ins e complementos que você pode escolher para ampliar as funcionalidades do seu cluster. Por exemplo, você pode querer habilitar complementos gerenciados pel IBM no seu cluster. Você deve atualizar esses add-ons separadamente seguindo as etapas para atualizar add-ons gerenciados.

Atualizando complementos gerenciados

Os complementos gerenciados para o cluster do IBM Cloud Kubernetes Service são uma maneira fácil de aprimorar seu cluster com recursos de código aberto, como o Istio. A versão da ferramenta de software livre que você agrega ao seu cluster é testada pela IBM e aprovada para uso no IBM Cloud Kubernetes Service. Para atualizar complementos gerenciados que você ativou em seu cluster para as versões mais recentes, consulte Atualizando complementos gerenciados.