Quando você faz upgrade do GKE em clusters 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.
Visão geral
O processo de upgrade move o cluster do GKE em Bare Metal 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 de destino e é definido quando o processo de upgrade começa a ser executado.
Uma operação de upgrade bem-sucedida reconcilia a versão de destino de
spec.anthosBareMetalVersion para
status.anthosBareMetalVersion.
Versão skew
O desvio de versão é a diferença nas 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 estar 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.15.11 de bmctl, poderá fazer upgrade de um cluster apenas para a versão
1.15.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.15.X para a versão
1.15.Y, desde que
Y seja maior que
X. Por exemplo, é possível fazer upgrade de
1.14.0 para 1.14.1, bem como de
1.14.1 para 1.14.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.14.3 para 1.15.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.13.0 para a versão 1.15.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.14.2 para
o GKE em Bare Metal 1.15.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 do ciclo de vida do cluster e os complementos da plataforma da edição Google Kubernetes Engine (GKE) Enterprise | 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 da edição Google Kubernetes Engine (GKE) Enterprise, 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 de destino. Mais duas etapas são executadas antes que os componentes sejam atualizados, conforme mostrado no diagrama a seguir: o lifecycle-controller-manager faz upgrade para a versão de destino e, em seguida, implanta a versão de destino 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 cluster do GKE em Bare Metal podem levar à 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 do GKE em Bare Metal
- Fazer upgrade de clusters
- Resolver problemas de upgrade de cluster