InfoGrab Docs

Teleport 에이전트 고가용성

요약

동일한 인프라 리소스를 프록시하는 여러 Teleport 에이전트를 실행하여 고가용성을 구현할 수 있습니다. 이 가이드는 에이전트 고가용성의 작동 방식과 조직에서 구성하는 방법을 설명합니다. 고가용성 배포를 지원하는 네 가지 Teleport 에이전트 서비스가 있습니다:

동일한 인프라 리소스를 프록시하는 여러 Teleport 에이전트를 실행하여 고가용성을 구현할 수 있습니다. 하나의 Teleport 에이전트가 오프라인 상태가 되더라도, Teleport 사용자는 해당 에이전트가 프록시하도록 구성된 인프라 리소스에 계속 연결할 수 있습니다.

이 가이드는 에이전트 고가용성의 작동 방식과 조직에서 구성하는 방법을 설명합니다. 고가용성 에이전트 배포를 직접 유지 관리해야 하므로, 이 가이드는 이러한 배포가 어떻게 작동하는지 이해할 수 있도록 아키텍처 컨텍스트를 제공합니다.

고가용성 배포를 지원하는 네 가지 Teleport 에이전트 서비스가 있습니다:

  • Teleport Application Service
  • Teleport Database Service
  • Teleport Desktop Service
  • Teleport Kubernetes Service

팁: 일반적으로, Teleport Proxy Service에 연결된 두 에이전트가 동일한 구성을 가지면, 해당 에이전트들은 동일한 인프라 리소스를 프록시하며 Teleport Proxy Service는 이들 사이에서 사용자 트래픽을 로드 밸런싱합니다.

작동 방식#

Teleport Proxy Service가 Teleport로 보호된 리소스에 대한 트래픽을 수신하면, 해당 리소스를 프록시할 수 있는 사용 가능한 Teleport 에이전트를 찾아 트래픽을 전달합니다.

에이전트 하트비트#

각 Teleport 에이전트는 프록시하는 각 인프라 리소스에 대해 Teleport Proxy Service에 주기적인 하트비트 메시지를 전송합니다. Teleport Proxy Service는 하트비트를 사용하여 각 리소스가 에이전트와 연결된, 지속적으로 업데이트되는 Teleport로 보호된 리소스 목록을 구성합니다.

에이전트가 각 등록된 리소스에 대해 하트비트를 전송하므로, 여러 에이전트가 동일한 리소스를 프록시하는 경우 Proxy Service는 리소스-에이전트 조합의 여러 레코드를 유지합니다.

예를 들어, us-east-1a의 에이전트와 us-east-1b의 에이전트가 모두 myapp이라는 애플리케이션을 프록시하는 경우, Proxy Service는 별도의 하트비트를 수신하고 us-east-1a의 myapp과 us-east-1b의 myapp에 대한 별도의 레코드를 유지합니다.

Proxy Service 로드 밸런싱#

Teleport Proxy Service가 Teleport로 보호된 리소스에 대한 트래픽을 수신하면, 해당 트래픽이 기존 세션에 속하는지 여부를 확인합니다. 기존 세션에 속하는 경우, Proxy Service는 해당 세션과 연결된 Teleport 에이전트로 트래픽을 전달합니다. 그렇지 않은 경우, Proxy Service는 대상 리소스를 프록시하도록 구성된 Teleport 에이전트 목록을 조회하고(이전 섹션에서 설명한 하트비트 기반으로), 새 세션을 생성하고 목록에서 임의의 정상 에이전트와 연결합니다.

Teleport가 대상 인프라의 세션을 추적하기 때문에, Teleport 에이전트는 상태 비저장(stateless) 방식이 아닙니다. 사용자 연결을 프록시하는 에이전트를 잃으면 사용자는 새 세션을 설정해야 합니다.

사용자 경험#

tsh, Web UI, Teleport Connect는 특정 이름을 가진 각 Teleport로 보호된 리소스의 단일 인스턴스를 나열하므로, 최종 사용자는 특정 리소스를 프록시하는 Teleport 에이전트가 몇 개인지 알 필요가 없습니다.

이는 사용자가 여러 에이전트에 의해 프록시되는 인프라 리소스에 접근하려는 경우, 에이전트 중 하나가 사용 불가능해지더라도(새 세션을 설정하기 위한 약간의 지연이 있을 수 있음) 동일한 경험을 계속 유지할 수 있음을 의미합니다.

프록시된 리소스 구성#

Teleport 에이전트 구성 파일에는 에이전트가 인프라 리소스를 프록시하도록 지시하는 두 가지 방법이 있습니다:

  • 정적 리소스 구성: 에이전트가 프록시할 구성된 인프라 리소스 목록.
  • 동적 리소스 워처: 에이전트가 Teleport Auth Service에서 애플리케이션, 데이터베이스, Kubernetes 클러스터, 원격 데스크톱을 나타내는 동적 리소스를 가져오는 데 사용하는 필터 목록. 에이전트는 필터와 일치하는 인프라 리소스를 프록시합니다.

에이전트가 부팅되면 각 정적 리소스 구성에 대한 하트비트 메시지를 전송하기 시작합니다. 또한 동적 리소스 워처를 시작하고, 이와 일치하는 동적 리소스 구성을 가져와 각 일치하는 리소스에 대한 하트비트 전송을 시작합니다.

정적 리소스 구성#

정적 리소스 구성에서 에이전트가 인프라 리소스를 프록시하는 데 필요한 모든 정보는 처음 시작할 때 읽는 구성 파일에 있습니다. 동일한 이름의 인프라 리소스를 프록시하는 여러 에이전트가 있는 경우, Proxy Service는 그들 사이에서 사용자 트래픽을 로드 밸런싱합니다:

동일한 이름의 애플리케이션을 프록시하도록 Teleport Application Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
app_service:
  enabled: true
  apps:
  - name: "myapp"
    uri: "example.com"

동일한 이름의 데이터베이스를 프록시하도록 Teleport Database Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
db_service:
  enabled: true
  databases:
  - name: "postgres"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

동일한 kube_cluster_name을 가진 Kubernetes 클러스터를 프록시하도록 Teleport Kubernetes Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
kubernetes_service:
  enabled: true
  # Include the same kubeconfig for all agents.
  kubeconfig_file: /secrets/kubeconfig
  kube_cluster_name: mycluster

동일한 이름의 데스크톱을 프록시하도록 Teleport Desktop Service의 여러 인스턴스를 구성할 수 있습니다:

windows_desktop_service:
  enabled: true
  static_hosts:
    - name: example1
      ad: false
      addr: win1.dev.example.com

Teleport Desktop Service의 내장 검색 기능을 사용할 때, 서비스는 호스트 이름을 기반으로 자동으로 데스크톱 이름을 지정합니다.

연결할 에이전트 복제본 선택

별도의 복제본을 사용하면, 특정 인프라 리소스를 프록시하는 각 에이전트 서비스 인스턴스는 다른 이름을 갖습니다. 이를 통해 리소스에 연결할 에이전트를 명시적으로 선택할 수 있습니다. 다음 예시에서는 두 Teleport Database Service 인스턴스가 동일한 데이터베이스를 프록시합니다.

첫 번째 Database Service 인스턴스에서 데이터베이스의 이름은 postgres-us-east-1a입니다:

# Database service instance #1.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #2 but the URI is the same.
  - name: "postgres-us-east-1a"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

두 번째 인스턴스에서는 구성된 데이터베이스는 동일하지만 에이전트 구성에서 다른 이름을 부여합니다:

# Database service instance #2.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #1 but the URI is the same.
  - name: "postgres-us-east-1b"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

이 구성으로 두 서비스는 tsh db ls 출력에 별도의 항목으로 나타나며, 연결 시 명시적으로 하나를 선택해야 합니다:

$ tsh db ls
# Name
# -------------------
# postgres-us-east-1a
# postgres-us-east-1b

$ tsh db connect postgres-us-east-1a

이 방식은 연결에 사용할 복제본을 제어하고 싶을 때 유용합니다.

동적 리소스 워처#

에이전트가 동적 리소스 워처를 로드하면, Teleport Auth Service에서 프록시할 인프라 리소스를 나타내는 동적 리소스를 가져와 구성된 규칙 집합과 일치하도록 필터링합니다.

예를 들어, Teleport Application Service는 특정 레이블을 포함하는 한 app 리소스를 가져옵니다.

모든 동적 리소스와 마찬가지로, 인프라를 나타내는 리소스에는 metadata.name 필드가 포함됩니다. 두 인프라 리소스가 동일한 이름을 가지는 경우, Teleport Proxy Service는 그들 사이에서 사용자 트래픽을 로드 밸런싱합니다.

동적 리소스 워처의 예시 구성을 보려면 리소스 유형을 선택하세요:

app 리소스를 감시하도록 Teleport Application Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

app_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

db 리소스를 감시하도록 Teleport Database Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

db_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

kube_cluster 동적 리소스를 감시하도록 Teleport Kubernetes Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

kubernetes_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

dynamic_windows_desktop 리소스를 감시하도록 Windows Desktop Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

windows_desktop_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

다음 단계#

동적 리소스 워처를 사용하면 Teleport로 보호된 리소스의 이름을 미리 알 필요 없이 Teleport 에이전트의 고가용성을 구성할 수 있습니다.

Teleport 자동 검색을 사용하면 온라인 상태가 되는 인프라 리소스를 Teleport에 자동으로 등록할 수 있습니다. 리소스 이름이 자동으로 채워지므로, 적절한 동적 리소스 워처가 있는 에이전트가 두 개 이상 있는 한 고가용성이 이미 활성화됩니다. 자동 검색 시작하기.

Teleport 에이전트 고가용성

원문 보기
요약

동일한 인프라 리소스를 프록시하는 여러 Teleport 에이전트를 실행하여 고가용성을 구현할 수 있습니다. 이 가이드는 에이전트 고가용성의 작동 방식과 조직에서 구성하는 방법을 설명합니다. 고가용성 배포를 지원하는 네 가지 Teleport 에이전트 서비스가 있습니다:

동일한 인프라 리소스를 프록시하는 여러 Teleport 에이전트를 실행하여 고가용성을 구현할 수 있습니다. 하나의 Teleport 에이전트가 오프라인 상태가 되더라도, Teleport 사용자는 해당 에이전트가 프록시하도록 구성된 인프라 리소스에 계속 연결할 수 있습니다.

이 가이드는 에이전트 고가용성의 작동 방식과 조직에서 구성하는 방법을 설명합니다. 고가용성 에이전트 배포를 직접 유지 관리해야 하므로, 이 가이드는 이러한 배포가 어떻게 작동하는지 이해할 수 있도록 아키텍처 컨텍스트를 제공합니다.

고가용성 배포를 지원하는 네 가지 Teleport 에이전트 서비스가 있습니다:

  • Teleport Application Service
  • Teleport Database Service
  • Teleport Desktop Service
  • Teleport Kubernetes Service

팁: 일반적으로, Teleport Proxy Service에 연결된 두 에이전트가 동일한 구성을 가지면, 해당 에이전트들은 동일한 인프라 리소스를 프록시하며 Teleport Proxy Service는 이들 사이에서 사용자 트래픽을 로드 밸런싱합니다.

작동 방식#

Teleport Proxy Service가 Teleport로 보호된 리소스에 대한 트래픽을 수신하면, 해당 리소스를 프록시할 수 있는 사용 가능한 Teleport 에이전트를 찾아 트래픽을 전달합니다.

에이전트 하트비트#

각 Teleport 에이전트는 프록시하는 각 인프라 리소스에 대해 Teleport Proxy Service에 주기적인 하트비트 메시지를 전송합니다. Teleport Proxy Service는 하트비트를 사용하여 각 리소스가 에이전트와 연결된, 지속적으로 업데이트되는 Teleport로 보호된 리소스 목록을 구성합니다.

에이전트가 각 등록된 리소스에 대해 하트비트를 전송하므로, 여러 에이전트가 동일한 리소스를 프록시하는 경우 Proxy Service는 리소스-에이전트 조합의 여러 레코드를 유지합니다.

예를 들어, us-east-1a의 에이전트와 us-east-1b의 에이전트가 모두 myapp이라는 애플리케이션을 프록시하는 경우, Proxy Service는 별도의 하트비트를 수신하고 us-east-1a의 myapp과 us-east-1b의 myapp에 대한 별도의 레코드를 유지합니다.

Proxy Service 로드 밸런싱#

Teleport Proxy Service가 Teleport로 보호된 리소스에 대한 트래픽을 수신하면, 해당 트래픽이 기존 세션에 속하는지 여부를 확인합니다. 기존 세션에 속하는 경우, Proxy Service는 해당 세션과 연결된 Teleport 에이전트로 트래픽을 전달합니다. 그렇지 않은 경우, Proxy Service는 대상 리소스를 프록시하도록 구성된 Teleport 에이전트 목록을 조회하고(이전 섹션에서 설명한 하트비트 기반으로), 새 세션을 생성하고 목록에서 임의의 정상 에이전트와 연결합니다.

Teleport가 대상 인프라의 세션을 추적하기 때문에, Teleport 에이전트는 상태 비저장(stateless) 방식이 아닙니다. 사용자 연결을 프록시하는 에이전트를 잃으면 사용자는 새 세션을 설정해야 합니다.

사용자 경험#

tsh, Web UI, Teleport Connect는 특정 이름을 가진 각 Teleport로 보호된 리소스의 단일 인스턴스를 나열하므로, 최종 사용자는 특정 리소스를 프록시하는 Teleport 에이전트가 몇 개인지 알 필요가 없습니다.

이는 사용자가 여러 에이전트에 의해 프록시되는 인프라 리소스에 접근하려는 경우, 에이전트 중 하나가 사용 불가능해지더라도(새 세션을 설정하기 위한 약간의 지연이 있을 수 있음) 동일한 경험을 계속 유지할 수 있음을 의미합니다.

프록시된 리소스 구성#

Teleport 에이전트 구성 파일에는 에이전트가 인프라 리소스를 프록시하도록 지시하는 두 가지 방법이 있습니다:

  • 정적 리소스 구성: 에이전트가 프록시할 구성된 인프라 리소스 목록.
  • 동적 리소스 워처: 에이전트가 Teleport Auth Service에서 애플리케이션, 데이터베이스, Kubernetes 클러스터, 원격 데스크톱을 나타내는 동적 리소스를 가져오는 데 사용하는 필터 목록. 에이전트는 필터와 일치하는 인프라 리소스를 프록시합니다.

에이전트가 부팅되면 각 정적 리소스 구성에 대한 하트비트 메시지를 전송하기 시작합니다. 또한 동적 리소스 워처를 시작하고, 이와 일치하는 동적 리소스 구성을 가져와 각 일치하는 리소스에 대한 하트비트 전송을 시작합니다.

정적 리소스 구성#

정적 리소스 구성에서 에이전트가 인프라 리소스를 프록시하는 데 필요한 모든 정보는 처음 시작할 때 읽는 구성 파일에 있습니다. 동일한 이름의 인프라 리소스를 프록시하는 여러 에이전트가 있는 경우, Proxy Service는 그들 사이에서 사용자 트래픽을 로드 밸런싱합니다:

동일한 이름의 애플리케이션을 프록시하도록 Teleport Application Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
app_service:
  enabled: true
  apps:
  - name: "myapp"
    uri: "example.com"

동일한 이름의 데이터베이스를 프록시하도록 Teleport Database Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
db_service:
  enabled: true
  databases:
  - name: "postgres"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

동일한 kube_cluster_name을 가진 Kubernetes 클러스터를 프록시하도록 Teleport Kubernetes Service의 여러 인스턴스를 구성할 수 있습니다:

# Same config for all agents in the pool.
kubernetes_service:
  enabled: true
  # Include the same kubeconfig for all agents.
  kubeconfig_file: /secrets/kubeconfig
  kube_cluster_name: mycluster

동일한 이름의 데스크톱을 프록시하도록 Teleport Desktop Service의 여러 인스턴스를 구성할 수 있습니다:

windows_desktop_service:
  enabled: true
  static_hosts:
    - name: example1
      ad: false
      addr: win1.dev.example.com

Teleport Desktop Service의 내장 검색 기능을 사용할 때, 서비스는 호스트 이름을 기반으로 자동으로 데스크톱 이름을 지정합니다.

연결할 에이전트 복제본 선택

별도의 복제본을 사용하면, 특정 인프라 리소스를 프록시하는 각 에이전트 서비스 인스턴스는 다른 이름을 갖습니다. 이를 통해 리소스에 연결할 에이전트를 명시적으로 선택할 수 있습니다. 다음 예시에서는 두 Teleport Database Service 인스턴스가 동일한 데이터베이스를 프록시합니다.

첫 번째 Database Service 인스턴스에서 데이터베이스의 이름은 postgres-us-east-1a입니다:

# Database service instance #1.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #2 but the URI is the same.
  - name: "postgres-us-east-1a"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

두 번째 인스턴스에서는 구성된 데이터베이스는 동일하지만 에이전트 구성에서 다른 이름을 부여합니다:

# Database service instance #2.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #1 but the URI is the same.
  - name: "postgres-us-east-1b"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

이 구성으로 두 서비스는 tsh db ls 출력에 별도의 항목으로 나타나며, 연결 시 명시적으로 하나를 선택해야 합니다:

$ tsh db ls
# Name
# -------------------
# postgres-us-east-1a
# postgres-us-east-1b

$ tsh db connect postgres-us-east-1a

이 방식은 연결에 사용할 복제본을 제어하고 싶을 때 유용합니다.

동적 리소스 워처#

에이전트가 동적 리소스 워처를 로드하면, Teleport Auth Service에서 프록시할 인프라 리소스를 나타내는 동적 리소스를 가져와 구성된 규칙 집합과 일치하도록 필터링합니다.

예를 들어, Teleport Application Service는 특정 레이블을 포함하는 한 app 리소스를 가져옵니다.

모든 동적 리소스와 마찬가지로, 인프라를 나타내는 리소스에는 metadata.name 필드가 포함됩니다. 두 인프라 리소스가 동일한 이름을 가지는 경우, Teleport Proxy Service는 그들 사이에서 사용자 트래픽을 로드 밸런싱합니다.

동적 리소스 워처의 예시 구성을 보려면 리소스 유형을 선택하세요:

app 리소스를 감시하도록 Teleport Application Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

app_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

db 리소스를 감시하도록 Teleport Database Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

db_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

kube_cluster 동적 리소스를 감시하도록 Teleport Kubernetes Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

kubernetes_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

dynamic_windows_desktop 리소스를 감시하도록 Windows Desktop Service를 구성하려면 resources 구성에 labels 필드를 추가하세요:

windows_desktop_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

다음 단계#

동적 리소스 워처를 사용하면 Teleport로 보호된 리소스의 이름을 미리 알 필요 없이 Teleport 에이전트의 고가용성을 구성할 수 있습니다.

Teleport 자동 검색을 사용하면 온라인 상태가 되는 인프라 리소스를 Teleport에 자동으로 등록할 수 있습니다. 리소스 이름이 자동으로 채워지므로, 적절한 동적 리소스 워처가 있는 에이전트가 두 개 이상 있는 한 고가용성이 이미 활성화됩니다. 자동 검색 시작하기.