Primeiramente, o assunto dessa publicação não é definir qual é a melhor opção. Portanto, aos comentaristas com ânsia em apontar a melhor ou a pior alternativa, estejam cientes desde já.

O assunto dessa publicação é, simplesmente, contribuir para quem precisa de provisionar um volume Kubernetes usando um serviço Network File System (NFS) como backend.

Vamos lá?

A priori, a Google Cloud (GCP) não disponibiliza Persistent Volume com ReadWriteMany de maneira nativa. Atualmente, é necessário contratar uma solução gerenciada chamada Filestore.

O ReadWriteMany é útil quando mais de um workload precisa ler e escrever num mesmo volume, mesmo estando em nós diferentes. Por exemplo, se você tem um Deployment com cinco réplicas e cada Pod precisa de escrever no mesmo volume.

Dito isso, a criação de um serviço NFS para disponibilizar um share é um meio disponível. Na prática, o custo de uma VM e um disco persistente. Ou até mesmo um serviço no próprio cluster.

Nessa publicação, espera-se que você já tenha um share de NFS pronto e disponível.

Crie os seguintes objetos Kubernetes:

PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: share
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  mountOptions:
    - nfsvers=4.2
  nfs:
    server: "nfs.domain.tld"
    path: "/my-share"
    readOnly: false
  # Se você quiser tornar esse PV exclusivo ao PVC
  # claimRef:
  #   name: 
  #   namespace:

PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: share
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ""
  volumeName: share

Perceba que ambos possuem storageClassName com uma string vazia. Isso acontece para evitar que ele adote por um armazenamento diferente do que estamos buscando.

E, além disso, o PVC buscará pelo PV através de volumeName. Sendo parte da técnica de binding.

Por sua vez, o PV também pode fazer binding ao PVC através de claimRef. Isso seria a técnica completa. Se preferir, pode definir o claimRef para o nome e namespace do PVC. Nesse exemplo, não foi necessário.

O PV precisa do bloco nfs configurado com server e path com o serviço NFS disponível. Ou seja, defina o endereço IP ou nome DNS no campo spec.nfs.server e defina o caminho do share no campo spec.nfs.path.

Essa é a configuração de utilizar um serviço NFS por trás de um PV.

Assim, é possível você definir o volume no seu Deployment por exemplo:

  ...
  containers:
  - image: busybox
    name: teste
    volumeMounts:
    - mountPath: /opt/teste
      name: volume-compartilhado
  volumes:
  - name: volume-compartilhado
    persistentVolumeClaim:
      claimName: share

Simples?

Em caso de problemas, verifique se o serviço NFS tem regras de firewall permitindo a rede do nó, ou se há alguma restrição com permissão de usuários sobre o diretório utilizado no servidor.