Antes de começar
Antes da atualização, você pode verificar se o cluster pode ser atualizado e quais versões estão disponíveis no console do CCE. Para mais detalhes, consulte Visão geral de atualização.
Precauções
Antes de atualizar um cluster, preste atenção aos seguintes pontos:
- A atualização de um cluster não pode ser revertida. Realize uma atualização no momento adequado para minimizar o impacto em seus serviços. Para garantir a segurança dos dados, faça backup de seus dados antes de uma atualização.
- Antes de atualizar um cluster, garanta que nenhuma operação de alto risco seja executada no cluster. Caso contrário, a atualização de cluster poderá falhar ou a configuração poderá ser perdida após a atualização. As operações comuns de alto risco incluem a modificação local das configurações de nós do cluster e a modificação das configurações dos ouvintes gerenciados pelo CCE no console do ELB. Em vez disso, modifique configurações no console do CCE para que as modificações possam ser herdadas automaticamente durante a atualização.
- Antes de atualizar um cluster, verifique se o cluster está funcionando corretamente. Se o cluster não estiver funcionando corretamente, corrija a falha. Se a falha persistir, envie um tíquete de serviço para obter assistência.
- Antes de atualizar um cluster, saiba mais sobre os recursos e as diferenças de cada versão de cluster em Observações de versão do Kubernetes para evitar exceções devido ao uso de uma versão de cluster incompatível. Por exemplo, verifique se alguma API preterida na versão de destino é usada no cluster. Caso contrário, chamar as APIs pode falhar após a atualização. Para mais detalhes, consulte APIs preteridas.
Durante uma atualização de cluster, preste atenção aos seguintes pontos que podem afetar seus serviços:
- Durante uma atualização de cluster, não execute nenhuma operação no cluster. Não interrompa, reinicie ou exclua nós durante a atualização do cluster. Caso contrário, a atualização falhará.
- Durante uma atualização de cluster, as cargas de trabalho em execução não serão interrompidas, mas o acesso ao servidor da API será temporariamente interrompido.
- Durante uma atualização de cluster, a mancha node.kubernetes.io/upgrade (equivalente a NoSchedule) será adicionada aos nós no cluster. A mancha será removida depois que o cluster for atualizado. Não adicione manchas com o mesmo nome de chave em um nó. Mesmo que as manchas tenham efeitos diferentes, elas podem ser excluídas pelo sistema por engano após a atualização.
Restrições
- Os clusters do CCE e os clusters do CCE Turbo com nós de VM podem ser atualizados.
- Se houver nós criados usando uma imagem privada, o cluster não poderá ser atualizado.
- Depois que o cluster for atualizado, se a vulnerabilidade em contêiner do mecanismo de contêiner for corrigida nas Observações de versão do Kubernetes, reinicie manualmente o contêiner para que a atualização entre em vigor. O mesmo se aplica aos pods existentes.
- Se você montar o arquivo docker.sock em um nó em um pod usando o modo hostPath, ou seja, o Docker no cenário Docker, o Docker será reiniciado durante a atualização, mas o arquivo docker.sock não será alterado. Como resultado, seus serviços podem não funcionar corretamente. É aconselhável montar o arquivo docker.sock montando o diretório.
- Quando os clusters que usam o modelo de rede de túnel são atualizados para v1.19.16-r4, v1.21.7-r0, v1.23.5-r0, v1.25.1-r0 ou posterior, a regra SNAT cujo endereço de destino é o bloco CIDR do contêiner, mas o endereço de origem não é o bloco CIDR do contêiner será removido. Se você configurou as rotas da VPC para acessar diretamente todos os pods fora do cluster, somente os pods nos nós correspondentes poderão ser acessados diretamente após a atualização.
APIs preteridas
Com a evolução das APIs do Kubernetes, as APIs são periodicamente reorganizadas ou atualizadas, e as APIs anteriores são preteridas e finalmente excluídas. As tabelas a seguir listam as APIs preteridas em cada versão da comunidade do Kubernetes. Para obter detalhes sobre mais APIs preteridas, consulte Guia de migração de APIs preteridas.
- APIs preteridas no Kubernetes v1.25
- APIs preteridas no Kubernetes v1.22
- APIs preteridas no Kubernetes v1.16
Quando uma API é preterida, os recursos existentes não são afetados. No entanto, quando você criar ou editar os recursos, a versão da API será interceptada.
|
Nome do recurso |
Versão da API preterida |
Versão da API substituta |
Descrição de mudança |
|---|---|---|---|
|
CronJob |
batch/v1beta1 |
batch/v1 (Esta API está disponível desde a v1.21.) |
Nenhuma |
|
EndpointSlice |
discovery.k8s.io/v1beta1 |
discovery.k8s.io/v1 (Esta API está disponível desde a v1.21.) |
Preste atenção às seguintes mudanças:
|
|
Event |
events.k8s.io/v1beta1 |
events.k8s.io/v1 (Esta API está disponível desde a v1.19.) |
Preste atenção às seguintes mudanças:
|
|
HorizontalPodAutoscaler |
autoscaling/v2beta1 |
autoscaling/v2 (Esta API está disponível desde a v1.23.) |
Nenhuma |
|
PodDisruptionBudget |
policy/v1beta1 |
policy/v1 (Esta API está disponível desde a v1.21.) |
Se spec.selector for definido como nulo ({}) em PodDisruptionBudget de policy/v1, todos os pods no namespace serão selecionados. (Em policy/v1beta1, um spec.selector vazio significa que nenhum pod será selecionado.) Se spec.selector não for especificado, pod será selecionado em nenhuma das versões da API. |
|
PodSecurityPolicy |
policy/v1beta1 |
Nenhuma |
Desde a v1.25, o recurso PodSecurityPolicy não fornece mais APIs da versão policy/v1beta1, e o controlador de acesso de PodSecurityPolicy é excluído. Substitua-o por Configuração de admissão de segurança do pod. |
|
RuntimeClass |
node.k8s.io/v1beta1 |
node.k8s.io/v1 (Esta API está disponível desde a v1.20.) |
Nenhuma |
|
Nome do recurso |
Versão da API preterida |
Versão da API substituta |
Descrição de mudança |
|---|---|---|---|
|
MutatingWebhookConfiguration ValidatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
admissionregistration.k8s.io/v1 (Esta API está disponível desde a v1.16.) |
|
|
CustomResourceDefinition |
apiextensions.k8s.io/v1beta1 |
apiextensions/v1 (Esta API está disponível desde a v1.16.) |
|
|
APIService |
apiregistration/v1beta1 |
apiregistration.k8s.io/v1 (Esta API está disponível desde a v1.10.) |
Nenhuma |
|
TokenReview |
authentication.k8s.io/v1beta1 |
authentication.k8s.io/v1 (Esta API está disponível desde a v1.6.) |
Nenhuma |
|
LocalSubjectAccessReview SelfSubjectAccessReview SubjectAccessReview SelfSubjectRulesReview |
authorization.k8s.io/v1beta1 |
authorization.k8s.io/v1 (Esta API está disponível desde a v1.16.) |
spec.group foi renomeado spec.groups na v1 (patch #32709). |
|
CertificateSigningRequest |
certificates.k8s.io/v1beta1 |
certificates.k8s.io/v1 (Esta API está disponível desde a v1.19.) |
Preste atenção às seguintes alterações em certificates.k8s.io/v1:
|
|
Lease |
coordination.k8s.io/v1beta1 |
coordination.k8s.io/v1 (Esta API está disponível desde a v1.14.) |
Nenhuma |
|
Ingress |
networking.k8s.io/v1beta1 extensions/v1beta1 |
networking.k8s.io/v1 (Esta API está disponível desde a v1.19.) |
|
|
IngressClass |
networking.k8s.io/v1beta1 |
networking.k8s.io/v1 (Esta API está disponível desde a v1.19.) |
Nenhuma |
|
ClusterRole ClusterRoleBinding Role RoleBinding |
rbac.authorization.k8s.io/v1beta1 |
rbac.authorization.k8s.io/v1 (Esta API está disponível desde a v1.8.) |
Nenhuma |
|
PriorityClass |
scheduling.k8s.io/v1beta1 |
scheduling.k8s.io/v1 (Esta API está disponível desde a v1.14.) |
Nenhuma |
|
CSIDriver CSINode StorageClass VolumeAttachment |
storage.k8s.io/v1beta1 |
storage.k8s.io/v1 |
|
|
Nome do recurso |
Versão da API preterida |
Versão da API substituta |
Descrição de mudança |
|---|---|---|---|
|
NetworkPolicy |
extensions/v1beta1 |
networking.k8s.io/v1 (Esta API está disponível desde a v1.8.) |
Nenhuma |
|
DaemonSet |
extensions/v1beta1 apps/v1beta2 |
apps/v1 (Esta API está disponível desde a v1.9.) |
|
|
Deployment |
extensions/v1beta1 apps/v1beta1 apps/v1beta2 |
apps/v1 (Esta API está disponível desde a v1.9.) |
|
|
StatefulSet |
apps/v1beta1 apps/v1beta2 |
apps/v1 (Esta API está disponível desde a v1.9.) |
|
|
ReplicaSet |
extensions/v1beta1 apps/v1beta1 apps/v1beta2 |
apps/v1 (Esta API está disponível desde a v1.9.) |
spec.selector agora é um campo obrigatório e não pode ser alterado após a criação do objeto. O rótulo de um modelo existente pode ser usado como um seletor para migração perfeita. |
|
PodSecurityPolicy |
extensions/v1beta1 |
policy/v1beta1 (Esta API está disponível desde a v1.10.) |
PodSecurityPolicy para a versão da API policy/v1beta1 será removida na v1.25. |
Diferenças entre versões
|
Caminho de atualização |
Diferença entre versões |
Auto-verificação |
|---|---|---|
|
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.
|
|
|
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. |
|
|
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.
{
"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.
AVISO:
Para mitigar o impacto das diferenças de versão na atualização do cluster, o CCE executa um processamento especial durante a atualização de 1.15 para 1.19 e ainda oferece suporte a certificados sem SANs. No entanto, nenhum processamento especial é necessário para atualizações subsequentes. Aconselha-se que retifique o seu certificado o mais rapidamente possível. |
|
|
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. |
|
Init contêiner (calculado com base em spec.initContainers) |
Contêiner de serviço (calculado com base em spec.containers) |
Pod (calculado com base em spec.containers e spec.initContainers) |
Impactado ou não |
|---|---|---|---|
|
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 |
Atualizar backup
Como fazer backup de um nó:
- Backup do banco de dados etcd: o CCE faz backup automaticamente do banco de dados etcd durante a atualização do cluster.
- Backup de nó principal (recomendado, confirmação manual necessária): na página de confirmação da atualização, clique em Backup para fazer backup de todo o nó principal do cluster. O processo de backup usa o serviço Cloud Backup and Recovery (CBR) e leva cerca de 20 minutos. Se houver muitas tarefas de backup de nuvem no site atual, o tempo de backup pode ser prolongado
