add: под с 3X-UI .

kubernetes/k3s-3xui-pod.md

@@ -52,8 +52,8 @@ nano ~/k3s/vpn/x-ui/deployment.yaml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: x-ui
-  namespace: x-ui
+  name: x-ui        # имя развертывания (имя пода)
+  namespace: x-ui   # пространство имён, в котором будет создан под
 spec:
   replicas: 1
   selector:
@@ -64,26 +64,21 @@ spec:
       labels:
         app: x-ui
     spec:
-      hostNetwork: true
+      hostNetwork: true   # использовать сетевой стек хоста
       containers:
-      - name: x-ui
+      - name: x-ui        # имя контейнера
         image: ghcr.io/mhsanaei/3x-ui:latest
-        # image: enwaiax/x-ui:latest    # альтернативный облеченный: меньше способов шифрования и интерфейс на китайском
+        # image: enwaiax/x-ui:latest    # альтернативный облегчённый: меньше способов шифрования и китайский интерфейс
 ```
 В этом манифесте примечательно следующее:
 - `hostNetwork: true` — позволяет контейнеру использовать сетевой стек хоста и значит работать
   с сетевыми интерфейсами и портами хоста напрямую. Это полезно для приложений, которые требуют прямого доступа
   к сети, например, VPN-серверы.
-- `replicas: 1` — это количество реплик (экземпляров) пода, которые будут запущены. В данном случае мы запускаем
-  только одну реплику, но при необходимости можно увеличить это число для обеспечения отказоустойчивости и
-  масштабируемости.
-- `selector` — это селектор, который используется для выбора подов, которые будут управляться этим
+- `spec.replicas: 1` — количество реплик (экземпляров) пода, которые будут запущены. В данном случае -- оин под.
+- `spec.selector` —  селектор, который используется для выбора подов, которые будут управляться этим
   развертыванием. Он определяет, какие поды будут обновлены или удалены при изменении конфигурации развертывания.
-- `matchLabels` — это метки, которые должны совпадать с метками подов, чтобы они были выбраны селектором.
+- `matchLabels` —  метки, которые должны совпадать с метками подов, чтобы они были выбраны селектором.
   В данном случае мы используем метку `app: x-ui`, чтобы выбрать поды, которые относятся к приложению x-ui.
-- `emptyDir: {}` — это временное хранилище SQLite, которое создаётся при запуске пода и удаляется при его завершении.
-  Оно используется для хранения настроек, включая настройки VPN-серверов и клиентских соединений ( 3x-ui. Это удобно для тестирования и разработки, но не рекомендуется
-  для продакшн-среды, так как данные будут потеряны при перезапуске пода.
 
 
 Применим манифест:
@@ -104,7 +99,7 @@ x-ui-bb97f6894-h7zj8   1/1     Running   0          11s   10.42.1.50   opi5plus-
 Видим, что нода на которой запустился 3x-ui это `opi5plus-3`, а имя пода `x-ui-bb97f6894-h7zj8`. Проверим логи пода,
 используя его имя:
 ```bash
-sudo kubectl logs -n x-ui x-ui-886dbc87-hdw4h
+sudo kubectl logs -n x-ui x-ui-bb97f6894-h7zj8
 ```
 
 Увидим что-то вроде:
@@ -119,15 +114,105 @@ WARNING - XRAY: core: Xray 25.3.6 started
 ```
 
 Теперь мы знаем порт, на котором работает 3x-ui (`2053`), и значит можем получить доступ к веб-интерфейсу через браузер
-по адресу `http://opi5plus-3:2053` или `http://<IP_адрес_вашего_узла>:2053`. Можно настаивать VPN-подключения, создавать
-пользователей , менять логин и пароль на вход и т.д. Веб-интерфейс 3x-ui интуитивно понятен, так что разбираться
+по адресу `http://opi5plus-3:2053` или `http://<IP_адрес_вашего_узла>:2053`.
+
+![k3s--3x-ui-welcome.png](../images/k3s--3x-ui-welcome.png)
+
+После первого логирования (по умолчанию логин и пароль `admin`/`admin`) можно настаивать VPN-подключения, создавать
+пользователей, менять логин и пароль на вход и т.д. Веб-интерфейс 3x-ui интуитивно понятен, так что разбираться
 не составит труда.
 
-Но есть один минус. При рестарте пода, все настройки будут сброшены, т.к. они храняться во внутреннем хранилище пода.
+Есть, конечно, у 3x-ui под k3s минусы. В частности? внури пода не будет работать командный интерфейс
+3x-ui (`x-ui admin`). Поды k3s работают на **Alpine**, а там некоторые команды отличаются (например, нет `bash`,
+а только `ash`). Но web-панель работает, всё управление удобнее сделать через веб-интерфейс, и можно вообще не
+лезть в консоль.
+
+Но есть вот другой минус более критичен. При рестарте пода, все настройки будут сброшены, так как они хранятся
+во внутреннем хранилище пода. 
 
 Чтобы этого избежать, нужно использовать постоянное хранилище (Persistent Volume). Для его работы нужно установить
-`Longhorn` (или другой менеджер хранилищ). K3s на Orange Pi 5 поддерживает `Longhorn` из коробки, так как в операционной
-системе нет поддержки `iSCSI`, и включение его потребует перекомпиляции ядра (если вы этого еще не сделали, [смотрите
+`Longhorn` (или другой менеджер хранилищ). K3s поддерживает `Longhorn` из коробки, так как в операционной системе на
+Orange Pi 5 нет поддержки `iSCSI`, включение его потребует компиляции ядра (если вы этого еще не сделали, [смотрите
 инструкцию](../raspberry-and-orange-pi/opi5plus-rebuilding-linux-kernel-for-iscsi.md).
 
+Если `Longhorn` уже установлен, создадим не его базе постоянное хранилище для -- _PersistentVolumeClaim_ (**PVC**).
+Манифест PVC создадим в каталоге `~/k3s/vpn/x-ui/`, рядом с `deployment.yaml`:
+```bash
+nano ~/k3s/vpn/x-ui/pvc-db.yaml
+```
+
+Вставим в него следующий код:
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: x-ui-db-pvc
+  namespace: x-ui
+spec:
+  storageClassName: longhorn  # Указываем Longhorn как класс хранилища
+  accessModes:
+    - ReadWriteOnce           # Доступ для чтения и записи одним подом
+  resources:
+    requests:
+      storage: 512Mi         # Запрашиваемое хранилище, размер можно увеличить, если нужно
+```
+
+Обратите внимание:
+- `metadata.name` и `metadata.namespace` — имя хранилища (и это имя мы должны использовать в манифесте
+  развертывания пода, чтобы указать, какое хранилище использовать) и пространство имён, в котором оно будет создано.
+- `spec.storageClassName` — класс хранилища, который будет использоваться для создания постоянного хранилища.
+  В данном случае -- `longhorn`.
+- `spec.accessModes` — режим доступа к хранилищу. `ReadWriteOnce` означает, что хранилище может быть смонтировано
+  только одним подом для чтения и записи. У нас один под и база на SQLite, так что этого достаточно.
+- `spec.resources.requests.storage` —  запрашиваемый размер хранилища. Мы запрашиваем 1 ГБ и не означает, что 
+  хранилище будет занимать 1 ГБ на диске. Это предельный размер, который сможет занять хранилище.
+  
+Применим pvc-манифест:
+```bash
+sudo kubectl apply -f ~/k3s/vpn/x-ui/pvc-db.yaml
+```
+
+После этого Longhorn создаст том, который будет привязан к этому PVC.
+
+Теперь нам нужно изменить манифест развертывания пода, и подключить к нему созданный PVC. Теперь наш
+`~/k3s/vpn/x-ui/deployment.yaml` будет выглядеть так:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: x-ui
+  namespace: x-ui
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: x-ui
+  template:
+    metadata:
+      labels:
+        app: x-ui
+    spec:
+      hostNetwork: true
+      containers:
+      - name: x-ui
+        image: ghcr.io/mhsanaei/3x-ui:latest
+        # image: enwaiax/x-ui:latest    # альтернативный облегчённый: меньше способов шифрования и китайский интерфейс
+        volumeMounts:
+        - name: db-storage
+          mountPath: /etc/x-ui  # Путь к базе данных внутри контейнера
+      volumes:
+      - name: db-storage
+        persistentVolumeClaim:
+          claimName: x-ui-db-pvc  # Ссылка на созданный PVC
+```
+
+Применим обновлённый манифест:
+```bash
+sudo kubectl apply -f ~/k3s/vpn/x-ui/deployment.yaml
+```
+
+Под перезапустится, и теперь база данных будет храниться в постоянном хранилище Longhorn. При перезапуске пода или его
+"переезде" на другой узел, база данных останется доступной и не потеряется.
+
+