Presentación de la versión alfa de instantáneas de volumen en Kubernetes



Nota perev. : El artículo original fue publicado recientemente en el blog de Kubernetes y fue escrito por empleados de Google y Huawei (Jing Xu, Xing Yang, Saad Ali), cuya actividad activa ciertamente ha visto en el GitHub del proyecto, si alguna vez ha estado interesado en las características y problemas de K8 relacionados con con almacenamiento de datos Los ingenieros hablan sobre el propósito de las instantáneas de volumen, sus capacidades actuales y los conceptos básicos para trabajar con ellas.

Kubernetes v1.12 introdujo una versión alfa de soporte para instantáneas para volúmenes. Esta característica le permite crear y eliminar instantáneas de volúmenes, así como crear nuevos volúmenes a partir de instantáneas utilizando los medios "nativos" del sistema, a través de la API de Kubernetes.

¿Qué es una instantánea?


Muchos sistemas de almacenamiento (como Google Cloud Persistent Disks, Amazon Elastic Block Storage y numerosos sistemas de almacenamiento en las instalaciones) ofrecen la posibilidad de crear una instantánea ("instantánea") para un volumen persistente. Una instantánea es una copia de un volumen en un momento determinado. Se puede utilizar para proporcionar un nuevo volumen (ya lleno de datos de una instantánea) o restaurar un volumen existente a un estado anterior (que se presenta en una instantánea).

¿Por qué agregar instantáneas a Kubernetes?


Ya se encuentra disponible una potente abstracción en el sistema de plug-in de volumen de Kubernetes, que automatiza el aprovisionamiento, la conexión y el montaje de almacenamientos de bloques y archivos.

Proporcionar todas estas capacidades es parte de los objetivos de tolerancia de carga de trabajo de Kubernetes: Kubernetes busca crear una capa de abstracción entre las aplicaciones que funcionan como sistemas distribuidos y clústeres subyacentes para que las aplicaciones sean independientes del clúster específico en el que se ejecutan, y la implementación de la aplicación no requiere cualquier conocimiento específico del clúster.

Kubernetes Storage SIG ha identificado las operaciones de instantáneas como capacidades críticas para una variedad de cargas de trabajo con estado. Por ejemplo, un administrador de base de datos puede querer tomar una instantánea de su base de datos antes de realizar cualquier operación en ella.

Habiendo recibido el método estándar para invocar operaciones de instantáneas en la API de Kubernetes, los usuarios de Kubernetes pueden trabajar con ellos sin la necesidad de soluciones alternativas (y la invocación manual de operaciones que son específicas del sistema de almacenamiento). En cambio, los usuarios tuvieron la oportunidad de integrar operaciones de instantáneas en sus herramientas y políticas con el tranquilo entendimiento de que todo funcionará con cualquier clúster de Kubernetes, independientemente del almacenamiento subyacente.

Además, estas primitivas de Kubernetes funcionan como bloques de construcción básicos, abriendo el camino para el desarrollo de características más avanzadas de nivel empresarial para la gestión del almacenamiento, por ejemplo, para protección, replicación y migración de datos.

¿Qué complementos de volumen admiten instantáneas en Kubernetes?


Kubernetes admite tres tipos de complementos de volumen: en árbol, Flex y CSI. Consulte las Preguntas frecuentes sobre el complemento de volumen de Kubernetes para obtener más información.

Las instantáneas solo son compatibles con los controladores CSI (no son compatibles ni en el árbol ni en Flex). Para aprovechar esta característica, asegúrese de que el controlador CSI que implementa el soporte de instantáneas esté implementado en el clúster de Kubernetes.

En el momento de esta publicación de blog (9 de octubre de 2018 - aprox. Transl. ) , Las instantáneas son compatibles con los siguientes controladores CSI:


El soporte para instantáneas para otros controladores está en desarrollo y debería estar disponible pronto. En la publicación " Interfaz de almacenamiento de contenedores (CSI) para Kubernetes Goes Beta " (y también vea nuestra traducción de la nota " Comprender la interfaz de almacenamiento de contenedores (en Kubernetes y más) ", se describen más detalles sobre CSI y cómo implementar controladores CSI. - aprox. Transl. ) .

API de Kubernetes para instantáneas


Para administrar instantáneas, Kubernetes Volume Snapshots presenta tres nuevos objetos API de la misma manera que en la API de volúmenes persistentes de Kubernetes:

  • VolumeSnapshot
    • Creado por el usuario de Kubernetes para solicitar una instantánea para el volumen especificado. Contiene información sobre la operación de la instantánea, como la marca de tiempo para eliminar la instantánea y si está lista para su uso.
    • Al igual que el objeto PersistentVolumeClaim , crear y eliminar este objeto representa el deseo del usuario de crear o eliminar un recurso de clúster (instantánea).
  • VolumeSnapshotContent
    • Creado por el controlador CSI cuando la instantánea se creó con éxito. Contiene información sobre la instantánea, incluida su ID.
    • Al igual que un objeto PersistentVolume , representa un recurso ya atendido por el clúster (instantánea).
    • Al igual que los objetos PersistentVolumeClaim y PersistentVolume , cuando se crea una instantánea, el objeto VolumeSnapshotContent adjunta a la VolumeSnapshot para la que se creó (se utiliza la asignación uno a uno).
  • VolumeSnapshotClass
    • Definido por los administradores de clúster para describir qué instantáneas se pueden crear. Incluye información del conductor, secretos para acceder a instantáneas, etc.

Es importante tener en cuenta que, a diferencia de los principales objetos de volumen persistente en Kubernetes, estos objetos instantáneos se definen como CustomResourceDefinitions (CRD) . El proyecto Kubernetes se aleja gradualmente de los tipos de recursos predefinidos en el Servidor API, acercándose a un modelo en el que el Servidor API es independiente de los objetos API. Este enfoque le permite reutilizar el servidor API en otros proyectos (además de Kubernetes), y los consumidores (como Kubernetes) pueden establecer los tipos de recursos que necesitan como CRD.

Los controladores CSI que admiten instantáneas instalarán automáticamente los CRD necesarios. Los usuarios finales de Kubernetes solo necesitan verificar que el controlador CSI que admite instantáneas esté implementado en el clúster.

Además de estos nuevos objetos, el PersistentVolumeClaim existente PersistentVolumeClaim un nuevo campo DataSource :

 type PersistentVolumeClaimSpec struct { AccessModes []PersistentVolumeAccessMode Selector *metav1.LabelSelector Resources ResourceRequirements VolumeName string StorageClassName *string VolumeMode *PersistentVolumeMode DataSource *TypedLocalObjectReference } 

Este campo (en el estado de versión alfa) le permite llenarlo automáticamente con datos de una instantánea existente al crear un nuevo volumen.

Requisitos de la instantánea de Kubernetes


Antes de usar instantáneas de volumen en Kubernetes, debe:

  • asegúrese de que el controlador CSI que implementa las instantáneas esté implementado y ejecutándose en el clúster;
  • habilite la función de instantáneas de volumen de Kubernetes a través de la nueva puerta de funciones (deshabilitada por defecto para la versión alfa):
    • establezca el siguiente indicador para el --feature-gates=VolumeSnapshotDataSource=true servidor API: --feature-gates=VolumeSnapshotDataSource=true

Antes de crear una instantánea, también debe determinar qué controlador CSI usar, lo que se hace creando un objeto VolumeSnapshotClass y especificando el controlador CSI en el campo de la snapshotter . En el ejemplo de VolumeSnapshotClass continuación, este controlador es com.example.csi-driver . Cada proveedor de instantáneas requiere al menos un objeto VolumeSnapshotClass . También es posible definir una VolumeSnapshotClass predeterminada para cada controlador CSI; esto se hace configurando snapshot.storage.kubernetes.io/is-default-class: "true" anotación snapshot.storage.kubernetes.io/is-default-class: "true" en la definición de clase:

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: default-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" snapshotter: com.example.csi-driver apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-snapclass snapshotter: com.example.csi-driver parameters: fakeSnapshotOption: foo csiSnapshotterSecretName: csi-secret csiSnapshotterSecretNamespace: csi-namespace 

Todos los parámetros requeridos deben establecerse de acuerdo con la documentación del controlador CSI. En el ejemplo anterior, el parámetro fakeSnapshotOption: foo y todos los secretos mencionados se pasarán al controlador CSI durante la creación y eliminación de la instantánea. CSI external-snapshotter de forma predeterminada guarda las claves de parámetro csiSnapshotterSecretName y csiSnapshotterSecretNamespace .

Finalmente, antes de crear una instantánea, debe crear el volumen a través del controlador CSI y llenarlo con los datos que desea ver allí (consulte esta publicación para obtener detalles sobre cómo usar los volúmenes CSI).

Crear una nueva instantánea en Kubernetes


Una vez que el objeto VolumeSnapshotClass definido y es el volumen del que desea eliminar la instantánea, puede realizar esta operación creando el objeto VolumeSnapshot .

La fuente de la instantánea está determinada por dos parámetros:

  • kind : aquí PersistentVolumeClaim indica PersistentVolumeClaim ;
  • name : el nombre real del objeto de PVC.

Se entiende que el espacio de nombres del volumen para el que se crea la instantánea está determinado por el espacio de nombres del objeto VolumeSnapshot .

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: new-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass source: name: mypvc kind: PersistentVolumeClaim 

La especificación VolumeSnapshot puede VolumeSnapshot una VolumeSnapshotClass que contiene información sobre qué controlador CSI se utilizará para crear la instantánea. Como se informó anteriormente, después de crear el objeto VolumeSnapshot el parámetro fakeSnapshotOption: foo y todos los secretos mencionados de VolumeSnapshotClass se pasan al complemento CSI com.example.csi-driver en la llamada CreateSnapshot .

En respuesta a dicha solicitud, el controlador CSI toma una instantánea del volumen y luego crea automáticamente un objeto VolumeSnapshotContent que representa la nueva instantánea y vincula este objeto a VolumeSnapshot , VolumeSnapshot listo para usar. Si el controlador CSI no puede crear una instantánea y devuelve un error, el controlador de la instantánea informa este error en el estado del objeto VolumeSnapshot y no hace nuevos intentos (este comportamiento es diferente de otros controladores en Kubernetes; se implementa para no crear una instantánea en momentos impredecibles) .

Si no se especifica la clase de instantánea, external-snapshotter intentará encontrar la clase predeterminada y usarla para la instantánea creada. En este caso, el controlador CSI señalado por el snapshotter en la clase predeterminada debe corresponder al controlador CSI señalado por el provisioner en la clase de almacenamiento de PVC.

Tenga en cuenta que la publicación alfa de instantáneas para Kubernetes no proporciona una garantía de coherencia. Para garantizar datos completos en una instantánea, es necesario preparar adecuadamente la aplicación (detener la aplicación, congelar el sistema de archivos, etc.) antes de eliminarla.

Para VolumeSnapshot que el objeto VolumeSnapshot ha VolumeSnapshot creado y asociado con el VolumeSnapshotContent , puede usar el kubectl describe volumesnapshot :

  • Ready debe ser true en Status , lo que indicará que la instantánea de volumen está lista para su uso.
  • El campo Creation Time muestra cuándo se tomó realmente la instantánea.
  • El campo Restore Size es el tamaño de volumen mínimo para restaurar una instantánea.
  • El campo Snapshot Content Name en la especificación apunta al objeto VolumeSnapshotContent creado para esta instantánea.

Importar una instantánea existente en Kubernetes


Se puede importar una instantánea existente en Kubernetes creando manualmente un objeto VolumeSnapshotContent que representará esta instantánea. Dado que VolumeSnapshotContent es un objeto API que no está vinculado a un espacio de nombres, solo el administrador del sistema tiene los derechos para crearlo.

Cuando se VolumeSnapshotContent objeto VolumeSnapshotContent , el usuario puede crear otro objeto, VolumeSnapshot , que lo señalará. El controlador externo de instantáneas marcará la instantánea como lista después de verificar la existencia y la conexión correcta entre los VolumeSnapshotContent VolumeSnapshot y VolumeSnapshotContent . Una instantánea está lista para usarse en Kubernetes cuando se establece esta conexión.

El objeto VolumeSnapshotContent debe crearse con los siguientes campos que representan la instantánea preaprovisionada:

  • csiVolumeSnapshotSource : información que identifica una instantánea:
    • snapshotHandle : nombre / identificador de la instantánea. Campo obligatorio;
    • driver : el controlador CSI solía funcionar con este volumen. Campo obligatorio Debe coincidir con el nombre de la snapshotter en el controlador (controlador de instantánea);
    • creationTime y restoreSize : para volúmenes restoreSize , estos campos son opcionales. El controlador externo de instantáneas las actualizará automáticamente después de crear una instantánea.
  • volumeSnapshotRef : puntero al objeto VolumeSnapshot al que se debe adjuntar este objeto (es decir, VolumeSnapshotContent ):
    • name y namespace : el nombre y el espacio de nombres del objeto VolumeSnapshot cuyos contenidos están vinculados;
    • UID : campo opcional (para volúmenes preparados previamente). El controlador de instantáneas externas actualizará automáticamente este campo después del enlace. Si el usuario define este campo, debe asegurarse de que coincida con el UID de la instantánea para la que se produce el enlace. Si no existe dicha correspondencia, el contenido se considera irrelevante (objeto huérfano) y, por lo tanto, el controlador lo eliminará tanto a él como a la instantánea asociada.
  • snapshotClassName es un campo opcional. El controlador externo de instantáneas lo actualizará automáticamente después del enlace.

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: static-snapshot-content spec: csiVolumeSnapshotSource: driver: com.example.csi-driver snapshotHandle: snapshotcontent-example-id volumeSnapshotRef: kind: VolumeSnapshot name: static-snapshot-demo namespace: demo-namespace 

Se debe crear un objeto VolumeSnapshot para que el usuario pueda trabajar con la instantánea. En ella:

  • snapshotClassName : nombre de la clase de instantánea del volumen. Campo opcional. Si se establece, el campo de snapshotter en la clase de instantánea debe coincidir con el nombre del controlador de instantánea. Si no se establece, el controlador buscará la clase de instantánea predeterminada;
  • snapshotContentName : el nombre del contenido del volumen de la instantánea. Campo obligatorio para volúmenes preparados previamente.

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: static-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass snapshotContentName: static-snapshot-content 

Cuando se crean estos objetos, el controlador de instantáneas los vinculará, establecerá el campo Ready (en Status ) en True , lo que indica que la instantánea está lista para su uso.

Preparación de un nuevo volumen a partir de una instantánea en Kubernetes


Para crear un nuevo volumen dataSource previamente con datos del objeto de instantánea, use el nuevo campo dataSource en PersistentVolumeClaim . Tiene tres parámetros:

  • name : nombre del objeto VolumeSnapshot que representa el origen de la instantánea;
  • kind : debe establecerse como VolumeSnapshot ;
  • apiGroup : debe ser snapshot.storage.k8s.io .

Se supone que el espacio de nombres de la fuente, VolumeSnapshot , coincide con el espacio de nombres de PersistentVolumeClaim .

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-restore Namespace: demo-namespace spec: storageClassName: csi-storageclass dataSource: name: new-snapshot-demo kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 1Gi 

Cuando se crea el objeto PersistentVolumeClaim , llamará al aprovisionamiento del nuevo volumen, rellenado previamente con datos de la instantánea especificada.

¿Cómo agregar compatibilidad con instantáneas a mi controlador CSI si soy un desarrollador de almacenamiento?


Para proporcionar soporte para las instantáneas, se deben agregar capacidades de controlador adicionales al controlador CSI: CREATE_DELETE_SNAPSHOT y LIST_SNAPSHOTS , así como controladores RPC adicionales: CreateSnapshot , DeleteSnapshot , ListSnapshots . Consulte la especificación CSI para más detalles.

Aunque Kubernetes proporciona las pautas más básicas para empaquetar e implementar el Controlador de volumen CSI, existe un mecanismo recomendado para implementar un controlador CSI arbitrario en contenedores en Kubernetes para simplificar este proceso.

Como parte del proceso de implementación recomendado, el equipo de Kubernetes sugiere utilizar una variedad de contenedores de sidecar (es decir, auxiliares), incluido un contenedor de sidecar con un snapshotter externo .

El mencionado snapshotter externo supervisa los objetos VolumeSnapshot y VolumeSnapshotContent en el Servidor API, invocando las DeleteSnapshot CreateSnapshot y DeleteSnapshot para el punto final CSI. El contenedor de sidecar con el aprovisionador externo CSI también se ha actualizado para admitir la recuperación de volumen de instantáneas utilizando el nuevo campo PVC dataSource .

Para admitir las capacidades de instantáneas, se recomienda a los fabricantes de almacenamiento implementar contenedores de sidecar con un snapshotter externo además de un aprovisionador externo, y colocar el controlador CSI en un StatefulSet , como se muestra en el siguiente diagrama:



En este ejemplo de implementación, hay dos contenedores de sidecar, un aprovisionador externo y un snapshotter externo, y los controladores CSI se implementan con el complemento CSI hostpath dentro del pod StatefulSet. El CSI hostpath es un complemento de ejemplo que no está diseñado para usarse en producción.

¿Cuáles son las limitaciones de la versión alfa?


La versión alfa de la implementación de la instantánea en Kubernetes tiene las siguientes limitaciones:

  • No se admite la reversión de un volumen existente a un estado anterior representado por una instantánea (solo se admite el aprovisionamiento de un nuevo volumen desde una instantánea).
  • La restauración en contexto no es compatible con PersistentVolumeClaim existente de la instantánea: es decir el aprovisionamiento de un nuevo volumen de la instantánea funciona, pero no actualiza el PersistentVolumeClaim existente para que apunte a un nuevo volumen y el PVC vuelva a un estado anterior (solo se admite el uso de un nuevo volumen creado a partir de una instantánea a través de un nuevo PV / PVC).
  • Las garantías para la coherencia de las instantáneas no van más allá de las garantías proporcionadas por el sistema de almacenamiento (por ejemplo, integridad cuando se descarta).

Que sigue


El equipo de Kubernetes planea llevar la implementación de instantáneas para CSI a la versión beta en las versiones 1.13 o 1.14, dependiendo de los comentarios recibidos y la adaptación de la tecnología.

¿Cómo encontrar más detalles?


Consulte la documentación adicional de instantáneas en k8s.io/docs/concepts/storage/volume-snapshots y kubernetes-csi.imtqy.com/docs .

PD del traductor


Lea también en nuestro blog:

Source: https://habr.com/ru/post/es426133/


All Articles