Table of Contents

Introdução

Devido à natureza distribuída e dinâmica dos contêineres, gerenciar e configurar o armazenamento de maneira estática se transformou em um problema no Kubernetes, uma vez que agora as cargas de trabalho conseguem mover-se de uma máquina virtual (VM) para outra em questão de segundos. Para lidar com a questão, o Kubernetes gerencia os volumes com um sistema de Persistent Volumes (PV) (volumes persistentes), objetos de API que representam uma configuração de armazenamento/volume e de PersistentVolumeClaims (PVC), uma solicitação por armazenamento atendida por um volume persistente. Além disso, drivers da Interface de Armazenamento de Contêiner (CSI) podem ajudar a automatizar e gerenciar o manuseamento e fornecimento de armazenamento para cargas de trabalho em contêiner. Esses drivers são responsáveis pelo fornecimento, montagem, desmontagem, remoção e serviços de instantâneo de volumes.

O the cloud provider-csi integra um cluster do Kubernetes com o produto armazenamento em bloco da the cloud provider. Um desenvolvedor pode usar isso para fornecer volumes de armazenamento de bloco dinamicamente para aplicativos em contêiner no Kubernetes. No entanto, os aplicativos podem, por vezes, exigir que dados sejam mantidos e partilhados por vários Droplets. A solução padrão CSI de armazenamento em bloco da the cloud provider não consegue suportar a montagem de um volume de armazenamento de bloco em muitos Droplets simultaneamente. Isso significa que esta é uma solução *ReadWriteOnce* (RWO) (Ler e escrever uma vez), uma vez que o volume é limitado a um nó. O protocolo de Sistema de Arquivos de Rede (NFS), por outro lado, dá suporte à exportação da mesma quantidade a muitos consumidores. Isso se chama *ReadWriteMany* (RWX) (Ler e escrever muitos), pois muitos nós podem montar o volume como leitura-gravação. Assim, podemos usar um servidor NFS dentro do nosso cluster para fornecer armazenamento que pode potencializar o suporte confiável do armazenamento em bloco da the cloud provider com a flexibilidade das quantidades do NFS.

Neste tutorial, você irá configurar o fornecimento dinâmico de volumes NFS dentro de um cluster Kubernetes (DOKS) no qual as exportações são armazenadas em volumes de armazenamento em bloco da the cloud provider. Em seguida, implantará várias instâncias de um aplicativo de demonstração Nginx e testará o compartilhamento de dados entre cada instância.

Pré-requisitos

com illustration for: Pré-requisitos

Antes de iniciar este guia, você precisará do seguinte:

  • A interface de linha de comando kubectl instalada em sua máquina local. Você pode ler mais sobre como instalar e configurar o kubectl em sua documentação oficial.
  • Um cluster do Kubernetes da the cloud provider com sua conexão configurada como o kubectl padrão. Para criar um cluster do Kubernetes na the cloud provider, consulte nosso Guia de início rápido do Kubernetes. As instruções sobre como configurar o kubectl são mostradas no passo Conexão com seu cluster, quando você criar seu cluster.

Nota: a partir da versão 3.0 do Helm, o Tiller já não precisa estar instalado para que o Helm funcione. Caso esteja usando a versão mais recente do Helm, consulte a documentação de instalação do Helm para obter instruções.

Passo 1 — Implantando o servidor NFS com o Helm

Para implantar o servidor NFS, você usará um gráfico do Helm. Comparada à implantação manual do servidor NFS, a implantação de um gráfico do Helm se apresenta como uma solução automatizada mais rápida e menos suscetível a erros.

Primeiro, certifique-se de que o repositório padrão de gráficos stable esteja disponível para você, adicionando o repo:

				
					
helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Em seguida, puxe os metadados para o repositório que acabou de adicionar. Isso garantirá que o cliente do Helm esteja atualizado:

				
					
helm repo update

Para verificar o acesso ao repo stable, execute uma pesquisa nos gráficos:

				
					
helm search repo stable

Isso dará a você a lista de gráficos disponíveis, semelhante a esta:

				
					
[secondary_label Output]

NAME CHART VERSION APP VERSION DESCRIPTION

stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools

stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes

stable/airflow 5.2.4 1.10.4 Airflow is a platform to programmatically autho...

stable/ambassador 5.3.0 0.86.1 A Helm chart for Datawire Ambassador

...

Esse resultado significa que seu cliente do Helm está em execução e atualizado.

Agora que o Helm está configurado, instale o gráfico do Helm nfs-server-provisioner para configurar o servidor NFS. Caso queira examinar o conteúdo do gráfico, consulte sua documentação no GitHub.

Quando implantar o gráfico do Helm, você vai definir algumas variáveis para seu servidor NFS para especificar ainda mais a configuração do seu aplicativo. Você também pode investigar outras opções de configuração e ajustá-las para se adequarem às necessidades do aplicativo.

Para instalar o gráfico do Helm, use o seguinte comando:

				
					
helm install nfs-server stable/nfs-server-provisioner --set persistence.enabled=true,persistence.storageClass=do-block-storage,persistence.size=200Gi

Esse comando provisiona o servidor NFS com as seguintes opções de configuração:

  • Adiciona um volume persistente ao servidor NFS com o sinalizador --set. Isso garante que todos os dados do NFS compartilhados permaneçam nas reinicializações do pod.
  • Para o armazenamento persistente, usa a classe de armazenamento do-block-storage.
  • Provisiona um total de 200 Gi para que o servidor NFS consiga dividir em exportações.

Nota: a opção persistence.size determinará a capacidade total de todos os volumes NFS que você pode provisionar. No momento em que este artigo foi publicado, apenas a versão 1.16.2-do.3 e posteriores do DOKS ofereciam suporte à expansão de volumes. Dessa maneira, se você estiver usando uma versão mais antiga do DOKS, o redimensionamento desse volume terá que ser feito manualmente. Caso seja esse o caso, certifique-se de definir esse tamanho levando em conta suas necessidades futuras.

Depois que esse comando terminar, você receberá um resultado semelhante ao seguinte:

				
					
[secondary_label Output]

NAME: nfs-server

LAST DEPLOYED: Thu Feb 13 19:30:07 2020

NAMESPACE: default

STATUS: deployed

REVISION: 1

TEST SUITE: None

NOTES:

The NFS Provisioner service has now been installed.



A storage class named 'nfs' has now been created

and is available to provision dynamic volumes.



You can use this storageclass by creating a PersistentVolumeClaim with the

correct storageClassName attribute. For example:



 ---

 kind: PersistentVolumeClaim

 apiVersion: v1

 metadata:

 name: test-dynamic-volume-claim

 spec:

 storageClassName: "nfs"

 accessModes:

 - ReadWriteOnce

 resources:

 requests:

 storage: 100Mi

Para ver o servidor NFS que você provisionou, execute o seguinte comando:

				
					
kubectl get pods

Isso mostrará o seguinte:

				
					
[secondary_label Output]

NAME READY STATUS RESTARTS AGE

nfs-server-nfs-server-provisioner-0 1/1 Running 0 11m

Em seguida, verifique a storageclass que você criou:

				
					
kubectl get storageclass

Isso dará um resultado parecido com este:

				
					
[secondary_label Output]

NAME PROVISIONER AGE

do-block-storage (default) www.progressiverobot.com 90m

nfs cluster.local/nfs-server-nfs-server-provisioner 3m

Agora, você tem um servidor NFS em execução, bem como uma storageclass que pode usar para o provisionamento dinâmico de volumes. Em seguida, você poderá criar uma implantação que usará esse armazenamento, compartilhando-a em múltiplas instâncias.

Passo 2 — Implantando um aplicativo usando um PersistentVolumeClaim compartilhado

Neste passo, você criará uma implantação de exemplo no seu cluster DOKS para testar sua configuração de armazenamento. A implantação será a de um app de servidor Web Nginx chamado web.

Para implantar esse aplicativo, primeiro grave o arquivo YAML para especificar a implantação. Abra um arquivo nginx-test.yaml com seu editor de texto; este tutorial usará o nano:

				
					
nano nginx-test.yaml

Neste arquivo, adicione as linhas a seguir para definir a implantação com um PersistentVolumeClaim chamado nfs-data:

				
					
[label nginx-test.yaml]

apiVersion: apps/v1

kind: Deployment

metadata:

 labels:

 app: web

 name: web

spec:

 replicas: 1

 selector:

 matchLabels:

 app: web

 strategy: {}

 template:

 metadata:

 creationTimestamp: null

 labels:

 app: web

 spec:

 containers:

 - image: nginx:latest

 name: nginx

 resources: {}

 volumeMounts:

 - mountPath: /data

 name: data

 volumes:

 - name: data

 persistentVolumeClaim:

 claimName: nfs-data

---

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

 name: nfs-data

spec:

 accessModes:

 - ReadWriteMany

 resources:

 requests:

 storage: 2Gi

 storageClassName: nfs

Salve o arquivo e saia do editor de texto.

Essa implantação (web) foi configurada para usar o nfs-data do PersistentVolumeClaim (PVC) que a acompanha e para montá-la em /data.

Na definição do PVC, você descobrirá que o storageClassName está definido como nfs. Isso diz ao cluster para atender esse armazenamento, usando as regras de storageClass nfs que você criou no passo anterior. O novo PersistentVolumeClaim será processado e, em seguida, um compartilhamento NFS será provisionado para atender à solicitação e à declaração, na forma de um Volume Persistente. O pod tentará montar aquele PVC assim que ele tiver sido provisionado. Assim que terminar a montagem, você verificará a funcionalidade ReadWriteMany (RMX).

Execute a implantação com o seguinte comando:

				
					
kubectl apply -f nginx-test.yaml

Isso dará o seguinte resultado:

				
					
[secondary_label Output]

deployment.apps/web created

persistentvolumeclaim/nfs-data created

Em seguida, verifique e veja o pod web em funcionamento:

				
					
kubectl get pods

Isso irá mostrar o seguinte:

				
					
[secondary_label Output]

NAME READY STATUS RESTARTS AGE

nfs-server-nfs-server-provisioner-0 1/1 Running 0 23m

<^>web-64965fc79f-b5v7w 1/1 Running 0 4m<^>

Agora que a implantação de exemplo está em funcionamento, você pode dimensioná-la para três instâncias, usando o comando kubectl scale:

				
					
kubectl scale deployment web --replicas=3

Isso dará o resultado:

				
					
[secondary_label Output]

deployment.extensions/web scaled

Agora, execute o kubectl get novamente:

				
					
kubectl get pods

Você encontrará as instâncias dimensionadas da implantação:

				
					
[secondary_label Output]

NAME READY STATUS RESTARTS AGE

nfs-server-nfs-server-provisioner-0 1/1 Running 0 24m

<^>web-64965fc79f-q9626<^> 1/1 Running 0 5m

<^>web-64965fc79f-qgd2w<^> 1/1 Running 0 17s

<^>web-64965fc79f-wcjxv<^> 1/1 Running 0 17s

Agora, você tem três instâncias da sua implantação do Nginx, conectadas ao mesmo Volume Persistente. No próximo passo, você irá garantir que elas possam compartilhar dados entre si.

Passo 3 — Validando o compartilhamento de dados do NFS

No passo final, você validará a configuração para que os dados sejam compartilhados por todas as instâncias que foram montadas para o compartilhamento do NFS. Para fazer isso, criará um arquivo no diretório /data em um dos pods e, em seguida, verificará se o arquivo existe no diretório /data de outro pod.

Para validar isso, você usará o comando kubectl exec. Esse comando permite que você especifique um pod e execute um comando dentro daquele pod. Para aprender mais sobre a inspeção de recursos usando o kubectl, veja nossa Folha de referências do kubectl.

Para criar um arquivo chamado hello_world dentro de um dos seus pods web, use o kubectl exec para repassar o comando touch. Note que o número após web – no nome do pod – será diferente para você. Assim, certifique-se de substituir o nome do pod destacado por um dos pods que você apurou no resultado do comando kubectl get pods, no último passo.

				
					
kubectl exec <^>web-64965fc79f-q9626<^> -- touch /data/hello_world

Em seguida, altere o nome do pod e use o comando ls para listar os arquivos no diretório /data de um outro pod:

				
					
kubectl exec <^>web-64965fc79f-qgd2w<^> -- ls /data

Seu resultado mostrará o arquivo que criou no primeiro pod:

				
					
[secondary_label Output]

hello_world

Isso mostra que todos os pods compartilham dados usando o NFS e que sua configuração está funcionando corretamente.

Conclusão

Neste tutorial, você criou um servidor NFS com apoio do armazenamento em bloco da the cloud provider. Depois, o servidor NFS usou aquele armazenamento em bloco para provisionar e exportar os compartilhamentos NFS para as cargas de trabalho em um protocolo compatível com RWX. Ao fazer isso, você conseguiu contornar uma limitação técnica do armazenamento em bloco da the cloud provider e compartilhar os mesmos dados do PVC em muitos pods. Por seguir este tutorial, agora o seu cluster DOKS está configurado para acomodar um conjunto muito mais amplo de casos de uso de implantação.

Caso queira aprender mais sobre o Kubernetes, confira nosso Currículo de Kubernetes para desenvolvedores full-stack, ou examine a documentação de produto do Kubernetes da the cloud provider.