15.1. Requisiti di rete
Per configurare le reti GRID, Admin e Client, consulta la seguente immagine per un diagramma di cablaggio di SG1000 e SG6060:

15.1.1. Admin Node SG1000
Devi avere almeno due nodi di amministrazione in SG1000.
Per ogni nodo amministratore, devi avere un totale di quattro indirizzi IP, uno per ciascuno dei seguenti:
- BMC Network.
- Admin Network.
- Rete client.
- Grid Network.
Devi avere tre subnet per quanto segue:
- Admin Network.
- BMC Network.
La rete client e la rete di distribuzione e ogni subnet devono avere una maschera di subnet di al massimo 30 bit.
15.1.2. Nodi di archiviazione SG6060 e SG6000
Devi avere almeno tre nodi di archiviazione per i modelli SG6060 e SG6000.
Per ogni nodo di archiviazione, devi avere un totale di cinque indirizzi IP, uno per ciascuno dei seguenti elementi:
- BMC Network(mgmt).
- Admin Network(mgmt).
- Grid Network.
- Storage Controller Network (mgmt). Nota: la rete del controller di archiviazione deve avere due indirizzi IP.
Devi avere due subnet per ciascuno dei seguenti elementi:
- BMC Network.
- Admin Network.
- Storage Controller Network.
- Grid Network.
La tabella seguente elenca il numero di indirizzi IP per i nodi di amministrazione e di archiviazione:
| Numero di IP necessari | Admin Network | Rete client | Rete a griglia |
|---|---|---|---|
| Nodo amministratore | 2 | 1 | 1 |
| Nodo di archiviazione | 4 | 0 | 1 |
Devi disporre delle seguenti tre subnet:
- Admin Network.
- Rete client.
- Grid Network.
Ogni subnet deve avere una subnet mask di massimo 30 bit.
15.1.3. Dettagli rete
15.1.3.1. Rete del control plane di gestione di Distributed Cloud:
La rete di gestione out-of-band (OOB) di Distributed Cloud contiene
la rete Baseboard Management Controller (BMC) di Object Storage e la rete
di amministrazione. La rete si connette a mgmtsw.
Devi avere l'indirizzo IP BMC OOB su ciascuno dei seguenti elementi:
- SG1000
- SG6000
Devi avere l'indirizzo IP di gestione OOB su ciascuno dei seguenti elementi:
- SG1000
- SG6000
- SG6060
15.1.3.2. Rete del piano dati di Distributed Cloud
La rete del piano dati è costituita dall'interfaccia LIF client e dalla rete client in NetApp.
Segui i passaggi riportati di seguito per identificare
SubnetClaimsu ciascuno:- Endpoint API S3:
- Nel file
cellconfig, cercaexternal-objectstorage-client-lif-subnet. - Identifica il
SubnetClaimcorrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.
Endpoint dell'appliance di rete SG1000:
- Nel file
cellconfig, cercaobjectstorage-admin-nodes-lif-subnet. - Identifica il
SubnetClaimcorrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.
- Nel file
Endpoint dell'appliance di rete della griglia SG6060:
- Nel file
cellconfig, cercaobjectstorage-storage-nodes-lif-subnet. - Identifica il
SubnetClaimcorrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.
- Nel file
15.2. preparazione
15.2.1. Raccogliere informazioni
Tempo stimato: 5-10 minuti
Prima di continuare questa sezione, assicurati che il bootstrap e la configurazione di rete
completino l'istanza di Distributed Cloud e che l'operatore abbia accesso
al file cellconfig più preciso o più recente disponibile oppure al bootstrap.
15.2.1.1. Raccogliere informazioni sui dispositivi hardware di archiviazione
Le istanze Distributed Cloud seguono una convenzione di denominazione fissa per identificare i dispositivi hardware nei rack. In particolare, ai seguenti dispositivi di archiviazione di oggetti:
- Nodo di amministrazione(SG1000):
<cell>-<rack>-objsadm[node-number]. Ad esempio:af-ae-objsadm01rappresenta un nodo amministratore. - Nodo controller di computing dello spazio di archiviazione (SG6000-CN):
<cell>-<rack>-objs[node-number]. Ad esempio:af-ae-objs01. - Ripiano del controller di archiviazione(E2860):
<cell>-<rack>-objs[node-number]-s1. Ad esempio:af-ae-objs01-s1 - Controller dei nodi di archiviazione(SG6060):
<cell>-<rack>-objs[node-number]-s1-[controller number]. Ad esempio:af-ae-objs01-s1-01eaf-ae-objs01-s1-02
15.2.1.2. Raccogliere informazioni sulla rete del management plane
Durante il bootstrap e la configurazione della rete, l'operatore deve creare una subnet per il piano di gestione. Il sistema di archiviazione di oggetti richiede le seguenti informazioni durante la procedura di bootstrapping:
- Subnet di gestione.
- Indirizzo IP del gateway di gestione.
- 16 indirizzi IP riservati nella subnet di gestione, due indirizzi IP per ogni nodo amministratore e quattro indirizzi IP per ogni nodo di archiviazione.
Trova l'indirizzo IP del gateway di gestione da
SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. <cell> e <rack> sono
uguali a quelli identificati nel passaggio "Raccogli informazioni sui dispositivi hardware di archiviazione"
Ad esempio: 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}'
Memorizza il valore del comando in MANAGEMENT_SWITCH_GATEWAY.
15.2.1.3. Raccogliere le informazioni di rete del piano dati
Prima di continuare, assicurati di aver eseguito il provisioning di tre subnet per il sistema di archiviazione degli oggetti durante il bootstrapping e la configurazione della rete.
Controlla se esistono le seguenti subnet:
-
objectstorage-admin-nodes-lif-subnet -
objectstorage-storage-nodes-lif-subnet -
external-objectstorage-client-lif-subnet
Esegui questo comando con i nomi dei SubnetClaim:
kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME
Viene visualizzato l'output seguente:
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
Verifica se sono presenti i seguenti campi:
VLANREADY: TrueVLANREADY: True
15.2.1.4. Raccogliere informazioni sulle dipendenze
Il sistema di archiviazione di oggetti si basa sui seguenti servizi e infrastrutture di base in Distributed Cloud:
- NTP
- Moduli di sicurezza hardware (HSM)
- DNS
15.2.1.5. Aggiorna i campi TO-BE-FILLED
Controlla il file obj-cellobj.yaml per eventuali valori TO-BE-FILLED
e aggiornali.
Esegui il comando seguente per assicurarti che il valore non esista nel file YAML:
cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"
15.2.2. Rete di gestione della configurazione tramite connessione locale
Tempo stimato: 30-45 minuti
Questa sottosezione configura la rete di gestione per ogni nodo dell'appliance StorageGRID. Una volta configurata la rete di gestione, si accede ai nodi StorageGRID dal bootstrapper utilizzando l'IP nella rete di gestione.
Segui questi passaggi per tutti i dispositivi ObjectStorage:
-
af-ae-objsadm01 -
af-ae-objsadm02 -
af-ae-objs01 -
af-ae-objs02 -
af-ae-objs03
Per eseguire il bootstrap dei dispositivi StorageGRID, connettiti a ogni dispositivo, inclusi due nodi di amministrazione e tre nodi di archiviazione, con un carrello di emergenza sulla porta 6 della rete di amministrazione e visita https://169.254.0.1:8443 per configurare gli indirizzi IP di amministrazione sulla rete di gestione.
Collega un carrello di emergenza direttamente alla porta RJ-45 più a destra dell'appliance di servizi utilizzando un cavo Ethernet. I seguenti diagrammi mostrano la porta 6 per i nodi di amministrazione e di archiviazione come esempio:


Apri un browser web sul carrello di emergenza.
Vai a
https://169.254.0.1:8443su ogni macchina.Dalla barra dei menu di StorageGRID Appliance Installer, fai clic su Configure Networking > Link Configuration. Controlla se la rete amministrativa è attiva.

Per configurare l'indirizzo IP per la rete di amministrazione, seleziona Configura Networkinge > Configurazione IP.
Scorri verso il basso fino alla sezione Admin Network e, in IP Assignment, seleziona Static e inserisci gli indirizzi IP di gestione corrispondenti,
managementIP, per il nodo. Puoi trovare l'IP di gestione per ogni nodo nel fileobj-cellobj.yaml. Ad esempio: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-siteObjectStorageStorageNode (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
Imposta il gateway come
MANAGEMENT_SWITCH_GATEWAY.L'immagine di esempio seguente mostra la configurazione per
af-ae-objs01utilizzando l'indirizzo IP di gestione allocato nel fileobj-cellobj.yaml:
Fai clic su Salva e verifica se l'indirizzo IP viene aggiornato.
Invia un ping all'indirizzo IP di gestione dal bootstrapper per assicurarti che sia raggiungibile.
- Invia un ping all'indirizzo IP di gestione dal bootstrapper per assicurarti che sia raggiungibile.
- Una volta che tutti i nodi hanno un indirizzo IP sulla rete di amministrazione, accedi alla GUI di installazione del nodo StorageGRID utilizzando il suo indirizzo IP di gestione.
Risoluzione dei problemi:
Se un nodo non è pingabile:
- Accedi all'interfaccia utente di installazione del nodo StorageGRID dal passaggio 3 precedente e controlla se sono presenti errori visualizzati in un banner di dialogo. Tenta di risolvere gli errori. Contatta gli ingegneri, se necessario.
- Vai a Configura rete > Configurazione IP. Verifica che la sezione Rete amministrativa corretta sia configurata con IP statico e gateway corretti. A volte, il nodo StorageGRID non registra completamente la configurazione della rete di gestione dopo la conferma.
- Esegui di nuovo i passaggi da 5 a 8 e verifica la rete del nodo amministratore.
Per continuare l'installazione del sistema di archiviazione degli oggetti, è necessario l'accesso alla GUI di installazione del nodo StorageGRID su ogni nodo.
15.2.3. Esegui l'upgrade di StorageGRID
Tempo stimato: 1-1,5 ore
Prima di eseguire l'upgrade di StorageGRID, controlla la versione del software StorageGRID. Vai a Avanzate > Carica software StorageGRID. Viene visualizzata la versione attuale di StorageGRID.
Controlla la versione di installazione di StorageGRID inclusa:
gdcloud artifacts tree oci | grep object-storage/os
L'output di esempio è simile al seguente:
│ │ │ └── gpc-system-object-storage/os:11.8.0
├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig
La versione è taggata nell'artefatto, in questo esempio, come 11.8.0:
Archivia il valore della versione in SG_INSTALL_VERSION.
Controlla la versione del firmware StorageGRID in bundle:
gdcloud artifacts tree oci | grep object-storage/firmware
L'output di esempio è simile al seguente:
│ │ │ ├── gpc-system-object-storage/firmware:3.8.1
├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig
La versione è taggata nell'artefatto, in questo esempio, come 3.8.1:
Archivia il valore della versione in SG_FIRMWARE_VERSION.
Se la versione sul nodo non è SG_INSTALL_VERSION, continua con i passaggi successivi per eseguire l'upgrade o il downgrade della versione di installazione di StorageGRID. Se la
versione attuale è SG_INSTALL_VERSION, vai alla sezione Esegui l'upgrade di SANtricity.

15.2.3.1. Eseguire l'upgrade del firmware
Segui questi passaggi per tutti i nodi StorageGRID:
-
af-ae-objsadm01 -
af-ae-objsadm02 -
af-ae-objs01 -
af-ae-objs02 -
af-ae-objs03
Recupera l'immagine del firmware dal bundle:
gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION tar -xvzf storage/gpc-system-object-storage/firmware.tar.gzIl file è disponibile in
storagegrid_firmware_install/.Vai a StorageGRID Appliance Installer sul nodo StorageGRID. Scegli Avanzate > Aggiorna firmware. Carica l'immagine del firmware
storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2e il checksumstoragegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1per la versione del firmware selezionata. Dopo il caricamento, StorageGRID inizia automaticamente a convalidare i file. In genere la convalida richiede circa 5-10 minuti.
Quando vengono visualizzati due segni di spunta verdi, fai clic su Esegui l'upgrade della partizione inattiva.

Dopo aver ricevuto il messaggio
Successfully updated the firmware on the inactive partition, assicurati che la partizione inattiva sia effettivamente la versione corretta esaminando la sezione Firmware attuale.Fai clic su Riavvia e Scambia partizioni due volte.
Dopo il riavvio del nodo, ripeti i passaggi 1 e 2 per aggiornare il firmware dell'altra partizione. La partizione attiva è la versione scelta, mentre la partizione inattiva contiene la versione precedente.

15.2.3.2. Eseguire l'upgrade del software StorageGRID
Una volta completato l'upgrade del firmware su tutti i nodi alla versione corretta, esegui l'upgrade del software alla versione selezionata sui due nodi di amministrazione. Non è necessario eseguire l'upgrade dei nodi di archiviazione perché imitano ed estraggono il software sui nodi di amministrazione.
Segui queste istruzioni sui nodi amministratore per SG1000:
-
af-ae-objsadm01 -
af-ae-objsadm02
Recupera l'immagine di installazione dal bundle:
gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION tar -xvzf storage/gpc-system-object-storage/os.tar.gzI file sono disponibili in
storagegrid_os_install/.Vai a Advanced (Avanzate) -> Upload StorageGRID Software (Carica software StorageGRID). Fai clic su Rimuovi per rimuovere il software corrente e carica il nuovo pacchetto software
storagegrid_SG_INSTALL_VERSION_webscale_os_image.debe il checksum corrispondentestoragegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5come mostrato di seguito:
Una volta completato il caricamento del software, assicurati che il software per il nodo sia stato aggiornato alla versione selezionata:

15.2.4. Esegui l'upgrade di SANtricity
Tempo stimato: 1-1,5 ore
Prima di eseguire l'upgrade di SANtricity, controlla la versione del software SANtricity. Vai all'interfaccia utente SANtricity e fai clic su Supporto > CENTRO AGGIORNAMENTI > Inizia aggiornamento. Viene visualizzata la versione attuale di SANtricity.
Controlla la versione di installazione di SANtricity inclusa:
gdcloud artifacts tree oci | grep object-storage/santricity
L'output di esempio è simile al seguente:
│ │ │ └── gpc-system-object-storage/santricity:11.70.5R1
├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig
La versione è taggata nell'artefatto, in questo esempio, come 11.70.5R1.
Archivia il valore della versione in SANTRICITY_OS_VERSION.
Se la versione di SANtricity è precedente a SANTRICITY_OS_VERSION, continua con i passaggi successivi per eseguire l'upgrade della versione del sistema operativo SANtricity. In caso contrario, vai a Installazione.

15.2.4.1. Esegui l'upgrade di SANtricity OS
Segui queste istruzioni nell'interfaccia utente SANtricity per ogni nodo di archiviazione:
Recupera l'immagine di installazione dal bundle:
gdcloud artifacts extract oci santricity \ --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gzIl file di upgrade è disponibile in
santricity/SANTRICITY_OS_VERSION/.Vai a Assistenza > CENTRO AGGIORNAMENTI. Fai clic su Inizia l'upgrade da Aggiornamento software del sistema operativo SANtricity. Seleziona il file del software SANtricity OS facendo clic su Sfoglia. Carica il nuovo pacchetto software
RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlpcome mostrato:
Fai clic su Avvia e conferma di voler eseguire l'operazione.
Al termine dell'upgrade, verifica che la versione sia stata aggiornata:

15.3. Installazione
15.3.1. crea i Secret
Tempo stimato: 15-30 minuti
Per ottenere i valori per la creazione dei secret, utilizza la directory cellcfg:
Recupera i nomi di
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}'Esempio di output:
# 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-objs03Recupera l'indirizzo IP BMC per il nodo di archiviazione:
echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443Accedi a SANtricity System Manager dal link nell'output del comando precedente. Se non hai impostato la password in precedenza, crea una password ed esegui l'accesso:

- Se la password di SANtricity è stata persa, reimpostala tramite la console seriale StorageGRID E2860. Per connetterti alla porta seriale dell'array di dischi E2860, le impostazioni del terminale sono 115200 8N1.
Configura gli indirizzi del server NTP in SANtricity System Manager per entrambi i controller:

Recupera gli indirizzi del server NTP
kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP ```Seleziona Hardware in SANtricity System Manager.
Se la grafica mostra le unità, fai clic su Mostra retro del supporto. L'immagine cambia e mostra i controller anziché le unità.
Fai clic sul controller che vuoi configurare. Viene visualizzato il menu contestuale del controller.
Seleziona Configura server NTP. Si apre la finestra di dialogo Configura server Network Time Protocol (NTP).
Seleziona Voglio attivare NTP sul controller (A o B). Nella finestra di dialogo vengono visualizzate altre selezioni.
Seleziona Specifica manualmente gli indirizzi del server NTP. Inserisci l'indirizzo del server NTP principale utilizzando uno degli IP recuperati dal comando precedente.
Fai clic su Salva.
Aggiorna i secret che contengono le credenziali SANtricity per ciascuno dei nodi di archiviazione nel file cell.yaml. Se i secret non esistono, aggiungili seguendo questo modello:
apiVersion: v1 kind: Secret metadata: creationTimestamp: null name: <STORAGE_NODE_NAME>-santricity namespace: gpc-system stringData: password: 'PASSWORD' username: 'admin' type: OpaqueCrea i secret per ciascuno dei nodi di archiviazione elencati nel passaggio precedente:
kubectl create secret generic \ --namespace=gpc-system STORAGE_NODE_NAME-santricity \ --from-literal=username=admin \ --from-literal=password=PASSWORD
Convalida:
Esegui il comando seguente con ogni nodo di archiviazione elencato nel passaggio precedente. Stampa il nome utente Santricity impostato nel passaggio precedente. Convalida l'amministratore:
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echoEsegui il comando seguente con ogni nodo di archiviazione elencato nel passaggio precedente. Viene stampata la password di Santricity:
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echoEsegui questo comando per ottenere l'URL della GUI di gestione Santricity. Accedi a Santricity utilizzando il nome utente e la password:
echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
Risoluzione dei problemi:
Se i secret non vengono trovati durante l'esecuzione del passaggio di convalida 1 o 2, esegui di nuovo il passaggio kubectl create secret.
Se non riesci ad accedere alla GUI di gestione Santricity:
- Reimposta le credenziali di amministratore tramite la console seriale StorageGRID E2860.
- Esegui tutti i passaggi precedenti tranne l'ultimo.
Elimina il secret Santricity esistente di ogni nodo:
kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricityEsegui l'ultimo passaggio per ricreare il secret Santricity.
15.3.2. Bootstrap Object Storage
Il processo di bootstrapping di Object Storage varia tra la prima zona e le zone di unione. Fai riferimento alla sezione pertinente in base alla tua situazione specifica.
IMPORTANTE: prima di procedere, verifica che il bootstrapping dell'API globale della zona di ancoraggio sia terminato.
15.3.2.1. Bootstrap dell'archiviazione di oggetti nella prima zona
Esegui questo comando per avviare l'object storage:
gdcloud system objectstorage install --config /CELLCFG_PATH --first-zone --enable-objectstorage-hsm -v 5
15.3.2.2. Bootstrap dell'archiviazione di oggetti nella zona di unione
Risoluzione dei problemi:
- Quando i comandi Google Cloud CLI scadono o restituiscono errori, risolvi i problemi restituiti.
- Controlla il pod
gpc-system/obj-infra-cluster-cm-backend-controllerdi accesso per ulteriori dettagli sull'errore.
15.3.2.3. Bootstrap dell'archiviazione di oggetti nella zona di unione
Tempo stimato: 30-60 minuti
Il bootstrapping di Object Storage in una zona di unione richiede il coordinamento tra i riconciliatori di Object Storage nella zona di ancoraggio e nella zona di unione. Poiché durante il bootstrapping non esiste un canale di comunicazione protetto e controllato tra due zone per i riconciliatori, l'IO deve facilitare manualmente la comunicazione protetta per i riconciliatori Object Storage tra due zone.
- Concedi a te stesso il ruolo predefinito Amministratore cluster nel cluster di zona root-admin e nel cluster globale nella zona di ancoraggio. Per i dettagli, consulta il runbook IAM.
In alternativa, applica questi due binding dei ruoli nella zona di ancoraggio:
Nell'API globale:
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
Nel cluster di amministrazione principale:
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
Esegui il comando nella zona di ancoraggio per ottenere l'IP del server DNS e annotalo per un utilizzo successivo:
sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'Configura il resolver stub DNS della zona di unione in modo che si colleghi alla zona di ancoraggio:
Disattiva e arresta systemd-resolved
sh systemctl disable systemd-resolved.service --nowElimina il file resolv.conf se esiste
sh rm -f /etc/resolv.confScrivi l'IP del server DNS della zona di ancoraggio nel file resolv.conf della zona di unione
sh vim /etc/resolv.confContenuto del file /etc/resolv.conf di esempio:sh nameserver 10.200.40.0
Crea il file YAML
TokenRequestnella zona di unione.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_PATHSostituisci
JOINING_ZONE_NAMEcon il nome della zona del questionario di acquisizione del cliente, come descritto nella nota alla fine della sezione.Trasferisci il file YAML TokenRequest nella zona di ancoraggio.
scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATHApplica il file YAML TokenRequest al cluster globale root-admin nella zona di ancoraggio.
kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATHCrea il file YAML del token nella zona di ancoraggio.
gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATHTrasferisci il file YAML del token alla zona di unione.
scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATHApplica il file YAML del token al cluster KIND nella zona di unione.
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATHCrea il file YAML ObjectStorageBootstrap nella zona di ancoraggio.
gdcloud system objectstorage create-bootstrap --output-file OBJECT_STORAGE_BOOTSTRAP_YAML_PATHTrasferisci il file YAML ObjectStorageBootstrap nella zona di unione.
scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATHApplica il file YAML ObjectStorageBootstrap al cluster KIND nella zona di unione.
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATHEsegui il bootstrap dell'archiviazione di oggetti nella zona di unione.
gdcloud system objectstorage install --config /CELLCFG_PATH --add-zone --enable-objectstorage-hsm -v 5