Google Distributed Cloud (GDC) 에어 갭 적용 어플라이언스 기기는 Google Distributed Cloud 에어 갭 적용 환경으로 임의의 데이터를 전송합니다. 전송은 수동으로 시작하거나 설정된 간격으로 자동으로 실행되도록 설정할 수 있습니다.
이전 예시:
- 소프트웨어 업데이트 또는 업데이트된 고객 워크로드 다운로드
- 고객 데이터, 기기 측정항목 또는 기기 보안, 감사, 작업 로그 업로드
- 백업 데이터 스냅샷
스토리지 전송 도구는 데이터를 전송하며 클러스터에서 실행되는 컨테이너에 사용하기 위해 이미지에 배포됩니다.
데이터 소스
스토리지 전송 도구를 사용하면 GDC 에어 갭 적용 어플라이언스의 작동 조건을 유연하게 설정할 수 있습니다. S3 호환 API는 외부적으로 노출된 스토리지 타겟과 내부 스토리지 타겟에 액세스할 수 있습니다. 이 도구는 로컬 파일 시스템 및 Cloud Storage 소스도 지원합니다.
연산자는 GDC 에어갭 어플라이언스를 외부 네트워크에 연결하기 위한 인증에 필요한 액세스 키 및 기타 사용자 인증 정보, 보안 비밀 또는 민감한 데이터를 관리할 책임이 있습니다. 운영자는 외부 네트워크 구성도 담당합니다.
외부 스토리지를 만들고 액세스하려면 스토리지 버킷 만들기를 참고하세요.
로컬 스토리지
로컬 스토리지는 포드의 컨테이너 환경에 포함되며 임시 파일 시스템 또는 마운트된 볼륨을 포함합니다. 볼륨을 마운트할 때 포드에 바인딩된 ServiceAccount는 모든 마운트 타겟에 액세스할 수 있어야 합니다.
S3 스토리지
네트워크에서 사용할 수 있는 스토리지는 S3 호환 API를 통해 액세스할 수 있습니다. 서비스는 외부 서비스일 수도 있고 클러스터 네트워크 내에서만 노출될 수도 있습니다. 액세스 가능한 URL과 Kubernetes 보안 비밀을 사용하여 마운트된 표준화된 사용자 인증 정보를 제공해야 합니다.
다중 노드 및 객체 스토리지 정의 데이터는 S3 API를 통해 액세스합니다. GDC 오프라인 어플라이언스 내에서 다중 노드 스토리지 및 객체 스토리지를 설정하는 관련 섹션을 참고하세요.
클라우드 스토리지
액세스 가능한 URL과 보안 비밀을 사용하여 마운트된 표준화된 사용자 인증 정보를 제공해야 합니다.
균일한 액세스 제어로 Cloud Storage 버킷에 액세스하는 경우 --bucket-policy-only 플래그를 true로 설정해야 합니다.
사용자 인증 정보
S3 또는 GCS 소스 또는 대상 정의에 스토리지 전송 서비스를 사용하려면 Kubernetes 보안 비밀이 필요합니다. 원격 서비스 계정 또는 사용자 계정으로 제공할 수 있습니다.
Job 또는 CronJob 정의에서 보안 비밀을 사용하는 경우 JobSpec은 보안 비밀에 액세스할 수 있는 Kubernetes ServiceAccount에 연결되어야 합니다.
전송에서 사용하는 ServiceAccount를 만든 다음 역할과 역할 바인딩을 사용하여 보안 비밀을 읽고 쓸 수 있는 권한을 ServiceAccount에 추가합니다. 기본 네임스페이스 ServiceAccount 또는 맞춤 ServiceAccount에 이미 권한이 있는 경우 ServiceAccount를 만들지 않아도 됩니다.
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
원격 서비스 계정
전송을 위해 Cloud Storage 서비스 계정 사용자 인증 정보를 가져오려면 https://developers.google.com/workspace/guides/create-credentials#create_credentials_for_a_service_account을 참고하세요.
이 사용자 인증 정보는 service-account-key 필드의 보안 비밀에 저장해야 합니다.
예를 들면 다음과 같습니다.
apiVersion: v1
data:
service-account-key: BASE_64_ENCODED_VERSION_OF_CREDENTIAL_FILE_CONTENTS
kind: Secret
metadata:
name: gcs-secret
namespace: NAMESPACE
type: Opaque
사용자 계정
Cloud Storage 버킷이 아닌 S3 호환 버킷으로 인증하는 데는 사용자 계정을 사용할 수 있습니다. --src_type 또는 --dst_type 인수를 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
다음을 바꿉니다.
NAMESPACE: 작업 정의를 만들 네임스페이스의 이름입니다.SECRET_NAME: 만들려는 보안 비밀의 이름입니다.ACCESS_KEY_ID: Google Cloud 콘솔의 액세스 키 필드에 있는 값입니다. Object Storage용으로 구성할 때는 이를 access-key-id라고 합니다.ACCESS_KEY: Google Cloud 콘솔의 Secret 필드에 있는 값입니다. 객체 스토리지를 구성할 때 이는 secret-key 또는 보안 비밀입니다.
인증서
ca.crt 데이터 키가 포함된 Kubernetes 보안 비밀을 사용하여 작업에서 유효성 검사를 위한 인증서를 제공합니다.
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.
인증서는 NAMESPACE/SECRET_NAME 형식의 src_ca_certificate_reference 및 dst_ca_certificate_reference 인수를 사용하여 도구를 참조하여 제공할 수 있습니다. 예를 들면 다음과 같습니다.
...
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
어플라이언스의 S3 스토리지의 경우 trust-store-root-ext 보안 비밀을 CA 인증서로 직접 사용할 수 있습니다. 예를 들면 다음과 같습니다.
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
선택사항: Loki에서 로그를 볼 수 있도록 LoggingTarget 정의
기본적으로 작업의 로그는 Kubernetes 리소스에서만 볼 수 있으며 관측 가능성 스택에서는 사용할 수 없습니다. 로그를 보려면 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
내장 작업 정의
사용자가 자체 작업 리소스를 관리합니다. 일회성 데이터 전송의 경우 작업을 정의합니다. 작업은 스토리지 전송 컨테이너를 실행하는 포드를 만듭니다.
작업 예:
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
기본 제공 CronJob 정의
사용자는 자체 정의된 CronJob 리소스를 관리합니다. 기본 제공 CronJob을 사용하면 정기적으로 예약된 데이터 전송이 가능합니다.
자동 데이터 전송을 달성하는 CronJob의 예:
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
데이터 경합을 방지하려면 concurrencyPolicy을 Forbid로 설정하는 것이 좋습니다.
CronJob, Secret, PersistentVolumeClaim은 동일한 네임스페이스에 있어야 합니다.
데이터 작업 우선순위 지정
데이터 작업의 우선순위는 상호 배타적이지 않은 여러 방법으로 설정할 수 있습니다. CronJob 정의에서 작업 일정을 더 드물게 설정할 수 있습니다.
정의된 순서대로 항상 실행되는 InitContainers(https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)를 사용하여 작업을 정렬할 수도 있습니다. 하지만 모든 컨테이너가 성공적으로 실행되어야 합니다. InitContainers를 사용하여 하나의 작업에 더 높은 우선순위를 부여하거나, 미러링된 소스 및 대상 정의가 있는 두 개 이상의 InitContainers를 정의하여 데이터 경합을 관리합니다.
순서가 지정된 데이터 전송을 달성하는 jobTemplate의 예는 다음과 같습니다.
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
컨테이너 A-to-B이 B-to-A 전에 실행됩니다. 이 예시에서는 bisync와 작업 순서를 모두 달성합니다.