InfoGrab Docs

멀티 리전 블루프린트

요약

이 페이지는 탄력성을 향상시키고 리전 장애를 견디기 위해 여러 리전에 Teleport 클러스터를 배포하는 방법을 설명합니다. 이 배포는 멀티 리전 탄력성을 제공하기 위해 복잡성과 비용을 크게 증가시킵니다. 이 블루프린트를 수정 없이 정확히 따르세요.

이 페이지는 탄력성을 향상시키고 리전 장애를 견디기 위해 여러 리전에 Teleport 클러스터를 배포하는 방법을 설명합니다.

위험

이 배포는 멀티 리전 탄력성을 제공하기 위해 복잡성과 비용을 크게 증가시킵니다. 멀티 리전 탄력성이 요구사항이 아닌 경우 이 블루프린트를 사용하지 마세요. 대부분의 배포에는 고가용성 클러스터를 권장합니다.

이 블루프린트를 수정 없이 정확히 따르세요. 이 블루프린트의 일부를 수정하면 배포를 지원하지 못할 수 있습니다.

중요한 기술적 고려사항#

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

  • 이 설정은 대부분의 Teleport 사용자와 고객에게 필요하지 않습니다. 단일 리전 멀티 영역 배포는 최적의 가용성/비용 비율을 제공합니다. 예를 들어, Amazon SLA는 DynamoDB와 EC2 모두 99.99%입니다.
  • 멀티 리전 설정은 단일 리전 설정보다 더 나은 확장성을 제공하지 않습니다. 분산되고 중복적인 특성으로 인해 동일한 수의 에이전트에 대해 단일 리전 설정보다 성능이 낮고 비용이 더 많이 듭니다.
  • 이 블루프린트는 많은 복잡한 구성 요소에 의존합니다. 이러한 구성 요소를 배포하고 운영할 팀 역량과 전문성이 없다면 단일 리전 멀티 영역 설정보다 가용성이 낮아질 수 있습니다.
  • 데이터베이스, 객체 저장소, 컨테이너 런타임, 네트워크 플러그인 및 기타 필요한 모든 것을 포함한 Teleport 종속성을 배포하고 유지 관리할 책임은 사용자에게 있습니다.
  • 리전은 완전한 리전 장애 발생 시 모든 트래픽을 처리할 수 있는 충분한 용량으로 프로비저닝되어야 합니다. 여기에는 노드와 사용자가 정상 리전에 다시 연결될 때 새로운 트래픽을 즉시 흡수할 수 있는 능력이 포함됩니다.

멀티 리전 클러스터가 필요한 제한된 대역폭의 팀을 위해 Teleport는 크로스 리전 클러스터 호스팅을 제공합니다. 운영 비용과 복잡성 없이 이 문서에 설명된 설정의 이점을 누릴 수 있으며, 자세한 내용은 Teleport Enterprise (Cloud) 시작 가이드를 참조하세요.

아키텍처 개요#

멀티 리전 Teleport 배포는 여러 리전별 Teleport 배포로 구성됩니다. Teleport는 멀티 리전 백엔드에 상태를 저장하고 프록시 피어링을 사용하여 사용자를 다른 리전에 호스팅된 리소스에 연결합니다.

권장 멀티 리전 백엔드는 자체 호스팅 Teleport Enterprise에서 사용 가능한 CockroachDB 백엔드입니다.

아키텍처 다이어그램

멀티 리전 Teleport 배포를 실행하려면 다음이 필요합니다:

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

Kubernetes에서 멀티 리전 Teleport 구현#

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

Kubernetes CPU 제한

쓰로틀링이 예측할 수 없는 지연 시간을 유발하고, 실시간 인증 및 네트워킹 작업을 방해하며, 정상적인 리전 전반에 걸쳐 연속 장애를 트리거하여 전체 클러스터 중단으로 이어질 수 있으므로 Teleport 구성 요소에 CPU 제한을 설정하는 것을 강력히 권장하지 않습니다.

Teleport 종속성#

  • 3개의 피어링된 리전별 VPC(예: AWS) 또는 1개의 글로벌 VPC(예: GKE)를 생성합니다.
  • 각 리전에 1개의 Kubernetes 클러스터를 생성합니다. 파드 CIDR이 겹치지 않아야 합니다.
  • 파드 메시 연결성을 보장합니다. 프록시 파드는 서로 포트 3021로 연결할 수 있어야 합니다. 설정은 네트워크 및 CNI 플러그인 구성에 따라 다릅니다:
    • 파드가 네이티브 네트워크 레이어를 사용하는 경우(예: GKE 또는 AWS의 vpc-cni 애드온) VPC 피어링, 라우팅, 방화벽 기능만으로 각 Kubernetes 클러스터의 파드를 연결할 수 있습니다.
    • 파드에 비네이티브 IP 주소가 할당된 경우 Cilium 클러스터 메시 기능을 사용하여 파드를 연결할 수 있습니다. 클러스터 메시 단계별 가이드를 제공합니다.
  • 멀티 리전 객체 저장소를 설정합니다:
  • 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;

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

다음 3개의 파일로 끝나야 합니다:

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

CockroachDB Enterprise:

CockroachDB Enterprise의 경우 영역과 리전을 CockroachDB에 선언하고 데이터베이스에 리전 장애 허용을 구성해야 합니다.

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;

CockroachDB 리전의 영향

CockroachDB는 두 리전에 Teleport 데이터를 저장합니다. 2개의 리전별 Teleport 클러스터만 배포하는 경우 동일한 리전을 선택합니다. 3개의 Teleport 클러스터를 배포하는 경우 기본 및 보조 리전의 클러스터는 더 낮은 데이터베이스 지연 시간을 경험합니다.

기본 리전과 보조 리전이 멀리 떨어져 있는 경우(예: 다른 대륙) CockroachDB 쓰기 작업이 느려질 수 있습니다.

CockroachDB 코어:

CockroachDB 코어에서는 물리적 리전을 CockroachDB 영역으로 선언하고 Teleport 데이터베이스에 영역 장애 허용을 구성해야 합니다.

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

CockroachDB 코어는 CockroachDB Enterprise가 제공하는 리전 기능을 제공하지 않습니다. 성능에 영향을 줄 수 있습니다. CockroachDB 코어는 멀티 리전 설정에서 프로덕션에 권장되지 않습니다.

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"
        # 리전별 객체 저장소 URI로 교체하세요 (S3, GCS, MinIO)
        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 호환성 보장을 엄격하게 따르려면 업데이트 전에 단일 auth로 다운스케일해야 합니다. 멀티 리전 설정에서는 다음이 필요합니다:

  • 업데이트 중에 인증을 위해 단일 리전에 의존
  • 두 리전을 일시 중단하거나 프록시가 다른 리전의 auth에 연결할 수 있도록 허용 (이것은 기본값이 아니며 Cilium 크로스 클러스터 서비스와 Proxy Service를 위한 사용자 정의 조인 토큰이 필요합니다).

Auth 롤링 업데이트가 가능합니다. 이 경우 여러 auth 버전이 동시에 실행될 수 있습니다. 새로 도입된 리소스 필드는 모든 auth가 롤아웃될 때까지 제대로 설정되지 않을 수 있습니다.

롤아웃 기간이 짧고 버전 차이가 최소인 경우 이러한 일관성/사용성 트레이드오프는 허용 가능할 수 있습니다.

CockroachDB 크기 조정#

노드당 2개의 CPU와 8GiB 메모리를 가진 3x3 CockroachDB 클러스터(리전당 1개 영역, 3개 영역, 3개 리전)는 10,000개의 SSH 노드로 구성된 Teleport 클러스터를 지원할 수 있습니다.

CockroachDB 성능은 저장소 유형에 따라 다릅니다. CockroachDB의 상태를 SSD에 저장하도록 하세요. Kubernetes에서 실행하는 경우 기본 저장소 클래스가 최상의 지연 시간과 처리량을 제공하는 것이 아닐 수 있습니다.

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

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

중요

Kubernetes에서 실행할 때 정적 CPU 정책을 사용하지 않는 한 Teleport 또는 CockroachDB 파드에 CPU 제한을 설정하는 것을 권장하지 않습니다.

CPU 쓰로틀링이 구현되는 방식으로 인해 Teleport 및 CockroachDB와 같은 멀티스레드 I/O 집약적 애플리케이션은 CPU 제한에 도달하면 성능이 저하됩니다. 이는 서비스 중단으로 이어지고 전체 중단으로 이어질 가능성이 매우 높습니다.

경험적 법칙으로 대부분의 중요한 파드의 resources 섹션은 다음과 같아야 합니다:

resources:
  requests:
    # cpu 및 메모리 요청 설정
    cpu: "2"
    memory: "8Gi"
  limits:
    # 메모리 제한은 메모리 요청과 동일한 값으로 설정
    memory: "8Gi"
    # cpu 제한 없음

멀티 리전 AWS S3 복제 설정#

이 섹션에서는 여러 리전별 S3 버킷과 복제 규칙으로 멀티 리전 객체 저장소를 생성하는 방법을 설명합니다.

  1. 버전 관리가 활성화된 각 리전에 3개의 버킷을 생성합니다
  2. 3개의 버킷을 포함하는 멀티 리전 접근 포인트를 생성합니다
  3. 생성 후 "복제 및 장애 조치" 탭에서 "복제 규칙 생성"과 "지정된 모든 버킷 간에 객체 복제" 템플릿을 선택합니다.

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

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

Teleport가 세션 녹화를 자동으로 정리하도록 하려면 복제 규칙에서 "삭제 마커 복제"를 활성화해야 합니다.

마지막으로 Teleport가 자체적으로 시작된 파일 업로드만 완료하도록 구성해야 합니다(Teleport가 버킷 복제 규칙으로 인한 업로드를 완료하려고 시도하지 않도록).

audit_sessions_uri 값에 complete_initiators=를 설정하여 이를 수행할 수 있습니다. 는 Teleport Auth 서비스가 S3 버킷에 녹화를 업로드하는 데 사용하는 IAM 역할 이름입니다:

auth:
  teleportConfig:
    teleport:
      storage:
        # [다른 저장소 옵션들...]
        audit_sessions_uri: "uri://to-your-regional-bucket?complete_initiators=teleport-iam-role"/>"
        # ...

멀티 리전 블루프린트

원문 보기
요약

이 페이지는 탄력성을 향상시키고 리전 장애를 견디기 위해 여러 리전에 Teleport 클러스터를 배포하는 방법을 설명합니다. 이 배포는 멀티 리전 탄력성을 제공하기 위해 복잡성과 비용을 크게 증가시킵니다. 이 블루프린트를 수정 없이 정확히 따르세요.

이 페이지는 탄력성을 향상시키고 리전 장애를 견디기 위해 여러 리전에 Teleport 클러스터를 배포하는 방법을 설명합니다.

위험

이 배포는 멀티 리전 탄력성을 제공하기 위해 복잡성과 비용을 크게 증가시킵니다. 멀티 리전 탄력성이 요구사항이 아닌 경우 이 블루프린트를 사용하지 마세요. 대부분의 배포에는 고가용성 클러스터를 권장합니다.

이 블루프린트를 수정 없이 정확히 따르세요. 이 블루프린트의 일부를 수정하면 배포를 지원하지 못할 수 있습니다.

중요한 기술적 고려사항#

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

  • 이 설정은 대부분의 Teleport 사용자와 고객에게 필요하지 않습니다. 단일 리전 멀티 영역 배포는 최적의 가용성/비용 비율을 제공합니다. 예를 들어, Amazon SLA는 DynamoDB와 EC2 모두 99.99%입니다.
  • 멀티 리전 설정은 단일 리전 설정보다 더 나은 확장성을 제공하지 않습니다. 분산되고 중복적인 특성으로 인해 동일한 수의 에이전트에 대해 단일 리전 설정보다 성능이 낮고 비용이 더 많이 듭니다.
  • 이 블루프린트는 많은 복잡한 구성 요소에 의존합니다. 이러한 구성 요소를 배포하고 운영할 팀 역량과 전문성이 없다면 단일 리전 멀티 영역 설정보다 가용성이 낮아질 수 있습니다.
  • 데이터베이스, 객체 저장소, 컨테이너 런타임, 네트워크 플러그인 및 기타 필요한 모든 것을 포함한 Teleport 종속성을 배포하고 유지 관리할 책임은 사용자에게 있습니다.
  • 리전은 완전한 리전 장애 발생 시 모든 트래픽을 처리할 수 있는 충분한 용량으로 프로비저닝되어야 합니다. 여기에는 노드와 사용자가 정상 리전에 다시 연결될 때 새로운 트래픽을 즉시 흡수할 수 있는 능력이 포함됩니다.

멀티 리전 클러스터가 필요한 제한된 대역폭의 팀을 위해 Teleport는 크로스 리전 클러스터 호스팅을 제공합니다. 운영 비용과 복잡성 없이 이 문서에 설명된 설정의 이점을 누릴 수 있으며, 자세한 내용은 Teleport Enterprise (Cloud) 시작 가이드를 참조하세요.

아키텍처 개요#

멀티 리전 Teleport 배포는 여러 리전별 Teleport 배포로 구성됩니다. Teleport는 멀티 리전 백엔드에 상태를 저장하고 프록시 피어링을 사용하여 사용자를 다른 리전에 호스팅된 리소스에 연결합니다.

권장 멀티 리전 백엔드는 자체 호스팅 Teleport Enterprise에서 사용 가능한 CockroachDB 백엔드입니다.

아키텍처 다이어그램

멀티 리전 Teleport 배포를 실행하려면 다음이 필요합니다:

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

Kubernetes에서 멀티 리전 Teleport 구현#

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

Kubernetes CPU 제한

쓰로틀링이 예측할 수 없는 지연 시간을 유발하고, 실시간 인증 및 네트워킹 작업을 방해하며, 정상적인 리전 전반에 걸쳐 연속 장애를 트리거하여 전체 클러스터 중단으로 이어질 수 있으므로 Teleport 구성 요소에 CPU 제한을 설정하는 것을 강력히 권장하지 않습니다.

Teleport 종속성#

  • 3개의 피어링된 리전별 VPC(예: AWS) 또는 1개의 글로벌 VPC(예: GKE)를 생성합니다.
  • 각 리전에 1개의 Kubernetes 클러스터를 생성합니다. 파드 CIDR이 겹치지 않아야 합니다.
  • 파드 메시 연결성을 보장합니다. 프록시 파드는 서로 포트 3021로 연결할 수 있어야 합니다. 설정은 네트워크 및 CNI 플러그인 구성에 따라 다릅니다:
    • 파드가 네이티브 네트워크 레이어를 사용하는 경우(예: GKE 또는 AWS의 vpc-cni 애드온) VPC 피어링, 라우팅, 방화벽 기능만으로 각 Kubernetes 클러스터의 파드를 연결할 수 있습니다.
    • 파드에 비네이티브 IP 주소가 할당된 경우 Cilium 클러스터 메시 기능을 사용하여 파드를 연결할 수 있습니다. 클러스터 메시 단계별 가이드를 제공합니다.
  • 멀티 리전 객체 저장소를 설정합니다:
  • 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;

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

다음 3개의 파일로 끝나야 합니다:

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

CockroachDB Enterprise:

CockroachDB Enterprise의 경우 영역과 리전을 CockroachDB에 선언하고 데이터베이스에 리전 장애 허용을 구성해야 합니다.

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;

CockroachDB 리전의 영향

CockroachDB는 두 리전에 Teleport 데이터를 저장합니다. 2개의 리전별 Teleport 클러스터만 배포하는 경우 동일한 리전을 선택합니다. 3개의 Teleport 클러스터를 배포하는 경우 기본 및 보조 리전의 클러스터는 더 낮은 데이터베이스 지연 시간을 경험합니다.

기본 리전과 보조 리전이 멀리 떨어져 있는 경우(예: 다른 대륙) CockroachDB 쓰기 작업이 느려질 수 있습니다.

CockroachDB 코어:

CockroachDB 코어에서는 물리적 리전을 CockroachDB 영역으로 선언하고 Teleport 데이터베이스에 영역 장애 허용을 구성해야 합니다.

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

CockroachDB 코어는 CockroachDB Enterprise가 제공하는 리전 기능을 제공하지 않습니다. 성능에 영향을 줄 수 있습니다. CockroachDB 코어는 멀티 리전 설정에서 프로덕션에 권장되지 않습니다.

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"
        # 리전별 객체 저장소 URI로 교체하세요 (S3, GCS, MinIO)
        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 호환성 보장을 엄격하게 따르려면 업데이트 전에 단일 auth로 다운스케일해야 합니다. 멀티 리전 설정에서는 다음이 필요합니다:

  • 업데이트 중에 인증을 위해 단일 리전에 의존
  • 두 리전을 일시 중단하거나 프록시가 다른 리전의 auth에 연결할 수 있도록 허용 (이것은 기본값이 아니며 Cilium 크로스 클러스터 서비스와 Proxy Service를 위한 사용자 정의 조인 토큰이 필요합니다).

Auth 롤링 업데이트가 가능합니다. 이 경우 여러 auth 버전이 동시에 실행될 수 있습니다. 새로 도입된 리소스 필드는 모든 auth가 롤아웃될 때까지 제대로 설정되지 않을 수 있습니다.

롤아웃 기간이 짧고 버전 차이가 최소인 경우 이러한 일관성/사용성 트레이드오프는 허용 가능할 수 있습니다.

CockroachDB 크기 조정#

노드당 2개의 CPU와 8GiB 메모리를 가진 3x3 CockroachDB 클러스터(리전당 1개 영역, 3개 영역, 3개 리전)는 10,000개의 SSH 노드로 구성된 Teleport 클러스터를 지원할 수 있습니다.

CockroachDB 성능은 저장소 유형에 따라 다릅니다. CockroachDB의 상태를 SSD에 저장하도록 하세요. Kubernetes에서 실행하는 경우 기본 저장소 클래스가 최상의 지연 시간과 처리량을 제공하는 것이 아닐 수 있습니다.

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

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

중요

Kubernetes에서 실행할 때 정적 CPU 정책을 사용하지 않는 한 Teleport 또는 CockroachDB 파드에 CPU 제한을 설정하는 것을 권장하지 않습니다.

CPU 쓰로틀링이 구현되는 방식으로 인해 Teleport 및 CockroachDB와 같은 멀티스레드 I/O 집약적 애플리케이션은 CPU 제한에 도달하면 성능이 저하됩니다. 이는 서비스 중단으로 이어지고 전체 중단으로 이어질 가능성이 매우 높습니다.

경험적 법칙으로 대부분의 중요한 파드의 resources 섹션은 다음과 같아야 합니다:

resources:
  requests:
    # cpu 및 메모리 요청 설정
    cpu: "2"
    memory: "8Gi"
  limits:
    # 메모리 제한은 메모리 요청과 동일한 값으로 설정
    memory: "8Gi"
    # cpu 제한 없음

멀티 리전 AWS S3 복제 설정#

이 섹션에서는 여러 리전별 S3 버킷과 복제 규칙으로 멀티 리전 객체 저장소를 생성하는 방법을 설명합니다.

  1. 버전 관리가 활성화된 각 리전에 3개의 버킷을 생성합니다
  2. 3개의 버킷을 포함하는 멀티 리전 접근 포인트를 생성합니다
  3. 생성 후 "복제 및 장애 조치" 탭에서 "복제 규칙 생성"과 "지정된 모든 버킷 간에 객체 복제" 템플릿을 선택합니다.

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

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

Teleport가 세션 녹화를 자동으로 정리하도록 하려면 복제 규칙에서 "삭제 마커 복제"를 활성화해야 합니다.

마지막으로 Teleport가 자체적으로 시작된 파일 업로드만 완료하도록 구성해야 합니다(Teleport가 버킷 복제 규칙으로 인한 업로드를 완료하려고 시도하지 않도록).

audit_sessions_uri 값에 complete_initiators=를 설정하여 이를 수행할 수 있습니다. 는 Teleport Auth 서비스가 S3 버킷에 녹화를 업로드하는 데 사용하는 IAM 역할 이름입니다:

auth:
  teleportConfig:
    teleport:
      storage:
        # [다른 저장소 옵션들...]
        audit_sessions_uri: "uri://to-your-regional-bucket?complete_initiators=teleport-iam-role"/>"
        # ...