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

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

변경 사항 요약

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

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

버전 호환성

차트는 항상 Teleport와 함께 버전이 지정되었지만 이전의 Teleport 주요 버전과 호환되는 경우가 많았습니다. v12의 경우는 그렇지 않습니다. 차트 v12를 사용하려면 최소한 Teleport v12가 필요합니다.

업그레이드하는 방법

Kubernetes 1.23 이상을 실행하는 경우, 우리의 Kubernetes 1.25 PSP 제거 가이드를 따르십시오.

그런 다음 업그레이드 경로는 사용 중인 chartMode 에 따라 주로 결정됩니다. "managed" 모드(예: 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 로 헬름을 실행하고 있는 경우 타임아웃을 최소 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 모드에서 teleport-cluster 차트를 사용하여 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
# token을 `teleportConfig` 대신 joinParams를 통해 전달하여 Kubernetes Secret에
# ConfigMap 대신 존재하도록 합니다.
joinParams:
  method: token
  tokenName: abcd123-insecure-do-not-use-this

# 모든 구성을 `teleportConfig` 를 통해 전달할 경우 역할은 비워둘 수 있습니다.
roles: ""

# 이전의 모든 `teleport.yaml` 값을 `teleport` 섹션을 제외하고 아래에 기입하세요.
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:
  # 오직 auth 팟만 안티 친화성이 필요합니다
  highAvailability:
    requireAntiAffinity: true

Teleport 원문 보기