doc_memo/raspberry-and-orange-pi/k3s.md
2025-02-22 11:47:34 +03:00

76 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Развертывание k3s на Orange Pi
K3s — это облегчённая версия Kubernetes, созданная для слабых или малых серверов (Raspberry Pi, Orange Pi,
IoT-устройства, edge-серверы и т.п.). Для кластера из нескольких Orange Pi он предпочтительнее, так как:
* K3S менее требователен к ресурсам (Полный k8s на ARM может сожрать 1-2 ГБ только на управление кластером,
а k3s занимает ~500 МБ.
* K3s проще устанавливать и обновлять. Shell-скрипт с [https://get.k3s.io](get.k3s.io) все сделает сам, и не нужно
погружаться сложные настройки kubeadm. Обычный Kubernetes состоит из множества компонентов: kube-apiserver,
kube-controller-manager, kube-scheduler, kubelet на каждой ноде, kube-proxy, etcd и т.д. В K3s всё это
упаковано в один бинарник.
* Всё работает "из коробки" благодаря встроенному Flannel (CNI) и не надо вручную настраивать Calico, Weave, Cilium.
Но, для конкретно моего случая у k3s есть один минус -- распределенная база **etcd**, в которой хранится состояния
кластера, нод и подов, в нем заменена SQLite . Это круто для маленьких компьютеров, экономно по памяти и ресурсам, и никак
не сказывается на производительности (пока узлов меньше 80-100), но означает, что в кластере k3s
может быть только одна мастер-нода. Если мастер-нода упадет, ее некому будет заменить и весь кластер умрет.
Я же хочу, чтобы все ноды были мастерами (с возможностью работать
с воркерами) и буду делать k3s-кластер с использованием etcd. Причем etcd будет внутри нод (!).
## Установка k3s на первом узле
На первой ноде запускаем. Пока без кластерного etcd (ока хранение идёт в SQLite) и без Traefik (Traefik -- это
ingress-контроллера в k3s, и в Kubernetes в целом, — это компонент, который управляет входящим сетевым трафиком
кластера и позволяет маршрутизировать HTTP/HTTPS-запросы к соответствующим подам, с динамической конфигурацией
и интеграцией с Let's Encrypt... но пока он нам не нужен). И так:
```bash
curl -sfL https://get.k3s.io | sh -s - --disable traefik
```
У нас один узел, состояние k3s хранится в SQLite.
Проверим, что все k3s запущен:
```bash
sudo service k3s status
```
Увидим что-то типа:
```text
● k3s.service - Lightweight Kubernetes
Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
Active: active (running) since ...
...
...
```
Посмотрим сколько нод в кластере:
```bash
sudo kubectl get nodes
```
И, та-да! Увидим одну ноду:
```text
NAME STATUS ROLES AGE VERSION
opi5plus-2 Ready control-plane,master 47m v1.31.5+k3s1
```
А что там внутри? Посмотрим на поды:
```bash
sudo kubectl get pods -A
```
Целых три пода:
```text
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-ccb96694c-xnvwl 1/1 Running 0 47m
kube-system local-path-provisioner-5cf85fd84d-vpb5p 1/1 Running 0 47m
kube-system metrics-server-5985cbc9d7-ghmkh 1/1 Running 0 47m
```
* **coredns** -- DNS-сервер кластера, используется для разрешения имен сервисов и подов внутри k3s (и k8s тоже).
* **local-path-provisioner** -- организатор хранилища на дисках узлов, он автоматически создает Persistent Volumes (PV)
для хранения данных (например, базы).
* **metrics-server** -- агрегатор метрик, который собирает данные о нагрузке (CPU, память и все такое) на поды и узлы,
которые можно использовать для автоскейлинга (например, увеличивать количество подов при нагрузках).