Riscos de compatibilidade

v1.19 a v1.21

O bug de exec probe timeouts foi corrigido no Kubernetes 1.21. Antes que esse bug seja corrigido, a sonda exec não considera o campo timeoutSeconds. Em vez disso, a sonda será executada indefinidamente, mesmo após o data limite configurado. Ela irá parar até que o resultado seja retornado. Se este campo não for especificado, o valor padrão 1 será usado. Este campo entra em vigor após a atualização. Se a sonda for executada por mais de 1 segundo, a verificação de integridade da aplicação poderá falhar e a aplicação poderá ser reiniciada com frequência.

Antes do upgrade, verifique se o tempo limite está configurado corretamente para a sonda exec.

O kube-apiserver do CCE 1.19 ou posterior requer que o campo Subject Alternative Names (SANs) esteja configurado para o certificado do servidor webhook. Caso contrário, kube-apiserver falha ao chamar o servidor webhook após a atualização, e os contêineres não podem ser iniciados corretamente.

Causa raiz: X.509 CommonName é descartado em Go 1.15. kube-apiserver do CCE 1.19 é compilado usando Go 1.15. Se o seu certificado webhook não tiver SANs, kube-apiserver não processa o campo CommonName do certificado X.509 como o nome de host por padrão. Como resultado, a autenticação falha.

Antes da atualização, verifique se o campo SAN está configurado no certificado do servidor webhook.

• Se você não tem seu próprio servidor webhook, você pode pular esta verificação.
• Se o campo não estiver definido, é aconselhável usar o campo SAN para especificar o endereço IP e o nome de domínio suportados pelo certificado.

v1.15 a v1.19

O plano de controle de clusters do CCE de v1.19 é incompatível com kubelet v1.15. Se um nó não for atualizado ou o nó a ser atualizado for reiniciado após o nó principal ser atualizado com sucesso, há uma alta probabilidade de que o nó esteja no status NotReady.

Isso ocorre porque o nó falhou ao ser atualizado reinicia o kubelet e aciona o registro do nó. Em clusters de v1.15, as tags de registro padrão (failure-domain.beta.kubernetes.io/is-baremetal e kubernetes.io/availablezone) são consideradas tags inválidas pelo cluster da v1.19.

As tags válidas nos clusters da v1.19 são node.kubernetes.io/baremetal e failure-domain.beta.kubernetes.io/zone.

1. Em casos normais, esse cenário não é acionado.
2. Depois que o nó principal for atualizado, não suspenda a atualização para que o nó possa ser atualizado rapidamente.
3. Se um nó não for atualizado e não puder ser restaurado, expulse aplicações no nó o mais rápido possível. Entre em contato com o suporte técnico e pule a atualização do nó. Após a conclusão da atualização, redefina o nó.

Nos clusters do CCE 1.15 e 1.19, o sistema de arquivos do driver de armazenamento Docker é alterado de XFS para Ext4. Como resultado, a sequência de pacote de importação nos pods da aplicação Java atualizado pode ser anormal, causando exceções de pod.

Antes da atualização, verifique o arquivo de configuração do Docker /etc/docker/daemon.json no nó. Verifique se o valor de dm.fs é xfs.

• Se o valor for ext4 ou o driver de armazenamento for Overlay, você poderá ignorar as próximas etapas.
• Se o valor for xfs, é aconselhável implementar aplicações no cluster da nova versão com antecedência para testar se os aplicativos são compatíveis com a nova versão do cluster.

{
      "storage-driver": "devicemapper",
      "storage-opts": [
      "dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
      "dm.use_deferred_removal=true",
      "dm.fs=xfs",
      "dm.use_deferred_deletion=true"
      ]
}

O kube-apiserver do CCE 1.19 ou posterior requer que o campo Subject Alternative Names (SANs) esteja configurado para o certificado do servidor webhook. Caso contrário, kube-apiserver falha ao chamar o servidor webhook após a atualização, e os contêineres não podem ser iniciados corretamente.

Causa raiz: X.509 CommonName é descartado em Go 1.15. kube-apiserver do CCE 1.19 é compilado usando Go 1.15. O campo CommonName é processado como o nome do host. Como resultado, a autenticação falha.

Antes da atualização, verifique se o campo SAN está configurado no certificado do servidor webhook.

• Se você não tem seu próprio servidor webhook, você pode pular esta verificação.
• Se o campo não estiver definido, é aconselhável usar o campo SAN para especificar o endereço IP e o nome de domínio suportados pelo certificado.

Em clusters da v1.17.17 e posteriores, o CCE cria automaticamente políticas de segurança de pods (PSPs) para você, o que restringe a criação de pods com configurações inseguras, por exemplo, pods para os quais net.core.somaxconn sob um sysctl é configurado no contexto de segurança.

Após uma atualização, você pode permitir configurações inseguras do sistema, conforme necessário. Para mais detalhes, consulte Configuração de uma política de segurança de pod.

Se initContainer ou Istio for usado na atualização in-loco de um cluster v1.15, preste atenção às seguintes restrições:

No kubelet 1.16 e versões posteriores, as classes de QoS são diferentes daquelas em versões anteriores. No kubelet 1.15 e versões anteriores, somente contêineres em spec.containers são contados. No kubelet 1.16 e versões posteriores, os contêineres em spec.containers e spec.initContainers são contados. A classe de QoS de um pod mudará após a atualização. Como resultado, o contêiner no pod é reiniciado.

É aconselhável modificar a classe de QoS do contêiner de serviço antes da atualização para evitar esse problema. Para mais detalhes, consulte Tabela 4.

v1.13 a v1.15

Depois que um cluster de rede da VPC é atualizado, o nó principal ocupa um bloco CIDR extra devido à atualização dos componentes de rede. Se nenhum bloco CIDR de contêiner estiver disponível para o novo nó, o pod agendado para o nó não poderá ser executado.

Geralmente, esse problema ocorre quando os nós no cluster estão prestes a ocupar totalmente o bloco CIDR do contêiner. Por exemplo, o bloco CIDR do contêiner é 10.0.0.0/16, o número de endereços IP disponíveis é 65.536 e a rede da VPC recebe um bloco CIDR com o tamanho fixo (usando a máscara para determinar o número máximo de endereços IP de contêiner alocados para cada nó). Se o limite superior for 128, o cluster suportará um máximo de 512 (65536/128) nós, incluindo os três nós principais. Depois que o cluster é atualizado, cada um dos três nós principais ocupa um bloco CIDR. Como resultado, 506 nós são suportados.

Guaranteed

Besteffort

Burstable

Sim

Guaranteed

Burstable

Burstable

Não

Guaranteed

Guaranteed

Guaranteed

Não

Besteffort

Besteffort

Besteffort

Não

Besteffort

Burstable

Burstable

Não

Besteffort

Guaranteed

Burstable

Sim

Burstable

Besteffort

Burstable

Sim

Burstable

Burstable

Burstable

Não

Burstable

Guaranteed

Burstable

Sim