Alguns aplicativos também precisam armazenar dados, mas eles lidam relativamente bem com o fato de que os dados não serão mantidos após a reinicialização.
Por exemplo, serviços de cache são limitados em memória RAM, mas também podem mover dados que são raramente usados para um armazenamento que opera mais lentamente do que a memória RAM, com pouco impacto no desempenho geral. Outros aplicativos precisam saber que podem haver alguns arquivos apenas para leitura, como configurações ou chaves secretas.
No Kubernetes, já existem vários tipos , mas sua funcionalidade é limitada ao que está implementado no K8s.
Volumes permitiram que o Kubernetes fosse expandido com drivers CSI para dar suporte a volumes locais leves. Dessa forma, é possível aplicar : configurações, segredos, dados de identidade, variáveis e assim por diante. Os drivers CSI precisam ser aprimorados para suportar essa função do Kubernetes, uma vez que se presume que os drivers padronizados comuns não funcionarão — mas espera-se que tais volumes possam ser usados em qualquer nó escolhido para o pod.
Isso pode se tornar um problema para volumes que consomem recursos significativos do nó ou para o armazenamento disponível apenas em alguns nós. Portanto, no Kubernetes 1.19, duas novas funções de volume foram apresentadas para testes alfa, conceitualmente semelhantes aos volumes EmptyDir:
volumes efêmeros de uso geral;
monitoramento da capacidade de armazenamento CSI.
As vantagens da nova abordagem:
o armazenamento pode ser local ou montado pela rede;
os volumes podem ter um tamanho definido que não pode ser excedido pelo aplicativo;
funciona com qualquer driver CSI que suporta a provisão de volumes persistentes e (para suporte ao monitoramento da capacidade) implementa a chamada
GetCapacity;os volumes podem ter alguns dados iniciais, dependendo do driver e dos parâmetros;
todas as operações típicas de volume (criação de snapshot, redimensionamento etc.) são suportadas;
os volumes podem ser usados com qualquer controlador de aplicativo que aceite a especificação de módulo ou volume;
O programador Kubernetes escolhe os nós adequados, portanto, não é mais necessário fornecer e configurar extensões do programador e modificar webhooks.
Opções de aplicação
Assim, volumes efêmeros de uso geral são adequados para as seguintes opções de aplicação:
Memória persistente como substituto da memória RAM para memcached
Últimos lançamentos do memcached para o uso de memória persistente (Intel Optane, etc., Nota do tradutor) em vez de memória RAM convencional. Ao implantar memcached através do controlador de aplicativos, é possível, utilizando volumes efêmeros de uso geral, fazer uma solicitação para alocar um volume de tamanho específico de PMEM usando o driver CSI, por exemplo, .
Armazenamento local LVM como espaço de trabalho
Aplicativos que trabalham com dados cujo tamanho excede o tamanho da memória RAM podem solicitar armazenamento local com tamanho ou métricas de desempenho que não podem ser fornecidas por volumes EmptyDir convencionais do Kubernetes. Por exemplo, para esse fim, foi escrito .
Acesso somente leitura para volumes de dados
A alocação de um volume pode resultar na criação de um volume preenchido em:
restauração ;
criação ;
trabalho .
Esses volumes podem ser montados em modo somente leitura.
Como funciona
Volumes efêmeros de uso geral
Uma característica chave dos volumes efêmeros de uso geral é a nova fonte de volume, EphemeralVolumeSource, que contém todos os campos para criar uma solicitação para o volume (historicamente, isso é chamado de solicitação para um volume persistente, PVC). Um novo controlador em kube-controller-manager examina os pods que criam tal fonte de volume e, em seguida, cria PVCs para esses pods. Para o driver CSI, essa solicitação parece igual às outras, portanto, não requer suporte especial.
Enquanto esses PVCs existirem — podem ser usados como qualquer outra solicitação de volume. Em particular, eles podem ser referenciados como uma fonte de dados ao copiar um volume ou criar um snapshot a partir de um volume. O objeto PVC também contém o estado atual do volume.
Os nomes dos PVCs criados automaticamente são predefinidos: são combinações do nome do pod e do nome do volume, separados por um hífen. Essa predefinição facilita a interação com os PVCs, pois não é necessário procurar o PVC se o nome do pod e o nome do volume forem conhecidos. A desvantagem é que o nome já pode estar em uso, o que o Kubernetes detecta e, como resultado, impede a inicialização do pod.
Para garantir que o volume seja excluído junto com o pod, o controlador torna o pod o proprietário do pedido do volume. Quando o pod é removido, um mecanismo padrão de limpeza é acionado, que remove tanto o pedido quanto o volume.
Os pedidos são mapeados ao driver de armazenamento através do mecanismo padrão de classe de armazenamento. Embora as classes de vinculação imediata e tardia (também conhecidas como WaitForFirstConsumer) sejam apoiadas, para volumes efêmeros faz sentido usar WaitForFirstConsumer, pois assim o programador pode levar em conta tanto o uso do nó quanto a disponibilidade de armazenamento ao escolher um nó. Aqui surge uma nova funcionalidade.
Acompanhamento da capacidade de armazenamento
Normalmente, o programador não possui dados sobre onde o driver CSI criará o volume. Também não há como o programador se comunicar diretamente com o driver para solicitar essas informações. Portanto, o programador interroga os nós até encontrar um no qual os volumes possam estar disponíveis (vinculação tardia), ou deixa completamente a escolha do local a cargo do driver (vinculação imediata).
Novo CSIStorageCapacity, que está em fase alpha, permite o armazenamento dos dados necessários no etcd, de modo que eles estejam disponíveis para o programador. Ao contrário da suporte a volumes efêmeros de uso geral, ao implantar o driver é necessário ativar o acompanhamento da capacidade de armazenamento: external-provisioner deve publicar informações sobre a capacidade, obtidas do driver através do padrão GetCapacity.
Se o programador precisar selecionar um nó para um pod com um volume não vinculado, utilizando vinculação tardia, e o driver ativou essa funcionalidade durante a implantação definindo o flag CSIDriver.storageCapacity, então serão automaticamente descartados os nós que não possuem capacidade de armazenamento suficiente. Isso funciona tanto para volumes efêmeros de uso geral quanto para volumes persistentes, mas não para volumes efêmeros CSI, pois suas características não podem ser lidas pelo Kubernetes.
Como de costume, os volumes com ligação imediata são criados antes do planejamento dos pods, e sua alocação é escolhida pelo driver de armazenamento, portanto, ao configurar external-provisioner por padrão, as classes de armazenamento com ligação imediata são puladas, pois esses dados de qualquer forma não serão utilizados.
Como o agendador do Kubernetes é obrigado a trabalhar com informações potencialmente desatualizadas, não há garantias de que a capacidade estará disponível quando o volume for criado, no entanto, as chances de que ele seja criado sem tentativas repetidas aumentam.
N.B. Você poderá obter informações mais detalhadas e até mesmo treinar em um ambiente seguro, e em caso de situações realmente incompreensíveis, obter assistência qualificada do suporte técnico nas intensivas — acontecerá de 28 a 30 de setembro, e para profissionais mais avançados de 14 a 16 de outubro.
Segurança
CSIStorageCapacity
Os objetos CSIStorageCapacity estão em namespaces, ao implantar cada driver CSI em seu namespace, é recomendável restringir os direitos RBAC para CSIStorageCapacity nesse namespace, pois é óbvio de onde vêm os dados. De qualquer forma, o Kubernetes não verifica isso, e geralmente os drivers são implantados em um único namespace, então no final espera-se que os drivers funcionem e não publiquem dados incorretos (e aqui eu me empolguei, nota do tradutor baseada em uma piada antiga)
Volumes efêmeros de uso geral
Se os usuários têm permissões para criar um pod (diretamente ou indiretamente), eles também poderão criar volumes efêmeros de uso geral, mesmo que não tenham permissões para criar uma solicitação de volume. Isso ocorre porque as verificações de permissões RBAC são aplicadas ao controlador que cria o PVC e não ao usuário. Esta é a principal alteração a ser adicionada , antes de ativar essa função em clusters, se usuários não confiáveis não devem ter permissão para criar volumes.
Exemplo
Uma no PMEM-CSI contém todas as alterações necessárias para rodar um cluster Kubernetes 1.19 dentro de máquinas virtuais QEMU com todas as funções em fase alpha. O código do driver não foi modificado, apenas o deployment.
Em uma máquina apropriada (Linux, um usuário comum pode usar , veja os detalhes) esses comandos iniciarão o cluster e instalarão o driver PMEM-CSI:
git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh
Depois que tudo funcionar, a saída conterá instruções de uso:
O cluster de teste está pronto. Faça login com [...]\/pmem-csi\/_work\/pmem-govm\/ssh.0, execute
kubectl uma vez logado. Alternativamente, use kubectl diretamente com a
seguinte variável de ambiente:
KUBECONFIG=[...]\/pmem-csi\/_work\/pmem-govm\/kube.config
secret\/pmem-csi-registry-secrets criado
secret\/pmem-csi-node-secrets criado
serviceaccount\/pmem-csi-controller criado
...
Para experimentar os volumes efêmeros do driver pmem-csi:
cat deploy\/kubernetes-1.19\/pmem-app-ephemeral.yaml |
[...]\/pmem-csi\/_work\/pmem-govm\/ssh.0 kubectl create -f -
Os objetos CSIStorageCapacity não foram projetados para serem lidos por humanos, então alguma manipulação é necessária. Com filtros de modelo em Golang, serão mostradas classes de armazenamento; neste exemplo, nome, topologia e capacidade serão exibidos:
$ kubectl get
-o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}'
csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Um objeto separado tem o seguinte conteúdo:
$ kubectl describe csistoragecapacities\/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels:
Annotations:
API Version: storage.k8s.io\/v1alpha1
Capacity: 30716Mi
Kind: CSIStorageCapacity
Metadata:
Creation Timestamp: 2020-08-11T15:41:03Z
Generate Name: csisc-
Managed Fields:
...
Owner References:
API Version: apps\/v1
Controller: true
Kind: StatefulSet
Name: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Resource Version: 2994
Self Link: \/apis\/storage.k8s.io\/v1alpha1\/namespaces\/default\/csistoragecapacities\/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
Match Labels:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Storage Class Name: pmem-csi-sc-late-binding
Events:
Vamos tentar criar um aplicativo de demonstração com um único volume efêmero de uso geral. O conteúdo do arquivo pmem-app-ephemeral.yaml:
# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app-inline-volume
spec:
containers:
- name: my-frontend
image: intel/pmem-csi-driver-test:v0.7.14
command: [ "sleep", "100000" ]
volumeMounts:
- mountPath: "/data"
name: my-csi-volume
volumes:
- name: my-csi-volume
ephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
storageClassName: pmem-csi-sc-late-binding
Após a criação, como mostrado nas instruções acima, temos um pod e PVC adicionais:
$ kubectl get pods\/my-csi-app-inline-volume -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-csi-app-inline-volume 1\/1 Running 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc\/my-csi-app-inline-volume-my-csi-volume
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-csi-app-inline-volume-my-csi-volume Bound pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
O proprietário do PVC é o pod:
$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
creationTimestamp: "2020-08-11T15:44:57Z"
finalizers:
- kubernetes.io/pvc-protection
managedFields:
...
name: my-csi-app-inline-volume-my-csi-volume
namespace: default
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: true
controller: true
kind: Pod
name: my-csi-app-inline-volume
uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...
A informação foi atualizada como esperado para pmem-csi-pmem-govm-worker1:
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Se outro aplicativo precisar de mais do que 26620Mi, o planejador não levará em consideração pmem-csi-pmem-govm-worker1 em qualquer cenário.
E agora?
Ambas as funcionalidades ainda estão em desenvolvimento. Várias solicitações foram abertas durante os testes alpha. Links com sugestões de melhorias estão documentando o trabalho que precisa ser feito para passar para a fase beta, bem como quais alternativas já foram consideradas e rejeitadas:
Fonte: habr.com
