O dispositivo de appliance isolado do Google Distributed Cloud (GDC) transfere dados arbitrários de e para um ambiente isolado do Google Distributed Cloud. As transferências podem ser iniciadas manualmente ou definidas para ocorrerem automaticamente num intervalo definido.
Exemplos de transferências:
- Transferir atualizações de software ou cargas de trabalho de clientes atualizadas
- Carregue dados de clientes, métricas de dispositivos ou registos de segurança, auditoria e operações de dispositivos
- Instantâneos de dados de cópia de segurança
A ferramenta de transferência de armazenamento transfere dados e é distribuída numa imagem para utilização em contentores em execução no cluster.
Origens de dados
A ferramenta de transferência de armazenamento permite flexibilidade com as condições de funcionamento do dispositivo isolado do GDC. As APIs compatíveis com S3 podem aceder a destinos de armazenamento expostos externamente e internos. A ferramenta também suporta o sistema de ficheiros local e origens do Cloud Storage.
O operador é responsável por manter o controlo das chaves de acesso e de quaisquer outras credenciais, segredos ou dados confidenciais necessários para a autenticação de forma a ligar o dispositivo isolado do GDC a redes externas. O operador também é responsável pela configuração da rede externa.
Consulte o artigo Crie contentores de armazenamento para criar e aceder ao armazenamento externo.
Armazenamento local
O armazenamento local está contido no ambiente do contentor do pod e inclui o sistema de ficheiros temporário ou os volumes montados. A ServiceAccount associada ao pod tem de ter acesso a todos os destinos de montagem ao montar volumes.
Armazenamento S3
O armazenamento disponível na rede é acessível através da API compatível com S3. O serviço pode ser externo ou apenas exposto na rede do cluster. Tem de fornecer um URL acessível e credenciais padronizadas montadas através de um segredo do Kubernetes.
Os dados definidos de armazenamento de objetos e de vários nós são acedidos através da API S3. Consulte as secções relevantes para configurar o armazenamento de vários nós e o armazenamento de objetos no dispositivo isolado do GDC.
Armazenamento na nuvem
Tem de fornecer um URL acessível e credenciais padronizadas montadas através de um segredo.
Se aceder a um contentor do Cloud Storage com controlos de acesso uniformes, tem de definir a flag --bucket-policy-only como true.
Credenciais
É necessário um segredo do Kubernetes para usar o serviço de transferência de armazenamento para definições de origem ou destino do S3 ou do GCS. Estas podem ser fornecidas com uma conta de serviço remota ou uma conta de utilizador.
Quando usar segredos numa definição de trabalho ou CronJob, o JobSpec tem de ser anexado a uma ServiceAccount do Kubernetes que tenha acesso aos segredos.
Crie uma ServiceAccount que seja usada pela transferência e, em seguida, adicione autorizações à ServiceAccount para ler e escrever segredos através de funções e associações de funções. Pode optar por não criar uma ServiceAccount se a ServiceAccount do espaço de nomes predefinido ou a ServiceAccount personalizada já tiver autorizaçõ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 obter credenciais da conta de serviço do Cloud Storage para fazer uma transferência, consulte o artigo
https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account.
Estas credenciais têm de ser armazenadas num segredo no campo service-account-key.
Vejamos 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 utilizador
Pode usar uma conta de utilizador para autenticação com contentores compatíveis com S3, não com contentores do Cloud Storage. Tem de 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 o seguinte:
NAMESPACE: o nome do espaço de nomes no qual vai criar a definição de tarefa.SECRET_NAME: o nome do segredo que está a criar.ACCESS_KEY_ID: o valor encontrado no campo Chave de acesso na consola Google Cloud . Quando configurar o armazenamento de objetos, isto é denominado access-key-id.ACCESS_KEY: o valor encontrado no campo Secret na consola Google Cloud . Quando configurar o armazenamento de objetos, esta é a chave secreta ou o segredo.
Certificados
Forneça certificados para validação no trabalho com um segredo 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 através dos argumentos src_ca_certificate_reference e dst_ca_certificate_reference no formato NAMESPACE/SECRET_NAME. Por 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 dispositivo, pode usar diretamente o segredo trust-store-root-ext como o certificado de AC. Por 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 registos no Loki
Por predefinição, os registos de trabalhos só são visíveis nos recursos do Kubernetes e não estão disponíveis na pilha de observabilidade. Têm de ser configurados com um LoggingTarget para serem visíveis.
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
Defina uma profissão incorporada
Os utilizadores gerem os seus próprios recursos de emprego. Para transferências de dados de utilização única, defina um Job. A tarefa cria um pod para executar o contentor storage-transfer.
Um exemplo de tarefa:
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
Defina um CronJob incorporado
Os utilizadores gerem os seus próprios recursos CronJob definidos. A utilização de um CronJob integrado permite transferências de dados agendadas regularmente.
Um exemplo de CronJob que alcança 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
A Google recomenda definir concurrencyPolicy como Forbid para evitar a contenção de dados.
O CronJob, o segredo e o PersistentVolumeClaim têm de estar no mesmo espaço de nomes.
Priorize tarefas de dados
A definição da prioridade nas tarefas de dados pode ser alcançada de várias formas que não são mutuamente exclusivas. Pode definir programações de tarefas menos frequentes na definição de CronJob.
Também pode ordenar as tarefas através de InitContainers (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) que são sempre executados por ordem de definição. No entanto, todos os contentores têm de ser executados com êxito. Use InitContainers para dar maior prioridade a uma tarefa ou gerir a contenção de dados definindo dois ou mais InitContainers com definições de origem e destino espelhadas.
Um exemplo de jobTemplate que alcança 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 contentor A-to-B é executado antes de B-to-A. Este exemplo alcança uma sincronização bidirecional e uma ordenação de tarefas.