Introdução
Neste tutorial, você aprenderá como implantar o TrilioVault para Kubernetes (ou TVK) no seu cluster DOKS, criar backups e recuperar a partir de um backup caso algo dê errado. Você pode fazer backup de todo o seu cluster ou optar por backups baseados em namespace ou rótulo.
Vantagens de usar o Trilio:
- Faça backups completos (ou incrementais) do seu cluster e restaure em caso de perda de dados.
- Migre de um cluster para outro.
- Backups de lançamento do Helm são suportados.
- Execute ganchos pré e pós-operacionais para operações de backup e restauração.
- Console de gerenciamento da web que permite inspecionar detalhadamente o estado das suas operações de backup/restauração.
- Defina políticas de retenção para seus backups.
- O ciclo de vida da aplicação (ou seja, o próprio TVK) pode ser gerenciado por meio de um Operador TrilioVault dedicado.
- Integração com Velero.
- Você pode fazer backup e restaurar aplicativos baseados em operador.
Para mais informações, consulte a documentação oficial do TVK CRDs.
Índice
- Pré-requisitos
- Passo 1 – Instalando o TrilioVault para Kubernetes
- Passo 2 – Criando um Destino TrilioVault para Armazenar Backups
- Passo 3 – Conhecendo o Console de Gerenciamento Web do TVK
- Passo 4 – Exemplo de Backup e Restauração com Namespace
- Passo 5 – Exemplo de Backup e Restauração de Todo o Cluster
- Passo 6 – Backups Agendados
- Passo 7 – Política de Retenção de Backups
- Conclusão
Pré-requisitos
Para completar este tutorial, você precisa dos seguintes:
- A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
- A Git client to clone the Starter Kit repository.
- Helm, para gerenciar lançamentos e atualizações do TrilioVault Operator.
- Doctl para interação com a API da DigitalOcean.
- Kubectl para interação com o Kubernetes.
Para que o TrilioVault funcione corretamente e faça backup de seus PVCs, o DOKS precisa ser configurado para suportar a Interface de Armazenamento de Contêiner (ou CSI, na sigla em inglês). Por padrão, ele vem com o driver já instalado e configurado. Você pode verificar usando o seguinte comando:
A saída deve ser semelhante ao trecho a seguir. Observe que o provisionador é dobs.csi.digitalocean.com.
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
do-block-storage (default) dobs.csi.digitalocean.com Delete Immediate true 10d
A instalação do TrilioVault também precisa da Definição de Recurso Personalizado (CRD) volumeSnapshot para uma instalação bem-sucedida. Você pode verificar usando o seguinte comando:
A saída deve ser semelhante ao trecho a seguir. Se a CRD VolumeSnapshot não estiver instalada, consulte Instalando CRDs de VolumeSnapshot.
volumesnapshotclasses.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io 2022-02-01T06:01:15Z
Além disso, certifique-se de que a CRD suporte as versões de API v1beta1 e v1. Você pode executar o seguinte comando para verificar a versão da API:
No final do YAML do CRD, você deve ver uma lista storedVersions, contendo os valores tanto de v1beta1 quanto de v1 (se não estiver instalado, consulte Instalando CRDs de VolumeSnapshot):
...
- lastTransitionTime: "2022-01-20T07:58:06Z"
message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
reason: ApprovedAnnotation
status: "True"
type: KubernetesAPIApprovalPolicyConformant
storedVersions:
- v1beta1
- v1
Passo 1 – Instalando TrilioVault para Kubernetes
Nesta etapa, você aprenderá como implantar o TrilioVault para DOKS e gerenciar instalações do TVK via Helm. Os dados de backup serão armazenados no bucket do DO Spaces criado anteriormente na seção Pré-requisitos.
A aplicação TrilioVault pode ser instalada de várias maneiras:
- Através do Operador TrilioVault. Você define um CRD
TrilioVaultManagerque diz ao operadorTrilioVaultcomo lidar com a instalação, etapas de pós-configuração e futuras atualizações dos componentes da aplicação Trilio. - Através do gráfico triliovault-operator que é totalmente gerenciado pelo Helm, (coberto neste tutorial).
Instalando o TrilioVault usando Helm
O tutorial do Starter Kit usa o tipo de instalação de Cluster para a aplicação TVK (applicationScope o valor Helm é definido como “Cluster”). Todos os exemplos deste tutorial dependem deste tipo de instalação para funcionar corretamente.
Primeiro, clone o repositório Git do Starter Kit e mude o diretório para sua cópia local:
Em seguida, adicione o repositório Helm do TrilioVault e liste os gráficos disponíveis:
O resultado se parece com o seguinte:
NAME CHART VERSION APP VERSION DESCRIPTION
triliovault-operator/k8s-triliovault-operator 2.9.2 2.9.2 K8s-TrilioVault-Operator is an operator designe...
O gráfico de interesse é triliovault-operator/k8s-triliovault-operator, que irá instalar o TrilioVault para Kubernetes no cluster junto com o TrilioVault-Manager. Você pode executar helm show values triliovault-operator/k8s-triliovault-operator e exportar para um arquivo para ver todas as opções disponíveis.
Em seguida, abra e inspecione o arquivo de valores do Helm do TrilioVault fornecido no repositório Starter kit usando um editor de sua escolha (preferencialmente com suporte a lint YAML).
Finalmente, instale o TrilioVault para Kubernetes usando Helm:
–create-namespace \
O comando acima instala tanto o Operador TrilioVault quanto o Recurso Personalizado TriloVault Manager (TVM) usando os parâmetros fornecidos no arquivo triliovault-values.yaml. A versão TVK é agora gerenciada pelo campo tag no arquivo 05-setup-backup-restore/assets/manifests/triliovault-values.yaml, então o comando helm sempre terá a versão mais recente do TVK.
- Você pode atualizar os seguintes campos em
values.yaml: installTVK.applicationScopepara instalação do TVK com escopo, por exemplo,ClusterouNamespacedinstallTVK.ingressConfig.hostpara o nome do host da interface do usuário do TVK, por exemplo,tvk-doks.com
installTVK.ComponentConfiguration.ingressController.service.type para tipo de serviço para acessar a interface do usuário do TVK, por exemplo, NodePort ou LoadBalancer
Agora, verifique sua implantação do TVK:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
triliovault-manager-tvk tvk 1 2022-06-08 08:30:08.490304959 +0000 UTC deployed k8s-triliovault-2.9.2 2.9.2
triliovault-operator tvk 1 2022-06-08 11:32:55.755395 +0300 EEST deployed k8s-triliovault-operator-2.9.2 2.9.2
A saída se parece com o seguinte trecho (STATUS coluna deve exibir implementado):
Em seguida, verifique se o TrilioVault está funcionando:
NAME READY UP-TO-DATE AVAILABLE AGE
k8s-triliovault-admission-webhook 1/1 1 1 83s
k8s-triliovault-control-plane 1/1 1 1 83s
k8s-triliovault-exporter 1/1 1 1 83s
k8s-triliovault-ingress-nginx-controller 1/1 1 1 83s
k8s-triliovault-web 1/1 1 1 83s
k8s-triliovault-web-backend 1/1 1 1 83s
triliovault-operator-k8s-triliovault-operator 1/1 1 1 4m22s
A saída se parece com o seguinte trecho. Todos os pods de implantação devem estar no estado Pronto.
Se a saída se parecer com isso, você instalou o TVK com sucesso. Em seguida, você aprenderá como verificar o tipo e a validade da licença, bem como como renová-la.
Licenciamento de Aplicativo TrilioVault
- Por padrão, ao instalar o TVK via Helm, não há licença de avaliação gratuita instalada automaticamente. Você sempre pode ir ao site da Trilio e gerar uma nova licença para seu cluster que atenda às suas necessidades (por exemplo, você pode escolher o tipo de licença básico que permite executar o TrilioVault indefinidamente se a capacidade do seu cluster não exceder 10 nós). Uma licença de avaliação gratuita permite que você execute o TVK por um mês em nós de cluster ilimitados.
- O TrilioVault é gratuito para clusters Kubernetes com até 100000 nós para usuários da DigitalOcean. Eles podem seguir as seguintes etapas para criar uma licença especial disponível apenas para clientes da DO.
Exemplos de Starter Kit dependem de um tipo de licença de Cluster para funcionar corretamente.
Criando e Verificando Licenciamento de Aplicativo TVK
Execute o seguinte comando para criar uma nova licença para o seu cluster (ela é gerenciada via CRD de Licença):
O comando acima criará um trabalho job.batch/tvk-license-digitalocean que executará um pod tvk-license-digitalocean-828rx para obter a licença do Servidor de Licenças da Trilio e instalá-la no cluster DOKS. Após a conclusão do trabalho, ele será excluído em 60 segundos.
Se você estiver baixando uma licença gratuita do site da Trilio, aplique-a usando este comando:
Por favor, execute o seguinte comando para verificar se a licença está instalada e no estado Ativo no seu cluster.
NAME STATUS MESSAGE CURRENT NODE COUNT GRACE PERIOD END TIME EDITION CAPACITY EXPIRATION TIME MAX NODES
test-license-1 Active Cluster License Activated successfully. 1 FreeTrial 100000 2023-02-25T00:00:00Z 1
A saída se parece com o seguinte. Observe o STATUS, que deve ser Ativo, bem como o tipo de licença na coluna EDITION e o TEMPO DE EXPIRAÇÃO.
A licença é gerenciada via um CRD especial chamado objeto License. Você pode inspecioná-lo executando o seguinte comando:
A saída se parece com o seguinte. Observe os campos Mensagem e Capacidade, bem como a Edição.
A saída acima também informará quando a licença expirará no campo Timestamp de Expiração e o Escopo (baseado em Cluster neste caso). Você pode optar por um tipo de licença de escopo cluster ou baseado em namespace.
Renovando a Licença de Aplicativo TVK
Para renovar a licença, você terá que solicitar uma nova no site da Trilio navegando até a página de licenciamento para substituir a antiga. Após preencher o formulário, você deve receber o manifesto YAML da Licença, que pode ser aplicado ao seu cluster usando kubectl. Os comandos a seguir assumem que o TVK está instalado no namespace padrão tvk (substitua os espaços reservados <> conforme necessário):
# Obter informações sobre uma licença específica do namespace `tvk`
No próximo passo, você aprenderá como definir o backend de armazenamento para o TrilioVault para armazenar backups chamado de alvo.
Passo 2 – Criando um Destino TrilioVault para Armazenar Backups
A typical Target definition looks like:
O TrilioVault precisa primeiro saber onde armazenar seus backups. O TrilioVault se refere ao backend de armazenamento usando o termo destino, e é gerenciado por meio de um CRD especial chamado Destino. Os seguintes tipos de destino são suportados: S3 e NFS. Para o DigitalOcean e para o propósito do Kit Inicial, faz sentido confiar no tipo de armazenamento S3 porque é barato e escalável. Para se beneficiar de um nível aprimorado de proteção, você pode criar vários tipos de destino (tanto S3 quanto NFS), para que seus dados sejam mantidos em vários lugares, alcançando assim a redundância de backup.
- Nesta configuração,
spec.type: Tipo de destino para armazenamento de backup (S3 é um armazenamento de objetos).spec.vendor: Fornecedor de armazenamento de terceiros que hospeda o destino (para o DigitalOcean Spaces, você precisa usarOutroem vez deAWS).spec.enableBrowsing: Ativar navegação para o destino.spec.objectStoreCredentials: Define as credenciais necessárias (viacredentialSecret) para acessar o armazenamentoS3, além de outros parâmetros, como região e nome do bucket.
spec.thresholdCapacity: Capacidade máxima de limite para armazenar dados de backup.
# o valor deve estar codificado em base64
Observe que o nome do segredo é trilio-s3-target e é referenciado pelo campo spec.objectStoreCredentials.credentialSecret do CRD de Destino explicado anteriormente. O segredo pode estar no mesmo namespace onde o TrilioVault foi instalado (padrão para tvk), ou em outro namespace de sua escolha. Apenas certifique-se de referenciar o namespace corretamente. Por outro lado, por favor, certifique-se de proteger o namespace onde você armazena os segredos do TrilioVault via RBAC por motivos de segurança.
Passos para criar um Destino para o TrilioVault:
Primeiro, altere o diretório onde o repositório Git do Starter Kit foi clonado em sua máquina local:
Em seguida, crie o segredo do Kubernetes contendo as credenciais do seu bucket S3 de destino (substitua os espaços reservados <> conforme necessário):
–from-literal=accessKey=“<SEU_ACCESS_KEY_DO_DO_SPACES_AQUI>” \
–from-literal=secretKey=“<SUA_SECRET_KEY_DO_DO_SPACES_AQUI>”
Em seguida, abra e inspecione o arquivo de manifesto de destino fornecido no repositório do Starter Kit usando um editor de sua escolha (preferencialmente com suporte a lint YAML).
Agora, substitua os marcadores <> conforme necessário para o seu bucket DO Spaces Trilio, como bucketName, region, url e credentialSecret.
Por fim, salve o arquivo de manifesto e crie o objeto de Destino usando kubectl:
NAME TYPE THRESHOLD CAPACITY VENDOR STATUS BROWSING ENABLED
trilio-s3-target ObjectStore 10Gi Other Available
Em seguida, o TrilioVault irá iniciar um job de worker chamado trilio-s3-target-validator responsável por validar o seu bucket S3 (como disponibilidade, permissões, etc.). Se o job terminar com sucesso, o bucket é considerado saudável ou disponível e o recurso de job trilio-s3-target-validator é excluído em seguida. Se algo der errado, o job validador de destino S3 permanece em execução para que você possa inspecionar os logs e encontrar o possível problema.
Agora, por favor, verifique se o recurso de Destino criado anteriormente está saudável:
# A saída se parece com:
...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
mount_s3_datastore(metadata_list, base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
wait_until_mount(base_path)
File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...
#trilio-s3-target-validator-tio99a-6lz4q 1/1 Em Execução 0 104s
# Agora, obtenha os dados de logs
A saída será essa exceção:
Em seguida, você descobrirá o console da web TVK, que é uma adição útil para ajudá-lo a gerenciar facilmente operações de backup e restauração, entre muitas outras.
Passo 3 – Conhecendo o Console de Gerenciamento Web da TVK
Embora seja possível gerenciar operações de backup e restauração completamente via CLI usando o kubectl e CRDs, a TVK fornece um Console de Gerenciamento Web para realizar as mesmas operações via GUI. O console de gerenciamento simplifica tarefas comuns por meio de operações de clique e oferece melhor visualização e inspeção de objetos do cluster TVK, além de criar planos de recuperação de desastres (ou DRPs).
A instalação baseada em Helm abordada no Passo 1 – Instalando o TrilioVault para Kubernetes já cuidou da instalação dos componentes necessários para o console de gerenciamento web.
Obtendo Acesso ao Console de Gerenciamento Web da TVK
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
k8s-triliovault-admission-webhook ClusterIP 10.245.202.17 <none> 443/TCP 13m
k8s-triliovault-ingress-nginx-controller NodePort 10.245.192.140 <none> 80:32448/TCP,443:32588/TCP 13m
k8s-triliovault-ingress-nginx-controller-admission ClusterIP 10.3.20.89 <none> 443/TCP 13m
k8s-triliovault-web ClusterIP 10.245.214.13 <none> 80/TCP 13m
k8s-triliovault-web-backend ClusterIP 10.245.10.221 <none> 80/TCP 13m
triliovault-operator-k8s-triliovault-operator-webhook-service ClusterIP 10.245.186.59 <none> 443/TCP 16m
Para poder acessar o console e explorar os recursos que ele oferece, você precisa encaminhar a porta do serviço do controlador de ingresso para a TVK.
A saída se parece com o seguinte. Procure pela linha k8s-triliovault-ingress-nginx-controller e observe que ele está ouvindo na porta 80 na coluna PORT(S).
127.0.0.1 tvk-doks.com
A TVK está usando um Controlador de Ingresso Nginx para rotear o tráfego para os serviços do console de gerenciamento web. O roteamento é baseado em host, e o nome do host é tvk-doks.com conforme definido no arquivo de valores do Helm do Starter Kit:
# O nome do host a ser usado ao acessar o console web via o controlador de ingresso nginx da TVK
Por fim, exporte o arquivo kubeconfig para o seu cluster DOKS. Este passo é necessário para que o console web possa autenticá-lo.
# Listar os clusters disponíveis
# Salvar a configuração do cluster para YAML
Se você tiver apenas um cluster, execute o seguinte comando:
Após seguir esses passos, você pode acessar o console no seu navegador da web navegando para: http://tvk-doks.com:8080. Quando solicitado pelo arquivo kubeconfig, selecione o que você criou no último comando acima.
Por favor, mantenha o arquivo kubeconfig gerado em segurança, pois ele contém dados sensíveis.
- Explorando a Interface de Usuário do Console Web TVK
- Explore cada seção da esquerda, como:
- Gerenciamento de Cluster: Isso mostra a lista de clusters principais e outros clusters com instâncias TVK, adicionados ao cluster OVH principal usando o recurso de Gerenciamento de Múltiplos Clusters.
- Backup e Recuperação: Este é o painel principal que fornece uma visão geral do cluster inteiro, como espaços de nomes descobertos, Aplicações, lista de planos de backup, Destinos, Hooks, Políticas, etc.
Monitoramento: Isso tem duas opções – Monitoramento do TrilioVault e Monitoramento do Velero se o usuário tiver o Velero configurado em seu cluster OVH.
Recuperação de Desastres: Permite gerenciar e realizar operações de recuperação de desastres.
Recuperação de Desastres: Permite gerenciar e realizar operações de recuperação de desastres.
Também é possível ver o Destino S3 criado anteriormente, navegando até Backup & Recuperação -> Destinos -> <Namespace> a partir do menu suspenso no topo.
Além disso, você pode navegar até o destino e listar os backups disponíveis clicando no botão Ações à direita e selecionando a opção Iniciar Navegador no menu pop-up. Para que isso funcione, o destino deve ter o sinalizador enableBrowsing definido como true.
Para mais informações e recursos disponíveis, consulte a documentação oficial da Interface de Usuário do Console de Gerenciamento Web do TVK.
Em seguida, você aprenderá como realizar operações de backup e restauração para casos de uso específicos.
Passo 4 – Exemplo de Backup e Restauração com Namespace
Neste passo, você aprenderá como criar um backup único para um namespace inteiro (ambassador neste caso) do seu cluster DOKS e restaurá-lo posteriormente, garantindo que todos os recursos sejam recriados. TVK possui um recurso que permite realizar backups em um nível mais alto do que apenas namespaces.
- Criando o Backup do Release do Helm do Ambassador
- Para realizar backups para uma única aplicação no nível do namespace (ou release do Helm), é necessário um BackupPlan seguido por um Backup CRD. BackupPlan é uma definição de ‘o que’, ‘onde’, ‘para’ e ‘como’ do processo de backup, mas não realiza o backup real. O Backup CRD é responsável por acionar o processo real de backup, conforme ditado pela especificação do BackupPlan.
- Nesta configuração,
A typical Backup CRD looks like below:
spec.backupConfig.target.name: Indica para TVK qual nome de destino usar para armazenar os backups.
spec.backupConfig.target.namespace: Indica para TVK em qual namespace o destino foi criado.spec.backupComponents: Define uma lista de recursos para fazer backup.
Nesta configuração,
spec.type: Especifica o tipo de backup.
spec.backupPlan: Especifica o BackupPlan que este Backup deve usar.
Passos para iniciar o backup único do Ambassador Helm release:
Primeiro, certifique-se de que o Ambassador Edge Stack esteja implantado em seu cluster seguindo as etapas do tutorial Ambassador Ingress.
Em seguida, mude o diretório para onde o repositório Git do Starter Kit foi clonado em sua máquina local:
Depois, abra e inspecione os arquivos de manifesto Ambassador BackupPlan e Backup fornecidos no repositório Starter Kit usando um editor de sua escolha (preferencialmente com suporte a lint YAML).
NAME TARGET ... STATUS
ambassador-helm-release-backup-plan trilio-s3-target ... Available
Por fim, crie os recursos BackupPlan e Backup usando kubectl.
Agora, inspecione o status do BackupPlan (direcionando para o release Helm ambassador) usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full InProgress ...
A saída é semelhante ao seguinte. Observe o valor da coluna STATUS que deve ser definido como Available.
Em seguida, verifique o status do objeto Backup usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE
ambassador-helm-release-full-backup ambassador-helm-release-backup-plan Full Available ... 100
A saída é semelhante ao seguinte. Observe o valor da coluna STATUS que deve ser definido como InProgress, bem como o TIPO DE BACKUP definido como Completo.
Depois que todos os componentes do embaixador Helm forem carregados no destino S3, você deve obter esses resultados:
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04 311 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04 302 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04 305 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04 28 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04 330 s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...
# A saída se parece com (observe que o `STATUS` mudou para `Disponível` e `PERCENTAGE` é `100`)
Se a saída se parecer com isso, você fez o backup com sucesso do lançamento do Helm do embaixador. Você pode prosseguir e ver como o TrilioVault armazena metadados do Kubernetes listando o conteúdo do Bucket S3 do TrilioVault. Por exemplo, você pode usar s3cmd:
ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx 1/1 Running 0 4m32s
A saída se parece com o seguinte. Observe que a listagem contém os manifestos JSON e UIDs, representando objetos do Kubernetes.
No caso do backup não se tornar disponível, você pode inspecionar os logs do Pod metamover para encontrar o problema:
...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...
A saída se parece com:
Agora, obtenha os dados de logs:
A saída se parece com o seguinte.
Finalmente, você pode verificar que o backup está disponível também no console da web navegando até Gerenciamento de Recursos -> Embaixador -> Planos de Backup. Observe que está no estado Disponível e que o lançamento do Helm do embaixador foi backupado na sub-visualização Detalhes do Componente.
Excluindo o Lançamento do Helm do Embaixador e Recursos
Agora, vá em frente e simule um desastre deletando intencionalmente o lançamento do Helm do ambassador:
Em seguida, verifique se os recursos do namespace foram deletados (a listagem deve estar vazia):
- Por fim, verifique que o endpoint dos serviços de backend
echoequoteestáDOWN. Consulte Criando os Serviços de Backend do Stack de Borda do Ambassador em relação às aplicações de backend usadas no tutorial do Starter Kit. Você pode usar ocurlpara testar (ou pode usar o seu navegador da web): - Restaurando o Backup do Lançamento do Helm do Ambassador
- Importante
Se estiver restaurando o mesmo namespace, certifique-se de que os componentes da aplicação original tenham sido removidos. Especialmente o PVC da aplicação deve ser deletado.
Se estiver restaurando para outro cluster (cenário de migração), certifique-se de que o TrilioVault for Kubernetes também está em execução no namespace/cluster remoto. Para restaurar em um novo cluster (onde o CR de Backup não existe), source.type deve ser definido como location. Consulte a Seção de Definição de Recurso Personalizado de Restauração para ver um exemplo de restauração por localização.
- Ao excluir o namespace
ambassador, o recurso de balanceador de carga associado ao serviço ambassador também será excluído. Portanto, ao restaurar o serviçoambassador, o LB será recriado pela DigitalOcean. O problema é que você obterá um NOVO IP para o seu LB, então será necessário ajustar osregistros Apara direcionar o tráfego para seus domínios hospedados no cluster. - Para restaurar um Backup específico, você precisa criar um
RestoreCRD. O CRD de Restauração típico se parece com o seguinte: - Nesta configuração,
spec.source.type: Especifica o tipo de backup a ser restaurado.
spec.source.backup: Contém uma referência ao objeto de backup a ser restaurado.
spec.skipIfAlreadyExists: Especifica se deve pular a restauração de um recurso se ele já existir no namespace restaurado.
Restore permite restaurar o último Backup bem-sucedido para um aplicativo. É usado para restaurar um único namespace ou release do Helm, protegido pelo CRD de Backup. O CRD de Backup é identificado pelo nome ambassador-helm-release-full-backup.
Primeiro, inspecione o exemplo do CRD de Restore no repositório Git do Starter Kit:
NAME STATUS DATA SIZE START TIME END TIME PERCENTAGE COMPLETED DURATION
ambassador-helm-release-restore Completed 0 2021-11-25T15:06:52Z 2021-11-25T15:07:35Z 100 43.524191306s
Em seguida, crie o recurso de Restore usando kubectl:
Por fim, inspecione o status do objeto de Restore:
A saída se parece com o seguinte. Observe a coluna STATUS definida como Completed, assim como o PERCENTAGE COMPLETED definido como 100.
Se a saída se parecer com isso, então o processo de restauração do release do Helm ambassador foi concluído com sucesso.
NAME READY STATUS RESTARTS AGE
pod/ambassador-5bdc64f9f6-42wzr 1/1 Running 0 9m58s
pod/ambassador-5bdc64f9f6-nrkzd 1/1 Running 0 9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv 1/1 Running 0 9m58s
pod/ambassador-redis-64b7c668b9-69drs 1/1 Running 0 9m58s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ambassador LoadBalancer 10.245.173.90 157.245.23.93 80:30304/TCP,443:30577/TCP 9m59s
service/ambassador-admin ClusterIP 10.245.217.211 <none> 8877/TCP,8005/TCP 9m59s
service/ambassador-redis ClusterIP 10.245.77.142 <none> 6379/TCP 9m59s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ambassador 2/2 2 2 9m59s
deployment.apps/ambassador-agent 1/1 1 1 9m59s
deployment.apps/ambassador-redis 1/1 1 1 9m59s
NAME DESIRED CURRENT READY AGE
replicaset.apps/ambassador-5bdc64f9f6 2 2 2 9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8 1 1 1 9m59s
replicaset.apps/ambassador-redis-64b7c668b9 1 1 1 9m59s
Verificando a Integridade das Aplicações após a Restauração
Verifique se todos os recursos do namespace ambassador estão no lugar e em execução:
NAME HOSTNAME STATE PHASE COMPLETED PHASE PENDING AGE
echo-host echo.starter-kit.online Ready 11m
quote-host quote.starter-kit.online Ready 11m
A saída se parece com:
Obtenha os hosts do ambassador:
NAME SOURCE HOST SOURCE PREFIX DEST SERVICE STATE REASON
ambassador-devportal /documentation/ 127.0.0.1:8500
ambassador-devportal-api /openapi/ 127.0.0.1:8500
ambassador-devportal-assets /documentation/(assets|styles)/(.*)(.css) 127.0.0.1:8500
ambassador-devportal-demo /docs/ 127.0.0.1:8500
echo-backend echo.starter-kit.online /echo/ echo.backend
quote-backend quote.starter-kit.online /quote/ quote.backend
A saída se parece com o seguinte. O STATE deve ser Ready, assim como a coluna HOSTNAME apontando para o nome de host totalmente qualificado.
Obtenha os mapeamentos do ambassador:
A saída se parece com o seguinte. Observe o echo-backend, que está mapeado para o host echo.starter-kit.online e o prefixo de origem /echo/, o mesmo para quote-backend.
Agora, você precisa atualizar seus registros de DNS A, porque o recurso de balanceamento de carga do DigitalOcean foi recriado e recebeu um novo IP externo atribuído.
Por fim, verifique se as aplicações do backend respondem a solicitações HTTP também. Consulte Criando os Serviços de Backend do Ambassador Edge Stack em relação às aplicações de backend usadas no tutorial do Starter Kit.
O próximo passo lida com o backup e a restauração de todo o cluster.
Passo 5 – Exemplo de Backup e Restauração do Cluster Inteiro
A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:
Neste passo, você simulará um cenário de recuperação de desastres. O cluster DOKS inteiro será excluído e, em seguida, as aplicações importantes serão restauradas a partir de um backup anterior.
Criando o Backup do Cluster DOKS
A ideia principal aqui é realizar um backup do cluster DOKS incluindo todos os namespaces importantes que contêm suas aplicações essenciais e configurações.
Observe que kube-system (ou outros namespaces relacionados ao cluster DOKS) não estão incluídos na lista. Normalmente, eles não são necessários, a menos que haja um caso especial que exija que algumas configurações sejam persistidas nesse nível.
Primeiro, altere o diretório onde o repositório Git do Starter Kit foi clonado em sua máquina local:
Em seguida, abra e inspecione os arquivos de manifesto ClusterBackupPlan e ClusterBackup fornecidos no repositório do Starter Kit usando um editor de sua escolha (preferencialmente com suporte a lint YAML).
NAME TARGET ... STATUS
starter-kit-cluster-backup-plan trilio-s3-target ... Available
Finalmente, crie os recursos ClusterBackupPlan e ClusterBackup usando kubectl:
Agora, inspecione o status do ClusterBackupPlan usando kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE COMPLETE
starter-kit-cluster-backup starter-kit-cluster-backup-plan Full Available ... 100
A saída se parece com o seguinte. Observe o valor da coluna STATUS, que deve estar definido como Disponível.
Em seguida, verifique o status do ClusterBackup usando kubectl:
A saída se parece com o seguinte. Observe o valor da coluna STATUS, que deve estar definido como Disponível, assim como o PERCENTAGE COMPLETE definido como 100.
Se a saída se parece com o acima, então todos os seus namespaces de aplicação importantes foram salvos com sucesso.
Pode levar algum tempo para que o backup completo do cluster seja concluído, dependendo de quantos namespaces e recursos associados estão envolvidos no processo.
Você também pode abrir o painel principal do console da web e inspecionar o backup multi-namespace (observe como todos os namespaces importantes que foram salvos estão destacados em verde, em uma estrutura de favo de mel):
Recriando o Cluster DOKS e Restaurando Aplicações
Um aspecto importante a ter em mente é que sempre que você destruir um cluster DOKS e depois restaurá-lo, um novo Balanceador de Carga com um novo IP externo é criado também quando a TVK restaura o seu controlador de entrada. Portanto, certifique-se de atualizar seus registros A do DNS da DigitalOcean conforme necessário.
Agora, exclua todo o cluster DOKS (certifique-se de substituir os marcadores <> conforme necessário):
Em seguida, recrie o cluster conforme descrito em Configurar o Kubernetes da DigitalOcean.
Para realizar a operação de restauração, você precisa instalar o aplicativo TVK conforme descrito em Passo 1 – Instalando o TrilioVault para Kubernetes. É importante usar a mesma versão do Helm Chart.
Depois que a instalação for concluída com sucesso, configure o destino TVK conforme descrito em Passo 2 – Criando um Destino TrilioVault para Armazenar Backups, e aponte-o para o mesmo bucket S3 onde estão localizados seus dados de backup. Além disso, certifique-se de que a navegação no destino esteja ativada.
Em seguida, verifique e ative uma nova licença conforme descrito na seção Licenciamento da Aplicação TrilioVault.
Para obter acesso à interface de usuário do console web, consulte a seção Obtendo Acesso ao Console de Gerenciamento Web do TVK.
Depois, navegue até Gerenciamento de Recursos -> Namespace TVK -> Destinos (no caso do Starter Kit, o Namespace TVK é tvk):
Prosseguindo, navegue até o destino e liste os backups disponíveis clicando no botão Ações. Em seguida, selecione a opção Iniciar Navegador no menu suspenso. Para que isso funcione, o destino deve ter a sinalização enableBrowsing configurada como true.
Agora, clique no item starter-kit-cluster-backup-plan na lista e, em seguida, clique e expanda o item starter-kit-cluster-backup na janela secundária à direita:
Para iniciar o processo de restauração, clique no botão Restaurar.
Verificando o Estado das Aplicações do Cluster DOKS
Primeiro, verifique todos os recursos do Kubernetes do cluster.
Em seguida, certifique-se de que seus registros A de DNS estão atualizados para apontar para o novo IP externo do balanceador de carga.
Por fim, as aplicações de backend devem responder a solicitações HTTP também. Consulte Criando os Serviços de Backend do Conjunto de Inicialização da Pilha de Borda do Embaixador em relação às aplicações de backend usadas no tutorial do Kit Inicial.
No próximo passo, você aprenderá como realizar backups agendados (ou automáticos) para as aplicações do seu cluster DOKS.
Fazer backups automaticamente com base em um cronograma é uma característica realmente útil. Isso permite que você retroceda no tempo e restaure o sistema para um estado de funcionamento anterior caso algo dê errado. Esta seção fornece um exemplo de um backup automático em um cronograma de 5 minutos (o namespace kube-system foi escolhido).
Primeiro, você precisa criar um CRD de Policy do tipo Schedule que define o agendamento de backup no formato cron (mesmo que o cron do Linux). As políticas de agendamento podem ser usadas para os CRDs BackupPlan ou ClusterBackupPlan. Um CRD de política de agendamento típico parece o seguinte (define um agendamento de 5 minutos):
# disparar a cada 5 minutos
Em seguida, você pode aplicar a política de agendamento a um CRD de ClusterBackupPlan, por exemplo, conforme visto abaixo:
Perceba que é um CRD básico de ClusterBackupPlan, referenciando o CRD de Policy definido anteriormente através do campo spec.backupConfig.schedulePolicy. Você pode ter políticas separadas criadas para backups completos ou incrementais, daí as fullBackupPolicy ou incrementalBackupPolicy podem ser especificadas no spec.
Agora, por favor, crie a política de agendamento Policy usando o manifesto de exemplo fornecido pelo tutorial do Starter Kit.
NAME POLICY DEFAULT
scheduled-backup-every-5min Schedule false
Altere o diretório para onde o repositório Git do Starter Kit foi clonado em sua máquina local.
Por fim, crie os recursos para os backups agendados do namespace kube-system:
# Crie o plano de backup primeiro para o namespace kube-system
NAME TARGET ... FULL BACKUP POLICY STATUS
kube-system-ns-backup-plan-5min-schedule trilio-s3-target ... scheduled-backup-every-5min Available
# Crie e dispare o backup agendado para o namespace kube-system
Verifique o status do plano de backup agendado para kube-system:
NAME BACKUPPLAN BACKUP TYPE STATUS ...
kube-system-ns-full-backup-scheduled kube-system-ns-backup-plan-5min-schedule Full Available ...
A saída se parece com o seguinte. Observe o valor FULL BACKUP POLICY definido para o recurso de política de backup agendado anteriormente criado scheduled-backup-every-5min, assim como o STATUS que deve ser Disponível.
Verifique o status do backup agendado para kube-system:
A saída se parece com o seguinte. Observe o valor BACKUPPLAN definido para o recurso de plano de backup anteriormente criado, assim como o STATUS que deve ser Disponível.
Agora, você pode verificar se os backups são realizados em intervalos regulares (5 minutos), consultando o recurso de backup do cluster e inspecionando a coluna START TIME (kubectl get clusterbackup -n tvk). Deve refletir o delta de 5 minutos, conforme destacado na imagem abaixo:
No próximo passo, você aprenderá como configurar uma política de retenção para seus backups.
Passo 7 – Política de Retenção de Backups
A política de retenção permite que você defina o número de backups a serem retidos e a cadência para excluir backups conforme os requisitos de conformidade. O CRD da política de retenção fornece uma especificação YAML simples para definir o número de backups a serem retidos em termos de dias, semanas, meses, anos, mais recentes, etc.
- Usando Políticas de Retenção
- As políticas de retenção podem ser usadas para CRDs (Custom Resource Definitions) de
BackupPlanouClusterBackupPlan. Um manifesto típico dePolicypara o tipoRetentionse parece com o seguinte: - A política de retenção acima se traduz para:
- A cada semana, manter um backup em cada quarta-feira.
A cada mês, manter um backup no dia 15.
A typical ClusterBackupPlan example configuration that has a retention set looks like:
A cada ano, manter um backup em cada março.
No total, devem estar disponíveis 2 backups mais recentes.
O fluxo básico para criar um recurso de política de retenção segue o mesmo caminho que para backups agendados. Você precisa de um CRD BackupPlan ou ClusterBackupPlan definido para fazer referência à política de retenção e, em seguida, ter um objeto Backup ou ClusterBackup para acionar o processo.
Observe que ele usa um campo retentionPolicy para fazer referência à política em questão. Claro, você pode ter um plano de backup que tenha ambos os tipos de políticas definidas, para que possa realizar backups agendados, bem como lidar com estratégias de retenção.
Usando Políticas de Limpeza
Você precisa de uma maneira de coletar o lixo de todos esses objetos que não estão mais em uso. Para isso, você precisa introduzir o CRD Política de Limpeza:
A política de limpeza acima deve ser definida no namespace de instalação do TVK. Em seguida, um cron job é criado automaticamente para você que é executado a cada 30 minutos e deleta backups falhados com base no valor especificado para backupdays dentro do campo spec.
Conclusão
- Neste tutorial, você aprendeu como realizar backups únicos e programados, e como restaurar tudo.
- Todas as tarefas e operações básicas explicadas neste tutorial têm como objetivo dar a você uma introdução básica e compreensão do que o TrilioVault para Kubernetes é capaz de fazer.
- Saiba Mais