Manter o Zabbix em alta disponibilidade dentro de um cluster Kubernetes é sempre um desafio. Um upgrade mal feito pode derrubar o monitoramento inteiro.

O ponto é: como atualizar sem perder controle?

O problema

  • Zabbix tem dependência forte do banco.

  • São vários componentes: Server, Frontend, Proxy, DB.

  • Se subir fora de ordem, vira bagunça: erros de schema, instabilidade e downtime maior que o necessário.

Como faço na prática

1. Paro os dois Servers em HA(Réplicas 0) Tudo desligado pra não concorrer na hora do upgrade do banco.

2. Standalone primeiro Subo a versão nova isolada, valido compatibilidade. Aqui já corto 90% do risco.

3. Atualizo o banco O DB é a verdade do Zabbix. Ele vem primeiro, sempre. Validado?

4. Atualizo os Servers Paro o standalone e subo as réplicas. Rolling update, um por vez, validando conexão com o banco.

5. Atualizo o Web Última peça do quebra-cabeça. Só depois de tudo validado no backend.

Por que essa ordem?

  • Teste isolado : valida antes de arriscar produção.

  • Banco antes : evita quebra de schema.

  • Parada ordenada : sem conflito entre instâncias.

  • Rolling update : menos indisponibilidade.

  • Frontend por último : interface só funciona se o resto estiver estável.