|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Guia de Uso de Backup e Restauração
O chart de Backups do Rancher é nossa solução para recuperação de desastres e migração. Este chart permite que você faça backups de seus recursos do Kubernetes e os salve em uma variedade de locais de armazenamento persistente.
Este chart é uma ferramenta muito simples que atua em muitas áreas diferentes do ecossistema Rancher. Como resultado, surgiram casos limite que levam a funcionalidades não documentadas. O objetivo deste documento é destacar o uso adequado e definido para os Backups do Rancher, além de discutir alguns desses casos limite que encontramos.
Visão Geral da Funcionalidade
Backup
O operador coleta todos os recursos capturados pelo resourceSet no chart como objetos não estruturados em memória. Após a coleta dos recursos, um arquivo tar comprimido dos recursos é salvo como uma coleção de manifests em JSON e, em seguida, enviado para um armazenamento de objetos definido pelo usuário. Este backup pode ser programado para repetição e também pode ser criptografado. Esta opção de criptografia é importante, pois alguns dos recursos são sensíveis e os valores são armazenados em texto simples sem criptografia.
Consulte a documentação de configuração de backup para mais informações sobre as opções, incluindo criptografia, para configurar um backup.
|
Conforme mencionado na documentação de Backup do Rancher, você deve salvar manualmente o conteúdo do arquivo de configuração de criptografia, pois o operador não fará o backup. |
Restaurar
Existem dois cenários principais de restauração: restaurar para um cluster com o Rancher em execução e restaurar para um cluster novo. Você só pode restaurar para um cluster com o Rancher em execução se for o mesmo cluster de onde o backup foi feito e a prune opção estiver habilitada durante a restauração. Uma restauração tem entradas semelhantes a um backup. Ela requer um nome de arquivo de backup, o nome do encryptionConfigSecret e o local de armazenamento.
Os recursos são restaurados nesta ordem:
-
Definições de Recursos Personalizados (CRDs)
-
Recursos com escopo de cluster
-
Recursos com escopo de namespace
Consulte a documentação de Configuração de Restauração para mais informações sobre as opções para configurar uma restauração.
Conjuntos de recursos
O resourceSet determina quais recursos o operador de backup-restauração coleta em um backup. É um conjunto de ResourceSelectors, que definem os requisitos de seleção usando correspondência de chave/valor, correspondência de expressão regular ou o labelSelector do cliente Kubernetes.
Estes são os diferentes campos disponíveis para um resourceSelector:
-
versãoApi
-
excludeKinds
-
excludeResourceNameRegexp
-
kinds
-
kindsRegexp
-
labelSelectors
-
namespaceRegexp
-
namespaces
-
resourceNameRegexp
-
resourceNames
O chart de Backups do Rancher contém um conjunto de recursos padrão, que é uma combinação de arquivos YAML que são adicionados a um grande conjunto de recursos quando o chart é instalado. A ordem dos arquivos não importa. Os conjuntos de recursos podem diferir entre as versões.
|
Se você deseja fazer edições no conjunto de recursos, por favor, edite-o antes de instalar o chart. |
Uso Adequado
Esta seção descreve as diretrizes para o uso adequado do chart de Backups do Rancher de acordo com seu caso de uso.
Todos os Casos
-
Os Backups do Rancher devem ser instalados no cluster local.
-
NOTA: Os Backups do Rancher não gerenciam nenhum cluster além daquele em que estão instalados. Ele pode restaurar recursos do cluster que estão no cluster local, mas não se comunicará com os clusters downstream nem fará backup deles.
-
-
A versão do Rancher para a qual está sendo restaurado deve corresponder à versão do Rancher do backup.
-
A versão do Kubernetes deve ser considerada, pois você pode estar restaurando recursos desatualizados (recursos obsoletos da versão do Kubernetes para a qual está restaurando).
Backups
-
Alguns recursos gerados pelo usuário não serão salvos a menos que possam ser capturados pelo conjunto de recursos padrão ou o conjunto de recursos tenha sido alterado para capturá-los.
-
Fornecemos um rótulo
resources.cattle.io/backup:trueque, quando adicionado a um segredo em qualquer namespace, resultará em seu backup.
-
-
Backups não são mutáveis.
-
Os backups são apenas do cluster local
Restaurações
-
Uma restauração refere-se a restaurar um backup para o mesmo cluster de onde foi feito. Isso pode ser feito com o Rancher instalado (o prune deve estar habilitado) ou sem ele instalado (sem instruções especiais).
-
Uma coisa a notar ao restaurar é que você pode se ver precisando “wipe” o cluster de quaisquer recursos do Rancher. Isso pode ser feito implantando o script de limpeza do Rancher como um trabalho para o cluster. Isso permite que você instale os Backups do Rancher novamente e restaure para um cluster completamente novo.
-
Certifique-se de usar kubectl para implantar os scripts.
-
Migraçőes
A migração tem algumas nuances a mais, pois estamos restaurando para um cluster diferente. Estas são algumas coisas para lembrar que costumam ser esquecidas ou negligenciadas.
-
O domínio do Rancher deve ser o mesmo ao migrar. Isso significa que o nome de domínio do seu cluster anterior deve agora apontar para o novo cluster.
-
O Rancher não deve estar em execução no cluster para o qual você está migrando. Isso pode causar muitos problemas com backups do Rancher e certos serviços do Rancher também.
-
Instale a mesma versão do Rancher a partir do backup após o backup ter sido restaurado.
-
Se você optar por provisionar o novo cluster em uma versão diferente do Kubernetes, saiba que isso pode causar uma ampla variedade de comportamentos não suportados, pois a API do Kubernetes disponível pode ser diferente da que você fez o backup. Isso pode levar à restauração de recursos descontinuados, o que causará problemas.
-
Você não deve fazer upgrade durante uma migração.
Casos Limite e Uso Indevido
Abaixo estão alguns exemplos de usos ou expectativas incorretos dos Backups do Rancher.
Upgrades
-
Usar backups do Rancher para fazer upgrade de versões do Rancher não é um caso de uso válido. O procedimento recomendado é fazer um backup da versão atual, depois fazer upgrade da sua instância do Rancher usando estas instruções, e então fazer outro backup após o upgrade ser concluído. Dessa forma, se o upgrade falhar, você terá um backup para restaurar, e o segundo backup será válido para restaurar a versão do Rancher atualizada.
-
Usar backups do Rancher para fazer upgrade de versões do Kubernetes também não é um caso de uso válido. Como a API do Kubernetes e os recursos disponíveis estão atrelados à versão, fazer upgrade usando a restauração de backup pode levar a problemas com conjuntos de recursos desalinhados que podem estar descontinuados, não suportados ou atualizados. Como fazer upgrade da versão do seu cluster dependerá de como ele foi provisionado, no entanto, o mesmo formato que acima é recomendado (backup, fazer upgrade, backup).
ResourceSet
-
Devido à evolução de recursos e serviços de várias equipes, os desenvolvedores devem observar se novos recursos precisam ser adicionados ou removidos do resourceSet padrão.
-
Os backups do Rancher apenas fazem backup do que é capturado pelos resourceSets padrão (a menos que editados). Adicionamos um rótulo específico para segredos criados pelo usuário que fará backup de um segredo de qualquer nome e namespace que tenha esse rótulo (veja Uso Adequado de Backups).
Clusters downstream
-
Os Backups do Rancher só fazem backup de recursos Kubernetes no cluster local. Isso significa que os clusters downstream não são tocados ou incluídos no backup, exceto por sua presença nos recursos do cluster local. A atualização e comunicação dos clusters downstream são de responsabilidade do rancher-agent e do rancher-webhook.
Restaurando Recursos Excluídos
-
Alguns recursos têm resultados externos produzidos, como o provisionamento de um cluster downstream. Excluir um cluster downstream e restaurar o recurso do cluster no cluster local não faz com que o Rancher reprovisione esse cluster. Dependendo do recurso, a restauração pode não trazer completamente o recurso de volta a um estado disponível.
-
O caso limite de "restaurar um cluster excluído" não é um recurso suportado. Quando se trata de clusters downstream, sejam provisionados ou importados, excluí-los causa uma série de tarefas de limpeza que não permitem ao usuário restaurar os clusters excluídos. Clusters provisionados terão seus nós e recursos de provisionamento relacionados ao Rancher destruídos, e clusters importados provavelmente terão seus agentes do Rancher e outros recursos/serviços relacionados ao registro com um cluster local destruídos.
|
Tentar excluir e restaurar um cluster downstream pode levar a uma variedade de problemas com o Rancher, Rancher Backups, rancher-webhook, Fleet e mais. Não é recomendado fazer isso. |
SUSE® Rancher Prime: Continuous Delivery, SUSE Virtualization e Outros Serviços
Outros serviços, que são submetidos a backup pelo Rancher Backups, frequentemente mudam e evoluem. À medida que isso acontece, seus recursos e necessidades de backup também podem mudar. Alguns recursos podem não necessitar de backup e alguns nem são submetidos a backup. É importante que as equipes considerem isso em seu processo de desenvolvimento e avaliem se seus conjuntos de recursos relacionados estão capturando corretamente o conjunto adequado de recursos para que seus serviços sejam restaurados corretamente.
Monitoramento de Backups e Restaurações
O Rancher oferece recursos de monitoramento prontos para uso para o Backup Operator. Eles estão desativados por padrão, mas podem ser facilmente ativados ao implantar o Helm Chart do operador.
Métricas
Métricas podem ser ativadas definindo monitoring.metrics.enabled: true e monitoring.serviceMonitor.enabled: true nos valores do Helm Chart. Quando ativado, o Operador exporta as seguintes métricas. Observe que rancher-monitoring precisa estar instalado previamente para que as métricas sejam exportadas corretamente.
| Nome da Métrica | Descrição |
|---|---|
|
Detalhes sobre um CR de Backup específico do Rancher (rótulos: |
|
Número de CRs de Backup do Rancher existentes. Tipo Gauge. |
|
Número total de Backups do Rancher processados pelo Operador (rótulos: |
|
Número total de Backups do Rancher processados com falha por este operador (rótulos: |
|
Duração de cada backup processado pelo Operador em segundos (rótulos: |
|
Tempo Unix de quando o último Backup foi processado (em segundos) (rótulos: |
|
Detalhes sobre um CR de Restauração específico do Rancher (rótulos: |
|
Número de CRs de Restauração do Rancher existentes. Tipo Gauge. |
Alertas
Apenas um alerta é fornecido por padrão, 'BackupFailed', que avisa os usuários quando um Backup falha ao ser processado pelo Operador. Ele pode ser ativado configurando monitoring.prometheusRules.defaultAlert.enabled: true.
Os usuários também podem implantar suas próprias regras de alerta configurando monitoring.prometheusRules.customRules.enabled: true e definindo-as em monitoring.prometheusRules.customRules.rules.