Caso seja preciso, é possível parar a atualização dos jobs, deletando-os diretamente no cluster (# kubectl -n c2a7dv cNamespace delete job <<nome do job>> ). Porém, ao executar este processo deverá ser avaliado o que o mesmo executará. Um exemplo é o caso do “migration” (upddistr), ao deletar este job deveremos realizar a geração dos flags de controle de execução dos pods (# touch /volume/flags/<<filename>>). Além disto, temos que garantir que os demais processos foram executados. Caso durante o processo de atualização, quebre o UPDDISTR. Devemos entrar no volume do ambiente e verificar o erro gerado dentro do UPDDISTR.LOG que fica na pasta /volume/logs. Neste momento temos algumas ações: - Se o problema for de usuário e senha. Basta reiniciar o pod do upddistr para reiniciar o processo. Isto ocorre devido a falta de conectividade com o HLCLOUD. Caso seja preciso, acionar o time de FRAMEWORK para avaliar o HLCLOUD.
- Se o problema for na criação de campos/índices disponibilizados recentemente. Recomendo abortar o processo e identificar o módulo responsável pelo campo para ajustar no ATUSX. INFORMAR o time de GCAD sobre o erro.
- Se o problema for em campos/índices já existentes, direcionar a ocorrência para o time de banco de dados da engenharia avaliar. Neste caso, recomendo abortar a atualização até o ajuste do banco pelo time.
- Se for processos de infraestrutura, devemos atuar pontualmente e reiniciar o processo.
- Se o problema for em algum RUP, temos duas opções.
- Alterar o deployment do cronjob de migrator e adicionar o sleeper no command (# kubectl -n c2a7dv edit cj protheus-updater)
- Copiar o novo RPO para dentro do pod do cronjob (# kubectl -n c2a7dv cp tttm120.rpo c2a7dv/protheus-updater-xxxxx:protheus/apo/tttm120.rpo)
- Executar o init-upddistr diretamente dentro do pod(# init-upddistr)
- Retirar o rup do RPO e executar o processo na mão
- Abortar o processo e fazer o rollback no banco de dados.
Para todos os casos citados acima, recomendo realizar todo o troubleshoot antes de acionar os times responsáveis por cada artefato. Para todos os casos que envolvem rollback de dados, : coletar os logs de erro, realizar o processo citado no item Restore de dados e enviar os logs para o time de gestão de dados. Caso o problema identificado seja na atualização do HELM: Falta de imagem, falta de recurso ou quaisquer problemas de infra, realizar a análise do motivo do erro estar ocorrendo. Nesta situação temos a possibilidade de executar o helm upgrade na mão. Basta alterar o ns, informando a versão desejada (UpdateDesiredVersion) e criar o job de atualização na mão.
| Expandir |
|---|
| title | Realizando o rollback via HELM |
|---|
| 0. Somente se o job travou e não deu backofflime: kubectl -n cNAMESPACE delete job --all --force --grace-period=0
1. helm history cNAMESPACE -n cNAMESPACE
2. Anotar a ultima versão que esta com o status de deployed (n###)
3. Executar o rollback no ambiente: helm rollback cNAMESPACE (n###)
4. Deletar todos os pods do namespace para não dar conflito de rede. |
| Expandir |
|---|
| title | Realizando o rollback manualmente (Via secrets) |
|---|
| 1. Executar o comando: kubectl -n cNAMESPACE get secrets
2. Localizar a ultima secret criada com o nome de helm e o namespace (sh.helm.release.v1.cNAMESPACE)
3. Excluir o ultimo secret gerado
4. Reexecutar o helm upgrade no ambiente. Neste caso, com o processo de atualização do chart, as rotinas de atualização irão atualizar as labels de status e baseVersion no namespace. |
| Aviso |
|---|
| title | IMPORTANTE: Arrumar as labels do ambiente após manutenção |
|---|
| 1. Editar o namespace e deixar o desiredVersion igual ao baseVersion
kubectl edit ns cNAMESPACE
2. Atualizar o status do ambiente com o seguinte comando:
kubectl -n cNAMESPACE patch configmap protheus-updater-config -p '{"data":{"UPDATER_STATUS":"OK" }}'
3. Liberar o uso do ambiente |
| 