Quando você faz upgrade do Google Distributed Cloud, o processo envolve várias etapas
e componentes. Para ajudar a monitorar o status do upgrade ou diagnosticar e resolver problemas, é útil saber o que acontece quando você executa o
comando bmctl upgrade
cluster. Neste documento, detalhamos os componentes e
as etapas de um upgrade de cluster.
Visão geral
O processo de upgrade move o cluster do Google Distributed Cloud da versão atual para uma versão mais recente.
Essas informações da versão são armazenadas nos seguintes locais como parte do recurso personalizado do cluster no cluster de administrador:
status.anthosBareMetalVersion: define a versão atual do cluster.spec.anthosBareMetalVersion: define a versão pretendida e é definido quando o processo de upgrade começa a ser executado.
Uma operação de upgrade bem-sucedida reconcilia
status.anthosBareMetalVersion com
spec.anthosBareMetalVersion para que os dois mostrem
a versão de destino.
Desvio de versão do cluster
O desvio da versão do cluster é a diferença de versões entre um cluster de administrador (híbrido ou administrador) e os clusters de usuário gerenciados. Ao adicionar ou fazer upgrade de um cluster de usuário, as seguintes regras de versão são aplicáveis:
1.30
As regras a seguir são aplicáveis aos clusters de usuário gerenciados por um cluster híbrido ou de administrador da versão 1.30:
As versões do cluster de usuário não podem ser superiores à versão do cluster de gerenciamento (administrador ou híbrido).
(1.30 GA) Os clusters de usuário podem ter até duas versões secundárias a menos que a versão do cluster gerenciador. Por exemplo, um cluster de administrador da versão 1.30 pode gerenciar um cluster de usuário da versão 1.28. Esse recurso de gerenciamento de distorção da versão n-2 está na disponibilidade geral para gerenciar clusters na versão 1.30.
(1.30 GA) Para um determinado cluster de gerenciamento na versão 1.30, os clusters de usuário não precisam ter a mesma versão secundária. Por exemplo, um cluster de administrador da versão 1.30 pode gerenciar clusters de usuários das versões 1.30, 1.29 e 1.28.
O recurso de gerenciamento de várias distorções oferece mais flexibilidade para planejar os upgrades da frota. Por exemplo, não é necessário fazer upgrade de todos os clusters de usuários da versão 1.28 para a versão 1.29 antes de fazer upgrade do cluster de administrador para a versão 1.30.
1.29
As regras a seguir são aplicáveis aos clusters de usuários gerenciados por um cluster híbrido ou de administrador da versão 1.29:
As versões do cluster de usuário não podem ser superiores à versão do cluster de gerenciamento (administrador ou híbrido).
(1.29 Pré-visualização) Os clusters de usuário podem ter até duas versões secundárias abaixo da versão do cluster de administrador. Por exemplo, um cluster de administrador da versão 1.29 pode gerenciar um cluster de usuário da versão 1.16. Esse gerenciamento de distorção da versão n-2 está disponível como um recurso de pré-lançamento para gerenciar clusters na versão 1.29.
(1.29 Pré-lançamento) Para um determinado cluster de administração, os clusters de usuário não precisam ter a mesma versão secundária. Por exemplo, um cluster de administrador da versão 1.29 pode gerenciar clusters de usuário das versões 1.29, 1.28 e 1.16. Esse gerenciamento de distorção de versão mista está disponível como um recurso de pré-lançamento para gerenciar clusters na versão 1.29.
O recurso de gerenciamento de várias distorções Pré-visualização oferece mais flexibilidade para planejar os upgrades da frota. Por exemplo, não é necessário fazer upgrade de todos os clusters de usuário da versão 1.16 para a versão 1.28 antes de fazer upgrade do cluster de administrador para a versão 1.29.
1.28 e versões anteriores
As regras a seguir são aplicáveis aos clusters de usuários gerenciados por um cluster híbrido ou de administrador da versão 1.28 ou anterior:
As versões do cluster de usuário não podem ser superiores à versão do cluster de gerenciamento (administrador ou híbrido).
Os clusters de usuário podem ter até uma versão secundária anterior à versão do cluster de administrador. Por exemplo, um cluster de administrador da versão 1.28 não pode gerenciar um cluster de usuário na versão 1.15.
Para um determinado cluster de gerenciamento, todos os clusters de usuário gerenciados precisam estar na mesma versão secundária.
Para informações sobre as regras de desvio de versão para pools de nós, consulte Regras de controle de versão do pool de nós.
Regras da versão
Ao fazer o download e instalar uma nova versão de bmctl, será possível fazer upgrade dos
clusters de administrador, híbridos, independentes e de usuário criados ou atualizados com uma versão
anterior de bmctl. Não é possível fazer downgrade dos clusters para uma versão anterior.
Só é possível fazer upgrade de um cluster para uma versão que corresponda à de bmctl que você está usando. Ou seja, se você estiver usando a versão
1.30.100-gke.96 de bmctl, será possível fazer upgrade de um cluster apenas para a versão
1.30.100-gke.96.
Upgrades de versão de patchs
Para uma determinada versão secundária, é possível fazer upgrade para qualquer versão de patch superior. Ou seja,
é possível fazer upgrade de um
cluster de versão 1.30.X para a versão
1.30.Y, desde que
Y seja maior que
X. Por exemplo, é possível fazer upgrade de
1.29.0 para 1.29.100, bem como de
1.29.100 para 1.29.300. Recomendamos que você faça o upgrade
para a versão de patch mais recente sempre que possível para garantir que os clusters tenham as
correções de segurança mais recentes.
Upgrades de versão secundária
É possível fazer upgrade de clusters de uma versão secundária para a próxima, independentemente da
versão do patch. Ou seja, é possível fazer upgrade de
1.N.X para
1.N+1.Y, em que
1.N.X é a versão
do seu cluster, e N+1 é a próxima versão secundária
disponível. As versões de patch, X e
Y, não afetam a lógica de upgrade neste caso. Por
exemplo, é possível fazer upgrade de 1.29.600-gke.108 para 1.30.100-gke.96.
Não é possível pular versões secundárias ao fazer upgrade de clusters. Se você tentar fazer upgrade
para uma versão secundária que seja duas ou mais versões secundárias mais recentes que a versão do
cluster, bmctl emitirá um erro. Por exemplo, não é possível fazer upgrade de um cluster da versão
1.28.0 para a versão 1.30.0.
Um cluster de administrador pode gerenciar clusters de usuário que estão em uma versão secundária igual ou anterior. Os clusters de usuário gerenciados não podem ser mais que uma versão secundária anterior ao cluster de administrador. Portanto, antes de fazer upgrade de um cluster de administrador para uma nova versão secundária, verifique se todos os clusters de usuário gerenciados estão na mesma versão secundária que o cluster de administrador.
Regras de controle de versões do pool de nós
Quando você faz upgrade de pools de nós seletivamente, as seguintes regras de versão se aplicam:
1.30
A versão do cluster precisa ser maior ou igual à versão do pool de nós de trabalho.
A distorção máxima da versão entre um pool de nós de trabalho e o cluster é de duas versões secundárias.
Os pools de nós de trabalho podem estar em qualquer versão de patch de uma versão secundária compatível.
1.29
A versão do cluster precisa ser maior ou igual à versão do pool de nós de trabalho.
(1.29 GA) A distorção máxima da versão entre um pool de nós de trabalho e o cluster é de duas versões secundárias.
Os pools de nós de trabalho não podem estar em uma versão lançada mais tarde que a versão do cluster. A versão anterior não tem os detalhes completos da versão mais recente, que é um requisito para compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada após a versão 1.28.100-gke.146, portanto, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer um upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer um upgrade do pool de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
1.28
A versão do cluster precisa ser maior ou igual à versão do pool de nós de trabalho.
(1.28 Pré-lançamento) A distorção máxima da versão entre um pool de nós de trabalho e o cluster é de duas versões secundárias quando o recurso de desvio da versão n-2 Pré-lançamento está ativado. Se você não ativar esse recurso de pré-lançamento, a distorção máxima da versão entre um pool de nós de trabalho e o cluster será uma versão secundária.
Os pools de nós de trabalho não podem estar em uma versão lançada mais tarde que a versão do cluster. A versão anterior não tem os detalhes completos da versão mais recente, que é um requisito para compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada após a versão 1.28.100-gke.146, portanto, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer um upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer um upgrade do pool de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
1.16
A versão do cluster precisa ser maior ou igual à versão do pool de nós de trabalho.
A distorção máxima da versão entre um pool de nós de trabalho e o cluster é uma versão secundária.
Os pools de nós de trabalho não podem estar em uma versão lançada mais tarde que a versão do cluster. A versão anterior não tem os detalhes completos da versão mais recente, que é um requisito para compatibilidade.
Por exemplo, a versão 1.16.6 foi lançada após a versão 1.28.100-gke.146, portanto, não é possível fazer upgrade do cluster da versão 1.16.6 para a versão 1.28.100-gke.146 e deixar um pool de nós de trabalho na versão 1.16.6. Da mesma forma, se você fizer um upgrade do cluster para a versão 1.28.100-gke.146, mas optar por deixar um pool de nós de trabalho na versão 1.16.5, não será possível fazer um upgrade do pool de nós de trabalho para a versão 1.16.6 enquanto o cluster estiver na versão 1.28.100-gke.146.
A tabela a seguir lista as versões do pool de nós compatíveis com uma versão específica do cluster:
1.30
Para pools de nós em uma versão secundária compatível, versão 1.29 ou 1.28, todas as versões de patch são compatíveis com clusters em qualquer versão de patch da versão secundária 1.30.
1.29
| Versão do cluster (plano de controle) | Versões do pool de nós de trabalho com suporte (versões adicionadas em negrito) | |||
|---|---|---|---|---|
| 1.29.600-gke.105 |
|
|
|
|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1.28
| Versão do cluster (plano de controle) | Versões do pool de nós de trabalho com suporte (versões adicionadas em negrito) | |||
|---|---|---|---|---|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 1.28.700-gke.150 |
|
|
|
|
| 1.28.600-gke.163 |
|
|
|
|
| 1.28.500-gke.120 |
|
|
|
|
| 1.28.400-gke.77 |
|
|
|
|
| 1.28.300-gke.131 |
|
|
|
|
| 1.28.200-gke.118 |
|
|
|
|
| 1.28.100-gke.146 |
|
|
|
|
| 1.28.0-gke.425 |
|
|
|
|
1.16
| Versão do cluster (plano de controle) | Versões do pool de nós de trabalho com suporte (versões adicionadas em negrito) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 1.16.10 |
|
|
|
|
| 1.16.9 |
|
|
|
|
| 1.16.8 |
|
|
|
|
| 1.16.7 |
|
|
|
|
| 1.16.6 |
|
|
|
|
| 1.16.5 |
|
|
|
|
| 1.16.4 |
|
|
|
|
| 1.16.3 |
|
|
|
|
| 1.16.2 |
|
|
|
|
| 1.16.1 |
|
|
||
| 1.16.0 |
|
|
||
Fazer upgrade dos componentes
Os componentes são atualizados no nível do nó e do cluster. No nível do cluster, os seguintes componentes são atualizados:
- Componentes de cluster para rede, observabilidade e armazenamento.
- Para clusters de administrador, híbridos e autônomos, os controladores de ciclo de vida.
- O
gke-connect-agent.
Os nós em um cluster são executados com um dos seguintes papéis, com diferentes componentes atualizados dependendo do papel do nó:
| Papel do nó | Função | Componentes para fazer upgrade |
|---|---|---|
| Worker | Executa cargas de trabalho de usuários | Kubelet, ambiente de execução do contêiner (Docker ou containerd) |
| Plano de controle | Executa o plano de controle do Kubernetes, os controladores de ciclo de vida do cluster e os complementos da plataforma do Google Kubernetes Engine (GKE) Enterprise | Pods estáticos do plano de controle do Kubernetes (kubeapi-server,
kube-scheduler, kube-controller-manager etc.)
Controladores de ciclo de vida, como lifecycle-controllers-manager e
anthos-cluster-operatorComplementos da plataforma do Google Kubernetes Engine (GKE) Enterprise Edition, como stackdriver-log-aggregator e
gke-connect-agent |
| Balanceador de carga do plano de controle | Executa HAProxy e Keepalived que veiculam tráfego para
kube-apiserver e executa alto-falantes MetalLB para reivindicar endereços IP virtuais |
Pods estáticos do balanceador de carga do plano de controle (HAProxy, Keepalived)
Alto-falantes MetalLB |
Expectativa de inatividade
Na tabela a seguir, detalhamos a inatividade esperada e o possível impacto ao fazer upgrade dos clusters. Nesta tabela, presumimos que você tenha vários nós de cluster e um plano de controle de alta disponibilidade. Se você executar um cluster autônomo ou não tiver um plano de controle de alta disponibilidade, espere mais inatividade. A menos que indicado, essa inatividade se aplica aos upgrades de cluster de administrador e usuário:
| Componentes | Expectativas de inatividade | Quando ocorre inatividade |
|---|---|---|
Servidor de API do plano de controle do Kubernetes (kube-apiserver),
etcd e programador |
Sem inatividade | N/A |
Controladores de ciclo de vida e job ansible-runner (somente cluster de
administrador) |
Sem inatividade | N/A |
Plano de controle do Kubernetes loadbalancer-haproxy e
keepalived |
Inatividade temporária (menos de 1 a 2 minutos) quando o balanceador de carga redireciona o tráfego. | Início do processo de upgrade. |
Observabilidade pipeline-stackdriver e
metrics-server |
Operador drenado e atualizado. O tempo de inatividade deve ser inferior a cinco minutos.
Os DaemonSets continuam funcionando sem inatividade. |
Depois que o upgrade dos nós do plano de controle for concluído. |
| Interface de rede de contêiner (CNI) | Não há inatividade para as rotas de rede atuais. O DaemonSet implantou dois por dois sem inatividade. O operador é drenado e atualizado. Inatividade com menos de 5 minutos. |
Depois que o upgrade dos nós do plano de controle for concluído. |
| MetalLB (somente cluster de usuário) | Operador drenado e atualizado. A inatividade é inferior a 5 minutos.
Sem inatividade para o serviço atual |
Depois que o upgrade dos nós do plano de controle for concluído. |
| CoreDNS e escalonador automático de DNS (somente cluster de usuário) | O CoreDNS tem várias réplicas com o escalonador automático. Geralmente, não há inatividade. | Depois que o upgrade dos nós do plano de controle for concluído. |
| Provisionador de volume local | Sem inatividade para volumes permanentes provisionados (PVs).
O operador pode ter cinco minutos de inatividade. |
Depois que o upgrade dos nós do plano de controle for concluído. |
| Istio / entrada | O operador do Istio foi drenado e atualizado. Cerca de cinco minutos de inatividade. A entrada configurada atual continuará funcionando. |
Depois que o upgrade dos nós do plano de controle for concluído. |
| Outros operadores do sistema | Inatividade de cinco minutos quando drenado e atualizado. | Depois que o upgrade dos nós do plano de controle for concluído. |
| Cargas de trabalho de usuário | Depende da configuração, como se for altamente disponível. Revise suas implantações de carga de trabalho para entender o possível impacto. |
Quando os nós de trabalho são atualizados. |
Detalhes do upgrade do cluster de usuário
Nesta seção, detalhamos a ordem dos upgrades de componentes e as informações de status para um upgrade de cluster de usuário. A seção a seguir detalha os desvios desse fluxo para upgrades de cluster de administrador, híbrido ou autônomo.
O diagrama a seguir mostra o processo de verificação de simulação para um upgrade de cluster de usuário:
O diagrama anterior detalha as etapas que acontecem durante um upgrade:
- O comando
bmctl upgrade clustercria um recurso personalizadoPreflightCheck. - Essa verificação de simulação executa outras verificações, como verificações de upgrade de cluster, de integridade da rede e de nó.
- Os resultados dessas verificações adicionais se combinam para informar a capacidade do cluster de fazer upgrade para a versão de destino.
Se as verificações de simulação forem bem-sucedidas e não houver problemas de bloqueio, os componentes no cluster serão atualizados em uma ordem especificada, como mostrado no diagrama a seguir:
No diagrama anterior, os componentes são atualizados na ordem abaixo:
- O upgrade começa com a atualização do campo
spec.anthosBareMetalVersion. - Os balanceadores de carga do plano de controle são atualizados.
- O pool de nós do plano de controle é atualizado.
- Paralelamente, o GKE Connect é atualizado, os complementos do cluster e o
pool de nós do balanceador de carga são atualizados.
- Depois que o pool de nós do balanceador de carga é atualizado, os pools de nós de trabalho são atualizados.
Quando todos os componentes tiverem sido atualizados, as verificações de integridade do cluster serão executadas.
As verificações de integridade continuam em execução até que todas sejam aprovadas.
Quando todas as verificações de integridade forem aprovadas, o upgrade será concluído.
Cada componente tem o próprio campo de status no recurso personalizado de cluster. Verifique o status nestes campos para entender o progresso do upgrade:
| Sequência | Nome do campo | Significado |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
O status é copiado do status do pool de nós do plano de controle. O campo inclui as versões dos nós dos pools de nós do plano de controle. |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Versão de lifecycles-controllers-manager aplicada ao
cluster. Esse campo está disponível apenas para clusters
de administrador, autônomos ou híbridos. |
| 2 | status.anthosBareMetalManifestsVersion |
Versão do cluster do último manifesto aplicado. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
O status é copiado do status do pool de nós do
balanceador de carga do plano de controle. Este campo ficará vazio se nenhum balanceador de carga do plano de controle separado for
especificado em Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Um mapa de versão agregada da versão para números de nó. |
| 4 | status.anthosBareMetalVersion |
Status final da versão atualizada. |
Detalhes do upgrade de cluster de administrador, híbrido e autônomo
A partir da versão 1.15.0 do bmctl, o comportamento de upgrade padrão para
clusters autogerenciados (de administradores, híbridos ou independentes) é um upgrade no local.
Ou seja, quando você faz o upgrade de um cluster para a versão 1.15.0 ou mais recente, o upgrade
usa controladores de ciclo de vida, em vez de um cluster de inicialização, para gerenciar todo
o processo de upgrade. Essa alteração simplifica o processo e reduz os requisitos de recursos, o que torna os upgrades de cluster mais confiáveis e escalonáveis.
Ainda que o uso de um cluster de inicialização para upgrade não seja recomendado, a opção ainda está disponível. Para usar um cluster de inicialização ao fazer upgrade, execute o comando bmctl upgrade com a sinalização --use-bootstrap=true.
Os estágios do upgrade são diferentes, dependendo do método
usado.
Upgrades no local
O processo de upgrade padrão para clusters autogerenciados no local é semelhante ao processo de upgrade do cluster de usuário. No entanto, ao usar o processo de upgrade no local, uma nova versão do preflightcheck-operator é implantada antes da verificação de simulação do cluster e das verificações de integridade:
Assim como o upgrade do cluster de usuário, o processo de upgrade começa atualizando o
campo Cluster.spec.anthosBareMetalVersion para a versão desejada. Duas
outras etapas são executadas antes que os componentes sejam atualizados, como mostrado no
diagrama a seguir: o lifecycle-controller-manager faz upgrade para a
versão pretendida e implanta a versão desejada de
anthos-cluster-operator. Esse anthos-cluster-operator executa as etapas restantes do processo de upgrade:
Após a conclusão, o anthos-cluster-operator reconcilia a versão de destino de
spec.anthosBareMetalVersion para status.anthosBareMetalVersion.
Fazer upgrade com um cluster de inicialização
O processo de upgrade de um cluster de administrador, híbrido ou autônomo é semelhante a um cluster de usuário discutido na seção anterior.
A principal diferença é que o
comando bmctl upgrade cluster inicia um processo para criar um cluster
de inicialização. Esse cluster de inicialização é um cluster temporário que gerencia o cluster híbrido,
de administrador ou autônomo durante um upgrade.
O processo para transferir a propriedade de gerenciamento do cluster para o cluster de inicialização é chamado de tabela dinâmica. O restante do upgrade segue o mesmo processo que o upgrade do cluster de usuário.
Durante o processo de upgrade, os recursos no cluster de destino permanecem desatualizados. O progresso do upgrade só é refletido nos recursos do cluster de inicialização.
Se necessário, é possível acessar o cluster de inicialização para ajudar a monitorar e depurar o
processo de upgrade. O cluster de inicialização pode ser acessado usando
bmctl-workspace/.kindkubeconfig.
Para transferir a propriedade de gerenciamento do cluster novamente após a conclusão do upgrade, o cluster dinamiza os recursos do cluster de inicialização para o cluster atualizado. Não há etapas manuais para dinamizar o cluster durante o processo de upgrade. O cluster de inicialização é excluído após o upgrade do cluster.
Drenagem de nós
Os upgrades de clusters do Google Distributed Cloud podem causar interrupção do aplicativo à medida que os nós são drenados. Esse processo faz com que todos os pods executados em um nó sejam encerrados e reiniciados nos nós restantes no cluster.
As implantações podem ser usadas para tolerar essa interrupção. Uma implantação pode especificar várias réplicas de um aplicativo ou serviço que precisa ser executado. Um aplicativo com várias réplicas precisa sofrer pouca ou nenhuma interrupção durante os upgrades.
PodDisruptionBudgets (PDBs)
Ao fazer upgrade de um cluster, o Google Distributed Cloud usa o fluxo do modo de manutenção para drenar os nós.
A partir da versão 1.29, os nós são drenados com a API Eviction, que
honra PodDisruptionBudgets (PDBs). Os PDBs podem ser usados para garantir que um número definido
de réplicas seja sempre executado no cluster em condições normais de execução.
Os PDBs permitem
limitar a interrupção a uma carga de trabalho quando os pods precisam ser reprogramados. A drenagem de nós baseada em remoção está disponível como GA para a versão 1.29.
Nas versões 1.28 e anteriores, o Google Distributed Cloud não respeita os PDBs quando os nós
são drenados durante um upgrade. Em vez disso, o processo de drenagem de nós é o melhor esforço. Alguns
pods podem ficar travados no estado Terminating e se recusarem a desocupar o nó. O upgrade prossegue, mesmo
com pods travados, quando o processo de drenagem em um nó
leva mais de 20 minutos.
Para mais informações, consulte Colocar os nós no modo de manutenção.
A seguir
- Confira as práticas recomendadas para upgrades do Google Distributed Cloud
- Fazer upgrade do Google Distributed Cloud
- Resolver problemas de upgrade de cluster