Il dispositivo appliance con air gap di Google Distributed Cloud (GDC) trasferisce dati arbitrari da e verso un ambiente con air gap di Google Distributed Cloud. I trasferimenti possono essere avviati manualmente o impostati per essere eseguiti automaticamente a un intervallo prestabilito.
Esempi di trasferimenti:
- Scaricare aggiornamenti software o workload dei clienti aggiornati
- Carica dati dei clienti, metriche dei dispositivi o log di sicurezza, controllo e operazioni dei dispositivi
- Snapshot dei dati di backup
Lo strumento storage-transfer trasferisce i dati e viene distribuito su un'immagine da utilizzare per l'esecuzione di container sul cluster.
Origini dati
Lo strumento di trasferimento dello spazio di archiviazione offre flessibilità per le condizioni operative dell'appliance GDC air-gapped. Le API compatibili con S3 possono accedere a target di archiviazione interni ed esposti esternamente. Lo strumento supporta anche le origini del file system locale e Cloud Storage.
L'operatore è responsabile del mantenimento del controllo delle chiavi di accesso e di qualsiasi altra credenziale, segreto o dato sensibile richiesto per l'autenticazione per connettere l'appliance GDC air-gapped a reti esterne. L'operatore è anche responsabile della configurazione della rete esterna.
Consulta Creare bucket di archiviazione per creare e accedere allo spazio di archiviazione esterno.
Archiviazione locale
Lo spazio di archiviazione locale è contenuto nell'ambiente container del pod e include il file system temporaneo o i volumi montati. Il service account associato al pod deve avere accesso a tutti i target di montaggio durante il montaggio dei volumi.
Spazio di archiviazione S3
Lo spazio di archiviazione disponibile in rete è accessibile tramite l'API compatibile con S3. Il servizio può essere esterno o esposto solo all'interno della rete del cluster. Devi fornire un URL accessibile e credenziali standardizzate montate utilizzando un secret di Kubernetes.
Si accede ai dati definiti di archiviazione di oggetti e multi-nodo tramite l'API S3. Consulta le sezioni pertinenti per configurare l'archiviazione multimodale e l'archiviazione di oggetti all'interno dell'appliance GDC air-gapped.
Spazio di archiviazione sul cloud
Devi fornire un URL accessibile e credenziali standardizzate montate utilizzando un secret.
Se accedi a un bucket Cloud Storage con controlli dell'accesso uniformi, devi
impostare il flag --bucket-policy-only su true.
Credenziali
È necessario un secret Kubernetes per utilizzare il servizio di trasferimento dello spazio di archiviazione per le definizioni di origine o destinazione S3 o GCS. Questi possono essere forniti con un account di servizio remoto o un account utente.
Quando utilizzi i secret in una definizione di Job o CronJob, JobSpec deve essere collegato a un ServiceAccount Kubernetes che abbia accesso ai secret.
Crea un service account utilizzato dal trasferimento, quindi aggiungi le autorizzazioni al service account per leggere e scrivere i secret utilizzando ruoli e associazioni di ruoli. Puoi scegliere di non creare un ServiceAccount se il ServiceAccount dello spazio dei nomi predefinito o il ServiceAccount personalizzato dispone già delle autorizzazioni.
apiVersion: v1
kind: ServiceAccount
metadata:
name: transfer-service-account
namespace: NAMESPACE
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: read-secrets-role
namespace: NAMESPACE
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-secrets-rolebinding
namespace: NAMESPACE
subjects:
- kind: ServiceAccount
name: transfer-service-account
namespace: NAMESPACE
roleRef:
kind: Role
name: read-secrets-role
apiGroup: rbac.authorization.k8s.io
Service account remoti
Per ottenere le credenziali account di servizio Cloud Storage per eseguire un trasferimento, consulta la pagina
https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account.
Queste credenziali devono essere archiviate in un secret nel campo service-account-key.
Ecco un esempio:
apiVersion: v1
data:
service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
name: gcs-secret
namespace: NAMESPACE
type: Opaque
Account utente
Puoi utilizzare un account utente per l'autenticazione con i bucket compatibili con S3, non con i bucket Cloud Storage. Devi specificare l'argomento --src_type o --dst_type
come s3.
kubectl create secret -n NAMESPACE generic S3_CREDENTIAL_SECRET_NAME \
--from-literal=access-key-id=ACCESS_KEY_ID
--from-literal=access-key=ACCESS_KEY
Sostituisci quanto segue:
NAMESPACE: il nome dello spazio dei nomi in cui creerai la definizione del job.SECRET_NAME: il nome del secret che stai creando.ACCESS_KEY_ID: il valore trovato nel campo Chiave di accesso nella console Google Cloud . Quando configuri l'archiviazione di oggetti, questo valore viene chiamato access-key-id.ACCESS_KEY: il valore trovato nel campo Secret nella console Google Cloud . Quando configuri Object Storage, questo è il secret-key o Secret.
Certificati
Fornisci i certificati per la convalida nel job con un secret Kubernetes
contenente una chiave di dati ca.crt.
apiVersion: v1
kind: Secret
metadata:
name: SRC_CERTIFICATE_SECRET_NAME
namespace: NAMESPACE
data:
ca.crt : BASE_64_ENCODED_SOURCE_CERTIFICATE
---
apiVersion: v1
kind: Secret
metadata:
name: DST_CERTIFICATE_SECRET_NAME
namespace: NAMESPACE
data:
ca.crt : BASE_64_ENCODED_DESTINATION_CERTIFICATE # Can be same OR different than source certificate.
I certificati possono essere forniti facendo riferimento allo strumento utilizzando gli argomenti
src_ca_certificate_reference e dst_ca_certificate_reference nel formato
NAMESPACE/SECRET_NAME. Ad esempio:
...
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
command:
- /storage-transfer
args:
...
- --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
- --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME
Per l'archiviazione S3 nell'appliance, puoi utilizzare direttamente il
segreto trust-store-root-ext come certificato CA. Ad esempio:
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
command:
- /storage-transfer
args:
- --src_type=s3
- --src_ca_certificate_reference=NAMESPACE/trust-store-root-ext
(Facoltativo) Definisci un LoggingTarget per visualizzare i log in Loki
Per impostazione predefinita, i log dei job sono visibili solo nelle risorse Kubernetes e non sono disponibili nello stack di osservabilità e devono essere configurati con un LoggingTarget per essere visibili.
apiVersion: logging.gdc.goog/v1alpha1
kind: LoggingTarget
metadata:
namespace: NAMESPACE # Same namespace as your transfer job
name: logtarg1
spec:
# Choose matching pattern that identifies pods for this job
# Optional
# Relationship between different selectors: AND
selector:
# Choose pod name prefix(es) to consider for this job
# Observability platform will scrape all pods
# where names start with specified prefix(es)
# Should contain [a-z0-9-] characters only
# Relationship between different list elements: OR
matchPodNames:
- data-transfer-job # Choose the prefix here that matches your transfer job name
serviceName: transfer-service
Definisci un job integrato
Gli utenti gestiscono le proprie risorse di lavoro. Per i trasferimenti di dati monouso, definisci un Job. Il job crea un pod per eseguire il container storage-transfer.
Un esempio di job:
apiVersion: batch/v1
kind: Job
metadata:
name: data-transfer-job
namespace: NAMESPACE
spec:
template:
spec:
restartPolicy: Never
serviceAccountName: transfer-service-account,
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
command:
- /storage-transfer
args:
- --src_path=/src
- --src_type=local
- --dst_endpoint=https://your-dst-endpoint.com
- --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --dst_path=/FULLY_QUALIFIED_BUCKET_NAME/BUCKET_PATH
- --dst_type=gcs
- --bucket_policy_only=true
- --bandwidth_limit=10M #Optional of the form '10K', '100M', '1G' bytes per second
volumeMounts:
- mountPath: /src
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: data-transfer-source
Definisci un CronJob integrato
Gli utenti gestiscono le proprie risorse CronJob definite. L'utilizzo di un CronJob integrato consente trasferimenti di dati pianificati regolarmente.
Un esempio di CronJob che esegue un trasferimento dei dati automatizzato:
apiVersion: batch/v1
kind: CronJob
metadata:
name: data-transfer-cronjob
namespace: NAMESPACE
spec:
schedule: "* * * * *"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
serviceAccountName: transfer-service-account
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
command:
- /storage-transfer
args:
- --src_path=LOCAL_PATH
- --src_type=local
- --dst_endpoint=https://your-dst-endpoint.com
- --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --dst_path=/FULLY_QUALIFIED_BUCKET_NAME/BUCKET_PATH
- --dst_type=gcs
- --bucket_policy_only=true
volumeMounts:
- mountPath: LOCAL_PATH
name: source
restartPolicy: Never
volumes:
- name: source
persistentVolumeClaim:
claimName: data-transfer-source
Google consiglia di impostare concurrencyPolicy su Forbid per evitare la contesa dei dati.
CronJob, Secret e PersistentVolumeClaim devono trovarsi nello stesso spazio dei nomi.
Dai la priorità ai job di dati
L'impostazione della priorità per i job di dati può essere eseguita in diversi modi non mutualmente esclusivi. Puoi impostare pianificazioni dei job meno frequenti nella definizione di CronJob.
I job possono essere ordinati anche utilizzando InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) che vengono sempre eseguiti nell'ordine di definizione. Tuttavia, tutti i container devono essere eseguiti correttamente. Utilizza InitContainers per dare una priorità più alta a un job o gestire la contesa dei dati definendo due o più InitContainers con definizioni di origine e destinazione speculari.
Un esempio di jobTemplate che esegue il trasferimento dei dati in ordine:
apiVersion: batch/v1
kind: CronJob
metadata:
name: ordered-data-transfer-cronjob
namespace: NAMESPACE
spec:
schedule: "* * * * *"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
containers:
- name: job-complete
image: whalesay
command: ["sh", "-c", "echo Job Completed."]
initContainers:
- name: A-to-B
image: gcr.io/private-cloud-staging/storage-transfer:latest
command: [/storage-transfer]
args:
- --src_type=s3
- --src_endpoint=ENDPOINT_A
- --src_path=/example-bucket
- --src_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
- --dst_type=s3
- --dst_endpoint=ENDPOINT_B
- --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME
- --dst_path=/example-bucket
- name: B-to-A
image: gcr.io/private-cloud-staging/storage-transfer:latest
command: [/storage-transfer]
args:
- --src_type=s3
- --src_endpoint=ENDPOINT_B
- --src_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --src_ca_certificate_reference=NAMESPACE/SRC_CERTIFICATE_SECRET_NAME
- --src_path=/example-bucket
- --dst_type=s3
- --dst_endpoint=ENDPOINT_A
- --dst_credentials=NAMESPACE/CREDENTIAL_SECRET_NAME
- --dst_ca_certificate_reference=NAMESPACE/DST_CERTIFICATE_SECRET_NAME
- --dst_path=/example-bucket
Il container A-to-B viene eseguito prima di B-to-A. Questo esempio consente sia la sincronizzazione bidirezionale sia l'ordinamento dei lavori.