🥇Nossas mãos não são para o tédio: restaurando um cluster Rook no K8s

Nós já dissePor que gostamos do Rook: ele simplifica significativamente o trabalho com armazenamento em clusters Kubernetes. No entanto, essa simplicidade traz consigo certas complexidades. Esperamos que este novo material ajude você a entender melhor essas complexidades antes que elas surjam.

Para tornar a leitura mais interessante, vamos começar com as consequências problema hipotético em um cluster.

"Tudo está perdido!"

Imagine que você configurou e iniciou o Rook em seu cluster K8s e ele estava funcionando perfeitamente, mas em algum momento "maravilhoso", acontece o seguinte:

Novos pods não conseguem montar imagens RBD do Ceph.
Equipes como lsblk и df Elas não funcionam nos nós do Kubernetes. Isso significa automaticamente que há algo errado com as imagens RBD montadas nos nós. Elas não podem ser lidas, o que indica que os monitores estão indisponíveis...
Sim, não há monitores funcionando no cluster. Além disso, não há nem mesmo pods OSD ou um pod MGR.

Quando a cápsula foi iniciada rook-ceph-operatorNão faz muito tempo, ele foi implantado. Por quê? O operador do Rook decidiu criar um novo cluster... Como podemos restaurar o cluster e seus dados agora?

Vamos começar com uma abordagem mais longa e interessante, conduzindo uma investigação minuciosa do funcionamento interno do Rook e uma restauração passo a passo de seus componentes. Claro, também existe uma maneira mais curta e eficaz: usando backups. Como todos sabemos, existem dois tipos de administradores: aqueles que não fazem backups e aqueles que fazem... Mas falaremos mais sobre isso após a investigação.

Um pouco de prática ou um longo caminho

Vamos dar uma olhada e restaurar seus monitores.

Então, vamos dar uma olhada na lista de ConfigMaps: existem aqueles necessários para backup. rook-ceph-config и rook-config-overrideEles aparecem quando o cluster é implantado com sucesso.

NBEm novas versões, após a adoção. este comunicado de imprensaOs ConfigMaps deixaram de ser um indicador de sucesso na implantação de clusters.

Para executar outras ações, precisamos reiniciar completamente todos os servidores que possuem imagens RBD montadas (ls /dev/rbd*Isso deve ser feito via sysrq (ou "manualmente" no data center). Esse requisito é necessário para desconectar os RBDs montados, para os quais uma reinicialização padrão não funcionará (o sistema tentará desmontá-los normalmente sem sucesso).

Um teatro começa com um cabideiro, e um cluster Ceph começa com monitores. Vamos dar uma olhada neles.

Rook monta as seguintes entidades no pod de monitoramento:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (a volume populated by a ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare host directory volume)
   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 qual é o segredo. rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Decodificamos e obtemos um chaveiro comum com direitos de administrador e de monitoramento:

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

Vamos relembrar. Agora, vamos dar uma olhada no chaveiro em segredo. rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

O que contém?

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

Comigo também. Vamos ver de novo... Aqui vai um segredo, por exemplo. rook-ceph-mgr-a-keyring:

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

Por fim, 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 chaveiros, de onde provêm todos os segredos descritos acima.

Como é sabido (ver dataDirHostPath в documentaçãoO Rook armazena esses dados em dois locais. Então, vamos aos nós para examinar os keyrings armazenados nos diretórios montados nos pods com monitores e OSDs. Para isso, vamos encontrar [keyrings] 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 *"

Fora do azul Aqui, o segredo acabou sendo diferente – não como nos ConfigMaps.

E quanto ao chaveiro de administrador? Também temos isso:

# 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 *"

Esse é o problema. Houve algum tipo de falha: o cluster foi recriado... mas, na realidade, não foi.

Fica claro que os segredos contêm chaveiros recém-criados, e eles não do nosso antigo cluster. Portanto:

Retiramos o chaveiro do monitor de um arquivo. /var/lib/rook/mon-a/data/keyring (ou a partir do backup);
Troque o chaveiro secretamente rook-ceph-mons-keyring;
Registre o chaveiro a partir do administrador e monitore no ConfigMap. rook-ceph-mon;
Removemos os controladores de pods com monitores.

O milagre não tardará a chegar: os monitores aparecerão e começarão a funcionar. Viva, um começo foi dado!

Vamos restaurar o OSD

Vamos até a cápsula. rook-operator: desafio ceph mon dump mostra que todos os monitores estão instalados, e ceph -s - que eles estão em quórum. No entanto, se você olhar para a árvore OSD (ceph osd tree), veremos algo estranho: os OSDs começaram a aparecer, mas estão vazios. Descobrimos que eles também precisam ser restaurados de alguma forma. Mas como?

Entretanto, os ConfigMaps adquiriram os recursos de que tanto precisávamos. rook-ceph-config и rook-config-override, bem como muitos outros ConfigMaps com nomes como rook-ceph-osd-$nodename-configVamos analisá-los:

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

Está tudo errado, está tudo misturado!

Vamos reduzir o número de pods do operador a zero, excluir os Deployments de pod gerados com OSD e corrigir esses ConfigMaps. Mas onde os encontramos? corrigir Mapeamento OSD por nós?

Vamos tentar vasculhar os diretórios novamente. /mnt/osd[1-2] nos nós - na esperança de que possamos descobrir algo ali.
No catálogo /mnt/osd1 Existem 2 subdiretórios: osd0 и osd16O último é exatamente o ID especificado no ConfigMap (16)?
Vamos verificar as dimensões e ver que osd0 muito mais osd16.

Concluimos que osd0 - Este é o OSD necessário, que foi especificado como /mnt/osd1 no ConfigMap (porque usamos OSD baseado em diretório.)

Passo a passo, verificamos todos os nós e editamos os ConfigMaps. Após a conclusão de todas as instruções, podemos iniciar o pod do operador Rook e ler seus logs. E tudo parece ótimo:

Sou operador de cluster;
Encontrei discos nos nós;
Encontrei monitores;
Os monitores tornaram-se amigos, ou seja, formaram um quórum;
Estou executando implantações de OSD...

Vamos acessar novamente o pod do operador Rook e verificar a integridade do cluster... sim, estávamos um pouco equivocados com os nomes dos OSDs em alguns nós! Sem problemas: ajustamos os ConfigMaps novamente, removemos os diretórios extras dos novos OSDs e chegamos ao estado tão esperado. HEALTH_OK!

Vamos conferir as imagens na piscina:

# 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
…

Tudo está no lugar - o cluster está salvo!

Tenho preguiça de fazer backups, ou do jeito mais rápido.

Se forem feitos backups do Rook, o procedimento de recuperação torna-se significativamente mais simples e se resume ao seguinte:

Reduzimos a implantação do operador Rook a zero;
Removemos todas as implantações, exceto o operador Rook;
Restauramos todos os segredos e ConfigMaps a partir do backup;
Recuperando o conteúdo do diretório /var/lib/rook/mon-* nos nós;
Restauramos (caso o CRD seja perdido repentinamente) CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Reduzimos a implantação do operador Rook para 1.

Dicas úteis

Faça backups!

E para evitar situações em que seja necessária a recuperação delas:

Antes de executar trabalhos em larga escala em clusters que envolvam a reinicialização de servidores, reduza a escala do operador Rook a zero para que ele não execute nenhuma ação extra.
Em monitores com antecedência adicionar afinidade de nó.
Preste atenção ao preliminar definindo tempos limite ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

Em vez de uma conclusão

Não adianta argumentar que o Rook, como uma camada adicional (no esquema geral de organização de armazenamento do Kubernetes), simplifica muitas coisas, mas também introduz novas complexidades e potenciais problemas de infraestrutura. Resta apenas fazer uma escolha equilibrada e informada entre esses riscos, por um lado, e os benefícios que a solução traz para a sua situação específica, por outro.

Aliás, recentemente na documentação do Rook foi adicionado A seção "Adotar um cluster Rook Ceph existente em um novo cluster Kubernetes" descreve em mais detalhes o que precisa ser feito para migrar dados existentes para um novo cluster Kubernetes ou para restaurar um cluster que tenha falhado por algum motivo.