Quando você faz upgrade do GKE em Bare Metal, o processo de upgrade 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.
Informações gerais
O processo de upgrade move o GKE em Bare Metal da versão atual para uma 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 a versão desejada de
spec.anthosBareMetalVersion para
status.anthosBareMetalVersion.
Versão skew
O desvio da versão é a diferença de versões entre um cluster de administrador e os clusters de usuário gerenciados. Os clusters do GKE em bare metal seguem o mesmo estilo do Kubernetes: o cluster de administrador pode ser, no máximo, uma versão secundária à frente dos clusters gerenciados.
Upgrades de regras de 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.14.11 de bmctl, só poderá fazer upgrade de um cluster para a versão
1.14.11.
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.14.X para a versão
1.14.Y, desde que
Y seja maior que
X. Por exemplo, é possível fazer upgrade de
1.13.0 para 1.13.1, bem como de
1.13.1 para 1.13.3. 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.13.3 para 1.14.11.
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.12.0 para a versão 1.14.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.
Os exemplos nas
instruções de upgrade a seguir mostram
o processo de upgrade da versão 1.13.2 para
o GKE em Bare Metal 1.14.11.
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 Anthos | Pods estáticos do plano de controle do Kubernetes (kubeapi-server,
kube-scheduler ,kube-controller-manager etcd)
Controladores de ciclo de vida, como lifecycle-controllers-manager e
anthos-cluster-operatorComplementos da plataforma Anthos 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 forem atualizados, 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
O upgrade de um cluster de administrador, híbrido e autônomo geralmente usa um cluster de inicialização para gerenciar o processo. A partir dos clusters do GKE em bare metal 1.13.0 e versões mais recentes, é possível executar o upgrade sem um cluster de inicialização. Somente os clusters que já estão na versão 1.13.0 ou posterior podem ser atualizados sem um cluster de inicialização. Os estágios do upgrade são diferentes, dependendo do método usado.
Para mais informações sobre upgrades no local, consulte Upgrades no local para clusters autogerenciados.
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.
Sem um cluster de inicialização
Os clusters do GKE em bare metal 1.13.0 e mais recente podem fazer upgrade de um cluster de administrador, híbrido ou autônomo sem um cluster de inicialização. Sem um cluster de inicialização, a experiência de upgrade é semelhante à do cluster de usuário.
O diagrama a seguir mostra a diferença na experiência do cluster de usuário.
Sem um cluster de inicialização, uma nova versão do preflightcheck-operator será
implantada antes da verificação de simulação de cluster e execução de 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 é reconciliado posteriormente
no processo de upgrade:
Drenagem de nós
Os upgrades do GKE em Bare Metal podem causar a 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.
Orçamentos de interrupção de pod (PDBs)
Os orçamentos de interrupção de pod (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.
No entanto, o GKE em Bare Metal faz jus a 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.
A seguir
- Consulte as práticas recomendadas para upgrades de clusters do Anthos em bare metal
- Fazer upgrade de Clusters do Anthos em bare metal
- Resolver problemas de upgrade de cluster