Накидайте задачек по Kubernetes

Вот это вот всё, но под Istio.

Задачка по Kubernetes: опишите свои навыки работы с кубером так, чтобы вам прислали офер.

Описывать можно только в yaml.

Сделай, чтобы всё было зашибись.

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

Сделай чтобы у тебя в конфиге деплоя было подключение и пул логинов, а в под при старте попадала конкретная пара.

man курица и яйцо

Ну, он же не сказал «научитесь работать». Он сказал «опишите навыки». Так что никакого замкнутого круга нет.

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

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

Возможные причины и признаки:

Сфокусированность на себе:

Разговоры ведутся вокруг его тем, планов и интересов.

Игнорирование ваших вопросов:

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

Удобство: Он пишет только тогда, когда ему это удобно, или когда ему что-то нужно.

Отсутствие планов:

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

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

Ты что-то не туда поехал :) У тебя две (и более) машин, на каждом висит два (и более контейнера) нужно сделать так чтобы они (те программы что крутятся в разных контейнерах, на разных физических тачках) видели друг друга по localhost:port, в мир же они смотрят через nginx прокси, если то требуется (Вспомнилось из одного чата)

Физически несколько независимых контейнеров, находящихся на нескольких независимых машинках или виртуалках, но работающие как в одной сети на одной тачке и где-то сбоку наружу торчит nginx который пробрасывает 443 порт в эту межтачковую локалку на 4480

Гы. А давайте. Задача:

Есть микросервис Counter. Он развёрнут в Kubernetes с replicas = N.

Требуется:

• при каждом HTTP-запросе возвращать уникальное целое число
• числа должны быть строго монотонно возрастающими
• без пропусков

сервис должен быть:

• stateless
• масштабируемым
• отказоустойчивым
• без внешних сервисов (БД, Redis, Kafka и т.п.)

Разрешено использовать только возможности Kubernetes.

Ты что-то не туда поехал :) У тебя две (и более) машин, на каждом висит два (и более контейнера) нужно сделать так чтобы они (те программы что крутятся в разных контейнерах, на разных физических тачках) видели друг друга поlocalhost:port, в мир же они смотрят черезnginxпрокси, если то требуется (Вспомнилось из одного чата)

Физически несколько независимых контейнеров, находящихся на нескольких независимых машинках или виртуалках, но работающие как в одной сети на одной тачке и где-то сбоку наружу торчит nginx который пробрасывает 443 порт в эту межтачковую локалку на 4480

У меня уже так 2 деплоя работают.

Пока что через nodeport Там vuejs(front) к fastapi(back) обрашается и ip и port

Для них сделаны helm-чарты и через argo-cd они из github в kubernetes поподают.

Далее для них планирую L2 балансировшик mettallb или openlb так как нужны разные IP адреса .

Ну, значит слабо я предложил, но на этом мои полномочия всё.

Кубовый etcd считается за внешнюю БД? И что там с рбаком? =)

Можно использовать только официальные API Kubernetes. Насколько я помню доступ к etcd к нему не относится.

RBAC - можно.

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

К остальным: ну что же вы, девопсы, нападайте :)

Нету у этой задачи решения при поставленных условиях

Нету у этой задачи решения при поставленных условиях

Я специально поставил условие задачи таким образом чтобы те кто не знает кубер и пытаются решить задачу используя нейронные сети (chatgpt/claude/etc) получили неверный ответ что задача нерешаема.

Какую нейронку использовали? (я без осуждения, используйте что хотите).

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

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

Если вы считаете что знаете решение, то вы не пробовали как следует его сломать

Вот тебе задачка: удалить kubernetes. Вторая задачка: выключить систему.

Так есть же etcd concurrency API Reference . (отмазка: сам не трогал).

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

блокировка нужна между репликами, чтобы исключить классический race condition, чтобы пока одна реплика пишет, никто больше не читал. а в целом на гошке с go-client такое наговнякать за час можно :) с сильными ограничениями по rps, конечно же, с кучей возможных проблем, но удовлетворяющий условиям задачи

Впрочем, если разрешить прямой доступ к etcd, то это не спортивно.

Можно так: есть cm содержащий текущее число и confimaps вида lock-$pod-name, используемые для запроса на блокировку.

1. pod создаёт cm lock-blah-blah.

2. pod читает список cm lock-*.

3. если список не пуст, ждёт.

4. когда список пуст, значит можно работать. Читает текущее число, пишет увеличенную версию.

5. удаляет lock-blah-blah.

без пропусков

С точки зрения клиента нириальна положившись лишь на один простой запрос.

С точки зрения клиента нириальна положившись лишь на один простой запрос.

Ответ на запрос либо HTTP 200 и значение счетчика, либо HTTP 503 Service Temporary Unavailable.

Только lock-$pod-name — плохо, потому что имя пода случайно, лучше lock-$deployment-name, но в целом да, выглядит как рабочий вариант. А во втором конфигмапе само значение хранить, которое потом инкрементить и отдавать.

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

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

На вопрос: сколько нужно девопсов чтобы забороть обезъяну ответ - больше чем есть на этом форуме. Зато эникеи в соседних темах периодически гнут пальцы какие они девопсы и как они важны. Но стоит чуть копнуть и - кек.

Только George показал что он действительно знает по теме и имеет какой-то опыт, для него я и напишу решение.

lock-$deployment-name

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

если во время попытки удалить лок

Значит pod будет удалять блокировку или умрёт пытаясь. Система в это время работать, конечно, не будет.

его вообще убили еще до того, как он смог удалить

А для этого имя блокировки включает имя pod’а. Тогда Cronjob может проверить отсутствие осиротевших блокировок (или почистить ненужные).

можно ж завести условный конфигмап

Прекрасно, вы на правильном пути, используйте объект ConfigMap. Это половина решения.

Вы также правильно поняли что нужен механизм координации. Это вы нагуглите со времением, поэтому не вижу смысла тянуть дальше - для координации можно использовать паттерн Leader Election взяв объект Lease и использовать его через стандартный Kubernetes Lease API.

В итоге мы имеем масштабируемость и Stateless на уровне подов, ведь состояние живет только в ConfigMap (часть Kubernetes), Lease API обеспечивает то что только лидер инкреминирует. Отказоустойчивость обеспечивает паттерн Leader Election - при падении пода с лидером происходит выбор нового.

я при ответе вообще не гуглил :) ну и ии тоже мимо. но и на полном серьезе чуть лениво решение расписывать. в отношении именно веб-сервера я бы не стал Leader Election использовать — конечно же, я знаю, что это и пользовался в нужной ситуации — а просто бы сделал лок на основе соседней конфигмапы/аннотации на текущей конфигмапе/любом другом решении, которое придет мне в голову на момент реализации. ну и да, я не девопс =)

ну и да, я не девопс =)

Я и не думал о вас плохо ) Написал только что вы разбираетесь в теме кубера. Я тоже не девопс.

Вы - справились. Девопсы - не справились.

просто бы сделал лок на основе соседней конфигмапы/аннотации на текущей конфигмапе/любом другом решении, которое придет мне в голову на момент реализации

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

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

Я к тому, что ответ сервер отдал а он до клиента не доехал. Итого на клиенте будут «дырки».

Я с Пубернетис не знаком. Но решение не особо понял. Собственно два вопроса:
1. Leader Election. У тебя только лидер может генерировать следующее число? В чем тогда масштабируемость?
2. Как я понял ConfigMap не рассчитан, чтобы туда много писали. Предполагается писать туда из лидера при каждом инкременте? Опять вопрос к производительности и масштабируемости.

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

1. Leader Election. У тебя только лидер может генерировать следующее число? В чем тогда масштабируемость?

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

2. Как я понял ConfigMap не рассчитан, чтобы туда много писали. Предполагается писать туда из лидера при каждом инкременте? Опять вопрос к производительности и масштабируемости.

Обновляется всего один ключ при каждом запросе.

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

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

Ну я ваще не девпупс. Но на промпт поглядеть любопытно.

Слушай, вот ты крут, но почему звезда только одна и та погашена?

Но на промпт поглядеть любопытно.

«Попробуй решить эту задачу с помощью объектов ConfigMap и Lease».

После этого сеть понимает что можно избежать нарушения САР-теоремы создав единую точку обновления на уровне выше чем поды оставив их таким образом stateless (что и требовалось по задаче).

Слушай, вот ты крут,

Я не крут, я php-макака вооруженная логикой.

но почему звезда только одна и та погашена?

Я крымчанин, поэтому органически не переношу визг. В итоге ответы удаляются со сносом скора от -7 до -21. Не считаю что количество звезд на ЛОРе является показателем чего бы то ни было важного.

Закинул твой оригинальный пост гопнику, и он сразу выдал ConfigMap как один из вариантов.

❌ 1. Atomic counter через Kubernetes API (CRD / ConfigMap / Annotation)

Идея:

хранить число в ConfigMap или CRD

при запросе:

read → increment → write

Почему не работает:

Kubernetes не гарантирует линейризуемость read-modify-write

race conditions при нескольких репликах

optimistic locking → конфликты → ретраи → пропуски

API Server — не high-throughput счётчик

при падении между read и write — число потеряно

👉 максимум: eventually consistent, но не «без пропусков».

и он сразу выдал ConfigMap как один из вариантов.

и сразу же:

Почему не работает:

Именно это я и имел ввиду.

-=-

DevOps | Тесты

-=-

Первый день полёта в OC Talos

Составил список основных команд:

• talosctl get links -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl get disks -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl reboot -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl shutdown -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl dashboard -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl dmesg -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl health -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl memory -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl netstat -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl processes -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl stats -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig
• talosctl usage -n 192.168.1.100 –endpoints 192.168.1.100 –talosconfig=vbox-config/talosconfig

А она меня радует, не чего лишнего и мало памяти потребляет.

Надо ещё cilium туда добавить.

Ещё задачки и идей будут ??