El dispositivo air-gapped de Google Distributed Cloud (GDC) transfiere datos arbitrarios a un entorno air-gapped de Google Distributed Cloud y desde él. Las transferencias se pueden iniciar manualmente o se pueden programar para que se produzcan automáticamente en un intervalo determinado.
Ejemplos de transferencias:
- Descargar actualizaciones de software o cargas de trabajo de clientes actualizadas
- Subir datos de clientes, métricas de dispositivos o registros de seguridad, auditoría y operaciones de dispositivos
- Capturas de copias de seguridad de datos
La herramienta storage-transfer transfiere datos y se distribuye en una imagen para usarla en contenedores en ejecución en el clúster.
Fuentes de datos
La herramienta de transferencia de almacenamiento ofrece flexibilidad en las condiciones de funcionamiento del dispositivo con air gap de GDC. Las APIs compatibles con S3 pueden acceder a destinos de almacenamiento expuestos externamente e internos. La herramienta también admite fuentes del sistema de archivos local y de Cloud Storage.
El operador es responsable de mantener el control de las claves de acceso y de cualquier otra credencial, secreto o dato sensible necesario para la autenticación con el fin de conectar el dispositivo aislado de GDC a redes externas. El operador también es responsable de la configuración de la red externa.
Consulta cómo crear segmentos de almacenamiento para crear y acceder al almacenamiento externo.
Almacenamiento local
El almacenamiento local se encuentra en el entorno de contenedor del pod e incluye el sistema de archivos temporal o los volúmenes montados. La cuenta de servicio vinculada al pod debe tener acceso a todos los destinos de montaje al montar volúmenes.
Almacenamiento de S3
Se puede acceder al almacenamiento disponible en la red a través de la API compatible con S3. El servicio puede ser externo o solo estar expuesto en la red de clústeres. Debes proporcionar una URL accesible y credenciales estandarizadas montadas mediante un secreto de Kubernetes.
Se accede a los datos definidos de almacenamiento de objetos y multinodo a través de la API de S3. Consulta las secciones correspondientes para configurar el almacenamiento multinodo y el almacenamiento de objetos en el dispositivo aislado de GDC.
Almacenamiento en la nube
Debes proporcionar una URL accesible y credenciales estandarizadas montadas mediante un secreto.
Si accedes a un segmento de Cloud Storage con controles de acceso uniformes, debes definir la marca --bucket-policy-only en true.
Credenciales
Se necesita un secreto de Kubernetes para usar el servicio de transferencia de almacenamiento en las definiciones de origen o destino de S3 o GCS. Se pueden proporcionar con una cuenta de servicio remota o una cuenta de usuario.
Cuando se usan secretos en una definición de Job o CronJob, el JobSpec debe adjuntarse a una ServiceAccount de Kubernetes que tenga acceso a los secretos.
Crea una cuenta de servicio que use la transferencia y, a continuación, añade permisos a la cuenta de servicio para leer y escribir secretos mediante roles y enlaces de roles. Puedes no crear una cuenta de servicio si la cuenta de servicio predeterminada de tu espacio de nombres o la cuenta de servicio personalizada ya tienen permisos.
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
Cuentas de servicio remotas
Para obtener las credenciales de la cuenta de servicio de Cloud Storage y hacer una transferencia, consulta https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account.
Estas credenciales deben almacenarse en un secreto en el campo service-account-key.
A continuación se muestra un ejemplo:
apiVersion: v1
data:
service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
name: gcs-secret
namespace: NAMESPACE
type: Opaque
Cuentas de usuario
Puedes usar una cuenta de usuario para autenticarte con segmentos compatibles con S3, pero no con segmentos de Cloud Storage. Debes especificar el argumento --src_type o --dst_type como 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
Haz los cambios siguientes:
NAMESPACE: el nombre del espacio de nombres en el que crearás la definición de Job.SECRET_NAME: el nombre del secreto que estás creando.ACCESS_KEY_ID: el valor que se encuentra en el campo Clave de acceso de la consola Google Cloud . Cuando se configura el almacenamiento de objetos, se llama access-key-id.ACCESS_KEY: el valor que se encuentra en el campo Secreto de la consola de Google Cloud . Al configurar el almacenamiento de objetos, se trata de la clave secreta o del secreto.
Certificados
Proporciona certificados para la validación en el trabajo con un secreto de Kubernetes
que contenga una clave de datos 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.
Los certificados se pueden proporcionar haciendo referencia a la herramienta mediante los argumentos src_ca_certificate_reference y dst_ca_certificate_reference en el formato NAMESPACE/SECRET_NAME. Por ejemplo:
...
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
Para el almacenamiento de S3 en el dispositivo, puedes usar directamente el secreto trust-store-root-ext como certificado de CA. Por ejemplo:
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
Opcional: Define un LoggingTarget para ver los registros en Loki
De forma predeterminada, los registros de los trabajos solo se pueden ver en los recursos de Kubernetes y no están disponibles en la pila de observabilidad. Para poder verlos, deben configurarse con un LoggingTarget.
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
Definir un trabajo integrado
Los usuarios gestionan sus propios recursos de trabajo. Para las transferencias de datos de un solo uso, define un Job. El trabajo crea un pod para ejecutar el contenedor storage-transfer.
Ejemplo de 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
Definir una tarea cron integrada
Los usuarios gestionan sus propios recursos de CronJob definidos. Si usas un CronJob integrado, puedes programar transferencias de datos periódicas.
Un ejemplo de CronJob que consigue una transferencia de datos automatizada:
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 recomienda definir concurrencyPolicy como Forbid para evitar la contención de datos.
CronJob, Secret y PersistentVolumeClaim deben estar en el mismo espacio de nombres.
Priorizar tareas de datos
La prioridad de las tareas de datos se puede definir de varias formas que no son mutuamente excluyentes. Puedes definir programaciones de tareas menos frecuentes en la definición de CronJob.
Los trabajos también se pueden ordenar mediante InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) que siempre se ejecutan en el orden de definición. Sin embargo, todos los contenedores deben ejecutarse correctamente. Usa InitContainers para dar mayor prioridad a un trabajo o gestionar la contención de datos definiendo dos o más InitContainers con definiciones de origen y destino reflejadas.
Ejemplo de jobTemplate que consigue una transferencia de datos ordenada:
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
El contenedor A-to-B se ejecuta antes que B-to-A. En este ejemplo se consigue tanto la sincronización bidireccional como el orden de los trabajos.