El dispositivo aislado de Google Distributed Cloud (GDC) transfiere datos arbitrarios hacia y desde un entorno aislado de Google Distributed Cloud. Las transferencias se pueden iniciar de forma manual o configurar para que se realicen automáticamente en un intervalo establecido.
Ejemplos de transferencias:
- Descargar actualizaciones de software o cargas de trabajo actualizadas de los clientes
- Subir datos del cliente, métricas del dispositivo o registros de seguridad, auditoría y operaciones del dispositivo
- Instantáneas de copias de seguridad de datos
La herramienta storage-transfer transfiere datos y se distribuye en una imagen para usarse en contenedores en ejecución en el clúster.
Fuentes de datos
La herramienta de transferencia de almacenamiento permite flexibilidad con las condiciones de funcionamiento del dispositivo aislado de GDC. Las APIs compatibles con S3 pueden acceder a destinos de almacenamiento internos y expuestos de forma externa. La herramienta también admite fuentes de sistemas de archivos locales y de Cloud Storage.
El operador es responsable de mantener el control de las claves de acceso y cualquier otra credencial, secreto o dato sensible que se requiera para la autenticación y la conexión del dispositivo aislado de GDC a redes externas. El operador también es responsable de la configuración de la red externa.
Consulta Crea buckets de almacenamiento para crear y acceder al almacenamiento externo.
Almacenamiento local
El almacenamiento local se encuentra en el entorno del contenedor del pod y comprende el sistema de archivos temporales o los volúmenes activados. La ServiceAccount vinculada al pod debe tener acceso a todos los destinos de activación cuando se activan volúmenes.
Almacenamiento en S3
Se puede acceder al almacenamiento de red disponible a través de la API compatible con S3. El servicio puede ser externo o solo estar expuesto dentro de la red del clúster. Debes proporcionar una URL accesible y credenciales estandarizadas activadas con un Secret de Kubernetes.
Se accede a los datos definidos de almacenamiento de objetos y varios nodos a través de la API de S3. Consulta las secciones pertinentes para configurar el almacenamiento de varios nodos y el almacenamiento de objetos en el dispositivo aislado de GDC.
Almacenamiento en la nube
Debes proporcionar una URL accesible y credenciales estandarizadas que se activen con un Secret.
Si accedes a un bucket de Cloud Storage con controles de acceso uniformes, debes establecer la marca --bucket-policy-only en true.
Credenciales
Se requiere un Secret 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 Secrets en una definición de Job o CronJob, el JobSpec debe adjuntarse a un ServiceAccount de Kubernetes que tenga acceso a los Secrets.
Crea una ServiceAccount que se use para la transferencia y, luego, agrega permisos a la ServiceAccount para leer y escribir secretos con roles y vinculaciones de roles. Puedes optar por no crear una ServiceAccount si tu ServiceAccount predeterminada del espacio de nombres o tu ServiceAccount 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 credenciales de la cuenta de servicio de Cloud Storage y realizar 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 la autenticación con buckets compatibles con S3, no con buckets 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
Reemplaza lo siguiente:
NAMESPACE: Es el nombre del espacio de nombres en el que crearás la definición del trabajo.SECRET_NAME: Es el nombre del Secret que crearás.ACCESS_KEY_ID: Es el valor que se encuentra en el campo Clave de acceso de la consola de Google Cloud . Cuando se configura Object Storage, se denomina access-key-id.ACCESS_KEY: Es el valor que se encuentra en el campo Secret de la consola de Google Cloud . Cuando se configura Object Storage, esta es la clave secreta o el secreto.
Certificados
Proporciona certificados para la validación en el trabajo con un Secret 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 como referencia a la herramienta con 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 de 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. Además, se deben configurar con un LoggingTarget para que se puedan ver.
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
Define un trabajo integrado
Los usuarios administran sus propios recursos de Job. Para las transferencias de datos de un solo uso, define un Job. El objeto Job crea un Pod para ejecutar el contenedor de Storage Transfer.
Ejemplo de un trabajo:
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
Define un CronJob integrado
Los usuarios administran sus propios recursos de CronJob definidos. Usar un CronJob integrado permite transferencias de datos programadas con regularidad.
Ejemplo de un CronJob que logra 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 establecer concurrencyPolicy en Forbid para evitar la contención de datos.
El CronJob, el Secret y la PersistentVolumeClaim deben estar en el mismo espacio de nombres.
Prioriza los trabajos de datos
La prioridad de los trabajos de datos se puede establecer de varias maneras que no son mutuamente excluyentes. Puedes establecer programas de trabajos menos frecuentes en la definición de CronJob.
Los trabajos también se pueden ordenar con 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 darle mayor prioridad a un trabajo o administrar la contención de datos definiendo dos o más InitContainers con definiciones de origen y destino duplicadas.
Un ejemplo de jobTemplate que logra la 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 logra tanto la sincronización de bits como el orden de los trabajos.