O dispositivo com isolamento físico do Google Distributed Cloud (GDC) transfere dados arbitrários para e de um ambiente com isolamento físico do Google Distributed Cloud. As transferências podem ser iniciadas manualmente ou definidas para ocorrer automaticamente em um intervalo definido.
Exemplos de transferências:
- Baixar atualizações de software ou cargas de trabalho atualizadas do cliente
- Fazer upload de dados de clientes, métricas de dispositivos ou registros de segurança, auditoria e operações de dispositivos
- Snapshots de dados de backup
A ferramenta storage-transfer transfere dados e é distribuída em uma imagem para uso em contêineres em execução no cluster.
Fontes de dados
A ferramenta Storage Transfer Service oferece flexibilidade com as condições operacionais do dispositivo isolado fisicamente do GDC. As APIs compatíveis com o S3 podem acessar destinos de armazenamento interno e expostos externamente. A ferramenta também é compatível com fontes do sistema de arquivos local e do Cloud Storage.
O operador é responsável por manter o controle das chaves de acesso e de quaisquer outras credenciais, secrets ou dados sensíveis necessários para a autenticação e conexão do dispositivo isolado do GDC a redes externas. O operador também é responsável pela configuração da rede externa.
Consulte Criar buckets de armazenamento para criar e acessar o armazenamento externo.
Armazenamento local
O armazenamento local está contido no ambiente de contêiner do pod e inclui o sistema de arquivos temporário ou volumes montados. A ServiceAccount vinculada ao pod precisa ter acesso a todos os destinos de montagem ao montar volumes.
Armazenamento do S3
O armazenamento disponível na rede pode ser acessado pela API compatível com S3. O serviço pode ser externo ou exposto apenas na rede do cluster. Você precisa fornecer um URL acessível e credenciais padronizadas ativadas usando um secret do Kubernetes.
Os dados definidos de armazenamento de objetos e de vários nós são acessados pela API S3. Consulte as seções relevantes para configurar o armazenamento de vários nós e o armazenamento de objetos no appliance isolado do GDC.
Armazenamento em nuvem
Você precisa fornecer um URL acessível e credenciais padronizadas montadas usando um Secret.
Se você estiver acessando um bucket do Cloud Storage com controles de acesso uniformes, defina a flag --bucket-policy-only como true.
Credenciais
Um Secret do Kubernetes é necessário para usar o serviço de transferência do Cloud Storage para definições de origem ou destino do S3 ou do GCS. Eles podem ser fornecidos com uma conta de serviço remota ou uma conta de usuário.
Ao usar secrets em uma definição de Job ou CronJob, o JobSpec precisa ser anexado a uma ServiceAccount do Kubernetes que tenha acesso aos secrets.
Crie uma ServiceAccount usada pela transferência e adicione permissões a ela para ler e gravar secrets usando papéis e vinculações de papéis. Você pode optar por não criar uma ServiceAccount se a ServiceAccount padrão do namespace ou a ServiceAccount personalizada já tiver permissões.
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
Contas de serviço remotas
Para conseguir credenciais da conta de serviço do Cloud Storage e fazer uma transferência, acesse
https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account.
Essas credenciais precisam ser armazenadas em um secret no campo service-account-key.
Veja um exemplo:
apiVersion: v1
data:
service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
name: gcs-secret
namespace: NAMESPACE
type: Opaque
Contas de usuário
É possível usar uma conta de usuário para autenticação com buckets compatíveis com o S3, não com o Cloud Storage. É necessário especificar o argumento --src_type ou --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
Substitua:
NAMESPACE: o nome do namespace em que você vai criar a definição de job.SECRET_NAME: o nome do secret que você está criando.ACCESS_KEY_ID: o valor encontrado no campo Chave de acesso no console do Google Cloud . Ao configurar o Object Storage, isso é chamado de access-key-id.ACCESS_KEY: o valor encontrado no campo Secret no console do Google Cloud . Ao configurar para o Object Storage, essa é a secret-key ou o Secret.
Certificados
Forneça certificados para validação no job com um secret do Kubernetes
que contenha uma chave de dados 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.
Os certificados podem ser fornecidos por referência à ferramenta usando os argumentos
src_ca_certificate_reference e dst_ca_certificate_reference no formato
NAMESPACE/SECRET_NAME. Exemplo:
...
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 o armazenamento S3 no appliance, use diretamente o
segredo trust-store-root-ext como o certificado da CA. Exemplo:
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: defina um LoggingTarget para ver os registros no Loki
Por padrão, os registros dos jobs só podem ser visualizados nos recursos do Kubernetes e não estão disponíveis na pilha de observabilidade. Eles precisam ser configurados com um LoggingTarget para serem visualizados.
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 um job integrado
Os usuários gerenciam os próprios recursos de Job. Para transferências de dados de uso único, defina um Job. O job cria um pod para executar o contêiner storage-transfer.
Exemplo 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 um CronJob integrado
Os usuários gerenciam os próprios recursos definidos do CronJob. Usar um CronJob integrado permite transferências de dados programadas regularmente.
Exemplo de um CronJob que realiza uma transferência de dados 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
O Google recomenda definir concurrencyPolicy como Forbid para evitar disputas de dados.
O CronJob, o Secret e o PersistentVolumeClaim precisam estar no mesmo namespace.
Priorizar jobs de dados
É possível definir a prioridade dos jobs de dados de várias maneiras que não são mutuamente exclusivas. É possível definir programações de jobs menos frequentes na definição do CronJob.
Os jobs também podem ser ordenados usando InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) que sempre são executados na ordem de definição. No entanto, todos os contêineres precisam ser executados com sucesso. Use InitContainers para dar maior prioridade a um job ou gerenciar a disputa de dados definindo dois ou mais InitContainers com definições de origem e destino espelhadas.
Um exemplo de jobTemplate que realiza a transferência de dados 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
O contêiner A-to-B é executado antes de B-to-A. Este exemplo realiza uma
bisync e uma ordenação de jobs.