Nota perev. : Primero hablamos sobre los llamados complementos de almacenamiento Kubernetes (Complementos de volumen CSI fuera del árbol) en nuestra revisión de la versión K8s 1.9 , donde esta característica apareció en el estado de versión alfa. El autor del nuevo material, Anoop Vijayan Maniankara (ingeniero líder de DevOps de la compañía finlandesa Tuxera), reunió información clave sobre las ideas y el dispositivo CSI, que ayuda a familiarizarse rápidamente con el nuevo concepto, que, según algunos de nuestros empleados, "será la próxima gran novedad". Para un estudio más detallado y técnico de CSI, se proporcionan enlaces útiles al final del artículo, entre los cuales destacaré especialmente la presentación de uno de los autores de esta especificación (Jie Yu). Pero vale la pena comenzar con el "panorama general" de todos modos ...
La interfaz de almacenamiento de contenedores (CSI) es una iniciativa para unificar la interfaz de los almacenes, como Ceph, Portworx, NetApp, etc., en sistemas de orquestación de contenedores: Kubernetes, Mesos, Docker Swarm, Cloud Foundry y otros. La idea es que la implementación de un CSI por parte del fabricante del almacenamiento esté garantizada para funcionar con todos estos sistemas.
Fuente de la imagen: informe CSI de Jie Yu en CloudNativeCon EU 2018Tenga en cuenta : este artículo solo hablará sobre el aprovisionamiento dinámico. Los volúmenes preconfigurados y los volúmenes flexibles van más allá de su alcance. Si desea comprender mejor lo que se discutirá, primero debe leer la documentación de Kubernetes . Además, el artículo no profundizará en los detalles de la implementación de CSI. Proporcionaré una visión general de alto nivel de CSI y sentaré las bases para crear un volumen CSI. Por último, la información de Kubernetes se utiliza para ejemplos y enlaces a detalles.Antes de profundizar en el tema, también es importante saber qué contenedores de sidecar hay en Kubernetes. Expanden las capacidades del contenedor principal (
principal ), existente en el mismo hogar, compartiendo almacenamiento y red.
Al momento de escribir este artículo
(13 de agosto de 2018), los componentes de CSI tenían las siguientes versiones:
Antes de CSI
El primer lanzamiento de CSI - v0.1 - tuvo lugar en diciembre de 2017. Por supuesto, el aprovisionamiento podría realizarse para el almacenamiento externo en sistemas de orquestación incluso antes de que apareciera. En el caso de Kubernetes, los complementos de volumen - los complementos de volumen fueron responsables de las necesidades de almacenamiento:
Como puede ver en la imagen de arriba, estos complementos son parte del núcleo del sistema de orquestación. Debido a esto, ocurrieron los siguientes problemas que se mencionaron en el
documento de arquitectura CSI :
- El desarrollo del complemento de volumen está estrechamente relacionado y depende de las versiones de Kubernetes.
- Los desarrolladores / comunidad de Kubernetes son responsables de probar y admitir todos los complementos en lugar de solo probar y mantener una API estable de complementos;
- los errores en los complementos de volumen pueden eliminar no solo el complemento en sí, sino también los componentes críticos de Kubernetes;
- los complementos obtienen todos los privilegios de los componentes de Kubernetes (kubelet y kube-controller-manager);
- los desarrolladores de complementos se ven obligados a publicar el código fuente del complemento y no pueden elegir la ruta de los binarios.
Entendiendo CSI
Al presentar CSI, el equipo de Kubernetes lanzó componentes externos que no son parte del núcleo y están diseñados para interactuar con otros componentes externos proporcionados por los fabricantes. Se comunican
entre sí a través de sockets de dominio
( sockets de dominio
UNIX - aprox. Transl.) Utilizando
gRPC .
Componentes externos de Kubernetes
Están totalmente implementados y respaldados por el equipo de Kubernetes y extienden las actividades de Kubernetes fuera de Kubernetes. Los fabricantes no pueden preocuparse en absoluto por las características de su implementación. Consta de tres partes:
- El registrador de controladores es un contenedor de sidecar que registra el controlador CSI en kubelet y agrega el controlador
NodeId a la etiqueta del objeto de nodo en la API de Kubernetes. Para hacer esto, interactúa con el servicio del controlador Identity CSI (para más detalles, ver más abajo, aprox. Transl.) Y llama a GetNodeId en CSI; - Aprovisionador externo : un contenedor de sidecar que supervisa los objetos PersistentVolumeClaim en la API de Kubernetes y llama a los
DeleteVolume CreateVolume y DeleteVolume para el controlador de punto final; - El atacante externo es un contenedor de sidecar que supervisa los objetos VolumeAttachment en la API de Kubernetes y llama a los comandos
ControllerPublish y ControllerUnpublish para el controlador de punto final.
Componente externo del fabricante de almacenamiento / tercero
Implementación específica del proveedor. Cada fabricante implementa las API necesarias como parte de las funciones del servicio gRPC. Por ejemplo, una implementación de
GCE PD o
Ceph , etc. También consisten en tres componentes:
- Identidad CSI : principalmente para identificar un complemento: asegúrese de que funciona, devuelva información básica sobre el complemento;
service Identity { // rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {} // , Controller rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {} // , , rpc Probe (ProbeRequest) returns (ProbeResponse) {} }
( kubernetes-csi-identity.proto ) - CSI Controller es responsable de controlar y administrar los volúmenes: creación, eliminación, adjuntar / separar, instantáneas, etc.
service Controller { // provisioning rpc CreateVolume (CreateVolumeRequest) returns (CreateVolumeResponse) {} // rpc DeleteVolume (DeleteVolumeRequest) returns (DeleteVolumeResponse) {} // rpc ControllerPublishVolume (ControllerPublishVolumeRequest) returns (ControllerPublishVolumeResponse) {} // rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest) returns (ControllerUnpublishVolumeResponse) {} // , / rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest) returns (ValidateVolumeCapabilitiesResponse) {} // rpc ListVolumes (ListVolumesRequest) returns (ListVolumesResponse) {} // rpc GetCapacity (GetCapacityRequest) returns (GetCapacityResponse) {} // , GetCapacity Snapshotting rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest) returns (ControllerGetCapabilitiesResponse) {} // rpc CreateSnapshot (CreateSnapshotRequest) returns (CreateSnapshotResponse) {} // rpc DeleteSnapshot (DeleteSnapshotRequest) returns (DeleteSnapshotResponse) {} // rpc ListSnapshots (ListSnapshotsRequest) returns (ListSnapshotsResponse) {} }
( kubernetes-csi-controller.proto ) - El nodo CSI es responsable de monitorear la actividad del volumen en el host Kubernetes.
service Node { // staging- rpc NodeStageVolume (NodeStageVolumeRequest) returns (NodeStageVolumeResponse) {} // staging- rpc NodeUnstageVolume (NodeUnstageVolumeRequest) returns (NodeUnstageVolumeResponse) {} // staging rpc NodePublishVolume (NodePublishVolumeRequest) returns (NodePublishVolumeResponse) {} // rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest) returns (NodeUnpublishVolumeResponse) {} // rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest) returns (NodeGetVolumeStatsResponse) {} // ID rpc NodeGetId (NodeGetIdRequest) returns (NodeGetIdResponse) { option deprecated = true; } // (capabilities) rpc NodeGetCapabilities (NodeGetCapabilitiesRequest) returns (NodeGetCapabilitiesResponse) {} // NodeGetId rpc NodeGetInfo (NodeGetInfoRequest) returns (NodeGetInfoResponse) {} }
( kubernetes-csi-node.proto )
Conclusión
El advenimiento de CSI trajo una ventaja obvia a los sistemas de orquestación y a los fabricantes de almacenamiento. Además, las interfaces bien definidas ayudan a la implementación y prueba simples de CSI tanto para desarrolladores como para futuros sistemas de orquestación. Si decide comenzar a implementar su CSI después de leer este artículo, el
complemento Cómo escribir una interfaz de almacenamiento de contenedores (CSI) de Fatih Arslan
es un buen punto de partida.
Referencias
- Especificación CSI ;
- Contenedores de sidecar en Kubernetes ;
- Informe de Jie Yu CSI en KubeCon EU: CloudNativeCon EU 2018 (y aquí está el video de esta presentación - aprox. Transl.) ;
- Documento de arquitectura CSI
- Documentación actual sobre CSI de Kubernetes ;
- Documentación obsoleta de Kubernetes CSI .
PD del traductor
Lea también en nuestro blog: