Rook: un almacén de datos de autoservizo para Kubernetes

O pasado 29 de xaneiro, o comité técnico da CNCF (Cloud Native Computing Foundation), a organización detrás de Kubernetes, Prometheus e outros produtos de código aberto do mundo dos contedores e cloud native, anunciou sobre a aceptación do proxecto Torre nas súas filas. Unha excelente oportunidade para coñecer este "orquestrador de almacenamento distribuído en Kubernetes".

Que tipo de torre?

Torre é un software escrito en Go (distribuído por baixo a licenza gratuíta de Apache 2.0), deseñado para proporcionar aos almacéns de datos funcións automatizadas que os autoxestión, autoescalado e autocuración. Para iso, Rook automatiza (para almacéns de datos utilizados nun contorno de Kubernetes): despregamento, arranque, configuración, aprovisionamento, escalado, actualizacións, migracións, recuperación ante desastres, seguimento e xestión de recursos.

O proxecto está en fase alfa e está especializado na orquestración do sistema de almacenamento distribuído Ceph en clústeres de Kubernetes. Os autores tamén anuncian plans para soportar outros sistemas de almacenamento, pero isto non ocorrerá nas próximas versións.

Compoñentes e dispositivo técnico

O traballo de Rook dentro de Kubernetes baséase nun operador especial (escribimos máis sobre os operadores de Kubernetes en Este artigo), que automatiza a configuración do almacenamento e implementa o seu seguimento.

Así, Operador de torre parece ser un contedor que contén todo o necesario para a implantación e o mantemento posterior do repositorio. As responsabilidades do operador inclúen:

• creando un DaemonSet para os daemons de almacenamento Ceph (ceph-osd) cun simple clúster RADOS;
• creando pods para a monitorización de Ceph (con ceph-mon, comprobando o estado do clúster; para o quórum, na maioría dos casos despréganse tres copias e, se cae algunha delas, aumenta unha nova);
• xestión de CRD (Definicións de recursos personalizados) por si mesmo clúster, piscinas de almacenamento, almacéns de obxectos (conxuntos de recursos e servizos para atender solicitudes HTTP que realizan PUT/GET en obxectos; son compatibles con S3 e Swift API)E sistemas de ficheiros;
• inicializando pods para lanzar todos os servizos necesarios;
• creación de axentes Rook.

Axentes de Rook están representados por pods separados que se despregan en cada nodo de Kubernetes. O propósito do axente é a configuración do complemento FlexVolume, que ofrece soporte para volumes de almacenamento en Kubernetes. O axente implementa o funcionamento do almacenamento: conecta dispositivos de almacenamento en rede, monta volumes, formatea o sistema de ficheiros, etc.

Lugar e función dos compoñentes de Rook no esquema xeral de clúster de Kubernetes

Rook ofrece tres tipos de almacenamento:

1. bloque (Bloquear, StorageClass) — monta o almacenamento nun único fogar;
2. obxecto (obxecto, ObjectStore) - dispoñible dentro e fóra do clúster de Kubernetes (a través da API S3);
3. sistema de ficheiros compartido (Sistema de ficheiros compartidos, Filesystem) é un sistema de ficheiros que se pode montar para ler e escribir desde varios pods.

Os elementos internos do Rook inclúen:

• Mons — vainas para o seguimento de Ceph (co xa mencionado ceph-mon);
• OSD - pods con daemons ceph-osd (object Storage Daemons);
• M.G.R. - vainas cun demo ceph-mgr (Xestor Ceph), que proporciona capacidades e interfaces de monitorización adicionais para sistemas externos (monitorización/control);
• RGW (opcional) - vainas con almacenamento de obxectos;
• MDS (opcional) - pods con sistema de ficheiros compartido.

Todos os daemons Rook (Mons, OSD, MGR, RGW, MDS) compílanse nun único binario (rook) funcionando nun contedor.

Para unha breve introdución ao proxecto Rook, esta curta (12 diapositivas) tamén pode ser útil. presentación de Bassam Tabbara (CTO de Quantum Corp).

Operando o Rook

O operador de Rook admite totalmente a versión 1.6 de Kubernetes e superior (e, parcialmente, a versión máis antiga de K8s - 1.5.2). O seu instalación в escenario máis sinxelo parece así:

cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml

Ademais, o operador de Rook está preparado Gráfico de timón, grazas ao cal a instalación pódese realizar así:

helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook

Pequena cantidade dispoñible opcións de configuración (por exemplo, pode desactivar o soporte RBAC, se esta función non se utiliza no seu clúster), que se pasan a helm install mediante parámetro --set key=value[,key=value] (ou almacenar nun ficheiro YAML separado e transmitir mediante -f values.yaml).

Despois de instalar o operador Rook e lanzar pods cos seus axentes, só queda crear o propio clúster Rook, cuxa configuración máis sinxela semella así (rook-cluster.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: rook
---
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook
spec:
  dataDirHostPath: /var/lib/rook
  storage:
    useAllNodes: true
    useAllDevices: false
    storeConfig:
      storeType: bluestore
      databaseSizeMB: 1024
      journalSizeMB: 1024

Nota: débese prestar especial atención ao atributo dataDirHostPath, cuxo valor correcto é necesario para gardar o clúster despois de reiniciar. Para os casos nos que se usa como localización de almacenamento permanente para os datos de Rook en hosts de Kubernetes, os autores recomendan ter polo menos 5 GB de espazo libre neste directorio.

Todo o que queda é crear realmente o clúster a partir da configuración e asegurarse de que os pods foron creados no clúster (no espazo de nomes rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NAME                              READY     STATUS    RESTARTS   AGE
rook-api-1511082791-7qs0m         1/1       Running   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1       Running   0          5m
rook-ceph-mon0-jflt5              1/1       Running   0          6m
rook-ceph-mon1-wkc8p              1/1       Running   0          6m
rook-ceph-mon2-p31dj              1/1       Running   0          6m
rook-ceph-osd-0h6nb               1/1       Running   0          5m

Actualizar O clúster de Rook (ata unha nova versión) é un procedemento que nesta fase require a actualización secuencial de todos os seus compoñentes nunha determinada secuencia, e só podes inicialo despois de asegurarte de que a instalación actual de Rook estea completamente "saludable". estado. Pódense atopar instrucións detalladas paso a paso usando o exemplo de actualización de Rook da versión 0.5.0 á 0.5.1 en documentación do proxecto.

O pasado mes de novembro no blog Rook publicouse comparación produtividade con EBS. Os seus resultados merecen atención e, en breve, son os seguintes:

Perspectivas

O estado actual de Rook é alfa, e o último lanzamento importante ata o momento é versión 0.6, publicado en novembro de 2017 (corrección actual - v0.6.2 - saíu o 14 de decembro). Xa no primeiro semestre de 2018 espéranse lanzamentos de versións máis maduras: beta e estable (oficialmente listas para o seu uso en produción).

Conforme roadmap proxecto, os desenvolvedores teñen unha visión detallada do desenvolvemento de Rook polo menos nos próximos dous lanzamentos: 0.7 (a súa preparación está no rastreador de GitHub estimado como 60%) e 0.8. Entre os cambios esperados atópanse a transferencia de soporte para Ceph Block e Ceph Object ao estado da versión beta, o aprovisionamento dinámico de volumes para CephFS, un sistema de rexistro avanzado, actualizacións automatizadas de clústeres, soporte para instantáneas de volumes.

Levando a Rook ao número Proxectos CNCF (ata agora na fase moi inicial - "nivel de inicio" - á par linkerd и CoreDNS) é unha especie de garantía de interese crecente polo produto. Como se implantará no mundo das aplicacións na nube quedará máis claro unha vez que se publiquen versións estables, o que seguramente traerá novos probadores e usuarios a Rook.

PS

Lea tamén no noso blog:

• «Creación de almacenamento persistente con aprovisionamento en Kubernetes baseado en Ceph»;
• «Operadores para Kubernetes: como executar aplicacións con estado»;
• «CoreDNS: servidor DNS para o mundo nativo da nube e Service Discovery para Kubernetes»;
• «Container Networking Interface (CNI): interface de rede e estándar para contedores Linux»;
• «Infraestrutura con Kubernetes como servizo asequible».

Fonte: www.habr.com