Kubernetes에서 Spanner Omni용 멀티 클러스터 배포 만들기

미리보기

이 제품 또는 기능은 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제품 약관'이 적용되는 미리보기 제품이며, 소프트웨어 프로그램을 개발, 테스트, 프로토타이핑, 데모하는 목적으로만 사용할 수 있습니다. 데이터 처리 또는 상업적 목적으로는 사용할 수 없습니다. GA 이전 제품 및 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참고하세요.

이 문서에서는 여러 Kubernetes 클러스터에 Spanner Omni 배포를 설정하는 방법을 설명합니다. TLS 암호화 유무에 관계없이 Spanner Omni를 배포할 수 있습니다. 암호화를 사용하는 경우 Spanner Omni는 전송 계층 보안 (TLS) 1.3을 사용하여 배포 내에서 그리고 클라이언트와의 통신을 암호화하고 인증합니다.

TLS 암호화가 없는 배포에는 다음과 같은 보안 위험이 있습니다.

• IP 주소에 도달할 수 있는 사용자는 누구나 배포에 액세스할 수 있습니다.
• 클라이언트와 서버 간 또는 포드 간에 네트워크 암호화가 없습니다.

이러한 위험 때문에 프로덕션 환경에서는 TLS 암호화로 구성되지 않은 배포를 피하세요.

Spanner Omni의 미리보기 버전은 TLS 암호화를 지원하지 않으며 배포를 만든 후 90일이 지나면 데이터 쓰기를 중지합니다. 전체 기능을 갖춘 버전을 사전 체험하려면 Google에 문의하세요.

시작하기 전에

배포를 준비하려면 다음 요구사항을 완료하세요.

• 배포를 위해 각 위치에 여러 Kubernetes 클러스터를 만듭니다. 클러스터에 하나의 영역만 배포하는 경우 클러스터는 영역별일 수 있습니다. Spanner Omni는 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (Amazon EKS) 환경의 Helm 차트 구성을 지원합니다. 다른 환경에는 맞춤 구성이 필요할 수 있습니다.

• Artifact Registry에 호스팅된 컨테이너 이미지에 액세스합니다.

• kubectl 명령줄 도구와 Helm을 설치하고 구성합니다.

• vSphere 가상화 플랫폼 머신에서 Kubernetes 환경을 설정하는 경우 가상 머신의 .vmx 구성 파일에 monitor_control.virtual_rdtsc = FALSE를 추가하여 타임스탬프 카운터 (TSC) 가상화를 사용 중지합니다. 이렇게 하면 TrueTime이 올바르게 작동합니다.

• 한 클러스터의 포드가 다른 클러스터의 포드와 연결될 수 있도록 Kubernetes 클러스터 네트워크를 구성합니다. 기본적으로 Spanner Omni는 내부 통신에 TCP 포트 15000~15025를 사용합니다. 이러한 클러스터의 포드 간 통신을 사용 설정하려면 트래픽에 대해 이러한 포트를 엽니다.

• spanner-a-0.pod.spanner-ns-r1와 같은 포드의 호스트 이름을 IP 주소로 변환하도록 클러스터 DNS를 구성합니다. Spanner Omni에는 서로 다른 클러스터의 포드 간 TCP 연결을 위한 호스트 이름 확인이 필요합니다.

Helm 차트 구성 준비

Helm 구성을 만듭니다. 자세한 내용은 Helm 구성 만들기를 참고하세요.

일관성을 위해 쿼럼을 보장하려면 영역당 루트 서버 수가 1~9 사이의 홀수여야 합니다. 서버 수가 짝수이면 배포가 실패할 수 있습니다. 영역을 구성할 때 서버를 루트 서버로 지정합니다. 매우 작은 영역의 경우 하나의 루트 서버를 사용합니다. 더 큰 영역의 경우 루트 서버 3개, 5개 또는 9개를 사용합니다.

멀티 클러스터 배포이므로 Helm 구성 YAML 파일에 다음이 포함되어 있는지 확인합니다.

# This is required for a multi-cluster deployment setup.

deployment:
  multiCluster: true

멀티 클러스터 배포를 위한 샘플 Helm 차트 구성

다음은 Spanner Omni 멀티 클러스터 배포를 위해 구성된 Helm 차트의 예시입니다. 이 구성은 us-west1, us-west2, us-west3의 세 개 Google Cloud 리전에 배포를 만듭니다. 배포는 5개 영역에 분산되어 있으며 각 영역은 복제본을 나타냅니다. us-west1 및 us-west2의 복제본은 읽기-쓰기 복제본이고 us-west3의 단일 복제본은 감시 복제본입니다.

# The platform of the deployment
global:
  platform: gke

# This is required for a multi-cluster deployment setup.
deployment:
  multiCluster: true

# Locations and zones where clusters are created for the deployment
locations:
  - name: us-west1
    namespace: spanner-ns-usw1
    zones:
      - name: "us-west1-a"
        shortName: "a"
      - name: "us-west1-b"
        shortName: "b"
  - name: us-west2
    namespace: spanner-ns-usw2
    zones:
      - name: "us-west2-a"
        shortName: "a"
      - name: "us-west2-b"
        shortName: "b"
  - name: us-west3
    namespace: spanner-ns-usw3
    zones:
      - name: "us-west3-a"
        shortName: "a"
        replicaType: WITNESS

# Remaining configuration like storage, resources, isn't included in this sample.

여러 클러스터에 연결하도록 kubectl 구성

계속하기 전에 kubectl 컨텍스트로 클러스터를 만드세요. 예를 들어 Helm 구성 YAML 파일에서 위치에 따라 컨텍스트 이름을 지정할 수 있습니다(예: ctx-usw1, ctx-usw2, ctx-usw3).

TLS 암호화 구성

암호화 없이 배포를 설정하는 경우 각 클러스터에 Helm 차트 설치로 건너뜁니다.

멀티 클러스터 배포에서 TLS 암호화를 구성하려면 인증 기관 (CA)을 만들고 각 클러스터의 인증서를 생성해야 합니다. 자세한 내용은 Kubernetes 배포에 TLS 암호화 추가를 참고하세요.

인증서 생성

서버 및 API의 CA와 인증서를 만듭니다. 서버 및 API 인증서에는 모든 클러스터의 호스트가 포함되어야 합니다.

Spanner Omni 서버 인증서 만들기

Spanner Omni 서버는 서버 인증서를 사용하여 서버 간 통신을 암호화합니다.

서버 인증서를 만들려면 다음을 실행합니다. SERVER_LIST를 쉼표로 구분된 Spanner Omni 서버 포드 FQDN 목록으로 바꾸거나 와일드 카드를 사용합니다.

SERVER_NAMES=*.pod.spanner-ns-usw1,*.pod.spanner-ns-usw2,*.pod.spanner-ns-usw3
Spanner Omni CLI certificates create-server --hostnames=${SERVER_NAMES} --ca-certificate-directory certs --output-directory certs

API 인증서 만들기

API 인증서는 배포와 상호작용하는 시스템의 통신을 암호화합니다.

API 인증서를 만들려면 다음을 실행하세요. OMNI_ENDPOINT을 각 클러스터의 서비스 엔드포인트로 바꿉니다.

OMNI_ENDPOINT=spanner.spanner-ns-usw1,spanner.spanner-ns-usw2,spanner.spanner-ns-usw3
Spanner Omni CLI certificates create-server --filename-prefix=api --hostnames=${OMNI_ENDPOINT} --ca-certificate-directory certs --output-directory certs

각 Kubernetes 클러스터에 인증서 푸시

각 클러스터에 대해 네임스페이스와 인증서가 포함된 일반 보안 비밀을 만듭니다.

# Repeat for each context (for example, ctx-usw1, ctx-usw2, ctx-usw3)
# Replace NAMESPACE with the appropriate namespace for each region

kubectl create namespace <var>NAMESPACE</var> --context <var>CONTEXT</var>
kubectl create secret generic tls-certs \
  --from-file=ca.crt="certs/ca.crt" \
  --from-file=ca-api.crt="certs/ca-api.crt" \
  --from-file=server.crt="certs/server.crt" \
  --from-file=server.key="certs/server.key" \
  --from-file=api.crt="certs/api.crt" \
  --from-file=api.key="certs/api.key" \
  -n <var>NAMESPACE</var> \
  --context <var>CONTEXT</var>

각 클러스터에 Helm 차트 설치

Helm 구성을 만듭니다. 자세한 내용은 Helm 구성 만들기를 참고하세요.

멀티 클러스터 배포의 경우 Helm 구성 파일의 Helm 차트 구성을 각 Kubernetes 클러스터에 적용합니다. 각 명령어에서 특정 위치와 네임스페이스를 타겟팅하여 Spanner Omni 배포에 바인딩합니다. Helm 구성 파일에 나열된 순서와 동일한 순서로 각 위치에 구성을 적용합니다. 최종 위치에 구성을 적용하면 시스템에서 해당 클러스터에 배포 부트스트랩 작업을 만듭니다.

각 클러스터에 Helm을 설치하기 전에 관측 가능성 스택을 호스팅할 클러스터에 모니터링 네임스페이스를 만듭니다.

kubectl create namespace monitoring --context ctx-usw1

Helm 차트 설치 명령어 예시

다음 명령어는 클러스터에 Helm 차트를 설치합니다. 각 명령어에서 PATH_TO_HELM_CONFIG_FILE은 배포를 위해 만든 Helm 차트 구성 YAML 파일의 경로입니다.

모니터링이 사용 설정된 us-west1에 차트 설치

helm upgrade --install spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni --version 0.1.0 \
  -f PATH_TO_HELM_CONFIG_FILE \
  --namespace spanner-ns-usw1 \
  --set currentLocation=us-west1 \
  --set monitoring.enabled=true \
  --create-namespace \
  --kube-context ctx-usw1

모니터링 없이 us-west2에 차트 설치

helm upgrade --install spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni --version 0.1.0 \
  -f  PATH_TO_HELM_CONFIG_FILE \
  --namespace spanner-ns-usw2 \
  --set currentLocation=us-west2 \
  --create-namespace \
  --kube-context ctx-usw2

모니터링 없이 us-west3에 차트 설치

helm upgrade --install spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni --version 0.1.0 \
  -f  PATH_TO_HELM_CONFIG_FILE \
  --namespace spanner-ns-usw3 \
  --set currentLocation=us-west3 \
  --create-namespace \
  --kube-context ctx-usw3

배포 진행 상황 확인

Helm 차트 구성을 적용하면 각 Kubernetes 클러스터에서 부트스트랩 작업이 시작됩니다. 마지막 클러스터에서 부트스트랩 작업이 시작된 후 다음 명령어를 실행하여 배포 프로세스를 따릅니다.

kubectl logs -n spanner-ns-usw3 -l app.kubernetes.io/component=bootstrap -f

로그에 배포가 모든 서버에 도달할 수 없다고 표시되면 각 클러스터의 DNS 서비스가 올바르게 구성되어 있는지 확인합니다.

클러스터 DNS 서비스 구성

Kubernetes 클러스터에서 외부 DNS를 사용하고 이 DNS가 헤드리스 서비스의 DNS 항목을 관리하는 경우 이 단계를 건너뛸 수 있습니다.

Spanner는 모든 내부 통신에 포드 호스트 이름을 사용합니다. 포드가 서로 다른 Kubernetes 클러스터에서 실행될 때도 호스트 이름을 확인할 수 있도록 DNS를 구성합니다. 이를 위해 다른 클러스터가 dns-setup.sh 스크립트를 실행하여 연결할 수 있도록 각 클러스터에서 kube-dns 서비스를 노출합니다.

이 스크립트는 각 클러스터에 kube-dns 애플리케이션용 부하 분산기 서비스를 배포하고 부하 분산기 서비스를 가리키도록 DNS 구성을 업데이트합니다. dns-setup.sh은 GKE와 Amazon EKS 전반에서 kube-dns 및 CoreDNS을 구성하지만 환경에 맞게 구성해야 할 수도 있습니다.

클러스터 DNS 서비스를 구성하려면 다음 단계를 따르세요.

1. 아직 다운로드하지 않았다면 spanner-omni Cloud Storage 버킷에서 dns-setup.sh 스크립트를 다운로드합니다.

   Spanner Omni 버킷으로 이동

2. dns-setup.sh 스크립트를 실행합니다.

   dns-setup.sh -n CSV_NAME_SPACE_LIST CONTEXTS
   

   • CSV_NAME_SPACE_LIST를 쉼표로 구분된 네임스페이스 목록으로 바꿉니다.

   • CONTEXTS을 컨텍스트 목록으로 바꿉니다.

   다음은 dns-setup.sh 스크립트 사용의 예입니다.

   dns-setup.sh -n spanner-ns-usw1,spanner-ns-usw2,spanner-ns-usw3 ctx-usw1 ctx-usw2 ctx-usw3
   

스크립트를 실행한 후 배포 작업의 로그를 확인합니다. 메시지에 배포가 진행 중이라고 표시되고 Deployment created successfully 메시지가 표시됩니다.

API 인증서 업데이트

TLS 암호화 없이 배포를 설정하는 경우 Spanner Omni와 상호작용으로 진행합니다.

TLS 암호화를 구현하려면 각 클러스터의 부하 분산기에 대한 외부 IP 주소 또는 DNS 이름으로 API 인증서를 업데이트해야 합니다. 이렇게 하면 클라이언트가 보안 채널을 통해 배포에 연결할 수 있습니다.

1. 각 클러스터의 서비스 세부정보를 가져옵니다.

   kubectl get service spanner -n spanner-ns-usw1 --context ctx-usw1
   kubectl get service spanner -n spanner-ns-usw2 --context ctx-usw2
   kubectl get service spanner -n spanner-ns-usw3 --context ctx-usw3
   

2. 외부 IP 주소로 API 인증서를 업데이트합니다.

   # Replace <var>EXTERNAL_IP_USW1</var>, <var>EXTERNAL_IP_USW2</var>, and <var>EXTERNAL_IP_USW3</var>
   # with the actual external IP addresses or DNS names.
   
   OMNI_ENDPOINT=<var>EXTERNAL_IP_USW1</var>,<var>EXTERNAL_IP_USW2</var>,<var>EXTERNAL_IP_USW3</var>,spanner.spanner-ns.svc
   Spanner Omni CLI certificates update --filename_prefix=api --hostnames=${OMNI_ENDPOINT} --ca-certificate-directory certs --output_directory certs --overwrite
   

3. 각 Kubernetes 클러스터의 보안 비밀을 새 API 인증서로 업데이트합니다.

   # Repeat for each context
   kubectl patch secret tls-certs -n spanner-ns-usw1 --context ctx-usw1 -p "{\"data\":{\"api.crt\":\"$(base64 -w 0 certs/api.crt)\"}}"
   kubectl patch secret tls-certs -n spanner-ns-usw2 --context ctx-usw2 -p "{\"data\":{\"api.crt\":\"$(base64 -w 0 certs/api.crt)\"}}"
   kubectl patch secret tls-certs -n spanner-ns-usw3 --context ctx-usw3 -p "{\"data\":{\"api.crt\":\"$(base64 -w 0 certs/api.crt)\"}}"
   

Spanner Omni와 상호작용

멀티 클러스터 설정의 각 클러스터에는 부하 분산기 서비스가 하나 있습니다. 서비스의 외부 IP 주소를 사용하여 Spanner Omni와 상호작용할 수 있습니다. 쓰기 및 강력 읽기의 경우 리더 리전 역할을 하는 주소를 사용합니다. 비활성 읽기 요청의 경우 애플리케이션과 가장 가까운 리전을 사용하여 최적의 성능을 달성하세요.

1. 다음 명령어를 실행하여 서비스 주소를 가져옵니다.

   kubectl get service spanner -n spanner-ns-usw1 --context ctx-usw1
   

   EXTERNAL-IP:PORT은 배포의 DEPLOYMENT_ENDPOINT입니다.

2. 아직 다운로드하지 않았다면 spanner-omni Cloud Storage 버킷에서 Spanner Omni CLI를 다운로드합니다.

   Spanner Omni 버킷으로 이동

3. TLS 암호화로 배포를 만든 경우 암호화된 연결을 설정하려면 각 명령어에 CA 인증서를 포함해야 합니다. 클라이언트용 mTLS를 사용 설정한 경우 클라이언트 인증서 디렉터리도 포함합니다.

   • --ca-certificate-file=certs/ca-api.crt
   • --client-certificate-directory=clientcerts

4. Spanner Omni CLI를 사용하여 GoogleSQL 또는 PostgreSQL 데이터베이스를 만들고 상호작용합니다.

   GoogleSQL

   GoogleSQL 데이터베이스를 만들고 상호작용하려면 다음을 실행하세요.

   Spanner Omni CLI databases create DATABASE_NAME \
     --deployment-endpoint=dns:///DEPLOYMENT_ENDPOINT \
     --ca-certificate-file=certs/ca-api.crt
   Spanner Omni CLI sql --database=DATABASE_NAME \
     --deployment-endpoint=dns:///DEPLOYMENT_ENDPOINT \
     --ca-certificate-file=certs/ca-api.crt
   

   PostgreSQL

   PostgreSQL 데이터베이스를 만들고 상호작용하려면 다음을 실행하세요.

   Spanner Omni CLI databases create POSTGRESQL_DATABASE_NAME \
     --database_dialect POSTGRESQL \
     --deployment-endpoint=dns:///DEPLOYMENT_ENDPOINT \
     --ca-certificate-file=certs/ca-api.crt
   Spanner Omni CLI sql --database=POSTGRESQL_DATABASE_NAME \
     --deployment-endpoint=dns:///DEPLOYMENT_ENDPOINT \
     --ca-certificate-file=certs/ca-api.crt
   

   PGAdapter를 사용하여 연결의 안내에 따라 PGAdapter를 구성하고 PostgreSQL 언어 데이터베이스와 함께 psql와 같은 PostgreSQL 도구를 사용하여 PostgreSQL 데이터베이스와 상호작용할 수도 있습니다.

다음 단계

• 클라이언트 라이브러리 및 JDBC 드라이버를 사용하여 애플리케이션을 배포에 연결하는 방법을 알아봅니다.