Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Mount OSS buckets using ossfs 1.0 dynamic volumes

    Central de documentação

    Container Service for Kubernetes:Mount OSS buckets using ossfs 1.0 dynamic volumes

    Última atualização: Nov 03, 2026

    O ossfs 1.0 oferece suporte ao dynamic provisioning, que cria automaticamente um volume persistente (PV) e monta um OSS Bucket com base em uma StorageClass e em uma PersistentVolumeClaim (PVC). Esse recurso elimina a configuração manual de PV

    , simplifica significativamente o gerenciamento de armazenamento e é ideal para ambientes multilocatários ou cenários que exigem provisionamento de armazenamento frequente e sob demanda.

    tmpfile

    Requisitos

    Seu cluster e componentes CSI (csi-plugin e csi-provisioner) devem atender aos seguintes requisitos:

    • Para autenticação usando RAM Roles for Service Accounts (RRSA): Seu cluster deve estar na versão 1.26 ou posterior, e a versão do CSI deve ser v1.30.4 ou posterior.

      Se você utilizou o recurso RRSA em uma versão anterior à v1.30.4, consulte {{XREF_0}} para adicionar a configuração de autorização da função RAM necessária.

    • Para autenticação usando AccessKey: Para garantir a estabilidade da montagem, recomendamos a versão v1.18.8.45 ou posterior do CSI.

    Para atualizar seu cluster, consulte {{XREF_1}}. Para atualizar os componentes CSI, consulte {{XREF_2}}.

    A partir do CSI v1.30.4-*, {{XREF_3}} .

    Etapa 1: Escolher um método de autenticação

    Para garantir que seu cluster possa acessar recursos do OSS Bucket de forma segura e em conformidade, configure primeiro um método de autenticação.

    • {{XREF_4}}: Concede dinamicamente aos Pods funções RAM temporárias e com rotação automática para permitir isolamento de permissões granular no nível da aplicação. Este método é mais seguro.

    • {{XREF_5}}: Armazena chaves estáticas de longo prazo em um Secret. Este método é mais simples de configurar, mas menos seguro.

    Importante

    • Para clusters executando a versão 1.26 ou posterior, recomendamos a autenticação RRSA para evitar reinicializações de cargas de trabalho e remontagens do ossfs causadas pela rotação de AccessKey.

    • Este exemplo pressupõe que o cluster e o {{XREF_6}} estejam na mesma conta Alibaba Cloud. Para {{XREF_7}}, recomendamos o uso da autenticação RRSA.

    RRSA

    1. Ativar RRSA para seu cluster

    1. Na página ACK Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Cluster Information.

    2. Na aba Basic Information, na seção Security and Auditing, clique em Enabled à direita de RRSA OIDC. Siga as instruções na tela para ativar o RRSA fora do horário de pico.

      Quando o status do cluster mudar de Updating para Running, o RRSA estará ativado.

      Importante

      Após ativar o RRSA, o período máximo de validade dos tokens ServiceAccount recém-criados no cluster fica limitado a 12 horas.

    2. Criar e autorizar uma função RAM

    Crie uma função RAM que seus Pods possam assumir para acesso autenticado via RRSA ao volume de armazenamento OSS.

    View the steps

    1. Crie uma função RAM.

      1. Acesse a página Create Role no RAM Console. Em Principal Type, selecione IdP. Em seguida, clique em Switch to Policy Editor para abrir o Visual Editor.

      2. Em Principal, selecione IdP. Clique em Edit e configure os parâmetros conforme descrito na tabela a seguir.

        Configure os principais parâmetros e mantenha os valores padrão para os demais. Para mais informações, consulte {{XREF_8}} .

        Parâmetro

        Descrição

        IdP Type

        OIDC.

        IdP

        Selecione ack-rrsa-<cluster_id>, onde <cluster_id> é o ID do seu cluster.

        Condition

        Adicione manualmente oidc:sub.

        • Chave de condição: Selecione oidc:sub.

        • Operador: Selecione StringEquals.

        • Valor da condição: Insira system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs.

          • ack-csi-fuse: O namespace do cliente ossfs. Este valor não pode ser personalizado.

          • csi-fuse-ossfs: O nome da ServiceAccount.

            Para alterar este valor, consulte {{XREF_9}}

        Role Name

        Por exemplo, insira demo-role-for-rrsa.

    2. Crie uma política de acesso.

      Este exemplo segue o princípio do menor privilégio. {{XREF_10}} para conceder acesso ao OSS Bucket de destino. É possível conceder permissões somente leitura ou leitura/gravação.

      1. Acesse a página Create Policy no RAM Console, alterne para o JSON Editor e configure o script da política.

        Se você já possui uma função RAM com permissões OSS, pode reutilizá-la modificando sua política de confiança. Para mais informações, consulte {{XREF_11}} .

        Política somente leitura

        Substitua pelo nome real do bucket.
        tmpfile

        Política de leitura/gravação do OSS

        Substitua &lt;myBucketName&gt; pelo nome real do bucket.
        tmpfile

      2. (Opcional) Se você usar um CMK ID específico gerenciado pelo KMS para criptografar objetos OSS, também deverá conceder permissões do KMS à função. Para mais informações, consulte {{XREF_12}}.

    3. Anexe a política de acesso à função RAM.

      1. Acesse a página Roles no RAM Console, localize a função criada e, na coluna Actions, clique em Attach Policy.

      2. Na seção Policies, pesquise e selecione a política de acesso criada.

    AccessKey

    Crie um usuário RAM com permissões para acessar o OSS Bucket de destino e obtenha um AccessKey para esse usuário.

    1. Crie um usuário RAM. Pule esta etapa se já possuir um usuário RAM.

      Acesse a página Create User no RAM Console e siga as instruções na tela para criar um usuário RAM. Especifique parâmetros como nome de logon e senha.

    2. Crie uma política de acesso.

      Este exemplo segue o princípio do menor privilégio. {{XREF_13}} para conceder acesso ao OSS Bucket de destino. É possível conceder permissões somente leitura ou leitura/gravação.

      1. Acesse a página Create Policy no RAM Console, alterne para o JSON Editor e configure o script da política.

        Política somente leitura

        Substitua &lt;myBucketName&gt; pelo nome real do bucket.
        tmpfile

        Política de leitura/gravação do OSS

        Substitua &lt;myBucketName&gt; pelo nome real do bucket.
        tmpfile

        Se desejar criar um PV no console, você também precisará da permissão oss:ListBuckets.

        tmpfile

      2. (Opcional) Se você usar um CMK ID específico gerenciado pelo KMS para criptografar objetos OSS, também deverá conceder permissões do KMS ao usuário RAM. Para mais informações, consulte {{XREF_14}}.

    3. Anexe a política de acesso ao usuário RAM.

      1. Acesse a página Users no RAM Console, localize o usuário criado e, na coluna Actions, clique em Add Permissions.

      2. Na seção Policies, pesquise e selecione a política de acesso criada.

    4. O AccessKey criado será armazenado como um Secret para o PV.

      1. Acesse a página Users no RAM Console, clique no nome do seu usuário RAM e, na seção AccessKey, clique em Create AccessKey.

      2. Siga as instruções na tela para criar um AccessKey. Copie e armazene com segurança o AccessKey ID e o AccessKey Secret.

    Etapa 2: Criar uma StorageClass

    Crie uma StorageClass para definir um modelo de provisionamento de volumes persistentes.

    Método RRSA

    1. Crie um arquivo chamado sc-oss.yaml.

      tmpfile

      Parâmetro

      Descrição

      bucket

      O bucket OSS a ser montado.

      region

      Ao usar a assinatura OSS v4, defina este valor como a região OSS onde o bucket está localizado. Para consultar a região OSS, consulte {{XREF_15}}.

      Quando este parâmetro é definido, v4 é usado automaticamente como versão da assinatura OSS.

      path

      A versão do componente CSI deve ser v1.14.8.32-c77e277b-aliyun ou posterior.

      O caminho de montagem relativo ao diretório raiz do bucket. O valor padrão é /, que monta o bucket inteiro.

      Se a {{XREF_16}} for anterior a 1.91, o path especificado deve existir no bucket OSS. Para mais informações, consulte {{XREF_17}}.

      url

      O {{XREF_18}} do OSS Bucket a ser montado.

      • Use um endpoint interno se o nó de montagem e o bucket estiverem na mesma região, ou se houver uma conexão VPC estabelecida.

      • Use um endpoint público se o nó de montagem e o bucket estiverem em regiões diferentes.

      Os formatos comuns para diferentes portas de acesso são:

      • Formato de rede interna: https://oss-{{regionName}}-internal.aliyuncs.com.

        O formato de endpoint interno vpc100-oss-{{regionName}}.aliyuncs.com foi descontinuado. Migre para o novo formato prontamente.

      • Formato de rede pública: https://oss-{{regionName}}.aliyuncs.com.

      Por questões de segurança, recomendamos {{XREF_19}}. Para usar HTTP, substitua o prefixo https:// nos formatos acima por http://.

      authType

      Defina este parâmetro como rrsa para usar RRSA na autenticação.

      roleName

      A função RAM que você criou ou modificou.

      Para configurar permissões diferentes para StorageClasses distintas, crie múltiplas funções RAM e especifique valores roleName diferentes em cada StorageClass.

      otherOpts

      Parâmetros personalizados para o volume persistente OSS, no formato -o -o . Exemplo: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

      Expandir para detalhes

      • umask: Define a máscara de permissão para arquivos e diretórios.

        Por exemplo, umask=022 altera as permissões de arquivo para 755. Isso resolve problemas de permissão para arquivos enviados por outros métodos, como SDKs ou o console OSS, que possuem permissão padrão 640. Recomendamos configurar este parâmetro para separação de leitura/gravação ou acesso multiusuário.

      • max_stat_cache_size: Define o limite máximo de entradas de cache de metadados, por exemplo, 100000. Metadados são armazenados em cache na memória para melhorar o desempenho de operações como ls e stat.

        No entanto, este cache não detecta imediatamente modificações de arquivos feitas pelo console OSS, SDKs ou ossutil. Isso pode fazer com que aplicações leiam dados inconsistentes. Se tiver requisitos rigorosos de consistência de dados, defina este parâmetro como 0 para desativar o cache, ou reduza o tempo de expiração usando o parâmetro stat_cache_expire. Isso, contudo, pode reduzir o desempenho de leitura.

      • allow_other: Permite que usuários diferentes daquele que montou o volume acessem arquivos e diretórios no caminho de montagem. Adequado para ambientes compartilhados multiusuário onde outros usuários também precisam acessar dados.

      Para mais informações sobre parâmetros opcionais, consulte {{XREF_20}} e {{XREF_21}}.

      provisioner

      O tipo de driver. Este valor é fixo em ossplugin.csi.alibabacloud.com ao usar o plug-in CSI do Alibaba Cloud OSS.

      reclaimPolicy

      A política de recuperação para volumes persistentes provisionados dinamicamente. Volumes persistentes OSS suportam apenas Retain, o que significa que, ao excluir uma PVC, o volume persistente correspondente e os dados no bucket OSS não são excluídos.

      volumeBindingMode

      O modo de vinculação de volume.

      Volumes persistentes OSS não exigem afinidade de nó baseada em zona de disponibilidade. Você pode usar o valor padrão Immediate.

      volumeAs

      O modo de acesso ao volume. O valor padrão é sharepath. Valores válidos:

      • sharepath: Todos os volumes persistentes compartilham o mesmo caminho de montagem. Os dados são armazenados em <bucket>:<path>/.

      • subpath: Cria um subdiretório dedicado para cada volume persistente visando isolar dados. Os dados são armazenados em <bucket>:<path>/<pv-name>/.

        Este parâmetro entra em vigor apenas quando a versão do componente CSI é 1.31.3 ou posterior.

      sigVersion

      A versão da assinatura para solicitações enviadas ao servidor OSS.

      • "v1" (Padrão): Usa {{XREF_22}} do OSS.

      • "v4" (Recomendado): Usa {{XREF_23}} do OSS.

    2. Crie a StorageClass.

      tmpfile

    Método AccessKey

    kubectl

    1. Criar uma StorageClass

    1. Crie um Secret no mesmo namespace da sua aplicação.

      Substitua akId e akSecret pelo seu AccessKey ID e AccessKey Secret.

      tmpfile

    2. Crie a StorageClass.

      1. Crie um arquivo chamado sc-oss.yaml.

        tmpfile

        Parâmetro

        Descrição

        name

        O nome da StorageClass.

        bucket

        O bucket OSS a ser montado.

        region

        Ao usar a assinatura OSS v4, defina este valor como a região OSS onde o bucket está localizado. Para consultar a região OSS, consulte {{XREF_24}}.

        Quando este parâmetro é definido, v4 é usado automaticamente como versão da assinatura OSS.

        path

        A versão do componente CSI deve ser v1.14.8.32-c77e277b-aliyun ou posterior.

        O caminho de montagem relativo ao diretório raiz do bucket. O valor padrão é /, que monta o bucket inteiro.

        Se a {{XREF_25}} for anterior a 1.91, o path especificado deve existir no bucket OSS. Para mais informações, consulte {{XREF_26}}.

        url

        O {{XREF_27}} do OSS Bucket a ser montado.

        • Use um endpoint interno se o nó de montagem e o bucket estiverem na mesma região, ou se houver uma conexão VPC estabelecida.

        • Use um endpoint público se o nó de montagem e o bucket estiverem em regiões diferentes.

        Os formatos comuns para diferentes portas de acesso são:

        • Formato de rede interna: https://oss-{{regionName}}-internal.aliyuncs.com.

          O formato de endpoint interno vpc100-oss-{{regionName}}.aliyuncs.com foi descontinuado. Migre para o novo formato prontamente.

        • Formato de rede pública: https://oss-{{regionName}}.aliyuncs.com.

        Por questões de segurança, recomendamos {{XREF_28}}. Para usar HTTP, substitua o prefixo https:// nos formatos acima por http://.

        csi.storage.k8s.io/node-publish-secret-name

        O nome do Secret que armazena as informações do AccessKey.

        csi.storage.k8s.io/node-publish-secret-namespace

        O namespace onde o Secret que armazena as informações do AccessKey está localizado.

        otherOpts

        Parâmetros personalizados para o volume persistente OSS, no formato -o -o . Exemplo: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

        Expandir para detalhes

        • umask: Define a máscara de permissão para arquivos e diretórios.

          Por exemplo, umask=022 altera as permissões de arquivo para 755. Isso resolve problemas de permissão para arquivos enviados por outros métodos, como SDKs ou o console OSS, que possuem permissão padrão 640. Recomendamos configurar este parâmetro para separação de leitura/gravação ou acesso multiusuário.

        • max_stat_cache_size: Define o limite máximo de entradas de cache de metadados, por exemplo, 100000. Metadados são armazenados em cache na memória para melhorar o desempenho de operações como ls e stat.

          No entanto, este cache não detecta imediatamente modificações de arquivos feitas pelo console OSS, SDKs ou ossutil. Isso pode fazer com que aplicações leiam dados inconsistentes. Se tiver requisitos rigorosos de consistência de dados, defina este parâmetro como 0 para desativar o cache, ou reduza o tempo de expiração usando o parâmetro stat_cache_expire. Isso, contudo, pode reduzir o desempenho de leitura.

        • allow_other: Permite que usuários diferentes daquele que montou o volume acessem arquivos e diretórios no caminho de montagem. Adequado para ambientes compartilhados multiusuário onde outros usuários também precisam acessar dados.

        Para mais informações sobre parâmetros opcionais, consulte {{XREF_29}} e {{XREF_30}}.

        provisioner

        O tipo de driver. Este valor é fixo em ossplugin.csi.alibabacloud.com ao usar o plug-in CSI do Alibaba Cloud OSS.

        reclaimPolicy

        A política de recuperação para volumes persistentes provisionados dinamicamente. Volumes persistentes OSS suportam apenas Retain, o que significa que, ao excluir uma PVC, o volume persistente correspondente e os dados no bucket OSS não são excluídos.

        volumeBindingMode

        O modo de vinculação de volume.

        Volumes persistentes OSS não exigem afinidade de nó baseada em zona de disponibilidade. Você pode usar o valor padrão Immediate.

        volumeAs

        O modo de acesso ao volume. O valor padrão é sharepath. Valores válidos:

        • sharepath: Todos os volumes persistentes compartilham o mesmo caminho de montagem. Os dados são armazenados em <bucket>:<path>/.

        • subpath: Cria um subdiretório dedicado para cada volume persistente visando isolar dados. Os dados são armazenados em <bucket>:<path>/<pv-name>/.

          Este parâmetro entra em vigor apenas quando a versão do componente CSI é 1.31.3 ou posterior.

        sigVersion

        A versão da assinatura para solicitações enviadas ao servidor OSS.

        • "v1" (Padrão): Usa {{XREF_31}} do OSS.

        • "v4" (Recomendado): Usa {{XREF_32}} do OSS.

      2. Crie a StorageClass.

        tmpfile

    Console

    1. Armazene o AccessKey de {{XREF_33}} como um Secret para o volume persistente.

      1. Na página ACK Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Configurations > Secrets.

      2. Clique em Create from YAML e siga as instruções na tela para criar o Secret.

        tmpfile

    2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Volumes > StorageClasses.

    3. Na página StorageClasses, clique em Create, defina PV Type como OSS e siga as instruções na tela para configurar a StorageClass.

      Parâmetro

      Descrição

      Certificado de acesso

      O Secret usado para acessar o OSS, contendo o AccessKey ID e o AccessKey Secret.

      Bucket ID:

      O bucket OSS a ser utilizado.

      O console exibe apenas os buckets que o AccessKey configurado pode acessar.

      Caminho OSS

      A versão do componente CSI deve ser v1.14.8.32-c77e277b-aliyun ou posterior.

      O caminho de montagem relativo ao diretório raiz do bucket. O valor padrão é /, que monta o bucket inteiro.

      Se a {{XREF_34}} for anterior a 1.91, o path especificado deve existir no bucket OSS. Para mais informações, consulte {{XREF_35}}.

      Volume Mode

      O modo de acesso ao volume. O padrão é Shared Directory. Valores válidos:

      O modo Subdirectory entra em vigor apenas quando a versão do componente CSI é 1.31.3 ou posterior. Caso contrário, o modo Shared Directory é utilizado.

      • Shared Directory (sharepath): Todos os volumes persistentes compartilham o mesmo caminho de montagem. Os dados são armazenados em <bucket>:<path>/.

      • Subdirectory (subpath): Cria um subdiretório dedicado para cada volume persistente visando isolar dados. Os dados são armazenados em <bucket>:<path>/<pv-name>/.

      Endpoint

      O endpoint de acesso para o bucket OSS.

      • Use um endpoint interno se os nós do cluster e o bucket estiverem na mesma região, ou se houver uma conexão Virtual Private Cloud (VPC) estabelecida.

      • Use um endpoint público se o nó de montagem e o bucket estiverem em regiões diferentes.

      Os formatos comuns para diferentes endpoints de acesso são:

      • Interno: http://oss-{{regionName}}-internal.aliyuncs.com ou https://oss-{{regionName}}-internal.aliyuncs.com.

        Nota

        O formato de endpoint de acesso interno vpc100-oss-{{regionName}}.aliyuncs.com foi descontinuado. Migre para o novo formato assim que possível.

      • Público: http://oss-{{regionName}}.aliyuncs.com ou https://oss-{{regionName}}.aliyuncs.com.

      Por padrão, o console usa HTTP para acessar o OSS via rede interna. Para usar HTTPS, crie o PV utilizando {{XREF_36}}.

      Política de recuperação

      A política de recuperação para volumes persistentes provisionados dinamicamente. Volumes persistentes OSS suportam apenas Retain, o que significa que, ao excluir uma PVC, o volume persistente correspondente e os dados no bucket OSS não são excluídos.

      Optional Parameters:

      Parâmetros personalizados para o volume persistente OSS, no formato -o -o . Exemplo: -o umask=022 -o max_stat_cache_size=100000 -o allow_other.

      Expandir para detalhes

      • umask: Define a máscara de permissão para arquivos e diretórios.

        Por exemplo, umask=022 altera as permissões de arquivo para 755. Isso resolve problemas de permissão para arquivos enviados por outros métodos, como SDKs ou o console OSS, que possuem permissão padrão 640. Recomendamos configurar este parâmetro para separação de leitura/gravação ou acesso multiusuário.

      • max_stat_cache_size: Define o limite máximo de entradas de cache de metadados, por exemplo, 100000. Metadados são armazenados em cache na memória para melhorar o desempenho de operações como ls e stat.

        No entanto, este cache não detecta imediatamente modificações de arquivos feitas pelo console OSS, SDKs ou ossutil. Isso pode fazer com que aplicações leiam dados inconsistentes. Se tiver requisitos rigorosos de consistência de dados, defina este parâmetro como 0 para desativar o cache, ou reduza o tempo de expiração usando o parâmetro stat_cache_expire. Isso, contudo, pode reduzir o desempenho de leitura.

      • allow_other: Permite que usuários diferentes daquele que montou o volume acessem arquivos e diretórios no caminho de montagem. Adequado para ambientes compartilhados multiusuário onde outros usuários também precisam acessar dados.

      Para mais informações sobre parâmetros opcionais, consulte {{XREF_37}} e {{XREF_38}}.

    Etapa 3: Criar uma PVC

    Crie uma PVC para solicitar recursos de armazenamento dinamicamente. O plug-in CSI cria automaticamente um PV com base na StorageClass.

    kubectl

    1. Crie um arquivo chamado pvc-oss.yaml:

      tmpfile

      Parâmetro

      Descrição

      accessModes

      Especifica o modo de acesso. Os valores suportados são ReadOnlyMany e ReadWriteMany.

      Se definido como ReadOnlyMany, o ossfs monta o bucket OSS no modo somente leitura.

      storage

      A capacidade solicitada do volume. Este valor não limita a capacidade real do volume OSS.

      storageClassName

      O nome da StorageClass.

    2. Crie a PVC:

      tmpfile

    3. Verifique se a PVC foi criada e está no estado Bound:

      tmpfile

      Saída esperada:

      tmpfile

    Console

    1. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Volumes > Persistent Volume Claims.

    2. Na página Persistent Volume Claims, clique em Create. Defina PVC Type como OSS e configure os parâmetros.

      Parâmetro

      Descrição

      Allocation Mode

      Selecione Use StorageClass.

      Existing Storage Class

      Clique em Select Storage Class e escolha a StorageClass criada anteriormente.

      Capacidade

      A capacidade solicitada do volume. Este valor não limita a capacidade real do volume OSS.

      Access Mode

      Especifica o modo de acesso. Os valores suportados são ReadOnlyMany e ReadWriteMany.

      Se definido como ReadOnlyMany, o ossfs monta o bucket OSS no modo somente leitura.

    Etapa 4: Criar uma aplicação e montar um volume

    Para montar o volume, referencie a PVC na sua aplicação.

    kubectl

    1. Crie um arquivo oss-workload.yaml.

      tmpfile

    2. Crie a aplicação.

      tmpfile

    3. Verifique a montagem.

      • Confirme se os Pods estão em execução.

        tmpfile

      • Acesse um Pod e verifique o ponto de montagem.

        tmpfile

        A saída deve listar os arquivos no caminho de montagem do OSS.

    Console

    1. Na página ACK Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Deployments.

    2. No canto superior direito da página Deployments, clique em Create from Image.

    3. Clique em Create from Image e siga as instruções na tela para configurar os parâmetros da aplicação.

      Os principais parâmetros estão descritos na tabela a seguir. Para os demais parâmetros, utilize os valores padrão. Para mais informações, consulte {{XREF_39}}.

      Página de configuração

      Parâmetro

      Descrição

      Basic Information

      Replicas:

      O número de réplicas de Pod para o Deployment.

      Container

      Nome da imagem

      O endereço da imagem do contêiner para a aplicação, como anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6.

      Required Resources

      A quantidade de vCPU e memória a ser alocada para cada contêiner.

      Volume

      Clique em Add PVC e configure os parâmetros.

      • Mount Source: Selecione a PVC criada anteriormente.

      • Container Path: O caminho dentro do contêiner onde o volume será montado, como /data.

      Labels and Annotations

      Rótulo do Pod

      Por exemplo, defina a chave como 'app' e o valor como 'nginx'.

    4. Verifique o status de implantação da aplicação.

      Na página Deployments, clique no nome da sua aplicação. Na aba Pods, verifique se os Pods apresentam status Running.

    Etapa 5: Verificar armazenamento compartilhado e persistente

    Verificar armazenamento compartilhado

    Para verificar o armazenamento compartilhado, crie um arquivo em um Pod e visualize-o em outro.

    1. Obtenha os nomes dos Pods da aplicação.

      tmpfile

    2. Este exemplo utiliza o Pod oss-workload-66fbb85b67-d****:

      • ReadWriteMany: Crie o arquivo tmpfile no caminho /data.

        tmpfile

      • ReadOnlyMany: Envie o arquivo tmpfile para o caminho correspondente no bucket OSS usando o console OSS ou {{XREF_40}}.

    3. Verifique a presença do arquivo no caminho de montagem de outro Pod.

      Tome como exemplo um Pod chamado oss-workload-66fbb85b67-l**** com o caminho de montagem data.

      tmpfile

      A presença do arquivo na saída confirma que os Pods podem compartilhar dados.

      tmpfile
      Se não visualizar a saída esperada, certifique-se de que a versão do {{XREF_41}} seja v1.20.7 ou posterior.

    Verificar armazenamento persistente

    Para verificar o armazenamento persistente, exclua um Pod e confirme se o arquivo permanece após a recriação automática do Pod.

    1. Exclua um Pod da aplicação. O controlador de Deployment o recriará automaticamente.

      tmpfile

    2. Verifique o status dos Pods. Aguarde até que o novo Pod inicie e fique como Running.

      tmpfile

    3. Visualize os arquivos no caminho /data.

      Este exemplo usa um Pod chamado oss-workload-66fbb85b67-z**** com o caminho de montagem data.

      tmpfile

      A saída mostra que o arquivo tmpfile ainda existe, confirmando que os dados persistem mesmo após a recriação do Pod.

      tmpfile

    Impactos conhecidos

    • Riscos de integridade de dados

      • Risco de consistência em gravações simultâneas: Para melhorar a estabilidade de gravação, recomendamos atualizar o {{XREF_42}} para v1.28 ou posterior. No entanto, em cenários de gravação simultânea em arquivo único, o recurso de "upload por sobrescrita" do OSS ainda pode sobrescrever dados. Garanta a consistência dos dados na camada de aplicação.

      • Risco de sincronização de dados e exclusão acidental: Quando um volume é montado, excluir ou modificar arquivos no caminho de montagem em um Pod de aplicação ou nó host sincroniza essas alterações diretamente com os arquivos de origem no OSS Bucket. Para evitar exclusão acidental de dados, recomendamos ativar {{XREF_43}} para seu OSS Bucket.

    • Riscos de estabilidade da aplicação

      • Risco de OOM: Ao executar uma operação readdir (como o comando ls em um script shell) em um grande número de arquivos (por exemplo, mais de 100.000, dependendo da memória do nó) pela primeira vez, o ossfs carrega todos os metadados de uma vez e consome muita memória. Isso pode causar OOM Killed no processo e tornar o ponto de montagem indisponível.

        Para mitigar esse risco, recomendamos montar um subdiretório do OSS Bucket ou otimizar sua estrutura de diretórios.

      • Tempo de montagem estendido: Configurar securityContext.fsgroup em uma aplicação faz com que o kubelet modifique recursivamente as permissões de arquivo (chmod/chown) ao montar um volume. Se o volume contiver muitos arquivos, o tempo de montagem aumenta significativamente, podendo causar atrasos graves na inicialização do Pod.

        Se precisar configurar este parâmetro, mas quiser reduzir o tempo de montagem, consulte {{XREF_44}}.

      • Risco de invalidação de chave (Autenticação AccessKey): Se um AccessKey referenciado por um PV tornar-se inválido ou suas permissões forem alteradas, a aplicação associada perde o acesso imediatamente.

        Para restaurar o acesso, atualize as credenciais no Secret e reinicie o Pod da aplicação para forçar uma remontagem. Isso causa interrupção do serviço, portanto execute esta operação durante uma janela de manutenção. Para mais informações, consulte {{XREF_45}}.

    • Riscos de custo

      • Custos de partes: Ao enviar arquivos maiores que 10 MB, o ossfs realiza upload multipartido, dividindo o arquivo em partes. Se um upload for interrompido inesperadamente, por exemplo devido à reinicialização da aplicação, você deve {{XREF_46}} ou {{XREF_47}} para evitar custos de armazenamento decorrentes de partes incompletas.

    Liberação de recursos

    1. Excluir cargas de trabalho

      • Ação: Exclua todas as cargas de trabalho, como Deployments e StatefulSets, que usam a PVC. Isso interrompe os Pods e desmonta o volume.

      • Comando de exemplo: kubectl delete deployment &lt;your-deployment-name&gt;

    2. Excluir a PVC

      • Ação: Exclua a PVC. A política de recuperação (reclaimPolicy) para volumes OSS provisionados dinamicamente suporta apenas Retain. Ao excluir a PVC, seu PV vinculado entra no estado Released, e o bucket OSS backend retém totalmente o subdiretório e os dados correspondentes.

      • Comando de exemplo: kubectl delete pvc &lt;your-pvc-name&gt;

    3. Excluir o PV

      • Ação: Exclua o PV no estado Released. Esta operação remove apenas o objeto de recurso PV do Kubernetes e não exclui nenhum dado no bucket OSS backend.

      • Comando de exemplo: kubectl delete pv &lt;your-pv-name&gt;

    4. Excluir a StorageClass e o Secret (opcional)

      • Ação: Exclua a StorageClass e o Secret associado se não forem mais necessários. Esta operação remove apenas os objetos de recurso do Kubernetes e não afeta o bucket OSS backend.

      • Comandos de exemplo: kubectl delete sc &lt;your-storageclass-name&gt;, kubectl delete secret &lt;your-secret-name&gt;

    Documentos relacionados

    • Gerencie volumes OSS usando CNFS para melhorar desempenho e QoS. Para mais informações, consulte {{XREF_48}}.

    • Ative a criptografia no lado do servidor para proteger dados sensíveis em repouso no OSS. Para mais informações, consulte {{XREF_49}}.

    • Para perguntas frequentes sobre ossfs e OSS, consulte {{XREF_50}} e {{XREF_51}}.

    • Ative {{XREF_52}} e configure alertas para detectar prontamente anomalias de volume ou gargalos de desempenho.

    • O ossfs 1.0 oferece consistência de dados mais forte para gravações aleatórias e simultâneas do que {{XREF_53}}. No entanto, o ossfs 2.0 oferece melhor desempenho para leituras e gravações sequenciais.