Configurar o armazenamento conectado do Distributed Cloud

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

• Rakuten Symcloud Storage
• Esquemas de armazenamento local
• Solução de problemas

Configurar o Distributed Cloud Connected para o Symcloud Storage

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

A 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 Connected, o Symcloud Storage é a solução de armazenamento CSI gerenciada e compatível. Quando o Symcloud Storage é ativado, as StorageClasses necessárias do Kubernetes são configuradas para você. Em seguida, configure as cargas de trabalho para usar a classe de armazenamento adequada.

O Symcloud Storage é implantado no Google Cloud Marketplace e está sujeito aos termos declarados nele. O Google oferece suporte limitado para o uso do Symcloud Storage com o Distributed Cloud Connected e pode entrar em contato com o provedor terceirizado para receber ajuda. As atualizações de software do Symcloud Storage estão incluídas nas atualizações de software conectadas do Distributed Cloud.

Esta versão do Distributed Cloud Connected é enviada com e oferece suporte ao Symcloud Storage 6.0.0-226. Nenhuma outra versão do Symcloud Storage é compatível com esta versão do Distributed Cloud Connected.

Adquirir uma licença do Symcloud Storage

Você precisa adquirir uma licença do Symcloud Storage no formato YAML no Google Cloud Marketplace:

Acessar o Marketplace

Pré-requisitos

Antes de começar, siga estas etapas:

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

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

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

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

   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 do Symcloud Storage:

   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 Symcloud Storage 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 Symcloud Storage pode ativar no seu cluster conectado do Distributed Cloud. O Symcloud Storage no Distributed Cloud Connected não é compatível com a classe de armazenamento robin-rwx nem com volumes de modo de sistema de arquivos RWX configurados de maneira personalizada. Para mais informações sobre classes de armazenamento do Symcloud, consulte Como usar o Robin CNS no Kubernetes.

Classe de armazenamento robin

A classe de armazenamento robin é uma classe básica de armazenamento 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 reivindicaçã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

O 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 mostra exemplos de como usar classes de armazenamento do Symcloud para configurar o armazenamento abstraído para suas cargas de trabalho conectadas ao Distributed Cloud. Para mais detalhes sobre como configurar volumes do Symcloud Storage, consulte Usar o Robin CNS no Kubernetes.

Configurar um volume ext4 RWO no modo de sistema de arquivos

O exemplo a seguir ilustra como configurar uma reivindicaçã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 bloqueio

O exemplo a seguir ilustra como configurar uma solicitaçã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 com LZ4 do Symcloud Storage 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 mostra como modificar a configuração de um volume RWO do Symcloud Storage 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 do Symcloud Storage

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

1. Receba o caminho da imagem do Symcloud Storage usado pela instância do 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 nome da imagem que você obteve na etapa 1.

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

4. Na instalação inicial, o Symcloud Storage 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. Consiga 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 carga de trabalho StatefulSet.

O exemplo pressupõe que você está 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 seguintes práticas recomendadas na sua configuração:

• Serviço headless: um StatefulSet exige um serviço headless complementar que corresponda ao campo serviceName. Um serviço sem comando é 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 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. Configurar a antiafinidade de pods garante que eles 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 sem cabeçalho (nginx) e um StatefulSet configurado com antiafinidade de pod referenciando a classe de armazenamento robin-repl-3. Se os requisitos de armazenamento da carga de trabalho aumentarem com o tempo, será possível redimensionar dinamicamente o volume editando a solicitação de armazenamento no PersistentVolumeClaim.

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 Symcloud Storage

Ao usar o Symcloud Storage com o Distributed Cloud Connected, só é possível alcançar alta disponibilidade se o cluster do Distributed Cloud Connected tiver três ou mais nós.

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

As réplicas de volume do Symcloud Storage são armazenadas em nós de trabalho no cluster conectado da Distributed Cloud. Se você remover um nó do cluster, os dados do volume do Symcloud Storage armazenados nele vão ficar indisponíveis. Para evitar isso, siga um destes procedimentos:

• Se você estiver desativando todo o cluster, remova as cargas de trabalho e os volumes persistentes do Symcloud Storage 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 removê-los 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 de forma sequencial 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 seu cluster conectado do Distributed Cloud, é necessário fazer uma solicitação ao Google. Depois de testar e criar o esquema 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, você precisa pedir a exclusão do esquema atual ao Google e solicitar a criação de um novo para substituí-lo.

Definir partições para um esquema de armazenamento local

Antes de solicitar um esquema de armazenamento local, defina as partições dele.

Uma partição tem as seguintes propriedades:

• Tamanho. Você pode 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 blocos ou um volume do 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 dos sistemas de arquivos contidos.

Solicitar um esquema de armazenamento local

Para solicitar um novo esquema de armazenamento local para seu cluster conectado do Distributed Cloud, entre em contato com o suporte do Google e informe o tamanho, tipo, modo e, opcionalmente, 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 o criamos no cluster conectado da Distributed Cloud.

Esquemas de armazenamento local padrão

O Distributed Cloud Connected vem 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 Connected 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 os PersistentVolumeClaims permanecerem pendentes inesperadamente ou as cargas de trabalho não anexarem 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 sua 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 faz referência à declaração seja programado. Confira se o pod da carga de trabalho foi programado.

Se o agendamento do pod estiver concluído, mas a reivindicação ainda estiver pendente, ou se a anexação do volume falhar, verifique a integridade do plano de controle do Symcloud Storage e dos daemons no nível do nó.

Verificar a integridade do plano de controle

Para verificar se o plano de controle do Symcloud Storage está íntegro e pronto para provisionar volumes, execute o comando kubectl describe 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 comando kubectl get:

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 daemon de armazenamento com falha, a vinculação de volume vai ficar pendente, independente do status central do RobinCluster.

Entrar em contato com o suporte

Se o status do plano de controle do Symcloud Storage 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.