15. Bootstrap de armazenamento de objetos

15.1. Requisitos de rede

Consulte a imagem a seguir para ver um diagrama de cabeamento do SG1000 e do SG6060 para configurar as redes GRID, Admin e Client:

15.1.1. Admin Node SG1000

É preciso ter pelo menos dois nós de administrador no SG1000.

Para cada nó de administrador, você precisa ter um total de quatro endereços IP, um endereço em cada um dos seguintes itens:

• Rede BMC.
• Rede de administradores.
• Rede de clientes.
• Rede de grade.

Você precisa ter três sub-redes para o seguinte:

• Rede de administradores.
• Rede BMC.

A rede de cliente e a rede de grade, e cada sub-rede precisa ter uma máscara de sub-rede de no máximo 30 bits.

15.1.2. Nós de armazenamento SG6060 e SG6000

É necessário ter pelo menos três nós de armazenamento para os modelos SG6060 e SG6000.

Para cada nó de armazenamento, você precisa ter um total de cinco endereços IP, um endereço em cada um dos seguintes itens:

• Rede BMC(mgmt).
• Rede de administrador(gerenciamento).
• Rede de grade.
• Rede do controlador de armazenamento (mgmt). Observação: a rede do controlador de armazenamento precisa ter dois endereços IP.

Você precisa ter duas sub-redes para cada um dos seguintes itens:

• Rede BMC.
• Rede de administradores.
• Rede de controladores de armazenamento.
• Rede de grade.

A tabela a seguir lista o número de endereços IP para os nós de administrador e de armazenamento:

Você precisa ter as três sub-redes a seguir:

• Rede de administradores.
• Rede de clientes.
• Rede de grade.

Cada sub-rede precisa ter uma máscara de sub-rede de no máximo 30 bits.

15.1.3. Detalhes da rede

15.1.3.1. Rede do plano de gerenciamento da nuvem distribuída:

A rede de gerenciamento fora de banda (OOB, na sigla em inglês) do Distributed Cloud contém a rede do controlador de gerenciamento da placa-mãe (BMC, na sigla em inglês) do Object Storage e a rede de administrador. A rede se conecta a mgmtsw.

Você precisa ter o endereço IP do BMC OOB em cada um dos seguintes itens:

• SG1000
• SG6000

Você precisa ter o endereço IP de gerenciamento OOB em cada um dos seguintes itens:

• SG1000
• SG6000
• SG6060

15.1.3.2. Rede do plano de dados do Distributed Cloud

A rede do plano de dados é composta pela LIF do cliente StorageGRID (SG1000) de objeto externo e pela rede do cliente no NetApp.

• Siga as etapas abaixo para identificar o SubnetClaim em cada um:

  • Endpoint de API do S3:
  1. No arquivo cellconfig, pesquise external-objectstorage-client-lif-subnet.
  2. Identifique o SubnetClaim correspondente, que especifica o CIDR/endereço IP do gateway atribuído.

  • Endpoints do dispositivo de rede de grade SG1000:

    1. No arquivo cellconfig, pesquise objectstorage-admin-nodes-lif-subnet.
    2. Identifique o SubnetClaim correspondente, que especifica o CIDR/endereço IP do gateway atribuído.

• Endpoints do dispositivo de rede de grade SG6060:

  1. No arquivo cellconfig, pesquise objectstorage-storage-nodes-lif-subnet.
  2. Identifique o SubnetClaim correspondente, que especifica o CIDR/endereço IP do gateway atribuído.

15.2. Preparação

15.2.1. Coletar informações

Tempo estimado: 5 a 10 minutos

Antes de continuar esta seção, verifique se a inicialização e a configuração da rede concluem a instância do Distributed Cloud e se o operador tem acesso ao arquivo cellconfig mais preciso ou mais recente disponível ou acesso à inicialização.

15.2.1.1. Coletar informações de dispositivos de hardware de armazenamento

As instâncias do Distributed Cloud seguem uma convenção de nomenclatura fixa para identificar dispositivos de hardware em racks. Especificamente, para os seguintes dispositivos de armazenamento de objetos:

• Nó de administrador(SG1000): <cell>-<rack>-objsadm[node-number]. Por exemplo, af-ae-objsadm01 representa um nó de administrador.
• Nó do controlador de computação de armazenamento (SG6000-CN): <cell>-<rack>-objs[node-number]. Por exemplo, af-ae-objs01.
• Compartimento do controlador de armazenamento(E2860): <cell>-<rack>-objs[node-number]-s1. Exemplo: af-ae-objs01-s1
• Controladores de nós de armazenamento(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Por exemplo: af-ae-objs01-s1-01 e af-ae-objs01-s1-02

15.2.1.2. Coletar informações da rede do plano de gerenciamento

Durante o bootstrap e a configuração da rede, o operador precisa criar uma sub-rede para o plano de gerenciamento. O sistema de armazenamento de objetos exige as seguintes informações durante o processo de inicialização:

1. Sub-rede de gerenciamento.
2. Endereço IP do gateway de gerenciamento.
3. 16 endereços IP reservados na sub-rede de gerenciamento, dois endereços IP para cada nó de administrador e quatro endereços IP para cada nó de armazenamento.

Encontre o endereço IP do gateway de gerenciamento no SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. Os <cell> e <rack> são os mesmos identificados na etapa "Coletar informações sobre dispositivos de hardware de armazenamento". Por exemplo: af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Armazene o valor do comando em MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Coletar informações de rede do plano de dados

Antes de continuar, provisione três sub-redes para o sistema de armazenamento de objetos durante a inicialização e configuração da rede.

Verifique se as seguintes sub-redes existem:

• objectstorage-admin-nodes-lif-subnet
• objectstorage-storage-nodes-lif-subnet
• external-objectstorage-client-lif-subnet

Execute o comando a seguir com os nomes dos SubnetClaim:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

A saída a seguir será exibida:

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Verifique se os seguintes campos estão presentes:

1. VLAN
2. READY: True
3. VLANREADY: True

15.2.1.4. Coletar informações de dependência

O sistema de armazenamento de objetos depende dos seguintes serviços e infraestrutura principais no Distributed Cloud:

• NTP
• Módulos de segurança de hardware (HSM)
• DNS

15.2.1.5. Atualizar campos TO-BE-FILLED

Verifique o arquivo obj-cellobj.yaml para encontrar valores de TO-BE-FILLED e atualize-os.

Execute o seguinte para garantir que o valor não exista no arquivo YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Rede de gerenciamento de configuração por conexão local

Tempo estimado: 30 a 45 minutos

Esta subseção configura a rede de gerenciamento para cada nó do dispositivo StorageGRID. Depois que a rede de gerenciamento é configurada, os nós do StorageGRID são acessados pelo bootstrapper usando o IP na rede de gerenciamento.

Siga estas etapas para todos os dispositivos ObjectStorage:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

Para fazer o bootstrap dos dispositivos StorageGRID, conecte-se a cada dispositivo, incluindo dois nós de administrador e três nós de armazenamento, com um carrinho de emergência na porta 6 da rede de administrador e acesse https://169.254.0.1:8443 para configurar os endereços IP de administrador na rede de gerenciamento.

1. Conecte um carrinho de emergência diretamente à porta RJ-45 mais à direita no dispositivo de serviços usando um cabo Ethernet. Os diagramas a seguir mostram a porta 6 para nós de administrador e de armazenamento como exemplo:

   

   

2. Abra um navegador da Web no carrinho de emergência.

3. Navegue até https://169.254.0.1:8443 em cada máquina.

4. Na barra de menus do StorageGRID Appliance Installer, clique em Configurar rede > Configuração de link. Verifique se a rede de administrador está ativada.

   

5. Para configurar o endereço IP da rede de administrador, selecione Configurar rede > Configuração de IP.

6. Role a tela para baixo até a seção Rede de administrador e, em Atribuição de IP, selecione Estático e insira os endereços IP de gerenciamento correspondentes, managementIP, para o nó. Você pode encontrar o IP de gerenciamento de cada nó no arquivo obj-cellobj.yaml. Exemplo:

   • ObjectStorageAdminNode (SG1000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageAdminNode
     metadata:
       creationTimestamp: null
       name: af-ae-objsadm01
     spec:
       network:
         bmcIP: 10.251.188.11/24
         clientIP: 10.251.113.2/28
         dataIP: 10.1.0.66/26
         managementIP: 10.251.188.10/24
       siteName: objectstorage-site
     

   • ObjectStorageStorageNode (SG6000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageStorageNode
     metadata:
       creationTimestamp: null
       name: af-ae-objs01
     spec:
       network:
         bmcIP: 10.251.243.34/24
         controllerAManagementIP: 10.251.243.35/24
         controllerBManagementIP: 10.251.243.36/24
         dataIP: 10.1.0.132/26
         managementIP: 10.251.243.33/24
       siteName: objectstorage-site
     

   Defina o gateway como MANAGEMENT_SWITCH_GATEWAY.

   A imagem de exemplo a seguir mostra a configuração de af-ae-objs01 usando o endereço IP de gerenciamento alocado no arquivo obj-cellobj.yaml:

   

7. Clique em Salvar e verifique se o endereço IP foi atualizado.

8. Dê um ping no endereço IP de gerenciamento do bootstrap para garantir que ele esteja acessível.

   1. Dê um ping no endereço IP de gerenciamento do bootstrap para verificar se ele está acessível.
   2. Depois que todos os nós tiverem um endereço IP na rede de administração, acesse a GUI de instalação do nó do StorageGRID usando o endereço IP de gerenciamento.

Solução de problemas:

Se um nó não puder ser pingado:

1. Acesse a UI de instalação do nó do StorageGRID na etapa 3 anterior e verifique se há erros mostrados em um banner de caixa de diálogo. Tente resolver os erros. Entre em contato com os engenheiros, se necessário.
2. Acesse Configurar rede > Configuração de IP. Verifique se a seção "Admin Network" correta está configurada com o IP estático e o gateway corretos. Às vezes, o nó do StorageGRID não registra totalmente a configuração da rede de gerenciamento após a confirmação.
3. Execute as etapas de 5 a 8 novamente e verifique a rede do nó de administrador.

O acesso à GUI de instalação do nó do StorageGRID em cada nó é necessário para continuar a instalação do sistema de armazenamento de objetos.

15.2.3. Fazer upgrade do StorageGRID

Tempo estimado: 1 a 1,5 hora(s)

Antes de fazer upgrade do StorageGRID, verifique a versão do software. Acesse Avançado > Fazer upload do software StorageGRID. A versão atual do StorageGRID aparece.

Verifique a versão de instalação do StorageGRID agrupada:

gdcloud artifacts tree oci | grep object-storage/os

A saída de exemplo é semelhante a esta:

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

A versão é marcada no artefato, neste exemplo, como 11.8.0:

Armazene o valor da versão em SG_INSTALL_VERSION.

Confira a versão do firmware do StorageGRID incluída:

gdcloud artifacts tree oci | grep object-storage/firmware

A saída de exemplo é semelhante a esta:

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

A versão é marcada no artefato, neste exemplo, como 3.8.1:

Armazene o valor da versão em SG_FIRMWARE_VERSION.

Se a versão no nó não for SG_INSTALL_VERSION, siga as próximas etapas para fazer upgrade ou downgrade da versão de instalação do StorageGRID. Se a versão atual for SG_INSTALL_VERSION, vá para a seção Fazer upgrade do SANtricity.

15.2.3.1. Fazer upgrade do firmware

Siga estas etapas para todos os nós do StorageGRID:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

1. Extraia a imagem de firmware do pacote:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz
   

   O arquivo está disponível em storagegrid_firmware_install/.

2. Navegue até o instalador de dispositivos StorageGRID no nó do StorageGRID. Escolha Avançado > Fazer upgrade do firmware. Faça upload da imagem de firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 e do checksum storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 para a versão de firmware selecionada. Depois do upload, o StorageGRID começa a validar os arquivos automaticamente. A validação geralmente leva de cinco a dez minutos.

   

3. Depois que duas marcas de seleção verdes aparecerem, clique em Fazer upgrade da partição inativa.

   

   Depois de receber a mensagem Successfully updated the firmware on the inactive partition, confira se a partição inativa é realmente a versão correta na seção Firmware atual.

   Clique em Reiniciar e Trocar partições duas vezes.

4. Depois que o nó terminar de reiniciar, repita as etapas 1 e 2 para fazer upgrade do firmware da outra partição. A partição ativa é a versão escolhida, enquanto a inativa contém a versão mais antiga.

   

15.2.3.2. Fazer upgrade do software StorageGRID

Depois que o upgrade do firmware em todos os nós for concluído para a versão correta, faça o upgrade do software para a versão selecionada nos dois nós de administrador. Não é necessário fazer upgrade dos nós de armazenamento, porque eles imitam e extraem o software dos nós de administrador.

Siga estas instruções nos nós de administrador do SG1000:

• af-ae-objsadm01
• af-ae-objsadm02

1. Extraia a imagem de instalação do pacote:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/os.tar.gz
   

   Os arquivos estão disponíveis em storagegrid_os_install/.

2. Acesse Avançado -> Fazer upload do software StorageGRID. Clique em Remover para remover o software atual e faça upload do novo pacote de software storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb e do checksum correspondente storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5, conforme mostrado:

   

3. Quando o upload do software terminar, verifique se o software do nó foi atualizado para a versão selecionada:

   

15.2.4. Fazer upgrade do SANtricity

Tempo estimado: 1 a 1,5 hora(s)

Antes de fazer upgrade do SANtricity, verifique a versão do software. Navegue até a interface do SANtricity e clique em Suporte > CENTRAL DE UPGRADE > Iniciar upgrade. A versão atual do SANtricity vai aparecer.

Verifique a versão instalada do SANtricity:

gdcloud artifacts tree oci | grep object-storage/santricity

A saída de exemplo é semelhante a esta:

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

A versão é marcada no artefato, neste exemplo, como 11.70.5R1.

Armazene o valor da versão em SANTRICITY_OS_VERSION.

Se a versão do SANtricity for anterior a SANTRICITY_OS_VERSION, siga as próximas etapas para fazer upgrade da versão do SO SANtricity. Caso contrário, acesse Instalação.

15.2.4.1. Fazer upgrade do sistema operacional SANtricity

Siga estas instruções na interface do SANtricity para cada nó de armazenamento:

1. Extraia a imagem de instalação do pacote:

   gdcloud artifacts extract oci santricity \
       --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION
   
   tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz
   

   O arquivo de upgrade está disponível em santricity/SANTRICITY_OS_VERSION/.

2. Acesse Suporte > CENTRAL DE UPGRADE. Clique em Iniciar upgrade em Upgrade do software do SO SANtricity. Clique em Procurar para selecionar o arquivo de software do SO SANtricity. Faça upload do novo pacote de software RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp, conforme mostrado:

   

3. Clique em Iniciar e confirme que quer realizar a operação.

4. Após a conclusão do upgrade, verifique se a versão foi atualizada:

   

15.3. Instalação

15.3.1. crie secrets

Tempo estimado: 15 a 30 minutos

Para receber valores para criar secrets, use o diretório cellcfg:

1. Consiga os nomes dos objectstoragestoragenodes:

   $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   

   Exemplo de resposta:

   # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   ah-ac-objs01
   ah-ac-objs02
   ah-ac-objs03
   

2. Extraia o endereço IP do BMC para o nó de armazenamento:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443
   

3. Faça login no SANtricity System Manager usando o link na saída do comando anterior. Se você não tiver definido a senha antes, crie uma e faça login:

   

   1. Se a senha do SANtricity for perdida, redefina-a pelo console serial do StorageGRID E2860. Para se conectar à porta serial do conjunto de discos E2860, as configurações do terminal são 115200 8N1.

4. Configure os endereços do servidor NTP no SANtricity System Manager para os dois controladores:

   

   1. Extrair os endereços do servidor NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      

   2. Selecione Hardware no SANtricity System Manager.

   3. Se o gráfico mostrar as unidades, clique em Mostrar parte de trás da estante. O gráfico muda para mostrar os controladores em vez das unidades.

   4. Clique no controlador que você quer configurar. O menu de contexto do controlador aparece.

   5. Selecione Configurar servidor NTP. A caixa de diálogo "Configurar servidor Network Time Protocol (NTP)" é aberta.

   6. Selecione Quero ativar o NTP no controlador (A ou B). Outras opções aparecem na caixa de diálogo.

   7. Selecione Especificar manualmente os endereços do servidor NTP. Insira o endereço do servidor NTP principal usando um dos IPs buscados pelo comando anterior.

   8. Clique em Salvar.

5. Atualize os secrets que contêm credenciais do SANtricity para cada um dos nós de armazenamento no arquivo cell.yaml. Se os secrets não existirem, adicione-os seguindo este modelo:

   apiVersion: v1
   kind: Secret
   metadata:
     creationTimestamp: null
     name: <STORAGE_NODE_NAME>-santricity
     namespace: gpc-system
   stringData:
     password: 'PASSWORD'
     username: 'admin'
   type: Opaque
   

6. Crie os secrets para cada um dos nós de armazenamento listados na etapa anterior:

   kubectl create secret generic \
      --namespace=gpc-system STORAGE_NODE_NAME-santricity \
      --from-literal=username=admin \
      --from-literal=password=PASSWORD
   

Validação:

1. Execute o comando a seguir com cada nó de armazenamento listado na etapa anterior. Ele imprime o nome de usuário do Santricity definido na etapa anterior. Valide o administrador:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
   

2. Execute o comando a seguir com cada nó de armazenamento listado na etapa anterior. Ele imprime a senha do Santricity:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
   

3. Execute o comando a seguir para acessar o URL da interface do usuário do Santricity Management. Faça login no Santricity com o nome de usuário e a senha:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
   

Solução de problemas:

Se os segredos não forem encontrados ao executar as etapas 1 ou 2 de validação, execute a etapa kubectl create secret novamente.

Se não for possível fazer login na interface de gerenciamento do Santricity:

1. Redefina a credencial de administrador pelo console serial do StorageGRID E2860.
2. Siga todas as etapas anteriores, exceto a última.

3. Exclua o secret do Santricity de cada nó:

   kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
   

4. Execute a última etapa para recriar o secret do Santricity.

15.3.2. Bootstrap Object Storage

O processo de bootstrap do Object Storage varia entre a primeira zona e as zonas de junção. Consulte a seção relevante com base na sua situação específica.

IMPORTANTE: verifique se a zona de ancoragem concluiu a inicialização da API global antes de continuar.

15.3.2.1. Inicializar o armazenamento de objetos na primeira zona

Execute o comando a seguir para fazer o bootstrap do armazenamento de objetos:

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

15.3.2.2. Inicializar o armazenamento de objetos na zona de junção

Solução de problemas:

1. Quando os comandos da Google Cloud CLI atingirem o tempo limite ou retornarem erros, resolva os problemas retornados.
2. Confira o pod gpc-system/obj-infra-cluster-cm-backend-controller de login para mais detalhes sobre o erro.

15.3.2.3. Inicializar o armazenamento de objetos na zona de junção

Tempo estimado: 30 a 60 minutos

O bootstrapping do Object Storage em uma zona de junção requer coordenação entre os reconciliadores do Object Storage na zona de ancoragem e na zona de junção. Como não existe um canal de comunicação seguro e controlado entre duas zonas para reconciliadores durante o tempo de bootstrap, o IO precisa facilitar manualmente a comunicação segura para reconciliadores do Object Storage entre duas zonas.

1. Conceda a si mesmo o papel predefinido Administrador do cluster no cluster zonal root-admin e no cluster global na zona de ancoragem. Consulte o runbook do IAM para mais detalhes.

Como alternativa, aplique essas duas vinculações de função na zona de ancoragem:

Na API global:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

No cluster de administrador raiz:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

1. Execute o comando na zona de ancoragem para receber o IP do servidor DNS e anote-o para uso posterior: sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

2. Configure o resolvedor stub de DNS da zona de junção para vincular à zona de ancoragem:

   1. Desativar e interromper o systemd-resolved sh systemctl disable systemd-resolved.service --now

   2. Exclua o arquivo resolv.conf se ele existir sh rm -f /etc/resolv.conf

   3. Grave o IP do servidor DNS da zona de ancoragem no resolv.conf da zona de junção. sh vim /etc/resolv.conf Exemplo de conteúdo do arquivo /etc/resolv.conf: sh nameserver 10.200.40.0

3. Crie o arquivo YAML TokenRequest na zona de junção.

   gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH
   

   Substitua JOINING_ZONE_NAME pelo nome da zona do Questionário de coleta de dados do cliente, conforme descrito na nota ao final da seção.

4. Transfira o arquivo YAML TokenRequest para a zona de ancoragem.

   scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
   

5. Aplique o YAML TokenRequest ao cluster global root-admin na zona de ancoragem.

   kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
   

6. Crie o arquivo YAML do token na zona de ancoragem.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
   

7. Transfira o arquivo YAML do token para a zona de junção.

   scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
   

8. Aplique o YAML do token ao cluster KIND na zona de junção.

   kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
   

9. Crie o arquivo YAML ObjectStorageBootstrap na zona de ancoragem.

   gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
   

10. Transfira o arquivo YAML ObjectStorageBootstrap para a zona de junção.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

11. Aplique o arquivo YAML ObjectStorageBootstrap ao cluster KIND na zona de junção.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

12. Inicialize o armazenamento de objetos na zona de junção.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5