Долгое время в нашей внутренней сети для обработки DNS-трафика мы использовали только BIND, и нам с ним было хорошо. Но в какой-то момент его возможностей перестало хватать. В статье расскажу, что именно с BIND не так и почему теперь весь DNS-трафик у нас проходит через DNSdist. И что это вообще такое...

Жизнь с BIND​

Прежде чем говорить о DNSdist, нужно знать, почему мы вообще начали в его сторону думать. А для этого необходимо понимать, как была устроена наша DNS-инфраструктура до его прихода. Итак, начнём.

Мы живём в трех разных облаках. В каждом из них у нас поднято по два DNS-сервера BIND, которые реплицируются от «мастера», который также поднят в одном из этих облаков. Все сервера хранят одни и те же зоны, одну и ту же информацию.

Клиентами этих серверов у нас выступают все наши виртуальные машины, АРМ и K8S кластера. Для отказоустойчивости на всех ВМ мы указываем DNS-сервера из всех облаков. Например: ВМ из облака А будет в /etc/resolv.conf иметь DNS-сервера из облаков A, B и C. Никакого DNS-клиента (типа systemd-resolved) на этих ВМ не установлено (к сожалению), поэтому DNS-запросы летят вразнобой. Это станет нашей проблемой номер ноль.

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

zone zona IN {
     type forward;
     forward only;
     forwarders { 172.17.20.22; 172.17.20.23;};
};

Тут у нас появляется одна, но серьёзная проблема – умершие апстримы не выпадают из балансировки. Это значит, что если один из серверов, который мы указали в списке forwarders, упадет, BIND продолжит пытаться слать ему запросы. Это нам не нравится, клиенты начинают получать лишние timeout'ы, а лучше бы не получали.

Помимо этого, у некоторых апстримов есть специфичная особенность – они по-хорошему должны обслуживать только DNS-запросы тех клиентов, которые находятся с ними в одном и том же облаке. К таким апстримам у нас, например, относятся Consul (решение от компании HashiCorp) сервера, которые возвращают клиенту адреса живых инстансов запрашиваемого сервиса. Всё, что нам нужно, это, по сути, редиректить DNS-запрос на нужный DNS-сервер (который указан в forwarders) в зависимости от ip-адреса клиента и при этом иметь возможность указать fallback апстримы. К сожалению, распределение запросов по форвардам, основываясь на source ip в BIND, невозможно, и это наша последняя проблема.

Выход на сцену DNSdist​

Теперь давайте поговорим наконец-то о том, что же такое DNSdist. Если по-простому, то это Load Balancer для DNS-запросов. Он не содержит информации о зонах (кроме той, что закешировал), он просто берёт запрос и перенаправляет его самому подходящему, основываясь на политике балансировки, DNS-серверу (если предыдущий ответ на такой же запрос не закешировался или кеш «протух»).

Конфигурацию DNSdist принимает либо в формате Lua-скрипта, либо в формате обычной и всем знакомой YAML-конфигурации. В нашем понимании Lua намного гибче, чем YAML (так как это, блин, скриптовый язык), поэтому, если инструмент из коробки даёт возможность сконфигурировать себя чем-то таким, то надо хотя бы попробовать! Мы попробовали, и получилось очень даже неплохо :).

По конфигурации важно отметить один не очень приятный момент: DNSdist не может «на ходу» перечитать конфигурацию из файла, который вы ему указали. То есть нет никакого systemctl reload dnsdist, и вы не можете отправить ему SIGHUP, чтобы он что-то там перечитал в своей конфигурации (однако это не значит, что вы не можете заставить dnsdist переоткрыть файл, в который он пишет логи. Об этом будет ниже).

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

Ещё вы можете вносить изменения в конфигурацию через консольный доступ к DNSdist. Всё, что вам нужно сделать — это прописать вот эти две строчки в конфиге:

controlSocket('127.0.0.1:8899')
setKey("ENCODED KEY")

И дальше вот таким образом подключиться к консоли: dnsdist -k "ENCODED KEY" -c 127.0.0.1:8899, если вы не рут, и без указания ключа, если выполняете команду от рута. Это не очень удобно, и нормально такое автоматизировать будет достаточно геморройно, но это можно использовать, как ручник, когда вам ну вот вообще нельзя ребутать DNSdist, а внести изменения в конфигурацию надо. Подробнее об этом тут.

Если вам нужно менять конфигурацию периодически, и факторы, по которым вам нужно это делать, вы знаете, а такжесчитаете, что можете легко описать их в коде, то DNSDist предоставляет вам следующие возможности: создавать динамические блоки временных IP-адресов, на которые вы сможете «завязаться» в своих политиках, описывать какой-либо код в функции maintenance(), которая запускается автоматически раз в секунду, использовать блоки динамических правил и так далее. Вы можете написать почти любую логику для динамического изменения политик балансировки. Например, сделать так, чтобы в случае, если часть серверов в одном пуле вдруг начала периодически отдавать ServFail, перевести трафик на другой пул. Главное, чтобы ваши Lua-функции работали достаточно быстро и не блокировали выполнение других. Мы такими вещами у себя не пользуемся, наша конфигурация достаточно проста.

Наша конфигурация DNSdist​

Давайте теперь посмотрим, на то как выглядит наша конфигурация DNSdist. Полностью, конечно, не покажем, но самые интересные моменты подсветим :).

Начинается всё с файла dnsdist.conf, который и указывается при запуске DNSdist.

-- Импорт других файлов конфигурации
dofile("/etc/dnsdist/preps.lua")
dofile("/etc/dnsdist/secrets.lua")
dofile("/etc/dnsdist/pools.lua")
dofile("/etc/dnsdist/logging.lua")
dofile("/etc/dnsdist/pool_actions.lua")

-- Политика балансировки по умолчанию
setServerPolicy(roundrobin)

-- Сокет для DNS принятия запросов
setLocal('0.0.0.0:53')

-- Настройка сокета для изменения конфигурации из терминала
controlSocket('127.0.0.1:8899')
setKey(terminalPass)

-- Настройка веб сервера
webserver("0.0.0.0:8080")
setWebserverConfig({
  password=webServerPass,
  apiKey=webServerPass
})

Из интересного в этом файле:

1. Возможность импорта других файлов конфигураций, которую предоставляет Lua.
2. Переопределение дефолтной политики балансировки трафика.

По первому пункту, я думаю, всё понятно, а вот про второй давайте поподробнее. По дефолту для всех пулов апстримов используется политика leastOutstanding, которая отправляет запрос серверу либо с меньшим количеством запросов «в очереди», либо, если таких нет, то серверу с наименьшим порядковым значением, либо, если и таких нет, то с наименьшим средним latency. Нам такая стратегия не подходила, потому что при ней у нас в каждом пуле большая часть запросов летела в один сервер (потому что у него на 1-2мс latency был ниже, чем у других). Поэтому мы решили использовать для балансировки стандартный roundrobin. Подробнее про политики балансировки можно почитать тут.

Далее у нас идет preps.lua файл, в нём лежат константы и функция создания новых пулов.

geoProdZone = "geo.zona."

-- Селектор запросов определённой зоны
geoProdZoneSelector = QNameSuffixRule(geoProdZone)

-- Селектор запросов только от определённых source ip
cloud1SubnetsSelector = OrRule{
  NetmaskGroupRule("172.18.0.0/16"),
  NetmaskGroupRule("172.19.0.0/16"),
  NetmaskGroupRule("172.20.0.0/16")
}

function newPool(options)
  for i, v in ipairs(options.servers) do
    local server = {
      address=v.address,
      name=v.name,
      -- Основной пул для сервера
      pool=options.primaryPool,
      checkType="SOA",
      --- Сервер обязан ответить что-то, что не NXDomain, ServFail или Refused чтобы пройти хелс чек
      mustResolve=true,
      --- Выводим сервер из балансировки после трех неудачных проверок
      maxCheckFailures=3,
      -- Две успешные проверки чтобы ввести сервер обратно в балансировку
      rise=2
    }

    server.checkName = options.zone

    local newServer = newServer(server)
    -- Определяем вторичный пул для сервреа
    if options.secondaryPool then
        newServer:addPool(options.secondaryPool)
    end
    
  end
end

В целом для констант всё описано в комментариях, поэтому на них не будем заострять внимание. С функцией чуть поинтереснее. DNSdist из коробки даёт функцию на создание нового сервера (по сути, на определение апстрима), но использовать только её нам не очень понравилось из-за дублирования кода, поэтому пришлось смастерить свою небольшую функцию newPool, которая и определяет сервер с правильными хелсчеками, и добавляет его в основной пул и вторичный (если такой передан).

Теперь посмотрите, как удобно ей создавать пулы апстримов в файле pools.lua.

newPool({
  servers = {
      {address="172.23.1.2", name="cloud1_prod_consul1"},
      {address="172.23.1.3", name="cloud1_prod_consul2"},
      {address="172.23.1.4", name="cloud1_prod_consul3"}
  }, 
  -- Передаём основной пул для серверов
  primaryPool = "consul_prod_cloud1",
  -- Передаём вторичный пул для серверов
  secondaryPool = "consul_prod_default",
  -- Передаём зону для корректных хелсчеков
  zone = consulProdZone
})

Далее у нас идет небольшой, но интересный файлик logging.lua.

function forLogsSelector(dq)
  return not (
    dq.qname:isPartOf(newDNSName("domain1.ru")) or
    dq.qname:isPartOf(newDNSName("domain2.ru")) 
  ) and dq.qname:countLabels() > 1
end

addAction(
  LuaRule(forLogsSelector), 
  LogAction(
    -- Имя файла, куда писать лог
    "/var/log/dnsdist/queries.log", 
    -- Бинарный формат логов
    false, 
    -- Добавлять (append) строчки логов к файлу или каждый раз очищать его
    true, 
    -- Буферизация для логов перед записью в файл
    false
  )
)

В нём мы настраиваем логгирование запросов к DNSdist-серверу. Само логгирование включается через добавление действия LogAction, которое записывает логи в файл. Подробнее про действия поговорим в следующем файле. В этом же для нас основной интерес представляет функция forLogsSelector, которая по сути обозначает запросы каких доменов нужно логгировать, а каких нет. В наши DNS-сервера летит куча запросов доменов, о которых нам не интересно знать, что их кто-то когда-то запрашивал, и, соответственно забивать этим еластик не очень хочется. И наоборот, есть домены, про резолв которых интересно было бы знать (в основном безопасникам). Поэтому в этом файлике мы отсекаем лог запроса большого количества ненужных зон и оставляем только те, которые нам нужны.

Если вы ротейтите логфайл (меняете текущему имя и создаете рядом новый), вам надо сказать DNSdist, чтобы он файлик переоткрыл. Для этого нужно воспользоваться терминалом и следующим образом «релоаднуть» LogAction:

echo "getAction(0):reload()" | dnsdist -c 127.0.0.1:8899 

Только учтите, что такой вызов работает только в случае, если действие с LogAction идёт в вашем списке первым. О порядке выполнение действий чуть ниже.

Ну и последнее – это файлик с действиями: pool_actions.lua.

-- consul cloud 1 action
addAction(AndRule{
  cloudOneSubnetsSelector,
  consulDevZoneSelector,
  PoolAvailableRule("consul_dev_cloud1")
}, PoolAction("consul_dev_cloud1"))

-- consul fallback action
addAction(AndRule{
  consulDevZoneSelector,
  PoolAvailableRule("consul_dev_default")
}, PoolAction("consul_dev_default"))

-- default fallback
addAction(AllRule(), PoolAction("bind_default"))

Тут важно немного объяснить, как работают действия (actions).

• Во-первых, синтаксис у них следующий: первым аргументом идет селектор, который выбирает, на какие запросы распространяется действие. Вторым идет само действие (есть ещё третий аргумент – хешмапа с опциями, но мы ей не пользуемся).
• Во-вторых, последовательность, в которой вы эти действия в коде прописываете, имеет значение. То есть если вы самым первым определили действие с селектором AllRule, то никакие действия дальше работать не будут просто потому, что первое действие по итогу будет обрабатывать все запросы. Исключениями тут являются действия, которые выполняются и пропускают запрос дальше – например, LogAction, про который говорили выше.
• В-третьих, вы можете менять последовательность действий на запущенном сервере DNSdist с помощью терминала, про который я говорил выше.

Полный список селекторов и действий можно найти тут и тут.

В нашем файле сверху у нас три действия.

• Первое отбирает только запросы от клиентов из облака Cloud1 и «нацеленные» на DEV зону consul. В случае, если dev консулы в Cloud1 живы, мы перенаправим туда трафик. Если хотя бы одно из условий не истинно, действие не выполнится, и запрос пойдет к следующему.
• Второе – это уже фолбек для консулов. Оно проверяет, что пользователь запрашивает DEV зону consul и в дефолтном пуле консулов (то есть где находятся все консулы из всех облаков) есть хотя бы один живой сервер.
• Ну и последнее – это фолбек для всех действий: если ничего выше не сработало, то трафик пойдет на дефолтные BIND-сервера.

Итог​

Подытожим: DNS-сервис, который мы предоставляем нашим клиентам, стал работать надёжнее после внедрения DNSdist за счёт его хелсчеков для апстрим DNS-серверов и гибкой настройки политик распределения DNS-трафика. Мы продолжим сопровождать DNSdist и в будущем, возможно, даже включим у него кеширование запросов на некоторых пулах для увеличения производительности.

Спасибо за чтение!

Зачем это нужно​

Давайте перед тем, как говорить про BPF CPU Scheduler, немного обсудим имеющиеся во встроенном cpu планировщике линукс проблемы, из-за которых собственно и появилась идея создания возможности для разработчиков писать свои собственные шедулеры.

Первая проблема – каким бы "Completely Fair" не был дефолтный планировщик, он все равно останется планировщиком общего назначения, и поэтому никогда не будет покрывать специфичные кейсы (гейминг, некоторые highload web сервисы и так далее).

Вторая проблема – невероятная сложность устройства подсистемы CPU шедулинга в линукс. Если вам нужно внести туда какие-то свои правки или не дай бог написать какой-то дополнительную политику планирования, вам нужно полностью разбираться в этой системе, а она очень сложная и не то чтобы полностью задокументированная.

Третья проблема – достаточно медленная разработка. Если вы всё-таки решились вносить какие-то правки в kernel scheduler, сразу приготовьтесь, что для каждой проверки, для каждого фикса вам нужно будет пересобирать ядро и перезапускать систему, а на это нужно время.

Четвертая проблема – вероятно ваши правки, которые нужны только вам, в апстрим не попадут. Соответственно каждый раз, когда ядро будет обновляться, вам придется пулить изменения с апстрима в вашу ветку, и всегда есть большая вероятность, что придется править мердж конфликты, а когда мы говорим про ядро, это может быть достаточно нетривиально.

Что такое Extensibe CPU Scheduler (SCHED_EXT)​

Extensible Scheduler – это функционал ядра линукс, который даёт возможность пользователям создавать свои собственные политики распределения CPU времени. Делается это посредством написания BPF приложения и его последующей загрузки в ядро. После этого контролировать выделение цпу времени всем процессам (или только процессам с классом SCHED_EXT, об этом подробнее ниже) будет ваш планировщик.

В linux есть ряд классов планирования помимо SCHED_EXT, о которых можно почитать в другой моей статье :). Касательно этой темы важно знать, что при запуске extensibe шедулера все SCHED_NORMAL, SCHED_IDLE и SCHED_EXT задачи перейдут под его контроль, если не передан флаг SCX_OPS_SWITCH_PARTIAL. Если же флаг всё-таки передали, то наш кастомный планировщик будет управлять только задачами, которым мы руками выставим класс планирования SCHED_EXT. Это не особо рекомендуется, потому что приоритет SCHED_EXT ниже SCHED_NORMAL и ваш планировщик просто не сможет в полной мере "показать себя", если ему будут мешать задачки, управляемые дефолтным планировщиком. Проверить, управляется ли запущенный процесс extensible планировщиком, можно, посмотрев его schedule параметры в файле /proc/$PID/sched. Если вы видите там строчку ext.enabled: 1, значит процессорное время ему выделяет запущенный SCHED_EXT планировщик.

Примечательно, что в отличие от бага в модуле или подсистеме ядра, баг в BPF программе SCHED_EXT не приведет к апокалипсису kernel panic и необходимости перезагрузки системы. Если внутри вашего планировщика происходит ошибка, то BPF приложение завершается, а все процессы, ранее им управляемые, переходят обратно на дефолтный планировщик.

Внутреннее устройство SCHED_EXT​

Начнем с самой базы – Сore CPU планировщика (kernel/sched/core.c). Он определяет, какой класс планирования выставить потоку, вызывает функции шедулеров, принадлежащих конкретным классам планирования, реализует context switching и так далее. В мире ООП можно было бы назвать его родительским классом для всех остальных планировщиков.

Далее у нас идет код класса планирования SCHED_EXT (kernel/sched/ext.c). В нём реализуется полный набор функций, которые требуются для функционирования отдельного класса планирования. Посмотреть их можно в вызове вот этого макроса.

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

/* Проверяется, реализована ли функция в вашем шедулере */
if (unlikely(!SCX_HAS_OP(sch, enqueue)))
    goto global;

/* Вызывается функция кастомного шедулера */
SCX_CALL_OP_TASK(sch, SCX_KF_ENQUEUE, enqueue, rq, p, enq_flags);

/* ... */

/* Дефолтная реализация, на случай, если функция enqueue не реализована в вашем планировщике */
global:
	touch_core_sched(rq, p);
	refill_task_slice_dfl(p);
	dispatch_enqueue(sch, find_global_dsq(p), p, enq_flags);

Подобные дефолтные реализации есть для каждой функции, поэтому когда вы пишете свой планировщик, у вас нет функций, которые вам нужно обязательно реализовать, иначе ничего работать не будет. Есть только одно обязательное поле для пользовательского планировщика - его имя :). Все остальные поля, которые вы можете реализовать, вы найдете в структуре sched_ext_ops.

В самом низу файла можно найти фрагмент регистрации bpf_struct_ops. "BPF Struct Ops" - это специальный тип BPF программ, позволяющий реализовывать отдельный функционал ядра. Работает это таким образом – вы пишите функции (программы), кладете ссылки на них в специальную структуру, а потом, на этапе загрузки приложения в ядро, эта структура вместе с программами кладётся в определённое место в памяти ядра. И далее уже эти функции могут в качестве call-back'ов вызываться подсистемами ядра, например, как это было показано выше макросом SCX_CALL_OP_TASK.

На уровне выше идёт код BPF программы собственно вашего планировщика. Примеры, как они могут выглядеть, можно посмотреть в этой папке. Вот самый простой из них - scx_simple.bpf.c.

Ну и ещё выше остается только программа, которая вызывала syscall bpf(), загрузив тем самым BPF программу шедулера. Так же прилагаю самый простой пример - программу scx_simple.c, запускающую планировщик scx_simple, на чей код уже была ссылка выше. Заметьте, что это единственная часть кода, которая запускается у нас в пространстве пользователя.

Планировщик в User Space​

Вам может показаться, что единственное место, в котором вы можете описывать логику вашего шедулера - это код планировщика в пространстве ядра, но это не так. BPF приложение состоит из программ (считай функций), BPF Map (это может быть хеш-таблица, массив или более специфичные типы данных) и глобальных переменных, и последние два пункта доступны в том числе и из пространства пользователя. Поэтому у вас, например, может быть общая мапа, в которую BPF шедулер будет складывать задачи, запрашивающие процессорное время, а user-space шедулер будет решать, кому из этой мапы следующему дать доступ к процессору, и после этого перекладывать в другую мапу, из которой планировщик в ядре возьмёт задачу и сразу отправит выполняться. Примерно так поступили при реализации scx_userland.

Вы можете справедливо задаться вопросом: "если у меня все основные решения по планированию задач принимаются в пространстве пользователя, не получится ли так, что теперь планировщик будет планировать сам себя?". Если процесс вашего "userland" планировщика имеет параметр ext.enabled: 1 (как этот параметр получается описано выше в разделе "Что такое Extensibe CPU Scheduler"), то да, получается ваш планировщик сам себе выписывает процессорное время. Эту ситуацию можно обыграть следующим образом: прописать логику в BPF коде так, чтобы часть планировщика, загруженная в ядро, относилась к своей "userland" части по-особенному. Например, BPF часть может выдать ей бесконечный доступ к процессорному времени, пока она не разберётся с накопленной очередью задач и не определит, на каких CPU они должны выполняться. Такой подход применяется в scx_rustland_core, фреймворке для написания "userland" планировщиков на rust.

Примеры существующих​

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

1. scx_rustland – планировщик, приоритезирующий интерактивные процессы над фоновыми и просчитывающий все решения планирования в пространстве пользователя. Хорошо себя показал на системе с запущенной Terraria, увеличив fps в игре с 30 кадров до 60. Весь код планировщика состоит из трёх частей: BPF код на C, выполняющийся в ядре, Rust фреймворк scx_rustland_core, о котором уже писал выше, и код на Rust, реализующий правила политики с помощью фреймворка.

2. scx_layered – планировщик, созданный в Meta (признана экстремистской и запрещена на территории РФ), позволяет делить процессы на "слои" и задавать каждому слою свою политику. Например, вы можете выделить все процессы в cgroup'е system.slice и указать, что процессам в ней выделяется от 1 до 4 ядер, и что выделение им новых ядер происходит только в случае высокой утилизации всех текущих. Подробнее можно почитать в этом исследовании и в этом мануале по конфигурации scx_layered. Утверждается, что в Meta (признана экстремистской и запрещена на территории РФ) этот планировщик используется для множества web сервисов, в которых важен точечный контроль над выделением CPU.

3. scx_lavd – планировщик, как говорят, разработанный специально для Steam Deck, и, как вы, наверное, уже поняли, для игр :). Код делится на BPF часть, написанную на С, и часть, написанную на Rust. Всё планирование задач происходит в C коде, а Rust предоставляет "высокоуровневую" информацию системе и загружает BPF код в ядро.

__

Спасибо за чтение!

Про кластерный мониторинг в OKD​

В OKD всё управляется встроенными операторами, и, соответственно, кластерный мониторинг — не исключение. У вас есть openshift-monitoring оператор, который разворачивает всё, что касается мониторинга: prometheus-operator, kube-state-metrics, openshift-state-metrics, node-exporter и так далее. А так как он всё это разворачивает, то он же и обновляет, и вносит изменения в конфигурацию всех компонентов. По обновлению, я думаю, всё понятно — обновляется версия кластера = обновляется версия оператора = обновляются компоненты, которыми оператор управляет. Это в принципе очень удобно. Теперь про конфигурацию: все изменения в компоненты вносятся исключительно через оператор, вы не можете в обход него пойти и что-то там подправить в прометеусе — ваши изменения просто перезатрёт. На словах это очень круто и логично звучит, но реализация... Ниже в разделе "Почему решили переезжать на VMAgent" я подробнее опишу минусы этого.

Основную нагрузку в этой схеме у нас принимает Prometheus, так как именно на него и сваливаются все метрики кластера. В OKD есть два типа инсталляций Prometheus: openshift-monitoring (далее по тексту "кластерный прометей") и openshift-user-workload-monitoring (далее по тексту "клиентский прометей"). Первый отвечает за снятие метрик самого кластера, то есть это метрики cAdvisor, node-exporter, kube-state-metrics и так далее. Второй отвечает за снятие метрик с приложений. Это разделение нужно для того, чтобы, например, толстые метрики какого-нибудь пользовательского приложения, убив прометей, не лишили при этом администраторов кластера доступа к "служебным" метрикам.

Развёртка этих двух прометеев в самом кластере — это деплой двух StatefulSet'ов в разных namespace'ах. Количество реплик этих SS не регулируется и в 99% случаев равно двум, подробнее про то, почему количество реплик нельзя регулировать, будет написано ниже в разделе "Почему решили переезжать на VMAgent". При этом сами эти реплики — это идентичные прометеи, которые скрепают в рамках SS одни и те же таргеты. То есть обе реплики кластерного прометея собирают ВСЕ кластерные метрики, а обе реплики клиентского прометея собирают ВСЕ пользовательские метрики :). То есть это не шарды, которые поделили между собой таргеты, и каждый собирает свои.

Как был настроен у нас​

Долгое время у нас была реализована следующая схема: есть "коммунальные" кластера VictoriaMetrics, и кластера OKD. В OKD кластерах были развёрнуты кластерный и клиентские инсталляции прометея. Обе эти инсталляции взаимодействовали с кластером VictoriaMetrics через компонент VMAuth, передавая свои метрики. Также у нас в каждом кластере была и есть OKD Console (веб-консоль кластера), которая ходит в прометей за кластерными метриками для отображения загруженности подов, метрик нод и так далее.

То есть у нас кластерные прометеусы выполняли две функции: все собранные метрики отправляли в VictoriaMetrics (основная функция) и также накапливали метрики для показа их в OKD Web Console (это касается только openshift-monitoring инсталляции Prometheus).

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

• VMAuth: выше я сказал, что в качестве хоста для remoteWrite в прометеусах указывался VMAuth – это компонент кластера VictoriaMetrics, отвечающий за добавление слоя авторизации для нижележащих компонентов. При успешной авторизации он проксирует запрос далее на нужный сервис (VMInsert или VMSelect).
• VMStorage: я думаю, по названию понятно, что это такое :). Это слой хранения, база данных для всех метрик кластера. Это может одна ВМка или несколько, репликация данных может быть включена, а может и нет, и так далее, возможностей для конфигурации много.
• VMInsert и VMSelect — это, соответственно, пишущий и читающий компоненты. У каждого есть свои специфичные функции, например, у VMSelect'а есть дополнительный кеш для запросов, чтобы лишний раз не ходить в хранилище.

Из представленной схемы кластера VictoriaMetrics, я думаю, уже понятен основной её плюс – гибкая микросервисная архитектура. Это позволяет быстро масштабировать кластер, а также добиваться максимальной отказоустойчивости. Например, "stateless" компоненты (VMAuth, VMInsert, VMSelect) вы можете увезти в Kubernetes, а VMStorage оставить на виртуальных машинах; вы можете отдельно скейлить «write» и «read» части кластера; вы можете выделить отдельные VMSelect для часто "читающего" сервиса, чтобы он не "зааффектил" остальных и так далее.

Что такое VMAgent​

VMAgent по сути тот же самый Prometheus за одним исключением — вы не можете запрашивать метрики у VMAgent, потому что он на это не рассчитан. Он накапливает небольшое количество собранных им метрик и сразу отправляет в хранилище, которое поддерживает "Prometheus remote write" или "VictoriaMetrics remote write" протоколы.

VictorieMetrics remote write протокол использует намного меньше сетевого трафика, чем аналогичный протокол от команды Prometheus (подробнее можно прочитать тут). VMAgent автоматически определяет, поддерживает ли хранилище протокол от VictoriaMetrics, и использует его для передачи данных.

Почему решили переезжать на VMAgent​

Поговорим наконец, почему мы решили "съезжать" с Прометеуса в наших OKD-кластерах. На самом деле, мигрировали мы не полностью. Как я выше писал:

То есть у нас кластерные прометеусы выполняли две функции: все собранные метрики отправляли в VictoriaMetrics (основная функция) и также накапливали метрики для показа их в OKD Web Console (это касается только openshift-monitoring инсталляции Prometheus).

И вот если основную функцию мы ещё можем забрать у преметея и унести на VMAgent, то отображение метрик в web-консоли OKD мы реализовать через VictoriaMetrics, к сожалению, не можем. В консоли всё, что касается метрик, сильно "захардкожено", и работать оно может только с прометеем, находящимся внутри кластера. Но тем не менее функцию отправки кластерных метрик в VictoriaMetrics можно реализовать через VMAgent, и это очень хорошо.

Теперь давайте перейдем к причинам миграции:

1. Урезанные возможности конфигурирования кластерного прометея в OKD. Список возможных настроек кластерных прометеев.

   • Вы не можете точечно управлять списком таргетов, которые скрепает прометей, всё, что у вас есть, это поле collectionProfile, у которого есть два значения, "full" и "minimal", то есть "скрепай вообще всё что можно" и "скрепай только минимально необходимое". Причем эта настройка доступна только с версии 4.19 (самая последняя на момент написания статьи).
   • Вы не можете изменять количество реплик стейтфулсетов прометеусов. Если у вас кластер в HA-режиме (3 и более мастеров, подробнее тут), то количество реплик в стейтфулсетах кластерного и клиентского прометеев будет равно двум (в ином случае одной), и вы ничего не сможете с этим сделать. У вас просто будут дублироваться прометеи, и в случае, если у вас не маленький кластер (несколько тысяч подов), то одна реплика кластерного прометея может спокойно потреблять 15–20 ГБ оперативной памяти. Это при условии, что прометей отправляет метрики в удаленное хранилище и ещё накапливает их для OKD Web Console.
   • Вы не можете вносить изменения в конфигурацию kube-state-metrics, ограничивая количество и список ресурсов, который он выводит в метрики. Если у вас есть ресурс, который, например, очень часто пересоздаётся/обновляется, то это будет генерировать значительное количество метрик, которое вам, может быть, и не нужно. И вы также не можете поднять свою инсталляцию kube-state-metrics, сконфигурировать её как вам нужно и перенаправить прометеусы на неё.

2. Высокое потребление ресурсов (в частности, RAM). В предыдущем пункте затронул эту тему.

3. Стабильность. Этот пункт тоже касается ресурсов :). У всех прометеев обязательно стояли лимиты на потребление RAM, но им его вечно не хватало, особенно если кластер резко рос по числу подов или в случае проведения тех работ. Из-за этого прометеи могли в цикле умирать по ООМу и, соответственно, ослеплять мониторинг. Чтобы это "полечить", нужно было тупо повышать им лимит на потребление оперативной памяти, так как давать ему безлимит на потребление RAM (или просто сильно завышать этот лимит) не очень хотелось. Мало ли что у него может заглючить и он съест всю оперативку на ноде.

Процесс миграции​

1. Установка оператора VictoriaMetrics​

Миграция начинается с установки VictoriaMetrics Operator, через который мы будем разворачивать инсталляции VMAgent. VMAgent можно поставить и без оператора, напрямую. Есть даже helm chart для этого. Но у установки с помощью оператора есть существенные плюсы:

• позволяет разворачивать в кластере не только VMAgent, но и другие компоненты экосистемы VictoriaMetrics, типа VMAuth или VMSelect;
• позволяет шардировать инсталляции VMAgent'а, то есть он может автоматически делить собираемые таргеты между шардами, количество которых вы также можете регулировать (вместе с этим вы можете управлять и количеством реплик шардов).

Установка оператора производится через helm chart, для деплоя в OKD каких-то особенных параметров не требуется. В чарт встроена проверка на то, что вы деплоите оператор в OpenShift/OKD кластер, и в таком случае в ресурсы чарта вносятся соответствующие изменения.

После установки оператора он автоматически для каждого ресурса ServiceMonitor (SM) создаст VictoriaMetricsServiceScrape (VMSS).

Если у вас в кластере используется ArgoCD, то рекомендуется включать параметр чарта operator.enable_converter_ownership, чтобы для созданных автоматически ресурсов VMSS в ownerReference указывался SM, по которому они были созданы. Иначе ArgoCD может помечать их как "объекты на удаление".

2. Установка инсталляций VMAgent​

Нам необходимы две инсталляции VMAgent: для служебных метрик кластера и для метрик с клиентских приложений (по той же причине, по которой в OKD/Openshift существует это деление). Делается это через создание ресурсов с kind VMAgent. Но если просто взять и создать два таких ресурса, то оператор запустит эти две инсталляции, разобьёт на шарды и тд, но "скрепать" они будут одни и те же таргеты, нам такое не подходит. К счастью для ресурсов VMAgent можно прописывать селекторы для таргетов, ими мы и воспользовались.

VMAgent для клиентских метрик у нас настроен с такими селекторами:

serviceScrapeNamespaceSelector:
	matchExpressions:
		- operator: DoesNotExist
		  key: openshift.io/cluster-monitoring # Специальный лейбл на служебных неймспейсах
serviceScrapeSelector:
	matchExpressions:
		- operator: DoesNotExist
		  key: vmagent-cluster-metrics # Специальный лейбл для VMSS, предназначенных инсталляции VMAgent собирающей служебные метрики

А VMAgent для кластерных метрик настроен с такими:

serviceScrapeSelector:
	matchLabels:
		vmagent-cluster-metrics: "true" # Специальный лейбл для VMSS, предназначенных инсталляции VMAgent собирающей служебные метрики
nodeScrapeNamespaceSelector:
	matchLabels:
		kubernetes.io/metadata.name: openshift-monitoring # Следит за VMNodeScrape только с конкретного namespace

Таким образом у нас каждая инсталляция собирает только те таргеты, которые предназначены ей.

Из интересного ещё устанавливалось вот такое affinity правило для того, чтобы реплики одного и того же шарда по возможности не попадали на одну ноду:

affinity:
	podAntiAffinity:
		preferredDuringSchedulingIgnoredDuringExecution:
			- weight: 100
			  podAffinityTerm:
			  labelSelector:
				  matchLabels:
						app.kubernetes.io/instance: vmoperator-vmagent
						shard-num: '%SHARD_NUM%'
			  topologyKey: kubernetes.io/hostname

3. Правки кластерных прометеев​

Теперь, когда VMAgent'ы установлены, нужно "отключить" прометеи. К сожалению, полностью отключить можно будет только один из них, но что поделать.

Удаляем configmap, включающий клиентский прометей. Выглядит он как-то так:

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-wokload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    enableUserWorkload: true # <-- включение прометея для клиентских метрик
							 # ... далее все его настройки 

Удаляем поле remoteWrite из configmap "cluster-monitoring-config" в namespace "openshift-monitoring", тем самым отключая отправку метрик в VictoriaMetrics для кластерного прометея.

Проблемы после миграции​

Разумеется не могло всё пройти без проблем. По порядку:

Первое: пропажа некоторых лейблов и агрегирующих метрик. По этому пункту основное — это отсутствие лейбла prometheus_replica на всех метриках, собираемых VMAgent'ами. prometheus_replica — это лейбл, вешавшийся на все метрики, отсылаемые в remoteWrite прометеями, и обозначавший, с какой конкретно реплики (prometheus-0 или prometheus-1) пришла метрика. На всех наших бордах в графане была завязка на этот лейбл, поэтому пришлось править их всех :). Так же кластерные прометеи на ходу создавали агрегирующие метрики (Recording rules), и полностью повторить их с переходом на VMAgent у нас не получилось, поэтому ото всех таких метрик (полный список тут) пришлось отказаться.

Второе: не все ServiceMonitor'ы корректно переводились оператором в VMSS. Выше я писал, что VictoriaMetrics оператор автоматически транслирует ресурсы ServiceMonitor в VictoriaMetricsServiceScrape. В общем SM, нацеленные на служебные сервисы (типа etcd, kubelet и тд), он транслировал неправильно, все их приходилось ручками переделывать.

Результаты​

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

К сожалению, у нас сохранились только метрики, на которых видно отключение remoteWrite у инсталляции кластерного прометея, а также установку VMAgent'ов, которые теперь будут слать метрики в кластер VictoriaMetrics. Этот момент выделен голубой линией на графиках.

Отключение клиентского прометея мы совершили сильно раньше, поэтому метрик за этот период у нас не сохранилось :(. Потреблял он около 10-15% от того, что потребляет кластерный прометей.

• Общее потребление памяти по нашим кластерам
• Общее потребление CPU по нашим кластерам
• Потребление отдельных VMAgent'ов на одном из самых нагруженных кластеров

При том, что в целом общие показатели потребления сильно снизились, мы также заметили, что потребление отдельных VMAgent'ов не особо растет при резком увеличении количества метрик, которые они обрабатывают. Пока что за всё время, что у нас работают VMAgent'ы (чуть больше полугода), у нас ни разу не было такого, что они падали от резких скачков нагрузки.

Проблема​

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

Дробные лимиты на CPU​

Причина у нашей проблемы одна – дробные лимиты на CPU. О том, что это такое, как возникает и как лечить – расскажу ниже.

I. У приложения один поток​

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

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

Как работает лимит? Допустим, вы указали контейнеру лимит в 400m. В таком случае поток приложения в контейнере сможет потратить 40мс из 100мс своих периодов. Что мы после этого получаем? Ниже у меня приведён пример процесса в потоке, контейнеру которого выставлен лимит в 400m CPU. По факту на выполнение этому процессу требуется всего 120мс, но из-за установленного лимита он не может потреблять всё время своих периодов. После того, как он проработал свой максимум (40мс), ему приходится ждать своего следующего периода. Поэтому на картинке мы видим паузы (троттлинг) в работе процесса, из-за которых 120мс превратились в 235мс.

II. У приложения много потоков​

Давайте теперь рассмотрим чуть более сложный вариант – когда у приложения несколько потоков. В таком случае лимит, который вы указали для контейнера, будет делиться поровну между активными потоками приложения.

А если у вас лимит делится между активными, то существует большая вероятность того, что каждый из этих активных потоков по итогу получит дробный лимит (меньше одного).

Например, у вас есть приложение с двумя потоками, вы контейнеру этого приложения задаёте лимит в одно ядро. В случае, если работает только один поток, он заберёт себе лимит в одно ядро полностью и соответственно будет иметь доступ к своим 100мс периодам (то есть по сути лимита для него не будет).

В случае же, если будут одновременно работать сразу два потока, то лимит в одно ядро поделится между ними и каждый получит по 500m CPU. А это в свою очередь означает, что каждый сможет использовать только половину своих периодов, что приведёт к троттлингу.

Итого​

Давайте подведём небольшие итоги по дробным лимитам.

1. Лимит меньше одного ядра приложений с одним потоком всегда будет приводить к задержкам и, соответственно, к потерям по производительности. Просто потому, что приложение не сможет целиком использовать свой период.
2. Для приложений с двумя и более потоками – анализируйте их загруженность. Например, есть приложение с двумя потоками, и эти потоки у него загруженны равномерно. Тут для получения максимальной производительности контейнеру нужно будет задавать лимит в два ядра, чтобы они поровну поделились между потоками и каждый получил по одному целому ядру. В случае же, если из этих двух потоков 90% времени работает только один, а второй выполняет фоновую активность, то контейнеру есть смысл ставить лимит в одно ядро, потому что большую часть времени работает из двух потоков только один.

Отказ от лимитов​

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

Но исходя из того, что было мной рассказано выше – получается, что для максимальной производительности приложенния лимит его контейнеру должен быть либо кол-во потоков = кол-во ядер в лимите, либо кол-во активных потоков = кол-во ядер в лимите. И честно говоря, вторую формулу никто никогда не применяет :). Везде всегда лимит накручивается до максимума, лишь бы избавится от троттлинга. А если так, то зачем он вообще тогда нужен, может отказаться от него?

Идея отказа от лимитов на CPU звучит как что-то сумасшедшее, но на самом деле поизучав статьи в интернете, послушав мнения других пользователей k8s, мы в команде пришли к выводу, что в сообществе давно сформированно мнение о том, что установление CPU лимитов в k8s это своего рода антипаттерн, и что нужно ограничиться только высталвением CPU реквестов.

Но тут сразу возникает вопрос: не получится ли такой ситуации, что у меня на ноде появится процесс, который наплодит себе потоков, сожрёт все процессорное время ноды и не будет давать его другим контейнерам? Ответ: нет, такого не получится. В cgroupV2 существует параметр CPUWeight, который как раз включается в работу, когда на ноде начинается "борьба" за CPU ресурс. Например, у вас есть два потока, оба претендуют на процессорное время. У одного CPUWeight 100, у другого – 400. Тот, у которого 400, будет получать в 4 раза больше процессорного времени относительного того, у которого 100. В свою очередь параметр CPUWeight привязан к CPU реквестам, которые мы устанавливаем нашим контейнерам. Поэтому у нас получается, что в случае 100% загруженности CPU больше процессорного времени будут получать те процессы, которые его больше запросили в своих реквестах.

Более менее честно процессорное время при "борьбе за ресурсы" будет распределяться только если у контейнеров, между которыми это время распределяется, реквесты хотя бы больше 100m. Иначе будет получаться следующая картина.

(На ноде 16 CPU)

1. Пример: два пода со 100% потреблением проц времени. Реквесты: 100m и 1m.
2. Пример: два пода со 100% потреблением проц времени. Реквесты: 100m и 20m.

Всё!

Что такое optimized​

Optimized в нашем случае стоит переводить не как «оптимизированная», а скорее как «оптимальная». Так и поступили неизвестные переводчики сайта Fedora Project. Потому что слово «оптимизированный» намекает на производительность, но никакого ее прироста при запуске контейнеров на FCOS (Fedora CoreOS) в сравнении с другими дистрибутивами мы не получим.

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

• Linux, потому что, будем честны, запускать контейнеризованные приложения на Windows — это не то, чем вы хотите заниматься;
• Платформа для запуска контейнеров, например, docker или podman.

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

Fedora CoreOS зачастую используется для запуска Kubernetes кластеров. Собственно, для этого и была разработана. FCOS редко когда используют для того, чтобы запускать единичные контейнеры. Это основная система для OKD, а также апстрим для RHEL CoreOS, которая является дефолтной для OpenShift.

Теперь рассмотрим, какие основные фичи имеет FCOS, и подумаем, как они смогут облегчить нам жизнь в работе с контейнеризованными приложениями.

Иммутабельная система и транзакционные обновления​

Начну с самой интересной, на мой взгляд, особенности. FCOS использует систему rpm-ostree. Это своего рода git для вашей операционки. Разберемся подробнее, что это такое.

В основе лежит ostree — система контроля обновлений операционной системы, очень похожая на git. Вот как она работает. У вас есть базовый образ ОС, к примеру, последняя стабильная версия. Вам нужно установить на нее нужное программное обеспечение и сконфигурировать его. Вы это выполняете, тестируете и коммитите изменения. Тем самым вы делаете их резистентными к перезагрузкам системы, так как установленное, но незакомиченное ПО будет слетать после каждого ребута.

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

Обновления в ostree происходят транзакционно: последние два-три образа системы хранятся на диске. Именно за счет этого и можно быстро откатиться на них.

А почему просто не использовать git? Зачем эта git-подобная система? Дело в том, что git отслеживает далеко не все. К примеру, без его внимания остаются метаданные файлов: права, владелец, дата создания и т. д. Для git все это — user specific data, которая ему не нужна.

А теперь вернемся к rpm-ostree. Она дополняет ostree, встраивая пакетный менеджер dnf. По итогу мы получаем image-based систему с гибкостью package-based системы. Rpm-ostree позволяет наслаивать установленные юзером пакеты на базовый образ. То есть их установка через rpm-ostree создает новый коммит в ostree-дерево. Таким образом, поддерживается так называемый client-side layering. Соответственно, когда у вас появится новая версия базового образа и вы хотите до нее обновиться, вы, можно сказать, делаете git rebase. :)

Изначально rpm-ostree проектировалась именно для поддержки удобного client-side layering, но сейчас все стало сложнее. Теперь система реализует ряд других полезных функций. Например, во время установки пакетов она изолирует запускаемые скрипты в контейнерах, используя утилиту bubblewrap, чтобы они не влияли на работающую систему. Также поддерживается функционал native containers, который позволяет собирать базовый образ системы через Docker-файлы (подробнее об этом — чуть ниже).

Если ostree считается иммутабельной системой больше из-за ее принципа обновления, то rpm-ostree к этому добавила почти полностью read-only файловую систему. Вносить изменения вы можете только в /etc или /run, в которых хранятся конфигурационные файлы, а также в /var, в котором находятся все остальные данные приложений.

Вот что происходит с файлами внутри этих директорий при обновлении системы:

• /run приводится в первоначальное состояние, не сохраняя пользовательских изменений или добавленных юзером файлов с прошлого запуска. Оно и понятно, эта директория предназначена для добавления конфигурационных файлов, относящихся только к текущему запуску системы;
• /etc будет принимать новые изменения от обновлений (если они есть), но в то же время не будет трогать пользовательские изменения;
• /var никак не меняется.

Привычные директории типа /home — это симлинки на /var/home.

Автоматические background-обновления​

Система rpm-ostree позволяет организовать транзакционные обновления в фоновом режиме. То есть когда появляется обновление, система об этом узнает и устанавливает его. После перезапуска будет использован новый образ.

По дефолту FCOS поставляется с запущенным приложением-демоном Zincati. Оно отвечает за автоматические обновления и перезапуски системы. Zincati узнает о доступных апдейтах с помощью удаленного сервера Cincinnati, периодически запрашивая у него информацию. Cincinnati, можно сказать, подписывается на нужный образ системы и по запросу предоставляет граф обновлений. По нему и проходится Zincati (пример: FCOS Updates Graph).

Так как перезапуск системы — действие, которое теоретически может поломать (пусть даже временно) работу всего кластера, Zincati поддерживает несколько стратегий обновления:

• Immediate (default) — перезагружает систему сразу после установки обновления;
• FleetLock — использует стороннее решение, которое устанавливает максимальное количество одновременно обновляющихся машин. Машина пошла обновляться — забрала замочек, обновилась — отдала. Если замков нет, она ждет, когда появятся;
• Periodic — позволяет указать конкретные временные окна, в которые система должна перезагружаться. Например, 29 мая в 10 утра.

По информации с форума Fedora Project, команда Fedora планирует упростить этот процесс и убрать из схемы Cincinati. Разработчикам кажется, что сейчас процесс излишне усложнен. Планируется оставить только Zincati, предварительно улучшив его и сделав умнее.

Запуск системы на основе контейнер-образа​

Система rpm-ostree наследует часть кода библиотеки ostree-rs-ext, которая реализует функционал ostree native containers. Он позволяет создавать базовый образ системы на основе Docker-файлов.

Примеры:

# Перемещение библиотек, установленных в /opt (симлинк на /var/opt), в /usr
FROM quay.io/fedora/fedora-coreos:testing-devel
RUN mkdir /var/opt && \
    rpm -Uvh https://downloads.linux.hpe.com/repo/stk/rhel/7/x86_64/current/hp-scripting-tools-11.60-20.rhel7.x86_64.rpm && \
    mv /var/opt/hp/ /usr/lib/hp && \
    echo 'L /opt/hp - - - - ../../usr/lib/hp' > /usr/lib/tmpfiles.d/hp.conf && \
    ostree container commit

# Установка пакетов
FROM quay.io/fedora/fedora-coreos:stable
RUN rpm-ostree install kubernetes-client && ostree container commit

# Изменение boolean значения SELinux
FROM quay.io/fedora/fedora-coreos:stable
RUN setsebool -P -N container_manage_cgroup 1

Чтобы использовать в системе «сбилженный» и опубликованный базовый образ, достаточно выполнить rebase системы (rpm-ostree rebase ostree-unverified-registry:REGISTRY/IMAGE:VERSION) и перезапуститься.

Дополнительную информацию по этой теме вы можете найти в документации, а больше примеров — на GitHub.

Безопасность​

В целом из статьи понятны некоторые security-фичи, которые вытекают из факта использования rpm-ostree системы. Вот они:

• Иммутабельная файловая система;
• Изоляция скриптов, запускаемых при установке пакетов, в контейнеры;
• Ограниченный и контролируемый список установленных пакетов в базовом образе;
• Автообновления.

Отмечу, что один из фокусов команды Fedora заключается в том, чтобы сделать FCOS сконфигурированной по дефолту со всеми нужными политиками безопасности. Это необходимо для исключения ситуации, когда пользователь на старте может выбрать путь небезопасно настроенной системы.

Именно поэтому FCOS идет с предварительно установленным и настроенным SELinux. Правда, в базовом образе операционки не установлены некоторые дополнительные программы для него типа semanage, так как они зависят от python, которого в FCOS нет (по поводу зависимостей от python есть отдельная дискуссия на GitHub). Из-за этого управлять политиками SELinux может быть затруднительно, но вы все равно можете скомпилировать свои модули и установить их в систему.

Если вам все же нужен semanage, установите его вместе с питоном, используя пакет policycoreutils-python-utils:

sudo rpm-ostree install policycoreutils-python-utils 
... 
Added:
  checkpolicy-3.5-3.fc39.x86_64 
  libb2-0.98.1-9.fc39.x86_64 
  libgomp-13.2.1-7.fc39.x86_64 
  mpdecimal-2.5.1-7.fc39.x86_64 
  policycoreutils-python-utils-3.5-8.fc39.noarch 
  python-pip-wheel-23.2.1-2.fc39.noarch 
  python-unversioned-command-3.12.3-2.fc39.noarch 
  python3-3.12.3-2.fc39.x86_64 
  python3-audit-3.1.2-8.fc39.x86_64 
  python3-distro-1.8.0-6.fc39.noarch 
  python3-libs-3.12.3-2.fc39.x86_64 
  python3-libselinux-3.5-5.fc39.x86_64 
  python3-libsemanage-3.5-4.fc39.x86_64 
  python3-policycoreutils-3.5-8.fc39.noarch 
  python3-setools-4.4.3-1.fc39.x86_64 
  python3-setuptools-67.7.2-7.fc39.noarch

Так как мы все-таки говорим о container optimized системе, отмечу следующее. Благодаря политикам SELinux в FCOS есть дополнительная изоляция контейнеров от хоста. Ниже приведены примеры на данный момент уже закрытых с помощью SELinux дыр в безопасности runc:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-30465

Сама система в целом рассчитана на то, что большая часть юзер-софта будет запускаться в контейнерах. В сочетании с политиками SELinux это дает плюсик к безопасности.

Кстати, часто дыры в этой самой безопасности связаны с неправильным использованием памяти. Это так называемые «memory safety issues». Чтобы уменьшить количество связанных с ними багов, команда Fedora старается все чаще использовать в кодовой базе своих приложений языки Rust и Go.

Предустановленные инструменты для контейнеров​

В FCOS из коробки идут podman и moby-engine (docker). А зачем их два? Одновременно запускать контейнеры и в одном, и в другом не получится — это вызовет конфликты, да и смысла нет. Разработчики FCOS оставляют moby-engine только ради удобства пользователей, которым привычнее работать с docker cli. Цитата с недавней встречи разработчиков:

«When we started building Fedora CoreOS one of the things we wanted to do was keep Container Linux users happy. Users who wanted to continue to use docker could do so without issue. We've held to that principle for a long time. I would like to continue to ship it because I know there are good number of people who do use it».

Кстати, на этой встрече как раз обсуждалась идея выпиливания moby-engine из базового образа FCOS (подробности на GitHub). Основным мотивом была нехватка волонтеров и мейнтейнеров в команде Fedora. Именно из-за нее версия moby-engine в стабильной FCOS на момент написания статьи — 24.0.5, когда для docker-ce доступна версия 26.1.2.

Кроме того, иногда в рамках одного обновления FCOS происходят большие скачки версии moby-engine. Например, так было в переходе с версии 38.20231027.3.2 на 39.20231101.3.0: moby-engine подняли сразу с 20.10.23 до 24.0.5. По итогу этой встречи в документацию решили добавить инструкцию по замене moby-engine на docker-ce.

Сейчас, насколько я понимаю по репозиторию, идет работа по обновлению пакета moby-engine до 26.0.0. Но когда этот переход произойдет, неизвестно.

Гибкий деплой​

FCOS доступен для установки, по сути, на все платформы, которые вам только могут понадобиться. На ту же виртуалку в Selectel его можно установить с помощью образа для OpenStack.

Предварительно сконфигурировать систему во время первого запуска можно с помощью Ignition-конфигурации. Ignition — это машиночитаемый формат, который можно скормить системе при первом запуске, как Cloud-Init, и она примет вид, описанный в файле. В свою очередь, Ignition-конфигурация формируется путем транспиляции файла в формате Butane. Butane — это YAML-файлы, данные в которых описаны человекочитаемой Butane-схемой.

Соответственно, в файлах Butane вы описываете желаемый вид вашей системы. Вот небольшой пример Butane-конфигурации, которая добавляет юзера с ssh-ключом, создает сетевой интерфейс, указывает hostname и отключает Zincati:

variant: fcos
version: 1.5.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-ed25519 AA...
storage:
  files:
    - path: /etc/NetworkManager/system-connections/ens3.nmconnection
      mode: 0600
      contents:
        inline: |
          [connection]
          id=ens3
          type=ethernet
          interface-name=ens3
          [ipv4]
          address1=192.168.0.3/24,192.168.0.1
          dns=8.8.8.8;
          dns-search=
          may-fail=false
          method=manual
    - path: /etc/hostname
      mode: 0644
      contents:
        inline: fcos
systemd:
  units:
    - name: zincati.service
      enabled: false

Заключение​

Возвращаемся к вопросу, который и стал причиной написания этой статьи: почему Fedora CoreOS — это оптимальная ОС для контейнеров?

В целом все описанные выше фичи FCOS способствуют тому, чтобы ее можно было просто и удобно использовать для работы с контейнерами. В первую очередь, как основную систему для узлов Kubernetes-кластера. Коробочное решение защищено с помощью политик SELinux, система невелика с точки зрения количества пакетов, в ней предустановлены две протестированные платформы для запуска контейнеров: moby-engine и podman.

Последний пункт, кстати, в этой статье я называл одним из минимальных требований к «оптимальной» для контейнеров ОС. Но во время своих поисков я наткнулся на этот занятный комментарий одного из разработчиков CoreOS в треде про удаление moby-engine. Он говорит, что они хотели бы выпустить версию FCOS вообще без предустановленного container engine, чтобы юзеры сами могли выбрать, какой им нужен. Можно ли считать такой образ FCOS «container optimized»? Я думаю да, если доступные rpm-пакеты всех возможных container-платформ будут протестированы для него. ¯(ツ)/¯

Сразу хочется оговориться, что помимо описанных ниже алгоритмов и классов планирования в Linux также реализованы дополнительные алгоритмы, основывающиеся на энергопотреблении системы, на cpu capacity и тд. Они встроены в классы, о которых поговорим ниже, но их самих мы затрагивать в рамках этой статьи не будем.

Понятия задачи (task), потока (thread) и процесса (process)​

Начнем с базы. Task, thread и process – это, в принципе, достаточно близкие по смыслу понятия, но надо всё-таки разобраться, что каждое из них значит.

Когда вы запускаете приложение, в системе создаётся процесс (process), которому выделяется память на хранение исполняемого кода и других данных. В рамках этого процесса создаётся минимум один поток (thread). Именно среди потоков планировщики Linux и распределяют время процессора, а также решают, в какой очерёдности они будут выполняться. Задачей (task) можно назвать уже непосредственно сами инструкции, которые процессор получает и выполняет. Дальше по статье я буду время от времени называть потоки задачами или процессами, потому что в рамках контекста статьи они своего рода синонимы.

Важно также знать, что у процессов есть поле state, которое, как понятно по названию, показывает, в каком состоянии сейчас находится процесс. Состояний может быть несколько:

• Running или Runnable (R) – процесс в состоянии running прямо сейчас использует процессорное время, в свою очередь runnable процесс только ожидает его.
• Uninterruptible Sleep (D) – процесс ждёт результата операции ввода-вывода. Например, ждёт данные от диска. Такой процесс никак нельзя убить.
• Interruptible Sleep (S) – процесс ждёт какое-то событие и не потребляет процессорного времени. Пример: ввод из командной строки.
• Stopped (T) – процесс получил сигнал SIGSTOP или SIGTSTP и остановил свою работу. В этом состоянии процессу можно послать сигнал SIGCONT и запустить его снова.
• Zombie (Z) – процесс, который получил сигналы на завершение работы, и полностью её завершил – он больше не потребляет ресурсов системы, только PID идентификатор. Он ждет, когда его родительский процесс выполнит системный вызов wait, после этого Zombie исчезнет. Иногда этого может не происходить, в таком случае приходится дебажить родителя.

Всю информации о процессе можно достать из папки /proc/<PID>, где <PID> – это идентификатор процесса. Если вам нужно получить информацию в более “user friendly” виде, то воспользуйтесь утилитами top, htop, ps и тд.

Политики и классы​

У каждой задачи выставлена какая-то политика, которая определяет, как именно нужно планировать выполнение этой задачи, какие алгоритмы для этого использовать. В свою очередь классы это, по сути, реализации этих политик. Не у каждой политики есть свой личный класс, но все они реализованы в рамках какого либо класса. К примеру, в rt_sched_class реализованы 2 политики: SCHED_FIFO и SCHED_RR, а в dl_sched_class – только SCHED_DEADLINE.

Политика задачи определяется её приоритетом sched_priority, его можно найти в файле /proc/<PID>/schedstat. Сопоставляются приоритеты с классами следующим образом:

• sched_priority == 0 – класс "Deadline"
• sched_priority >= 1 && sched_priority <= 99 – класс "Real-Time"
• sched_priority >= 100 – класс "Fair"

Класс для “обычных” задач​

За распределение процессорного времени для задач с политиками SCHED_OTHER, SCHED_BATCH и SCHED_IDLE отвечает fair_sched_class, описанный в файле kernel/sched/fair.c. В нём с 2007 по 2023 год (с версии 2.6.23 до версии 6.6) использовался алгоритм "Completely Fair Scheduler" CFS, сейчас же это "Earliest Eligible Virtual Deadline First" EEVDF.

У “обычных” задач поле priority игнорируется, вместо него есть NICE, которое играет роль в планировании.

Про политики:

• SCHED_OTHER – Дефолтная политика, используется для абсолютного большинства задач.
• SCHED_BATCH – Тоже самое, что и SCHED_OTHER, только они не могут “смещать” другие (не SCHED_IDLE), уже запущенные задачи.
• SCHED_IDLE – Используется для задач с самым низким приоритетом, ещё ниже чем NICE +19. В теории такие задачи запускаются только когда в очереди нет других задач. На практике же может быть и такое, когда IDLE задача выполняется вместе с SCHED_OTHER задачей, однако при этом получает слишком мало процессорного времени.

"Completely Fair Scheduler” CFS​

Как можно понять по имени, основная цель планировщика CFS это максимально “честное” распределение процессорного времени среди всех требующих его процессов. CFS это, как нам говорит документация linux, моделирование “идеального многозадачного CPU”, который, если бы существовал, распределял время процессора примерно так: два runnable процесса, каждый получает по 50% процессорного времени.

В CFS все runnable процессы хранятся в red-black дереве, которое отсортировано по vruntime процесса, что является количеством процессорного времени в наносекундах, которое процесс использовал. Таким образом получается, что в левой части дерева находятся процессы, которые использовали меньше всего времени, а в правой части те, что больше всего. И когда CFS выбирает, какой задаче дать доступ к процессорному времени, он выбирает самую левую задачу в дереве, то-есть ту, которая получила его меньше всех.

Когда задача получает доступ к процессорному времени, она получает его на заранее предопределённый промежуток времени, называемый slice. Он может увеличиваться и уменьшаться в зависимости от NICE значения процесса. Таким образом, к примеру, чем меньше значение NICE, тем больше процессорного времени получит задача по сравнению с задачами, имеющими более высокое значение.

Несмотря на то, что CFS действительно хорошо справлялся с “честным” распределением времени процессора на все runnable процессы, у него были и серьёзные недостатки. Один из них это невозможность правильно работать с процессами, которые требуют время процессора, как можно скорее. Для того, чтобы подружить CFS с этой историей были внедрены так называемые latency nice патчи. Они добавляли новое значение latency-nice, которое было зеркально существующему nice значению, в том плане, что тоже имело ограничение от -20 до +19 и его понижение также, как и у nice, понижало толерантность к другим процессам. Если у нового процесса latency-nice был ниже, чем у того, который в текущее время работает в процессоре, то он мог заменить его. Таким образом задачи с низким latency-nice не получали больше процессорного времени, но получали право на его более быстрое выделение.

"Earliest Eligible Virtual Deadline First" EEVDF​

Peter Zijlstra посчитал, что для решения той же проблемы, что решают latency-nice патчи для CFS, есть более подходящий путь. Он предположил, что использование алгоритма EEVDF, представленного ещё в 1995 году, может больше подходить для этого и избавит планировщик от кучи «icky heuristics code» (полагаю, что по-русски это значит «говнокод»).

По названию этого алгоритма можно примерно догадаться, как он работает :). Процессору он отдаёт ту задачу, которая “имеет на это право” и у которой раньше всех наступает deadline. В принципе на этом всё. Только осталось разобраться, что вообще значит “имеет право”, и как рассчитывается этот загадочный deadline.

Начнём с параметра “eligible”. Имеет право или не имеет право определяется функцией vruntime_eligible в файле kernel/sched/fair.c, в комментарии к которой написано: “Entity is eligible once it received less service than it ought to have, eg. lag >= 0”. То есть задача “eligible” тогда и только тогда, когда она получила меньше процессорного времени, чем должна. В пример приводится неравенство lag ≥ 0, которое собственно это и значит, потому что lag – это разница между временем, что задача должна была получить, и тем, что она на текущий момент получила. Как это считается? Мы берём средний vruntime всей очереди и отнимаем от него vruntime задачи. Важно понимать, что и средний vruntime очереди и vruntime отдельной задачи у нас считаются, учитывая веса задач, которыми являются их NICE значения. Таким образом, благодаря механизму “eligibility” среди всех процессов “честно” распределяется время.

Теперь перейдём к понятию “deadline”. Deadline – это самое раннее время, до которого задача должна получить slice своего процессорного времени. Считается по формуле: vruntime + (slice / weight), соответственно чем больше вес задачи (зависит от NICE), тем раньше её deadline.

Все runnable процессы так же, как и в CFS хранятся в red-black дереве, однако отсортировано оно не по vruntime, а по deadline’у. Само дерево является “augmented”, то есть дополненным, и содержит в своих узлах не только deadline процесса, но и остальные его данные (в CFS также), в том числе и min_vruntime, который считается по формуле se->min_vruntime = min(se->vruntime, se->{left,right}->min_vruntime). Таким образом появляется возможность фильтровать дерево по “eligibility” и затем уже выбирать самый левый узел, то есть процесс с самым близким deadline’ом.

Класс для Real-Time задач​

rt_sched_class, описанный в файле kernel/sched/rt.c, распределяет процессорное время для задач с политиками: SCHED_FIFO, SCHED_RR – обе эти политики описаны в стандарте POSIX. Значение NICE у задач роли не играет, берётся во внимание только приоритет.

SCHED_FIFO (FIFO – First In First Out) берёт задачу с самым большим приоритетом и отдаёт на выполнение в процессор, пока она не заблокируется, не закончит своё выполнение или не будет смещена более приоритетной задачей.

Для SCHED_RR (RR – Round-Robin) справедливо всё то, что и для SCHED_FIFO, за исключением того, что он не позволяет задачам исполняться в процессоре “до победного”, ограничивая время их исполнения. Таким образом, задача, время выполнения которой больше или равно отведённому ей, будет отправлена в конец очереди для задач с таким же приоритетом.

Важно отметить, что так как Real-Time задачи имею больший приоритет, чем обычные, это приводит к тому, что любая новая runnable Real-Time задача смещает обычную running задачу (если такая есть, конечно).

Пользователю, для того, чтобы сделать какую-либу задачу “Real-Time”, нужно воспользоваться утилитой chrt.

chrt -f 10 -p 2445 # Выставляем задаче с PID 2445 
                   # политику SCHED_FIFO и приоритет 10

chrt -r 10 your_command # Выставляем задаче, выполняющей вашу команду, 
                        # политику SCHED_RR и приоритет 10

Класс для Deadline задач​

dl_sched_class, описанный в файле kernel/sched/deadline.c, распределяет процессорное время для задач с политикой SCHED_DEADLINE, используя для этого в связке два алгоритма: EDF “Earliest Deadline First” и CBS “Constant Bandwidth Server”. В этом классе у задач игнорируется приоритет и NICE значения, все задачи, благодаря CBS, выполняются “изолировано” друг от друга, то есть не пересекаются.

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

В рамках этого класса у задачи есть 3 параметра: runtime определяет сколько процессорного времени задача будет получать, period определяет, за какой период он его получит, и deadline, который рассчитывается с помощью CBS, устанавливает крайнюю отметку времени, до которой задача может выполняться, для того, чтобы она не пересекалась с другими задачами. Алгоритм EDF, в свою очередь, использует значение deadline для понимания того, какую задачу отдавать на выполнение процессору, выбирая всегда процесс с самым ранним deadline’ом.

Чтобы задать процессу “deadline“ политику, пользователю, также, как и в случае с “Real-Time” политиками, нужно воспользоваться утилитой chrt, но теперь ей, помимо приоритета, который всегда 0 для “deadline” задач, необходимо также указать в наносекундах period, runtime и deadline.

# В этом примере задача будет иметь гарантированные 5мс процессорного времени
# с периодом 16.6мс и с дедлайном 10мс
chrt -d --sched-runtime 5000000 --sched-deadline 10000000 \
    	    --sched-period 16666666 0 your_command

Источники​

• https://lwn.net/Articles/743740/
• https://lwn.net/Articles/743946/
• https://docs.kernel.org/scheduler/sched-design-CFS.html
• https://docs.kernel.org/scheduler/sched-deadline.html
• https://lwn.net/Articles/925371/
• https://lwn.net/ml/linux-kernel/20230306132521.968182689@infradead.org/
• https://www.cs.unc.edu/~anderson/teach/comp790/papers/posix-rt.pdf
• https://lwn.net/Articles/805317/

Что такое Pkl?​

Pkl (читается, как Pickle) – это, как я уже выше написал, ЯП специального назначения для создания конфигураций. Синтаксис напоминает HCL и Nginx, только с кучей вспомогательных функций.

Pkl поддерживает валидацию полей через проставленые типов, проверки типа if, циклы, функции, наследование и GET http запросы. Всё это в настолько примитивном виде, на сколько это возможно.

Перевести код на Pkl вы можете в JSON, YAML, XML и другие форматы. Он также может генерировать код на Go, Java, Kotlin и Swift, но в статьей это рассматривать не будем.

name = "Swallow"

job {
  title = "Sr. Nest Maker"
  company = "Nests R Us"
  yearsOfExperience = 2
}

{
  "name": "Swallow",
  "job": {
    "title": "Sr. Nest Maker",
    "company": "Nests R Us",
    "yearsOfExperience": 2
  }
}

Манифесты Kubernetes на Pkl​

Для примера я взял манифесты своего pet-проекта, которые включают в себя Deployment, Service и Ingress ресурсы, и всё переписал на Pkl.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: davy-page-blog
  namespace: davy
spec:
  selector:
    matchLabels:
      app: davy-page-blog
  template:
    metadata:
      labels:
        app: davy-page-blog
    spec:
      containers:
      - name: davy-page
        image: image:v0.0.81
        imagePullPolicy: IfNotPresent
        resources:
          ...
        readinessProbe:
          ...
        livenessProbe:
          ...
      imagePullSecrets:
        - name: vault-registry-secret

apiVersion: v1
kind: Service
metadata:
  name: davy-page-blog
  namespace: davy
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: davy-page-blog

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: davy-page-blog
  namespace: davy
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - davy.page
    secretName: davy-tls
  rules:
  - host: davy.page
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: davy-page-blog
            port:
              number: 80

Основная задача заключалась в том, чтобы взять за основу текущие манифесты, которые у меня использовались для поднятия одного стенда, и создать конфигурацию на Pkl, с помощью которой, я смогу легко генерировать манифесты для трех разных окружений: prod-type-1, prod-type-2 и beta-(0..999).

Для валидации конфигов уже есть готовый модуль pkl-k8s. Он содержит в себе типизированные объекты для ресурсов Kubernetes. Если вы будете добавлять в будущий k8s ресурс поля, которых там не должно быть, или будете корректным полям выставлять некорректные значения, то при сборке конфига получите ошибку.

По итогу у меня получился вот такой главный файл, который создаёт необходимые манифесты для стендов любого типа:

import "@k8s/K8sResource.pkl"
import "./DavyPageStand.pkl"

stand = new DavyPageStand.Stand {
  args = new {
    // Все аргументы, которые нужны берутся из ENV переменных.
    // Если их вдруг нет, то выставится либо дефолтное значение, либо null.
    type = read?("env:TYPE") ?? "blog"
    version = read?("env:VERSION") ?? "v0.0.81"
    id = read?("env:ID")
  }
}

output {
  value = new Listing<K8sResource> {
    stand.deployment
    stand.service
    stand.ingress
  }
  renderer = (K8sResource.output.renderer as YamlRenderer) {
    isStream = true
  }
}

Для гибкости, если вдруг нужно подредактировать, в полученных объектах, конкретные поля, можно сделать так (в моём понимаение это костыль, и так смысл есть делать, только если нужно прям супер срочно что-то починить и нет желания смотреть другие Pkl файлы):

...
value = new Listing<K8sResource> {
  (stand.deployment) {
    metadata {
      name = "test"
    }
    spec {
      template {
        spec {
          containers {
            // меняем образ только у контейнера с таким именем
            [[name == "davy-page"]] {
              image = "bruh"
            }
          }
        }
      }
    }
  }
  stand.service
  stand.ingress
}
...

Конструкция (object) { ... } обнозначает наследование. Так можно накладывать на какой-то существующий объект свои новые значения.

Этот главный файл ссылается на DavyPageStand.pkl, который объединяет файлы: DavyPageDeployment.pkl, DavyPageService.pkl, DavyPageIngress.pkl, каждый из которых в свою очередь отвечает за создание объектов для своего ресурса (для какого можно понять по названию).

import "@k8s/K8sResource.pkl"

import "./DavyPageDeployment.pkl"
import "./DavyPageService.pkl"
import "./DavyPageIngress.pkl"

const function getHost(type, id) = if (id != null) "pr-\(id).\(type).dev.davy.page" else if (type == "blog") "davy.page" else "p.davy.page"

class Args {
  type: String
  version: String
  id: String?
}

class Stand {
  args: Args
  _args = args // Костыль (про него будет ниже в статье)
  ammend_deploy: Mapping

  type_name = if (args.type == "blog") "davy-page-blog" else "davy-page-private"
  name = if (args.id != null) "\(type_name)-\(args.id)" else "\(type_name)"

  variant = if (args.id != null) "dev" else "prod"

  deployment = new DavyPageDeployment.DPL {
    args = new {
      resource_name = name
      version = _args.version
      labels {
        ["app-variant"] = variant
      }
    }
    ...ammend_deploy
  }

  service = new DavyPageService.SVC {
    args = new {
      resource_name = name
      labels {
        ["app-variant"] = variant
      }
    }
  }

  ingress = new DavyPageIngress.ING {      
    args = new {
      resource_name = name
      resource_host = getHost(_args.type, _args.id)
      with_auth = _args.id != null || _args.type == "private"
      labels {
        ["app-variant"] = variant
      }
    }
  }
}

import "@k8s/api/apps/v1/Deployment.pkl"
import "@k8s/api/core/v1/Probe.pkl"
import "@k8s/api/core/v1/ResourceRequirements.pkl"

const defaultProbe = new Probe {
  httpGet {
    scheme = "HTTP"
    path = "/img/logo.svg"
    port = 80
  }
  failureThreshold = 3
  timeoutSeconds = 1
}

const params {
  readinessProbe = (defaultProbe) {
    initialDelaySeconds = 10
    periodSeconds = 5
  }
  livenessProbe = (defaultProbe) {
    initialDelaySeconds = 15
    periodSeconds = 10
  }
  resources = new ResourceRequirements {
    requests {
      ["memory"] = "170Mi"
      ["cpu"] = "10m" 
    }
    limits {
      ["memory"] = "340Mi"
      ["cpu"] = "100m"
    }
  }
  image = "my-image"
  image_pull_secret = "vault-registry-secret"
}

class Args {
  resource_name: String
  version: String
  labels: Mapping<String, String>?
}

class DPL extends Deployment {
  hidden args: Args
  
  metadata {
    namespace = "davy"
    name = args.resource_name
    labels {
      ["app"] = "\(args.resource_name)"
      ...args.labels
    }
  }

  spec {
    selector {
      matchLabels {
        ["app"] = args.resource_name
      }
    }
    template {
      metadata {
        labels {
          ["app"] = args.resource_name
        }
      }
      spec {
        containers {
          new {
            name = "davy-page"
            image = "\(params.image):\(args.version)"
            imagePullPolicy = "IfNotPresent"
            resources = params.resources
            readinessProbe = params.readinessProbe
            livenessProbe = params.livenessProbe
          }
        }
        imagePullSecrets {
          new {
            name = params.image_pull_secret
          }
        }
      }
    }
  }
}

import "@k8s/api/core/v1/Service.pkl"

class Args {
  resource_name: String
  labels: Mapping<String, String>
}

class SVC extends Service {
  hidden args = Args

  metadata {
    namespace = "davy"
    name = args.resource_name
    labels {
      ["app"] = "\(args.resource_name)"
      ...args.labels
    }
  }
  spec {
    type = "ClusterIP"
    ports {
      new {
        port = 80
        targetPort = 80
        name = "http"
      }
    }
    selector {
      ["app"] = args.resource_name
    }
  }
}

import "@k8s/api/networking/v1/Ingress.pkl"

class Args {
  resource_name: String
  resource_host: String
  with_auth: Boolean
  labels: Mapping<String, String>?
}

class ING extends Ingress {
  hidden args: Args

  metadata {
    namespace = "davy"
    name = args.resource_name
    annotations {
      ["cert-manager.io/cluster-issuer"] = "letsencrypt-prod"
      when (args.with_auth) {
        ["nginx.ingress.kubernetes.io/auth-type"] = "basic"
        ["nginx.ingress.kubernetes.io/auth-secret"] = "private-basic-auth"
        ["nginx.ingress.kubernetes.io/auth-realm"] = "private zone"
      }
    }
    labels {
      ["app"] = "\(args.resource_name)"
      ...args.labels
    }
  }
  spec {
    ingressClassName = "nginx"
    tls {
      new {
        hosts { args.resource_host }
        secretName = "\(args.resource_name)-tls"
      }
    }
    rules {
      new {
        host = args.resource_host
        http {
          paths {
            new {
              path = "/"
              pathType = "Prefix"
              backend {
                service {
                  name = args.resource_name
                  port {
                    name = "http"
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

На выходе я получаю рабочий k8s манифест состоящий из трёх ресурсов:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: davy-page-blog
    app-variant: prod
  name: davy-page-blog
  namespace: davy
spec:
  template:
    metadata:
      labels:
        app: davy-page-blog
    spec:
      imagePullSecrets:
      - name: vault-registry-secret
      containers:
      - image: my-image:v0.0.81
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          periodSeconds: 10
          timeoutSeconds: 1
          initialDelaySeconds: 15
          httpGet:
            path: /img/logo.svg
            scheme: HTTP
            port: 80
        resources:
          requests:
            memory: 170Mi
            cpu: 10m
          limits:
            memory: 340Mi
            cpu: 100m
        name: davy-page
        readinessProbe:
          failureThreshold: 3
          periodSeconds: 5
          timeoutSeconds: 1
          initialDelaySeconds: 10
          httpGet:
            path: /img/logo.svg
            scheme: HTTP
            port: 80
  selector:
    matchLabels:
      app: davy-page-blog
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: davy-page-blog
    app-variant: prod
  name: davy-page-blog
  namespace: davy
spec:
  ports:
  - port: 80
    name: http
    targetPort: 80
  type: ClusterIP
  selector:
    app: davy-page-blog
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  labels:
    app: davy-page-blog
    app-variant: prod
  name: davy-page-blog
  namespace: davy
spec:
  ingressClassName: nginx
  rules:
  - host: davy.page
    http:
      paths:
      - path: /
        backend:
          service:
            port:
              name: http
            name: davy-page-blog
        pathType: Prefix
  tls:
  - secretName: davy-page-blog-tls
    hosts:
    - davy.page

Проблемы​

Есть несколько проблем, с которыми лично я столкнулся, во время работы с Pkl.

1. Указание ключей объектам​

Начну с самого бесячего. Если вы хотите полю в объекте назначить переменную с таким же названием – вы получите Stack Overflow. Потому что Pkl будет подставлять вашу переменную вместо и ключа, и значения.

arg = "test"

object = new MyObject {
  arg = arg
}

Чтобы этого избежать, приходится придумывать костыли:

_arg = "test"

object = new MyObject {
  arg = _arg
}

2. Расширения для IDE​

Лично я пользуюся VSCode и для него пока есть только расширение, раскрашивающее синтаксис, и не более. Никаких подсказок нет. Для IntelliJ IDEA вроде как есть что-то получше, но я этого не проверял.

Расширение для VSCode, к тому же, не устанавливается из вкладки "Extensions", а скачивается отдельным файлом из гитхаба) Это не сильный минус, просто лишний раз показывает на насколько ещё молод Pkl.

3. Типизация​

Вы не можете через тип указать, что такое-то поле должно быть конкретной строкой, или одной из строк (Пример из TS: let a: "string" | "string1"). Такого можно добиться, но только через if, что не очень удобно.

4. Глобальные переменные​

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

Есть module.<var> переменные, но они относятся только к контексту одного файла.

Вы также можете задавать различные properties через cli -p name=value. Они будут доступны всем файлам в рамках одного билда, но это всё равно будет статичная переменная. Тоже самое про ENV.

5. Http запросы​

Из HTTP запроов есть только GET, и из него вы можете только raw текст вытащить и в таком виде где-нибудь использовать. То-есть достать с запроса JSON, и обращаться к конкретным полям вы не сможете.

Вывод​

C Pkl'ом интересно работать и уже можно, как мне кажется, начинать активно практиковаться в нём в своих pet-проектах. Но завозить его в коммерческую разработку пока всё-таки рановато. Это связано не только с выше перечисленными проблемами, но также с отсутствием стабильной версии: каждое новое минорное обновление может принести существенные изменения в язык, из-за чего потребуется значительная адаптация существующих Pkl-файлов для обновления версии.

Небольшая теоретическая часть​

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

Сетевые Namespace'ы (netns)​

Network Namespace в Linux – это изолированная среда сетевых ресурсов. У неё свои ip-адреса, таблицы маршрутизации, firewall (о нём ниже) и так далее.

Они полезны, когда, например, у вас есть две виртуальные машины, которые вы хотите связать друг с другом, но изолировать от других сетей. Ну, или если вам нужно сделать тоже самое, но с контейнерам :).

Виртуальные сетевые интерфейсы​

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

Мы будет использовать loopback (или lo или localhost), veth и bridge, поэтому про них поподробнее.

• loopback (localhost) – Предоставляет возможность обмена трафиком в пределах самого устройства.
  • Используется для внутренней коммуникации приложений и тестирования.
  • Доступен по адресам 127.0.0.1 - 127.255.255.255.
• veth (Virtual Ethernet) – Виртуальный ethernet кабель: связывает 2 точки виртуальной сети и делает возможным передачу трафика между ними.
• bridge – По сути, это виртуальный switch.

Firewall​

Firewall используется для фильтрации трафика, как входящего, так и исходящего. Он может иметь вид физического устройства или виртуальной логической реализации. Мы будем использовать второе для дополнительной изоляции сетевых namespace'ов.

NAT​

NAT или Network Address Translation – это технология преобразования внутренних ip-адресов во внешний, и наоброт. Например, когда вы подключены к одному Wi-Fi с телефона и компьютера, на обоих устройствах будет единый внешний ip-адрес. NAT будет менять у входящего трафика ip-адрес роутера на внтуренний ip-адрес устройста, которому адресованы пакеты. И наоборот, ip-адрес у исходящих пакетов будет изменён на ip-адрес роутера.

Нужно всё это для экономии публичных ip-адресов, так как их количество сильно ограничено (около 4.3 миллиардов, из которых 81% уже назначены или зарезервированы).

Что делает Docker?​

Docker для каждого контейнера создаёт сетевой namespace (netns), и если вы не указали при создании контейнера сеть, к которой его надо подключить, то контейнер подключится к дефолтной сети (которой под капотом является bridge) парой veth интерфейсов. Это нужно для того, чтобы по умолчанию контейнеры могли друг с другом общаться.

Но только этого было бы недостаточно. Для отправки ip пакетов контейнеры должны знать, какой узел будет начальной точкой в построении маршрута до других контейнеров, подключённых к той же docker-сети, то есть bridge'у. Этой начальной точкой (gateway'ем) становится сам bridge, к которому подключен контейнер. То есть выглядит это как-то так: "Для трафика, отправленного на ip-адреса, которые находятся в подсети 172.17.0.0/16, задай gateway 172.17.0.1".

Для того, чтобы у контейнеров был доступ в интернет, Docker добавляет в NAT правила подмены ip-адреса для пакетов, которые отправляются из bridge интерфейсов docker-сетей. Это нужно, чтобы ip-адреса контейнеров менялись на ip-адрес выходного интерфейса (или ip-адрес хоста), через который строятся маршруты в интернет. Также каждому контейнеру добавляется дефолтный gateway (шлюз) в таблицу маршрутизации, чтобы пакеты для всех адресов отправлялись через bridge интерфейс, так как у него есть доступ к сети хоста.

Помимо этого Docker добавляет в firewall правила, запрещающие перенаправление трафика из одной docker-сети в другую для их изоляции друг от друга.

Когда вы публикуете порт из контейнера -p <внешний порт>:<внутренний порт> внутренний порт становится доступен на локальной сети хоста. Сейчас по дефолту docker для этого держит процесс "docker-proxy", который слушает нужные порты и перенаправляет на адрес нужного контейнера, и его внутренний порт. Это ненужное legacy, которое будет скоро полностью удалено из Docker в пользу hairpin NAT, но пока его можно только вручную отключить, добавив демону флаг --userland-proxy=false.

Практическая часть​

Создадим виртуальную сеть с доступом в интернет и выведем из неё в сеть хоста TCP порт 8000, который будет доступен через 127.0.0.1 и другим машинам в нашей сети (аналог docker -p <внешний порт>:<внутренний порт>).

Шаг #1 – Создаём network namespace​

Начнём с создания netns и запуска в нём простого питоновского http-сервера.

# Создаём netns c именем "red"
ip netns add red
# Задаём loopback интерфейсу Ipv4 адрес, так как по дефолту он не задан
ip -n red addr add 127.0.0.1/8 dev lo 
# Включаем loopback интерфейс
ip -n red link set lo up

# Запускаем http-сервер в рамках нового netns
ip netns exec red python3 -m http.server

Мы можем запрашивать у сервера что-либо только изнутри netns (ip netns exec red curl 127.0.0.1:8000). Пока он полностью изолирован.

Шаг #2 – Создаём bridge интерфейс​

Теперь нам нужно создать тот самый bridge интерфейс и подключить к нему ранее созданный netns red.

Помимо этого мы также зададим ip-адреса для наших netns и bridge вместе с указанием подсети, которая должна у них совпадать.

# Создаём bridge интерфейс с именем br0
ip link add br0 type bridge
# Задаём bridge интерфейсу ip-адрес 10.100.0.1. 
# При этом также указывая, что первые 24 бита 
# предназначены для идентификации сети, то есть часть "10.100.0".
ip addr add 10.100.0.1/24 dev br0
# Включаем интерфейс br0
ip link set br0 up

# Создаём пару veth интерфейсов с именами red0 и red0.br0
ip link add red0 type veth peer name red0.br0

# Подключаем один из veth интерфейсов к bridge'у и включаем его
ip link set red0.br0 master br0
ip link set red0.br0 up

# Второй veth устанавливаем для нашего red netns
ip link set red0 netns red
# Устанавливаем ему ip-адрес и включаем
ip -n red addr add 10.100.0.2/24 dev red0
ip -n red link set red0 up

Теперь с сети хоста можно пинговать netns и отправлять запросы http-серверу.

ping 10.100.0.2

curl 10.100.0.2:8000

ip netns exec blue ping 10.100.0.2
ip netns exec red ping 10.100.0.3

Шаг #3 – Необходимые системные параметры​

Чтобы всё у нас корректно работало нам нужно поменять два системных параметра:

1. net.ipv4.ip_forward – ip port forwarding нужен для того, чтобы можно было перенаправлть трафик между интерфейсами.
2. net.ipv4.conf.<interface>.route_localnet – route_localnet=1 разрешает перенаправления трафика на локальные сети. В нашем случае нам нужно разрешить это для нашего bridge интерфейса.

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.br0.route_localnet=1

Шаг #4 – Даём доступ в интернет из network namespace​

Нужно добавить в таблицу NAT в iptables правило, которое применяет ко всем пакетам с исходными адресами нашей подсети bridge действие подмены ip-адреса на ip-адрес интерфейса, через который пакеты прошли (в нашем случае на ip-адрес интерфейса eth0). Вы должны подставить вместо eth0 имя вашего основного сетевеого интерфейса с доступом в интернет.

Также через тот же iptables необходимо добавить правила, разрешающие forward трафика из нашего основного сетевого интерфейса в bridge интерфейс и наоборот, в таблицу FILTER.

И наконец, добавить дефолтный gateway для netns, чтобы по умолчанию пакеты, адресованные во внешний интернет, шли через адрес bridge интерфейса.

# Правило для таблицы NAT
iptables -t nat -A POSTROUTING -s 10.100.0.0/24 -o eth0 -j MASQUERADE

# Правило для таблицы FILTER (firewall)
iptables -A FORWARD -o eth0 -i br0 -j ACCEPT
iptables -A FORWARD -i eth0 -o br0 -j ACCEPT

# Для нашего netns'а задаём дефолтным gateway'ем наш bridge
ip netns exec red ip route add default via 10.100.0.1

Пробуем пропинговать внешний ip-адрес:

ip netns exec red ping 8.8.8.8

Шаг #5 – Выводим TCP порт в сеть хоста​

На этом этапе мы добавим возможность стучать в наш http-сервер через http://localhost:8000 и вместе с этим сделаем возможным обращаться к нему машинкам извне, то есть другим реальным компьютерам, которые подключены к вашей приватной сети, или, если у вас напрямую подключение к публичной сети, тогда вообще для всех компьютеров в интернете.

### Правила для таблицы NAT

# Для пакетов извне (с других компьютеров) (относится к цепочке PREROUTING) добавляем правило, 
# которое для всех пакетов, адресованных нашей локальной сети по tcp порту 8000,
# меняет destionation адрес на адрес нашего namespace'а.
iptables -t nat -A PREROUTING -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 8000 -j DNAT --to-destination 10.100.0.2:8000

# Для пакетов, сгенерированных хостом (относится к цепочке OUTPUT), добавляем правило, 
# которое для всех пакетов, адресованных нашей локальной сети по tcp порту 8000,
# меняет destionation адрес на адрес нашего namespace'а.
iptables -t nat -A OUTPUT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 8000 -j DNAT --to-destination 10.100.0.2:8000

# Добавляем действие MASQUERADE, которое применяется к пакетам,
# проходящим через интерфейс br0
# и которые были отправлены с локальной сети (то есть прошедшие через цепочку OUTPUT).
# MASQUERADE заменит их ip-адрес на ip-адрес шлюза,
# через который они покинули сеть, в нашем случае на ip-адрес br0.
iptables -t nat -A POSTROUTING -o br0 -m addrtype --src-type LOCAL -j MASQUERADE

# Добавляем действие MASQUERADE ко всем TCP пакетам 
# с портом 8000, адресованным локальной сети.
# Нужно для пакетов, пришедших от других компьютеров (вышедших из цепочки PREROUTING). 
iptables -t nat -A POSTROUTING -m addrtype --dst-type LOCAL -p tcp -m tcp --dport 8000 -j MASQUERADE

### Правила для таблицы FILTER (firewall)

# Разрешаем роутинг, пакетам проходящим через bridge интерфейс, которые относятся к установленным соединениям.
iptables -A FORWARD -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Разрешаем роутинг пакетам, не входящим с интерфейса bridge и адресованным этому интерфейсу по TCP порту 8000. 
iptables -A FORWARD -d 10.100.0.2/32 ! -i br0 -o br0 -p tcp -m tcp --dport 8000 -j ACCEPT

# Разрешаем трафик, который приходит с bridge интерфейса
iptables -A FORWARD -i br0 -j ACCEPT

Теперь можно попробовать постучаться в наш http-сервер из сети хоста:

curl 127.0.0.1:8000

И также поотправлять в него запросы с других машин через ip-адрес хоста:

# замените ip на свой x)
curl 192.168.1.15:8000

Всё!​

По итогу мы получили:

1. http-сервер, запущенный в изолированном сетевом пространстве.
2. Доступ к этому серверу по порту 8000 из loopback (localhost) интерфейса хоста.
3. Перенаправление пакетов от других машин по tcp порту 8000 в наш http-сервер.

Спасибо за чтение :)

Как это работает и для чего вообще нужно?​

Часто бывают случаи, когда нужно обернуть веб-сервер в дополнительный слой защиты, которым может стать базовая http аутентификация.

По сути вся базовая http аутентификация заключается в добавлении клиентом к запросу хедера Authorization со строкой Basic $credentials, где $credentials это закодированные в base64 логин и пароль в формате login:password. Пример полного хедера: Authorization: Basic YWRtaW46dGVzdA==.

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

После ввода браузер запомнит учетные данные для этого сайта и в запросы всех остальных ресурсов будет автоматически помещать логин и пароль, которые вы ввели при заходе. Но если на один из запросов вернётся статус код 401 Unauthorized – придётся вводить логин и пароль заново.

Как этим пользоваться в nginx?​

Для того, чтобы включить базовую аутентификацию в nginx для всего виртуального сервера достаточно в контекст server добавить следующие директивы:

auth_basic "auth"; # обозначает защищаемую область. 
                   # Также должен выводиться пользователю в окне ввода 
                   # логина и пароля, но лично ни разу такого не видел)
auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

В auth_basic_user_file нужно указать путь до файла, в котором будут указаны учетные данные для доступа. Файл должен быть создан при помощи утилиты htpasswd от Apache. Подробнее читать тут.

Для отключения базовой аутентификации для конкретных ресурсов достаточно добавить следующий блок в location.

auth_basic off;

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

На что следует обратить внимание​

И так, существуют варианты конфигураций, при которых включение или отключение basic auth работать не будет.

1. Использование с директивой return​

Эта директива сработает вне зависимости от того, включена или выключена базовая аутентификация.

auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

# всегда будет возвращать 200, несмотря та то, 
# что локейшон наследует базовую аутентификацию
location = /test {
  return 200 "success";
}

2. Использование с директивой rewrite​

Надо понимать, что rewrite перепишет ваш урл и направит на другой локейшон, и если в этом локейшоне не отключен auth_basic, то у клиента всё равно запросит логин и пароль.

Но в сочитании с директивой proxy_pass переписанный локейшон сразу перейдёт в проксю, и, соответственно, запроса на аутентификацию не будет (если у ресурса, который указан в proxy_pass нет своей аутентификации. Смотреть в пункте 3). Тоже самое с try_files – переписанный урл уйдёт в папку статики и базовая аутентификация не запросится.

auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

# Перебросит на location /todos, но так как у todos 
# не отключена базовая аутентификация, то /link будет её запрашивать
location /link {
  auth_basic off;
  rewrite ^/link/(.+?)$ /todos/$1 break;
}
location /todos {
  proxy_pass https://jsonplaceholder.typicode.com;
}

# Перепишет урл и отправит его в проксю. Базовая 
# аутентификация не будет запрошена.
location /rewrited_todos {
  auth_basic off;
  rewrite ^/link/(.+?)$ /todos/$1 break;
  proxy_pass https://jsonplaceholder.typicode.com;
}

auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

root /usr/share/nginx/html;

# Перепишет урл и отправит его в папку 
# статики за файлом. Базовая 
# аутентификация не будет запрошена.
location /static {
  auth_basic off;

  rewrite ^/static/(.+?)$ /$1 break;
  try_files /$uri =404;
}

3. Использование с директивой proxy_pass​

Тут особо говорить нечего. Просто помните, что бэкенд, на который ведёт проксипас, может быть скрыт под своей базовой аутентификацией.

4. Использование с директивой error_page​

Директива отвечает за обработку ошибок и переброс на нужную fallback-страничку.

# На все перечисленные ошибки nginx будет возвращать 
# error.html страничку из директории со статикой.
error_page 400 403 404 500 501 502 503 504 /error.html;

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

auth_basic "auth";
auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

error_page 400 403 404 500 501 502 503 504 /error.html;

# При запросе несуществующего ресурса (например /todos/2223424), вернётся 404, 
# которая обработается директивой error_page и вернёт error.html 
# для которого включена basic auth.
# Соответственно и этот локейшон в таком случае запросит аутентификацию.
location /todos { 
  auth_basic off;

  proxy_ssl_server_name on;
  proxy_intercept_errors on;
  proxy_pass https://jsonplaceholder.typicode.com;
}

5. Использование с директивой try_files​

Используя try_files смотрите, куда вы отправляете nginx за статикой. Вы можете создать локейшон с auth_basic off и try_files, который будет доставать статику из защищённого базовой аутентификацией контекста, и в таком случае отключение basic auth в вашем локейшоне работать не будет.

auth_basic "auth";
auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

root /usr/share/nginx/html;

# Базовая аутентификация все равно будет запрашиваться,
# так как try_files будет запрашивать 
# файлы у рутовой директории, которая защищена basic auth.
location ^~ /htmls {
  auth_basic off;

  rewrite ^/htmls/(.+?)$ /$1 break;
  try_files /$uri =404;
}

Как это работает?​

Клиент генерирует OTP для нужного пользователя и ip-адреса, далее обычным ssh username@host подключается к серверу. Сгенерировать ключ можно напрямую через vault, используя cli, API или веб-интерфейс, или через вашу внутреннюю систему, которая сама будет дёргать vault API и создавать OTP.

Когда SSH-сервер получает запрос на аутентификацию, он вызывает PAM (Pluggable Authentication Modules) модуль, который в процессе выполняет внешнюю команду. Этой внешней командой является vault-ssh-helper, который, в свою очередь, стучится в ваш Vault-кластер для проверки токена, отправленного клиентом. Если всё ок, то доступ предоставляется, а токен инвалидируется.

vault secrets enable ssh

vault write ssh/roles/otp_role \
    key_type=otp \
    default_user=worker \
    allowed_users=worker, worker2 \
    cidr_list=10.10.10.10/32

tee test.hcl <<EOF
path "ssh/creds/otp_role" {
  capabilities = ["update"]
}
EOF

vault policy write otp-polcy ./test.hcl

vault token create -policy=otp-polcy

Key                  Value
---                  -----
token                hvs.CAESIG1_CrngaECzf6yvTDBgUZz2Lt-mYfdZXogrsiV0ulH1Gh4KHGh2cy4bPmFmN24xNVM5cnBqbFNLTUdpd1JDcTM
token_accessor       n76E8Bc8P9SyPLpVZa2EoWGq
token_duration       768h
token_renewable      true
token_policies       ["default" "otp-polcy"]
identity_policies    []
policies             ["default" "otp-polcy"]

wget https://releases.hashicorp.com/vault-ssh-helper/0.2.1/vault-ssh-helper_0.2.1_linux_amd64.zip

unzip -q vault-ssh-helper_0.2.1_linux_amd64.zip -d /usr/local/bin

sudo chown root:root /usr/local/bin/vault-ssh-helper

sudo chmod 0755 /usr/local/bin/vault-ssh-helper

sudo mkdir /etc/vault-ssh-helper.d

sudo tee /etc/vault-ssh-helper.d/config.hcl <<EOF
vault_addr = "VAULT_ADDR"
tls_skip_verify = false
ca_path = "CA_CRT_PATH"
ssh_mount_point = "ssh"
allowed_roles = "*"
EOF

# на всякий случай бэкапим её
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.orig

auth requisite pam_exec.so quiet expose_authtok log=/var/log/vault-ssh.log /usr/local/bin/vault-ssh-helper -config=/etc/vault-ssh-helper.d/config.hcl
auth optional pam_unix.so not_set_pass use_first_pass nodelay

# на всякий случай бэкапим её
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

KbdInteractiveAuthentication yes
UsePAM yes
PasswordAuthentication no

sudo systemctl restart sshd

vault login $TOKEN

vault write ssh/creds/otp_key_role ip=$IP_ADDRESS

Key                Value
---                -----
lease_id           ssh/creds/otp_key_role/yZaiE4bRiVUVvc6LetQDtDmS
lease_duration     768h
lease_renewable    false
ip                 10.10.10.10
key                edcf6837-902f-43c6-9e54-c8c26ab80ff3
key_type           otp
port               22
username           username

ssh username@10.10.10.10

Нюансы​