Use CPFS for Lingjun Statically Provisioned Volumes in ACK Clusters - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Escolha um método de montagem

Com base na Container Storage Interface (CSI), o ACK suporta a montagem de sistemas de arquivos CPFS for Lingjun como PVs e persistent volume claims (PVCs) provisionados estaticamente. O add-on CSI seleciona automaticamente o melhor método de montagem conforme o tipo de nó do pod:

Método de montagem	Nós suportados	Requisitos
Canal de armazenamento virtual (VSC)	Apenas nós Lingjun	Você deve enviar um ticket para as equipes de produto do CPFS e do Lingjun a fim de obter acesso à lista de permissões.
VPC	Nós não-Lingjun	Crie um ponto de montagem VPC na mesma VPC dos nós do cluster.

Antes de começar, identifique qual caminho se aplica ao seu cluster:

Pods executam em nós Lingjun: montagem VSC por padrão. Ignore a criação do ponto de montagem VPC.
Pods executam em nós não-Lingjun: montagem VPC obrigatória. Crie um ponto de montagem VPC na Etapa 1.
Pods executam em ambos os tipos de nó: defina vpcMountTarget e mountpointAutoSwitch: "true" no PV. O add-on CSI alterna automaticamente entre os métodos.

Pré-requisitos

Antes de iniciar, certifique-se de ter:

Revisado os limites do CPFS for Lingjun
Um cluster ACK rodando Kubernetes 1.26 ou superior. Atualize se necessário.
Nós rodando Alibaba Cloud Linux 3
Os seguintes add-ons de armazenamento nas versões exigidas (verifique e atualize na página Add-ons):
- Add-on CSI (csi-plugin e csi-provisioner): v1.33.1 ou superior (gerenciar add-ons CSI).
- cnfs-nas-daemon: 0.1.2 ou superior
  Configurar recursos do cnfs-nas-daemon
  O add-on cnfs-nas-daemon gerencia processos do Elastic File Client (EFC), consome recursos significativos e impacta diretamente a performance de armazenamento. Ajuste os recursos na página Add-ons:
  - CPU: Depende da largura de banda total do nó. Recomendação: 0,5 núcleo por 1 Gbps de largura de banda, mais 1 núcleo extra para gerenciamento de metadados.
    
    Exemplo: Para um nó de 100 Gbps, a requisição de CPU é 100 × 0.5 + 1 = 51 núcleos.
  - Memória: O CPFS for Lingjun usa Filesystem in USErspace (FUSE); portanto, caches de leitura/escrita e metadados consomem memória. Defina a requisição como 15% da memória total do nó.
  Ajuste conforme necessário com base na sua carga de trabalho.
  Importante
  
  Comportamento de atualização: O cnfs-nas-daemon usa uma estratégia de atualização OnDelete por padrão. Após ajustar CPU ou memória na página Add-ons, exclua manualmente os pods do cnfs-nas-daemon em cada nó para recriá-los com a nova configuração. Execute essa operação fora do horário de pico.
  
  Risco de interrupção: Excluir ou reiniciar o pod do cnfs-nas-daemon interrompe temporariamente o serviço de montagem do CPFS nesse nó.
  
  Para nós sem suporte a hot-upgrade^①: Interrupção severa que causa falha nos pods da aplicação. Exclua e reinicie manualmente os pods da aplicação para restaurar o serviço.
  
  Para nós com suporte a hot-upgrade^①: Os pods da aplicação se recuperam automaticamente após o reinício do cnfs-nas-daemon.
  
  ①: Um nó suporta hot-upgrades se atender a todas as condições abaixo:
  
  A versão do kernel do nó é 5.10.134-18 ou superior.
  
  bmcpfs-csi-controller e bmcpfs-csi-plugin estão na versão 1.35.1 ou superior.
  
  cnfs-nas-daemon está na versão 0.1.9-compatible.1 ou superior.
- bmcpfs-csi: inclui bmcpfs-csi-controller (add-on do plano de controle gerenciado pelo ACK) e bmcpfs-csi-node (DaemonSet no lado do nó)

Observações de uso

Zona de montagem VSC: O nó que executa o pod deve estar na mesma hpn-zone da instância do sistema de arquivos CPFS for Lingjun.
Inicialização do nó: Associe um nó Lingjun a um sistema de arquivos CPFS for Lingjun durante a inicialização. Caso contrário, a montagem via CSI falhará.
Drenagem de nós: Antes de descomissionar um nó Lingjun com falha, drene todos os pods dele. Ignorar esta etapa causa inconsistência nos metadados do cluster e deixa recursos de pods órfãos impossíveis de limpar.
Um PV por instância CPFS: Não há suporte para montar vários subdiretórios do mesmo sistema de arquivos CPFS como PVs separados em um único pod. Devido a limitações do driver, isso causa falha na inicialização do pod. Crie um único PV/PVC e use volumeMounts.subPath para montar subdiretórios. O subPath utiliza um bind mount leve, sem sobrecarga de performance.

Etapa 1: Criar um sistema de arquivos CPFS

Crie um sistema de arquivos CPFS for Lingjun e anote o ID do sistema de arquivos.
(Opcional) Para nós não-Lingjun, crie um ponto de montagem VPC na mesma VPC dos nós do seu cluster e anote o nome de domínio do ponto de montagem. Formato: cpfs--vpc-.<Região>.cpfs.aliyuncs.com.

Não necessário se os pods executarem em nós Lingjun (montagens VSC por padrão).

Etapa 2: Criar um PV e PVC

Salve o modelo a seguir como bmcpfs-pv-pvc.yaml, substituindo os placeholders pelo ID do seu sistema de arquivos e (se necessário) pelo ponto de montagem VPC.

Parâmetros do PV

Parâmetro	Descrição	Obrigatório
`accessModes`	Modo de acesso para o PV.	Sim
`capacity.storage`	Capacidade de armazenamento declarada. Não afeta a capacidade real.	Sim
`csi.driver`	Tipo de driver. Para CPFS for Lingjun, use `bmcpfsplugin.csi.alibabacloud.com`.	Sim
`csi.volumeHandle`	ID do sistema de arquivos CPFS for Lingjun.	Sim
`csi.volumeAttributes.vpcMountTarget`	Nome de domínio do ponto de montagem VPC. Obrigatório para nós não-Lingjun; omita se os pods forem agendados apenas em nós Lingjun.	Condicional
`csi.volumeAttributes.mountpointAutoSwitch`	Habilita a troca automática entre pontos de montagem VSC e VPC. Use junto com `vpcMountTarget`.	Não
`mountOptions`	Opções de montagem.	Não

Parâmetros do PVC

Parâmetro	Descrição	Obrigatório
`accessModes`	Modo de acesso solicitado pelo PVC. Deve corresponder ao do PV.	Sim
`resources.requests.storage`	Capacidade de armazenamento alocada ao pod. Não deve exceder a capacidade do PV.	Sim
`volumeMode`	Modo de montagem. Defina como `Filesystem`.	Sim
`volumeName`	Nome do PV a ser vinculado a este PVC.	Sim

apiVersion: v1
kind: PersistentVolume
metadata:
  name: bmcpfs
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Ti
  claimRef:
    name: bmcpfs
    namespace: default
  csi:
    driver: bmcpfsplugin.csi.alibabacloud.com
    volumeAttributes:
      # Required if pods schedule to non-Lingjun nodes or cross-zone automatic VPC switching is enabled.
      # Omit if pods schedule only to Lingjun nodes.
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
      # Enables automatic switching between VSC and VPC mount points.
      # Use together with vpcMountTarget.
      mountpointAutoSwitch: "true"
    # Replace with your CPFS for Lingjun file system ID.
    volumeHandle: bmcpfs-*****
  mountOptions: []

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bmcpfs
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Ti
  volumeMode: Filesystem
  volumeName: bmcpfs

Aplique a configuração.
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

Confirme se o PVC está vinculado ao PV.

kubectl get pvc bmcpfs

Saída esperada:

NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
bmcpfs   Bound    bmcpfs   10Ti       RWX                           <unset>                 51s

O STATUS como Bound confirma que o PVC está vinculado ao PV.

Etapa 3: Implantar uma carga de trabalho

Cenário 1: Montar todo o sistema de arquivos CPFS

Utilize esta abordagem quando todos os containers precisarem de acesso completo ao sistema de arquivos CPFS.

Salve o seguinte modelo YAML como cpfs-test.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpfs-test
  labels:
    app: cpfs-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cpfs-test
  template:
    metadata:
      labels:
        app: cpfs-test
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-cpfs
            mountPath: /data
      volumes:
        - name: pvc-cpfs
          persistentVolumeClaim:
            claimName: bmcpfs

Crie o Deployment.
```
kubectl create -f cpfs-test.yaml
```

Verifique se ambos os pods estão em execução.

kubectl get pod -l app=cpfs-test

Saída esperada:

NAME                         READY   STATUS    RESTARTS   AGE
cpfs-test-76b77d64b5-2hw96   1/1     Running   0          42s
cpfs-test-76b77d64b5-dnwdx   1/1     Running   0          42s

Verifique a montagem do volume CPFS dentro de um pod.

kubectl exec -it <pod-name> -- mount | grep /data

Saída esperada:

bindroot-f0a5c-******:cpfs-*******-vpc-****.cn-shanghai.cpfs.aliyuncs.com:/ on /data type fuse.aliyun-alinas-efc (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=1048576)

O tipo de montagem fuse.aliyun-alinas-efc em /data confirma que o volume CPFS está montado.

Cenário 2: Montar subdiretórios para isolamento de dados

Em cenários de armazenamento compartilhado, como configurações multilocatário ou multitarefa, vários containers podem compartilhar um volume CPFS enquanto isolam dados em diretórios separados. Use volumeMounts.subPath para montar subdiretórios diferentes em containers diferentes a partir do mesmo PVC.

Se um diretório subPath (por exemplo, workspace/alpha ) não existir, ele será criado automaticamente.

Salve o seguinte modelo YAML como pod.yaml. Este pod executa dois containers, cada um montando um subdiretório diferente do mesmo PVC (bmcpfs).

apiVersion: v1
kind: Pod
metadata:
  name: cpfs-subpath-demo-pod
spec:
  containers:
    - name: task-alpha-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace        # Mount path inside the container
          subPath: workspace/alpha          # Mount the workspace/alpha subdirectory only

    - name: task-beta-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace        # Mount paths can be identical across containers
          subPath: workspace/beta           # Mount the workspace/beta subdirectory only
  volumes:
    - name: cpfs-storage
      persistentVolumeClaim:
        claimName: bmcpfs                  # Reference the PVC created earlier

Implante o pod.
```
kubectl apply -f pod.yaml
```
Verifique a montagem e as permissões de escrita do task-alpha-container.
1. Conecte-se ao container.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh
```
2. Confirme se o volume CPFS está montado.
```
df -h
```
  Saída esperada (diretório compartilhado montado em /data/workspace):
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
  A entrada do sistema de arquivos em /data/workspace confirma que o subdiretório CPFS está montado.
3. Verifique a estrutura do diretório pai.
```
ls -l /data/
```
  Saída esperada:
```
total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace
```
4. Escreva um arquivo de teste e saia.
```
echo "hello from alpha" > /data/workspace/alpha.log
exit
```
Verifique a montagem e o isolamento de dados do task-beta-container.
1. Conecte-se ao container.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
2. Escreva um arquivo de teste.
```
echo "hello from beta" > /data/workspace/beta.log
```
3. Liste os arquivos no ponto de montagem.
```
ls -l /data/workspace/
```
  Saída esperada:
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```
  O arquivo beta.log está presente, mas o alpha.log está ausente, confirmando o isolamento de dados entre os containers.