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.

Como 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. Soluções de armazenamento definido por software (SDS, na sigla em inglês), como o armazenamento do Symcloud, têm como destino dispositivos de bloco brutos local-block não vinculados. O Distributed Cloud conectado espera que uma solução de SDS seja instalada na criação do cluster quando dispositivos local-block não vinculados estiverem disponíveis.

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 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 fornece 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. Receba o nome de usuário:

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

    2. Receba 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 trabalho 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 requer 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, os dados serão espelhados com segurança em vários nós de trabalho. No entanto, se o Kubernetes programar 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 trabalho 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, você poderá redimensionar o volume de maneira dinâmica editando a solicitação de armazenamento no 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.

Como 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 trabalho 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 em disco físico 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, você poderá 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 trabalho 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 bem-sucedida do cluster ou do pool de nós.

Volumes permanentes locais estáticos padrão

O Distributed Cloud conectado é fornecido com os seguintes tipos de PersistentVolumes (PVs) locais estáticos padrão pré-provisionados:

  • anthos-system (97 GiB): uma classe de armazenamento de volume local estático pré-provisionada no modo de sistema de arquivos.
  • local-shared (97 GiB): uma classe de armazenamento de volume local estático pré-provisionada no modo de sistema de arquivos.
  • local-disks: uma classe de armazenamento de volume local estático pré-provisionada no modo de sistema de arquivos disponível em implantações de nó único para armazenamento de carga de trabalho do cliente. Ao contrário de local-shared, esses PVs são apoiados por partições físicas dedicadas e não são logicamente supercomprometidos.
  • local-block: uma partição de dispositivo de transferência por blocos bruto não vinculada reservada para armazenamento de carga de trabalho e volumes de armazenamento do Symcloud. O tamanho dessa partição depende da capacidade de armazenamento de hardware subjacente, consumindo o espaço em disco restante após reservar espaço para partições do sistema. Normalmente, os nós do plano de controle reservam 200 GiB (partição do sistema de 100 GiB e partição etcd de 100 GiB), enquanto os nós de trabalho reservam 100 GiB (para a partição do sistema). O layout da partição, os deslocamentos de slice e os limites de dispositivos físicos desses dispositivos de bloco brutos são fixos e imutáveis.

Os PVs local-shared de cada nó não estão acessíveis a outros nós no cluster. Os pods em execução em um nó gravam em diretórios separados que residem na mesma unidade de disco físico nesse nó. Se você não usar o armazenamento do Symcloud, os dispositivos de bloco brutos local-block não vinculados permanecerão disponíveis em cada nó.

Os PVs estáticos anthos-system e local-shared são logicamente supercomprometidos e apoiados pelo mesmo sistema de arquivos de partição física ~105 GB montado em /dev/mapper/shared_lpvs_encrypted em cada nó. Essa arquitetura fornece isolamento no nível do diretório para serviços em segundo plano do sistema gerenciados pelo Google, como geração de registros, monitoramento e rede, sem desperdiçar a capacidade do disco físico. Esses PVs do sistema são superprovisionados para a capacidade nominal máxima antecipadamente, porque o redimensionamento do volume local estático requer a migração de dados e a recriação dos PVs e PVCs afetados.

Evitar o uso de PVs local-shared para cargas de trabalho de produção

Não use PVs local-shared para cargas de trabalho de produção. Como esses PVs residem na mesma unidade de disco físico que os serviços do sistema conectado do Distributed Cloud, todas as cargas de trabalho implantadas para usar esses PVs competem por espaço com o próprio sistema conectado do Distributed Cloud.

Se a unidade de disco do sistema ficar sem espaço livre, o seguinte vai acontecer:

  • Os serviços de plataforma gerenciados pelo Google e os pods de monitoramento falham
  • O Kubernetes aciona um estado DiskPressure rígido no nó
  • O Kubernetes remove todos os pods do nó

Para evitar isso, use apenas classes de armazenamento oferecidas pelo armazenamento do Symcloud para cargas de trabalho de produção.

Solução de problemas

Se os 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.

Os PersistentVolumeClaims permanecem pendentes

Se os 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 corretamente.

Se a programação do pod for concluída, mas a declaração permanecer pendente ou se a anexação de 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 que você executou.