LINUX.ORG.RU

Сообщения vbr

 

Фреймворк на основе архитектуры кубернетеса для любых приложений

Я изучаю кубернетес и меня восхищает его архитектура. Адски расширяемая и универальная.

Если очень вкратце - есть понятие ресурса, у него есть желаемое состояние с набором полей и реальное состояние. У него есть набор label-ов, мета-данных. Есть отношения между ресурсами. И всё это определено на полностью абстрактном уровне. В применении к кубернетесу это означает, что я создаю деплоймент с желаемым состоянием (декларативно) и контролеры кубернетеса работают над тем, чтобы привести реальное состояние к желаемому.

Но суть в том, что это всё прям идеально ложится на архитектуру REST - есть GET, PUT, PATCH и тд. Что позволяет делать, например, инструмент kubectl работающим универсально со всеми видами ресурсов, причём и с теми, которые добавляют другие разработчики плагинами, для этого код kubectl менять не надо.

В общем ладно, не буду петь дифирамбы кубернетесу, хотя чем больше я его изучаю, тем больше восхищаюсь его архитектурой, я вроде себя дураком не считаю, но те, кто его проектировал, прям на другом уровне мыслят, я так не могу.

Суть в том, что всё это настолько универсально, что из этого можно сделать универсальный фреймворк-бэкэнд. Из этих концепций. Причём если сохранить eventual consistency модель, то он будет бесконечно масштабироваться. От разработчика при использовании такого фреймворка будет нужно лишь добавить свои виды ресурсов и написать свои контролеры, которые будут обрабатывать эти ресурсы. На халяву получаем шикарный REST-API, инструменты вроде kubectl, универсально работающие с любыми ресурсами, универсальную и адаптируемую безопасность и, что самое главное, масштабируемость.

И мне интересно - кто-то уже таким занялся? Есть ли такое фреймворки?

 

vbr
()

Загрузка OpenBSD через ipxe и http

У меня есть VPS, на котором нет поддержки custom iso. Хочу попробовать установить OpenBSD. Установил убунту, установил grub-ipxe, загрузил ipxe, настроил сеть.

Сразу скажу, что у меня получилось загрузить OpenBSD двумя способами:

  1. Через команду chain https://boot.netboot.xyz/

Далее по менюшкам и тд.

  1. Проанализировав скрипты этого сайта я смог частично без него это сделать:
IPXE> initrd https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/cd71.iso
IPXE> chain https://boot.netboot.xyz/memdisk iso raw

Но, как видно, всё равно грузится memdisk с этого сайта который, как я понимаю, дальше каким-то образом передаёт управление на iso.

Хочется попробовать загрузить OpenBSD без этого сайта. Но пока не получилось. Пытался грузить через chain https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/bsd.rd, пытался сделать

imgfetch https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/bsd.rd
chain https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/pxeboot

но чего в меню pxeboot ввести, чтобы дальше загрузить загруженный в initrd bsd.rd, я не понял. Почему-то маны по этой теме очень куцые. В моём понимании команда imgfetch скачала указанный файл и расположила его в оперативной памяти по некоему фиксированному адресу, и в pxeboot мне нужно передать управление на этот адрес.

 , , ,

vbr
()

Postgres в Kubernetes-е

Некоторые не советуют такое сочетание, но серьёзных аргументов я не увидел, похоже на карго-культ - мол плохо, потому, что плохо и всё тут. Для меня это не понятно. Постгрес это обычная программа, которая работает с подключенным хранилищем. Не вижу никакой разницы - запускать его в кубернетесе или на отдельной виртуалке с ровно так же подключенным хранилищем.

Есть операторы, которые обещают автоматизацию всего - разворачивают несколько инстансов с репликацией, делают автоматические бэкапы в S3, обновляют версии БД, в общем звучит очень круто.

Есть ли опыт тех, кто обжёгся на сабже и вернулся к обычной инсталляции?

 ,

vbr
()

Где на Руси жить хорошо?

Подумываю о планах иммиграции в Россию из соседней страны. Поскольку иммиграция - дело такое, вроде как ни к чему не привязан, то возникает вопрос - куда лучше. Страна огромная и выбрать не так-то просто.

Мои критерии:

  1. Поближе к центру страны. Времена сейчас какие-то смутные. Хочется держаться подальше от всех границ и потенциально проблемных регионов.

  2. Преимущественно русское население. Не критично, но у каждого народа свои обычаи, я с чужим живу с рождения, хочется и со своим пожить. Не воспринимайте как нацпол, пожалуйста.

  3. Рядом должен быть большой лес и, желательно, вода (озёра, водохранилища, реки).

  4. Должно быть всё идеально с экологией настолько, насколько возможно. Плюс желательно наличие хорошей воды в кране.

  5. Квартиры должны стоить в районе 70 000 рублей за кв. м. Финансов у меня ограниченное число и переезжать в коммуналку в Москве не хочется. Съём не рассматриваю.

  6. Вероятно предыдущие пункты вычёркивают проживание в непосредственно крупных городах, поэтому рассматриваю небольшие города-спутники. Но большой город должен быть недалеко, всё же без цивилизации неудобно, как мне кажется.

  7. Климат - в целом было бы неплохо потеплей, но всё же летом жару не хочется, плохо её переношу. Поэтому скрепя сердце вычёркиваю краснодарский край, там, как я понимаю, летом очень жарко.

  8. Всё же более-менее «приличное» население в плане достатка. Бывают города с откровенно бедным населением и вытекающими из этого неудобствами быта. Я в таком доме сейчас живу - люди не могут 3000 рублей собрать на замену проводки в доме. Всё очень бедно и держится на последнем издыхании.

Пока по совокупности признаков рассматриваю окрестности Екатеринбурга, Новосибирска, Красноярска. Из них мне больше всего понравился Екатеринбург (кажется он чуть теплей остальных), а в качестве целевого места понравился городок «Заречный» возле Белоярской АЭС. Поэтому помимо прочего буду благодарен за информацию про этот город, в интернете не так много про него пишут.

Ещё хотелось бы город, где много IT. Тут, похоже, Новосибирск вне конкуренции среди вышеперечисленных. В Екатеринбурге показалось всё совсем скудно. В целом я планирую работать удалённо, но иметь возможность выбора было бы неплохо.

 ,

vbr
()

Как я кубернетес поднимал

Точней начал. Может кому интересно будет. Гайдов вроде миллиард в интернете, но почему-то конкретно мои проблемы нигде не описаны были, пришлось курить, хотя там всё просто. А если вдруг корифеи расскажут, чего я сделал не так, будет совсем хорошо.

Вводная - имеется набор виртуальных серверов в одной частной сети 10.206.192.0/24. На них хочется поднять сабж.

Из нестандартного только load balancer. Он у моего провайдера к счастью есть. По сути это реверс прокси. Принимает соединения на 10.206.192.2:6443 и перенаправляет на 10.206.192.90:6443, 10.206.192.91:6443, 10.206.192.92:6443. Помимо прочего мониторит состояние и если какой-то сервер долго не принимает соединения на порту, то выключает его из этого пула.

На самих серверах я поставил ubuntu 20.04. Вообще я написал скрипты terraform и ansible, без них свихнуться можно, тыщу раз пересоздавал узлы.

В идеале надо 3 узла на control cерверы и 3+ worker-а. Конечно желательно, чтобы они крутились на физически разных серверах, иначе какой в этом всём толк. А так - если один сервер умрёт, то остальное вроде продолжит работать. На мастерах надо по 4GB / 2 cores, в крайнем случае до 2GB можно опустить, меньше уже нельзя. На рабочих нодах наверное можно и 1GB по сути сколько уже вашим приложениям нужно.

На всех серверах делается следующая конфигурация (помимо накатывания апдейтов):

echo br_netfilter > /etc/modules-load.d/br_netfilter.conf
modprobe br_netfilter
echo net.ipv4.ip_forward = 1 > /etc/sysctl.conf
sysctl net.ipv4.ip_forward = 1
apt install containerd
mkdir -p /etc/containerd
cat >/etc/containerd/config.toml <<EOF
version = 2
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = false
EOF
systemctl restart containerd
curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" >/etc/apt/sources.list.d/kubernetes.list
apt install kubelet=1.23.7-00 kubeadm=1.23.7-00 kubectl=1.23.7-00
apt-mark hold kubelet kubeadm kubectl

На этом вся подготовка закончилась. containerd из репозитория не очень новый, поэтому 1.24 кажется запустить не получится. Если нужно - там еще надо добавить репозитории докера и ставить последний containerd.

Далее на первом мастере

kubeadm init \
  --kubernetes-version=v1.23.7 \
  --control-plane-endpoint=10.206.192.2:6443 \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

если тут какие-то проблемы будут, вероятно неправильно работает load balancer.

Он минут 5 попыхтит и родит кластер. Напечатает команды, их пока выполнять не надо. Еще напечатает команды для копирования admin.conf в ~/.kube, это сделать желательно.

Теперь ставим calico. Это некий плагин для сети. Вот тут я просидел два дня.

kubectl create -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml
curl -O 'https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml'
vim custom-resources.yaml
// spec.calicoNetwork.ipPools[0].cidr: 10.244.0.0/16
// spec.calicoNetwork.ipPools[0].encapsulation: IPIP
kubectl create -f ./custom-resources.yaml
watch kubectl get pods -A

Вся суть в том, чтобы поменять значение поля encapsulation. По умолчанию оно пытается делать что-то странное, что у меня не работало и сеть не поднималась, причем без каких-то индикаторов проблем, на вид все нормально, а пакеты не ходят.

Потом ждем пока все поды запустятся. После этого (а может можно и сразу, но я предпочитаю не торопиться) добавляем все остальные ноды в кластер теми командами, которые написаны в выхлопе kubeadm init.

Альтернативно вмето calico можно поставить flannel. Он типа проще но настроек меньше. Я его пробовал, из коробки заработал без проблем.

В принципе всё, кластер работает. Я пока до этого этапа дошел. busybox запускается, пинги идут. Дальше буду со storage разбираться. Пока что всё довольно просто выглядит, не знаю, чего там этим кубернетесом все пугают. Какой-нибудь Оракл ставить было куда сложней.

 ,

vbr
()

Вопросы по кубернетесу

Стоит задача поднять кубернетес кластер. Пока для гитлаба, в перспективе для кучи другого, что сейчас в колхозном docker-compose крутится.

Поигрался немного, в целом вроде понятно, как устанавливать через kubeadm, но хочется по некоторым вопросам подтверждения.

Работать оно будет на виртуальных серверах, запущенных в openstack.

  1. ОС для виртуального сервера. Пробовал Ubuntu 20.04 и 22.04, в принципе оба варианта работают, больше склоняюсь к 20.04, 22.04 всё же только вышла.

  2. Версия кубернетеса. Тут вообще понимания нет. LTS у них нет, в каждом облаке своя версия, причём они даже патч-версии последние не используют в стабильных каналах, что меня особенно удивляет. Пока планирую использовать 1.22.10 (последняя версия в ветке 1.22), т.е. 1.21 уже почти снят с поддержки. Хотя в gke/stable именно 1.21 доступна как последняя версия.

  3. Хранилище. Как я понимаю, для кубернетеса надо обеспечить сервис, где он сможет сохранять данные (вроде называется persistent volumes). Пока планирую использовать NFS-сервер, запущенный на отдельном сервере, но в целом хотелось бы что-то более легко реплицирующееся, т.к. будет единая точка отказа, что не очень нравится. Не очень понятно, есть ли тут какой-то «стандарт-де факто».

  4. СУБД. Для сервисов нужен постгрес. Планирую его тоже запускать на отдельном сервере, т.к. много слышал, что в кубернетесе СУБД запускать неправильно. Правда не понял, почему. В перспективе сделать репликацию для устойчивости.

  5. Сеть. Как я понял, два основных варианта это Flannel и Calico. С Flannel у меня всё заработало сразу, с Calico возникли проблемы (dashboard не открывается). Как я понимаю, Calico даёт возможность условно говоря делать фаервол на каждый сервис. Пока не уверен, надо ли это, т.е. понятно, что иметь это хорошо, но ценой большого усложнения - не уверен, и так есть с чем разбираться. Нормально ли будет остановиться на Flannel? Не приведёт ли к проблемам в будущем?

  6. Всё в одном кластере. Т.к. накладные расходы на сам кубернетес не так уж малы, хочется ограничиться одним кластером на: вспомогательные инструменты (гитлаб), мониторинг/логи, production, staging. Я так понимаю, есть namespaces, которые вроде должны позволять полностью разграничить все сервисы. Можно ли это считать приемлемым подходом? В основном волнует то, чтобы сервисы из других пространств имён не влияли на production. Я так понимаю, в кубере для этого есть все инструменты по ограничению ресурсов.

 

vbr
()

kubeadm init: [WARNING SystemVerification]: missing optional cgroups: blkio

Пытаюсь установить kubernetes по официальной инструкции. При запуске kubeadm init вылезло предупреждение

[WARNING SystemVerification]: missing optional cgroups: blkio

Пытался нагуглить, не нагуглил. В целом вроде заработало. Но хочется понять, насколько это важно.

ОС - Ubuntu Server 22.04.

ls /sys/fs/cgroup/
cgroup.controllers      cgroup.threads         dev-mqueue.mount  io.stat                        sys-kernel-config.mount
cgroup.max.depth        cpu.pressure           init.scope        memory.numa_stat               sys-kernel-debug.mount
cgroup.max.descendants  cpuset.cpus.effective  io.cost.model     memory.pressure                sys-kernel-tracing.mount
cgroup.procs            cpuset.mems.effective  io.cost.qos       memory.stat                    system.slice
cgroup.stat             cpu.stat               io.pressure       misc.capacity                  user.slice
cgroup.subtree_control  dev-hugepages.mount    io.prio.class     sys-fs-fuse-connections.mount

Как я понял, должен быть файл /sys/fs/cgroup/blkio, у меня его нет.

Ничего особенно не настраивал, всё из коробки.

 

vbr
()

RSS подписка на новые темы