Pull to refresh
1
Karma
0
Rating
  • Followers
  • Following

Запускаем HAProxy Kubernetes Ingress Controller вне Kubernetes-кластера

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

Делаете такие узлы воркерами кластера. Шедулите туда pod'ы ingress-controller'а с hostNentwork: true, и никаких двойных проксирований не будет. pod'у будет досупна как сеть внутри кластера, так и сеть хоста (то есть сеть edge узла).

Эта схема ничем принципиально не отличается от того что вы сделали. Только ingress-controller будет у вас в кластере, и деплоить вы его будете с помощью абстракций k8s. Любой pod k8s может иметь доступ в сеть хоста. На мой взгляд нет никаких причин выносить ingress-controller из куба. Вы сделали тоже самое решение что и с hostNetwork: true, только деплой реализовали сами (вместо того чтобы деплоить с помощью k8s).

Запускаем HAProxy Kubernetes Ingress Controller вне Kubernetes-кластера

В случае self hosted Kubernetes обычно используют NodePort и затем вручную устанавливают балансировщик нагрузки. Так что практически в каждом случае балансировщик нагрузки размещается перед вашим Ingress Controller, что означает наличие двойного проксирования, через которые должен пройти трафик для достижения приложений.

Вы же можете публиковать pod'ы ingress controller'а с помощью опции hostNetwork: true, получать трафик напрямую без лишних проксирований. Нет никакой необходимости иметь внешний балансировщик или вытаскивать ingress controller из кластера.

Сохраняем кластеры Kubernetes в чистоте и порядке

А что мешает глобально для всех агентов CI выставить переменную среды HELM_MAX_HISTORY? Или же сделать степ "helm", внутри которого эта переменная определяется, а потом вызывается обычная команда "helm"? В jenkins например это делается просто.

Ваше утверждение, что CI выполняет команды, никак не опровергает мое предложение, вы прост озвучили факт. Ну да, CI умеет выполнять команды, кто же спорит с этим?

Балансируем нагрузку в Jenkins

Если честно, мне этот синтаксис до сих пор взрывает мозг

Да вроде норм, в других языках похожие вещи есть.

В ruby например примерно такое-же называется блоками:

def example
yield 101
end

example do |i|
# any code
# i будет равен 101
puts i * 10
end

example {|i| puts i * 100}


Результат:
1010
10100

P.S. не могу понять как нормально оформить код в новом редакторе хабра, сори =(

Сохраняем кластеры Kubernetes в чистоте и порядке

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

Если у вас один CI. Это не сложно сделать. Ну или пойти с другой стороны, и эту переменную среды устанавливать на стороне раннеров/билд-агентов.

Kubernetes и моделирование на minizinc

Ну вот банальный кейс который я приводил выше.
Вот сейчас я смотрю на детализацию и вижу что у меня только за трафик выходит 4000$. У меня на bare-metal вся инфра стоила столько =).

А это не статика, а именно бэкенд трафик. Статику у нас CDN отдельно раздает. Отдельно за это платим.


@eosfor

 манажед сервисы уменьшают потребность в персонале


Кого нам уволить, чтобы окупить цену за трафик? На bare-metal нам этот трафик бесплатно обходился и никакие люди его отдельно не обслуживали. А цена только за этот трафик равна цене всей нашей инфраструктуре которая была на bare-metal.

Kubernetes и моделирование на minizinc

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

Но в моем кейсе это ведь не так. managed решение покрывает всего 1% задач. Возьмем для примера тот же куб, managed решает проблему обслуживания control-plain и обновления, но это ведь мизерная часть того, что обычно надо делать. Есть еще уйма задач связанных с кубом, которые вообще никак managed решением не покрывается. И как же "девопсы" будут не нужны, а кто node-local-dns развернет? Кто напишет gatekeeper политики на rego? Логирование, мониторинг, ingress-controller, istio, cert-manager, т.д. Кто будет это обслуживать, исправлять проблемы, дорабатывать?
P.S. На самом деле мы используем managed куб, поскольку он считай бесплатный. Но это никак не избавляет от того, что нужны компетентные люди, которые будут обслуживать его.

С managed mysql мы покрываем задачи настройки отказоустойчивого кластера и бэкапов. Но на обслуживание этого, сейчас у нас уходит максимум 8 часов в месяц. Каждый managed mysql сейчас нам обойдется в лучшем случае на 1170$ дороже, таких кластеров у нас 6 (6*1170 = 7020). 7K$ чтобы покрыть 8 часов работы в месяц.

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

Про серверлесс тоже непонятно, ну вот у нас есть 20-30 приложений, от 100 до 10000 rps, обычные бэкендики, что-то пишут в базу. Как серверлесс поможет сэкономить?

Kubernetes и моделирование на minizinc

И далеко не во всех случая совокупная стоимость владения bare metal ниже cloud и ни о каких "кратно дороже" и речи быть не может, просто вы не умеете в FinOps.

Из практики:

Переехали в yandex cloud из hetzner. Теперь платим в 4 раза дороже (вместо 4K евро, платим 16-18K долларов)

Прерываемая виртуалка в яндекс облаке, стоит больше обычной вирталки в hetzner. Обычная виртуалка в яндекс облаке естественно еще дороже. С bare-metal даже сравнивать нет смысла.


Надежность никак не поменялась. Возможно даже в облаке сеть моргает чаще чем моргала в hetzner. Не говоря уже о других проблемах, недавно например лег DNS на ощутимое время.

Ценник в основном за инстансы с кластерами БД, managed БД стоят еще дороже, и не факт, что дадут какие-то плюшки, которые это окупят.

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

Как научиться в FinOps чтобы платить меньше? Прерываемые/spot машины не станут чудесно дешевле, обычные инстансы тоже. На чем тогда экономить? На готовых сервисах? Ну у нас автоматизация для настройки пару типов кластеров бд и кластеров kubernetes не супер дорого вышла и вполне устраивает. Особенно учитывая, что один кластер managed БД по стоймости равен 50% зп одного девопса, а таких кластеров несколько. Да и managed решение далеко не идеальны, особенно по гибкости конфигурации. Например многие вещи в managed кубе яндекса, мы хотели бы сделать по другому (не использовать kube-proxy, вместо iptables для сервисов использовали бы ipvs, а в cilium хотели бы использовать native routing вместо тунелинга, хотели бы иметь возможность включить pod security policy и так далее и тому подобное). У меня если честно нет идей, но если вы что-то посоветуете, то я буду вам сильно благодарен. С облаками опыта имею не много.

P.S. Переезд был обусловлен 152-ФЗ



Мы запустили подкаст про девушек в ИТ

1) Ваши утверждения мне кажутся не убедительны их бы подкрепить какими-то данными.

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

3) Это тоже крайне сомнительно, вовлеченность не зависит ни от пола, ни от того когда ты пришел в индустрию. Я например до 2015 года, чем больше работаю тем меньше хочется в свободное время что-то ковырять (максимум что-то интересное и связанное с работой). А от всего железа и домашнего сервера избавился уже после 3 лет работы в индустрии. У всех всё по разному. Конкретные примеры ничего не доказывают и не опровергают.

Дальше вести дискуссию не буду, потому что слишком много минусов хватаю.

Мы запустили подкаст про девушек в ИТ

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

Мы запустили подкаст про девушек в ИТ

gender gap по РФ равен 0.7 то есть женщины на 30% имеют меньше возможностей. Когда я говорил про 30% я имел в виду РФ.

> Потому что, скажем, если о западных странах, то gender gap - методологическая ошибка статистики, возникающая из-за того, что все эти исследования, ставящие целью доказать существование gender gap, сбрасывают со счетов два главных фактора - количество сверхурочных и склонность мужчин к большему риску, выражающуюся в том, что они просят больше денег на собеседованиях и annual review.

Это ваше личное мнение, или есть какое-то исследование про ошибочность подсчета gender gap?


> что все эти исследования, ставящие целью доказать существование gender gap

Вроде исследование про неравенство, и существует ли это неравенство, а не про доказательство того что существует неравенство. В принципе считать статистику чтобы доказать какое-то утверждение как-то глупо. Смотрим стат данные а уже потом делаем выводы. Я может неправильно понял суть исследований, но вроде там не ставят целью доказать существование gender gap.

> это абсолютная демагогия
> Во-вторых, когда вы хотите сказать о "потраченных усилиях", лучше ничего не говорить, потому что это неизмеримая объективно величина.

Я не устраиваю демагогию, я стараюсь объективно смотреть на ситуацию. Поэтому и смотрю gender gap и другие стат данные. Где вообще в моих словах вы нашли про "давление общества и так далее".

Объективно по стат данным видно, что женщины получают худшие рабочие места и зарабатывают меньше мужчин с такими же бэкграундом и навыками. В исследованиях о "потраченных усилиях" конкретных людей ничего не сказано.
Можно конечно сказать что женщины стараются меньше и тратят меньше усилий чем мужчины, поэтому на 30% имеют меньше возможностей в РФ. Но мне в это слабо верится, также как и слабо верится в идеи что одна нация умнее и лучше другой. Если есть какие-то исследования, которые объясняют такое различие какими-то другими причинами, а не неравенством полов, то укажите их, я бы почитал.

> Если бы все было действительно очевидно, понадобился бы весь этот грязный арсенал аргументации?

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

Мы запустили подкаст про девушек в ИТ

Не понимаю почему набросились на статью и на gudvinr.

Дискриминация женщин до сих пор существует, это видно по статистике разницы зарплат между женщинами и мужчинами (и не только зарплат). Почитайте global gender gap report. Да что тут говорить женщинам буквально в этом году разрешили работать водителем метро. Или например возьмем министерства иностранных дел РФ. У нас 242 посольства, только в одном из них посол женщина.

В IT , тоже самое, хотя казалось бы разницы не должно быть, физическая сила не нужна в работе. Но женщинам в среднем с одинаковыми навыками, уровнем образования, опытом, бэкграундом что и кандидаты мужчины, нужно прикладывать гораздо больше усилий чтобы добиться такой же работы с идентичной зарплатой. Это и показывает характеристика Gender Gap из отчета который я упомянул выше.

Не понимаю аргументов в стиле: "ну у меня женщина начальник, или вот у меня женщина коллега, они же добились почему другие не могут?"
Но неравенство же состоит в том, когда твоей коллеге пришлось приложить гораздо больше усилий чтобы попасть на аналогичную должность. А другим женщинам с такими же навыками как у тебя платят меньшую зарплату. Аргумент "моей коллеге платят столько же" тоже не принимается, поскольку это статистика, если у вас так, не значит что в среднем точно также. А судя по подсчетам в среднем как раз не так, в среднем женщины на 30% имеют меньше возможностей чем мужчины с аналогичными характеристиками.

По поводу "начальница женщина" кстати в РФ действительно неплохо, но это касается менеджмента среднего звена, а вот на самых высоких должностях женщин считай совсем нет.

Создание переиспользуемых пайплайнов для GitLab CI на bash

А чем собственно это отличается от создания проекта для всех переиспользуемых CI шаблонов и подгрузкой их через include?

Тем что это совсем про другое. В jenkins и github actions вы реализуете библиотеку методов на groovy и javascript соотвественно, которые потом используйте в своих пайплайнах как обычные стандартные методы. А в gitlab по сути нет ничего кроме script.


Нечто подобное и пытался сделать автор поста в gitlab. Но поскольку gitlab не имеет никакого способа расширять и добавлять новые методы к его стандартным https://docs.gitlab.com/ee/ci/yaml/#job-keywords, поэтому так все печально и выглядит. И все на баше естественно, так как иначе придется таскать в раннеры зависимости для своего "библиотечного кода".

Создание переиспользуемых пайплайнов для GitLab CI на bash

В Jenkins есть shared lib, где ты можешь хранить переиспользуемый код любого уровня. В Github actions есть action'ы. В Gitlab почему-то до сих пор нет ничего подобного =(.

Почему я советую людям не учить Ansible. Переход с Configuration Synchronization на Immutable infra. Андрей Девяткин

Однако даже в среде с puppet может пригодиться ansible 

в среде puppet, используют bolt для таких вещей.

Почему я советую людям не учить Ansible. Переход с Configuration Synchronization на Immutable infra. Андрей Девяткин

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

Запекаешь образы packer'ом, разворачиваешь их через terraform, pulimi на виртуалках. Все как с контейнерами. Приложеньки со стейтом, обычно есть как готовые сервисы в облаке, их также готовишь через pulimi/terraform.

Чистка GitLab Registry для Kubernetes админов

это есть из коробки в werf, советую попробовать. Запушенные в kubernetes образы он также не чистит.

Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием

то на момент, когда версия control-plane в облачных кластерах соответствовала 1.17 и 1.18, были отключены компоненты

А как это сделано, вручную? Или Deckhouse при обновлении умеет автоматически выкручивать replicas этих компонентов в ноль?

Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием

Правильно ли я понял, что при обновлении воркер узлов, вы просто обновляете kubelet и рестартуете его?
Как я понял, из кучи кластеров и нод, у вас всего один раз он не поднялся. Просто в доке советуют делать drain, но это так долго =(. А вы обновили столько нод, и практически в 99.99% случаев kubelet успешно поднялся, похоже в доке перегибают с осторожностью?

Information

Rating
5,457-th
Registered
Activity