Linha do tempo de liberações

A tabela a seguir inclui o cronograma de lançamento esperado para a versão 4.15. Essas informações podem ser usadas para fins de planejamento, bem como para estimar o período geral após o qual a versão talvez deixe de ser suportada.

As datas marcadas com o símbolo (†) são tentativas e estão sujeitas a mudança.

Preparando-se para a atualização

Analise as alterações que talvez você precise fazer ao atualizar um cluster para a versão 4.15. Estas informações resumem as atualizações que provavelmente terão impacto nos apps implementados quando a atualização for feita.

O gráfico Helm de backup e restauração é suportado em clusters Red Hat OpenShift on IBM Cloud 4.15. No entanto, apenas os terminais diretos do COS são suportados Por exemplo: s3.direct.us.cloud-object-storage.appdomain.cloud.

Verificação do status do Upgradeable de seu cluster

Execute o seguinte comando para verificar o status Upgradeable do seu cluster.

oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'

Saída de exemplo em que o status de Upgradeable é False

{
  "lastTransitionTime": "2023-10-04T15:55:54Z",
  "message": "Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958395 for details and instructions.",
  "reason": "AdminAckRequired",
  "status": "False",
  "type": "Upgradeable"
}

Se o status Upgradeable for False, as informações de condição fornecerem instruções que devem ser seguidas antes do upgrade Para obter informações adicionais, consulte Fornecendo o Reconhecimento do Administrador

Mudanças importantes de rede para clusters VPC criados na versão 4.15

A partir da versão 4.15, o Red Hat OpenShift on IBM Cloud introduziu um novo recurso de segurança para clusters VPC chamado Secure by Default Cluster VPC Networking.

Em um alto nível, a postura de segurança para clusters VPC do Red Hat OpenShift on IBM Cloud mudou de permitir todo o tráfego de saída e, em seguida, fornecer aos usuários mecanismos para bloquear seletivamente o tráfego conforme necessário para agora bloquear todo o tráfego que não é crucial para a funcionalidade do cluster e fornecer aos usuários mecanismos para permitir seletivamente o tráfego conforme necessário.

Ao provisionar um novo cluster VPC do Red Hat OpenShift on IBM Cloud na versão 4.15 ou mais recente, o comportamento de fornecimento padrão é permitir somente o tráfego necessário para que o cluster funcione. Todos os outros acessos são bloqueados. Para implementar o Secure by Default Networking, há mudanças nas configurações de grupos de segurança do VPC padrão, bem como novos Virtual Private Endpoints (VPEs) para serviços IBM comuns.

Algumas notas chave para Secure by Default Networking são:

• Aplica-se apenas aos clusters de VPC Clusters clássicos não são afetados.

• Não afeta os clusters existentes Os clusters existentes em sua VPC continuarão a funcionar como hoje.

• Aplica-se somente aos clusters do Red Hat OpenShift on IBM Cloud recém-provisionados na versão 4.15 As configurações do grupo de segurança para clusters existentes do Red Hat OpenShift on IBM Cloud que são atualizados para a versão 4.15, incluindo quaisquer customizações feitas, não são mudadas.

• O comportamento padrão para clusters criados na versão 4.15 e posterior é ativar a proteção de tráfego de saída Secure by Default. No entanto, novos parâmetros na IU, na CLI, na API e no Terraform permitem desativar esse recurso. Também é possível ativar e desativar a proteção de tráfego de saída após criar um cluster.

• Se o seu VPC usar um resolvedor de DNS customizado, o fornecimento de um novo cluster da versão 4.15 incluirá regras automaticamente permitindo o tráfego por meio dos endereços IP do resolvedor em seu grupo de segurança gerenciado pelo IKS (kube-<clusterID>).

Para obter uma visão geral da rede VPC de Cluster Seguro por Padrão, incluindo os grupos de segurança, regras e VPEs que são criados por padrão, consulte Entendendo a Rede VPC de Cluster Seguro por Padrão.

Permitindo o tráfego de saída após a criação de um cluster 4.15

Se você tiver criado um cluster da versão 4.15 com a proteção de tráfego de saída ativada, seus apps ou serviços poderão experimentar tempo de inatividade devido a dependências que requerem conexões de rede externas Revise as opções a seguir para ativar o tráfego de saída seletivamente ou permitir todo o tráfego de saída.

Para obter mais informações, consulte Gerenciando a proteção de tráfego de saída em clusters VPC

Informações sobre a criação do gateway VPE

Quando um cluster VPC é criado ou atualizado para a versão 4.15, os seguintes gateways VPE são criados, caso não existam.

• Para clusters atualizados para a versão 4.15, esses gateways VPE já devem existir, pois teriam sido criados quando o cluster estava na versão 4.14.

Esses gateways VPE são compartilhados por todos os recursos na VPC e, quando são criados pela primeira vez, eles alteram os endereços IP associados a esses serviços e restringem o acesso a eles.

Se algum recurso na VPC estiver usando algum desses serviços em que o Gateway VPE ainda não existe, você deverá executar as ações descritas abaixo antes e possivelmente durante a atualização para garantir que os recursos ainda tenham acesso.

As etapas a serem seguidas são diferentes, dependendo se você estiver criando um novo cluster 4.15 ou atualizando o mestre de um cluster 4.14 existente.

• Os novos clusters 4.15 recebem as configurações Secure by Default descritas acima.
• Os clusters 4.14 atualizados continuam a usar o modelo antigo de grupo de segurança.

Problemas comuns e resolução de problemas

• Após ativar a proteção de tráfego de saída em meu cluster 4.15, meu app não funciona mais.
• Quando tento criar o cluster da versão 4.15, vejo um erro de quota.
• Quando eu atualizo meu cluster para proteger por padrão, meu app nodeport não funciona mais.
• Por que vejo falhas de DNS após incluir um resolvedor de DNS customizado?.
• Depois de criar um cluster da versão 4.15, os aplicativos em execução em outros clusters em meu VPC falham.