이 페이지에서는 복원력을 개선하고 지역적 실패를 지속하기 위해 여러 지역에 Teleport 클러스터를 배포하는 방법에 대해 설명합니다. 이는 단계별 가이드가 아니라 다중 지역 Teleport 클러스터를 구축하는 방법에 대한 청사진입니다. 이 청사진은 특정 인프라 및 네트워크 제약에 맞게 조정되어야 합니다.

중요한 기술 고려 사항

계속하기 전에 다음 경고를 인식해야 합니다:

• 이 설정은 대부분의 Teleport 사용자 및 고객에게는 필요하지 않습니다. 단일 지역 다중 영역 배포는 최고의 가용성/비용 비율을 제공합니다. 예를 들어, Amazon의 SLA는 DynamoDB와 EC2 모두에 대해 99.99%입니다.
• 이 청사진은 여러 복잡한 구성 요소에 의존합니다. 이러한 구성 요소를 배포하고 운영할 수 있는 팀의 역량과 전문성이 없다면, 단일 지역 다중 영역 설정보다 낮은 가용성을 갖게 될 것입니다.
• 데이터베이스, 객체 스토리지, 컨테이너 런타임, 네트워크 플러그인 등 요구되는 모든 Teleport 의존성을 배포하고 유지 관리하는 것은 여러분의 책임입니다.

아키텍처 개요

다중 지역 Teleport 배포는 여러 지역의 Teleport 배포로 구성됩니다. Teleport는 다중 지역 백엔드에 상태를 저장하며 프록시 피어링을 사용하여 서로 다른 지역에 호스팅된 리소스에 사용자 연결합니다.

추천하는 다중 지역 백엔드는 self-hosted Teleport Enterprise의 CockroachDB 백엔드입니다.

다중 지역 Teleport 배포를 실행하기 위해서는 다음이 필요합니다:

• 3개 지역. Teleport는 2개만 필요하지만, CockroachDB는 쿼럼 메커니즘을 위해 3개가 필요합니다.
• 서로의 IP 주소로 연결할 수 있는 Teleport Proxy Service 인스턴스. 이는 크로스 지역 Pod/인스턴스 연결성을 의미합니다. 일반적으로 VPC 피어링 및/또는 서비스 메시를 통해 달성됩니다.
• 세션 기록을 위한 다중 지역 객체 스토리지.
• 사용자와 Teleport 에이전트를 가장 가까운 Teleport 클러스터로 라우팅하기 위한 GeoDNS.
• 다중 지역 CockroachDB 클러스터. 테스트 목적으로 CockroachDB 코어를 사용할 수 있지만, 다중 지역 기능 때문에 프로덕션에는 CockroachDB Enterprise가 권장됩니다.

Kubernetes에서 다중 지역 Teleport 구현하기

Kubernetes 인프라를 가진 팀은 Kubernetes에서 Teleport를 호스팅하고 싶어할 것입니다. 이 섹션에서는 이 설정을 더 자세히 설명합니다.

Teleport 의존성

• 3개의 피어링된 지역 VPC를 생성합니다 (예: AWS에서) 또는 1개의 글로벌 VPC를 생성합니다 (예: GKE에서).
• 각 지역에 1개의 Kubernetes 클러스터를 생성합니다. Pod CIDR는 겹치지 않아야 합니다.
• 포드 메쉬 연결성을 보장합니다. 프록시 포드는 서로 포트 3021에서 연결할 수 있어야 합니다. 설정은 네트워크 및 CNI 플러그인 구성에 따라 달라집니다:
  • 포드가 기본 네트워크 레이어를 사용하는 경우 (예: GKE 또는 AWS의 vpc-cni 추가 기능), 각 Kubernetes 클러스터의 포드를 연결하기 위해 순수 VPC 피어링, 라우팅 및 방화벽 기능에 의존할 수 있습니다.
  • 포드에 비기본 IP 주소가 제공되는 경우, Cilium 클러스터 메쉬 기능을 사용하여 포드를 연결할 수 있습니다. 클러스터를 메쉬하는 방법에 대한 단계별 가이드를 제공합니다.
• 다중 지역 객체 스토리지 설정:
  • GCP에서는 GCS가 다중 지역 위치를 가집니다.
  • 온프레미스에서는 MinIO가 다중 사이트 버킷 복제를 지원합니다.
  • AWS에서는 S3 버킷 간에 양방향 복제를 설정할 수 있습니다.
• CockroachDB 다중 지역 클러스터 설정

Teleport 백엔드 구성

CockroachDB에서 Teleport 데이터베이스와 사용자를 생성합니다:

CREATE DATABASE teleport_backend;
CREATE DATABASE teleport_audit;
CREATE USER teleport;
GRANT CREATE ON DATABASE teleport_backend TO teleport;
GRANT CREATE ON DATABASE teleport_audit TO teleport;
SET CLUSTER SETTING kv.rangefeed.enabled = true;

그런 다음 teleport 사용자에 대한 인증서를 서명합니다 cockroach certs 명령어로.

최종적으로 다음과 같은 3개의 파일이 있어야 합니다:

• client.teleport.crt
• client.teleport.key
• ca.crt

ALTER DATABASE teleport_backend SET PRIMARY REGION <region1>;
ALTER DATABASE teleport_backend ADD REGION IF NOT EXISTS <region2>;
ALTER DATABASE teleport_backend SET SECONDARY REGION <region2>;
ALTER DATABASE teleport_backend SURVIVE REGION FAILURE;

ALTER DATABASE teleport_audit SET PRIMARY REGION <region1>;
ALTER DATABASE teleport_audit ADD REGION IF NOT EXISTS <region2>;
ALTER DATABASE teleport_audit SET SECONDARY REGION <region2>;
ALTER DATABASE teleport_audit SURVIVE REGION FAILURE;

ALTER DATABASE teleport_backend SURVIVE ZONE FAILURE;
ALTER DATABASE teleport_audit SURVIVE ZONE FAILURE;

Teleport 배포

모든 Teleport 종속성이 설정되면, teleport-cluster Helm 차트를 통해 Teleport를 배포할 수 있습니다. Kubernetes 클러스터당 하나의 릴리스를 생성해야 합니다. 특정 지역에 대한 값의 예는 다음과 같습니다:

chartMode: standalone
clusterName: teleport-multi-region.example.org
persistence:
  enabled: false
enterprise: true

auth:
  teleportConfig:
    # CockroachDB 구성
    teleport:
      storage:
        type: cockroachdb
        # 지역 CockroachDB URL, Cockroach 문서를 따른 경우 다음과 같습니다
        # cockroachdb-public.<region>.svc.cluster.local
        conn_string: postgres://teleport@cockroachdb-public.<region>.svc.cluster.local:26257/teleport_backend?sslmode=verify-full&pool_max_conns=20
        audit_events_uri:
          - "postgres://teleport@cockroachdb-public.<region>.svc.cluster.local:26257/teleport_audit?sslmode=verify-full"
        # 이 값을 지역 객체 스토리지(S3, GCS, MinIO)의 URI로 교체하십시오
        audit_sessions_uri: "uri://to-your-regional-bucket"
        ttl_job_cron: "*/20 * * * *"

    # 프록시 피어링 구성
    auth_service:
      tunnel_strategy:
        type: proxy_peering
        agent_connection_count: 2

  # CockroachDB 인증서를 마운트하고 Teleport가 이를 사용하게 함 (기본 환경 변수로)
  extraVolumes:
    - name: db-certs
      secret:
        secretName: cockroach-certs
  extraVolumeMounts:
    - name: db-certs
      mountPath: /var/lib/db-certs
      readOnly: true
  extraEnv:
    - name: PGSSLROOTCERT
      value: /var/lib/db-certs/ca.crt
    - name: PGSSLCERT
      value: /var/lib/db-certs/client.teleport.crt
    - name: PGSSLKEY
      value: /var/lib/db-certs/client.teleport.key

# 프록시에서 사용할 TLS 인증서 전달
# cert-manager를 사용하는 경우 및 `highAvailability.certManager` 를 설정한 경우 생략할 수 있습니다
tls:
  existingSecretName: proxy-cert

highAvailability:
  replicaCount: 2

GeoDNS 설정

가장 가까운 Teleport 배포로 사용자를 라우팅하기 위해 GeoDNS를 설정하여 배포를 마무리합니다. 설정은 DNS 제공업체마다 다를 것입니다. 필요에 따라 트래픽을 다른 지역으로 유도할 수 있도록 짧은 TTL을 사용하세요.

가능한 경우 /v1/webapi/ping 에서 헬스 체크를 구성하여 고장 난 Teleport 지역이 DNS 레코드에서 자동으로 제거되고 사용자가 가장 가까운 작동 중인 Teleport 배포로 라우팅되도록 합니다.

업데이트 전략

다중 지역 설정에서 Teleport를 업데이트하는 것은 몇 가지 도전 과제가 있습니다. Teleport 호환성 보증을 엄격히 따르려면 업데이트 전에 단일 인증으로 축소해야 합니다. 다중 지역 설정에서는 다음을 요구합니다:

• 업데이트 중 인증을 위해 단일 지역에 의존
• 두 지역을 중단하거나 프록시가 다른 지역의 인증에 연결할 수 있도록 허용 (기본적으로 그렇지 않으며 Cilium 크로스 클러스터 서비스와 프록시 서비스에 대한 사용자 정의 조인 토큰이 필요합니다).

CockroachDB 크기 조정

3개의 지역에 각각 1개의 노드를 가진 3x3 CockroachDB 클러스터 (3개의 지역당 3개의 존)는 10,000개의 SSH 노드를 가진 Teleport 클러스터를 지원할 수 있습니다.

CockroachDB 성능은 저장소 유형에 따라 달라집니다. CockroachDB의 상태를 SSD에 저장해야 합니다. Kubernetes에서 실행할 때 기본 저장소 클래스가 최상의 대기 시간 및 처리량을 제공하는 클래스가 아닐 수 있습니다.

Teleport 크기 조정에 대한 더 자세한 내용은 Teleport scaling 페이지를 참조하세요.

Teleport 부하는 사용 유형(연결된 노드 수, 보호된 리소스 수, 역할 수, 동시 연결 수 및 사용자 활동)에 따라 다르므로, 특정 요구 사항에 맞춰 크기 조정을 테스트하고 조정해야 합니다.

resources:
  requests:
    # cpu 및 메모리 요청 설정
    cpu: "2"
    memory: "8Gi"
  limits:
    # 메모리 제한은 메모리 요청과 동일한 값으로 설정됩니다.
    memory: "8Gi"
    # cpu 제한은 설정되지 않음

다중 지역 AWS S3 복제 설정

이 섹션에서는 여러 지역 S3 버킷과 복제 규칙을 가진 다중 지역 객체 저장소를 만드는 방법을 설명합니다.

1. 각 지역에 각각 하나씩 3개의 버킷을 만들고 버전 관리를 활성화합니다.
2. 3개의 버킷을 포함하는 다중 지역 액세스 포인트를 만듭니다.
3. 생성한 후 "Replication and Failover" 탭에서 "Create Replication Rule"을 선택하고 템플릿 "Replicate objects among all specified buckets."를 선택합니다.

또는 Terraform과 같은 도구를 사용하여 개별 복제 규칙을 만들 수 있습니다. 3개의 버킷 bucketA , bucketB , bucketC 가 있을 경우 6개의 규칙이 필요합니다:

• bucketA 에서 bucketB 로
• bucketA 에서 bucketC 로
• bucketB 에서 bucketA 로
• bucketB 에서 bucketC 로
• bucketC 에서 bucketA 로
• bucketC 에서 bucketB 로