Forwarded from Код и Капуста
Отличная статья про балансировку и разные алгоритмы балансировки. Еще и с анимацией!
https://samwho.dev/load-balancing/
https://samwho.dev/load-balancing/
Forwarded from Инженер Тяпкин (Clear Gray)
На днях ко мне пришёл коллега с интересным вопросом, для понимания которого придётся начать издалека.
Вот есть у нас в кубере securityContext и можно в нём выставлять списочек всяких линуксовых capabilies, ну знаете, setuid, setowner, setpcap... Все наши, короче.
И есть задача давать контейнерам одного публичного приложения только те capabilities, которые ему нужны, а те, что не нужны - отобрать. Делается это всё, традиционно, helm чартом от мейнтейнеров приложения. Чарт нормальный и в нём есть нужная шаблонизация и вот такой объект в values.yaml:
Но нам-то надо не только отобрать, но ещё и добавить, поэтому коллега дописывает сюда нужных нам вещей, в результате чего готовый объект в values.yaml становится вот таким:
Потом он запускает helm с dry-run, после чего и приходит ко мне, чтобы задать свой вопрос: "А вот смотри, я всегда считал, что drop и add тут должны идти в правильном порядке и ставить сперва add, потом drop нельзя. Ведь затрёт же. А хелм наш на этот блок делает toYaml и у него ключи сортируются по алфавиту, потому в манифест прилетает сперва add, потом drop. Что делать?"
И правда, в итоговом манифесте это выглядит вот так:
Документация кубернетиса на этот счёт не говорит ничего внятного, зато в интернете хватает статей, сообщающих в разных вариация, что:
Из-за этого мы несколько приуныли, ведь вечер только что резко перестал быть томным, и пошли выяснять, как дела обстоят на самом деле.
Так вот, если вдруг вы когда-нибудь зададитесь таким вопросом и пойдёте читать интернет, то знайте: НЕКОТОРЫЕ ЧЕРЕПАШКИ ПИЗДЯТ.
На самом деле API кубера глубоко поебать на порядок ключей в capabilities, он сперва делает drop, а потом уже add.
Такая вот хуйня, ребятки, верить нынче нельзя никому (но мне можно ).
https://music.yandex.ru/album/5792882/track/43516266
Вот есть у нас в кубере securityContext и можно в нём выставлять списочек всяких линуксовых capabilies, ну знаете, setuid, setowner, setpcap... Все наши, короче.
И есть задача давать контейнерам одного публичного приложения только те capabilities, которые ему нужны, а те, что не нужны - отобрать. Делается это всё, традиционно, helm чартом от мейнтейнеров приложения. Чарт нормальный и в нём есть нужная шаблонизация и вот такой объект в values.yaml:
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: false
runAsNonRoot: true
privileged: false
capabilities:
drop:
- ALL
Но нам-то надо не только отобрать, но ещё и добавить, поэтому коллега дописывает сюда нужных нам вещей, в результате чего готовый объект в values.yaml становится вот таким:
securityContext:
capabilities:
drop:
- ALL
add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETFCAP
- SETGID
- SETUID
Потом он запускает helm с dry-run, после чего и приходит ко мне, чтобы задать свой вопрос: "А вот смотри, я всегда считал, что drop и add тут должны идти в правильном порядке и ставить сперва add, потом drop нельзя. Ведь затрёт же. А хелм наш на этот блок делает toYaml и у него ключи сортируются по алфавиту, потому в манифест прилетает сперва add, потом drop. Что делать?"
И правда, в итоговом манифесте это выглядит вот так:
securityContext:
capabilities:
add:
- CHOWN
- DAC_OVERRIDE
- FOWNER
- SETFCAP
- SETGID
- SETUID
drop:
- ALL
Документация кубернетиса на этот счёт не говорит ничего внятного, зато в интернете хватает статей, сообщающих в разных вариация, что:
Here the order is very important, if you first provide the add field and then later provide the drop ALL field then all the capabilities would be dropped from the container. So, make sure you use drop first followed by add.
Из-за этого мы несколько приуныли, ведь вечер только что резко перестал быть томным, и пошли выяснять, как дела обстоят на самом деле.
Так вот, если вдруг вы когда-нибудь зададитесь таким вопросом и пойдёте читать интернет, то знайте: НЕКОТОРЫЕ ЧЕРЕПАШКИ ПИЗДЯТ.
На самом деле API кубера глубоко поебать на порядок ключей в capabilities, он сперва делает drop, а потом уже add.
Такая вот хуйня, ребятки, верить нынче нельзя никому (
https://music.yandex.ru/album/5792882/track/43516266
Яндекс Музыка
Пиздеть - не мешки ворочать
Bebopovsky And The Orkestry Podyezdov • Трек • 2018
👍1
Forwarded from Zhovner Hub
Оказывается, уже во всю используется новый типа DNS записи SVCB (HTTPS). Смысл в том, что браузер сразу подключается по протоколу HTTP/3 выполняя всего один DNS запрос.
Да, этой штуке уже 3 года, но я только узнал 😊
Раньше для апрегйда на HTTP/3 сначала происходило подключение по старому протоколу и только внутри существующего коннета поднималась версия протокола, на это уходило лишнее время.
Блог Флиппера, кстати поддерживает эту DNS запись. Проверить можно так:
Для нового dig в линуксе:
Для старого dig в макосе:
Да, этой штуке уже 3 года, но я только узнал 😊
Раньше для апрегйда на HTTP/3 сначала происходило подключение по старому протоколу и только внутри существующего коннета поднималась версия протокола, на это уходило лишнее время.
Блог Флиппера, кстати поддерживает эту DNS запись. Проверить можно так:
Для нового dig в линуксе:
dig https blog.flipperzero.oneДля старого dig в макосе:
dig -t type65 blog.flipperzero.oneForwarded from Код и Капуста
Не самые популярные но полезные HTTP коды
https://blog.frankel.ch/leverage-richness-http-status-codes/
https://blog.frankel.ch/leverage-richness-http-status-codes/
👎1
https://gist.github.com/mcastelino/b8ce9a70b00ee56036dadd70ded53e9f#cpu-resource-management
#k8s #cgroups #cpu #gist #github
#k8s #cgroups #cpu #gist #github
Gist
Kubernetes and cgroups Resource Management/Static cpuManagerPolicy/Memory and Resource Isolation & Scheduling
Kubernetes and cgroups Resource Management/Static cpuManagerPolicy/Memory and Resource Isolation & Scheduling - kcgroups.md
Forwarded from Технологический Болт Генона
There are three phases to the setup:
1. Install the LocalAI server
2. Install the K8sGPT operator
3. Create a K8sGPT custom resource to kickstart the SRE magic!
Слишком много магии, а магию я не люблю 🌝
K8sGPT + LocalAI: Unlock Kubernetes superpowers for free!
https://itnext.io/k8sgpt-localai-unlock-kubernetes-superpowers-for-free-584790de9b65
За ссылку спасибо подписчику
https://www.sobyte.net/post/2022-03/kubelet-quality-of-service-management-for-pods/
#pod #cgroup #QoS
#pod #cgroup #QoS
www.sobyte.net
Quality of Service Management for Pods by Kubelet
The previous article, Kubelet Pod Creation Workflow, explained how kubelet creates pods and how the components collaborate with each other. Based on the previous article, this article will explain how kubelet performs quality of service management for pods.…
👍1
Scaling Kubernetes to 7,500 nodes
https://openai.com/research/scaling-kubernetes-to-7500-nodes
#k8s #kubernetes
https://openai.com/research/scaling-kubernetes-to-7500-nodes
#k8s #kubernetes
Openai
Scaling Kubernetes to 7,500 nodes
We’ve scaled Kubernetes clusters to 7,500 nodes, producing a scalable infrastructure for large models like GPT-3, CLIP, and DALL·E, but also for rapid small-scale iterative research such as Scaling Laws for Neural Language Models.
I'm done with Red Hat (Enterprise Linux) | Jeff Geerling
https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux
#redhat #rh
https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux
#redhat #rh
Forwarded from Мониторим ИТ
Sample vs Metrics vs Cardinality
В статье объясняются три эти понятия относительно работы с TSDB. Читать дальше.
В статье объясняются три эти понятия относительно работы с TSDB. Читать дальше.