One place for hosting & domains

      persistentes

      Como configurar os volumes persistentes ReadWriteMany (RWX) com NFS no Kubernetes da DigitalOcean


      Introdução

      Devido à natureza distribuída e dinâmica dos contêineres, gerenciar e configurar o armazenamento de maneira estática se transformou em um problema no Kubernetes, uma vez que agora as cargas de trabalho conseguem mover-se de uma máquina virtual (VM) para outra em questão de segundos. Para lidar com a questão, o Kubernetes gerencia os volumes com um sistema de Persistent Volumes (PV) (volumes persistentes), objetos de API que representam uma configuração de armazenamento/volume e de PersistentVolumeClaims (PVC), uma solicitação por armazenamento atendida por um volume persistente. Além disso, drivers da Interface de Armazenamento de Contêiner (CSI) podem ajudar a automatizar e gerenciar o manuseamento e fornecimento de armazenamento para cargas de trabalho em contêiner. Esses drivers são responsáveis pelo fornecimento, montagem, desmontagem, remoção e serviços de instantâneo de volumes.

      O digitalocean-csi integra um cluster do Kubernetes com o produto armazenamento em bloco da DigitalOcean. Um desenvolvedor pode usar isso para fornecer volumes de armazenamento de bloco dinamicamente para aplicativos em contêiner no Kubernetes. No entanto, os aplicativos podem, por vezes, exigir que dados sejam mantidos e partilhados por vários Droplets. A solução padrão CSI de armazenamento em bloco da DigitalOcean não consegue suportar a montagem de um volume de armazenamento de bloco em muitos Droplets simultaneamente. Isso significa que esta é uma solução ReadWriteOnce (RWO) (Ler e escrever uma vez), uma vez que o volume é limitado a um nó. O protocolo de Sistema de Arquivos de Rede (NFS), por outro lado, dá suporte à exportação da mesma quantidade a muitos consumidores. Isso se chama ReadWriteMany (RWX) (Ler e escrever muitos), pois muitos nós podem montar o volume como leitura-gravação. Assim, podemos usar um servidor NFS dentro do nosso cluster para fornecer armazenamento que pode potencializar o suporte confiável do armazenamento em bloco da DigitalOcean com a flexibilidade das quantidades do NFS.

      Neste tutorial, você irá configurar o fornecimento dinâmico de volumes NFS dentro de um cluster DigitalOcean Kubernetes (DOKS) no qual as exportações são armazenadas em volumes de armazenamento em bloco da DigitalOcean. Em seguida, implantará várias instâncias de um aplicativo de demonstração Nginx e testará o compartilhamento de dados entre cada instância.

      Pré-requisitos

      Antes de iniciar este guia, você precisará do seguinte:

      Nota: a partir da versão 3.0 do Helm, o Tiller já não precisa estar instalado para que o Helm funcione. Caso esteja usando a versão mais recente do Helm, consulte a documentação de instalação do Helm para obter instruções.

      Para implantar o servidor NFS, você usará um gráfico do Helm. Comparada à implantação manual do servidor NFS, a implantação de um gráfico do Helm se apresenta como uma solução automatizada mais rápida e menos suscetível a erros.

      Primeiro, certifique-se de que o repositório padrão de gráficos stable esteja disponível para você, adicionando o repo:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com/

      Em seguida, puxe os metadados para o repositório que acabou de adicionar. Isso garantirá que o cliente do Helm esteja atualizado:

      Para verificar o acesso ao repo stable, execute uma pesquisa nos gráficos:

      Isso dará a você a lista de gráficos disponíveis, semelhante a esta:

      Output

      NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes stable/airflow 5.2.4 1.10.4 Airflow is a platform to programmatically autho... stable/ambassador 5.3.0 0.86.1 A Helm chart for Datawire Ambassador ...

      Esse resultado significa que seu cliente do Helm está em execução e atualizado.

      Agora que o Helm está configurado, instale o gráfico do Helm nfs-server-provisioner para configurar o servidor NFS. Caso queira examinar o conteúdo do gráfico, consulte sua documentação no GitHub.

      Quando implantar o gráfico do Helm, você vai definir algumas variáveis para seu servidor NFS para especificar ainda mais a configuração do seu aplicativo. Você também pode investigar outras opções de configuração e ajustá-las para se adequarem às necessidades do aplicativo.

      Para instalar o gráfico do Helm, use o seguinte comando:

      • helm install nfs-server stable/nfs-server-provisioner --set persistence.enabled=true,persistence.storageClass=do-block-storage,persistence.size=200Gi

      Esse comando provisiona o servidor NFS com as seguintes opções de configuração:

      • Adiciona um volume persistente ao servidor NFS com o sinalizador --set. Isso garante que todos os dados do NFS compartilhados permaneçam nas reinicializações do pod.
      • Para o armazenamento persistente, usa a classe de armazenamento do-block-storage.
      • Provisiona um total de 200 Gi para que o servidor NFS consiga dividir em exportações.

      Nota: a opção persistence.size determinará a capacidade total de todos os volumes NFS que você pode provisionar. No momento em que este artigo foi publicado, apenas a versão 1.16.2-do.3 e posteriores do DOKS ofereciam suporte à expansão de volumes. Dessa maneira, se você estiver usando uma versão mais antiga do DOKS, o redimensionamento desse volume terá que ser feito manualmente. Caso seja esse o caso, certifique-se de definir esse tamanho levando em conta suas necessidades futuras.

      Depois que esse comando terminar, você receberá um resultado semelhante ao seguinte:

      Output

      NAME: nfs-server LAST DEPLOYED: Thu Feb 13 19:30:07 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The NFS Provisioner service has now been installed. A storage class named 'nfs' has now been created and is available to provision dynamic volumes. You can use this storageclass by creating a PersistentVolumeClaim with the correct storageClassName attribute. For example: --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-dynamic-volume-claim spec: storageClassName: "nfs" accessModes: - ReadWriteOnce resources: requests: storage: 100Mi

      Para ver o servidor NFS que você provisionou, execute o seguinte comando:

      Isso mostrará o seguinte:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 11m

      Em seguida, verifique a storageclass que você criou:

      Isso dará um resultado parecido com este:

      Output

      NAME PROVISIONER AGE do-block-storage (default) dobs.csi.digitalocean.com 90m nfs cluster.local/nfs-server-nfs-server-provisioner 3m

      Agora, você tem um servidor NFS em execução, bem como uma storageclass que pode usar para o provisionamento dinâmico de volumes. Em seguida, você poderá criar uma implantação que usará esse armazenamento, compartilhando-a em múltiplas instâncias.

      Passo 2 — Implantando um aplicativo usando um PersistentVolumeClaim compartilhado

      Neste passo, você criará uma implantação de exemplo no seu cluster DOKS para testar sua configuração de armazenamento. A implantação será a de um app de servidor Web Nginx chamado web.

      Para implantar esse aplicativo, primeiro grave o arquivo YAML para especificar a implantação. Abra um arquivo nginx-test.yaml com seu editor de texto; este tutorial usará o nano:

      Neste arquivo, adicione as linhas a seguir para definir a implantação com um PersistentVolumeClaim chamado nfs-data:

      nginx-test.yaml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: web
        name: web
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: web
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              name: nginx
              resources: {}
              volumeMounts:
              - mountPath: /data
                name: data
            volumes:
            - name: data
              persistentVolumeClaim:
                claimName: nfs-data
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: nfs-data
      spec:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 2Gi
        storageClassName: nfs
      

      Salve o arquivo e saia do editor de texto.

      Essa implantação (web) foi configurada para usar o nfs-data do PersistentVolumeClaim (PVC) que a acompanha e para montá-la em /data.

      Na definição do PVC, você descobrirá que o storageClassName está definido como nfs. Isso diz ao cluster para atender esse armazenamento, usando as regras de storageClass nfs que você criou no passo anterior. O novo PersistentVolumeClaim será processado e, em seguida, um compartilhamento NFS será provisionado para atender à solicitação e à declaração, na forma de um Volume Persistente. O pod tentará montar aquele PVC assim que ele tiver sido provisionado. Assim que terminar a montagem, você verificará a funcionalidade ReadWriteMany (RMX).

      Execute a implantação com o seguinte comando:

      • kubectl apply -f nginx-test.yaml

      Isso dará o seguinte resultado:

      Output

      deployment.apps/web created persistentvolumeclaim/nfs-data created

      Em seguida, verifique e veja o pod web em funcionamento:

      Isso irá mostrar o seguinte:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 23m web-64965fc79f-b5v7w 1/1 Running 0 4m

      Agora que a implantação de exemplo está em funcionamento, você pode dimensioná-la para três instâncias, usando o comando kubectl scale:

      • kubectl scale deployment web --replicas=3

      Isso dará o resultado:

      Output

      deployment.extensions/web scaled

      Agora, execute o kubectl get novamente:

      Você encontrará as instâncias dimensionadas da implantação:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 24m web-64965fc79f-q9626 1/1 Running 0 5m web-64965fc79f-qgd2w 1/1 Running 0 17s web-64965fc79f-wcjxv 1/1 Running 0 17s

      Agora, você tem três instâncias da sua implantação do Nginx, conectadas ao mesmo Volume Persistente. No próximo passo, você irá garantir que elas possam compartilhar dados entre si.

      Passo 3 — Validando o compartilhamento de dados do NFS

      No passo final, você validará a configuração para que os dados sejam compartilhados por todas as instâncias que foram montadas para o compartilhamento do NFS. Para fazer isso, criará um arquivo no diretório /data em um dos pods e, em seguida, verificará se o arquivo existe no diretório /data de outro pod.

      Para validar isso, você usará o comando kubectl exec. Esse comando permite que você especifique um pod e execute um comando dentro daquele pod. Para aprender mais sobre a inspeção de recursos usando o kubectl, veja nossa Folha de referências do kubectl.

      Para criar um arquivo chamado hello_world dentro de um dos seus pods web, use o kubectl exec para repassar o comando touch. Note que o número após web – no nome do pod – será diferente para você. Assim, certifique-se de substituir o nome do pod destacado por um dos pods que você apurou no resultado do comando kubectl get pods, no último passo.

      • kubectl exec web-64965fc79f-q9626 -- touch /data/hello_world

      Em seguida, altere o nome do pod e use o comando ls para listar os arquivos no diretório /data de um outro pod:

      • kubectl exec web-64965fc79f-qgd2w -- ls /data

      Seu resultado mostrará o arquivo que criou no primeiro pod:

      Output

      hello_world

      Isso mostra que todos os pods compartilham dados usando o NFS e que sua configuração está funcionando corretamente.

      Conclusão

      Neste tutorial, você criou um servidor NFS com apoio do armazenamento em bloco da DigitalOcean. Depois, o servidor NFS usou aquele armazenamento em bloco para provisionar e exportar os compartilhamentos NFS para as cargas de trabalho em um protocolo compatível com RWX. Ao fazer isso, você conseguiu contornar uma limitação técnica do armazenamento em bloco da DigitalOcean e compartilhar os mesmos dados do PVC em muitos pods. Por seguir este tutorial, agora o seu cluster DOKS está configurado para acomodar um conjunto muito mais amplo de casos de uso de implantação.

      Caso queira aprender mais sobre o Kubernetes, confira nosso Currículo de Kubernetes para desenvolvedores full-stack, ou examine a documentação de produto do Kubernetes da DigitalOcean.



      Source link

      Cómo configurar volúmenes persistentes de ReadWriteMany (RWX) con NFS en Kubernetes de DigitalOcean


      Introducción

      Con la naturaleza distribuida y dinámica de los contenedores, la administración y configuración estática de almacenamiento se ha convertido en un problema complejo en Kubernetes, porque las cargas de trabajo ahora pueden moverse de una máquina virtual (VM) a otra en cuestión de segundos. Para abordar esto, Kubernetes administra los volúmenes con un sistema de volúmenes persistentes (PV), objetos API que representan una configuración y un volumen de almacenamiento, y PersistentVolumeClaims (PVC), una solicitud de almacenamiento que debe satisfacerse a través de un volumen persistente. Además, los controladores de Container Storage Interface (CSI) pueden ayudar automatizar y administrar la gestión y el aprovisionamiento de almacenamiento para cargas de trabajo en contenedores. Estos controladores se encargan de aprovisionar, montar y desmontar volúmenes, eliminarlos y realizar capturas de ellos.

      La digitalocean-csi integra un clúster de Kubernetes con el producto Block Storage de Digital Ocean. Un desarrollador puede usar esto para proporcionar volúmenes de Block Storage de forma dinámica para aplicaciones en contenedores en Kubernetes. Sin embargo, las aplicaciones a veces requieren que los datos persistan y se compartan entre varios Droplets. La solución Block Storage CSI predeterminada de DigitalOcean no puede admitir el montaje de un volumen de almacenamiento en bloque en muchos Droplets al mismo tiempo. Esto significa que esta es una solución ReadWriteOnce (RWO), ya que el volumen se limita a un nodo. El protocolo Network File System (NFS), por otro lado, sí admite la exportación del mismo intercambio a muchos consumidores. Esto se denomina ReadWriteMany (RWX), porque muchos nodos pueden montar el volumen con atributos de lectura y escritura. Por lo tanto, podemos usar un servidor NFS en nuestro clúster para proporcionar almacenamiento que pueda aprovechar el respaldo fiable de DigitalOcean Block Storage con la flexibilidad de los intercambios NFS.

      En este tutorial, configurará el aprovisionamiento dinámico para volúmenes NFS en un clúster DigitalOcean Kubernetes (DOKS) en el cual las exportaciones se almacenan en volúmenes de almacenamiento de DigitalOcean Block. A continuación, implementará varias instancias de una aplicación Nginx de demostración y probará el intercambio de datos entre cada instancia.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • La interfaz de línea de comandos kubectl instalada en su computadora local. Puede obtener más información sobre cómo instalar y configurar kubectl en su documentación oficial.

      • Un clúster de Kubernetes de DigitalOcean con su conexión configurada como kubectl predeterminado. Para crear un clúster de Kubernetes en DigitalOcean, consulte nuestra Guía rápida de Kubernetes. Verá las instrucciones para configurar kubectl en el paso *Establecer conexión con su clúster *cuando cree su clúster.

      • El administrador de paquetes de Helm instalado en su computadora local y Tiller instalado en su clúster. Para hacerlo, complete los pasos 1 y 2 del tutorial Cómo instalar software en clústeres de Kubernetes con el administrador de paquetes de Helm.

      Nota: Al empezar con Helm versión 3.0, no será necesario que Tiller esté instalado para que Helm funcione. Si usa la versión más reciente de Helm, consulte la documentación para la instalación de Helm para hallar instrucciones.

      Paso 1: Implementar el servidor NFS con Helm

      Para implementar el servidor NFS, usará un gráfico de Helm. La implementación de un gráfico de Helm es una solución automatizada que es más rápida y está menos expuesta a errores si se compara con la creación manual de la implementación de un servidor NFS.

      Primero, asegúrese de que el respositorio de gráficos predeterminado stable esté disponible añadiéndolo:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com/

      A continuación, extraiga los metadatos del repositorio que acaba de añadir. Esto garantizará que el cliente de Helm está actualizado:

      Para verificar el acceso al repositorio stable, realice una búsqueda en los gráficos:

      Esto le proporcionará una lista de gráficos disponibles similar a la siguiente:

      Output

      NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes stable/airflow 5.2.4 1.10.4 Airflow is a platform to programmatically autho... stable/ambassador 5.3.0 0.86.1 A Helm chart for Datawire Ambassador ...

      Este resultado implica que su cliente de Helm se encuentra en ejecución y está actualizado.

      Ahora que configuró Helm, instale el gráfico de Helm nfs-server-provisioner para configurar el servidor NFS. Si desea examinar el contenido del gráfico, eche un vistazo a la documentación en GitHub.

      Cuando implemente el gráfico de Helm, establecerá algunas variables para su servidor NFS a fin de especificar la configuración de su aplicación. También puede investigar otras opciones de configuración y adaptarlas para que se ajusten a las necesidades de la aplicación.

      Para instalar el gráfico de Helm, utilice el siguiente comando:

      • helm install nfs-server stable/nfs-server-provisioner --set persistence.enabled=true,persistence.storageClass=do-block-storage,persistence.size=200Gi

      Este comando proporciona un servidor NFS con las siguientes opciones de configuración:

      • Añade un volumen persistente para el servidor NFS con el indicador --set. Esto garantiza que todos los datos compartidos de NFS persistan al reiniciarse el pod.
      • Para el almacenamiento persistente, utiliza la clase de almacenamiento do-block-storage.
      • Proporciona un total de 200Gi para que el servidor NFS pueda dividir exportaciones.

      Nota: La opción persistence.size determinará la capacidad total de todos los volúmenes NFS que puede proporcionar. En el momento en que se realizó esta publicación, solo DOKS 1.16.2-do.3 y las versiones posteriores eran compatibles con la expansión de volumen, de modo que la tarea de cambiar el tamaño de este volumen se deberá realizar manualmente si usa una versión anterior. Si este es el caso, asegúrese de establecer este tamaño teniendo en cuenta sus necesidades futuras.

      Una vez que este comando se aplique, verá un resultado similar al siguiente:

      Output

      NAME: nfs-server LAST DEPLOYED: Thu Feb 13 19:30:07 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The NFS Provisioner service has now been installed. A storage class named 'nfs' has now been created and is available to provision dynamic volumes. You can use this storageclass by creating a PersistentVolumeClaim with the correct storageClassName attribute. For example: --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-dynamic-volume-claim spec: storageClassName: "nfs" accessModes: - ReadWriteOnce resources: requests: storage: 100Mi

      Para ver el servidor NFS que proporcionó, ejecute el siguiente comando:

      Con esto, se mostrará lo siguiente:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 11m

      A continuación, busque el storageclass que creó:

      Con esto, se mostrará un resultado similar al siguiente:

      Output

      NAME PROVISIONER AGE do-block-storage (default) dobs.csi.digitalocean.com 90m nfs cluster.local/nfs-server-nfs-server-provisioner 3m

      Ahora, dispondrá de un servidor NFS en ejecución y un storageclass que puede usar para el aprovisionamiento dinámico de volúmenes. A continuación, puede crear una implementación que usará este almacenamiento y lo compartirá entre varias instancias.

      Paso 2: Implementar una aplicación usando un PersistentVolumeClaim compartido

      A través de este paso, creará una implementación de ejemplo en su clúster DOKS para probar la configuración de su almacenamiento. Esta será una aplicación de servidor web de Nginx llamada web.

      Para implementar esta aplicación, primero escriba el archivo YAML a fin de especificar la implementación. Abra un archivo nginx-test.yaml con su editor de texto; en este tutorial se usará nano:

      En este archivo, añada las siguientes líneas para definir la implementación con un PersistentVolumeClaim llamado nfs-data:

      nginx-test.yaml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: web
        name: web
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: web
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              name: nginx
              resources: {}
              volumeMounts:
              - mountPath: /data
                name: data
            volumes:
            - name: data
              persistentVolumeClaim:
                claimName: nfs-data
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: nfs-data
      spec:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 2Gi
        storageClassName: nfs
      

      Guarde el archivo y salga del editor de texto.

      Esta implementación se configura para usar el PersistentVolumeClaim nfs-data y montarlo en /data.

      En la definición de PVC, verá que el valor de storageClassName es nfs. Esto indica al clúster que satisfaga este almacenamiento usando las reglas de nfs storageClass que creó en el paso anterior. Se procesará el nuevo PersistentVolumeClaim y luego se proporcionará un intercambio NFS para satisfacer la instrucción en forma de volumen persistente. El pod intentará montar ese PVC una vez que se haya proporcionado. Cuando finalice el montaje, verificará la funcionalidad ReadWriteMany (RWX).

      Ejecute la implementación con el siguiente comando:

      • kubectl apply -f nginx-test.yaml

      Esto generará el siguiente resultado:

      Output

      deployment.apps/web created persistentvolumeclaim/nfs-data created

      A continuación, compruebe que el pod web esté girando:

      Esto dará el siguiente resultado:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 23m web-64965fc79f-b5v7w 1/1 Running 0 4m

      Ahora que la implementación de ejemplo está activa y funcionando, puede escalarla a tres instancias usando el comando kubectl scale:

      • kubectl scale deployment web --replicas=3

      Esto generará el siguiente resultado:

      Output

      deployment.extensions/web scaled

      Ahora, ejecute el comando kubectl get de nuevo:

      Encontrará las instancias escaladas de la implementación:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 24m web-64965fc79f-q9626 1/1 Running 0 5m web-64965fc79f-qgd2w 1/1 Running 0 17s web-64965fc79f-wcjxv 1/1 Running 0 17s

      Con esto, dispondrá de tres instancias de su implementación Nginx conectadas en el mismo Volumen persistente. En el siguiente paso, se asegurará de que puedan compartir datos entre ellas.

      Paso 3: Validar el intercambio de datos de NFS

      Para el paso final, validará el intercambio de datos entre todas las instancias montadas en el intercambio de NFS. Para hacer esto, creará un archivo en el directorio /data en uno de los pods, y luego verificará que exista en el directorio /data de otro pod.

      Para validar esto, usará el comando kubectl exec. Este comando le permite especificar un pod y luego aplicar un comando dentro de él. Para obtener más información sobre cómo inspeccionar recursos usando kubectl, vea nuestra ficha de ayuda de kubectl.

      Si desea crear un archivo llamado hello_world en uno de sus pods web, utilice kubectl exec para pasar el comando touch. Tenga en cuenta que el número después de web en el nombre del pod será diferente para usted. Por lo tanto, asegúrese de sustituir el nombre resaltado del pod por uno de sus propios pods que encontró en el resultado de kubectl get pods del último paso.

      • kubectl exec web-64965fc79f-q9626 -- touch /data/hello_world

      A continuación, cambie el nombre del pod y utilice el comando ls para listar los archivos en el directorio /data de un pod diferente:

      • kubectl exec web-64965fc79f-qgd2w -- ls /data

      Su resultado mostrará el archivo que creó en el primer pod:

      Output

      hello_world

      Esto muestra que todos los pods comparten datos usando NFS y que su configuración funciona correctamente.

      Conclusión

      A lo largo de este tutorial, creó un servidor NFS respaldado por DigitalOcean Block Storage. El servidor NFS luego usó ese almacenamiento en bloque para proporcionar y exportar intercambios de NFS a cargas de trabajo en un protocolo compatible con RWX. Al hacer esto, pudo solventar una limitación técnica del almacenamiento en bloque de DigitalOcean y compartir los mismos datos de PVC en muchos pods. Una vez completado este tutorial, su clúster DOKS quedará configurado para contemplar un conjunto mucho más amplio de casos de uso de implementación.

      Si desea obtener más información sobre Kubernetes, vea nuestro programa de Kubernetes para desarrolladores “full-stack” o consulte la documentación del producto para Kubernetes de DigitalOcean.



      Source link