Provisionando PVCs no Serviço Block Volume

Você pode provisionar dinamicamente um volume em blocos usando o plug-in CSI especificado pela definição da classe de armazenamento oci-bv (provisioner: blockvolume.csi.oraclecloud.com). Por exemplo, se o administrador do cluster não tiver criado qualquer PV adequado que corresponda à solicitação de PVC.

Você define uma PVC em um arquivo chamado csi-bvs-pvc.yaml. Por exemplo:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mynginxclaim
spec:
  storageClassName: "oci-bv"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Digite o seguinte comando para criar a PVC com base no arquivo csi-bvs-pvc.yaml:

kubectl create -f  csi-bvs-pvc.yaml

A saída do comando anterior confirma a criação da PVC:

persistentvolumeclaim "mynginxclaim" created

Verifique se a PVC foi criada executando kubectl get pvc:

kubectl get pvc

A saída do comando anterior mostra o status atual da PVC:

		
NAME               STATUS   VOLUME   CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Pending                                    oci-bv         4m

A PVC tem um status Pending porque a definição da classe de armazenamento oci-bv inclui volumeBindingMode: WaitForFirstConsumer.

Você pode usar essa PVC ao criar outros objetos, como pods. Por exemplo, você pode criar um novo pod com base na definição de pod a seguir, que instrui o sistema a usar a PVC mynginxclaim como volume nginx, que é montado pelo pod em /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: mynginxclaim

Depois de ter criado o novo pod, você poderá verificar se a PVC foi vinculada a um novo volume persistente digitando:

kubectl get pvc

A saída do comando anterior confirma que a PVC foi vinculada:

			
NAME               STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv         4m

Você pode verificar se o pod está usando a nova reivindicação de volume persistente digitando:

kubectl describe pod nginx

Você pode exibir estatísticas de capacidade para o novo volume persistente usando uma ferramenta de agregação de métricas, como o Prometheus.

Um snapshot de volume do Kubernetes é um snapshot de um volume persistente em um sistema de armazenamento. Você pode usar um snapshot de volume para provisionar um novo volume persistente. Para obter mais informações sobre snapshots de volume do Kubernetes, consulte Instantâneos de Volume na documentação do Kubernetes.

Ao usar o plug-in de volume CSI para conectar clusters a volumes em blocos no serviço Block Volume, você pode usar backups de volumes em blocos para provisionar snapshots de volumes do Kubernetes. Você pode usar um snapshot de volume para criar um novo volume em blocos e preenchê-lo previamente com dados do backup de volume em blocos. Para obter mais informações sobre backups de volume em blocos no serviço Block Volume, consulte Visão Geral dos Backups do Serviço Block Volume.

Você pode usar o plug-in de volume CSI para provisionar um snapshot de volume de duas maneiras:

• Dinamicamente: Você pode solicitar a criação de um backup do volume em blocos provisionando um volume persistente. Você especifica a reivindicação de volume persistente usando o objeto VolumeSnapshot e especifica os parâmetros a serem usados para criar o backup de volume em blocos usando o objeto VolumeSnapshotClass. Os snapshots de volume provisionados dinamicamente também são chamados de snapshots de volume dinâmico. Consulte Criando Snapshots de Volume Provisionados Dinamicamente.
• Estaticamente: Você pode fornecer detalhes de um backup de volume em blocos existente usando o objeto VolumeSnapshotContent. Os snapshots de volume provisionados estaticamente também são chamados de snapshots de volume estáticos e de snapshots de volume pré-provisionados. Criando Snapshots de Volume Provisionados Estaticamente

Quando você cria um snapshot de volume provisionado dinamicamente, as mesmas tags de formato livre e as tags definidas que foram aplicadas ao volume em blocos de origem são aplicadas ao backup do volume em blocos. No entanto, você pode usar parâmetros para aplicar tags adicionais ao backup de volume em blocos (consulte Marcando com Tags Backups de Volume em Blocos).

Há vários pré-requisitos a serem atendidos antes da criação de snapshots de volume para uso com clusters criados pelo Kubernetes Engine. Consulte Pré-requisitos para Criar Snapshots de Volume.

Observe o seguinte ao criar e usar snapshots de volume:

• Você só pode criar snapshots de volume ao usar o plug-in de volume CSI (ou seja, não é possível criar snapshots de volume ao usar o plug-in de volume FlexVolume).
• No caso de backups de volume dinâmicos, o plug-in de volume CSI cria um novo backup de volume em blocos para provisionar um snapshot de volume dinâmico no mesmo compartimento do cluster. No caso de snapshots de volume estático, o backup de volume em blocos que provisiona um snapshot de volume estático pode estar em outro compartimento para o cluster, desde que existam instruções de política apropriadas para permitir que o cluster acesse esse outro compartimento (consulte Pré-requisitos para Criar Instantâneos de Volume).
• Não é possível usar o plug-in de volume CSI para preencher novamente um volume existente com dados. Em outras palavras, você não pode restaurar (reverter) dados em um volume persistente existente para um estado anterior alterando o snapshot de volume especificado no manifesto da reivindicação de volume persistente. Você só pode usar o plug-in de volume CSI para preencher um novo volume com dados.
• Quando você cria um backup de volume em blocos (por exemplo, ao criar um snapshot de volume dinâmico), a chave de criptografia usada ao criar o volume em blocos também é usada para criar o backup. Você não pode especificar uma nova chave de criptografia ao criar um backup de volume em blocos. Portanto, o backup de volume em blocos usa a mesma criptografia do volume em blocos que ele faz backup.
• O tamanho especificado para um volume persistente provisionado por um snapshot de volume não deve ser menor que o tamanho do volume original do qual o snapshot foi criado.
• Quando o plug-in de volume CSI cria um novo volume em blocos para fazer backup de um volume persistente provisionado por um snapshot de volume, o posicionamento do volume em blocos depende dos requisitos de topologia da solicitação de criação de volume. Por exemplo, se o plug-in de volume CSI criar um volume em blocos para um pod que use uma reivindicação de volume persistente, o volume em blocos será criado no mesmo domínio de disponibilidade que o nó de trabalho no qual o pod está sendo executado.
• Não há suporte para snapshots de espaços entre nomes.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

ALLOW any-user to manage volume-backups in compartment <compartment-name> where request.principal.type = 'cluster'
ALLOW any-user to use volumes in compartment <compartment-name> where request.principal.type = 'cluster'

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: "oci-bv"
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvctobackup.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: sample-pvc

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
deletionPolicy: Delete

kubectl create -f csi-mysnapshotclass.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
  namespace: default
spec:
  volumeSnapshotClassName: my-snapclass
  source:
    persistentVolumeClaimName: sample-pvc

kubectl create -f csi-mysnapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: my-static-snapshot-content
spec:
  deletionPolicy: Retain
  driver: blockvolume.csi.oraclecloud.com
  source:
    snapshotHandle: ocid1.volumebackup.oc1.iad.aaaaaa______xbd
  volumeSnapshotRef:
    name: my-static-snapshot
    namespace: default

kubectl create -f csi-mystaticsnapshotcontent.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-static-snapshot
spec:
  source:
    volumeSnapshotContentName: my-static-snapshot-content

kubectl create -f csi-mystaticsnapshot.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fromsnapshot
  namespace: default
spec:
  storageClassName: oci-bv
  dataSource:
    name: test-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvcfromsnapshot.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-restore
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-fromsnapshot

oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'

oci.oraclecloud.com/defined-tags: '{"<tag-namespace>": {"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}}'

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
  oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'
deletionPolicy: Delete

Um clone do Kubernetes é uma duplicata exata de um volume persistente existente em um sistema de armazenamento. Você pode clonar um volume persistente existente para provisionar uma nova reivindicação de volume persistente. O novo volume persistente contém uma cópia dos dados do volume persistente de origem, mas é independente do volume persistente de origem. Você pode usar clones de volume para testar alterações de configuração rapidamente, sem afetar um ambiente de produção. Para obter mais informações sobre clones do Kubernetes, consulte Clonagem de Volume do CSI na documentação do Kubernetes.

No serviço Block Volume, você pode clonar um volume em blocos para criar um novo volume em blocos pré-preenchido com dados do volume em blocos de origem. Para obter mais informações sobre a clonagem de volumes em blocos no serviço Block Volume, consulte Clonando um Volume em Blocos.

Ao usar o plug-in de volume CSI para conectar clusters a volumes em blocos no serviço Block Volume, você pode provisionar uma nova PVC com um novo volume em blocos que foi clonado de um volume em blocos existente provisionando outra PVC existente. Para indicar que você deseja que o plug-in de volume CSI clone o volume em blocos existente para a nova PVC, especifique a PVC existente como origem de dados para a nova PVC.

O PVC novo pode ser usado da mesma maneira que qualquer outro PVC, e é inteiramente separado ao PVC existente especificado como a fonte de dados. Da mesma forma, o novo volume em blocos e o volume em blocos existente do qual ele é clonado são recursos totalmente separados e podem ser atualizados, clonados, instantâneos e excluídos independentemente um do outro.

Assim que o volume em blocos de origem tiver sido clonado e um novo volume em blocos tiver sido criado (geralmente em alguns segundos), o novo volume em blocos terá um estado Disponível. Todos os dados presentes no volume em blocos de origem nesse momento são copiados para o novo volume em blocos (nenhuma alteração subsequente é copiada). No entanto, os dados são copiados em segundo plano, o que pode levar até trinta minutos, dependendo do tamanho do volume em blocos (por exemplo, pode levar até quinze minutos para copiar um volume em blocos de 1 TB). Portanto, para evitar a possibilidade de erros ou corrupção de dados, a nova PVC tem um estado de Pendente até que todos os dados tenham sido copiados. Quando todos os dados foram copiados, a nova PVC está vinculada ao PV provisionado pelo novo volume em blocos e a nova PVC tem um estado Disponível.

Há vários pré-requisitos a serem atendidos antes de provisionar uma nova reivindicação de volume persistente clonando o volume em blocos que já está provisionando uma reivindicação de volume persistente existente. Consulte Pré-requisitos para Clonar um Volume em Blocos Existente para Provisionar uma Nova PVC.

Observe o seguinte ao clonar um volume em blocos para provisionar uma nova PVC:

• O plug-in de volume CSI cria o novo volume em blocos no mesmo domínio de disponibilidade, região e tenancy do volume em blocos de origem.
• O novo volume em blocos criado pelo plug-in de volume CSI pode ser clonado assim que tiver um estado Disponível.
• Todos os requisitos de topologia em uma solicitação de criação de volume são ignorados. Por exemplo, se o plug-in de volume CSI clones um volume em blocos para um pod que usa uma reivindicação de volume persistente, o novo volume em blocos será criado no mesmo domínio de disponibilidade que o nó de trabalho no qual o pod está sendo executado.
• Não é possível usar o plug-in de volume CSI para clonar volumes em blocos criados pelo plug-in de volume FlexVolume.
• Não é possível excluir a PVC de origem enquanto a clonagem estiver em andamento. Da mesma forma, não é possível excluir um volume em blocos de origem enquanto os dados estão sendo copiados para um volume em blocos que foi clonado dele.
• A clonagem entre namespaces não é suportada. A nova PVC e a PVC de origem devem estar no mesmo namespace.
• Você não precisa especificar explicitamente uma classe de armazenamento para a nova PVC. Se você especificar explicitamente uma classe de armazenamento para a nova PVC, a classe de armazenamento especificada poderá ser diferente da classe de armazenamento especificada para a PVC de origem. Se você não especificar uma classe de armazenamento para a nova PVC, a classe de armazenamento padrão será usada.

Por exemplo, você define uma reivindicação de volume persistente chamada my-clone-pvc em um arquivo chamado csi-myclonepvc.yaml. A reivindicação de volume persistente my-clone-pvc é provisionada por um volume em blocos criado pela clonagem do volume em blocos que provisiona a reivindicação de volume persistente my-source-pvc:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-clone-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: custom-clone-storage-class
  resources:
    requests:
      storage: 50Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: my-source-pvc

Crie a reivindicação de volume persistente:

kubectl create -f csi-myclonepvc.yaml

Você pode usar a reivindicação de volume persistente ao definir outros objetos, como pods. Por exemplo, a definição de pod a seguir instrui o sistema a usar a reivindicação de volume persistente my-clone-pvc como volume nginx, que é montado pelo pod em /sample-volume.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: my-clone-pvc

Tendo criado o novo pod, a reivindicação de volume persistente my-clone-pvc é vinculada a um novo volume persistente provisionado por um volume em blocos que foi clonado do volume em blocos provisionando a reivindicação de volume persistente my-source-pvc.

Você pode criar uma PVC com base em um volume em blocos existente ou em um backup de volume em blocos para uso pelo plug-in de volume FlexVolume. Por exemplo, se o administrador do cluster tiver criado um backup de volume em blocos para você usar ao provisionar uma nova reivindicação de volume persistente. Esse backup de volume em blocos pode vir com dados prontos para uso de outros objetos, como pods.

Você define uma PVC em um arquivo chamado flex-pvcfrombackup.yaml. Use o elemento de anotação volume.beta.kubernetes.io/oci-volume-source para especificar a origem do volume em blocos a ser usado ao provisionar uma nova reivindicação de volume persistente usando o plug-in de volume FlexVolume. Você pode especificar o OCID de um volume em blocos ou de um backup de volume em blocos como valor da anotação. Neste exemplo, você especifica o OCID do backup de volume em blocos criado pelo administrador do cluster. Por exemplo:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myvolume
  annotations:
    volume.beta.kubernetes.io/oci-volume-source: ocid1.volumebackup.oc1.iad.abuw...
spec:
  selector:
    matchLabels:
      topology.kubernetes.io/zone: US-ASHBURN-AD-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Observe que o arquivo flex-pvcfrombackup.yaml inclui o elemento matchLabels, que só se aplica no caso do plug-in de volume FlexVolume.

Digite o seguinte comando para criar a PVC com base no arquivo flex-pvcfrombackup.yaml:

kubectl create -f flex-pvcfrombackup.yaml

A saída do comando anterior confirma a criação da PVC:

persistentvolumeclaim "myvolume" created

Verifique se a PVC foi criada e vinculada a um novo volume persistente criado com base no backup de volume digitando:

kubectl get pvc

A saída do comando anterior mostra o status atual da PVC:

			
NAME           STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
myvolume       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci            4m

Você pode usar o novo volume persistente criado do backup de volume ao definir outros objetos, como pods. Por exemplo, a definição de pod a seguir instrui o sistema a usar a PVC myvolume como volume nginx, que é montado pelo pod em /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: myvolume

Depois de ter criado o novo pod, você poderá verificar se ele está sendo executado e usando a nova reivindicação de volume persistente digitando:

kubectl describe pod nginx

O serviço Oracle Cloud Infrastructure Block Volume sempre criptografa todos os volumes em blocos e backups de volume em armazenamento usando o algoritmo AES (Advanced Encryption Standard) com criptografia de 256 bits. Por padrão, todos os volumes e seus backups são criptografados usando as chaves de criptografia fornecidas pela Oracle. Cada vez que um volume é clonado ou restaurado de um backup, ele recebe uma nova chave de criptografia exclusiva.

Você tem a opção de criptografar todos os volumes e seus backups usando as chaves que possui e gerencia usando o serviço Vault. Para obter mais informações, consulte Key Management. Se você não configurar um volume para usar o serviço Vault ou posteriormente cancelar a designação de uma chave do volume, o serviço Block Volume usará a chave de criptografia fornecida pela Oracle. Isso se aplica à criptografia em repouso e em trânsito paravirtualizada.

Todos os dados em movimento entre a instância e o volume em blocos são transferidos por meio de uma rede interna altamente segura. Se você tiver requisitos de conformidade específicos relacionados à criptografia dos dados durante a movimentação entre a instância e o volume em blocos, o serviço Block Volume fornecerá a opção de ativar a criptografia em trânsito para anexos de volume paravirtualizados em instâncias de máquina virtual (VM). Algumas formas bare metal suportam criptografia em trânsito para os volumes em blocos anexados ao iSCSI da instância.

Para obter mais informações sobre criptografia de volume em blocos e suporte a criptografia em trânsito, consulte Criptografia de Volume em Blocos.

Quando as PVCs do Kubernetes são respaldadas pelo serviço Block Volume, você escolhe como os volumes em blocos são criptografados especificando:

• A chave de criptografia mestra a ser usada, definindo a propriedade kms-key-id na definição da classe de armazenamento do Kubernetes. Você pode especificar o OCID de uma chave de criptografia principal no serviço Vault.
• Como o volume em blocos é anexado à instância de computação, definindo a propriedade attachment-type na definição da classe de armazenamento do Kubernetes como iscsi ou paravirtualized.
• Se a criptografia em trânsito está ativada para cada pool de nós em um cluster, definindo a propriedade isPvEncryptionInTransitEnabled do pool de nós (usando a CLI, a API ou a opção Usar criptografia em trânsito: do pool de nós na Console).

A interação das definições especificadas determina como os volumes em blocos são criptografados, conforme mostrado na tabela:

Para poder criar um cluster para o qual você mesmo deseja gerenciar a chave de criptografia mestra, é necessário:

• Crie uma chave principal de criptografia adequada no Vault (ou obtenha o OCID dessa chave). Consulte Gerenciando Chaves.
• Crie uma política que conceda acesso à chave de criptografia principal. Consulte Criar Política para Acessar Chaves de Criptografia Gerenciadas pelo Usuário para Criptografar Volumes de Inicialização, Volumes em Blocos e/ou Sistemas de Arquivos.

Para obter mais informações sobre rotação de chaves no serviço Vault, consulte Rotacionando uma Chave do Vault.

Quando uma PVC é criada usando o plug-in de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), você pode expandir o tamanho do volume on-line. Ao fazer isso, você torna possível implantar inicialmente aplicativos com uma certa quantidade de armazenamento e, em seguida, aumentar o armazenamento disponível sem qualquer tempo de inatividade.

Se você quiser suportar aumentos de solicitação de armazenamento, defina allowVolumeExpansion: true na definição da classe de armazenamento especificada para a PVC. Por exemplo:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-bv
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  attachment-type: "paravirtualized"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

A classe de armazenamento oci-bv padrão para o plug-in de volume CSI tem allowVolumeExpansion: true por padrão.

Para expandir o tamanho de um volume, edite o manifesto de PVC e atualize o tamanho do volume e aplique o manifesto. Quando o disco for submetido a nova verificação para permitir que o sistema operacional identifique o tamanho do volume expandido (o que pode levar alguns minutos), o armazenamento aumentado ficará automaticamente disponível para pods usando a PVC. Os pods não precisam ser reiniciados.

Digite o seguinte comando para confirmar se a PVC foi vinculada a um volume em blocos recém-alargado:

kubectl get pvc <pvc_name> -o yaml

Observe o seguinte:

• A expansão de volume é suportada em clusters que executam o Kubernetes 1.19 ou posterior.
• A classe de armazenamento oci-bv padrão para o plug-in de volume CSI é configurada com allowVolumeExpansion: true em clusters que executam o Kubernetes 1.19 ou posterior. As definições de classes de armazenamento oci-bv em clusters existentes que executam o Kubernetes 1.19 ou posterior são editadas automaticamente para definir allowVolumeExpansion: true.
• Não é possível reduzir o tamanho de um volume em blocos. Você só pode especificar um valor maior que o tamanho atual do volume em blocos. Se você atualizar um manifesto de PVC para solicitar menos armazenamento do que o solicitado anteriormente, a solicitação de armazenamento falhará.
• Para obter mais informações sobre como aumentar os tamanhos do volume em blocos no serviço Block Volume, consulte Redimensionando um Volume. Em particular, observe a recomendação de criar um backup antes de redimensionar um volume em blocos.

Os volumes em blocos no serviço Block Volume podem ser configurados para diferentes níveis de desempenho, de acordo com os requisitos esperados de E/S da carga de trabalho. O desempenho do volume em blocos é expresso em unidades de desempenho de volumes (VPUs). Vários níveis de desempenho estão disponíveis, incluindo:

• Menor Custo (0 VPUs)
• Balanceado (10 VPUs)
• Melhor Desempenho (20 VPUs)
• Altíssimo Desempenho (entre 30 VPUs e 120 VPUs)

Por padrão, os volumes em blocos são configurados para o nível de desempenho Balanceado (10 VPUs). Para obter mais informações sobre os diferentes níveis de desempenho do volume em blocos, consulte Níveis de Desempenho do Volume em Blocos.

Ao definir uma PVC usando o plug-in de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), você pode especificar outro nível de desempenho de volume em blocos na definição de classe de armazenamento apropriada para a carga de trabalho esperada.

Observe que não é possível alterar subsequentemente o nível de desempenho de um volume em blocos que oferece suporte a uma PVC. Em vez disso, você precisa definir uma nova classe de armazenamento, definir o nível de desempenho conforme necessário e criar uma nova PVC provisionada por essa nova classe de armazenamento.

Os volumes em blocos no serviço Block Volume podem ser configurados para diferentes tipos de sistema de arquivos. O sistema de arquivos mais apropriado a ser usado depende (entre outras coisas) do tamanho de arquivo esperado e do número de arquivos a serem processados. Vários tipos de sistema de arquivos estão disponíveis, incluindo:

• ext3: O tipo de sistema de arquivos ext3 inclui recursos de diário para melhorar a confiabilidade e a disponibilidade. Verificações de consistência após uma falha de energia ou um desligamento descontrolado do sistema são desnecessárias.
• ext4: Além dos recursos ext3, o tipo de sistema de arquivos ext4 suporta extensões (blocos físicos contíguos), pré-alocação, alocação atrasada, verificação mais rápida do sistema de arquivos, registro em diário mais robusto e outros aprimoramentos.
• XFS: O sistema de arquivos XFS é um tipo de sistema de arquivos de registro em diário de alto desempenho, que fornece alta escalabilidade para threads de E/S, largura de banda do sistema de arquivos, tamanho do arquivo e do sistema de arquivos, mesmo quando o sistema de arquivos abrange muitos dispositivos de armazenamento.

Os sistemas de arquivos ext3 e ext4 são geralmente considerados mais adequados para aplicativos que usam um único thread de leitura/gravação e arquivos pequenos. Considerando que, o sistema de arquivos XFS é geralmente considerado mais adequado para aplicativos que têm vários threads de leitura/gravação e arquivos maiores.

Quando uma PVC é criada usando o plug-in de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), você pode especificar um tipo de sistema de arquivos para o volume em blocos apropriado para a carga de trabalho esperada.

Por padrão, os volumes em blocos são configurados com um sistema de arquivos ext4. Se o sistema de arquivos ext4 não for o sistema de arquivos mais apropriado para a carga de trabalho esperada, você poderá especificar um tipo de sistema de arquivos alternativo na definição da classe de armazenamento.

Para criar uma PVC suportada por um volume em blocos com um sistema de arquivos ext3 ou XFS, defina o parâmetro fstype na definição da classe de armazenamento personalizada da seguinte forma:

• para ext3, defina csi.storage.k8s.io/fstype: ext3
• para XFS, defina csi.storage.k8s.io/fstype: xfs

Por exemplo, para criar uma PVC suportada por um volume em blocos com um sistema de arquivos ext3:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: oci-bv-ext3
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  csi.storage.k8s.io/fstype: ext3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForConsumer

Crie um manifesto para uma PVC provisionada pela classe de armazenamento oci-bv-ext3 e inclua uma solicitação de armazenamento. Por exemplo, em um arquivo chamado csi-bvs-pvc-fstype.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: oci-bv-claim-ext3
spec:
  storageClassName: oci-bv-ext3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Digite o seguinte comando para criar a PVC com base no arquivo csi-bvs-PVC-fstype.yaml:

kubectl apply -f csi-bvs-pvc-fstype.yaml

Depois de criar a PVC, você pode usá-la ao criar outros objetos, como pods. Por exemplo, você pode criar um novo pod com base na definição de pod a seguir, que instrui o sistema a usar a PVC oci-bv-claim-ext3 como volume nginx, que é montado pelo pod em /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: oci-bv-claim-ext3

Depois de ter criado o novo pod, você poderá verificar se a PVC foi vinculada a um novo volume persistente digitando:

kubectl get pvc

A saída do comando anterior confirma que a PVC foi vinculada:

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
oci-bv-claim-ext3       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv-ext3         4m

Você pode verificar se o pod está usando a nova reivindicação de volume persistente digitando:

kubectl describe pod nginx

Observe que não é possível alterar subsequentemente o sistema de arquivos de um volume em blocos que suporta uma PVC. Em vez disso, você precisa definir uma nova classe de armazenamento, definir o sistema de arquivos conforme necessário e criar uma nova PVC provisionada por essa nova classe de armazenamento.