Alguns aplicativos também precisam armazenar dados, mas ficam bastante confortáveis com o fato de que os dados não serão salvos após uma reinicialização.
Por exemplo, os serviços de cache são limitados pela RAM, mas também podem mover dados que raramente são usados para um armazenamento mais lento que a RAM, com pouco impacto no desempenho geral. Outros aplicativos precisam estar cientes de que pode haver alguma entrada somente leitura nos arquivos, como configurações ou chaves secretas.
Kubernetes já possui vários tipos , mas sua funcionalidade é limitada ao que está implementado nos K8s.
Efêmero permitiu que o Kubernetes fosse estendido com drivers CSI para fornecer suporte para volumes locais leves. Dessa forma é possível usar : configurações, segredos, dados de identificação, variáveis e assim por diante. Os drivers CSI devem ser modificados para suportar esse recurso do Kubernetes, pois presume-se que os drivers padronizados regulares não funcionarão - mas presume-se que tais volumes possam ser usados em qualquer nó selecionado para o pod.
Isto pode ser um problema para volumes que consomem recursos de host significativos ou para armazenamento que está disponível apenas em alguns hosts. É por isso que o Kubernetes 1.19 introduz dois novos recursos de volume de teste alfa que são conceitualmente semelhantes aos volumes EmptyDir:
-
volumes efêmeros de uso geral;
-
Rastreamento da capacidade de armazenamento CSI.
Vantagens da nova abordagem:
-
o armazenamento pode ser local ou conectado através de uma rede;
-
os volumes podem ter um tamanho especificado que não pode ser excedido pelo aplicativo;
-
funciona com qualquer driver CSI que suporte o provisionamento de volumes persistentes e (para oferecer suporte ao rastreamento de capacidade) implemente a chamada
GetCapacity; -
os volumes podem ter alguns dados iniciais dependendo do driver e das configurações;
-
todas as operações padrão com um volume (criação de instantâneo, redimensionamento, etc.) são suportadas;
-
os volumes podem ser usados com qualquer controlador de aplicativo que aceite uma especificação de módulo ou volume;
-
O agendador Kubernetes seleciona os nós adequados por conta própria, portanto não há mais necessidade de provisionar e configurar extensões do agendador ou modificar webhooks.
Opções de aplicação
Portanto, os volumes efêmeros de uso geral são adequados para os seguintes casos de uso:
Memória persistente como substituto da RAM para memcached
Últimos lançamentos do memcached usando memória persistente (Intel Optane, etc., Aproximadamente. tradutor) em vez de RAM normal. Ao implantar o memcached por meio de um controlador de aplicativo, você pode usar volumes efêmeros de uso geral para solicitar que um volume de determinado tamanho seja alocado do PMEM usando o driver CSI, por exemplo .
Armazenamento local LVM como espaço de trabalho
Os aplicativos que trabalham com dados maiores que a RAM podem exigir armazenamento local com um tamanho ou métricas de desempenho que os volumes vazios regulares do Kubernetes não podem fornecer. Por exemplo, para este propósito foi escrito .
Acesso somente leitura para volumes de dados
A alocação de um volume pode resultar na criação de um volume completo quando:
-
recuperação ;
-
criando ;
-
trabalho .
Esses volumes podem ser montados no modo somente leitura.
Как это работает
Volumes efêmeros de uso geral
Um recurso importante dos volumes efêmeros de uso geral é a nova fonte de volume, EphemeralVolumeSource, contendo todos os campos para criar uma solicitação de volume (historicamente chamada de solicitação de volume persistente, PVC). Novo controlador em kube-controller-manager analisa os pods que criam essa origem de volume e, em seguida, cria um PVC para esses pods. Para o driver CSI, esta solicitação é igual às outras, portanto, nenhum suporte especial é necessário aqui.
Enquanto tais PVCs existirem, eles poderão ser usados como quaisquer outras solicitações no volume. Em particular, eles podem ser referenciados como fonte de dados ao copiar um volume ou criar um instantâneo 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 uma combinação do nome do pod e do nome do volume, separados por um hífen. Os nomes predefinidos facilitam a interação com o PVC porque você não precisa procurá-lo se souber o nome do pod e do volume. A desvantagem é que o nome pode já estar em uso, o que é detectado pelo Kubernetes e, como resultado, o início do pod é bloqueado.
Para garantir que o volume seja excluído junto com o pod, o controlador faz uma solicitação ao volume do proprietário. Quando o pod é excluído, o mecanismo padrão de coleta de lixo funciona, o que exclui a solicitação e o volume.
As solicitações são correspondidas pelo driver de armazenamento por meio do mecanismo normal da classe de armazenamento. Embora as classes com ligação imediata e tardia (também conhecidas como WaitForFirstConsumer) são suportados, para volumes efêmeros faz sentido usar WaitForFirstConsumer, o planejador poderá considerar o uso do nó e a disponibilidade de armazenamento ao selecionar um nó. Um novo recurso aparece aqui.
Rastreamento de capacidade de armazenamento
Normalmente, o agendador não tem conhecimento de onde o driver CSI criará o volume. Também não há como o agendador entrar em contato diretamente com o motorista para solicitar essas informações. Portanto, o escalonador pesquisa os nós até encontrar um em que os volumes possam ser acessados (ligação tardia) ou deixa a escolha do local inteiramente para o driver (ligação imediata).
Novo CSIStorageCapacity, que está em fase alfa, permite que os dados necessários sejam armazenados no etcd para que fiquem disponíveis para o agendador. Ao contrário do suporte para volumes efêmeros de uso geral, ao implantar o driver, você deve habilitar o rastreamento da capacidade de armazenamento: external-provisioner deve publicar as informações de capacidade recebidas do motorista via normal GetCapacity.
Se o agendador precisar selecionar um nó para um pod com um volume não vinculado que usa ligação tardia e o driver tiver habilitado esse recurso durante a implantação definindo o sinalizador CSIDriver.storageCapacity, os nós que não tiverem capacidade de armazenamento suficiente serão automaticamente descartados. Isso funciona para volumes efêmeros e persistentes de uso geral, mas não para volumes efêmeros CSI porque seus parâmetros não podem ser lidos pelo Kubernetes.
Como de costume, os volumes imediatamente vinculados são criados antes do agendamento dos pods e seu posicionamento é escolhido pelo driver de armazenamento, portanto, ao configurar external-provisioner Por padrão, as classes de armazenamento com ligação imediata são ignoradas, pois esses dados não serão usados de qualquer maneira.
Como o agendador do Kubernetes é forçado a trabalhar com informações potencialmente desatualizadas, não há garantia de que a capacidade estará disponível em todos os casos quando o volume for criado, mas as chances de ele ser criado sem novas tentativas aumentam, mesmo assim.
NB Você pode obter informações mais detalhadas, bem como “praticar na barraca dos gatos” com segurança e, em caso de situação totalmente incompreensível, receber suporte técnico qualificado em cursos intensivos - será realizada de 28 a 30 de setembro, e para especialistas mais avançados 14 a 16 de outubro.
segurança
Capacidade de armazenamento CSIS
Os objetos CSIStorageCapacity residem em namespaces; ao implementar cada driver CSI em seu próprio namespace, é recomendado restringir os direitos RBAC ao CSIStorageCapacity nesse espaço, pois é óbvio de onde os dados vêm. De qualquer maneira, o Kubernetes não verifica isso e geralmente os drivers são colocados no mesmo namespace; portanto, espera-se que os drivers funcionem e não publiquem dados incorretos (e foi aí que minha placa falhou, Aproximadamente. tradutor baseado em uma piada barbuda)
Volumes efêmeros de uso geral
Se os usuários tiverem direitos para criar um pod (direta ou indiretamente), eles também poderão criar volumes efêmeros de uso geral, mesmo que não tenham direitos para criar uma solicitação no volume. Isso ocorre porque as verificações de permissão do RBAC são aplicadas ao controlador que cria o PVC, e não ao usuário. Esta é a principal mudança a ser adicionada , antes de ativar esse recurso em clusters onde usuários não confiáveis não deveriam ter direitos para criar volumes.
Exemplo
Separado PMEM-CSI contém todas as alterações necessárias para executar um cluster Kubernetes 1.19 dentro de máquinas virtuais QEMU com todos os recursos do estágio alfa. O código do driver não mudou, apenas a implantação mudou.
Em uma máquina adequada (Linux, um usuário normal pode usar , ver detalhes) estes comandos abrirã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:
The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in. Alternatively, use kubectl directly with the
following env variable:
KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Os objetos CSIStorageCapacity não devem ser lidos por humanos, portanto, é necessário algum processamento. Os filtros do modelo Golang mostrarão as classes de armazenamento, este exemplo mostrará o nome, topologia e capacidade:
$ 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 único objeto possui o seguinte conteúdo:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels: <none>
Annotations: <none>
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: <none>
Vamos tentar criar um aplicativo de demonstração com um único volume efêmero de uso geral. 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, conforme mostrado nas instruções acima, agora temos um pod adicional e PVC:
$ 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 <none> <none>
$ 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
Proprietário de PVC - em:
$ 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
...
Informações esperadamente atualizadas 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 outra aplicação precisar de mais de 26620Mi, o agendador não levará em consideração pmem-csi-pmem-govm-worker1 em todo o caso.
Qual é o próximo?
Ambos os recursos ainda estão em desenvolvimento. Vários aplicativos foram abertos durante o teste alfa. Os links de propostas de melhoria documentam o trabalho que precisa ser feito para passar para a fase beta, bem como quais alternativas já foram consideradas e rejeitadas:
Fonte: habr.com