InfoGrab DocsInfoGrab Docs

Kubernetes에서 Calls 배포

요약

이 가이드는 Kubernetes 환경에서 Mattermost Calls를 배포하는 방법에 대한 자세한 정보를 제공합니다. Mattermost Calls는 배포의 확장성과 제어를 개선하기 위해 Kubernetes와 통합되도록 설계되었습니다.

사용 가능 플랜: Entry, Professional, Enterprise, Enterprise Advanced

이 가이드는 Kubernetes 환경에서 Mattermost Calls를 배포하는 방법에 대한 자세한 정보를 제공합니다.

개요#

Mattermost Calls는 배포의 확장성과 제어를 개선하기 위해 Kubernetes와 통합되도록 설계되었습니다. RTCD 서비스를 사용하는 방식이 유일하게 지원되는 배포 모델입니다.

아키텍처#

Kubernetes 클러스터에 배포된 Calls

이 다이어그램은 RTCD 독립 실행형 서비스를 Kubernetes 클러스터에 배포하는 방법을 보여 줍니다. 이 아키텍처에서는 다음과 같이 동작합니다.

  1. Calls 트래픽은 전용 RTCD Pod가 처리합니다.
  2. 스케일링은 Kubernetes Deployment 구성을 통해 관리됩니다.
  3. 통화 녹음과 전사는 calls-offloader 서비스가 처리합니다(Calls Offloader 설정 및 구성 참조).

Mattermost가 Kubernetes 클러스터에 아직 배포되어 있지 않은데 이 배포 유형을 사용하려면 Kubernetes 오퍼레이터 가이드를 참조하세요.

Helm 차트 배포#

Kubernetes 환경에서 Calls 관련 구성 요소를 배포하는 권장 방법은 공식 Helm 차트를 사용하는 것입니다.

RTCD Helm 차트#

RTCD Helm 차트는 통화 미디어 처리에 필요한 RTCD 서비스를 배포합니다.

helm repo add mattermost https://helm.mattermost.com
helm repo update

helm install mattermost-rtcd mattermost/mattermost-rtcd \
  --set service.annotations."service\\.beta\\.kubernetes\\.io/aws-load-balancer-backend-protocol"=udp

전체 구성 옵션은 RTCD Helm 차트 문서를 참조하세요.

Calls-Offloader Helm 차트#

통화 녹음과 전사 기능이 필요하면 calls-offloader 서비스를 배포하세요.

helm install mattermost-calls-offloader mattermost/mattermost-calls-offloader \
  --set ingress.enabled=true \
  --set ingress.host=calls-offloader.example.com

전체 구성 옵션은 Calls-Offloader Helm 차트 문서를 참조하세요.

Kubernetes 전용 구성#

네트워크 구성#

Kubernetes 배포에서는 특정 연결 경로가 확보되어 있어야 합니다.

  1. 클라이언트에서 RTCD로의 연결: 포트 8443의 UDP 및 TCP 트래픽이 클라이언트에서 RTCD Pod로 올바르게 라우팅되어야 합니다(미디어용이며, TCP는 폴백 역할을 합니다).
  2. Mattermost에서 RTCD API로의 연결: API 포트(TCP 8045)에서 Mattermost와 RTCD 사이에 명확한 연결 경로가 있어야 합니다.
  3. 네트워크 정책: 네트워크 정책에서 Mattermost와 RTCD 서비스 간에 필요한 통신을 허용해야 합니다.

리소스 요구 사항#

RTCD Pod의 리소스 요구 사항은 예상 통화량, 참가자 수, 화면 공유 사용 여부에 크게 좌우됩니다.

일반적인 기본값에 의존하기보다 성능 기준선을 검토하여 배포 요구에 적합한 CPU, 메모리, 네트워크 요청 및 제한을 결정할 것을 강력히 권장합니다.

스케일링 고려 사항#

RTCD Pod의 수평 스케일링이 가능하지만 다음 사항에 유의하세요.

  1. 각 통화는 전적으로 하나의 RTCD Pod에서 호스팅됩니다.
  2. 서버가 RTCD 서버를 찾을 수 있도록 모든 RTCD Pod에 대해 DNS A 레코드를 설정해야 합니다.
  3. 정상 상태인 Pod만 DNS를 통해 보고되도록 상태 점검을 구성해야 합니다.
  4. 통화는 지속되는 동안 할당된 Pod에 계속 유지됩니다.

제한 사항#

WebRTC 서비스를 호스팅하는 데 내재된 복잡성 때문에 Kubernetes 환경에 Calls를 배포할 때는 몇 가지 제한 사항이 적용됩니다.

핵심 요구 사항 중 하나는 각 rtcd 프로세스가 전용 Kubernetes 노드에서 실행되어야 한다는 것입니다. 이는 수평 스케일링을 허용하면서 데이터를 올바르게 전달하기 위해 필요합니다. 데이터는 일반적으로 rtcd 프로세스를 실행하는 Pod로 직접 전달되어야 하며, 이 트래픽을 표준 인그레스를 통해 라우팅하는 것은 RTCD 배포에 권장되지 않습니다.

일반적인 권장 사항은 rtcd 인스턴스(Kubernetes 노드)마다 외부 IP 주소를 하나씩 노출하는 것입니다. 이렇게 하면 애플리케이션이 (STUN을 통해) 자체 외부 주소를 감지하고 이를 클라이언트에 알려 최소한의 구성으로 연결을 확보할 수 있으므로 스케일링이 더 간단해집니다.

모니터링 및 메트릭#

메트릭 수집과 모니터링에 대한 자세한 내용은 Calls 메트릭 및 모니터링 가이드를 참조하세요.

문제 해결#

Kubernetes 관련 문제 해결 방법은 다음과 같습니다.

  1. Pod 로그를 확인합니다: kubectl logs -f deployment/mattermost-rtcd
  2. 서비스 연결을 확인합니다: kubectl port-forward service/mattermost-rtcd 8045:8045
  3. UDP 및 TCP 트래픽이 로드 밸런서를 통해 올바르게 라우팅되는지 확인합니다.
  4. 네트워크 정책이 필요한 통신 경로를 허용하는지 확인합니다.

자세한 로깅 안내는 Calls 로깅 가이드를 참조하세요.

기타 Calls 문서#

Kubernetes에서 Calls 배포

Mattermost v12.0
원문 보기

요약

이 가이드는 Kubernetes 환경에서 Mattermost Calls를 배포하는 방법에 대한 자세한 정보를 제공합니다. Mattermost Calls는 배포의 확장성과 제어를 개선하기 위해 Kubernetes와 통합되도록 설계되었습니다.

사용 가능 플랜: Entry, Professional, Enterprise, Enterprise Advanced

이 가이드는 Kubernetes 환경에서 Mattermost Calls를 배포하는 방법에 대한 자세한 정보를 제공합니다.

개요#

Mattermost Calls는 배포의 확장성과 제어를 개선하기 위해 Kubernetes와 통합되도록 설계되었습니다. RTCD 서비스를 사용하는 방식이 유일하게 지원되는 배포 모델입니다.

아키텍처#

Kubernetes 클러스터에 배포된 Calls

이 다이어그램은 RTCD 독립 실행형 서비스를 Kubernetes 클러스터에 배포하는 방법을 보여 줍니다. 이 아키텍처에서는 다음과 같이 동작합니다.

  1. Calls 트래픽은 전용 RTCD Pod가 처리합니다.
  2. 스케일링은 Kubernetes Deployment 구성을 통해 관리됩니다.
  3. 통화 녹음과 전사는 calls-offloader 서비스가 처리합니다(Calls Offloader 설정 및 구성 참조).

Mattermost가 Kubernetes 클러스터에 아직 배포되어 있지 않은데 이 배포 유형을 사용하려면 Kubernetes 오퍼레이터 가이드를 참조하세요.

Helm 차트 배포#

Kubernetes 환경에서 Calls 관련 구성 요소를 배포하는 권장 방법은 공식 Helm 차트를 사용하는 것입니다.

RTCD Helm 차트#

RTCD Helm 차트는 통화 미디어 처리에 필요한 RTCD 서비스를 배포합니다.

helm repo add mattermost https://helm.mattermost.com
helm repo update

helm install mattermost-rtcd mattermost/mattermost-rtcd \
  --set service.annotations."service\\.beta\\.kubernetes\\.io/aws-load-balancer-backend-protocol"=udp

전체 구성 옵션은 RTCD Helm 차트 문서를 참조하세요.

Calls-Offloader Helm 차트#

통화 녹음과 전사 기능이 필요하면 calls-offloader 서비스를 배포하세요.

helm install mattermost-calls-offloader mattermost/mattermost-calls-offloader \
  --set ingress.enabled=true \
  --set ingress.host=calls-offloader.example.com

전체 구성 옵션은 Calls-Offloader Helm 차트 문서를 참조하세요.

Kubernetes 전용 구성#

네트워크 구성#

Kubernetes 배포에서는 특정 연결 경로가 확보되어 있어야 합니다.

  1. 클라이언트에서 RTCD로의 연결: 포트 8443의 UDP 및 TCP 트래픽이 클라이언트에서 RTCD Pod로 올바르게 라우팅되어야 합니다(미디어용이며, TCP는 폴백 역할을 합니다).
  2. Mattermost에서 RTCD API로의 연결: API 포트(TCP 8045)에서 Mattermost와 RTCD 사이에 명확한 연결 경로가 있어야 합니다.
  3. 네트워크 정책: 네트워크 정책에서 Mattermost와 RTCD 서비스 간에 필요한 통신을 허용해야 합니다.

리소스 요구 사항#

RTCD Pod의 리소스 요구 사항은 예상 통화량, 참가자 수, 화면 공유 사용 여부에 크게 좌우됩니다.

일반적인 기본값에 의존하기보다 성능 기준선을 검토하여 배포 요구에 적합한 CPU, 메모리, 네트워크 요청 및 제한을 결정할 것을 강력히 권장합니다.

스케일링 고려 사항#

RTCD Pod의 수평 스케일링이 가능하지만 다음 사항에 유의하세요.

  1. 각 통화는 전적으로 하나의 RTCD Pod에서 호스팅됩니다.
  2. 서버가 RTCD 서버를 찾을 수 있도록 모든 RTCD Pod에 대해 DNS A 레코드를 설정해야 합니다.
  3. 정상 상태인 Pod만 DNS를 통해 보고되도록 상태 점검을 구성해야 합니다.
  4. 통화는 지속되는 동안 할당된 Pod에 계속 유지됩니다.

제한 사항#

WebRTC 서비스를 호스팅하는 데 내재된 복잡성 때문에 Kubernetes 환경에 Calls를 배포할 때는 몇 가지 제한 사항이 적용됩니다.

핵심 요구 사항 중 하나는 각 rtcd 프로세스가 전용 Kubernetes 노드에서 실행되어야 한다는 것입니다. 이는 수평 스케일링을 허용하면서 데이터를 올바르게 전달하기 위해 필요합니다. 데이터는 일반적으로 rtcd 프로세스를 실행하는 Pod로 직접 전달되어야 하며, 이 트래픽을 표준 인그레스를 통해 라우팅하는 것은 RTCD 배포에 권장되지 않습니다.

일반적인 권장 사항은 rtcd 인스턴스(Kubernetes 노드)마다 외부 IP 주소를 하나씩 노출하는 것입니다. 이렇게 하면 애플리케이션이 (STUN을 통해) 자체 외부 주소를 감지하고 이를 클라이언트에 알려 최소한의 구성으로 연결을 확보할 수 있으므로 스케일링이 더 간단해집니다.

모니터링 및 메트릭#

메트릭 수집과 모니터링에 대한 자세한 내용은 Calls 메트릭 및 모니터링 가이드를 참조하세요.

문제 해결#

Kubernetes 관련 문제 해결 방법은 다음과 같습니다.

  1. Pod 로그를 확인합니다: kubectl logs -f deployment/mattermost-rtcd
  2. 서비스 연결을 확인합니다: kubectl port-forward service/mattermost-rtcd 8045:8045
  3. UDP 및 TCP 트래픽이 로드 밸런서를 통해 올바르게 라우팅되는지 확인합니다.
  4. 네트워크 정책이 필요한 통신 경로를 허용하는지 확인합니다.

자세한 로깅 안내는 Calls 로깅 가이드를 참조하세요.

기타 Calls 문서#