1. Вступ
Запуск додатків WebRTC у Kubernetes стає все більш популярним, оскільки розробники та інженери прагнуть до впровадження хмарних рішень для комунікації в реальному часі. Однак розгортання цих додатків у AWS Elastic Kubernetes Service (EKS) має свої унікальні виклики порівняно з іншими хмарними провайдерами. Ця стаття допоможе хмарним інженерам та розробникам WebRTC налаштувати повністю функціональну архітектуру в EKS, використовуючи STUNner для безшовного проходження NAT WebRTC.
AWS залишається найпопулярнішим хмарним провайдером, але налаштування Kubernetes у AWS, зокрема в EKS, часто є більш складним, ніж в Azure або Google Cloud. Наприклад, налаштування STUNner в EKS вимагає додаткових кроків через специфіку мережевого управління та балансування навантаження в AWS. Ці конфігурації, хоча і здійсненні, можуть бути складними для новачків. Цей посібник допоможе зрозуміти процес і надасть чіткий шлях до розгортання STUNner в EKS.
Щоб зробити демонстрацію практичною, ми розгорнемо популярний відкритий сервер WebRTC LiveKit, а також приклад додатку LiveKit Meet. Це налаштування підкреслить переваги використання STUNner як TURN-сервера перед LiveKit, з акцентом на специфічні кроки для AWS, необхідні для його роботи. Архітектура, яку ми створимо, зображена на малюнку нижче.
Архітектура запуску LiveKit за STUNner в AWS EKS
Наприкінці цієї статті ви не тільки отримаєте робочий приклад LiveKit, що працює за STUNner в EKS, але й краще зрозумієте, чому конфігурації STUNner відрізняються в AWS і як вирішувати ці проблеми. Як тільки ви правильно налаштуєте STUNner в EKS, ви зможете так само легко розгорнути будь-який інший сервер медіа WebRTC (наприклад, Mediasoup, Jitsi, Janus, або Elixir WebRTC) за допомогою документації STUNner — LiveKit є лише одним з прикладів. Якщо ви новачок у WebRTC в Kubernetes або хочете оптимізувати свої розгортання в AWS EKS, цей посібник допоможе вам зробити правильний крок.
2. Передумови
Перед тим, як перейти до розгортання додатків WebRTC в AWS EKS, давайте переконаємось, що у нас є всі необхідні інструменти, сервіси та доступи. Ось що вам знадобиться:
Необхідні інструменти
- AWS CLI: Для взаємодії з AWS-сервісами через командний рядок.
- eksctl: CLI-інструмент, спеціально призначений для створення та управління кластерами EKS.
- kubectl: CLI для Kubernetes для взаємодії з вашим кластером.
- Helm: Менеджер пакетів для Kubernetes, що використовується для встановлення та управління додатками.
Налаштування акаунту AWS та API-ключа
Щоб слідувати цьому посібнику, вам потрібен AWS акаунт. Якщо у вас його ще немає, ви можете зареєструватися на aws.amazon.com.
Після того, як у вас буде акаунт:
- Увійдіть в AWS Management Console.
- Перейдіть до IAM (Identity and Access Management).
- Створіть нового користувача IAM з програмним доступом.
- Надійдіть користувачеві необхідні права (для цього посібника достатньо AdministratorAccess, хоча для продуктивного середовища слід застосовувати більш обмежені права).
5.
Завантажте ключ доступу та секретний ключ для цього користувача.
Маючи API-ключ, встановіть та налаштуйте AWS CLI:
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws configure
Вам буде запропоновано ввести:
- Access Key ID
- Secret Access Key
- Default Region (наприклад, us-west-2)
- Output Format (за замовчуванням json)
Ви можете виконати наступну команду, щоб перевірити, чи авторизовано AWS CLI і чи працює він:
aws sts get-caller-identity
Встановлення eksctl, kubectl та Helm
Оскільки eksctl, kubectl та helm є окремими Go-бінарниками, їх встановлення є досить простим. Виконайте наступні кроки для кожного інструмента:
Встановлення eksctl:
curl -L "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" -o eksctl.tar.gz
tar -xzf eksctl.tar.gz -C /usr/local/bin
rm eksctl.tar.gz
eksctl version
Встановлення kubectl:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/$(uname -s | tr '[:upper:]' '[:lower:]')/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/
kubectl version --client
Встановлення helm:
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm version
Після того як ви встановите ці інструменти та налаштуєте свій AWS акаунт, ви будете готові до створення EKS кластера та розгортання додатків WebRTC.
3. Налаштування EKS кластера
Для розгортання додатків WebRTC в AWS EKS першим кроком є створення кластера Elastic Kubernetes Service (EKS). У цьому розділі ми пройдемо через процес за допомогою eksctl, CLI-інструмента, спеціально створеного для спрощення управління кластерами EKS.
Вступ до EKS та eksctl
Amazon Elastic Kubernetes Service (EKS) — це повністю керований Kubernetes сервіс, який полегшує запуск додатків Kubernetes у хмарі AWS. Хоча EKS бере на себе більшу частину складності, налаштування кластера все ще може зайняти час без правильних інструментів.
Саме тут і вступає eksctl. Це утиліта командного рядка, розроблена спочатку компанією Weaveworks (тепер повністю керована AWS), яка значно спрощує створення та управління кластерами EKS. За допомогою eksctl ви можете визначити ваш кластер у YAML конфігураційному файлі та створити його всього за один командний рядок.
Створення кластера
Для створення EKS кластера за допомогою eksctl виконайте наступні кроки:
- Створіть YAML конфігураційний файл, наприклад cluster-config.yaml, з таким вмістом:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: stunner-livekit
region: eu-central-1
iam:
withOIDC: true
nodeGroups:
- name: ng-1
instanceType: t3.medium
desiredCapacity: 3
volumeSize: 100
ssh:
publicKeyPath: ~/.ssh/id_rsa.pub
- Назва кластера: Кластер називається stunner-livekit.
- Регіон: Кластер розгортається в регіоні eu-central-1.
- IAM з OIDC: Увімкнення ролей IAM для облікових записів сервісів, що буде необхідно пізніше.
- Група вузлів: Конфігурує групу вузлів з:
— типом екземпляра t3.medium.
— 3 бажаними вузлами.
— 100 ГБ дискового простору на кожен вузол.
— SSH ключ для безпечного доступу до вузлів.
Створіть кластер за допомогою eksctl:
eksctl create cluster -f cluster-config.yaml
Ця команда:
- Створить необхідну інфраструктуру (наприклад, VPC, підмережі, групи безпеки).
- Створить контрольний план Kubernetes і робочі вузли.
- Налаштує ролі та дозволи IAM.
Перевірка налаштувань
Після створення кластера перевірте, чи працює він, і чи правильно налаштовано kubectl для взаємодії з ним:
Перевірте статус кластера:
eksctl create cluster -f cluster-config.yaml
Тестування підключення kubectl: Переконайтесь, що kubectl налаштовано для використання нового кластера, перевіривши вузли:
kubectl get nodes
Ви повинні побачити виведення з переліком вузлів вашого кластера, схоже на:
NAME STATUS ROLES AGE VERSION
ip-192–168–29–7.eu-central-1.compute.internal Ready 3h15m v1.30.7-eks-59bf375
ip-192–168–63–16.eu-central-1.compute.internal Ready 3h21m v1.30.7-eks-59bf375
ip-192–168–67–17.eu-central-1.compute.internal Ready 3h21m v1.30.7-eks-59bf375
4. Встановлення AWS Load Balancer Controller
Один з найважливіших кроків у налаштуванні вашого EKS кластера для будь-яких публічно доступних додатків — це встановлення AWS Load Balancer Controller. Цей компонент необхідний для керування вхідним трафіком з Інтернету в ваш кластер, а також для автоматичного налаштування та управління AWS Application Load Balancers (ALBs) і Network Load Balancers (NLBs) для сервісів Kubernetes.
Однак цей крок може бути доволі складним через інтеграцію між ролями AWS IAM і обліковими записами сервісів Kubernetes. Без правильного розуміння обох аспектів, процес встановлення може бути схильний до помилок. Цей посібник проведе вас крок за кроком, щоб переконатися, що все налаштовано правильно.
Призначення AWS Load Balancer Controller
AWS Load Balancer Controller дозволяє Kubernetes керувати AWS-специфічними ресурсами балансування навантаження для ваших додатків. Зокрема, він:
- Створює та налаштовує ALB або NLB у відповідь на ресурси Kubernetes ingress і service.
- Забезпечує зовнішній доступ до ваших додатків у масштабованому та ефективному вигляді.
- Надає необхідну підтримку вашій архітектурі EKS, керуючи маршрутизацією трафіку до ваших Kubernetes робочих навантажень.
Кроки встановлення
Дотримуйтесь цих кроків для налаштування AWS Load Balancer Controller:
1. Створення ролі IAM для контролера
Контролер потребує ролі IAM з правами для керування ресурсами AWS. Ось як це налаштувати:
Завантажте необхідну політику IAM: створіть документ політики (iam-policy.json) з правами, необхідними для контролера:
curl -o iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json
Застосуйте політику в AWS:
aws iam create-policy \
- policy-name AWSLoadBalancerControllerIAMPolicy \
- policy-document file://iam-policy.json
Створіть роль IAM для контролера та зв’яжіть її з політикою:
POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==`AWSLoadBalancerControllerIAMPolicy`].Arn' --output text)
eksctl create iamserviceaccount \
--cluster=stunner-livekit \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--attach-policy-arn="$POLICY_ARN" \
--approve
Цей крок створює обліковий запис сервісу в просторі імен kube-system і зв’язує його з роллю IAM. Ви можете перевірити, чи правильно створено обліковий запис сервісу в Kubernetes кластері:
$ kubectl get serviceaccounts -n kube-system aws-load-balancer-controller
NAME SECRETS AGE
aws-load-balancer-controller 0 30s
2.
**Встановлення AWS Load Balancer Controller за допомогою Helm
Після того, як роль IAM буде пов'язана з обліковим записом сервісу, можна приступати до встановлення контролера за допомогою Helm.
Додайте репозиторій Helm:
helm repo add eks https://aws.github.io/eks-charts
helm repo update
Встановіть контролер: Замість __ і __ вставте ім’я вашого кластера (stunner-livekit) та регіон (eu-central-1):
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
--set clusterName=stunner-livekit \
--set serviceAccount.create=false \
--set service
--set region=eu-central-1
3. Перевірка встановлення
Перевірте статус пода контролера: Ви повинні побачити под з ім'ям aws-load-balancer-controller, який працює.
kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller
Перевірте, чи працює контролер: Перевірте логи пода контролера, щоб переконатися, що він успішно запустився:
kubectl logs -n kube-system deployment/aws-load-balancer-controller
На цьому етапі AWS Load Balancer Controller встановлено та готовий до керування трафіком вашого кластера. Цей крок є критичним для забезпечення функціональності STUNner в AWS EKS, оскільки він потребує Load Balancer Controller для маршрутизації трафіку до своїх компонентів.
4. Встановлення Nginx Ingress та Cert-Manager для HTTP(S) трафіку та управління TLS сертифікатами
Хоча Nginx Ingress та Cert-Manager не є специфічними для AWS або EKS, це стандартні інструменти для керування ресурсами ingress та TLS сертифікатами в Kubernetes кластерах, які нам знадобляться для LiveKit. WebRTC потребує безпечного контексту (тобто HTTPS) для роботи API getUserMedia в браузерах, що робить необхідним захист підключення клієнт-сервер для сигналізації.
Примітка: якщо ви знайомі з AWS і EKS, можна замінити цей крок, використовуючи AWS Application Load Balancer замість Nginx і налаштувати Cert-Manager для використання специфічних для AWS сертифікатів CAs для генерації TLS сертифікатів для ваших ресурсів ingress. Однак, налаштування цього буде значно складніше, ніж просто використання Nginx та Cert-Manager, і це повністю відволіче від основної мети цього блогу.
Щоб встановити Nginx та Cert-Manager, просто виконайте наступне:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0/deploy/static/provider/aws/deploy.yaml
kubectl annotate service -n ingress-nginx ingress-nginx-controller service.beta.kubernetes.io/aws-load-balancer-scheme=internet-facing
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.2/cert-manager.yaml
kubectl wait --for=condition=Ready -n cert-manager pod -l app.kubernetes.io/component=webhook --timeout=90s
kubectl get services -n ingress-nginx
Після перевірки сервісів в просторі імен ingress-nginx ви повинні побачити публічну IP-адресу (або ім'я хосту), яке AWS Load Balancer Controller створив для вас. Ви повинні зареєструвати це у вашого постачальника DNS, оскільки це буде маршрутизувати HTTP трафік до вашого кластера (AWS LoadBalancer зазвичай надає ім'я хосту, тому вам слід визначити запис типу CNAME для вашого домену).
Також нам потрібно створити ClusterIssuer для Cert-Manager, який використовуватиме Let’s Encrypt для генерації дійсного TLS сертифікату для ваших ingress хостнеймів.
Застосуйте наступний yaml за допомогою kubectl:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
email: [email protected] # використовуйте ваш власний домен
privateKeySecretRef:
name: letsencrypt-prod
server: https://acme-v02.api.letsencrypt.org/directory
solvers:
- http01:
ingress:
class: nginx
У наступному розділі ми зосередимось на розгортанні STUNner і налаштуванні його для NAT проходження в EKS.
5. Встановлення STUNner
З AWS Load Balancer Controller та Cert-Manager в наявності, ми можемо зосередитись на розгортанні STUNner, важливого компонента для забезпечення безперебійної роботи WebRTC додатків у Kubernetes. У цьому розділі ми познайомимо вас із STUNner, опишемо його роль у WebRTC та проведемо вас через процес його розгортання в вашому EKS кластері.
Вступ до STUNner
STUNner — це медіа-шлюз на базі Kubernetes, який спрощує розгортання WebRTC додатків у хмарних середовищах. Він діє як сервер STUN і TURN, дозволяючи клієнтам WebRTC встановлювати peer-to-peer з'єднання, навіть коли вони знаходяться за NAT або фаєрволами.
У цьому розгортанні STUNner виступає як шлюз між зовнішніми WebRTC клієнтами та медіа-серверами, що працюють у Kubernetes. Використовуючи STUNner, ви можете:
- Вивести ваші медіа-сервери WebRTC через лише один порт (TURN), замість тисяч, що значно зменшує поверхню атаки на безпеку.
- Уникнути ручної конфігурації NAT і управління фаєрволами.
- Досягти безперешкодного NAT проходження для WebRTC трафіку.
- Спростити масштабування та операційне управління WebRTC додатками в Kubernetes.
STUNner ідеально підходить для EKS, і інтегруючи його з AWS Load Balancer Controller, ми відкриємо STUNner для обробки трафіку від зовнішніх WebRTC клієнтів.
Встановлення STUNner
Щоб встановити STUNner в вашому EKS кластері, ви можете використовувати або Helm, або Kubernetes маніфести. В цьому посібнику ми використаємо Helm для простоти.
Додайте репозиторій STUNner в Helm:
helm repo add stunner https://l7mp.io/stunner
helm repo update
Встановіть STUNner: Замість вставте ім’я простору імен, куди ви хочете встановити STUNner (наприклад, stunner):
helm install stunner stunner/stunner-gateway-operator \
--namespace stunner \
--create-namespace
Ця команда розгортає STUNner Gateway Operator, включаючи стандартний dataplane. Helm chart дозволяє легко налаштовувати конфігурації, більше інформації можна знайти тут.
Конфігурація
Наступний крок у розгортанні STUNner — це його налаштування для функціонування як TURN сервер і шлюз для WebRTC трафіку. Це досягається за допомогою GatewayConfig, який визначає метод автентифікації, а також інші налаштування, такі як анотації для балансування навантаження, адаптовані до специфікацій хмарного провайдера — в даному випадку AWS.
У цьому прикладі ми використовуємо базову комбінацію ім’я користувача/пароль для автентифікації TURN. Однак STUNner підтримує більш просунуті методи автентифікації, такі як довгострокові облікові дані або сторонні автентифікаційні бекенди, які можна інтегрувати відповідно до ваших вимог.
Додатково, GatewayConfig є місцем, де можна включити специфічні налаштування для хмарного провайдера для балансувальника навантаження, використовуючи анотації сервісів Kubernetes. Ці анотації передаються в AWS Load Balancer Controller, що забезпечує правильну конфігурацію сервісу для STUNner з урахуванням специфікацій AWS.
Ось приклад конфігурації для AWS EKS:
apiVersion: stunner.l7mp.io/v1
kind: GatewayConfig
metadata:
name: stunner-gatewayconfig
namespace: stunner
spec:
realm: stunner.l7mp.io
authType: plaintext
userName: "stunneruser"
password: "stunnerpassword"
loadBalancerServiceAnnotations:
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
service.beta.kubernetes.io/aws-load-balancer-type: external
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: stickiness.enabled=true,stickiness.type=source_ip
service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /live
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8086"
service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: HTTP
Пояснення анотацій для балансувальника навантаження
Ось розбір анотацій, що використовуються в конфігурації, та їх конкретні ролі:
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
Ця анотація визначає схему балансувальника навантаження.
- internet-facing: Робить балансувальник доступним через публічний інтернет.
- Альтернативно, можна використовувати internal для приватного доступу.
service.beta.kubernetes.io/aws-load-balancer-type: external
Це визначає тип балансувальника навантаження.
- external: Створює AWS Network Load Balancer (NLB) для зовнішнього трафіку.
- AWS також підтримує інші типи, такі як Application Load Balancers (ALB), але STUNner вимагає NLB для обробки L4 TURN трафіку.
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
Налаштовує NLB на орієнтацію на pod-адреси безпосередньо, а не на порт вузла.
- Це важливо для безпосереднього виведення pod-ів STUNner для зовнішніх клієнтів.
- Використання типу цільового IP покращує масштабованість і уникає зайвих стрибків через Kubernetes вузли.
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: “true”
Вмикає балансування навантаження через зони доступності, що рівномірно розподіляє трафік між усіма зонами в регіоні.
- Це забезпечує стабільну продуктивність, навіть коли трафік різко зростає в окремих зонах.
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: stickiness.enabled=true,stickiness.type=source_ip
Вказує на sticky маршрутизацію за IP-адресою джерела.
- Оскільки UDP — це безстанова протокол, за замовчуванням NLB випадково направлятиме клієнтський трафік до різних точок STUNner. Якщо ця точка змінюється під час сеансу, з'єднання TURN обривається, тому ми повинні забезпечити, щоб трафік одного клієнта завжди надходив до одного й того ж pod STUNner.
service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /live
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: “8086”
service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: HTTP
Визначає перевірку здоров'я для STUNner.
- STUNner за замовчуванням налаштований для відкриття цього кінцевого ендпоінту перевірки здоров'я.
- UDP слухачі NLB потребують цієї конфігурації, щоб перевірити, чи є ендпоінти STUNner живими, інакше вони не будуть перенаправляти UDP трафік до STUNner.
Налаштовуючи ці анотації, ви забезпечуєте, щоб балансувальник навантаження, створений для STUNner, був оптимізований для WebRTC трафіку в AWS EKS. Анотації керують важливими аспектами, такими як sticky маршрутизація, перевірки здоров'я та балансування через зони доступності, що робить розгортання більш надійним і ефективним.
Після застосування цієї конфігурації STUNner автоматично успадкує ці анотації, коли AWS Load Balancer Controller створюватиме балансувальник навантаження для цього сервісу. Цей крок є критично важливим для забезпечення надійного підключення зовнішніх WebRTC клієнтів до шлюзу STUNner.
Далі, нам потрібно створити GatewayClass, в якому ми посилаємось на попередню конфігурацію.
Застосуйте наступну yaml конфігурацію.
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: stunner-gatewayclass
spec:
controllerName: "stunner.l7mp.io/gateway-operator"
parametersRef:
group: "stunner.l7mp.io"
kind: GatewayConfig
name: stunner-gatewayconfig
namespace: stunner
description: "STUNner — це шлюз для WebRTC трафіку в Kubernetes"
Останнім кроком є створення Gateway, який вказує STUNner, на яких портах він має слухати TURN трафік. В цьому прикладі ми створюємо слухачів для UDP та TCP. Зверніть увагу, що вони налаштовані на різні номери портів. Це пов'язано з поточним обмеженням AWS Load Balancer Controller, який може створювати комбіновані сервіси лише для різних портів TCP і UDP.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
stunner.l7mp.io/enable-mixed-protocol-lb: "true"
name: stunner-gateway
namespace: stunner
spec:
gatewayClassName: stunner-gatewayclass
listeners:
- name: udp-listener
port: 3478
protocol: TURN-UDP
- name: tcp-listener
port: 3480
protocol: TURN-TCP
На цьому етапі ви успішно встановили STUNner у вашому EKS кластері. Після налаштування STUNner буде працювати як шлюз для WebRTC трафіку, безперешкодно з'єднуючи зовнішніх клієнтів з внутрішніми медіа серверами. У наступному розділі ми розгорнемо LiveKit та з'єднаємо його з STUNner для завершення налаштування.
6. Розгортання LiveKit
З STUNner, налаштованим і працюючим у вашому AWS EKS кластері, ми готові до розгортання LiveKit, потужної платформи з відкритим кодом для реального відео- та аудіозв'язку. LiveKit надає базові елементи для WebRTC додатків, дозволяючи реалізовувати такі функції, як відеоконференції, прямі трансляції та інтерактивну співпрацю.
Вступ до LiveKit
LiveKit спрощує процес створення масштабованих систем реального часу для комунікацій. Він виступає як медіа сервер, що обробляє сигналізацію, WebRTC транспорт та маршрутизацію медіа, дозволяючи розробникам зосередитися на своїх додатках, а не на складнощах інфраструктури WebRTC.
Хоча офіційна документація LiveKit надає Helm chart для розгортання LiveKit у Kubernetes, вона використовує host networking для транспорту медіа. Host networking дозволяє pod-ам ділити мережевий інтерфейс Kubernetes вузла, що часто вважається антипатерном Kubernetes. Використання host networking може призвести до таких проблем, як:
- Зниження ізоляції мережі.
- Конфлікти портів, особливо під час оновлень або з іншими робочими навантаженнями на вузлі.
- Обмежена масштабованість в хмарних середовищах.
Замість використання host networking ми використаємо STUNner, щоб обробляти TURN трафік і безпечно та ефективно вивести LiveKit. Така архітектура краще відповідає кращим практикам Kubernetes і надає переваги, такі як масштабованість, модульність та правильну ізоляцію мережі.
Компоненти для розгортання
Для запуску LiveKit ми розгорнемо кілька взаємопов'язаних компонентів, кожен з яких має своє власне налаштування Deployment, Service та Ingress. До цих компонентів належать:
-
Redis
Redis служить бекендом для LiveKit, керуючи зберіганням сесій та станом. Це легка, in-memory база даних, оптимізована для операцій з низькою затримкою, що робить її ідеальним вибором для платформ реального часу. -
LiveKit Server
Сервер LiveKit обробляє сигналізацію, сесії WebRTC і маршрутизацію медіа. Це основа архітектури LiveKit, яка взаємодіє з STUNner для управління медіа транспорту для клієнтів. -
Demo Token Server
Аутентифікація в LiveKit вимагає генерування JWT токенів, які визначають дозволи користувачів та можливості для сесії.
Demo токен сервер — це простий сервіс, який генерує ці токени на основі заздалегідь визначених секретів. Це корисний інструмент для тестування та демонстраційних цілей. -
LiveKit Meet Demo додаток
Щоб продемонструвати можливості LiveKit, ми розгорнемо LiveKit Meet, демонстраційний додаток, який надає повноцінний інтерфейс для відеоконференцій. Цей додаток є чудовою відправною точкою для вивчення можливостей LiveKit або створення власного WebRTC додатка.
Процес розгортання
Усі файли розгортання (маніфести для Deployment, Service та Ingress) для вищезгаданих компонентів вже підготовлені та розміщені в одному YAML файлі на GitHub. Ви можете розгорнути всі компоненти одним кроком, застосувавши цей файл до вашого кластера.
Щоб розгорнути LiveKit та його компоненти, виконайте наступну команду:
kubectl create namespace livekit
kubectl apply -f https://raw.githubusercontent.com/megzo/aws-eks-stunner-livekit/refs/heads/main/manifests/livekit.yaml -n livekit
Будь ласка, перевірте цей маніфест файл і змініть його відповідно до вашого випадку. Зокрема, є два основні моменти, які ви повинні змінити:
- Перевірте хости в ресурсах Ingress і використовуйте ваші власні домени. Переконайтеся, що ці домени вказують на хостнейм вашого Nginx ingress load balancer в вашому DNS провайдері.
- Перевірте ConfigMap для LiveKit і змініть хости TURN сервера на публічну IP адресу або хостнейм, який сервіс stunner-gateway отримав від AWS Load Balancer Controller. ConfigMap має виглядати ось так:
apiVersion: v1
kind: ConfigMap
metadata:
name: livekit-server
data:
config.yaml: |
keys:
access_token: secret
log_level: debug
port: 7880
redis:
address: redis:6379
rtc:
port_range_start: 50000
port_range_end: 60000
tcp_port: 7801
stun_servers: []
turn_servers:
- credential: stunnerpassword
# використовуйте ваш хостнейм load balancer
host: k8s-stunner-stunnerg-68f0a27aae-d7d3aa5970ce2e68.elb.eu-central-1.amazonaws.com
port: 3478
protocol: udp
username: stunneruser
- credential: stunnerpassword
# використовуйте ваш хостнейм load balancer
host: k8s-stunner-stunnerg-68f0a27aae-d7d3aa5970ce2e68.elb.eu-central-1.amazonaws.com
port: 3480
protocol: tcp
username: stunneruser
use_external_ip: false
turn:
enabled: false
Нарешті, нам потрібно визначити UDPRoute для STUNner, щоб дозволити TURN клієнтам підключатися до LiveKit. Це функція безпеки STUNner, яка дозволяє підключення лише до тих кінцевих точок, для яких визначено UDPRoute, інакше, маючи правильні TURN креденціали, ви могли б просто підключитися до будь-якого pod-а на будь-якому порту в Kubernetes внутрішній мережі. Також не хвилюйтеся, що сервіс LiveKit вказує на HTTP (websocket) порт, а WebRTC підключення використовує UDP/RTP, STUNner насправді не звертає уваги на тип протоколу та номери портів, він просто виявить Endpoints за сервісом. Отже, застосуйте наступну yaml конфігурацію:
apiVersion: stunner.l7mp.io/v1
kind: UDPRoute
metadata:
name: livekit
namespace: stunner
spec:
parentRefs:
- name: stunner-gateway
rules:
- backendRefs:
- name: livekit-server
namespace: livekit
На цьому етапі, розгорнувши LiveKit разом з Redis, токен сервером та додатком LiveKit Meet, ви отримаєте повноцінну платформу WebRTC, що працює в Kubernetes, за допомогою STUNner для ефективного та масштабованого транспорту медіа. Така архітектура не тільки уникатиме недоліків host networking, але й відповідає кращим практикам Kubernetes, забезпечуючи модульність, безпеку та масштабованість у хмарі.
7. Перевірка повного налаштування
Тепер, коли ми розгорнули всі компоненти, настав час перевірити, чи все працює правильно і доступно.
Цей розділ проведе вас через процес тестування налаштувань, щоб переконатися, що система готова до реального часу комунікації.
Доступ до LiveKit Meet
Щоб отримати доступ до демонстраційного додатку LiveKit Meet, відкрийте наступне посилання у вашому браузері: https://meet.aws.stunner.cc (замініть на ваш власний ingress домен).
Ви повинні побачити інтерфейс LiveKit Meet, де можна приєднатися до кімнати або створити нову та почати тестування реального відео- та аудіо-спілкування.
Інтерфейс LiveKit Meet
Використання тесту підключення LiveKit
LiveKit надає сайт для тестування підключення, який допомагає переконатися, що ваша інсталяція правильно налаштована для WebRTC підключень. Слідуйте цим крокам, щоб використовувати тест підключення:
- Відкрийте сайт тестування підключення: https://livekit.io/connection-test
- Введіть наступні дані:
- LiveKit URL: wss://ms.aws.stunner.cc/
(Замініть ms.aws.stunner.cc на ваш власний домен.) - Room (JWT) Token: Згенеруйте токен, використовуючи розгорнутий токен сервер, перейшовши за наступним посиланням: https://ms.aws.stunner.cc/api/token?identity=YourName&roomName=test-room
(Замініть YourName і test-room на бажане ім’я та назву кімнати.)
Тепер запустіть тест і перевірте, чи підключення було встановлено успішно.
Якщо все налаштовано правильно, ви побачите повідомлення про успіх, що підтверджує, що ваша інсталяція LiveKit працює як очікується.
Успішний тест підключення на сайті LiveKit
Завершивши ці тести, ви можете бути впевнені, що ваша інсталяція LiveKit в AWS EKS працює і готова підтримувати реальну комунікацію. Тепер можна починати будувати та масштабувати свої WebRTC додатки на основі цієї надійної основи!
8. Висновок
У цьому блозі ми пройшли повний процес розгортання WebRTC додатка в AWS EKS, що працює на базі LiveKit та STUNner. Починаючи з налаштування EKS кластеру та конфігурації AWS Load Balancer Controller, до розгортання STUNner і LiveKit, ми побудували повноцінну та масштабовану платформу реального часу комунікацій в Kubernetes. Я також створив GitHub репозиторій, щоб зібрати всі кроки та Kubernetes маніфести в одному місці.
Однак цей посібник став досить довгим через додаткову складність розгортання Kubernetes в AWS. На відміну від інших хмарних провайдерів, де STUNner часто «просто працює» з коробки, налаштування EKS з STUNner вимагає вирішення специфічних для AWS проблем, таких як налаштування IAM ролей, анотацій для балансувальника навантаження та інтеграції з зовнішніми сервісами.
Тим не менш, те, що ми побудували тут, є основою для подальшого розвитку. Повноцінне виробниче розгортання передбачає багато додаткових кроків, зокрема:
- Розгортання кількох кластерів для резервування та географічного розподілу.
- Реалізація авто-скейлінгу для STUNner, LiveKit і самого кластера для обробки змінних навантажень.
- Підвищення безпеки за допомогою просунутих механізмів автентифікації та суворіших політик.
- Налаштування стійких бекенд-систем для Redis для забезпечення довговічності даних.
Якщо ви хочете підняти свої WebRTC додатки на новий рівень або шукаєте рекомендації щодо побудови масштабованих, безпечних та хмарних WebRTC сервісів в Kubernetes, не вагайтеся звертатися до нас. Ми допоможемо вам спростити процес і досягти ваших цілей швидше. Зв'яжіться з нами — ми завжди готові допомогти!
Перекладено з: Deploying WebRTC Applications in AWS EKS: A Step-by-Step Guide with LiveKit and STUNner