Nutanix Enterprise AI no NKPParte 2: Nutanix Files para o Kubernetes

Resumo: o Nutanix Enterprise AI guarda os modelos num volume ReadWriteMany (RWX), e a storage class padrão do NKP é a do Nutanix Volumes, ReadWriteOnce; o RWX vem do Nutanix Files. Nesta parte eu crio um Nutanix Files 5.4.0.1 pelo Prism Central (3 FSVMs, 5 TiB, 27 minutos), habilito NFS v3 e v4, testo a montagem numa VM e ligo o Files ao Kubernetes. Um detalhe de configuração que vale conhecer: o CSI do NKP 2.19 roda em modo Prism Central, e o Files dinâmico precisa de um secret próprio com um usuário de REST API do file server. No fim, um volume RWX fica pronto em 6 segundos, e dois pods em nós diferentes gravam no mesmo arquivo. Esta é a parte 2 de 4.

Onde estamos

A série acompanha a habilitação do Nutanix Enterprise AI (NAI) num lab com NKP 2.19 e cluster HCI Nutanix sem GPU.

Antes de instalar o NAI, li o User Guide da versão 2.8.1 e os dois Nutanix Validated Designs que tratam dele. Os três concordam num pré-requisito que o NKP não entrega pronto: storage compartilhado em NFS. Esta parte resolve isso de ponta a ponta, e serve para qualquer aplicação no NKP que precise de RWX, não só para o NAI.

Por que o NAI precisa de RWX

Um volume no Kubernetes tem um modo de acesso. Os dois que importam aqui:

O NAI baixa cada modelo uma vez e o deixa num volume compartilhado. Quando um endpoint ganha uma segunda réplica, ou quando o pod é recriado em outro nó, ele lê os pesos do mesmo lugar, sem baixar tudo de novo. Por isso o volume dos modelos precisa ser RWX.

O que o User Guide do NAI 2.8.1 pede de storage:

A arquitetura

O Nutanix Files roda como um conjunto de VMs no próprio cluster HCI, as FSVMs (File Server VMs). Elas servem NFS para os clientes e guardam os dados num storage container do cluster. Do lado do Kubernetes, o CSI da Nutanix faz duas coisas diferentes: pela API REST do Files, cria um share para cada volume pedido; pelo NFS, monta esse share no nó onde o pod roda.

Planejamento: as decisões antes do assistente

Tamanho

Os NVDs da Nutanix usam FSVMs de 12 vCPU e 64 GB em produção. Num lab, o recurso escasso é memória, então fui no mínimo suportado.

As 3 FSVMs somam 36 GB de RAM. Fiz a conta do cluster antes: o lab tem 3 hosts, e eu quero que tudo continue rodando se um host cair (N+1), o que limita o uso a cerca de dois terços da memória total.

Rede

O assistente pede duas redes. No lab existe uma só VLAN, gerenciada pelo IPAM do AHV, então as duas ficaram nela.

DNS e NTP

O Files pede servidores de DNS e NTP. O lab não tem DNS interno, e eu quis confirmar o que o gateway resolvia antes de preencher:

$ dig @192.0.2.1 pe.lab.exemplo.local
;; WARNING: .local is reserved for Multicast DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; AUTHORITY SECTION:
.   86400  IN  SOA  a.root-servers.net. nstld.verisign-grs.com. ...

NXDOMAIN com o SOA da raiz da internet: o gateway só encaminha consultas para fora e não conhece o domínio interno. Consequência prática: os clientes vão montar o Files pelo IP, não pelo nome. Funciona bem, e o CSI aceita IP normalmente.

Licença

O Files é licenciado pela Nutanix Unified Storage (NUS), medida em TiB utilizáveis. Antes de criar, conferi o que estava aplicado no cluster:

Criando o file server pelo Prism Central

Objetivo: um file server com 3 FSVMs, 5 TiB e NFS, criado pelo assistente do Prism Central (Files → File Servers → New File Server).

O ponto de partida, sem nenhum file server:

1. Local: Prism Central ou Prism Element

A primeira tela pede o provider (Nutanix, AWS ou Azure) e já traz um aviso: alguns recursos não são suportados em file servers criados pelo Prism Central; para usá-los, crie pelo Prism Element.

Segui pelo Prism Central. Esse aviso pesa na escolha da proteção (veja a seção de proteção).

2. Cluster e versão

O assistente lista só as versões compatíveis e disponíveis no LCM. Havia 13; escolhi a mais nova, a 5.4.0.1.

3. Básico e dimensionamento

Nome (até 15 caracteres, sem ponto), domínio DNS, capacidade lógica e o tamanho das FSVMs.

4. Rede client e rede storage

As duas telas mostram a faixa do IPAM, quantos IPs estão livres e quantos o file server vai usar: 3 na client, 4 na storage.

5. Settings: DNS, NTP e dois interruptores para Kubernetes

Esta é a tela mais importante, porque nada aqui muda depois do deploy.

O campo Deployment Profile tem três opções:

E os dois interruptores:

6. Resumo

O deploy: 27 minutos

O Prism Central criou as 3 FSVMs nos primeiros 90 segundos e depois montou a imagem do Files e configurou o cluster de file server.

O dashboard do file server já abriu Healthy, sem alertas e com os 5 TiB livres:

Logo depois do Succeeded, o Files ainda rodou duas tarefas: FS Deploy VG Create e Volume Group Manage. É o Containerized Workload em ação, pré-criando os volume groups que os shares do Kubernetes vão usar.

A rede do file server

A tela de rede mostra o desenho e os IPs que o IPAM entregou:

O quarto IP da rede storage (o “+1” do assistente) não aparece na tabela da interface. Ele existe; procure no IPAM da sub-rede se precisar registrar.

O container que o Files cria

O assistente cria um storage container só para o file server, NTNX_files-lab_ctr. Conferi as propriedades contra o NVD do GPT-in-a-Box:

Igual ao recomendado, sem mexer em nada. Os 32 GiB já usados logo após o deploy são os volume groups pré-criados.

Habilitando o NFS

O file server nasce sem protocolo. Em Configuration → Authentication, habilitei só o NFS:

Primeiro export e o teste manual

Antes de envolver o Kubernetes, testei o Files sozinho, com um export de 10 GiB montado numa VM Linux.

Standard ou Distributed

O squash e o sudo

Na tela de permissões, o padrão é Root Squash:

Com root squash, o root do cliente vira um usuário anônimo no servidor. Como o meu teste gravava com sudo, ele falharia com Permission denied. Para o teste, troquei para None:

Montando numa VM

$ sudo apt install -y nfs-common
$ sudo mount -t nfs4 192.0.2.128:/teste-nfs /mnt/teste-nfs
$ echo "ok $(date)" | sudo tee /mnt/teste-nfs/teste.txt
ok Fri Oct 30 01:56:55 AM UTC 2026
$ df -h /mnt/teste-nfs
Filesystem               Size  Used Avail Use% Mounted on
192.0.2.132:/teste-nfs      0     0     0    - /mnt/teste-nfs
$ mount | grep teste-nfs
192.0.2.132:/teste-nfs on /mnt/teste-nfs type nfs4 (rw,vers=4.2,proto=tcp,sec=sys,addr=192.0.2.132)

Três coisas para reparar:

1. Montei pelo .128 e terminei no .132. Num export Standard, uma FSVM só atende o export inteiro, e o Files usa o redirecionamento do NFSv4 para mandar o cliente para ela. O cliente pode usar qualquer IP client.
2. NFS 4.2, negociado sozinho.
3. O df mostra tamanho 0. O Files não expõe a cota do export ao cliente NFS. Não é erro; vale saber para não estranhar.

O Kubernetes enxergando o Files

O que já existe no NKP

O NKP instala o CSI da Nutanix em todo cluster. O inventário do cluster de workload:

$ kubectl get sc
NAME                       PROVISIONER                              VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION
dkp-object-store           <workspace>.ceph.rook.io/bucket          Immediate              false
nutanix-volume (default)   csi.nutanix.com                          WaitForFirstConsumer   true

$ kubectl get csidrivers
NAME              ATTACHREQUIRED   PODINFOONMOUNT   MODES
csi.nutanix.com   true             true             Persistent

$ kubectl -n ntnx-system get ds,deploy -o wide | grep csi
daemonset.apps/nutanix-csi-node         6 6 6 ...  docker.io/nutanix/ntnx-csi:3.9.0
deployment.apps/nutanix-csi-controller  2/2 ...    docker.io/nutanix/ntnx-csi:3.9.0

O driver é o 3.9.0, a storage class padrão é a de Volumes (RWO) e existe um único secret de credenciais, ntnx-system/nutanix-csi-credentials.

O detalhe: o CSI está em modo Prism Central

A documentação do CSI 3.x mostra o Files dinâmico com o driver falando com o Prism Element, e um secret com uma segunda chave, files-key. Antes de copiar o exemplo, verifiquei com quem o CSI do NKP fala, sem expor nenhuma senha:

# Só os nomes das chaves do secret
$ kubectl -n ntnx-system get secret nutanix-csi-credentials \
    -o go-template='{{range $k,$v := .data}}{{$k}}{{"\n"}}{{end}}'
key

# Só host e porta da chave (o comando corta usuário e senha)
$ kubectl -n ntnx-system get secret nutanix-csi-credentials \
    -o jsonpath='{.data.key}' | base64 -d | cut -d: -f1,2
192.0.2.88:9440

$ kubectl -n ntnx-system get deploy nutanix-csi-controller -o yaml \
    | grep -iE 'usepc|use_pc|management-plane|mixed'
    app.kubernetes.io/management-plane: PrismCentral
        - name: USE_PC
        - --use-mixed-mode=false

O endereço é o do Prism Central, e o controller tem USE_PC. O CSI do NKP 2.19 roda em modo PC.

1. Usuário de REST API no file server

O files-key usa um usuário da API do próprio file server, não do Prism. Ele é criado no console do file server, em Configuration → Manage Roles → REST API access users:

2. Secret próprio

O script lê a chave do Prism Central do secret do NKP e monta o novo secret sem mostrar nada na tela:

read -rp  "Usuário de REST API do file server: " FU
read -rsp "Senha (não aparece): " FP; echo
PCKEY=$(kubectl -n ntnx-system get secret nutanix-csi-credentials \
          -o jsonpath='{.data.key}' | base64 -d)
kubectl -n ntnx-system create secret generic nutanix-files-csi \
  --from-literal=key="$PCKEY" \
  --from-literal=files-key="192.0.2.128:$FU:$FP"
unset PCKEY FP

Usei o IP client no files-key, e não o nome, porque os nós do lab não resolvem o domínio interno.

3. A storage class

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nai-nfs
provisioner: csi.nutanix.com
parameters:
  storageType: NutanixFiles
  dynamicProv: ENABLED
  nfsServerName: files-lab        # nome do file server no Prism
  nfsServer: 192.0.2.128          # IP client: montagem e API
  squashType: "none"
  csi.storage.k8s.io/provisioner-secret-name: nutanix-files-csi
  csi.storage.k8s.io/provisioner-secret-namespace: ntnx-system
  csi.storage.k8s.io/node-publish-secret-name: nutanix-files-csi
  csi.storage.k8s.io/node-publish-secret-namespace: ntnx-system
  csi.storage.k8s.io/controller-expand-secret-name: nutanix-files-csi
  csi.storage.k8s.io/controller-expand-secret-namespace: ntnx-system
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate      # exigência do NAI

O teste RWX: dois nós, um arquivo

O teste cria um PVC RWX de 2 GiB e um deployment com 2 réplicas, obrigadas a cair em nós diferentes (podAntiAffinity). Cada réplica grava uma linha a cada 5 segundos no mesmo arquivo:

apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: rwx-teste }
spec:
  accessModes: [ReadWriteMany]
  storageClassName: nai-nfs
  resources: { requests: { storage: 2Gi } }
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: rwx-escritor }
spec:
  replicas: 2
  selector: { matchLabels: { app: rwx-escritor } }
  template:
    metadata: { labels: { app: rwx-escritor } }
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector: { matchLabels: { app: rwx-escritor } }
            topologyKey: kubernetes.io/hostname
      containers:
      - name: c
        image: busybox:1.36
        command: ["sh","-c","while true; do echo \"$(date -u +%H:%M:%S) $(hostname) no nó $NODE\" >> /dados/log.txt; sleep 5; done"]
        env: [{ name: NODE, valueFrom: { fieldRef: { fieldPath: spec.nodeName } } }]
        volumeMounts: [{ name: d, mountPath: /dados }]
      volumes: [{ name: d, persistentVolumeClaim: { claimName: rwx-teste } }]

O resultado:

$ kubectl -n files-teste get pvc rwx-teste
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
rwx-teste   Bound    pvc-bc03c1b0-8456-4cda-a43c-3a5f70b446ea   2Gi        RWX            nai-nfs        6s

$ kubectl -n files-teste get pods -o wide
NAME                            READY   STATUS    NODE
rwx-escritor-68f798cf6d-v5s5s   1/1     Running   worker-a
rwx-escritor-68f798cf6d-wrlph   1/1     Running   worker-b

$ kubectl -n files-teste exec <pod> -- tail -6 /dados/log.txt
02:38:48 rwx-escritor-68f798cf6d-wrlph no nó worker-b
02:38:50 rwx-escritor-68f798cf6d-v5s5s no nó worker-a
02:38:53 rwx-escritor-68f798cf6d-wrlph no nó worker-b
02:38:55 rwx-escritor-68f798cf6d-v5s5s no nó worker-a
02:38:58 rwx-escritor-68f798cf6d-wrlph no nó worker-b
02:39:00 rwx-escritor-68f798cf6d-v5s5s no nó worker-a

linhas por pod:
      5 rwx-escritor-68f798cf6d-v5s5s
      5 rwx-escritor-68f798cf6d-wrlph

$ kubectl -n files-teste exec <pod> -- mount | grep /dados
192.0.2.128:/pvc-bc03c1b0-... on /dados type nfs4 (rw,vers=4.2,proto=tcp,...)

As linhas das duas réplicas se intercalam: dois nós gravando no mesmo arquivo. Isso é RWX.

O que o CSI fez por baixo

O log do controller mostra o caminho completo, em cerca de 2,6 segundos:

Using Files secrets available in PC Mode
GET  https://192.0.2.128:9440/api/files/v4.0/config/file-servers
POST https://192.0.2.128:9440/api/files/v4.0/config/file-servers/<uuid>/mount-targets
Task completed with status: SUCCEEDED, progress: 100%
Setting cfg.volumePath with value: pvc-bc03c1b0-8456-4cda-a43c-3a5f70b446ea
ControllerPublishVolume called ... nfsServer:192.0.2.128 nfsServerName:files-lab provNFSShare:ENABLED

Três mensagens informativas que vale conhecer:

O ciclo de vida, visto do Files

Com o teste rodando, o volume aparece no console do Files como um share com o nome do PV:

Apaguei o namespace do teste. Com reclaimPolicy: Delete, o CSI removeu o share sozinho:

O export dos modelos do NAI

O NAI também pede um export NFSv4 à parte, para importar modelos custom ou baixados à mão. Criei o nai-modelos: Standard, NFS v3 e v4, Read-Write, squash None, sem limite de tamanho.

“Max Size 5 TiB” significa que o export pode usar o file server inteiro. O Mount Path aparece com o nome DNS; sem DNS interno, use o IP client.

Proteção: Protection Domain, Smart DR ou SSR

O console do file server oferece duas formas de proteção:

Ao configurar o Protection Domain, a tela indica que ele vale para file servers criados pelo Prism Element:

No lab, decidi não proteger o file server: os modelos podem ser baixados de novo, e os dados que importam do NAI (banco, métricas, cache) ficam em volumes RWO, no Nutanix Volumes. A proteção desses volumes é assunto para o NDK e o Velero.

Lab × Nutanix Validated Design

Os números

O que aprendi

1. O RWX do NKP vem do Nutanix Files. A storage class padrão é Nutanix Volumes (RWO); para o NAI, e para qualquer app com volume compartilhado, adicione o Files e uma storage class própria.
2. O CSI do NKP 2.19 roda em modo Prism Central. O Files dinâmico funciona nesse modo com um secret próprio que tenha key (PC) e files-key (usuário de REST API do file server).
3. Containerized Workload e Direct Attach são as opções certas para Kubernetes, e não mudam depois do deploy.
4. Habilite o NFSv4 antes de criar exports. O padrão de fábrica é só NFSv3.
5. Root squash e sudo não combinam no teste manual; decida o squash conscientemente na storage class.
6. Para Protection Domain, crie o file server pelo Prism Element. Pelo Prism Central, a proteção é o Smart DR.
7. Sem DNS interno, monte pelo IP. O Files redireciona o cliente para a FSVM certa.

Checklist: Nutanix Files para o NKP

• Licença NUS aplicada ao cluster (o NCI Ultimate traz 1 TiB)
• Memória para as FSVMs dentro do N+1 do cluster
• Sub-rede com IPAM e IPs livres (FSVMs na client; FSVMs + 1 na storage)
• DNS e NTP alcançáveis pela rede client
• Decidido: Prism Central ou Prism Element (proteção)
• Containerized Workload e Direct Attach ligados no assistente
• Tarefas pós-deploy concluídas antes do primeiro share
• NFSv4 habilitado
• Usuário de REST API criado (e salvo com o ✓)
• Secret próprio com key e files-key, sem tocar no secret do NKP
• Storage class RWX com Immediate
• Teste com 2 pods em nós diferentes e o share sumindo depois da limpeza
• Export separado para modelos custom (se for usar o NAI)

O que ainda não testei

• Nutanix Objects (S3), que o NVD usa no desenho: não instalei no lab e fica para depois (são ~104 GB de RAM).
• Proteção do file server com Smart DR, que pede um segundo file server. No lab, decidi não proteger o Files, porque os modelos podem ser baixados de novo.
• O tamanho de produção do NVD: FSVMs de 12 vCPU / 64 GB e rede client numa sub-rede separada. No lab, fiquei no mínimo suportado e numa VLAN só, como desvio consciente.

Referências

Nutanix

• Nutanix Validated Design: Nutanix Enterprise AI (NVD-2057)
• Nutanix CSI Operator: storage classes e secrets (opendocs.nutanix.com)
• Compatibilidade entre Files e AOS (Nutanix Community)
• Nutanix Enterprise AI Guide 2.8 (portal Nutanix), seção de requisitos e deploy no NKP

Projetos e comunidade

• Kubernetes: Persistent Volumes, access modes

Independentes

• Deploying Nutanix Enterprise AI on a non-Nutanix Kubernetes cluster (Jonas Hogman)