teleport-cluster v12로의 마이그레이션

이 가이드는 teleport-cluster v12 차트의 주요 변경 사항과 버전 11에서 버전 12로의 기존 배포업그레이드 방법을 다룹니다.

변경 사항 요약

teleport-cluster 차트 버전 12의 주요 변경 사항은 다음과 같습니다:

PodSecurityPolicy가 Kubernetes 1.23 및 1.24에서 제거되었습니다.
Teleport는 이제 Auth 및 Proxy 서비스를 별도의 포드로 배포합니다. 이 새로운 토폴로지로 Teleport를 실행하면 중단에 더 탄력적이고 더 나은 확장성을 가질 수 있습니다.
프록시는 이제 상태 없는 워크로드로 배포됩니다. proxy 세션 기록 모드는 기록을 비동기적으로 업로드합니다. 업로드되지 않은 기록은 롤아웃 중에 손실될 수 있습니다 (예: 구성 변경 또는 버전 업그레이드). proxy-sync는 일관성을 보장하며 이 제한이 없습니다.
custom 모드는 토폴로지 변경으로 인해 작동하지 않기 때문에 제거되었습니다. 임의의 Teleport 구성 값을 전달할 수 있는 새로운 구성 오버라이드 메커니즘으로 대체되었습니다.
이전에 persistence를 위해 사용된 standalone.* 값이 제거되었습니다.
이제 차트를 standalone 모드에서 스케일 업할 수 있습니다. 프록시 복제에는 TLS 인증서가 필요하고, 인증 복제에는 HA 스토리지 백엔드를 사용해야 합니다.

버전 호환성

이 차트는 항상 Teleport와 함께 버전 관리되었으나 종종 이전 Teleport 주요 버전과 호환 가능했습니다. v12의 경우는 다릅니다. 차트 v12를 사용하려면 최소한 Teleport v12가 필요합니다.

업그레이드 방법

Kubernetes 1.23 이상을 실행 중이면, 우리의 Kubernetes 1.25 PSP 제거 가이드를 따르세요.

그런 다음 업그레이드 경로는 주로 사용된 chartMode에 따라 다릅니다. "관리형" 모드인 aws, gcp 또는 standalone을 사용한 경우 상대적으로 간단할 것입니다. custom 차트 모드에 의존한 경우 구성 변경을 수행해야 합니다.

업그레이드 전에 항상:

클러스터 내용을 백업하세요,
비생산 환경에서 업그레이드를 테스트하세요.

Warning

업그레이드 중에 Kubernetes는 기존 배포를 삭제하고 새로운 배포를 생성합니다. 이는 원활하지 않으며 새로운 포드가 가동되고 모든 상태 검사에 통과할 때까지 일부 다운타임을 발생시킵니다. 이는 일반적으로 약 5분이 소요됩니다.

`gcp`, `aws` 또는 `standalone` 모드를 사용하는 경우

업그레이드 시 구성 변경이 필요하지 않아야 합니다. 스토리지 구성에 standalone.*에 의존하지 않는지 확인하세요 (의존하는 경우 persistence 값을 사용하도록 전환하세요).

v12로 업그레이드하면 auth와 프록시를 별도로 배포하므로 배포되는 포드 수가 증가합니다. 차트는 가능할 경우 여러 프록시 복제를 배포하려고 시도합니다 (프록시는 인증서가 비밀 또는 cert-manager를 통해 제공되는 경우 복제 가능). 추가 Teleport 포드를 실행할 수 있도록 Kubernetes 클러스터에 충분한 공간이 있는지 확인하세요:

aws 및 gcp는 배포되는 포드 수가 두 배가 됩니다.
standalone은 1 또는 2개의 추가 포드를 배포합니다 (프록시를 복제할 수 있는지에 따라 다릅니다).

추가 포드가 이전보다 배포되고 준비되기까지 시간이 더 걸릴 수 있습니다. --wait 또는 --atomic과 함께 helm을 실행하는 경우 타임아웃을 최소 10분으로 늘리세요.

`custom` 모드를 사용하는 경우

custom 모드는 Teleport 구성을 ConfigMap을 통해 전달함으로써 작동했습니다. 버전 12의 토폴로지 변경으로 인해 기존 custom 구성은 그대로 작동하지 않으며 프록시 및 인증을 위한 두 개의 별도 구성으로 나누어야 합니다.

예상치 못한 파괴적인 업그레이드를 피하기 위해, teleport-cluster v12 차트는 custom 모드에서 배포를 거부하고 이 마이그레이션 가이드로 안내합니다.

버전 12는 완전한 구성 파일을 작성할 필요 없이 Teleport에 임의 구성을 전달하는 새로운 방법을 도입했습니다. (예: etcd 백엔드 지원과 같은) 차트 기능이 부족하여 custom 모드를 사용했다면, 여기서 맞춤형 구성을 관리하는 것보다 진행하는 것이 더 나을 수 있습니다.

Teleport 클러스터를 배포하는 경우

이제 기존 모드인 aws, gcp, standalone을 사용하고 auth.teleportConfig와 proxy.teleportConfig 값을 통해 사용자 정의 구성을 오버라이드할 수 있습니다. 대부분의 경우 이 설정이 권장되며, 미래 구성 업그레이드의 혜택을 자동으로 받게 됩니다.

구성을 두 개로 나누어야 하며, 각 노드 유형에 대한 구성이 필요합니다:

proxy 구성에는 최소한 proxy_service 섹션과 storage 부분이 없는 teleport 섹션이 포함되어야 합니다.
auth 구성에는 최소한 auth_service 및 teleport 섹션이 포함되어야 합니다.

예를 들어, 다음과 같은 v11 사용자 정의 구성이 있을 경우:

teleport:
  log:
    output: stderr
    severity: INFO
auth_service:
  enabled: true
  cluster_name: custom.example.com
  tokens:                                        # 이것은 사용자 정의 구성입니다.
  - "proxy,node:abcd123-insecure-do-not-use-this"
  - "trusted_cluster:efgh456-insecure-do-not-use-this"
  listen_addr: 0.0.0.0:3025
  public_addr: custom.example.com:3025
  session_recording: node-sync
proxy_service:
  enabled: true
  listen_addr: 0.0.0.0:3080
  public_addr: custom.example.com:443
  ssh_public_addr: ssh-custom.example.com:3023   # 이것은 사용자 정의 구성입니다.

다음과 같은 값으로 변환될 수 있습니다:

chartMode: standalone
clusterName: custom.example.com

sessionRecording: node-sync

auth:
  teleportConfig:
    auth_service:
      tokens:
        - "proxy,node:abcd123-insecure-do-not-use-this"
        - "trusted_cluster:efgh456-insecure-do-not-use-this"

proxy:
  teleportConfig:
    proxy_service:
      ssh_public_addr: ssh-custom.example.com:3023

Warning

teleport.cluster_name와 teleport.auth_service.authentication.webauthn.rp_id는 변경되지 않아야 합니다.

Teleport 노드를 배포하는 경우

custom 모드를 사용하여 app_service, db_service, kube_service, windows_service 또는 discovery_service와 같은 서비스만 배포하는 경우 이 목적에 대해 teleport-kube-agent 차트를 사용해야 합니다.

이 차트는 app_service, kube_service 및 db_service를 구성하는 값을 제공하지만, 다른 서비스는 teleportConfig 값을 통해 구성할 수 있습니다.

teleport-cluster 차트에서 teleport-kube-agent 차트로 마이그레이션하려면, 다음 값을 사용하세요:

proxyAddr: teleport.example.com
# 토큰을 `teleportConfig`가 아니라 joinParams를 통해 전달하여
# Kubernetes 비밀에 저장되도록 합니다.
joinParams:
  method: token
  tokenName: abcd123-insecure-do-not-use-this

# 구성 요소를 모두 `teleportConfig`로 전달하는 경우 역할은 비어 있을 수 있습니다.
roles: ""

# 아래의 `teleport` 섹션을 제외한 모든 이전 `teleport.yaml` 값을 넣으세요.
teleportConfig:
  # kubernetes_service:
  #   enabled: true
  #   [...]
  # discovery_service:
  #   enabled: true
  #   [...]

더 나아가기

새로운 토폴로지는 프록시를 복제하여 가용성을 높일 수 있는 기능을 제공합니다. Kubernetes 리소스나 친화도와 같은 설정을 조정할 수도 있습니다.

기본적으로 각 값은 proxy 및 auth 포드 모두에 적용됩니다. 예를 들어:

resources:
  requests:
    cpu: "1"
    memory: "2GiB"
  limits:
    cpu: "1"
    memory: "2GiB"

highAvailability:
  requireAntiAffinity: true

그러나 특정 포드 집합에 대한 값을 범위 지정하려면, proxy 또는 auth 값 아래에 중첩하여 설정할 수 있습니다. 루트의 값과 특정 값이 모두 설정된 경우, 특정 값이 우선합니다:

# 기본적으로 모든 포드는 이러한 리소스를 사용합니다.
resources:
  requests:
    cpu: "1"
    memory: "2GiB"
  limits:
    cpu: "1"
    memory: "2GiB"

proxy:
  # 그러나 프록시 포드는 다른 리소스 요청과 cpu 제한이 없습니다.
  resources:
    requests:
      cpu: "0.5"
      memory: "1GiB"
    limits:
      cpu: ~  # 일반 및 특정 구성이 병합됩니다: 값을 설정 해제하려는 경우, 명시적으로 해야 합니다.
      memory: "1GiB"

auth:
  # 오직 인증 포드만 안티 어피니티를 요구합니다.
  highAvailability:
    requireAntiAffinity: true

Teleport 원문 보기