Nota perev. : Conversamos pela primeira vez sobre os chamados plug-ins de armazenamento Kubernetes (Out-of-Tree CSI Volume Plugins) em nossa análise da versão K8s 1.9 , onde esse recurso apareceu no status da versão alfa. O autor do novo material, Anoop Vijayan Maniankara (engenheiro líder de DevOps da empresa finlandesa Tuxera), reuniu informações importantes sobre as idéias e o dispositivo CSI, que ajuda a se familiarizar rapidamente com o novo conceito, que, segundo alguns de nossos funcionários, “será a próxima grande novidade”. Para um estudo mais detalhado e técnico da CSI, links úteis são fornecidos no final do artigo, entre os quais destacamos especialmente a apresentação de um dos autores desta especificação (Jie Yu). Mas vale a pena começar com o "quadro geral" de qualquer maneira ...
A CSI (Container Storage Interface) é uma iniciativa para unificar a interface de armazenamentos, como Ceph, Portworx, NetApp, etc., em sistemas de orquestração de contêineres: Kubernetes, Mesos, Docker Swarm, Cloud Foundry e outros. A idéia é que a implementação de um CSI pelo fabricante de armazenamento funcione com todos esses sistemas.
Fonte da imagem: Relatório Jie Yu CSI no CloudNativeCon EU 2018Observe : este artigo fala apenas sobre provisionamento dinâmico. Volumes pré-configurados e flex volumes vão além de seu escopo. Se você quiser entender melhor o que será discutido, leia primeiro a documentação do Kubernetes . Além disso, o artigo não se aprofundará nos detalhes da implementação do CSI. Vou fornecer uma visão geral de alto nível do CSI e estabelecer as bases para a criação de um volume CSI. Por fim, as informações do Kubernetes são usadas para exemplos e links para detalhes.Antes de mergulhar no tópico, também é importante saber o que são os contêineres laterais no Kubernetes. Eles expandem os recursos do contêiner principal (
principal ), existente no mesmo coração, compartilhando armazenamento e rede.
No momento da redação deste artigo
(13 de agosto de 2018), os componentes CSI tinham as seguintes versões:
Antes da CSI
A primeira versão do CSI - v0.1 - ocorreu em dezembro de 2017. Obviamente, o provisionamento poderia ser feito para armazenamento externo em sistemas de orquestração antes mesmo de aparecer. No caso do Kubernetes, plugins de volume - os plugins de volume foram responsáveis pelas necessidades de armazenamento:
Como você pode ver na figura acima, esses plug-ins fazem parte do núcleo do sistema de orquestração. Por esse motivo, ocorreram os seguintes problemas mencionados no
documento de arquitetura CSI :
- O desenvolvimento do plug-in de volume está intimamente relacionado e depende das versões do Kubernetes.
- Os desenvolvedores / comunidade do Kubernetes são responsáveis por testar e dar suporte a todos os plugins, em vez de apenas testar e manter uma API de plug-in estável;
- os bugs nos plug-ins de volume podem eliminar não apenas o próprio plug-in, mas também componentes críticos do Kubernetes;
- os plugins obtêm privilégios totais dos componentes do Kubernetes (kubelet e kube-controller-manager);
- Os desenvolvedores de plug-ins são forçados a publicar o código-fonte do plug-in e não podem escolher o caminho dos binários.
Entendendo CSI
Apresentando o CSI, a equipe do Kubernetes lançou componentes externos que não fazem parte do kernel e foram projetados para interagir com outros componentes externos fornecidos pelos fabricantes. Eles se comunicam por meio de soquetes de domínio
(soquetes de domínio UNIX - aprox. Transl.) Usando
gRPC .
Componentes externos do Kubernetes
Eles são totalmente implementados e suportados pela equipe do Kubernetes e estendem as atividades do Kubernetes fora do Kubernetes. Os fabricantes não podem se preocupar com os recursos de sua implementação. Consistem em três partes:
- O registrador de driver é um contêiner lateral que registra o driver CSI no kubelet e adiciona o driver
NodeId ao rótulo do objeto do nó na API do Kubernetes. Para fazer isso, ele interage com o serviço de driver do Identity CSI (para obter mais detalhes, veja abaixo - aprox. Transl.) E chama GetNodeId no CSI; - Provedor externo - um contêiner lateral que monitora os objetos PersistentVolumeClaim na API Kubernetes e chama os
DeleteVolume CreateVolume e CreateVolume para o driver do nó de extremidade; - O attacher externo é um contêiner lateral que monitora os objetos VolumeAttachment na API do Kubernetes e chama os comandos
ControllerUnpublish e ControllerUnpublish para o driver do nó de extremidade.
Componente externo do fabricante de armazenamento / terceiros
Implementação específica do fornecedor. Cada fabricante implementa as APIs necessárias como parte das funções do serviço gRPC. Por exemplo, uma implementação de
GCE PD ou
Ceph , etc. Eles também consistem em três componentes:
- Identidade CSI - principalmente para identificar um plugin: verifique se ele funciona, retorne informações básicas sobre o plugin;
service Identity { // rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {} // , Controller rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {} // , , rpc Probe (ProbeRequest) returns (ProbeResponse) {} }
( kubernetes-csi-identity.proto ) - O CSI Controller é responsável por controlar e gerenciar volumes: criação, exclusão, anexar / desanexar, instantâneos, 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 ) - O nó CSI é responsável pelo monitoramento da atividade do volume no 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 )
Conclusão
O advento do CSI trouxe uma vantagem óbvia aos sistemas de orquestração e aos fabricantes de armazenamento. Além disso, interfaces bem definidas ajudam a implementação e teste simples de CSI para desenvolvedores e futuros sistemas de orquestração. Se você decidir começar a implementar seu CSI depois de ler este artigo, o
plugin Como Escrever um CSI (Container Storage Interface) da Fatih Arslan
é um bom ponto de partida.
Referências
- Especificação CSI ;
- Contêineres laterais em Kubernetes ;
- Relatório CSI de Jie Yu no KubeCon EU: CloudNativeCon EU 2018 (e aqui está o vídeo desta apresentação - aprox. Transl.) ;
- Documento de arquitetura CSI
- Documentação atual sobre CSI do Kubernetes ;
- Documentação CSI obsoleta do Kubernetes .
PS do tradutor
Leia também em nosso blog: