L'appliance Google Distributed Cloud (GDC) sous air gap transfère des données arbitraires vers et depuis un environnement Google Distributed Cloud sous air gap. Les transferts peuvent être lancés manuellement ou configurés pour se produire automatiquement à un intervalle défini.
Exemples de transferts :
- Télécharger des mises à jour logicielles ou des charges de travail client mises à jour
- Importer des données client, des métriques d'appareil ou des journaux d'audit, de sécurité et d'opérations des appareils
- Instantanés des données de sauvegarde
L'outil storage-transfer transfère les données et est distribué sur une image pour être utilisé dans les conteneurs en cours d'exécution sur le cluster.
Sources de données
L'outil de transfert de stockage offre une grande flexibilité en ce qui concerne les conditions de fonctionnement de l'appliance GDC sous air gap. Les API compatibles avec S3 peuvent accéder aux cibles de stockage internes et exposées en externe. L'outil est également compatible avec les sources de système de fichiers local et Cloud Storage.
L'opérateur est responsable du contrôle des clés d'accès et de tous les autres identifiants, secrets ou données sensibles requis pour l'authentification afin de connecter l'appliance GDC isolée du réseau à des réseaux externes. L'opérateur est également responsable de la configuration du réseau externe.
Pour créer un stockage externe et y accéder, consultez Créer des buckets de stockage.
Stockage en local
Le stockage local est contenu dans l'environnement de conteneur du pod et inclut le système de fichiers temporaire ou les volumes montés. Le ServiceAccount lié au pod doit avoir accès à toutes les cibles de montage lors du montage des volumes.
Stockage S3
Le stockage réseau disponible est accessible via l'API compatible S3. Le service peut être externe ou uniquement exposé au sein du réseau du cluster. Vous devez fournir une URL accessible et des identifiants standardisés installés à l'aide d'un secret Kubernetes.
Les données définies pour le stockage d'objets et les nœuds multiples sont accessibles via l'API S3. Consultez les sections correspondantes pour configurer le stockage multinœud et le stockage d'objets dans l'appliance GDC isolée.
Stockage dans le cloud
Vous devez fournir une URL accessible et des identifiants standardisés montés à l'aide d'un secret.
Si vous accédez à un bucket Cloud Storage avec des contrôles d'accès uniformes, vous devez définir l'indicateur --bucket-policy-only sur true.
Identifiants
Un secret Kubernetes est requis pour utiliser le service de transfert de stockage pour les définitions de source ou de destination S3 ou GCS. Ils peuvent être fournis avec un compte de service ou un compte utilisateur distant.
Lorsque vous utilisez des secrets dans une définition Job ou CronJob, JobSpec doit être associé à un compte de service Kubernetes ayant accès aux secrets.
Créez un ServiceAccount utilisé par le transfert, puis ajoutez des autorisations au ServiceAccount pour lire et écrire des secrets à l'aide de rôles et de liaisons de rôles. Vous pouvez choisir de ne pas créer de ServiceAccount si votre ServiceAccount d'espace de noms par défaut ou votre ServiceAccount personnalisé disposent déjà d'autorisations.
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
Comptes de service distants
Pour obtenir les identifiants du compte de service Cloud Storage afin d'effectuer un transfert, consultez https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account.
Ces identifiants doivent être stockés dans un secret dans le champ service-account-key.
Voici un exemple :
apiVersion: v1
data:
service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
name: gcs-secret
namespace: NAMESPACE
type: Opaque
Comptes utilisateur
Vous pouvez utiliser un compte utilisateur pour l'authentification avec des buckets compatibles avec S3, mais pas avec des buckets Cloud Storage. Vous devez spécifier l'argument --src_type ou --dst_type en tant que 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
Remplacez les éléments suivants :
NAMESPACE: nom de l'espace de noms dans lequel vous allez créer la définition du job.SECRET_NAME: nom du secret que vous créez.ACCESS_KEY_ID: valeur trouvée dans le champ Clé d'accès de la console Google Cloud . Lorsque vous configurez Object Storage, il s'agit de l'ID de clé d'accès.ACCESS_KEY: valeur trouvée dans le champ Secret de la console Google Cloud . Lors de la configuration pour Object Storage, il s'agit de la clé secrète ou du secret.
Certificats
Fournissez des certificats pour la validation dans le job avec un secret Kubernetes contenant une clé de données 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.
Les certificats peuvent être fournis en référence à l'outil à l'aide des arguments src_ca_certificate_reference et dst_ca_certificate_reference au format NAMESPACE/SECRET_NAME. Exemple :
...
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
Pour le stockage S3 dans l'appliance, vous pouvez utiliser directement le secret trust-store-root-ext comme certificat CA. Exemple :
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
Facultatif : Définissez un LoggingTarget pour afficher les journaux dans Loki
Par défaut, les journaux des jobs ne sont visibles que dans les ressources Kubernetes. Ils ne sont pas disponibles dans la pile d'observabilité et doivent être configurés avec un LoggingTarget pour être visibles.
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
Définir un job intégré
Les utilisateurs gèrent leurs propres ressources Job. Pour les transferts de données à usage unique, définissez un Job. Le job crée un pod pour exécuter le conteneur storage-transfer.
Exemple 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
Définir un CronJob intégré
Les utilisateurs gèrent leurs propres ressources CronJob définies. L'utilisation d'un CronJob intégré permet de planifier régulièrement les transferts de données.
Voici un exemple de CronJob permettant d'automatiser le transfert de données :
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 recommande de définir concurrencyPolicy sur Forbid pour éviter les conflits de données.
CronJob, Secret et PersistentVolumeClaim doivent se trouver dans le même espace de noms.
Hiérarchiser les jobs de données
Il existe plusieurs façons de définir la priorité des jobs de données, qui ne sont pas mutuellement exclusives. Vous pouvez définir des planifications de tâches moins fréquentes dans la définition CronJob.
Les jobs peuvent également être ordonnés à l'aide d'InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/), qui s'exécutent toujours dans l'ordre de définition. Toutefois, tous les conteneurs doivent s'exécuter correctement. Utilisez InitContainers pour donner une priorité plus élevée à un job ou pour gérer la contention des données en définissant deux ou plusieurs InitContainers avec des définitions de source et de destination en miroir.
Voici un exemple de jobTemplate permettant d'effectuer un transfert de données ordonné :
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
Le conteneur A-to-B s'exécute avant B-to-A. Cet exemple permet à la fois une bisynchronisation et un ordre des jobs.