Fedora Server можно использовать в качестве домашнего или рабочего сервера для многих приложений. Одно из приложений, которое можно запустить на нем, – сетевой видеорегистратор (NVR) для организации системы видеонаблюдения с помощью IP-камер. Viseron – это приложение для сетевого видеорегистратора, которое просто настроить и практически не имеет зависимостей (например, базы данных или специфического хранилища). Оно обладает широкими возможностями настройки и предлагает на выбор множество компонентов. Кроме того, для обработки видео можно использовать такие аппаратные средства, как Intel VAAPI и Google Coral Edge TPU. Некоторые функции, которые делают его идеальным для CCTV, – это обнаружение движения, объектов, номерных знаков и лиц. В этом посте я покажу, как настроить Viseron на Fedora Server, используя Kubernetes.
Подготовка платформы для размещения нашего приложения NVR
В этой статье предполагается, что вы начинаете со свежей установки Fedora Server, имя хоста сервера – server, и есть пользователь user с привилегиями sudo.
Настройка одного узла Kubernetes
Сначала настройте брандмауэр для установок Kubernetes и Viseron:
firewall-cmd --permanent --add-port=6443/tcp #apiserver firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 #pods firewall-cmd --permanent --zone=trusted --add-source=10.43.0.0/16 #services firewall-cmd --permanent --add-port=30888/tcp #node port we will use for viseron firewall-cmd --reload
Начиная со свежей установки Fedora Linux, установите K3s, который представляет собой облегченный сертифицированный Kubernetes, идеально подходящий для одиночных узлов. Выполните следующую команду на своем сервере, чтобы установить последнюю стабильную версию K3s.
curl -sfL https://get.k3s.io | sh -
Чтобы убедиться в успешной установке, выполните следующую команду:
sudo k3s kubectl get node NAME STATUS ROLES AGE VERSION server Ready control-plane,master 2m v1.29.6+k3s2
Мы хотим получить доступ к нашим узлам Kubernetes с нашей собственной машины. Для этого мы скопируем файл /etc/rancher/k3s/k3s.yaml, находящийся на сервере, на нашу локальную машину. Файл k3s.yaml не доступен для чтения на сервере по соображениям безопасности. Чтобы скопировать его, нам нужно sudo скопировать его сначала в домашнюю директорию пользователя на сервере, а затем использовать scp для передачи его на локальную машину. Вы также можете использовать следующий фрагмент команды с нашей локальной машины, чтобы сделать это за один раз:
ssh -q user@server "sudo --stdin cat /etc/rancher/k3s/k3s.yaml" <<(read -s && echo $REPLY) > k3s.yaml
Команда выполняет следующие действия:
- запускает
sudoдляcatфайла k3s.yaml - перенаправляет вывод в локальный файл k3s.yaml
- указывает
sudoотображать запрос пароля на stderr, чтобы перенаправление stdout исключало его - говорит
sshработать в тихом режиме, чтобы ничего не добавлять в перенаправление stdout - использует
read -sдля чтения пароляsudoбез вывода его на консоль - перенаправляет пароль
sudoв stdin командыssh.
Чтобы использовать файл k3s.yaml для доступа к кластеру, вам потребуется сделать еще несколько вещей. При установке K3s был сгенерирован TLS-сертификат для нескольких локальных имен хостов, включая имя нашего узла: server . Файл k3s.yaml содержит конечную точку Kubernetes как https://127.0.0.1:6443 . Поэтому давайте изменим его на https://server:6443, чтобы мы могли получить доступ к нему с локальной машины. Мы можем сделать это с помощью нашего любимого редактора или просто sed.
sed -i.bak 's/127.0.0.1/server/g' k3s.yaml
Наконец, поместим наш файл в каталог ~/.kube и изменим его права доступа:
mkdir ~/.kube mv k3s.yaml ~/.kube/k3s.yaml chmod 0600 ~/.kube/k3s.yaml
В качестве последнего шага для доступа к кластеру нам нужно установить kubectl на нашу локальную машину:
sudo dnf install kubernetes-clientТеперь мы должны быть в состоянии перечислить наш серверный узел с помощью следующих команд:
export KUBECONFIG=$HOME/.kube/k3s.yaml kubectl get nodes NAME STATUS ROLES AGE VERSION server Ready control-plane,master 10m v1.29.6+k3s2
Настройка провайдера хранилища LVM
Нам нужно настроить тома для нашего приложения NVR, чтобы хранить видео и конфигурации. K3s поставляется с local-path в качестве провайдера хранения по умолчанию:
kubectl get storageclass NAME PROVISIONER (cut for brevity) local-path (default) rancher.io/local-path
Это означает, что определенный нами том будет смонтирован на существующую файловую систему внутри /var. Проблема такого подхода заключается в том, что local-path не устанавливает никаких ограничений, поэтому, когда вы определяете том размером 10 Гб, это ограничение фактически игнорируется, и использование диска может просто расти и использовать все доступное на нем пространство, что может привести к краху всей системы. Менее чем идеальный вариант.
При установке Fedora Server создается группа томов LVM под названием fedora с логическим томом root в ней. Например, если бы в нашей системе был диск объемом 1 Тбайт, это выглядело бы следующим образом:
vgs VG #PV #LV #SN Attr VSize VFree fedora 1 7 0 wz--n- 952g 937g
lvs LV VG Attr LSize (cut for brevity) root fedora -wi-ao---- 15.00g
Обратите внимание, что логический том root не использует все доступное пространство. Мы будем использовать дополнительное пространство для размещения томов Kubernetes.
Итак, мы можем создавать логические тома с определенными ограничениями, монтировать их в локальную файловую систему и монтировать их в контейнеры Kubernetes с помощью провайдера хранения local-path! Но разве не было бы здорово, если бы Kubernetes сама создавала и управляла этими логическими томами за нас? Именно здесь на помощь приходит проект OpenEBS LocalPV-LVM. LocalPV-LVM – это провайдер хранения для LVM на локальных узлах.
Чтобы настроить провайдера хранения, мы применим следующий манифест Kubernetes к нашему кластеру Kubernetes:
kubectl apply -f https://openebs.github.io/charts/lvm-operator.yaml
Этот манифест установит в нашем кластере все необходимые артефакты для реализации провайдера хранения LVM.
Выполнив вышеуказанную команду и немного подождав, мы можем убедиться, что все работает, как и ожидалось:
kubectl -n kube-system get pod | grep openebs openebs-lvm-controller-0 5/5 Running 0 1m openebs-lvm-node-8mxj5 2/2 Running 0 1m kubectl get crd | grep openebs lvmnodes.local.openebs.io 2024-07-30T04:00:00Z lvmsnapshots.local.openebs.io 2024-07-30T04:00:00Z lvmvolumes.local.openebs.io 2024-07-30T04:00:00Z
В качестве последнего шага мы настроим наш собственный класс хранения Kubernetes с нашим новым провайдером хранения OpenEBS.
Создадим файл fedora-vg-openebs-sc.yaml, содержащий следующее:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-lvmpv #arbitrary storage class name allowVolumeExpansion: true #allows for volume expansion parameters: storage: "lvm" volgroup: "fedora" #name of the volume group in the server provisioner: local.csi.openebs.io
Затем развернем его:
kubectl apply -f fedora-vg-openebs-sc.yaml
Мы можем убедиться, что он установлен, выполнив следующую команду:
kubectl get storageclass NAME PROVISIONER (cut for brevity) local-path (default) rancher.io/local-path openebs-lvmpv local.csi.openebs.io
Установка приложения Viseron NVR
Мы с сопровождающим Viseron создали диаграмму Helm, чтобы облегчить установку и управление Viseron в Kubernetes. Helm – это как менеджер пакетов для Kubernetes.
Для следующих шагов нам нужно установить Helm, следуя официальной документации или с помощью dnf install helm.
Предположим, что наше серверное оборудование – это Intel с VAAPI. Сначала мы установим репозиторий Viseron Helm, а затем установим приложение в нашем кластере с определенными конфигурациями.
helm repo add viseron https://roflcoopter.github.io/viseron-helm-chart helm repo update
Теперь создадим следующий файл viseron-values.yaml:
securityContext:
privileged: true # Privileges to use the /dev/dri device
service:
type: NodePort
nodePort: 30888 # The port where the app will be available in our server, opened with firewall-cmd in steps above
storage:
config:
className: "openebs-lvmpv" # Our storageclass
size: 50Mi # Not a lot of space needed to store configs
data:
className: "openebs-lvmpv" # Our storageclass
size: 200Gi # Here we set plenty of space for videos storage. See the official viseron documentation to change the retention periods default of 7 days.
volumes:
- name: dev-dri
hostPath:
path: /dev/dri # To make this device available as a volume to the app container
volumeMounts:
- name: dev-dri
mountPath: /dev/dri # To mount the dev-dri volume on the same /dev/dri path.
Затем установим диаграмму:
helm -n nvr upgrade --create-namespace --install --values viseron-values.yaml viseron viseron/viseron
Ниже приведено объяснение аргументов, используемых в команде helm:
-n nvr: указывает пространство имен Kubernetes, которое будет использоваться для нашего приложенияupgrade: указывает, что мы хотим обновить наш релиз («релиз» – это терминология Helm для установленных приложений)-create-namespace: создает пространство имен nvr, если оно не существует.-install: устанавливает (вместо обновления) релиз, если он не существует.-values viseron-values.yaml: указывает файл значений для использования (наши специфические конфигурации)viseron: название релизаviseron/viseron: используемая нами таблица Helm
Если мы захотим обновить наше приложение позже, мы сначала обновим репозиторий Helm (helm repo update), а затем снова выполним команду выше.
Если все прошло успешно, наша установка должна выглядеть следующим образом:
helm -n nvr history viseron REVISION UPDATED STATUS CHART APP VERSION 1 Tue Jul... deployed viseron-0.1.2 2.3.1 kubectl -n nvr get pod NAME READY STATUS RESTARTS AGE viseron-5745654d57-9kcbz 1/1 Running 0 2m kubectl -n nvr get pvc NAME STATUS VOLUME (cut for brevity) viseron-config Bound pvc-0492f99d-1b35-42e5-9725-af9c50fd0d63 viseron-data Bound pvc-4230c3fe-ae9d-471c-b0a7-0c0645e1449b
Журналы Viseron также сообщат нам, были ли обнаружены платформы аппаратного ускорения. В нашем случае Viseron обнаружил, что VAAPI и OpenCL доступны для использования:
kubectl -n nvr logs viseron-5745654d57-9kcbz (cut for brevity) ************** Setting EdgeTPU permissions *************** Coral Vendor IDs: "1a6e" "18d1" No EdgeTPU USB device was found No EdgeTPU PCI device was found ************************** Done ************************** ****** Checking for hardware acceleration platforms ****** OpenCL is available! VA-API is available! CUDA cannot be used (cut for brevity)
Если бы мы не подключили /dev/dri к контейнеру, в журналах было бы написано VA-API не может быть использован .
Если мы зайдем на наш сервер, мы должны увидеть эти тома Kubernetes как логические тома:
lvs LV VG Attr LSize (cut for brevity) pvc-0492f99d-1b35-42e5-9725-af9c50fd0d63 fedora -wi-ao---- 52.00m pvc-4230c3fe-ae9d-471c-b0a7-0c0645e1449b fedora -wi-ao---- 200.00g root fedora -wi-ao---- 15.00g
Приложение Viseron будет доступно по адресу http://server:30888/ . При первом посещении оно сообщит, что ожидает камеры. Это связано с тем, что система поставляется с конфигурацией по умолчанию, которая является лишь примером, указывающим на несуществующие камеры. Конфигурацию можно изменить, перейдя в Меню > Администрирование > Конфигурация.
Заключение
В этом посте мы выполнили шаги по настройке приложения Viseron NVR на сервере Fedora с Kubernetes. Были использованы следующие компоненты:
Комментарии (0)