Versão 1.5. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Versões disponíveis

Como fazer backup e restaurar clusters

Nesta página, mostramos como fazer backup e restauração do armazenamento etcd para um cluster. Esta página também fornece um script que pode ser usado para fazer backup automático do armazenamento etcd de um cluster.

É possível criar um arquivo de backup para recuperação de potenciais desastres que possam danificar os dados do etcd do cluster. Armazene o arquivo de backup em um local fora do cluster que não dependa da operação dele.

Limitações

Este procedimento não faz backup de dados específicos do aplicativo.
Este procedimento não faz backup dos PersistentVolumes.
As cargas de trabalho programadas após a criação de um backup não são restauradas com esse backup.
Não é possível restaurar um cluster após uma falha no upgrade.
Esse procedimento não tem a finalidade de restaurar um cluster excluído.

Como fazer backup de um cluster de usuário

Um backup de cluster de usuário é um snapshot do armazenamento etcd do cluster de usuário. O armazenamento etcd contém todos os objetos do Kubernetes e objetos personalizados necessários para gerenciar o estado do cluster. O snapshot contém os dados necessários para recriar os componentes e as cargas de trabalho do cluster.

Para criar um snapshot do armazenamento etcd, execute as seguintes etapas:

Coloque um shell no contêiner kube-etcd:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec -it \
   kube-etcd-0 --container kube-etcd --namespace USER_CLUSTER_NAME \
   -- bin/sh
```
em que:
- ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador.
- USER_CLUSTER_NAME é o nome do cluster de usuário.

No shell, no diretório raiz, crie um backup chamado snapshot.db:

ETCDCTL_API=3 etcdctl \
   --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt \
   --key=/etcd.local.config/certificates/etcd.key \
   snapshot save snapshot.db

No shell, insira exit para sair.

Copie snapshot.db do contêiner kube-etcd para o diretório atual:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp \
   USER_CLUSTER_NAME/kube-etcd-0:snapshot.db \
   --container kube-etcd snapshot.db

Como restaurar um cluster de usuário de um backup (que não é de HA)

Antes de usar um arquivo de backup para restaurar o armazenamento etcd do cluster de usuários, faça o diagnóstico do seu cluster e resolva problemas existentes. Usar um backup para restaurar um cluster problemático pode recriar ou piorar problemas. Entre em contato com a equipe de suporte do GKE On-Prem para receber mais ajuda sobre como restaurar os clusters.

Nas instruções a seguir, explicamos como usar um arquivo de backup para restaurar um cluster de usuário nos casos em que os dados do etcd do cluster foram corrompidos e o pod do etcd apresenta um loop de falhas.

É possível restaurar os dados do etcd implantando um pod utilitário que substitui os dados corrompidos pelo backup. O servidor da API do cluster de administrador precisa estar em execução, e o programador do cluster de administrador tem de ser capaz de programar novos pods.

Copie o seguinte manifesto de pod em um arquivo chamado etcd-utility.yaml. Substitua esses marcadores pelos valores:

NODE_NAME: o nó em que o pod kube-etcd-0 está em execução.
ADMIN_CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster de administrador.
USER_CLUSTER_NAME: o nome do cluster do usuário.
GKE_ON_PREM_VERSION: a versão do cluster em que você quer executar a restauração do etcd (por exemplo, 1.5.0-gke.0).

apiVersion: v1
kind: Pod
metadata:
  name: etcd-utility-0
  namespace: USER_CLUSTER_NAME
spec:
  containers:
  - command: ["/bin/sh"]
    args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
    image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
    name: etcd-utility
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: data
    - mountPath: /etcd.local.config/certificates
      name: etcd-certs
  nodeSelector:
    kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
    kubernetes.io/hostname: NODE_NAME
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-kube-etcd-0
  - name: etcd-certs
    secret:
      defaultMode: 420
      secretName: kube-etcd-certs

Implante o pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   create -f etcd-utility.yaml --namespace USER_CLUSTER_NAME

Copie snapshot.db do diretório atual para o diretório raiz do pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp snapshot.db \
   USER_CLUSTER_NAME/etcd-utility-0:snapshot.db --container etcd-utility

Coloque um shell no contêiner etcd-utility:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec it \
   etcd-utility-0 --container etcd-utility --namespace USER_CLUSTER_NAME \
   -- bin/sh

No shell, no diretório raiz, execute o seguinte comando para criar uma nova pasta que contenha o backup:

ETCDCTL_API=3 etcdctl \
   --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt \
   --key=/etcd.local.config/certificates/etcd.key \
   snapshot restore snapshot.db

No shell, exclua os dados antigos do etcd:
```
rm -r var/lib/etcd/*
```
No shell, copie os dados restaurados do etcd para o local permanente:
```
cp -r default.etcd/* var/lib/etcd/
```
No shell, insira exit para sair.

Exclua o pod do etcd com falha:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   delete pod kube-etcd-0 --namespace USER_CLUSTER_NAME

Verifique se o pod do etcd não está mais falhando.

Exclua o pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   delete pod etcd-utility-0 --namespace USER_CLUSTER_NAME

Remova etcd-utility.yaml do diretório atual:
```
rm etcd-utility.yaml
```

Como restaurar um cluster de usuário de um backup (HA)

Esta seção mostra como restaurar os dados do etcd para um cluster de usuário de alta disponibilidade (HA).

Para um cluster de usuário HA, existem três nós no cluster de administrador que servem como planos de controle para o cluster de usuário. Cada um desses nós executa um pod do etcd que mantém os dados do etcd em um volume de armazenamento.

Se dois dos pods do etcd estiverem íntegros e os dados nos volumes de armazenamento associados estiverem intactos, não será necessário usar um arquivo de backup. Isso ocorre porque você ainda tem um quórum de etcd.

No caso raro em que dois dos volumes de armazenamento etcd tenham dados corrompidos, você precisará usar um arquivo de backup para restaurar os dados etcd.

Para realizar as etapas desta seção, você precisa ter criado um arquivo snapshot.db, conforme descrito em Como fazer backup de um cluster de usuário.

Como listar seus pods e nós do etcd

Liste os pods do etcd que gerenciam o armazenamento etcd para seu cluster de usuários. Esses pods são executados no cluster de administrador:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --namespace USER_CLUSTER_NAME \
    --output wide | grep kube-etcd
```
A saída mostra os pods etcd e os nós em que eles são executados. Os nós mostrados na saída são do cluster de administrador, e servem como planos de controle para o cluster de usuário:
```
NAME              ...   NODE
kube-etcd-0       ...   node-xxx
kube-etcd-1       ...   node-yyy
kube-etcd-2       ...   node-zzz
```
Anote os nomes dos pods e os nomes dos nós do plano de controle para uso posterior.

Observe que cada pod do etcd é chamado de kube-etcd anexado com um número. Esse número é chamado de número de membro do pod. Ele identifica o pod como um membro específico do cluster do etcd com os dados de objeto para o cluster de usuário. Este guia usa o marcador MEMBER_NUMBER para se referir ao número de membro do pod do etcd.

Observe também que cada pod no cluster do etcd é executado no próprio nó.

Como se preparar para implantar os pods utilitários

Salve um manifesto para o PodDisruptionBudget (PDB) do servidor da API Kubernetes do cluster de usuário. Em seguida, exclua o PDB.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG get pdb --namespace USER_CLUSTER_NAME \
   kube-apiserver-pdb --output yaml > kube-apiserver-pdb.yaml

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pdb --namespace USER_CLUSTER_NAME \
   kube-apiserver-pdb

Interrompa o servidor da API Kubernetes e a implantação de manutenção do etcd. Isso garante que nenhum componente usará o etcd durante a restauração:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
   scale --replicas 0 statefulset kube-apiserver

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
   scale --replicas 0 deployment gke-master-etcd-maintenance

Lembre-se do nome da imagem do contêiner dos pods do etcd.

Como implantar os pods utilitários

Siga as etapas desta seção para cada um dos pods do etcd.

Lembre-se do nome do pod do etcd e do nome do nó em que o pod é executado.

Salve o seguinte manifesto de pod no diretório atual em um arquivo chamado etcd-utility-MEMBER_NUMBER.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: etcd-utility-MEMBER_NUMBER
  namespace: USER_CLUSTER_NAME
spec:
  containers:
  - command: ["/bin/sh"]
    args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
    image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
    name: etcd-utility
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: data
    - mountPath: /etcd.local.config/certificates
      name: etcd-certs
  nodeSelector:
    kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
    kubernetes.io/hostname: NODE_NAME
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-kube-etcd-MEMBER_NUMBER
  - name: etcd-certs
    secret:
      defaultMode: 420
      secretName: kube-etcd-certs

O manifesto anterior descreve um pod utilitário que você executa temporariamente para restaurar dados do etcd.

Crie o pod utilitário no seu cluster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f etcd-utility-MEMBER_NUMBER.yaml

Copie o arquivo de backup, snapshot.db, para o diretório raiz do pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG cp snapshot.db \
   USER_CLUSTER_NAME/etcd-utility-MEMBER_NUMBER:snapshot.db

Coloque um shell no contêiner etcd-utility no pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG exec -it --namespace USER_CLUSTER_NAME \
   etcd-utility-MEMBER_NUMBER --container etcd-utility -- bin/sh

No shell, no diretório raiz, use snapshot.db para restaurar os dados do etcd:

ETCDCTL_API=3 etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    --name=kube-etcd-MEMBER_NUMBER \
    --initial-cluster=kube-etcd-0=https://kube-etcd-0.kube-etcd:2380,kube-etcd-1=https://kube-etcd-1.kube-etcd:2380,kube-etcd-2=https://kube-etcd-2.kube-etcd:2380 \
    --initial-cluster-token=etcd-cluster-1 \
    --initial-advertise-peer-urls=https://kube-etcd-MEMBER_NUMBER.kube-etcd:2380 \
    snapshot restore snapshot.db

O comando anterior armazenou dados do etcd no diretório /kube-etcd-MEMBER_NUMBER.etcd.

No shell, exclua os dados antigos do etcd:
```
rm -r var/lib/etcd/*
```
No shell, copie os dados do etcd restaurados para o local permanente:
```
cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
```
No shell, remova o diretório temporário do etcd e o arquivo de backup:
```
rm -R kube-etcd-MEMBER_NUMBER.etcd/
rm snapshot.db
```
No shell, insira exit para sair.

Exclua o pod utilitário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pod \
    --namespace USER_CLUSTER_NAME etcd-utility-MEMBER_NUMBER

Como reiniciar componentes

Agora que você implantou e excluiu os pods utilitários, é necessário reiniciar alguns componentes do cluster.

Reinicie os pods no StatefulSet kube-etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG restart rollout statefulset \
    --namespace USER_CLUSTER_NAME kube-etcd

Inicie os servidores da API Kubernetes para o cluster de usuário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale statefulset --replicas 3 \
   --namespace USER_CLUSTER_NAME kube-apiserver

Inicie a implantação de manutenção do etcd no cluster de usuário:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale deployment --replicas 1 \
    --namespace=USER_CLUSTER_NAME  gke-master-etcd-maintenance

Restaure o PDB para o servidor da API Kubernetes:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG apply -f kube-apiserver-pdb.yaml

Como fazer backup de um cluster de administrador

Um backup de cluster de administrador contém os seguintes elementos:

Um snapshot do etcd do cluster de administrador.
Os Secrets do plano de controle do administrador, necessários para a autenticação nos clusters de administrador e de usuário.

Conclua as etapas a seguir antes de criar um backup do cluster de administrador:

Encontre o endereço IP externo do cluster de administrador, que é usado para fazer o SSH no plano de controle do cluster de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes -n kube-system -o wide | grep master
```
em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.
Crie uma chave SSH chamada vsphere_tmp a partir da chave privada do cluster de administrador.

É possível encontrar a chave privada nos Secrets dos clusters de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get secrets sshkeys -n kube-system -o yaml
```
Na resposta ao comando, encontre a chave privada no campo vsphere_tmp.

Copie a chave privada para vsphere_tmp:
```
echo "[PRIVATE_KEY]" | base64 -d > vsphere_tmp; chmod 600 vsphere_tmp
```
Verifique se é possível entrar no plano de controle do administrador usando esta chave privada:
```
ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
Saia do contêiner:
```
exit
```

Como fazer backup do armazenamento etcd de um cluster de administrador

Para fazer backup do armazenamento etcd do cluster de administrador:

Consiga o nome do pod do etcd:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get pods \
    -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}'

Coloque um shell no contêiner kube-etcd do pod:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]  exec -it \
    -n kube-system [ADMIN_ETCD_POD] -- bin/sh

em que [ADMIN_ETCD_POD] é o nome do pod etcd.

No shell, use etcdctl para criar um backup chamado snapshot.db no diretório local:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
    --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save snapshot.db

Saia do contêiner:
```
exit
```
Copie o backup do contêiner kube-etcd usando kubectl cp:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
kube-system/[ADMIN_ETCD_POD]:snapshot.db [RELATIVE_DIRECTORY]
```
em que [RELATIVE_DIRECTORY] é um caminho em que você quer armazenar o backup.

Como fazer backup de Secrets de um cluster de administrador

Para fazer backup dos secrets do plano de controle do administrador:

Use SSH para se conectar ao nó do plano de controle do administrador:
```
ssh -i vsphere_tmp ubuntu@EXTERNAL_IP
```
Substitua EXTERNAL_IP pelo endereço IP externo do plano de controle de administrador anotado anteriormente.
Opcional, mas altamente recomendado: crie um diretório de backup local.

É necessário alterar as permissões dos Secrets de backup para copiá-los do nó:
```
mkdir backup
```
Copie localmente os Secrets para o diretório de backup local:
```
sudo cp -r /etc/kubernetes/pki/* backup/
```
Altere as permissões dos secrets de backup:
```
sudo chmod -R +rw backup/
```
Saia do nó do plano de controle do administrador:
```
exit
```
Execute scp para copiar a pasta de backup do nó do plano de controle do administrador:
```
sudo scp -r -i vsphere_tmp  ubuntu@EXTERNAL_IP:backup/ RELATIVE_DIRECTORY
```
Substitua RELATIVE_DIRECTORY por um caminho em que você quer armazenar o backup.

Como restaurar um cluster de administrador

O procedimento a seguir recria um cluster de administrador armazenado em backup e todos os planos de controle do usuário que ele gerenciou quando o snapshot do etcd foi criado.

Execute scp para copiar snapshot.db para o plano de controle do administrador:
```
sudo scp -i vsphere_tmp snapshot.db ubuntu@[EXTERNAL_IP]:
```
em que [EXTERNAL_IP] é o endereço IP externo do plano de controle do administrador coletado anteriormente.
Coloque um shell no plano de controle do administrador:
```
sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
Copie snapshot.db/ para /mnt:
```
sudo cp snapshot.db /mnt/
```
Crie um diretório temporário, como backup:

Observação: isso não será necessário se já houver uma pasta de backup contendo os Secrets.
```
mkdir backup
```
Saia do plano de controle do administrador:
```
exit
```

Copie os certificados para backup/:

sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/

Coloque um Shell no nó do plano de controle de administrador:
```
ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
em que [EXTERNAL_IP] é o endereço IP externo do plano de controle do administrador coletado anteriormente.

Parar kube-etcd e kube-apiserver.

sudo mv /etc/kubernetes/manifests/etcd.yaml /tmp/etcd.yaml

sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/kube-apiserver.yaml

Copie os Secrets de backup para /etc/kubernetes/pki/:
```
sudo cp -r backup/* /etc/kubernetes/pki/
```

Execute etcdctl restore com o Docker:

sudo docker run --rm \
-v '/mnt:/backup' \
-v '/var/lib/etcd:/var/lib/etcd' --env ETCDCTL_API=3 'gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; rm -r /var/lib/etcd/*; mv /default.etcd/member/ /var/lib/etcd/"

Reinicie kube-etcd e kube-apiserver.

sudo mv /tmp/etcd.yaml /etc/kubernetes/manifests/etcd.yaml

sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml

Saia do plano de controle do administrador:
```
exit
```
Copie o arquivo kubeconfig recém-gerado do nó de administrador:
```
sudo scp -i vsphere_tmp ubuntu@[EXTERNAL_IP]:[HOME]/.kube/config kubeconfig
```
em que:
- [EXTERNAL_IP] é o endereço IP externo do plano de controle de administrador.
- [HOME] é o diretório inicial no nó de administrador.
Agora é possível usar esse novo arquivo kubeconfig para acessar o cluster restaurado.

Backup automático de cluster

É possível usar o script fornecido aqui como um exemplo de como fazer backup dos clusters automaticamente. O script a seguir não é compatível, e só deve ser usado como referência para escrever um script melhor, mais robusto e completo. Antes de executar o script, preencha os valores das cinco variáveis no início do script:

Defina BACKUP_DIR como o caminho em que você quer armazenar os backups de cluster de administrador e de usuário. Este caminho não pode existir.
Defina ADMIN_CLUSTER_KUBECONFIG como o caminho do arquivo kubeconfig do cluster de administrador.
Defina USER_CLUSTER_NAMESPACE como o nome do cluster de usuário. O nome do cluster de usuário é um namespace no cluster de administração.
Defina EXTERNAL_IP como o VIP que você reservou para o serviço de plano de controle do administrador.
Defina SSH_PRIVATE_KEY como o caminho da chave SSH que você criou ao configurar a estação de trabalho do administrador.
Se você estiver usando uma rede privada, defina JUMP_IP como o endereço IP do servidor jump da sua rede.

#!/usr/bin/env bash

# Automates manual steps for taking backups of user and admin clusters.
# Fill in the variables below before running the script.

BACKUP_DIR=""                       # path to store user and admin cluster backups
ADMIN_CLUSTER_KUBECONFIG=""         # path to admin cluster kubeconfig
USER_CLUSTER_NAMESPACE=""           # user cluster namespace
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to vsphere_tmp ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network.

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP

# Snapshot user cluster etcd
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} exec -it -n ${USER_CLUSTER_NAMESPACE} kube-etcd-0 -c kube-etcd -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etcd.local.config/certificates/etcdCA.crt --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key snapshot save ${USER_CLUSTER_NAMESPACE}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp ${USER_CLUSTER_NAMESPACE}/kube-etcd-0:${USER_CLUSTER_NAMESPACE}_snapshot.db $BACKUP_DIR/user-cluster_${USER_CLUSTER_NAMESPACE}_snapshot.db

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
    SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -r "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save admin_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:admin_snapshot.db $BACKUP_DIR/admin-cluster_snapshot.db

Solução de problemas

Para mais informações, consulte Solução de problemas.

Como diagnosticar problemas de cluster usando `gkectl`

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de geração de registros padrão:

Por padrão, as entradas de registro são salvas da seguinte maneira:
- Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.
- Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.
Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
O nível de detalhamento -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registro que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

A seguir

Saiba como diagnosticar problemas de cluster
Saiba mais sobre o Augur, uma ferramenta de código aberto para restaurar objetos individuais de backups do etcd.