add: Перенос контейнера Docker в k3s.
This commit is contained in:
parent
b6b54e136c
commit
3bc414ca98
@ -14,6 +14,7 @@
|
||||
* [Под с Shadowsocks-клиент](kubernetes/k3s-shadowsocks-client.md) (k3s)
|
||||
* [Под с 3X-UI](kubernetes/k3s-3xui-pod.md) (k3s)
|
||||
* [Проксирование внешнего хоста через Traefik (Ingress-контроллер)](kubernetes/k3s-proxy.md)
|
||||
* [Перенос контейнера Docker в k3s](kubernetes/k3s-migrating-container-from-docker-to-kubernetes.md)
|
||||
|
||||
## Python
|
||||
* [Устранение проблем при установке Python-коннектора mysqlclient (MySQL/MariaDB)](python/python-mysql.md)
|
||||
|
||||
669
kubernetes/k3s-migrating-container-from-docker-to-kubernetes.md
Normal file
669
kubernetes/k3s-migrating-container-from-docker-to-kubernetes.md
Normal file
@ -0,0 +1,669 @@
|
||||
# Перенос контейнера из Docker в k3s (на примере Gitea)
|
||||
|
||||
Вот эта самая инструкция, котору вы сейчас читаете размещена на моем персональном сервере Gitea. Раньше она размещалась
|
||||
на домашнем хосте Orange Pi 5 в Docker-контейнере, и проксировалась через nginx c добавлением SSL-сертификата
|
||||
Let's Encrypt. Мне показалось, что зависимость от одного хоста -- опасненько. И я решил перенести Gitea в кластер,
|
||||
в котором у меня несколько узлов, и в случае падения одного из них, Gitea продолжит работать на другом узле. К тому
|
||||
же мне очень хотелось подключить старый Orange Pi 5 тоже к кластеру (ведь для этого нужно установить чистую систему и
|
||||
[перекомпилировать ядро](../raspberry-and-orange-pi/opi5plus-rebuilding-linux-kernel-for-iscsi.md)
|
||||
).
|
||||
|
||||
Я решил задокументировать процесс переноса контейнера из Docker в k3s, тем более Gitea был не единственный контейнер,
|
||||
который нужно было перенести. Возможно мой опыт вам тоже пригодится.
|
||||
|
||||
|
||||
## Перенос данных Docker-контейнера Gitea на узел k3s
|
||||
|
||||
Останавливаем докер
|
||||
|
||||
Архивируем данные gitea
|
||||
|
||||
Переносим данные на узел k3s (в моем случае это opi5plus-1) по SCP:
|
||||
|
||||
|
||||
## Подготовка узла k3s
|
||||
|
||||
Создадим пространство имен для gitea в k3s (чтобы все было аккуратно):
|
||||
```bash
|
||||
sudo kubectl create namespace gitea
|
||||
```
|
||||
|
||||
Создаем папку для хранения манифестов gitea:
|
||||
```bash
|
||||
mkdir -p ~/k3s/gitea
|
||||
```
|
||||
|
||||
## Перемещаем файлы и базу данных SQLite в блочное хранилище k3s
|
||||
|
||||
Теперь нам надо перенести данные gitea в k3s в PersistentVolumeClaim (Longhorn). Longhorn -- это блочное хранилище k3s,
|
||||
которое позволяет создавать и управлять блочными томами в кластере для обеспечения высокой доступности
|
||||
и отказоустойчивости. Если узел, на котором находится том, выходит из строя, Longhorn автоматически перемещает том
|
||||
на другой узел и контейнер продолжает работу с томом, как будто ничего не произошло.
|
||||
|
||||
Создадим манифест для PersistentVolumeClaim (PVC) и PersistentVolume (PV):
|
||||
```bash
|
||||
nano ~/k3s/gitea/longhorn-pvc.yaml
|
||||
```
|
||||
|
||||
Вставляем в него следующее содержимое:
|
||||
```yaml
|
||||
piVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: gitea-pvc # Имя PVC-хранилища
|
||||
namespace: gitea # Пространство имен gitea
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce # Режим доступа к PVC -- чтение и запись
|
||||
storageClassName: longhorn # Используем Longhorn как класс хранения
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi # Размер под данные Gitea 10 Гб (максимальный объем)
|
||||
```
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/longhorn-pvc.yaml
|
||||
```
|
||||
|
||||
Проверим, что PVC создан и доступен:
|
||||
```bash
|
||||
sudo kubectl get pvc -n gitea -o wide
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE VOLUMEMODE
|
||||
gitea-pvc Bound pvc-5a562c67-89b2-48e2-97a6-25035b90729a 10Gi RWO longhorn <unset> 20h Filesystem
|
||||
```
|
||||
|
||||
Создадим временный под `gitea-init-data` для переноса данных gitea с хост-узла в хранилище Longhorn:
|
||||
```bash
|
||||
nano ~/k3s/gitea/gitea-init-data.yaml
|
||||
```
|
||||
|
||||
Манифест временного пода:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: gitea-init-data
|
||||
namespace: gitea
|
||||
spec:
|
||||
nodeName: opi5plus-1 # Привязка к хосту opi5plus-1 (на этом узле у нас лежит архив с данными gitea из docker)
|
||||
containers:
|
||||
- name: init-data
|
||||
image: alpine:latest
|
||||
command: ["/bin/sh", "-c", "tar -xzf /mnt/gitea-data.tar.gz -C /data && chmod -R 777 /data && ls -la /data && sleep 3600"]
|
||||
volumeMounts:
|
||||
- name: gitea-data
|
||||
mountPath: /data
|
||||
- name: tmp-data
|
||||
mountPath: /mnt
|
||||
volumes:
|
||||
- name: gitea-data
|
||||
persistentVolumeClaim:
|
||||
claimName: gitea-pvc
|
||||
- name: tmp-data
|
||||
hostPath:
|
||||
path: /home/opi/tmp
|
||||
type: Directory # Указываем, что это папка
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
Что тут происходит:
|
||||
- `metadata` — задаёт имя пода `gitea-init-data` и привязывает его к пространству имен `gitea`.
|
||||
- `nodeName` — гарантирует запуск на нужной ноде (в данном случае `opi5plus-1`).
|
||||
- `containers` — задаёт контейнер с именем `init-data`, который использует образ `alpine:latest`.
|
||||
- `command` — выполняет команду в контейнере:
|
||||
- `tar -xzf /mnt/gitea-data.tar.gz -C /data` — распаковывает архив в `/data`.
|
||||
- `chmod -R 777 /data` — задаёт права на папку `/data`.
|
||||
- `ls -la /data` — выводит содержимое `/data` в логи.
|
||||
- `sleep 3600` — держит под живым 1 час, чтобы ты можно было зайти в sh и проверить, что всё распаковалось.
|
||||
- `volumeMounts` — монтирует два тома:
|
||||
- том и именем `gitea-data` монтируем PVC в `/data`.
|
||||
- том и именем `tmp-data` монтирует временную папку на хосте в `/mnt`.
|
||||
- `volumes` — определяет расположение томов:
|
||||
- том `gitea-data` — размещается в PersistentVolumeClaim (PVC) хранилища `gitea-pvc`, которое мы создали ранее.
|
||||
- том `tmp-data` — размещается в каталоге хоста `/home/opi/tmp` (как рам, у нас лежит архив с данными gitea
|
||||
из docker).
|
||||
- `restartPolicy: Never` — под не будет перезапускаться, если завершится.
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/gitea-init-data.yaml
|
||||
```
|
||||
|
||||
Проверим, что под создан и работает:
|
||||
```bash
|
||||
sudo kubectl get pod -n gitea -o wide
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
|
||||
gitea-init-data 1/1 Running 0 4m 10.42.2.64 opi5plus-1 <none> <none>
|
||||
```
|
||||
|
||||
Проверим логи пода:
|
||||
```bash
|
||||
sudo kubectl logs -n gitea gitea-init-data
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
total 36
|
||||
drwxrwxrwx 6 1000 1000 4096 Apr 16 15:09 .
|
||||
drwxr-xr-x 1 root root 4096 Apr 17 13:01 ..
|
||||
drwxrwxrwx 5 root root 4096 Apr 16 15:09 git
|
||||
drwxrwxrwx 18 root root 4096 Apr 17 13:02 gitea
|
||||
drwxrwxrwx 2 root root 16384 Apr 16 15:27 lost+found
|
||||
drwxrwxrwx 2 root root 4096 Apr 17 13:01 ssh
|
||||
```
|
||||
|
||||
Как видим, данные благополучно распаковались в `/data` внутри пода, и это Longhorn PVC `gitea-pvc`. Можно также "зайти"
|
||||
в под и посмотреть, что там внутри:
|
||||
```bash
|
||||
sudo kubectl exec -it -n gitea gitea-init-data -- /bin/sh
|
||||
```
|
||||
|
||||
Внутри пода дать команду, например:
|
||||
```bash
|
||||
ls -l /data/gitea/gitea.db
|
||||
```
|
||||
|
||||
И убедиться, что данные gitea распакованы. Увидим что-то вроде:
|
||||
```text
|
||||
-rwxrwxrwx 1 root root 2555904 Apr 16 15:09 /data/gitea/gitea.db
|
||||
```
|
||||
|
||||
База SQLite gitea.db на месте. Выходим из пода:
|
||||
```bash
|
||||
exit
|
||||
```
|
||||
|
||||
## Создание пода gitea и подключение к нему хранилища
|
||||
|
||||
Теперь нужно создать под с Gitea, подключить к нему PVC `gitea-pvc` и проверить, что данные подцепились.
|
||||
|
||||
### Настройка Аффинити -- предпочтительные узлы
|
||||
|
||||
В моем кластере k3s на OrangePi 5 Plus несколько узлов работают на nVME SSD, а некоторые на eMMC. Накопители
|
||||
SSD быстрее (если интересно, то вот [заметка о тестировании производительности дискового накопителя](../raspberry-and-orange-pi/measuring-performance-storage-devices.md))
|
||||
и потому если контейнер с Gitea будет работать на SSD, то он будет работать быстрее. Как настроить предпочтение узлов
|
||||
описано в [заметке о аффинити](k3s-affinate.md), поэтому кратко: присваиваем узлам метки, например `disk=ssd`:
|
||||
```bash
|
||||
sudo kubectl label nodes opi5plus-1 disk=ssd
|
||||
sudo kubectl label nodes opi5plus-3 disk=ssd
|
||||
```
|
||||
|
||||
Проверяем, что метки добавлены:
|
||||
```bash
|
||||
sudo kubectl get nodes --show-labels | grep "disk=ssd"
|
||||
```
|
||||
|
||||
Будут показаны только узлы с меткой `disk=ssd`. У каждого узда очень много меток.
|
||||
|
||||
### Создание манифеста для развертывания Gitea
|
||||
|
||||
Создадим манифест для развертывания Gitea (deployment):
|
||||
```bash
|
||||
nano ~/k3s/gitea/gitea-deployment.yaml
|
||||
```
|
||||
|
||||
Вставляем в него следующее содержимое:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment # определяем тип ресурса -- Deployment (развертывание)
|
||||
metadata: # определяем метаданные развертывания
|
||||
name: gitea # имя развертывания `gitea`
|
||||
namespace: gitea # в пространстве имен `gitea`
|
||||
labels:
|
||||
app: gitea
|
||||
spec:
|
||||
replicas: 1 # количество реплик (подов) в кластере -- 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: gitea
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: gitea
|
||||
spec:
|
||||
affinity: # определяем аффинити (предпочтения) для узлов
|
||||
nodeAffinity: # аффинити для узлов
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 100 # вес предпочтения -- 100
|
||||
preference: # предпочтение
|
||||
matchExpressions: # выражения для соответствия
|
||||
- key: disk # метка узла `disk`...
|
||||
operator: In # ...оператор `In` (входит в множество)...
|
||||
values: # ...значений...
|
||||
- ssd # ...значение `ssd` (т.е. узлы с SSD)
|
||||
containers: # определяем контейнеры, которые будут запущены в поде
|
||||
- name: gitea # имя контейнера `gitea`
|
||||
image: gitea/gitea:latest # образ
|
||||
env: # переменные окружения
|
||||
- name: USER_UID # идентификатор пользователя
|
||||
value: "1000"
|
||||
- name: USER_GID # идентификатор группы
|
||||
value: "1000"
|
||||
ports: # определяем порты, которые будут открыты в контейнере
|
||||
- containerPort: 3000 # порт 3000
|
||||
name: http # будет именоваться 'http' (используется в Gitea для веб-интерфейса)
|
||||
- containerPort: 22 # порт 22
|
||||
name: ssh # будет именоваться 'ssh' (используется в Gitea для SSH-доступа)
|
||||
volumeMounts: # монтируем тома в контейнер
|
||||
- name: gitea-data # том с именем 'gitea-data'...
|
||||
mountPath: /data # в каталог '/data' внутри контейнера
|
||||
- name: timezone # том 'timezone'...
|
||||
mountPath: /etc/timezone # в каталог '/etc/timezone' внутри контейнера
|
||||
readOnly: true # только для чтения
|
||||
- name: localtime # том 'localtime'...
|
||||
mountPath: /etc/localtime # в каталог '/etc/localtime' внутри контейнера
|
||||
readOnly: true # только для чтения
|
||||
volumes: # определяем тома, которые будут использоваться в поде
|
||||
- name: gitea-data # том с именем 'gitea-data'...
|
||||
persistentVolumeClaim: # используем PersistentVolumeClaim (PVC Longhorn)
|
||||
claimName: gitea-pvc # имя PVC 'gitea-pvc'
|
||||
- name: timezone # том 'timezone'...
|
||||
hostPath: # использует каталог (или файл) на хосте узла
|
||||
path: /etc/timezone # путь к файлу '/etc/timezone' на хосте
|
||||
- name: localtime # том 'localtime'...
|
||||
hostPath: # использует каталог (или файл) на хосте узла
|
||||
path: /etc/localtime # путь к файлу '/etc/localtime' на хосте
|
||||
```
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/gitea-deployment.yaml
|
||||
```
|
||||
|
||||
Проверим, что под создан и работает:
|
||||
```bash
|
||||
sudo kubectl get pod -n gitea -o wide
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
|
||||
gitea-55dfcf4dd9-d99nw 1/1 Running 0 74s 10.42.1.94 opi5plus-3 <none> <none>
|
||||
gitea-init-data 0/1 Completed 0 2h 10.42.2.64 opi5plus-1 <none> <none>
|
||||
```
|
||||
|
||||
Как видим:
|
||||
* под `gitea` работает и запущен на узде `opi5plus-3` (там где у нас SSD). В принципе, аффинити не гарантирует запуск
|
||||
пода на узле с SSD, это только предпочтение. Но в данном случае предпочтение сработало.
|
||||
* под `gitea-init-data` завершился. Это нормально, так как он был создан только для переноса данных gitea в Longhorn
|
||||
PVC `gitea-pvc`, и должен быть "жив" только 1 час (времени, которое мы указали в `sleep 3600` в манифесте пода).
|
||||
|
||||
Проверим логи пода `gitea`:
|
||||
```bash
|
||||
sudo kubectl logs -n gitea deployment/gitea
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
Server listening on :: port 22.
|
||||
Server listening on 0.0.0.0 port 22.
|
||||
2025/04/18 17:42:33 cmd/web.go:253:runWeb() [I] Starting Gitea on PID: 17
|
||||
2025/04/18 17:42:33 cmd/web.go:112:showWebStartupMessage() [I] Gitea version: 1.23.7 built with GNU Make 4.4.1, go1.23.8 : bindata, timetzdata, sqlite, sqlite_unlock_notify
|
||||
2025/04/18 17:42:33 cmd/web.go:113:showWebStartupMessage() [I] * RunMode: prod
|
||||
2025/04/18 17:42:33 cmd/web.go:114:showWebStartupMessage() [I] * AppPath: /usr/local/bin/gitea
|
||||
2025/04/18 17:42:33 cmd/web.go:115:showWebStartupMessage() [I] * WorkPath: /data/gitea
|
||||
2025/04/18 17:42:33 cmd/web.go:116:showWebStartupMessage() [I] * CustomPath: /data/gitea
|
||||
2025/04/18 17:42:33 cmd/web.go:117:showWebStartupMessage() [I] * ConfigFile: /data/gitea/conf/app.ini
|
||||
...
|
||||
...
|
||||
...
|
||||
2025/04/18 17:42:34 cmd/web.go:205:serveInstalled() [I] PING DATABASE sqlite3
|
||||
...
|
||||
...
|
||||
...
|
||||
2025/04/18 17:42:39 cmd/web.go:315:listen() [I] Listen: http://0.0.0.0:3000
|
||||
2025/04/18 17:42:39 cmd/web.go:319:listen() [I] AppURL(ROOT_URL): https://git.cube2.ru/
|
||||
2025/04/18 17:42:39 cmd/web.go:322:listen() [I] LFS server enabled
|
||||
2025/04/18 17:42:39 ...s/graceful/server.go:50:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 17
|
||||
```
|
||||
|
||||
Как видим, Gitea запустилась, порт 3000 (HTTP) и 22 (SSH) открыты, тома подключены, база данных SQLite на месте, права
|
||||
на папку `/data` установлены. Всё работает.
|
||||
|
||||
Можно устроить более глубокую проверку, зайдя внутр пода и посмотреть как там всё устроено:
|
||||
```bash
|
||||
sudo kubectl exec -n gitea -it deployment/gitea -- /bin/bash
|
||||
```
|
||||
|
||||
Внутри пода проверим, что PVC `gitea-pvc` подключен и данные gitea и база на месте:
|
||||
```bash
|
||||
ls -la /data
|
||||
ls -l /data/gitea/gitea.db
|
||||
```
|
||||
|
||||
Проверим открытые порты в поде:
|
||||
```bash
|
||||
netstat -tuln
|
||||
```
|
||||
|
||||
Увидим что порты слушаются:
|
||||
```text
|
||||
Active Internet connections (only servers)
|
||||
Proto Recv-Q Send-Q Local Address Foreign Address State
|
||||
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
|
||||
tcp 0 0 :::3000 :::* LISTEN
|
||||
tcp 0 0 :::22 :::* LISTEN
|
||||
```
|
||||
|
||||
Проверим, что web-интерфейс Gitea доступен:
|
||||
```bash
|
||||
curl -v http://localhost:3000
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
Host localhost:3000 was resolved.
|
||||
* IPv6: ::1
|
||||
* IPv4: 127.0.0.1
|
||||
* Trying [::1]:3000...
|
||||
* Connected to localhost (::1) port 3000
|
||||
* using HTTP/1.x
|
||||
> GET / HTTP/1.1
|
||||
> Host: localhost:3000
|
||||
> User-Agent: curl/8.12.1
|
||||
> Accept: */*
|
||||
>
|
||||
* Request completely sent off
|
||||
< HTTP/1.1 303 See Other
|
||||
< Cache-Control: max-age=0, private, must-revalidate, no-transform
|
||||
< Content-Type: text/html; charset=utf-8
|
||||
...
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
Как видим, web-интерфейс Gitea доступен внутри пода по http на порту 3000. Все работает. Можно выходить из пода:
|
||||
```bash
|
||||
exit
|
||||
```
|
||||
|
||||
## Создание сервиса и IngressRoute для доступа к Gitea снаружи
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
nano ~/k3s/gitea/gitea-service.yaml
|
||||
```
|
||||
|
||||
Вставляем в него следующее содержимое:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: gitea
|
||||
namespace: gitea
|
||||
spec:
|
||||
selector:
|
||||
app: gitea
|
||||
ports:
|
||||
- name: http
|
||||
port: 80
|
||||
targetPort: 3000
|
||||
#- name: ssh
|
||||
# port: 22
|
||||
# targetPort: 222
|
||||
```
|
||||
Объяснение:
|
||||
|
||||
selector: app: gitea — находит поды из Deployment gitea.
|
||||
port: 80 — внешний порт сервиса (Traefik будет слать трафик сюда).
|
||||
targetPort: 3000 — порт контейнера Gitea.
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/gitea-service.yaml
|
||||
```
|
||||
|
||||
sudo kubectl get svc -n gitea -o wide
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
|
||||
gitea ClusterIP 10.43.211.8 <none> 80/TCP 115s app=gitea
|
||||
|
||||
nano ~/k3s/gitea/https-redirect-middleware.yaml
|
||||
|
||||
```yaml
|
||||
apiVersion: traefik.containo.us/v1alpha1
|
||||
kind: Middleware
|
||||
metadata:
|
||||
name: https-redirect
|
||||
namespace: gitea
|
||||
spec:
|
||||
redirectScheme:
|
||||
scheme: https
|
||||
permanent: true
|
||||
```
|
||||
|
||||
Объяснение:
|
||||
|
||||
redirectScheme: scheme: https — перенаправляет запросы на HTTPS.
|
||||
permanent: true — возвращает 301 (постоянный редирект) для SEO и кэширования.
|
||||
Размещаем в gitea, чтобы не затрагивать другие сервисы.
|
||||
|
||||
Применить:
|
||||
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/https-redirect-middleware.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
У нас уже настроена выдача сертификатов Let’s Encrypt в подах cert-managerб cert-manager-cainjector и
|
||||
cert-manager-webhook, в пронстве имен cert-manager. Это нестандартный способ (см. [заметку о cert-manager](k3s-cert-manager.md)).
|
||||
|
||||
Проверим, что cert-manager работает:
|
||||
```bash
|
||||
sudo kubectl get pods -n cert-manager
|
||||
```
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
|
||||
cert-manager-64478b89d5-p4msl 1/1 Running 2 (5d13h ago) 19d 10.42.1.55 opi5plus-3 <none> <none>
|
||||
cert-manager-cainjector-65559df4ff-t7rj4 1/1 Running 5 (5d13h ago) 19d 10.42.1.54 opi5plus-3 <none> <none>
|
||||
cert-manager-webhook-544c988c49-zxdxc 1/1 Running 0 19d 10.42.1.56 opi5plus-3 <none> <none>
|
||||
```
|
||||
|
||||
Поды `cert-manager`, `cainjector`, `webhook` должны быть **Running**.
|
||||
|
||||
Проверим наличие ClusterIssuer:
|
||||
```bash
|
||||
sudo kubectl get clusterissuer -A -o wide
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME READY STATUS AGE
|
||||
letsencrypt-prod True The ACME account was registered with the ACME server 19d
|
||||
```
|
||||
|
||||
Проверим, что работает и Let's Encrypt знает о нас:
|
||||
```bash
|
||||
sudo kubectl describe clusterissuer letsencrypt-prod
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
Name: letsencrypt-prod
|
||||
Namespace:
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
API Version: cert-manager.io/v1
|
||||
Kind: ClusterIssuer
|
||||
...
|
||||
...
|
||||
...
|
||||
Status:
|
||||
Acme:
|
||||
Last Private Key Hash: тут-будет-хэш-вашего-ключа=
|
||||
Last Registered Email: тут-будет-ваш-email
|
||||
Uri: https://acme-v02.api.letsencrypt.org/acme/acct/тут-будет-id-вашего-аккаунта
|
||||
Conditions:
|
||||
...
|
||||
...
|
||||
Status: True
|
||||
Type: Ready
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
Важно чтобы `Status: Conditions: Ready:` был `True`.
|
||||
|
||||
|
||||
|
||||
Создадим манифест для получения сертификата Let's Encrypt:
|
||||
```bash
|
||||
nano ~/k3s/gitea/gitea-certificate.yaml
|
||||
```
|
||||
|
||||
и вставим в него следующее содержимое:
|
||||
```yaml
|
||||
apiVersion: cert-manager.io/v1
|
||||
kind: Certificate
|
||||
metadata:
|
||||
name: gitea-tls
|
||||
namespace: gitea
|
||||
spec:
|
||||
secretName: gitea-tls
|
||||
dnsNames:
|
||||
- git.cube2.ru
|
||||
issuerRef:
|
||||
name: letsencrypt-prod
|
||||
kind: ClusterIssuer
|
||||
```
|
||||
|
||||
secretName: gitea-tls: Сертификат сохраняется в Secret gitea-tls в gitea.
|
||||
dnsNames: Домен git.cube2.ru.
|
||||
issuerRef: Ссылается на ClusterIssuer letsencrypt-prod.
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/gitea-certificate.yaml
|
||||
```
|
||||
|
||||
Проверим, что секрет создан:
|
||||
```bash
|
||||
sudo kubectl get secret -n gitea gitea-tls -o wide
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
NAME TYPE DATA AGE
|
||||
gitea-tls kubernetes.io/tls 2 46s
|
||||
```
|
||||
|
||||
Проверим, что сертификат выдан:
|
||||
```bash
|
||||
sudo kubectl describe certificate -n gitea gitea-tls
|
||||
```
|
||||
|
||||
Увидим что-то вроде:
|
||||
```text
|
||||
Name: gitea-tls
|
||||
Namespace: gitea
|
||||
...
|
||||
...
|
||||
...
|
||||
Spec:
|
||||
Dns Names:
|
||||
тут-будет-ваш-домен
|
||||
...
|
||||
...
|
||||
Status:
|
||||
Conditions:
|
||||
Last Transition Time: тут-будет-дата-время-выдачи-сертификата
|
||||
Message: Certificate is up to date and has not expired
|
||||
Observed Generation: 1
|
||||
Reason: Ready
|
||||
Status: True
|
||||
Type: Ready
|
||||
Not After: тут-будет-дата-время-окончания-действия-сертификата
|
||||
Not Before: тут-будет-дата-время-начала-действия-сертификата
|
||||
Renewal Time: тут-будет-дата-время-ближайшего-обновления-сертификата
|
||||
Revision: 1
|
||||
Events:
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
Ожидается `Status: True` в `Conditions`, свежие даты в `Not After` и `Not Before` и сообщение `Certificate is
|
||||
up to date and has not expired` в `Message`.
|
||||
|
||||
|
||||
|
||||
|
||||
Создать IngressRoute для HTTPS
|
||||
Настроим IngressRoute для маршрутизации git.cube2.ru через HTTPS с Let’s Encrypt и редиректом HTTP.
|
||||
```bash
|
||||
nano ~/k3s/gitea/gitea-ingressroute.yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: traefik.containo.us/v1alpha1
|
||||
kind: IngressRoute
|
||||
metadata:
|
||||
name: gitea-http
|
||||
namespace: gitea
|
||||
spec:
|
||||
entryPoints:
|
||||
- web
|
||||
routes:
|
||||
- match: Host(`git.cube2.ru`)
|
||||
kind: Rule
|
||||
services:
|
||||
- name: gitea
|
||||
port: 80
|
||||
middlewares:
|
||||
- name: https-redirect
|
||||
---
|
||||
apiVersion: traefik.containo.us/v1alpha1
|
||||
kind: IngressRoute
|
||||
metadata:
|
||||
name: gitea-https
|
||||
namespace: gitea
|
||||
spec:
|
||||
entryPoints:
|
||||
- websecure
|
||||
routes:
|
||||
- match: Host(`git.cube2.ru`)
|
||||
kind: Rule
|
||||
services:
|
||||
- name: gitea
|
||||
port: 80
|
||||
tls:
|
||||
secretName: gitea-tls
|
||||
# Если у вас стандартная настройка Traefik, то раскомментируйте следующую строку (а строку выше закомментируйте)
|
||||
# certResolver: letsencrypt
|
||||
```
|
||||
Объяснение:
|
||||
|
||||
Первая IngressRoute (gitea-http):
|
||||
entryPoints: web — слушает порт 80 (HTTP).
|
||||
match: Host(git.cube2.ru) — обрабатывает запросы к git.cube2.ru.
|
||||
services: gitea — направляет трафик в Service gitea (порт 80 → 3000).
|
||||
middlewares: https-redirect — редирект на HTTPS.
|
||||
Вторая IngressRoute (gitea-https):
|
||||
entryPoints: websecure — слушает порт 443 (HTTPS).
|
||||
tls: certResolver: letsencrypt — включает Let’s Encrypt для автоматического получения сертификата.
|
||||
Трафик идёт в тот же Service gitea.
|
||||
|
||||
Применим манифест:
|
||||
```bash
|
||||
sudo kubectl apply -f ~/k3s/gitea/gitea-ingressroute.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Можно удалить временный под:
|
||||
```bash
|
||||
sudo kubectl delete pod gitea-init-data -n gitea
|
||||
```
|
||||
Loading…
x
Reference in New Issue
Block a user