🥇Nossas mãos não estão para ficar paradas: recuperação de cluster Rook no K8s

Nós já comentamos, como/por que gostamos do Rook: ele simplifica consideravelmente o trabalho com armazenamentos em clusters Kubernetes. No entanto, essa simplicidade traz determinadas complexidades. Esperamos que este novo material ajude a entender melhor essas dificuldades antes que elas se manifestem.

E para tornar a leitura mais interessante, vamos começar com consequências de um problema hipotético no cluster.

«Está tudo perdido!»

Imagine que um dia você configurou e lançou o Rook em seu cluster K8s, e ele estava funcionando bem, mas em algum momento 'maravilhoso', acontece o seguinte:

Novos pods não conseguem montar as imagens RBD do Ceph.
Comandos como lsblk e df não estão funcionando nos nós Kubernetes. Isso automaticamente significa: 'algo está errado' com as imagens RBD montadas nos nós. Não é possível lê-las, o que indica que os monitores estão inacessíveis...
Sim, não há monitores funcionando no cluster. Além disso — não há nem pods com OSD, nem pod MGR.

Quando o pod foi iniciado rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Primeiramente, vamos seguir um caminho mais longo e interessante, conduzindo uma investigação cuidadosa sobre as 'entrañas' do Rook e uma restauração passo a passo de seus componentes. Claro, existe um caminho mais curto e correto: a utilização de backups. Como se sabe, os administradores se dividem em dois tipos: aqueles que não fazem backups e aqueles que já fazem... Mas sobre isso — depois da investigação.

Um pouco de prática, ou O caminho longo

Vamos dar uma olhada e restaurar os monitores

Então, vamos olhar para a lista de ConfigMaps: há os necessários para reserva rook-ceph-config e rook-config-override. Eles aparecem quando o cluster é implantado com sucesso.

NB: Nas novas versões, após a aceitação deste PR, os ConfigMaps deixaram de ser um indicador de sucesso na implantação do cluster.

Para prosseguir, precisamos fazer um reboot completo de todos os servidores que têm imagens RBD montadas (ls /dev/rbd*). Isso deve ser feito através do sysrq (ou 'a pé' no data center). Essa exigência é devido à tarefa de desconectar as RBD montadas, para a qual um reboot normal não é adequado (será infrutífero tentar desmontá-las normalmente).

O teatro começa com um cabide, e o cluster Ceph — com monitores. Vamos examiná-los.

O Rook monta no pod do monitor entidades assim:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (um volume populado por um ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (um volume populado por um Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (volume de diretório host bare)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (volume de diretório host bare)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

Vamos ver o que há no segredo rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Decodificamos e obtemos um keyring normal com permissões para o admin e monitores:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Vamos lembrar. Agora vamos olhar o keyring no segredo rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

O que há nele?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

O mesmo. Vamos ver mais... Aqui, por exemplo, o segredo rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

No final, encontramos mais alguns segredos no ConfigMap rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

E esta é a lista original com os keyrings, de onde surgem todos os segredos descritos acima.

Como se sabe (ver dataDirHostPath em documentação), o Rook armazena esses dados em dois lugares. Portanto, vamos dar uma olhada nos nós para ver os keyrings localizados nos diretórios que estão montados nos pods com monitores e OSD. Para isso encontramos nos nós /var/lib/rook/mon-a/data/keyring e veremos:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

De repente o segredo se mostrou diferente — não como nos ConfigMaps.

E quanto ao keyring do admin? Nós também o temos:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Aqui está o problema. Aconteceu alguma falha: o cluster foi recriado... mas na verdade não.

Fica claro que os segredos contêm keyrings regenerados e eles não são do nosso antigo cluster. Portanto:

pegue o keyring do monitor do arquivo /var/lib/rook/mon-a/data/keyring (ou do backup);
modifique o keyring no segredo rook-ceph-mons-keyring;
insira o keyring do admin e do monitor no ConfigMap rook-ceph-mon;
remova os controladores dos pods com monitores.

O milagre não vai demorar: os monitores irão aparecer e iniciar. Ura, o começo foi dado!

Vamos restaurar o OSD

Entramos no pod rook-operator: chamada ceph mon dump mostra que todos os monitores estão no lugar, e ceph -s — sobre o fato de estarem no quórum. No entanto, se observarmos a árvore OSD (ceph osd tree), veremos algo estranho: os OSDs começaram a aparecer, mas estão vazios. Portanto, também precisamos restaurá-los de alguma forma. Mas como?

Enquanto isso, apareceram nos ConfigMaps os muito necessários rook-ceph-config e rook-config-override, além de muitos outros ConfigMaps com nomes do tipo rook-ceph-osd-$nodename-config. Vamos dar uma olhada neles:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Tudo está errado, tudo está confuso!

Vamos escalar o pod do operador para zero, remover os Deployments gerados dos pods com OSD e corrigir esses ConfigMaps. Mas de onde obter o mapa OSD correto por nós?

Vamos tentar novamente explorar os diretórios /mnt/osd[1-2] nos nós — na esperança de encontrarmos algo útil.
No diretório /mnt/osd1 há 2 subdiretórios: osd0 e osd16. O último é exatamente o ID que está indicado no ConfigMap (16)?
Vamos verificar pelos tamanhos e veremos que osd0 é muito maior osd16.

Chegamos à conclusão de que osd0 — este é o OSD necessário, que foi indicado como /mnt/osd1 no ConfigMap (já que estamos usando directory based osd.)

Verificamos passo a passo todos os nós e corrigimos os ConfigMaps. Após todas as modificações, podemos iniciar o pod do operador Rook e ler seus logs. E neles tudo está ótimo:

eu sou o operador do cluster;
encontramos os discos nos nós;
encontramos os monitores;
os monitores se conectaram, ou seja, formaram o quórum;
estou iniciando os Deployments OSD…

Vamos acessar novamente o pod do operador Rook e verificar a saúde do cluster… sim, erramos um pouco nas conclusões sobre os nomes dos OSD em alguns nós! Sem problemas: ajustamos novamente os ConfigMaps, removemos diretórios desnecessários dos novos OSDs e chegamos ao tão aguardado estado HEALTH_OK!

Vamos verificar as imagens no pool:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Está tudo em ordem — o cluster foi salvo!

Eu sou preguiçoso ao fazer backups, ou O caminho rápido

Se os backups para o Rook foram feitos, o procedimento de recuperação se torna significativamente mais fácil e se resume ao seguinte:

Escalamos o deployment do operador Rook para zero;
Removemos todos os Deployments, exceto o operador Rook;
Restauramos todos os secrets e ConfigMaps a partir do backup;
Restauramos o conteúdo dos diretórios /var/lib/rook/mon-* nos nós;
Restauramos (caso tenhamos perdido) o CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Escalamos o deployment do operador Rook de volta para 1.

Dicas úteis

Faça backups!

E para evitar situações em que precisemos recuperá-los:

Antes de grandes operações no cluster, que envolvem reinicializações de servidores, escale para zero o operador Rook para que ele não faça nada desnecessário.
Nos monitores, adicione com antecedência nodeAffinity.
Preste atenção à preparação configuração de timeouts ROOK_MON_HEALTHCHECK_INTERVAL e ROOK_MON_OUT_TIMEOUT.

Em conclusão

Não faz sentido discutir que o Rook, sendo uma "camada" adicional (na estrutura geral de organização de armazenamento no Kubernetes), simplifica muitas coisas, mas também traz novas complexidades e potenciais problemas na infraestrutura. A questão é: fazer uma escolha ponderada e fundamentada entre esses riscos de um lado e os benefícios que a solução traz no seu caso específico do outro.

Aliás, recentemente na documentação do Rook foi adicionado uma seção "Adoptar um cluster Rook Ceph existente em um novo cluster Kubernetes". Nela está descrito com mais detalhes o que é necessário fazer para migrar dados existentes para um novo cluster Kubernetes ou para recuperar o funcionamento de um cluster que falhou por algum motivo.