Incluindo o File Storage for VPC em apps

Red Hat OpenShift on IBM Cloud oferece classes de armazenamento predefinidas que você pode usar para provisionar o serviço “ File Storage for VPC ” para os aplicativos em seu cluster. Cada classe de armazenamento especifica o tamanho disponível, o IOPS, o sistema de arquivos e a política de retenção para o compartilhamento de arquivos que você provisionar. Você também pode criar suas próprias classes de armazenamento para o seu caso de uso.

Revise as observações e considerações a seguir antes de continuar.

Depois de provisionar um tipo específico de armazenamento usando uma classe de armazenamento, você não poderá mudar o tipo ou a política retenção para o dispositivo de armazenamento. No entanto, será possível mudar o tamanho e o IOPS se você desejar aumentar sua capacidade de armazenamento e desempenho. Para alterar o tipo e a política de retenção do seu armazenamento, é necessário criar uma nova instância de armazenamento e copiar os dados da instância antiga para a nova.
Se o seu cluster e a VPC estiverem em grupos de recursos separados, antes de poder provisionar compartilhamentos de arquivos, você deverá criar sua própria classe de armazenamento e fornecer o ID do grupo de recursos da VPC na seção resourceGroup juntamente com o ID do grupo de segurança kube-<clusterID> na seção securityGroupIDs. Para recuperar o ID do grupo de segurança, faça o seguinte. Para obter mais informações, consulte Criando sua própria classe de armazenamento.
Novas regras de grupo de segurança foram introduzidas em versões de cluster 4.11 e depois. Essas alterações de regras significam que você deve sincronizar seus grupos de segurança antes de poder usarFile Storage for VPC. Para mais informações, veja AdicionandoFile Storage for VPC para aplicativos.
Novas classes de armazenamento foram adicionadas com a versão2.0 do complemento. Você não pode mais provisionar novos compartilhamentos de arquivos que usam classes de armazenamento mais antigas. Os volumes existentes que usam as classes de armazenamento mais antigas continuam a funcionar, mas não é possível expandir os volumes que foram criados usando as classes mais antigas. Para obter mais informações, consulte o Migrando para uma nova classe de armazenamento.
A criação de um PVC usando StorageClassSecrets não é compatível.
Certifique-se de que o usuário que cria o cluster tenha as permissões Reader, Writer e Operator para o VPC Infrastructure Services.
Certifique-se de configurar uma autorização de serviço da Infraestrutura VPC para o KMS/HPCS se estiver planejando usar criptografia nos compartilhamentos de arquivos.

A IBM Cloud está mudando os serviços dedicados de gerenciamento de chave de Hyper Protect Crypto Services para Key Protect Dedicated.

Por padrão, File Storage for VPC provisionam compartilhamentos de arquivo de provisões do cluster no grupo de segurança kube-<clusterID>. Isso significa que os pods podem acessar compartilhamentos de arquivos entre nós e zonas.
Se estiver usando restrições baseadas em contexto, certifique-se de configurar suas zonas e regras de rede. Para obter mais informações, consulte Proteção dos serviços de infraestrutura da nuvem privada virtual(VPC)com restrições baseadas em contexto.

Novas regras de grupo de segurança foram introduzidas nas versões 4.11 e posteriores. Essas alterações nas regras significam que você deve sincronizar seus grupos de segurança antes de poder usar o File Storage for VPC. Se o seu cluster foi criado inicialmente na versão 4.11 ou anterior, execute os seguintes comandos para sincronizar as configurações do seu grupo de segurança.

Obtenha o ID do seu cluster.
```
ibmcloud oc cluster ls
```
Obtenha o ID do grupo de segurança kube-<clusterID>.
```
ibmcloud is sg kube-CLUSTER_ID  | grep ID
```
Sincronize o grupo de segurança kube-<clusterID> usando a ID que você recuperou na etapa anterior.
```
ibmcloud ks security-group sync -c CLUSTER_ID --security-group ID
```

Guia de início rápido para File Storage for VPC

Crie uma reivindicação de volume persistente (PVC) para provisionar dinamicamente um File Storage for VPC e para o seu cluster. O provisionamento dinâmico cria automaticamente o volume persistente (PV) correspondente e solicita o compartilhamento de arquivos em sua conta.

Agora disponível, você pode escolher uma classe de armazenamento de segunda geração.

Acesse o seu Red Hat OpenShift cluster.
Revise as classes de armazenamento pré-instaladas, executando o comando a seguir: Para obter mais informações, consulte a referência de classe de armazenamento.
```
oc get sc | grep vpc-file
```

Salve o YAML a seguir em um arquivo. Este exemplo cria uma solicitação denominada my-pvc usando a classe de armazenamento ibmc-vpc-file-min-iops com um tamanho de gigabyte de 10Gi.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc # Enter a name for your PVC.
spec:
  accessModes:
  - ReadWriteMany # The file share can be mounted on multiple nodes and pods.
  resources:
    requests:
      storage: 20Gi # Enter the size of the storage in gigabytes (Gi).
  storageClassName: ibmc-vpc-file-min-iops # Enter the name of the storage class that you want to use.

Crie o PVC.
```
oc apply -f my-pvc.yaml
```

Verifique se o PVC foi criado e ligado ao PV.

oc describe pvc my-pvc

Saída de exemplo

Name:        my-pvc
Namespace:    default
StorageClass:    ""
Status:        Bound
Volume:        pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
Labels:        <none>
Capacity:    20Gi
Access Modes:    RWX
Events:
    FirstSeen    LastSeen    Count    From                                SubObjectPath    Type        Reason            Message
    ---------    --------    -----    ----                                -------------    --------    ------            -------
    1m        1m        1    {ibm.io/ibmc-vpc-file 31898035-3011-11e7-a6a4-7a08779efd33 }            Normal        ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2

Salve a configuração de implementação a seguir no arquivo chamado deployment.yaml e referencie o PVC criado na etapa anterior.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: my-deployment
spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox:1.28
        command: [ "sh", "-c", "sleep 1h" ]
        volumeMounts:
        - name: my-vol
          mountPath: /data/demo # Mount path for the application.
      volumes:
      - name: my-vol
        persistentVolumeClaim:
          claimName: my-pvc # Your PVC name.
```
volumeMounts.mountPath

Na seção de montagens de volume do contêiner, insira o caminho absoluto do diretório para onde o volume é montado dentro do contêiner. Os dados que são gravados no caminho de montagem são armazenados sob o diretório root em sua instância física File Storage for VPC. Para compartilhar um volume entre diferentes apps, é possível especificar subcaminhos de volume para cada um dos apps.

volumeMounts.name

Na seção de montagens de volume de contêineres, insira o nome do volume para montar em seu pod.

volume.name

Na seção volumes, insira o nome do volume para montar em seu pod. Geralmente, esse nome é igual a volumeMounts.name.

claimName

Na seção de solicitação de volume persistente de volumes, insira o nome da PVC que liga o PV que você deseja usar.
Crie a implementação.
```
oc apply -f deployment.yaml
```

Verifique se o PV foi montado com êxito.

oc describe deployment my-deployment

O ponto de montagem está no campo Montagens de volume e o volume está no campo Volumes.

Containers:
  Mounts:
    /data/demo from my-vol (rw)
Volumes:
my-vol:
  Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
  ClaimName:  my-pvc
  ReadOnly:   false

Opcional: após o pod estar em execução, tente expandir seu volume de armazenamento.

Migrando para uma nova classe de armazenamento

Novas classes de armazenamento foram adicionadas com a versão2.0 do complemento.
Você não pode mais provisionar novos compartilhamentos de arquivos que usam classes de armazenamento mais antigas.
Os volumes existentes que usam as classes de armazenamento mais antigas continuam a funcionar, mas não é possível expandir os volumes que foram criados usando as classes mais antigas.
Se precisar do recurso de expansão de volume, conclua as etapas a seguir para migrar seus aplicativos para uma classe de armazenamento mais recente.
Se não precisar do recurso de expansão de volume, não será necessário migrar e seus PVCs continuarão funcionando normalmente.
As etapas a seguir abrangem a migração manual.

Encontre o PVC que deseja migrar e anote o nome do PVC e o nome do PV associado.
```
oc get pvc
```
Reduza a escala do seu aplicativo que usa o PVC.
```
oc scale deployment DEPLOYMENT --replicas 0
```

Edite o objeto PV que seu aplicativo está usando para alterar a política de recuperação para Retain e classe de armazenamento para ibmc-vpc-file-min-iops.

kubectl edit pv PV

spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 20Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: <pvc-name>
    namespace: default
    ...
  persistentVolumeReclaimPolicy: Retain # Change delete to retain
  storageClassName: ibmc-vpc-file-min-iops # Enter a new storage class
  volumeMode: Filesystem

Exclua o objeto PVC existente.
```
kubectl delete pvc PVC
```

Edite o PV novamente e remova o claimRef seção.

kubectl edit pv PV

spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 20Gi
  #claimRef:
    #apiVersion: v1
    #kind: PersistentVolumeClaim
    #name: <pvc-name>
    #namespace: default
    #resourceVersion: "381270"
    #uid: 4042f319-1233-4187-8549-8249a840a8dd

Crie um PVC que tenha o mesmo nome e tamanho do PVC anterior. Isto deve ser feito um por um para todos os PVCs afetados.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <pvc-name>
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: <size>Gi
  storageClassName: ibmc-vpc-file-min-iops

Amplie seu aplicativo que estava usando o PVC.
```
k scale deployment DEPLOYMENT --replicas x
```
Para continuar usando a expansão de volume, consulte Configurando expansão de volume.

Configurando a expansão de volume

Para fornecer volumes que suportem expansão, deve-se utilizar uma classe de armazenamento que tenha allowVolumeExpansion configurado como true.

O complemento de cluster File Storage for VPC suporta expansão nos modos online e offline. No entanto, a expansão só é possível dentro do tamanho e da faixa de IOPs especificados no perfil File Storage for VPC.

Novas classes de armazenamento foram introduzidas com a versão 2.0. A expansão de volume não funciona para compartilhamentos que usam classes de armazenamento de versões anteriores do complemento.

Antes de Iniciar

Para usar a expansão de volume, certifique-se de atualizar seu add-on para, no mínimo, a versão 2.0.
Certifique-se de que seu aplicativo esteja usando uma das classes de armazenamento mais recentes. Para conhecer as etapas de migração, consulte Migrando para uma nova classe de armazenamento
Se você não tiver um aplicativo em execução, comece implantando o exemplo de início rápido PVC e implantação.

Expandindo um volume montado

Depois que sua PVC for montada por um pod do app, será possível expandir seu volume editando o valor do campo spec.resources.requests.storage na PVC. Para expandir o seu volume, edite a sua PVC e aumente o valor no campo spec.resources.requests.storage.
```
kubectl edit pvc my-pvc
```
```
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
```
Salve e feche a PVC. Aguarde alguns minutos para que o volume seja expandido

Verifique se o seu volume está desdobrado.

kubectl get pvc

Saída de exemplo

NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
my-pvc   Bound    pvc-25b6912e-75bf-41ca-b6b2-567fa4f9d245   50Gi       RWX            ibmc-vpc-file-min-iops   3m31s

Anexando o armazenamento de arquivo existente a um app

Crie uma reivindicação de volume persistente (PVC) para provisionar estaticamente um File Storage for VPC e para o seu cluster. O fornecimento estático permite que os administradores de cluster tornem dispositivos de armazenamento existentes disponíveis para um cluster.

Obtenha o ID do cluster.
```
ibmcloud ks cluster ls
```
Obtenha o ID de seu grupo de segurança kube-<clusterID>.
```
ibmcloud is sg kube-CLUSTER_ID  | grep ID
```
Criar um compartilhamento de arquivos. Para obter mais informações, consulte Criando compartilhamentos de arquivo e destinos de montagem.
```
ibmcloud is share-create --name my-file-share --zone us-south-2 --profile dp2 --size 1000 --iops 1000
```

Crie um destino de montagem de compartilhamento e especifique o ID do grupo de segurança kube-<clusterID> que você recuperou anteriormente na opção --vni-sgs.

ibmcloud is share-mount-target-create my-file-share --subnet my-subnet --name NAME --vni-name my-share-vni-1  --vni-sgs kube-CLUSTER_ID --resource-group-name Default --vpc ID

Antes de criar um volume persistente (PV), recupere os detalhes sobre seu compartilhamento de arquivo.
```
ibmcloud is shares
```

Veja os detalhes da sua ação. Anote os destinos de montagem.

ibmcloud is share SHARE-ID

Comando de exemplo

ibmcloud is share r134-bad98878-1f63-45d2-a3fd-60447094c2e6

Saída de exemplo

ID                           r134-bad98878-1f63-45d2-a3fd-60447094c2e6   
Name                         pvc-e7e005a9-e96b-41ad-9d6e-74650a9110a0   
CRN                          crn:v1:staging:public:is:us-south-1:a/77f2bceddaeb577dcaddb4073fe82c1c::share:r134-bad98878-1f63-45d2-a3fd-60447094c2e6   
Lifecycle state              stable   
Access control mode          security_group   
Zone                         us-south-1   
Profile                      dp2   
Size(GB)                     10   
IOPS                         100   
User Tags                    clusterid:cpjao3l20dl78jadqkd0,namespace:default,provisioner:vpc.file.csi.ibm.io,pv:pvc-e7e005a9-e96b-41ad-9d6e-74650a9110a0,pvc:pv-file,reclaimpolicy:delete,storageclass:custom-eni   
Encryption                   provider_managed   
Mount Targets                ID                                          Name      
                            r134-aa2aabb8-f616-47be-886b-99220852b728   pvc-e7e005a9-e96b-41ad-9d6e-74650a9110a0      
Resource group               ID                                 Name      
                            300b9469ee8676f9a038ecdf408c1a9d   Default      
Created                      2024-06-11T19:55:11+05:30   
Replication role             none   
Replication status           none   
Replication status reasons   Status code   Status message

Obtenha o nfsServerPath, também chamado de Mount Path

ibmcloud is share-mount-target SHARE-ID SHARE-TARGET-ID

Comando de exemplo

ibmcloud is share-mount-target  r134-bad98878-1f63-45d2-a3fd-60447094c2e6 r134-aa2aabb8-f616-47be-886b-99220852b728

Saída de exemplo

ID                          r134-aa2aabb8-f616-47be-886b-99220852b728   
Name                        pvc-e7e005a9-e96b-41ad-9d6e-74650a9110a0   
VPC                         ID                                          Name      
                            r134-f05922d4-d8ab-4f64-9a3d-82664b303bc1   vpc-public      
Access control mode         security_group   
Resource type               share_mount_target   
Virtual network interface   ID                                          Name      
                            0716-6407fb4b-e962-49c4-8556-dc94f4574b4b   defective-chloride-huffy-gladly      
Lifecycle state             stable   
Mount path                  10.240.0.23:/89d8a454_f552_42bf_8374_4d31481edf4d   
Transit Encryption          none   
Created                     2024-06-11T19:55:12+05:30

Crie um arquivo de configuração PV chamado static-file-share.yaml que faça referência ao compartilhamento de arquivo.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: static-file-share
spec:
  mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Gi
  csi:
    volumeAttributes:
      nfsServerPath: NFS-SERVER-PATH
    driver: vpc.file.csi.ibm.io
    volumeHandle: FILE-SHARE-ID#SHARE-TARGET-ID

Crie o PV.
```
oc apply -f static-file-share.yaml
```

Crie um PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-static
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: "" #Leave the storage class blank.

Crie o PVC para ligar o seu PV
```
oc apply -f pvc-static.yaml
```
Crie um nome de arquivo de implantação testpod.yaml para anexar seu compartilhamento de arquivos a um pod de aplicativo.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: testpod
  labels:
    app: testpod
spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox:1.28
        command: [ "sh", "-c", "sleep 1h" ]
        volumeMounts:
        - name: my-vol
          mountPath: /data/demo # Mount path for the application.
      volumes:
      - name: pvc-name
        persistentVolumeClaim:
          claimName: pvc-static # The name of the PVC that you created earlier
```
spec.containers.volumeMounts.mountPath

Insira o caminho absoluto do diretório no qual o volume está montado dentro do contêiner. Os dados que são gravados no caminho de montagem são armazenados sob o diretório root em sua instância física File Storage for VPC. Para compartilhar um volume entre diferentes apps, é possível especificar subcaminhos de volume para cada um dos apps.

volumeMounts.name

Insira o nome do volume a ser montado no pod.

volume.name

Insira o nome do volume a ser montado no pod. Geralmente, esse nome é igual a volumeMounts.name.

volumes.persistentVolumeClaim.claimName

Digite o nome do PVC associado ao PV que você deseja utilizar.
Crie a implementação.
```
oc apply -f testpod.yaml
```

Criando sua própria classe de armazenamento

Você pode criar sua própria classe de armazenamento personalizada com as configurações de sua preferência para sua instância do File Storage for VPC. Para manter os custos baixos, é possível provisionar inicialmente um PVC com taxa de transferência mínima e, posteriormente, acessar o PVC e ajustar a taxa de transferência conforme as necessidades forem melhor definidas.

Se você precisar dos recursos a seguir, deverá criar sua própria classe de armazenamento.

O seu app precisa ser executado como não raiz
Seu cluster está em um grupo de recursos diferente do seu VPC e da sub-rede
É necessário limitar o acesso de compartilhamento de arquivo a pods em um determinado nó ou em uma determinada zona..
É necessário trazer sua própria criptografia (BYOK) usando um provedor KMS, como HPCS ou Key Protect.
É necessário especificar manualmente a sub-rede ou o endereço IP da Virtual Network Interface(VNI).
Você precisa de mais controle sobre a capacidade e a largura de banda. Nesse caso, você pode usar o perfil rfs. Para obter mais informações, consulte Visão geral dos compartilhamentos de arquivos regionais.
Você deseja arredondar automaticamente para cima a capacidade de PVC solicitada até a capacidade mínima suportada para um perfil de dp2 com IOPS fixas. Para obter mais informações, consulte “Ativando o arredondamento automático de capacidade para perfis de IOPS fixos ”.

Se o cluster e a VPC não estiverem no mesmo grupo de recursos, será necessário especificar o ID do grupo de recursos da VPC na seção resourceGroup e o ID do grupo de segurança kube-<clusterID> na seção securityGroupIDs. Você pode encontrar o ID do grupo de segurança kube-<clusterID> executando ibmcloud is sg kube-CLUSTER_ID | grep ID.

Crie um arquivo de configuração da classe de armazenamento. O exemplo a seguir usa o perfil dp2. Escolha entre uma classe de armazenamento de primeira geração e uma de segunda geração.

Exemplo de primeira geração:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-vpc-file-custom-sc
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
provisioner: vpc.file.csi.ibm.io
mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
parameters:
    profile: "dp2" # or rfs
    billingType: "hourly" # hourly or monthly
    encrypted: "false"
    encryptionKey: "" # If encrypted is true, then a user must specify the CRK-CRN.
    resourceGroup: "" # Resource group ID. By default, the resource group of the cluster will be used from storage-secrete-store secret.
    isENIEnabled: "true" # VPC File Share VNI feature will be used by all PVCs created with this storage class.
    securityGroupIDs: "" # By default cluster security group i.e kube-<clusterID> will be used. User can provide their own comma separated SGs.
    subnetID: "" # User can provide subnetID in which the VNI will be created. Zone and region are mandatory for this. If not provided CSI driver will use the subnetID available in the cluster's VPC zone.
    region: "" # VPC CSI driver will select a region from cluster node's topology. The user can override this default.
    zone: "" # VPC CSI driver will select a region from cluster node's topology. The user can override this default.
    primaryIPID: "" # Existing ID of reserved IP from the same subnet as the file share zone. Zone and region are mandatory for this. SubnetID is not mandatory for this.
    primaryIPAddress: "" # IPAddress for VNI to be created in the subnet of the zone. Zone, region and subnetID are mandatory for this.
    iops: "" # Example: 100, this option is valid only for the dp2 profile.
    allowCapacityRoundoffForIops: "true" # Optional. Enables automatic capacity roundoff for fixed IOPS dp2 profiles. When set to "true", if the requested PVC size is lower than the minimum supported capacity for the requested IOPS, the driver automatically provisions the volume at the minimum supported capacity. Disabled by default. Requires a Virtual Private Endpoint Gateway (VPEG) to IBM Global Catalog.
    throughput: "" # Example: 2000, this option is valid only for the rfs profile
    tags: "" # User can add a list of tags "a, b, c" that will be used at the time of provisioning file share, by default CSI driver has its own tags.
    uid: "0" # The initial user identifier for the file share, by default its root.
    gid: "0" # The initial group identifier for the file share, by default its root.
    classVersion: "1"
reclaimPolicy: "Delete"
allowVolumeExpansion: true

Exemplo de segunda geração:

Se você provisionar um PVC 10Gi usando a classe de armazenamento ibmc-vpc-file-min-iops de primeira geração, o IOPS máximo será de 1.000. A alocação padrão é 100 e a taxa de transferência é fixada em 210 Mbps, que não pode ser ajustada.

No entanto, se você provisionar um PVC 10Gi usando a classe de armazenamento ibmc-vpc-file-regional de segunda geração, o IOPS será fixado em 35.000 e a taxa de transferência máxima poderá ser ajustada para até 8192 Mbps, embora o padrão seja 8 Mbps.

Por outro exemplo, se você provisionar inicialmente um PVC com tamanho inferior a 16 TB e IOPS 500 fixo usando a classe de armazenamento ibmc-vpc-file-500-iops de primeira geração, o IOPS e a taxa de transferência serão fixos e calculados com base no tamanho e no IOPS.

Para expandir esse PVC além de 16 TB, a classe de armazenamento ibmc-vpc-file-500-iops de primeira geração não funcionará. Ao usar a classe de armazenamento ibmc-vpc-file-regional-max-bandwidth de segunda geração, um PVC de qualquer tamanho pode ser provisionado até 32 TB e tem até 35.000 IOPS e uma taxa de transferência padrão de 8192 Mbps, que pode ser ajustada.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-vpc-file-regional-max-bandwidth
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
  annotations:
    version: v2.0
    revision: "1"
provisioner: vpc.file.csi.ibm.io
mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
parameters:
  profile: "rfs" # general-purpose, sdp, 5iops-tier, 10iops-tier, or custom
  billingType: "hourly"
  encrypted: "false"
  encryptionKey: ""
  resourceGroup: ""
  throughput: "8192" # Example: 2000
  classVersion: "1"
  isENIEnabled: "true"   # VPC File Share ENI/VNI feature will be used by all PVCs created with this storage class.
  securityGroupIDs: ""   # By default cluster security group i.e kube-<clusterID> will be used. User can provide their own command separated SGs.
  subnetID: ""         # User can provide subnetID in which the ENI/VNI will be created.If not provided CSI driver will use the subnetID available in the cluster' VPC zone.
  primaryIPID: ""      # Existing ID of reserved IP from any of subnets within the VPC,subnetID is not mandatory for this.
  primaryIPAddress: "" # IPAddress for ENI/VNI to be created in the respective subnet,subnetID is mandatory for this.
  uid: "0"             # The initial user identifier for the file share, by default its root.
  gid: "0"             # The initial group identifier for the file share, by default its root.
allowVolumeExpansion: true # Select true or false. Only supported on version 3.0.1 and later
reclaimPolicy: "Delete"

Crie a classe de armazenamento customizada no cluster.
```
oc apply -f custom-storageclass.yaml
```
Verifique se a classe de armazenamento está disponível no cluster.
```
oc get sc
```
Saída de exemplo
```
ibmc-vpc-file-custom-sc                       vpc.file.csi.ibm.io
```

Definindo a classe de armazenamento padrão

A alteração da classe de armazenamento padrão só está disponível para a versão do add-on 2.0 ou posterior.
Você pode definir a classe de armazenamento padrão como uma das classes File Storage for VPC pré-instaladas ou como sua própria classe de armazenamento personalizada. Se estiver usando uma classe de armazenamento personalizada, certifique-se de que o provisionador esteja definido como vpc.file.csi.ibm.io.
Se várias classes de armazenamento forem definidas como padrão em um cluster, qualquer uma das classes de armazenamento padrão poderá ser usada. Como prática recomendada, e para garantir que a classe de armazenamento correta seja usada, remova todas as classes de armazenamento padrão existentes no cluster antes de definir uma nova classe padrão. Se o complemento de armazenamento em bloco do VPC também estiver instalado, é possível que uma classe de armazenamento em bloco do VPC já esteja definida como padrão. Para removê-la antes de definir um novo padrão, consulte “Alteração da classe de armazenamento padrão para o armazenamento em bloco da VPC ”.

Edite o configmap addon-vpc-file-csi-driver-configmap e especifique o nome da classe de armazenamento no parâmetro SET_DEFAULT_STORAGE_CLASS.
```
oc edit cm addon-vpc-file-csi-driver-configmap -n kube-system
```
Saída de exemplo
```
SET_DEFAULT_STORAGE_CLASS: "ibmc-vpc-file-eit"
```

Verifique se o padrão está definido corretamente descrevendo o file-csi-driver-status configmap.

oc describe cm file-csi-driver-status -n kube-system

Exemplo de saída.

events:
----
- event: EnableVPCFileCSIDriver
  description: 'VPC File CSI Driver enable successful, DriverVersion: v2.0.6'
  timestamp: "2024-09-20 12:01:02"
- event: Change default storage class request
  description: Successfully set 'ibmc-vpc-file-eit' as default storage class
  timestamp: "2024-09-20 12:01:36"

Implementando um app executado como não raiz

Os parâmetros uid e gid na classe de armazenamento definem os identificadores iniciais de usuário e grupo para o compartilhamento de arquivos no nível da infraestrutura. Para obter informações básicas sobre como os IDs suplementares funcionam no armazenamento de arquivos do VPC, consulte “IDs suplementares para compartilhamentos de arquivos do VPC ”.

Crie sua própria classe de armazenamento e especifique o ID do grupo ou o ID do usuário que você deseja usar para seu app.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-vpc-file-custom-sc
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
provisioner: vpc.file.csi.ibm.io
mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
parameters:
    profile: "dp2"
    iops: "100"
    billingType: "hourly" # hourly or monthly
    encrypted: "false"
    uid: "3000" # The initial user identifier for the file share.
    gid: "1000" # The initial group identifier for the file share.
    classVersion: "1"
reclaimPolicy: "Delete"
allowVolumeExpansion: true

Salve o YAML a seguir em um arquivo chamado my-pvc.yaml.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ibmc-vpc-file-custom-sc

Crie o PVC.
```
oc apply -f my-pvc.yaml
```

Crie um pod que monte o PVC..

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 3000
    runAsGroup: 1000
  volumes:
  - name: sec-ctx-vol
    persistentVolumeClaim:
        claimName: my-pvc
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

Verifique se o pod está em execução.
```
oc get pods
```

Configuração da criptografia KMS para File Storage for VPC

Utilize um provedor de serviço de gerenciamento de chaves (KMS), como IBM® Key Protect ou Hyper Protect Crypto Services, para criar uma chave raiz privada que você usará em sua instância do File Storage for VPC para criptografar os dados à medida que forem gravados no armazenamento. Depois de criar a chave raiz privada, crie sua própria classe de armazenamento ou um segredo do serviço de armazenamento em nuvem ( Kubernetes ) com sua chave raiz e, em seguida, use essa classe de armazenamento ou esse segredo para provisionar sua instância do serviço de armazenamento em nuvem ( File Storage for VPC ).

Crie uma instância do provedor KMS que você deseja usar.
- Key Protect.
- Hyper Protect Crypto Services.
Crie uma chave raiz na sua instância do KMS.
- Chave raiz do Key Protect.
- Chave raiz do Hyper Protect Crypto Services. Por padrão, a chave raiz é criada sem uma data de expiração.
Conclua os pré-requisitos para a criptografia gerenciada pelo cliente e autorize o File Storage for VPC a acessar IBM® Key Protect. Certifique-se de dar File Storage for VPC pelo menos Reader acesso à sua instância KMS.

Crie uma classe de armazenamento personalizada e especifique os detalhes do KMS.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: custom-sc-encrypted
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
provisioner: vpc.file.csi.ibm.io
mountOptions:
  - hard
  - nfsvers=4.1
  - sec=sys
parameters:
    profile: "dp2"
    billingType: "hourly" # hourly or monthly
    encrypted: "true"
    encryptionKey: "" # Specify the root key CRN.
    resourceGroup: "" # Resource group ID. By default, the resource group of the cluster will be used from storage-secrete-store secret.
    isENIEnabled: "true" # VPC File Share VNI feature will be used by all PVCs created with this storage class.
    securityGroupIDs: "" # By default cluster security group i.e kube-<clusterID> will be used. User can provide their own comma separated SGs.
    subnetID: "" # User can provide subnetID in which the VNI will be created. Zone and region are mandatory for this. If not provided CSI driver will use the subnetID available in the cluster's VPC zone.
    region: "" # VPC CSI driver will select a region from cluster node's topology. The user can override this default.
    zone: "" # VPC CSI driver will select a region from cluster node's topology. The user can override this default.
    primaryIPID: "" # Existing ID of reserved IP from the same subnet as the file share zone. Zone and region are mandatory for this. SubnetID is not mandatory for this.
    primaryIPAddress: "" # IPAddress for VNI to be created in the subnet of the zone. Zone, region and subnetID are mandatory for this.
    tags: "" # User can add a list of tags "a, b, c" that will be used at the time of provisioning file share, by default CSI driver has its own tags.
    uid: "0" # The initial user identifier for the file share, by default its root.
    gid: "0" # The initial group identifier for the file share, by default its root.
    classVersion: "1"
reclaimPolicy: "Delete"
allowVolumeExpansion: true

Crie a classe de armazenamento.
```
oc apply -f encrypted-class.yaml
```

Salve o YAML a seguir em um arquivo chamado my-pvc.yaml.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: custom-sc-encrypted

Crie o PVC.
```
oc apply -f my-pvc.yaml
```
Salve a configuração de implementação a seguir no arquivo chamado deployment.yaml e referencie o PVC criado na etapa anterior.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: my-deployment
spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox:1.28
        command: [ "sh", "-c", "sleep 1h" ]
        volumeMounts:
        - name: my-vol
          mountPath: /data/demo # Mount path for the application.
      volumes:
      - name: my-vol
        persistentVolumeClaim:
          claimName: my-pvc # Your PVC name.
```
volumeMounts.mountPath

Na seção de montagens de volume do contêiner, insira o caminho absoluto do diretório para onde o volume é montado dentro do contêiner. Os dados que são gravados no caminho de montagem são armazenados sob o diretório root em sua instância física File Storage for VPC. Para compartilhar um volume entre diferentes apps, é possível especificar subcaminhos de volume para cada um dos apps.

volumeMounts.name

Na seção de montagens de volume de contêineres, insira o nome do volume para montar em seu pod.

volume.name

Na seção volumes, insira o nome do volume para montar em seu pod. Geralmente, esse nome é igual a volumeMounts.name.
Crie a implementação.
```
oc apply -f deployment.yaml
```

Configurando criptografia em trânsito (EIT)

Para configurar a criptografia em trânsito para File Storage for VPC, consulte “Criptografia em trânsito para IBM Cloud File Storage for VPC ”. Esse tópico abrange tanto os compartilhamentos de arquivos zonais (perfil dp2 ) quanto os compartilhamentos de arquivos regionais (perfil rfs, Beta).

Atualização das solicitações e limites de recursos dos contêineres

É possível personalizar as solicitações e os limites de recursos de CPU e memória para os contêineres executados no complemento “ File Storage for VPC ”. Ajustar esses valores pode ajudar a otimizar o desempenho em grandes clusters ou em ambientes com restrições de recursos.

Os parâmetros seguem o padrão de nomenclatura <ContainerName>CPULimit, <ContainerName>CPURequest, <ContainerName>MemoryLimit e <ContainerName>MemoryRequest. Aplique-as aos contêineres do controlador e do servidor de nós.

Edite o configmap addon-vpc-file-csi-driver-configmap e adicione os parâmetros de recurso para os contêineres que você deseja ajustar. O exemplo a seguir define os valores de CPU e memória para os contêineres do controlador e do servidor de nós.

oc edit cm addon-vpc-file-csi-driver-configmap -n kube-system

Valores de exemplo:

controllerCPULimit: "200m"
controllerCPURequest: "100m"
controllerMemoryLimit: "256Mi"
controllerMemoryRequest: "128Mi"
nodeServerCPULimit: "200m"
nodeServerCPURequest: "100m"
nodeServerMemoryLimit: "256Mi"
nodeServerMemoryRequest: "128Mi"

Verifique se as alterações no recurso foram aplicadas com sucesso, consultando o configmap file-csi-driver-status. Procure por um evento “ Successfully set container resources ” na seção “ events ”.
```
oc describe cm file-csi-driver-status -n kube-system
```
Saída de exemplo:
```
events:
----
- description: Successfully set container resources
  event: Change container resources
  timestamp: "2026-06-26 08:32:05"
```

Limitando o acesso de compartilhamento de arquivo por conjunto de trabalhadores, zona ou nó do trabalhador

O comportamento padrão para o complemento do cluster File Storage for VPC é que os pods em qualquer nó podem acessar compartilhamentos de arquivos. Também é possível aplicar um controle mais granular sobre como os pods acessam seus compartilhamentos de arquivo Por exemplo, é possível limitar o acesso de compartilhamento de arquivo a apenas pods em um nó específico, em uma zona específica, em um conjunto de trabalhadores específico Revise os cenários a seguir para saber como é possível configurar o acesso de pod para seus compartilhamentos de arquivo

Quando um PVC é criado, ele cria um destino de compartilhamento de arquivos por PVC e um IP VNI é reservado nessa sub-rede na zona. Isso significa que o número máximo de PVCs para armazenamento de arquivo VPC depende dos endereços IP disponíveis nessa sub-rede.

Se você usar os recursos do VNI a seguir para limitar o acesso do pod aos compartilhamentos de arquivo, seu app poderá não ser altamente disponível

Antes de Iniciar

Para limitar o acesso de compartilhamento de arquivo por nó, zona ou grupo de recursos, deve-se primeiro criar um grupo de segurança de VPC customizado

Liste seus clusters e anote o ID do cluster no qual você deseja implementar o armazenamento de arquivo.
```
ibmcloud ks cluster ls
```
Obtenha os detalhes de seu pool de funcionários.
```
ibmcloud ks worker-pool ls --cluster CLUSTER
```

Obtenha os detalhes de sua sub-rede.

ibmcloud ks worker-pool get WORKER_POOL --cluster CLUSTER | grep -A 3 Subnets

Obtenha seus CIDRs de sub-rede. Repita essa etapa para cada sub-rede. Você usará esse intervalo CIDR posteriormente.
```
ibmcloud is subnet SUBNET_ID | grep "IPv4 CIDR"
```

Liste seus grupos de segurança e anote o grupo de segurança do ID kube-<clusterID> para seu cluster. É necessário o ID do grupo de segurança posteriormente ao incluir regras do grupo de segurança..

ibmcloud is sg

Saída de exemplo

ID                                          Name                                             Rules   Targets   VPC       Resource group
r006-4aaec88f-4986-4b7c-a737-401f7fef1555   kube-clusterID                       15      0         my-vpc   default

Crie um grupo de segurança customizado no mesmo VPC que o seu cluster Você pode usar esse grupo de segurança para controlar o acesso a seus compartilhamentos de arquivos incluindo regras do grupo de segurança
```
ibmcloud is security-group-create my-custom-security-group VPC-ID
```
Crie sua própria classe de armazenamento e insira o ID do grupo de segurança customizado criado anteriormente. Todos os PVCs criados a partir dessa classe de armazenamento estão em seu grupo de segurança customizado

Crie um PVC que utilize sua própria classe de armazenamento.

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: pvc-custom-vni
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 10Gi
    storageClassName: "" # For example: my-custom-storage-class

Após o PV se ligar ao PVC, obtenha os detalhes do PV e anote o valor nfsServerPath para localizar o endereço IP do VNI.
```
kubectl get pv pvc-XXXX -o yaml | grep nfsServerPath
```
Saída de exemplo
```
nfsServerPath: XXX.XX.XX.XXX:/XX # VNI IP address
```

Limitando o acesso de compartilhamento de arquivo a pods em um nó do trabalhador

Certifique-se de que você concluiu os pré-requisitos.

Inclua a regra a seguir no grupo de segurança customizado criado anteriormente.

ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.20 # Worker node IP

Adicione a seguinte regra ao grupo de segurança “ kube-clusterID ”.

ibmcloud is sg-rulec kube-<cluster-id> outbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.10 # VNI IP

Crie uma implementação que use o seu PVC. Somente os pods que são implementados no nó do trabalhador que corresponde à regra que você criou podem montar ou usar o PVC. Os pods implementados em outros nós estão presos no estado creating do contêiner

Limitando o acesso de compartilhamento de arquivo para pods em nós do trabalhador em uma única zona..

Certifique-se de que você concluiu os pré-requisitos.

Inclua a regra a seguir no grupo de segurança customizado criado anteriormente.

ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.0/24 # zone subnet cidr range

Adicione a seguinte regra ao grupo de segurança “ kube-clusterID ”. Especifique o endereço IP da interface de rede virtual (VNI).
```
ibmcloud is sg-rulec kube-<cluster-ID> outbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.10 # VNI IP
```
Crie uma implementação que use o seu PVC. Somente os pods implementados na zona listada na regra anterior podem montar o PVC. Os pods implementados em outras zonas não podem acessar o PVC e estão presos no estado creating do Contêiner.

Limitando o acesso de compartilhamento de arquivo a pods em nós do trabalhador em um único conjunto de trabalhadores..

Certifique-se de que você concluiu os pré-requisitos.

Crie regras de entrada para cada intervalo de sub-rede do pool de trabalhadores.

ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.0/24 # zone 1 subnet cidr range
ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.1.0/24 # zone 2 subnet cidr range

Adicione a seguinte regra ao grupo de segurança “ kube-clusterID ”. Especifique o endereço IP da interface de rede virtual (VNI) como o remoto ou origem.
```
ibmcloud is sg-rulec kube-<cluster-ID> outbound tcp --port-min 111 --port-max 2049 --remote 10.240.0.10 # VNI IP
```
Implemente um aplicativo que utilize o PVC que você criou anteriormente. Somente os pods nos conjuntos de trabalhadores indicados na regra anterior podem montar o PVC Ou, se você implementar seu app em um daemonset, os pods serão implementados com sucesso apenas nos nós do trabalhador para os qual você criou regras do grupo de segurança.... Os pods nos conjunto de trabalhadores que não estão no conjunto de trabalhadores especificado falham com um erro MountVolume.SetUp failed for volume "pvc-184b8c92-33ea-4874-b2ac-17665e53c060" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

Limitando o acesso de compartilhamento de arquivo aos pods nos nós do trabalhador em diversos conjuntos de trabalhadores

Certifique-se de que você concluiu os pré-requisitos.

Adicione as seguintes regras ao seu grupo de segurança personalizado. Especifique os conjuntos de trabalhadores e os intervalos de CIDR de sub-rede como o remoto ou a origem

ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.1.0/24 # worker pool 1, zone 1 subnet CIDR range
ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.240.1.0/24 # worker pool 1, zone 2 subnet CIDR range
ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.241.0.0/24 # worker pool 2, zone 1 subnet CIDR range
ibmcloud is sg-rulec CUSTOM-SG inbound tcp --port-min 111 --port-max 2049 --remote 10.241.1.0/24 # worker pool 2, zone 2subnet CIDR range

Adicione a seguinte regra ao grupo de segurança “ kube-<clusterID> ”. Especifique o endereço IP da interface de rede virtual (VNI) como o remoto ou origem.
```
ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 111 --port-max 2049 --remote 10.240.1.7 # VNI-IP
```
Crie uma implementação que use o seu PVC. Somente os pods implementados na zona indicada na regra podem montar o PVC Os pods implementados nos nós do trabalhador restritos estão presos no estado creating do Contêiner