Este documento mostra como fazer backup e restauração do armazenamento etcd para um cluster de usuário. 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 desastres imprevistos que podem danificar os dados 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.
As etapas de backup a serem seguidas dependem da ativação do Controlplane V2 no cluster de usuário. Quando o plano de controle V2 está ativado, o plano do cluster de usuário é executado no próprio cluster. Quando o plano de controle V2 não está ativado, o plano de controle do cluster de usuário é executado em um ou mais nós no cluster de administrador, chamado de kubeception.
Execute o seguinte comando para determinar se o cluster tem o Controlplane V2 ativado:
kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo
Se a saída for true
, siga as etapas do Controlplane V2 para fazer backup
do cluster. Caso contrário, siga as etapas do Kubeception.
Cubecepção
Coloque um shell no contêiner
kube-etcd
:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec -it \ kube-etcd-0 -c kube-etcd -n USER_CLUSTER_NAME \ -- /bin/sh
onde:
- 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
/tmp
, crie um backup com o nomesnapshot.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 /tmp/snapshot.db
No shell, insira
exit
para sair.Copie
/tmp/snapshot.db
do contêinerkube-etcd
para o diretório atual:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp \ USER_CLUSTER_NAME/kube-etcd-0:/tmp/snapshot.db \ --container kube-etcd snapshot.db
Plano de controle V2
Consiga o nome do pod do etcd:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \ -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}'
onde:
- USER_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de usuário.
Exemplo:
NAME READY STATUS RESTARTS AGE etcd-uc1-cp1 1/1 Running 0 38m etcd-uc1-cp2 1/1 Running 0 37m etcd-uc1-cp3 1/1 Running 0 38m
Observe que pode haver vários pods
etcd
, por exemplo, três para clusters de alta disponibilidade. Para backup, qualquer podetcd
deve funcionar.Coloque um shell no contêiner
etcd
:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG exec -it \ POD_NAME -c etcd -n kube-system -- /bin/sh
onde:
- POD_NAME é o nome do pod do etcd retirado da etapa anterior.
No shell, crie um arquivo de backup chamado
snapshot.db
:ETCDCTL_API=3 etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ snapshot save /tmp/snapshot.db
No shell, insira
exit
para sair.Copie
snapshot.db
do contêineretcd
para o diretório inicial da estação de trabalho:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ cp POD_NAME:/tmp/snapshot.db ~/snapshot.db \ -c etcd -n kube-system
Copie os secrets do diretório PKI:
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP sudo chmod -R 0644 /etc/kubernetes/pki/* sudo chmod 0755 /etc/kubernetes/pki/etcd exit scp -ri NODE_NAME.key ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki ~/pki_NODE_NAME
onde:
- NODE_NAME é o arquivo que contém a chave SSH para o nó do plano de controle.
- NODE_EXTERNAL_IP é o endereço IP do nó do plano de controle do usuário de que você quer que os secrets sejam copiados.
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 no VMware 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.
Cubecepção
É 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.
Encontre o nome do secret usado pelo etcd no cluster do usuário:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME \ get secrets | grep kube-etcd-certs
Copie o seguinte manifesto de pod em um arquivo chamado
etcd-utility.yaml
. Substitua:NODE_NAME
: o nó em que o podkube-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).KUBE_ETCD_SECRET_NAME
: o nome do secret usado pelo etcd no cluster do usuário, começando comkube-etcd-certs
.
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_SECRET_NAME
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 do etcd restaurados 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
Plano de controle V2
É possível restaurar os dados do etcd
um de cada vez, implantando um contêiner temporário do etcd que substitui os
dados danificados pelo backup.
Insira um shell no nó do plano de controle do usuário:
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
No shell, interrompa o servidor da API Kubernetes e o servidor etcd:
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
No shell, digite
exit
para sair.Execute
scp
para copiar o arquivo de backupsnapshot.db
e os secrets para o nó do plano de controle do usuário:scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/
chmod a+rw pki/ scp -ri NODE_NAME.key ~/pki_NODE_NAME ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki
No shell, use
snapshot.db
para restaurar os dados do etcd:sudo docker run --rm -t \ -v /opt/data/var/lib:/var/lib \ -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \ -v /tmp:/tmp \ --env ETCDCTL_API=3 \ gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --data-dir=/opt/data/var/lib/etcd \ --name=NODE_NAME \ --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \ --initial-cluster=NODE_NAME=https://NODE_IP_ADDRESS:2380 \ snapshot restore /tmp/snapshot.db
onde:
GKE_ON_PREM_VERSION
é a versão do GKE Enterprise usada como tag de imagem;NODE_NAME
é o nome do nó em que a restauração está sendo realizada.NODE_IP_ADDRESS
é o IP do nó mencionado
Adicione a flag
- --initial-cluster-state=new
ao arquivo de manifesto do etcd no comando do contêiner.Exemplo:
containers: - command: - etcd ... - --initial-cluster-state=new ...
No shell, inicie os servidores kube-apiserver e etcd:
sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
No shell, digite
exit
para sair.
Como restaurar um cluster de usuário de um backup (HA)
Cubecepção
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 executar as etapas desta seção, você precisa já 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 ... xxx kube-etcd-1 ... yyy kube-etcd-2 ... 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
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_SECRET_NAME
O manifesto anterior descreve um pod utilitário executado 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 rollout restart 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
Plano de controle V2
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 de alta disponibilidade, há três nós no cluster de usuário que servem como plano 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 porque você ainda teria 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 etcd e os respectivos nós:
kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system -l component=etcd,tier=control-plane -o wide
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 etcd-xxx ... xxx etcd-yyy ... yyy etcd-zzz ... 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 é denominado
etcd-xxx
anexado com um nome de nó. Isso ocorre porque no plano de controle V2 os pods do etcd são executados como um pod estático.
Preparando a restauração
Execute
scp
para copiar o arquivo de backupsnapshot.db
para todos os nós do plano de controle do usuário:scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/
Copie os secrets para o respectivo nó do plano de controle do usuário:
chmod a+rw ~/pki_* scp -ri NODE_NAME.key ~/pki_NODE_NAME/* ubuntu@NODE_EXTERNAL_IP:/opt/data/etc/kubernetes/pki/
Insira um shell no nó do plano de controle do usuário:
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
Como realizar a restauração
Lembre-se do nome do pod do etcd e do nome do nó em que o pod é executado.
No shell, interrompa o servidor da API Kubernetes e o servidor do etcd em todos os nós do plano de controle do usuário:
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
No shell, use
snapshot.db
para restaurar os dados do etcd em todos os nós do plano de controle do usuário:sudo docker run --rm -t \ -v /opt/data/var/lib:/var/lib \ -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \ -v /tmp:/tmp \ --env ETCDCTL_API=3 \ gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --data-dir=/opt/data/var/lib/etcd \ --name=NODE_NAME \ --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \ --initial-cluster=NODE1=https://NODE1_IP:2380,NODE2=https://NODE2_IP:2380,NODE3=https://NODE3_IP:2380 \ snapshot restore /tmp/snapshot.db
onde:
GKE_ON_PREM_VERSION
é a versão do GKE Enterprise usada como tag de imagem;NODE_NAME
é o nome do nó em que a restauração está sendo realizada.NODE_IP_ADDRESS
é o IP do nó mencionado- Preencha
NODE1
,NODE2
,NODE3
eIP
do respectivo nó para a sinalização--initial-cluster
. Também é possível conseguir isso no manifesto do etcd.
Adicione a flag
- --initial-cluster-state=existing
ao arquivo de manifesto do etcd no comando do contêiner.Exemplo:
containers: - command: - etcd ... - --initial-cluster-state=existing ...
Como reiniciar componentes
No shell, inicie os servidores
kube-apiserver
eetcd
em todos os nós do plano de controle do usuário:sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
No shell, digite
exit
para sair.Verifique se
kube-apiserver
eetcd
estão em execução em todos os nós do plano de controle do usuário:kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \ -n kube-system -l tier=control-plane
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:
Cubecepção
- Defina
BACKUP_DIR
como o caminho em que você quer armazenar os backups de cluster de administrador e de usuário. Esse caminho não deveria 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 sua chave SSH. - 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
Plano de controle V2
- Defina
BACKUP_DIR
como o caminho em que você quer armazenar os backups de cluster de administrador e de usuário. Esse caminho não deveria existir. - Defina
ADMIN_CLUSTER_KUBECONFIG
como o caminho do arquivo kubeconfig do cluster de administrador. - Defina
USER_CLUSTER_KUBECONFIG
como o caminho do kubeconfig do cluster de usuário. - 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 sua chave SSH. - 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_KUBECONFIG="" # path to user cluster kubeconfig EXTERNAL_IP="" # admin control plane node external ip - follow steps in documentation SSH_PRIVATE_KEY="" # path to 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 user_etcd=$(kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[0].metadata.name}{"\n"}') kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} exec -it -n kube-system ${user_etcd} -c 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/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/${user_etcd}_snapshot.db" kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} cp kube-system/${user_etcd}:/tmp/${user_etcd}_snapshot.db $BACKUP_DIR/${user_etcd}_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 /tmp/${admin_etcd}_snapshot.db" kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:/tmp/${admin_etcd}_snapshot.db $BACKUP_DIR/${admin_etcd}_snapshot.db
Verificar a restauração
Para verificar se o cluster foi restaurado, execute gkectl diagnose cluster.
A seguir
- Fazer backup e restaurar um cluster de administrador
- 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.