Configurar o armazenamento conectado do Distributed Cloud

Esta página descreve como configurar o armazenamento para clusters conectados do Distributed Cloud, incluindo:

Configurar o Distributed Cloud conectado para o armazenamento do Symcloud

Os nós conectados do Distributed Cloud não expõem o armazenamento local diretamente às cargas de trabalho. Em vez disso, o Distributed Cloud conectado usa o armazenamento do Rakuten Symcloud, que é uma solução de terceiros que atua como uma camada de abstração de armazenamento local executada em cada nó conectado do Distributed Cloud e disponibiliza o armazenamento local para cargas de trabalho executadas em todos os nós conectados do Distributed Cloud em um cluster.

Container Storage Interface (CSI) é uma API padrão aberta compatível com os principais fornecedores de armazenamento que permite ao Kubernetes expor sistemas de armazenamento arbitrários a cargas de trabalho em contêineres. No Distributed Cloud conectado, o armazenamento do Symcloud é a solução de armazenamento CSI compatível e gerenciada. Quando o armazenamento do Symcloud é ativado, as StorageClasses StorageClasses necessárias do Kubernetes são configuradas para você. Em seguida, é possível configurar as cargas de trabalho para usar a classe de armazenamento apropriada.

O armazenamento do Symcloud é implantado no Google Cloud Marketplace e está sujeito aos termos declarados nele. O Google oferece suporte limitado para o uso do armazenamento do Symcloud com o Distributed Cloud conectado e pode envolver o provedor de terceiros para receber assistência. As atualizações de software para o armazenamento do Symcloud estão incluídas nas atualizações de software do Distributed Cloud conectado.

Esta versão do Distributed Cloud conectado é fornecida com o armazenamento do Symcloud 6.0.0-226 e oferece suporte a ele . Nenhuma outra versão do armazenamento do Symcloud é compatível com esta versão do Distributed Cloud conectado.

Receber uma licença de armazenamento do Symcloud

É necessário receber uma licença de armazenamento do Symcloud no formato YAML do Google Cloud Marketplace:

Acessar o Marketplace

Pré-requisitos

Antes de começar, conclua as etapas a seguir:

  1. Configure a geração de registros e o monitoramento do projeto de destino do Distributed Cloud conectado.
  2. Crie o cluster de destino do Distributed Cloud conectado. É possível monitorar o progresso do provisionamento.
  3. Configure a rede do Distributed Cloud para que os pods no cluster de destino do Distributed Cloud conectado possam acessar o Google Cloud data center.
  4. Vincule cada volume permanente local-block em cada nó do Distributed Cloud que você não quer que seja abstraído pelo armazenamento do Symcloud. Se você desvincular um volume permanente local-block vinculado, a instalação do armazenamento do Symcloud vai apagar o conteúdo desse volume permanente. Para instruções, consulte Vinculação na documentação do Kubernetes.

Instalar o armazenamento do Symcloud em um nó conectado do Distributed Cloud

Para instalar o armazenamento do Symcloud em um nó conectado do Distributed Cloud, siga estas etapas:

  1. Use o comando a seguir para aplicar a licença de armazenamento do Symcloud ao cluster. Substitua LICENSE_FILE pelo caminho completo e o nome do arquivo de licença de armazenamento do Symcloud.

    kubectl apply -f LICENSE_FILE -n robin-admin

  2. Use o comando a seguir para verificar o status do serviço RobinCluster e de todos os nós de armazenamento do Symcloud:

    kubectl describe robinclusters -n robinio

    O comando retorna uma saída semelhante a esta:

    [...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]

    O status esperado para o serviço e os nós é Ready.

Definir o armazenamento do Symcloud como a classe de armazenamento padrão

Use o comando a seguir para definir o armazenamento do Symcloud como a classe de armazenamento padrão no cluster conectado do Distributed Cloud. Substitua STORAGE_CLASS por uma das classes de armazenamento do Symcloud.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Para mais informações sobre como definir a classe de armazenamento padrão, consulte Alterar o StorageClass padrão na documentação do Kubernetes.

Classes de armazenamento do Symcloud

Esta seção descreve as classes de armazenamento que o armazenamento do Symcloud pode ativar no cluster conectado do Distributed Cloud. O armazenamento do Symcloud no Distributed Cloud conectado não oferece suporte à classe de armazenamento robin-rwx nem a volumes de modo de sistema de arquivos RWX configurados de maneira personalizada. Para mais informações sobre as classes de armazenamento do Symcloud, consulte Como usar o Robin CNS no Kubernetes.

Classe de armazenamento robin

A classe de armazenamento robin é uma classe de armazenamento básica de leitura e gravação única (RWO, na sigla em inglês). O exemplo a seguir ilustra a instanciação da classe:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Classe de armazenamento robin-immediate

A classe de armazenamento robin-immediate é igual a robin, exceto que o volume permanente é criado imediatamente após a criação da declaração de volume permanente correspondente. O exemplo a seguir ilustra a instanciação da classe:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

Classe de armazenamento robin-repl-3

A robin-repl-3 é uma classe de armazenamento RWO com três réplicas que abrangem vários nós conectados do Distributed Cloud. O exemplo a seguir ilustra a instanciação da classe:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

Configurar volumes de armazenamento do Symcloud abstraídos para cargas de trabalho

Esta seção fornece exemplos de como usar classes de armazenamento do Symcloud para configurar o armazenamento abstraído para cargas de trabalho conectadas do Distributed Cloud. Para mais detalhes sobre como configurar volumes de armazenamento do Symcloud, consulte Como usar o Robin CNS no Kubernetes.

Configurar um volume RWO ext4 no modo de sistema de arquivos

O exemplo a seguir ilustra como configurar uma declaração de volume permanente para um volume RWO no modo de sistema de arquivos com o sistema de arquivos ext4. Substitua STORAGE_CLASS por uma das classes de armazenamento do Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Configurar um volume RWO no modo de bloco

O exemplo a seguir ilustra como configurar uma declaração de volume permanente para um volume RWO no modo de bloco. Substitua STORAGE_CLASS por uma das classes de armazenamento do Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

Modificar a configuração de um volume atual

O exemplo a seguir ilustra como modificar a configuração de um volume RWO compactado LZ4 de armazenamento do Symcloud usando anotações. Substitua STORAGE_CLASS por uma das classes de armazenamento do Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

O exemplo a seguir ilustra como modificar a configuração de um volume RWO de armazenamento do Symcloud com o sistema de arquivos xfs usando anotações. Substitua STORAGE_CLASS por uma das classes de armazenamento do Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Configurar o cliente da CLI de armazenamento do Symcloud

O armazenamento do Symcloud oferece um cliente de interface de linha de comando (CLI) que pode ser usado para gerenciar a configuração do armazenamento do Symcloud. Para configurar o cliente no cluster conectado do Distributed Cloud, siga estas etapas:

  1. Receba o caminho da imagem de armazenamento do Symcloud usado pela instância de serviço RobinCluster implantada no cluster conectado do Distributed Cloud e defina as variáveis de ambiente da seguinte maneira:

    image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

  2. Crie um recurso robincli com o seguinte conteúdo:

    kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

    Substitua ROBIN_CNS_IMAGE pelo caminho completo do repositório e o nome da imagem que você recebeu na etapa 1.

  3. Aplique o recurso robincli ao cluster conectado do Distributed Cloud.

  4. Na instalação inicial, o armazenamento do Symcloud gera um secret default-admin-user no namespace robinio com uma senha aleatória. Use os comandos a seguir para receber essas credenciais de login:

    1. Receber o nome de usuário:

      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d

    2. Receber a senha:

       
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d

  5. Faça login no pod recém-criado e execute o cliente:

    kubectl exec -it robincli -- bash

Referenciar a classe de armazenamento em um StatefulSet

O exemplo a seguir mostra como referenciar uma classe de armazenamento do Symcloud em uma StatefulSet.

O exemplo pressupõe que você esteja usando a classe de armazenamento robin-repl-3 pré-configurada, que fornece volumes replicados em três nós de worker distintos para alta disponibilidade.

Ao configurar um StatefulSet para alta disponibilidade, inclua as práticas recomendadas a seguir na configuração:

  • Serviço headless: um StatefulSet exige um serviço headless complementar que corresponda ao campo serviceName. Um serviço headless é um serviço com clusterIP: None. Esse serviço atribui nomes de host DNS estáveis a cada pod no conjunto.
  • Antiafinidade de pods: se você usar uma classe de armazenamento replicada como robin-repl-3, seus dados serão espelhados com segurança em vários nós de worker. No entanto, se o Kubernetes escalonar todos os pods do aplicativo no mesmo nó de trabalho, uma única interrupção do nó poderá derrubar o aplicativo. A configuração da antiafinidade de pods garante que os pods sejam distribuídos em nós de worker separados, correspondendo à disponibilidade de computação à redundância de armazenamento.

O exemplo a seguir demonstra uma configuração completa que inclui o serviço headless (nginx) e um StatefulSet configurado com antiafinidade de pods que referencia a classe de armazenamento robin-repl-3. Se os requisitos de armazenamento da carga de trabalho aumentarem com o tempo, será possível redimensionar o volume de maneira dinâmica editando a solicitação de armazenamento na PersistentVolumeClaim.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

Limitações do armazenamento do Symcloud

Ao usar o armazenamento do Symcloud com o Distributed Cloud conectado, só é possível alcançar alta disponibilidade se o cluster conectado do Distributed Cloud consistir em três ou mais nós conectados do Distributed Cloud.

Remover nós que usam o armazenamento do Symcloud de um cluster

As réplicas de volume de armazenamento do Symcloud são armazenadas em nós de worker no cluster conectado do Distributed Cloud. Se você remover um nó do cluster, os dados de volume de armazenamento do Symcloud armazenados nesse nó ficarão indisponíveis. Para evitar isso, faça uma das seguintes ações:

  • Se você estiver desativando todo o cluster, remova as cargas de trabalho e os volumes permanentes de armazenamento do Symcloud correspondentes antes de desativar o cluster.
  • Se você estiver removendo nós específicos do cluster, migre os dados da carga de trabalho armazenados nesses nós antes de remover esses nós do cluster. Para instruções, consulte Como evacuar volumes de um disco.

Configurar esquemas de armazenamento local

Um esquema de armazenamento é um agrupamento lógico de uma ou mais partições. Cada partição é uma unidade de armazenamento logicamente independente. As partições são criadas no cluster sequencialmente até que o espaço físico em disco seja esgotado. Cada esquema de armazenamento tem um nome exclusivo que o identifica.

Para criar um novo esquema de armazenamento local para o cluster conectado do Distributed Cloud, é necessário solicitá-lo ao Google. Depois que testarmos o esquema e o criarmos no cluster, será possível aplicá-lo usando a CLI gcloud.

Não é possível modificar um esquema depois que ele é aplicado a um cluster. Para mudar um esquema atual, é necessário solicitar a exclusão do esquema atual do Google e, em seguida, solicitar a criação de um novo esquema para substituí-lo.

Definir partições para um esquema de armazenamento local

Antes de solicitar um esquema de armazenamento local, é necessário definir as partições desse esquema.

Uma partição tem as seguintes propriedades:

  • Tamanho. É possível especificar um tamanho de partição em bytes binários ou usar todo o espaço restante no disco local.
  • Tipo. É possível configurar uma partição como um volume permanente (PV) do Kubernetes ou um volume local do Linux no disco local.
  • Modo. É possível configurar o volume armazenado na partição como um volume de bloco ou um volume de sistema de arquivos. Para partições de volume permanente, a classe de armazenamento da partição é local-block ou local-disks, respectivamente. Para partições de volume local, é possível especificar os pontos de vinculação e montagem para os sistemas de arquivos contidos.

Solicitar um esquema de armazenamento local

Para solicitar um novo esquema de armazenamento local para o cluster conectado do Distributed Cloud, entre em contato com o suporte do Google e forneça o tamanho, o tipo, o modo e, opcionalmente, os pontos de montagem e vinculação para cada partição que você quer criar no esquema.

Quando recebemos sua solicitação, executamos uma série de testes para garantir a robustez do esquema e, em seguida, o criamos no cluster conectado do Distributed Cloud.

Esquemas de armazenamento local padrão

O Distributed Cloud conectado é fornecido com os seguintes esquemas de armazenamento local padrão:

  • default_control_plane_node. Esse esquema define as seguintes partições:

    • Uma partição de volume local de 100 GB no modo de sistema de arquivos.
    • Uma partição de volume permanente no modo de bloco que ocupa o espaço livre restante no disco.

  • default_worker_node. Esse esquema define uma partição de volume permanente de 410 GB no modo de bloco.

Aplicar um esquema de armazenamento local a um cluster

Para aplicar um esquema de armazenamento local ao cluster conectado do Distributed Cloud, faça uma das seguintes ações:

  • Para aplicar um esquema de armazenamento local aos nós do plano de controle do cluster, use a flag --control-plane-node-storage-schema ao criar o cluster. Para mais informações, consulte Criar um cluster.

  • Para aplicar um esquema de armazenamento local aos nós de worker do cluster, use --node-storage-schema ao criar um pool de nós para o cluster. Para mais informações, consulte Criar um pool de nós.

O Distributed Cloud conectado cria as partições definidas no esquema de armazenamento local após a criação do cluster ou do pool de nós.

Solução de problemas

Se as PersistentVolumeClaims permanecerem pendentes de maneira inesperada ou as cargas de trabalho não conseguirem anexar volumes, siga as etapas de solução de problemas listadas nesta seção.

As PersistentVolumeClaims permanecem pendentes

Se as PersistentVolumeClaims permanecerem no estado Pending, verifique o volumeBindingMode da classe de armazenamento. As classes de armazenamento do Symcloud pré-configuradas usam volumeBindingMode: WaitForFirstConsumer, o que atrasa o provisionamento de volume até que o pod que referencia a declaração seja programado. Verifique se o pod da carga de trabalho foi programado.

Se a programação do pod estiver concluída, mas a declaração permanecer pendente ou se a anexação do volume falhar, verifique a integridade do plano de controle de armazenamento do Symcloud e dos daemons no nível do nó.

Verificar a integridade do plano de controle

Para verificar se o plano de controle de armazenamento do Symcloud está íntegro e pronto para provisionar volumes, execute o kubectl describe comando para verificar o status do recurso personalizado RobinCluster:

kubectl describe robinclusters -n robinio

Na resposta ao comando, verifique se Phase é Ready.

Verificar a integridade do daemon de armazenamento

Para verificar se todos os pods de daemon de armazenamento no nível do nó estão em execução, execute o kubectl get comando:

kubectl get pods -n robinio

Na resposta ao comando, verifique se todos os pods estão no estado Running. Se uma carga de trabalho for programada em um nó com um pod de daemon de armazenamento com falha, a anexação de volume será suspensa, independentemente do status central do RobinCluster.

Entrar em contato com o suporte

Se o status do plano de controle de armazenamento do Symcloud não for Ready ou se algum pod de daemon de armazenamento não estiver no estado Running, entre em contato com o suporte do Google. Ao abrir um tíquete de suporte, forneça as saídas dos comandos de solução de problemas executados.