Almacenamento de datos nun clúster de Kubernetes

Hai varias formas de configurar o almacenamento de datos para aplicacións que se executan nun clúster de Kubernetes. Algúns deles xa están desactualizados, outros apareceron recentemente. Neste artigo, analizaremos o concepto de tres opcións para conectar sistemas de almacenamento, incluída a máis recente: conectarse mediante a Interface de almacenamento de contedores.

Método 1: especifique PV no manifesto do pod

Un manifesto típico que describe un pod nun clúster de Kubernetes:

As partes do manifesto que describen que volume está conectado e onde se destacan en cor.

Na sección volumeMounts indica os puntos de montaxe (mountPath) - en que directorio dentro do contedor se montará o volume permanente, así como o nome do volume.

Na sección x enumera todos os volumes que se usan no pod. Especifique o nome de cada volume, así como o tipo (no noso caso: awsElasticBlockStore) e os parámetros de conexión. Os parámetros que aparecen no manifesto dependen do tipo de volume.

O mesmo volume pódese montar simultaneamente en varios recipientes de vainas. Deste xeito, diferentes procesos de aplicación poden acceder aos mesmos datos.

Este método de conexión foi inventado ao principio, cando Kubernetes estaba na súa infancia, e hoxe o método está desfasado.

Hai varios problemas ao usalo:

1. todos os volumes deben ser creados manualmente; Kubernetes non pode crear nada para nós;
2. os parámetros de acceso para cada volume son únicos e deben especificarse nos manifestos de todos os pods que utilicen o volume;
3. para cambiar o sistema de almacenamento (por exemplo, pasar de AWS a Google Cloud), cómpre cambiar a configuración e o tipo de volumes montados en todos os manifestos.

Todo isto é moi inconveniente, polo que en realidade este método úsase para conectar só algúns tipos especiais de volumes: configMap, secret, emptyDir, hostPath:

• configMap e secret son volumes de servizo que che permiten crear un volume con ficheiros dos manifestos de Kubernetes no contedor.

• emptyDir é un volume temporal, creado só para a vida útil do pod. Conveniente de usar para probar ou almacenar datos temporais. Cando se elimina un pod, tamén se elimina o volume emptyDir e pérdense todos os datos.

• hostPath: permítelle montar calquera directorio no disco local do servidor no que se executa a aplicación dentro do contedor coa aplicación, incluído /etc/kubernetes. Esta é unha función non segura, polo que as políticas de seguranza normalmente prohiben o uso de volumes deste tipo. En caso contrario, a aplicación dun atacante poderá montar o directorio HTC Kubernetes dentro do seu contedor e roubar todos os certificados do clúster. Normalmente, os volumes hostPath só poden ser usados ​​por aplicacións do sistema que se executan no espazo de nomes kube-system.

Sistemas de almacenamento cos que funciona Kubernetes figuran na documentación.

Método 2. Conexión a fogares SC/PVC/PV

Un método de conexión alternativo é o concepto de clase de almacenamento, PersistentVolumeClaim, PersistentVolume.

Clase de almacenamento almacena os parámetros de conexión ao sistema de almacenamento de datos.

Reclamación de volume persistente describe os requisitos para o que necesita a aplicación.
Volume persistente almacena os parámetros de acceso e o estado do volume.

A esencia da idea: no manifesto pod indican un volume de tipo PersistentVolumeClaim e indican o nome desta entidade no parámetro claimName.

O manifesto PersistentVolumeClaim describe os requisitos para o volume de datos que require a aplicación. Inclúe:

• tamaño do disco;
• método de acceso: ReadWriteOnce ou ReadWriteMany;
• ligazón a Clase de almacenamento: en que sistema de almacenamento de datos queremos crear o volume.

O manifesto da clase Storage almacena o tipo e os parámetros da conexión ao sistema de almacenamento. O cubelet precisa deles para montar o volume no seu nodo.

Os manifestos de PersistentVolume indican a clase de almacenamento e os parámetros de acceso para un volume específico (ID de volume, ruta, etc.).

Ao crear un PVC, Kubernetes analiza o tamaño do volume e a clase de almacenamento que se require e selecciona un PersistentVolume gratuíto.

Se tales PV non están dispoñibles, Kubernetes pode lanzar un programa especial: Provisioner (o seu nome indícase na clase de almacenamento). Este programa conéctase ao sistema de almacenamento, crea un volume do tamaño necesario, recibe un identificador e crea un manifesto de PersistentVolume no clúster de Kubernetes, que está asociado co PersistentVolumeClaim.

Toda esta multitude de abstraccións permítelle eliminar información sobre con que sistema de almacenamento está a traballar a aplicación desde o nivel de manifesto da aplicación ata o nivel de administración.

Todos os parámetros para conectarse ao sistema de almacenamento de datos están situados na clase Almacenamento, da que son responsables os administradores do clúster. Todo o que tes que facer ao pasar de AWS a Google Cloud é cambiar o nome da clase Storage a PVC nos manifestos da aplicación. O volume de permanencia para o almacenamento de datos crearase no clúster automaticamente mediante o programa Provisioner.

Método 3: Interface de almacenamento de contedores

Todo o código que interactúa con varios sistemas de almacenamento forma parte do núcleo de Kubernetes. O lanzamento de correccións de erros ou a nova funcionalidade está ligado a novos lanzamentos; o código debe cambiarse para todas as versións compatibles de Kubernetes. Todo isto é difícil de manter e engadir novas funcionalidades.

Para resolver o problema, os desenvolvedores de Cloud Foundry, Kubernetes, Mesos e Docker crearon a Container Storage Interface (CSI), unha interface unificada sinxela que describe a interacción do sistema de xestión de contedores e un controlador especial (Controlador CSI) que funciona cun sistema de almacenamento. Todo o código para a interacción cos sistemas de almacenamento trasladouse do núcleo de Kubernetes a un sistema separado.

Documentación da interface de almacenamento de contedores.

Normalmente, o controlador CSI consta de dous compoñentes: Node Plugin e Controller plugin.

Node Plugin execútase en cada nodo e é responsable de montar volumes e realizar operacións neles. O complemento Controller interactúa co sistema de almacenamento: crea ou elimina volumes, asigna dereitos de acceso, etc.

Polo momento, os controladores antigos permanecen no núcleo de Kubernetes, pero xa non se recomenda o seu uso e recoméndase a todos que instalen o controlador CSI especificamente para o sistema co que traballarán.

A innovación pode asustar a aqueles que xa están afeitos a configurar o almacenamento de datos a través da clase Storage, pero de feito non pasou nada terrible. Para os programadores, nada cambia realmente: só traballaron co nome Clase de almacenamento e seguirán facéndoo. Para os administradores, engadiuse a instalación do gráfico de timón e cambiou a estrutura da configuración. Se antes a configuración se introducía directamente na clase Almacenamento, agora debe establecerse primeiro no gráfico de timón e despois na clase Almacenamento. Se o miras, non pasou nada malo.

Poñamos un exemplo para ver os beneficios que pode obter ao conectar os sistemas de almacenamento Ceph mediante o controlador CSI.

Cando se traballa con Ceph, o complemento CSI ofrece máis opcións para traballar con sistemas de almacenamento que os controladores integrados.

1. Creación dinámica de discos. Normalmente os discos RBD só se usan no modo RWO, pero CSI para Ceph permite que se utilicen no modo RWX. Varios pods en distintos nodos poden montar o mesmo disco RDB nos seus nodos e traballar con eles en paralelo. Para ser xustos, non todo é tan brillante: este disco só se pode conectar como un dispositivo de bloque, o que significa que terás que adaptar a aplicación para traballar con el en modo de acceso múltiple.
2. Creando instantáneas. Nun clúster de Kubernetes, podes crear un manifesto co requisito de crear unha instantánea. O complemento CSI verao e tirará unha instantánea do disco. Con base nel, pode facer unha copia de seguridade ou unha copia de PersistentVolume.
3. Aumentando o tamaño do disco sobre o almacenamento e o PersistentVolume no clúster de Kubernetes.
4. Cotas. Os controladores CephFS integrados en Kubernetes non admiten cotas, pero os complementos CSI novos co Ceph Nautilus máis recente poden activar cotas nas particións CephFS.
5. Métricas. O complemento CSI pode proporcionar a Prometheus unha variedade de métricas sobre os volumes conectados, cales son as comunicacións, etc.
6. Coñecendo a topoloxía. Permite especificar nos manifestos como se distribúe xeograficamente o clúster e evitar conectar un sistema de almacenamento situado en Ámsterdam aos pods que se executan en Londres.

Como conectar Ceph a un clúster de Kubernetes mediante CSI, consulte na parte práctica da charla da escola nocturna de Slurm. Tamén podes subscribirte Video curso de Ceph, que se lanzará o 15 de outubro.

Autor do artigo: Sergey Bondarev, arquitecto en exercicio en Southbridge, administrador certificado de Kubernetes, un dos desenvolvedores de kubespray.

Un pouco de Post Scriptum non para publicidade, senón para beneficio...

PS Sergey Bondarev dirixe dous cursos intensivos: actualizado Base Kubernetes 28-30 de setembro e avanzado Kubernetes Mega 14-16 de outubro.

Fonte: www.habr.com