Introdução
Neste tutorial, você aprenderá como implantar o TrilioVault para Kubernetes (ou TVK) em seu cluster DOKS, criar backups e recuperar um backup caso algo dê errado. Você pode fazer backup de todo o seu cluster ou optar por backups baseados em namespace ou rótulos.
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çamentos 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 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.
Sumário
- Pré-requisitos
- Passo 1 – Instalando o TrilioVault para Kubernetes
- Passo 2 – Criando um Destino TrilioVault para Armazenar Backups
- Passo 3 – Conhecendo a Console de Gerenciamento Web do TVK
- Passo 4 – Exemplo de Backup e Restauração por Namespace
- Passo 5 – Exemplo de Backup e Restauração do Cluster Inteiro
- 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 itens:
- 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 as versões 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 dos 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 o CRD VolumeSnapshot não estiver instalado, consulte Instalando CRDs 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
Também certifique-se de que o 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 v1beta1 quanto v1 (se não estiver instalado, consulte Instalando CRDs 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 o TrilioVault para Kubernetes
Neste passo, você aprenderá como implantar o TrilioVault para DOKS e gerenciar as instalações do TVK via Helm. Os dados de backup serão armazenados no bucket DO Spaces criado anteriormente na seção de Pré-requisitos.
A aplicação TrilioVault pode ser instalada de várias maneiras:
- Através do Operador TrilioVault. Você define um CRD
TrilioVaultManagerque informa 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 totalmente gerenciado pelo Helm, (coberto neste tutorial).
Instalando o TrilioVault usando Helm
O tutorial do Kit Inicial usa o tipo de instalação do Cluster para a aplicação TVK (o valor Helm applicationScope é definido como “Cluster”). Todos os exemplos deste tutorial dependem deste tipo de instalação para funcionar corretamente.
Primeiro, clone o repositório Git do Kit Inicial e altere o diretório para sua cópia local:
Em seguida, adicione o repositório Helm do TrilioVault e liste os gráficos disponíveis:
A saída 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).
Por fim, instale o TrilioVault para Kubernetes usando o 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 do 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 a 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 o tipo de serviço para acessar a interface do usuário do TVK, por exemplo, NodePort ou LoadBalancer
Agora, verifique a implantação do seu 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ásica 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 os seguintes passos 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.
Criar e Verificar 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 irá criar um trabalho job.batch/tvk-license-digitalocean que executará um pod tvk-license-digitalocean-828rx para buscar a licença do Servidor de Licenças 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, assim como o tipo de licença na coluna EDITION e HORA 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, assim como a Edição.
O resultado 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 em todo o cluster ou baseado em namespace.
Renovando a Licença do 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ê deverá receber o manifesto da licença em YAML, que pode ser aplicado ao seu cluster usando o kubectl. Os comandos a seguir pressupõem que o TVK está instalado no namespace padrão tvk (por favor, 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 chamados de destino.
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 target, e é gerenciado por meio de um CRD especial chamado Target. 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 para S3 quanto para NFS), para que seus dados sejam mantidos seguros em vários locais, alcançando assim a redundância de backup.
- Nesta configuração,
spec.type: Tipo de destino para armazenamento de backup (S3 é um armazenamento de objeto).spec.vendor: Fornecedor de armazenamento de terceiros que hospeda o destino (para DigitalOcean Spaces você precisa usarOutroem vez deAWS).spec.enableBrowsing: Habilitar a navegação para o destino.spec.objectStoreCredentials: Define as credenciais necessárias (viacredentialSecret) para acessar o armazenamentoS3, bem como 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 é tvk), ou em outro namespace de sua escolha. Apenas certifique-se de referenciar o namespace corretamente. Por outro lado, certifique-se de proteger o namespace onde você armazena segredos do TrilioVault via RBAC por motivos de segurança.
Passos para criar um Destino para o TrilioVault:
Primeiro, mude 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=“<AQUI_SUA_CHAVE_DE_ACESSO_DO_DO_SPACES>” \
–from-literal=secretKey=“<AQUI_SUA_CHAVE_SECRETA_DO_DO_SPACES>”
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 ao YAML lint).
Agora, por favor substitua os espaços reservados <> adequadamente para o seu bucket do DO Spaces Trilio, como bucketName, region, url e credentialSecret.
Finalmente, 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, TrilioVault irá iniciar um job de trabalhador chamado trilio-s3-target-validator responsável por validar 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 do job trilio-s3-target-validator é excluído posteriormente. Se algo der errado, o job de validador de destino do S3 é mantido em execução para que você possa inspecionar os logs e encontrar o possível problema.
Agora, por favor, prossiga e 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 Executando 0 104s
# Agora, busque os dados de logs
O resultado será esta exceção:
Em seguida, você descobrirá o console web do 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 do TVK
Embora seja possível gerenciar operações de backup e restauração completamente via CLI usando kubectl e CRDs, o 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 apontar e clicar, fornece uma melhor visualização e inspeção dos objetos do cluster do TVK, bem como para criar planos de recuperação de desastres (ou DRPs).
A instalação baseada em Helm coberta 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 entrada para a TVK.
A saída se parece com o seguinte. Procure pela linha k8s-triliovault-ingress-nginx-controller e observe que ele escuta 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 controlador de ingresso da TVK nginx
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 em 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 aquele que você criou no último comando acima.
Por favor, mantenha o arquivo kubeconfig gerado seguro porque ele contém dados sensíveis.
- Explorando a Interface de Usuário do Console Web TVK
- Explore cada seção à esquerda, como:
- Gerenciamento de Cluster: Isso mostra a lista de clusters primários e outros clusters com instâncias TVK, adicionados ao cluster OVH primário usando o recurso de Gerenciamento Multi-Cluster.
- Backup & Recuperação: Este é o painel principal que lhe dá uma visão geral do cluster inteiro, como Espaços de nomes descobertos, Aplicações, Lista de planos de backup, Destinos, Ganchos, Políticas, etc.
Monitoramento: Isso tem duas opções – Monitoramento do TrilioVault e Monitoramento do Velero se o usuário tiver Velero configurado em seu cluster OVH.
Recuperação de Desastres: Permite que você gerencie e execute operações de recuperação de desastres.
Recuperação de Desastres: Permite que você gerencie e execute operações de recuperação de desastres.
Você também pode ver o Destino S3 criado anteriormente, navegando até Backup & Recuperação -> Destinos -> <Namespace> tvk no menu suspenso no topo.
Indo mais adiante, você pode navegar pelo destino e listar os backups disponíveis clicando no botão Ações à direita e, em seguida, selecionando a opção Iniciar Navegador do menu pop-up. Para isso funcionar, o destino deve ter a sinalização enableBrowsing definida como true.
Para obter 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. O TVK possui um recurso que permite realizar backups em um nível mais alto do que apenas namespaces.
- Criando o Backup do Helm Release do Ambassador
- Para realizar backups para um único aplicativo no nível do namespace (ou release do Helm), é necessário um BackupPlan seguido por um Backup CRD. BackupPlan é uma definição do ‘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 de backup real, conforme ditado pela especificação do BackupPlan.
- Nesta configuração,
A typical Backup CRD looks like below:
spec.backupConfig.target.name: Indica ao TVK qual nome de destino usar para armazenar backups.
spec.backupConfig.target.namespace: Indica ao 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 está implantado em seu cluster seguindo as etapas do tutorial do Ambassador Ingress.
Em seguida, mude para o diretório onde o repositório Git do Starter Kit foi clonado em sua máquina local:
Depois, abra e inspecione os arquivos de manifesto do Ambassador BackupPlan e Backup fornecidos no repositório do 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
Finalmente, crie os recursos BackupPlan e Backup usando kubectl.
Agora, inspecione o status do BackupPlan (direcionando o lançamento do 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 BACKUP TYPE definido como Full.
Depois que todos os componentes de liberação do embaixador Helm terminarem de serem enviados para o destino S3, você deve obter estes 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 backup com sucesso da liberação 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 de o backup não ficar 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 a liberação do Helm do embaixador foi copiada no subexibição Detalhes do Componente.
Excluindo a Liberação 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 excluídos (a listagem deve estar vazia):
- Por fim, verifique se o endpoint dos serviços de backend
echoequoteestáDOWN. Consulte Criando os Serviços de Backend da Pilha do Ambassador Edge sobre os aplicativos de backend usados no tutorial do Starter Kit. Você pode usar ocurlpara testar (ou pode usar seu navegador da web): - Restaurando o Backup do Lançamento do Helm do Ambassador
- Importante
Se estiver restaurando o mesmo namespace, verifique se os componentes do aplicativo original foram removidos. Especialmente o PVC do aplicativo deve ser excluído.
Se estiver a restaurar para outro cluster (cenário de migração), certifique-se de que o TrilioVault para Kubernetes está em execução no namespace/cluster remoto também. Para restaurar num 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 para Restauração para ver um exemplo de restauração por localização.
- Ao excluir o namespace
ambassador, o recurso de balanceamento de carga associado ao serviço de embaixador também será excluído. Portanto, ao restaurar o serviçoambassador, o LB será recriado pela DigitalOcean. O problema é que você obterá um endereço de IP NOVO para o seu LB, então será necessário ajustar osregistros Apara receber tráfego nos seus domínios hospedados no cluster. - Para restaurar um Backup específico, é necessário criar um CRD de
Restore. O CRD de Restauração típico é semelhante ao seguinte: - Nesta configuração,
spec.source.type: Especifica que tipo de backup restaurar.
spec.source.backup: Contém uma referência ao objeto de backup a partir do qual restaurar.
spec.skipIfAlreadyExists: Especifica se deve pular a restauração de um recurso se já existir no namespace restaurado.
Restaurar permite que você restaure o último Backup bem-sucedido para uma aplicação. É usado para restaurar um único namespace ou release Helm, protegido pelo CRD de Backup. O CRD de Backup é identificado pelo seu nome ambassador-helm-release-full-backup.
Primeiro, inspecione o exemplo do CRD de Restauração 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 Restauração usando kubectl:
Por fim, inspecione o status do objeto de Restauração:
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 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 DNS A, pois o recurso do balanceador de carga da DigitalOcean foi recriado e recebeu um novo IP externo atribuído.
Por fim, verifique se as aplicações backend respondem às solicitações HTTP também. Consulte Criando os Serviços Backend do Ambassador Edge Stack em relação às aplicações backend utilizadas no tutorial Starter Kit.
O próximo passo trata do backup e 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 completo do DOKS 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 e configurações essenciais.
Observe que o namespace kube-system (ou outros namespaces relacionados ao cluster DOKS) não está incluído na lista. Geralmente, esses não são necessários, a menos que haja um caso especial exigindo 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 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
Por fim, crie os recursos ClusterBackupPlan e ClusterBackup usando o kubectl:
Agora, inspecione o status do ClusterBackupPlan usando o kubectl:
NAME BACKUPPLAN BACKUP TYPE STATUS ... PERCENTAGE COMPLETE
starter-kit-cluster-backup starter-kit-cluster-backup-plan Full Available ... 100
A saída parece semelhante ao seguinte. Observe o valor da coluna STATUS, que deve ser definido como Available.
Em seguida, verifique o status do ClusterBackup usando o kubectl:
A saída parece semelhante ao seguinte. Observe o valor da coluna STATUS, que deve ser definido como Available, assim como o PERCENTAGE COMPLETE definido como 100.
Se a saída se parecer com a acima, então todos os seus namespaces de aplicativos importantes foram salvos com sucesso.
Pode levar um tempo para o backup completo do cluster ser 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 de 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 seu controlador de entrada. Portanto, certifique-se de atualizar seus registros A DNS da DigitalOcean de acordo.
Agora, exclua todo o cluster DOKS (certifique-se de substituir os espaços reservados <> 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 os seus dados de backup. Além disso, certifique-se de que a navegação no destino esteja habilitada.
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 Kit Inicial, 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 Navegação no menu pop-up. Para que isso funcione, o destino deve ter a sinalização enableBrowsing configurada como true.
Agora, clique no item starter-kit-cluster-backup-plan da lista e, em seguida, clique e expanda o item starter-kit-cluster-backup na janela lateral 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 do DNS estejam atualizados para apontar para o novo IP externo do balanceador de carga.
Por fim, as aplicações do backend devem responder às solicitações HTTP também. Consulte Criando os Serviços de Backend da Pilha de Borda do Embaixador em relação às aplicações do 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 muito útil. Isso permite que você volte no tempo e restaure o sistema para um estado de funcionamento anterior se algo der errado. Esta seção fornece um exemplo de um backup automático em um cronograma de 5 minutos (o namespace kube-system foi selecionado).
Primeiro, você precisa criar um CRD Policy do tipo Schedule que define o agendamento de backup no formato cron (igual ao cron do Linux). As políticas de agendamento podem ser usadas para CRDs BackupPlan ou ClusterBackupPlan. Um CRD de política de agendamento típico parece com abaixo (define um agendamento de 5 minutos):
# acionar a cada 5 minutos
Em seguida, você pode aplicar a política de agendamento a um CRD ClusterBackupPlan, por exemplo, como visto abaixo:
Você pode notar que é um CRD básico de ClusterBackupPlan, fazendo referência ao CRD de Policy definido anteriormente por meio 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 na especificação.
Agora, por favor, crie a política de agendamento 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.
Finalmente, crie os recursos para os backups agendados do namespace kube-system:
# Crie primeiro o plano de backup 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 acione 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 parece semelhante ao seguinte. Observe o valor FULL BACKUP POLICY definido para o recurso de política de backup agendado previamente criado scheduled-backup-every-5min, assim como o STATUS que deve ser Available.
Verifique o status do backup agendado para kube-system:
A saída parece semelhante ao seguinte. Observe o valor BACKUPPLAN definido para o recurso de plano de backup previamente criado, assim como o STATUS que deve ser Available.
Agora, você pode verificar se os backups são executados 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, como 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 de acordo com os requisitos de conformidade. O CRD de 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 os CRDs
BackupPlanouClusterBackupPlan. Um manifesto típico dePolicypara o tipoRetentionse parece com: - 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 todo março.
No geral, deve haver 2 backups mais recentes disponíveis.
O fluxo básico para criar um recurso de política de retenção segue o mesmo caminho que para backups programados. Você precisa de um CRD BackupPlan ou ClusterBackupPlan definido para referenciar a 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 referenciar a 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 programados, 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 aqueles 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 trabalho cron é criado automaticamente para você, que é executado a cada 30 minutos e deleta backups falhados com base no valor especificado para diasdebackup dentro do campo spec.
Conclusão
- Neste tutorial, você aprendeu como realizar backups únicos e programados, e restaurar tudo.
- Todas as tarefas e operações básicas explicadas neste tutorial têm como objetivo fornecer uma introdução básica e compreensão do que o TrilioVault para Kubernetes é capaz de fazer.
- Saiba Mais