У letsencrypt есть неприятная особенность. У него стоит ограничение на 5 сертификатов в неделю для определенного имени. То бишь можно выпустить ровно 5 сертификатов для www.linux.org.ru, к примеру. Если этот лимит превышен, можно запросить сертификат для двух доменов вроде www.linux.org.ru, www1.linux.org.ru и он его успешно выпустит ещё 5 раз и тд.

У меня настроены скрипты на полный деплой кучи всего и я эти скрипты тестирую на отдельном окружении, где с нуля всё деплоится, в том числе и генерируются сертификаты. Понятно, что когда идёт разработка, то в этот лимит упираешься быстро. Приходится мусорить в конфигах. staging использовать не вариант, там куча всего поломается.

Тут внезапно узнал про сабж. Работает по протоколу ACME, то бишь вообще ничего менять не нужно кроме URL сервера. И вроде как у него вообще нет никаких ограничений на число сертификатов и тд. Конечно бесплатен.

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

Я использую сервер, на котором запущен докер. Локально у меня установлен только клиент-бинарник. Соединение настроено через docker context поверх ssh.

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

Нет ли тут какого-то более удобного решения? Также должно работать с docker-compose. Теоретически я это вижу, как некоторый демон, который запускается локально, а также мониторит запущенные докер-контейнеры на удаленном хосте. И при появлении новых контейнеров с выставленными портами он будет автоматически пробрасывать эти порты на локальный компьютер.

На всякий случай приведу команды, чтобы стало понятней.

$ s=someserver.com
$ docker run -d --rm --name nginx -p 127.0.0.1:8080:80 nginx
$ ssh $s curl -i --head -sS http://127.0.0.1:8080/
HTTP/1.1 200 OK
$ curl -i --head -sS http://127.0.0.1:8080/
curl: (7) Failed to connect to 127.0.0.1 port 8080 after 10 ms: Connection refused
$ ssh -L 127.0.0.1:8080:127.0.0.1:8080 -N $s
$ curl -i --head -sS http://127.0.0.1:8080/
HTTP/1.1 200 OK

Вот чтобы ssh -L не нужно было запускать, мне хочется.

Надо написать небольшой драйвер. Какие-то отрывочные знания по устройству ОС с университета есть, но драйверы никогда не писал. Драйвер взаимодействует с устройством через общую память. Прям глубоко в тему вникать мне не нужно. Посоветуйте, с чего начать. В идеале книжку, я книжки уважаю.

Нужно генерировать PDF-документ, в котором вставлено сложное векторное изображение.

Сейчас процесс выглядит так: генерируется SVG, растеризуется в PNG, генерируется HTML, в нём вставлено это PNG изображение и результат преобразуется в PDF.

Что не нравится:

1. PDF получается больше, чем, как кажется, должна была бы быть. Ну собственно 99% её размера это эта картинка.

2. PDF в теории это векторный формат, хотелось бы для пущего качества оставлять исходный вектор.

Но общий подход нравится, т.к. каждый этап легко отлаживать, поэтому сам процесс хотелось бы оставить (SVG, HTML).

Собственно в идеале нужен инструмент, которому на вход подаётся HTML в котором какой-то текст, разметка и тд, а также ссылка на SVG. А на выходе получается PDF, в котором SVG преобразован в PS или чего там внутри.

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

Есть утилита rsvg-convert которая умеет конвертировать SVG в PDF, у неё PDF получается хороший, и размер небольшой и вектор остаётся. Но как этот PDF встроить в HTML и потом сгенерировать следующий PDF - не понятно.

Последний раз плотно этим занимался несколько лет назад, по меркам фронтэнда мои знания полностью устарели. Тогда использовал react с классами, состояние в redux хранил, кучу каких-то библиотек натягивал чтобы с редуксом не так больно было работать. Билд вроде через webpack делал.

Сейчас нужно написать небольшой фронт. Проект - типичная опердень, тупо кучка табличек, формочек, CRUD в общем, с псевдо-REST бэкэндом.

Брать планирую реакт, ибо я его знаю. Понятно, что уже с функциями, я примерно в курсе как там что работает в плане базового реакта.

Языком планирую взять тайпскрипт, раньше с ним были шероховатости, думаю, уже всё должно быть идеально.

Вопрос с тем - что сейчас правильно брать:

1. Для сборки. webpack была жутко муторная ерунда. Слыхал, сейчас esbuild используют, хороший вариант? Я так понял, он typescript компилирует не пойми как, без проверок типов и тд, мне надо с проверками, как это правильно организовать?

2. Для хранения состояния что посоветуете? redux для форм мне тогда показался плохо приспособлен. Да и в целом странная библиотека, вроде концептуально всё просто и понятно, но когда на практике начинаешь использовать, там подтягиваешь 500 библиотек со всякими сагами и внезапно всё становится сложно и непонятно. Не понравилось по итогу. Хотя подозреваю, что сейчас с этим должно быть получше. Гуглится какой-то redux toolkit.

Слыхал, что react-query какая-то волшебная библиотека, которой даже каким-то макаром можно заменить state (а что нельзя - просто в компонентах пускай лежит, без всяких выпендрёжей).

Есть такой сайт: https://cloud.debian.org/images/cloud/bullseye/

Я так понимаю, это официальные образы от Debian для облачных провайдеров.

По указанному URL новый образ появляется примерно раз в месяц.

По адресу https://cloud.debian.org/images/cloud/bullseye/daily/ образы обновляются ежедневно.

Хочется понять, по какому принципу отбираются образы, которые появляются примерно раз в месяц. Я предполагал, что они публикуются, когда публикуется новое ядро, но это предположение оказалось неверным.

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

Использую set -e для упрощения обработки ошибок в shell-скрипте. Но в одном месте нужна более сложная обработка. Т.е. я вызываю определённую команду и после этого мне нужно получить код ошибки.

Для иллюстрации покажу следующий пример:

#!/bin/sh

set -e

(exit 2)
rv=$?
echo "rv=$rv"

В данном случае мне нужно продолжить выполнение после того, как subshell вернул ошибку. И обработать конкретное значение этой ошибки.

Понятно, что можно сделать set +e в нужном месте. Но может быть есть какой-то более изящный трюк?

Имеется ресурс с параметром count. Например

resource "openstack_compute_instance_v2" "worker" {
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = data.openstack_compute_flavor_v2.worker.name
  user_data   = templatefile("${path.module}/cloud-init/config.yaml.tftpl", { ... })

count больше единицы.

Если я поменяю значение flavor_name или user_data, то все серверы разом будут пересозданы. Это недопустимо. Нужно это делать по одному, мониторя состояние остальных серверов. Не получилось придумать, как это можно сделать адекватно. Пока пришел в голову только один способ:

resource "openstack_compute_instance_v2" "worker" {
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = count.index < var.worker_new_count ? new_worker_name : worker_name;
  user_data   = count.index < var.worker_new_count ? new_user_data : user_data;

продублировать все поля с новыми значениями и меняя переменную var.worker_new_count постепенно пересоздать все ресурсы, начиная с первого. Но будет довольно много дублирования, что кажется не совсем удачным вариантом.

В идеале хотелось бы написать

resource "openstack_compute_instance_v2" "worker" {
  lifecycle {
    ignore_changes = count.index < var.worker_new_count ? [] : [all]
  }
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = data.openstack_compute_flavor_v2.worker.name
  user_data   = templatefile("${path.module}/cloud-init/config.yaml.tftpl", { ... })

но в этом поле нельзя писать выражения.

Планирую создание кластера. Столкнулся с тем, что не могу решить, как правильно организовать доступ в сетевом плане. Всё делаю сам, поэтому обладаю некоторой гибкостью.

У провайдера OpenStack. Для виртуальных машин выделяю отдельную подсеть. Для контрольных серверов создаю выделенный балансировщик нагрузки, создаю 3 контрольных сервера, у балансировщика нагрузки фиксированный IP, он распределяет запросы по этим контрольным серверам. Ну и сколько нужно рабочих серверов. Такая конфигурация даёт некоторую доступность в случае небольших аварий или обслуживания серверов, ну насколько это можно сделать в текущих условиях. Сразу скажу, что использую инкапсулированную сеть для pod-ов, без инкапсуляции мне не удалось настроить, bgp-анонсы роутер опенстаковской сети не принимает. То бишь из пода я могу достучаться до сервера, а вот из сервера до пода уже нет.

Собственно стоят следующие задачи, которые нужно решить:

1. Доступ к этому балансировщику нагрузки, чтобы kubectl с локального компьютера использовать.

2. Доступ непосредственно к серверам по ssh. Во-первых, конечно, начальный, чтобы настроить всё, ну и потом может быть нужда.

3. В кластере будут работать ряд внутренних сервисы с единой авторизацией через работающий там же Keycloak, включая авторизацию для kubectl. Внутренние сервисы включают в себя gitlab, grafana, какие-то ещё средства мониторинга и управления вроде kubernetes dashboard. Не все пользователи технически подкованы, чтобы прокидывать туннели через kubectl proxy, поэтому нужен более простой доступ ко всем этим сервисам.

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

На текущий момент я вижу и частично опробовал три варианта.

Вариант один - всё публичное. Каждому серверу даём публичный IP помимо внутреннего (ну или одному даём и потом через ssh proxy jump ходим). Балансировщику нагрузки даём публичный IP. В итоге всё торчит нужными портами в интернет. Ну понятно, что фаерволом ненужное закрываем. kubectl просто работает.

Основной минус - нет дополнительного слоя безопасности. В то, что у всех пользователей будут сильные пароли, верить сложно. А значит могут взломать одного пользователя, получить доступ к внутренним сервисам. Также все внутренние сервисы будут торчать наружу и любая публичная уязвимость может создать проблему.

Вариант два - создаём один бастион-сервер. На нём публичный адрес, ssh и wireguard. Далее на все внутренние серверы ходим либо через proxyjump, либо через wireguard. Обычные пользователи настраивают себе wireguard клиента и одним нажатием подключаются во внутреннюю сеть. А там уже или через колхозный балансировщик нагрузки на haproxy на том же бастионе (не смотрящий наружу), или через провайдерский балансировщик нагрузки получают доступ к внутренним сервисам, выставленным через ingress-ы.

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

Вариант три - создаём в кластере wireguard-сервер. Мне этот вариант сразу понравился больше всего. По сути запускаем pod, в котором запускается wireguard, настрен ip forwarding и masquerade. Имеем доступность - если какие-то проблемы, под перезапустится на другом сервере. Имеем доступ прям к внутренней сети кластера - напрямую можно подключаться хоть к любому поду, хоть к любому сервису. Тут тоже можно сэкономить на балансировщике нагрузки для внутренних сервисов: в кубернетесе любой сервис это балансировщик нагрузки.

Но есть некоторые проблемы. Во-первых если делать не думая, то для этого пода нужен привилегированный режим. А это плохо. Если делать думая, то поду надо выдать capability NET_ADMIN, без неё wireguard настраивать не получается, я точно не знаю, насколько это плохо. А также нужно в кластере добавить unsafe sysctl net.ipv4.ip_forward, чтобы можно было его проставить для пода, тут тоже у меня нет чёткого понимания, насколько это плохо, но в любом случае это лишние телодвижения при создании кластера.

Далее - доступ к сети подов, как уже писал, чуть подумав я пришел к выводу, что не такая уж и хорошая эта идея. Хотя это решается, можно делат nat только на выбранные адреса, а не на все.

Далее - вся эта конструкция видимо несколько нестандартная, с calico оно работало, я пробовал недавно cilium, вот с ним оно сходу не заработало, поды видит, а сервисы - нет. Есть идеи, что можно настроить, чтобы заработало, но сам факт - сетап нестандартный и возможны проблемы, особенно с этой ebpf-машинерией, в которой я совсем не разбираюсь и могу только уповать на то, что оно работает.

И самое неприятное на мой взгляд - то, что судя по гайдам никто так не делает. Я собрал свой образ, сам набил все шишки. Это было полезно в любом случае, но я не люблю идти какими-то непроторёнными путями.

В общем на текущий момент я склоняюсь к варианту с отдельным бастион-сервером. Это кажется наиболее неинвазивным вариантом, если можно так выразиться и в целом решает основные задачи вроде как.

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

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

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

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

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

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

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

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

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

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

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

2. Проанализировав скрипты этого сайта я смог частично без него это сделать:

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 мне нужно передать управление на этот адрес.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вводная - имеется набор виртуальных серверов в одной частной сети 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 разбираться. Пока что всё довольно просто выглядит, не знаю, чего там этим кубернетесом все пугают. Какой-нибудь Оракл ставить было куда сложней.

Стоит задача поднять кубернетес кластер. Пока для гитлаба, в перспективе для кучи другого, что сейчас в колхозном 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. Я так понимаю, в кубере для этого есть все инструменты по ограничению ресурсов.

Пытаюсь установить 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, у меня его нет.

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