Forwarded from #corpix
https://blade.tencent.com/en/advisories/qualpwn/
Уязвимости в чипах qualcomm, позволяющие атаковать wi-fi чип и выполнить код на уровне ядра
Уязвимости в чипах qualcomm, позволяющие атаковать wi-fi чип и выполнить код на уровне ядра
Forwarded from Пятничный деплой
Если вы до сих пор не слышали про Trunk Based Development - почитайте, это очередное "модное" слово https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0 #tbd
Medium
Why I love Trunk Based Development (or pushing straight to master)
(or pushing straight to master)
10 open-source Kubernetes tools for highly effective SRE and Ops Teams
https://www.abhishek-tiwari.com/10-open-source-tools-for-highly-effective-kubernetes-sre-and-ops-teams/
https://www.abhishek-tiwari.com/10-open-source-tools-for-highly-effective-kubernetes-sre-and-ops-teams/
Abhishek Tiwari
10 open-source Kubernetes tools for highly effective SRE and Ops Teams
If you are running workloads in Kubernetes, your site reliability engineering (SRE) and operations (Ops) teams need right kind of tooling to ensure the high-reliability of the Kubernetes cluster and workloads running in it. Here we present a list of 10 open…
Forwarded from Находки в опенсорсе
Simple real time visualisation of the execution of a #python program: https://github.com/alexmojaki/heartrate
Rook v1.0 Adds Support for Ceph Nautilus, EdgeFS, and NFS Operator
https://www.infoq.com/news/2019/08/rook-v1-release/
#kubernetes #k8s-operator
https://www.infoq.com/news/2019/08/rook-v1-release/
#kubernetes #k8s-operator
InfoQ
Rook v1.0 Adds Support for Ceph Nautilus, EdgeFS, and NFS Operator
Rook, a storage orchestrator for Kubernetes, has released version 1.0 for production-ready workloads that use file, block, and object storage in containers. Highlights of Rook 1.0 include support for storage providers through operators like Ceph Nautilus…
https://insights.sei.cmu.edu/sei_blog/2017/06/six-things-you-need-to-know-about-data-governance.html
#datamanagement #architecture
#datamanagement #architecture
SEI Blog
Six Things You Need to Know About Data Governance
This SEI Blog post discusses an incremental approach to launching data governance that delivers immediate payback, based on six principles.
Forwarded from I hate overtime
Открыл тут для себя диаграммы Исикавы. Оказалось, что очень удобно с помощью сабжа наглядно объяснять суть проблемы людям, не имеющим нужных компетенций, или не очень понимающим предметную область. Особенно, если софт-скилы не на высоте(как у меня😞)
Кароч хозяюшке на заметку)
Кароч хозяюшке на заметку)
Kubernetes multi-cluster networking made simple - ITNEXT
https://itnext.io/kubernetes-multi-cluster-networking-made-simple-c8f26827813
https://itnext.io/kubernetes-multi-cluster-networking-made-simple-c8f26827813
Medium
Kubernetes multi-cluster networking made simple
TL;DR: Kubernetes multi-cluster networking should be simple in order to scale. If you don’t want to worry about complex routing, overlay…
How to automate REST API end-to-end tests in a CI environment with Postman and Newman
https://www.freecodecamp.org/news/how-to-automate-rest-api-end-to-end-tests/amp/
https://www.freecodecamp.org/news/how-to-automate-rest-api-end-to-end-tests/amp/
freeCodeCamp.org
How to automate REST API end-to-end tests in a CI environment with Postman and Newman
Postman [https://learning.getpostman.com/] is a great tool to explore REST APIs. You can build requests and try them out to get quick feedback. Then you can persist them as collections to make sure that the knowledge doesn't get lost. Newman [https://git…
Kubernetes Workloads in the Serverless Era: Architecture, Platforms, and Trends
https://www.infoq.com/articles/kubernetes-workloads-serverless-era/
https://www.infoq.com/articles/kubernetes-workloads-serverless-era/
InfoQ
Kubernetes Workloads in the Serverless Era: Architecture, Platforms, and Trends
Explore how microservices architecture has evolved into cloud-native architecture, where many of the infrastructure concerns are provided by Kubernetes in combination with additional abstractions provided by service mesh and serverless frameworks. In addition…
https://cilium.io/blog/2019/08/20/cilium-16/
- KVStore free operation
- 100% Kube-proxy replacement (OMFG LOL)
- Socket-based load-balancing
- Policy scalability improvements
- Generic CNI chaining
*ушел тестить на своих нагрузочках, хехе*
#cilium #release
- KVStore free operation
- 100% Kube-proxy replacement (OMFG LOL)
- Socket-based load-balancing
- Policy scalability improvements
- Generic CNI chaining
*ушел тестить на своих нагрузочках, хехе*
#cilium #release
cilium.io
Cilium 1.6: KVstore-free operation, 100% kube-proxy replacement, Socket-based load-balancing, Generic CNI Chaining, Native AWS…
We are excited to announce the Cilium 1.6 release. A total of 1408 commits have been contributed by the community with many developer...
Forwarded from Dodo Engineering
Шпаргалки по Python. Продвинутый уровень.
Сохраняйте, чтобы не потерять.
– Regular Expression (https://clck.ru/H59qw);
– Concurrency (https://clck.ru/H59se);
– Security (https://clck.ru/H59ua);
– Test (https://clck.ru/H59vV);
– Asyncio (https://clck.ru/H59wP).
Авторы: https://www.pythonsheets.com
Enjoy!
Сохраняйте, чтобы не потерять.
– Regular Expression (https://clck.ru/H59qw);
– Concurrency (https://clck.ru/H59se);
– Security (https://clck.ru/H59ua);
– Test (https://clck.ru/H59vV);
– Asyncio (https://clck.ru/H59wP).
Авторы: https://www.pythonsheets.com
Enjoy!
Forwarded from Господин Архитектор
Я на днях в твиттере написал "смешной" бизнес-совет из интернета: "будьте везучими". Посмеялся, типа. И со мной также люди посмеялись. Мол, ха-ха, спасибо за полезный совет, вот теперь-то все наладится!
Только я - не смеялся в этом месте.
Вы делаете гы-гы, вы и так все знаете лучше всех. А я глупый, я пошел смотреть, что такое везение, и что знает культура про удачу и неудачу.
"Неудачи бессильны против того, кто твердо гнет свою линию. Раз не везет, два, сто, – но не бесконечно. И когда человек обретает умение и мужество держаться вопреки любому невезению – вот тогда он в порядке; и с первой крохой удачи – а эти крохи выпадают всем! – он попрет, как танк."
"Во-первых, [..] невезение – это когда человек хочет больше, чем может. Этим надо быть скромней. Второе: не умеет учитывать все жизненные обстоятельства. Третье: не готов к худшему. Четвертое: принимает мелочи близко к сердцу."
"На удачу надо плевать – тогда она придет сама. И быть к ней готовым: недостойному она не поможет – он не сумеет ею воспользоваться, удержать. Ее надо добиваться, но на нее нельзя рассчитывать: везет тому, кто сам себя везет. Когда человек может и без удачи, своим горбом и разумом добиться цели – при любых обстоятельствах! – вот тогда удача сама идет навстречу."
👆 Это все из одной только книги, навскидку. Совет в твите умный, просто не всякий читатель его способен понять.
Только я - не смеялся в этом месте.
Вы делаете гы-гы, вы и так все знаете лучше всех. А я глупый, я пошел смотреть, что такое везение, и что знает культура про удачу и неудачу.
"Неудачи бессильны против того, кто твердо гнет свою линию. Раз не везет, два, сто, – но не бесконечно. И когда человек обретает умение и мужество держаться вопреки любому невезению – вот тогда он в порядке; и с первой крохой удачи – а эти крохи выпадают всем! – он попрет, как танк."
"Во-первых, [..] невезение – это когда человек хочет больше, чем может. Этим надо быть скромней. Второе: не умеет учитывать все жизненные обстоятельства. Третье: не готов к худшему. Четвертое: принимает мелочи близко к сердцу."
"На удачу надо плевать – тогда она придет сама. И быть к ней готовым: недостойному она не поможет – он не сумеет ею воспользоваться, удержать. Ее надо добиваться, но на нее нельзя рассчитывать: везет тому, кто сам себя везет. Когда человек может и без удачи, своим горбом и разумом добиться цели – при любых обстоятельствах! – вот тогда удача сама идет навстречу."
👆 Это все из одной только книги, навскидку. Совет в твите умный, просто не всякий читатель его способен понять.
Forwarded from Experimental chill
Как Netflix пытается лучше обеспечить CPU изоляцию.
Статья:https://medium.com/netflix-techblog/predictive-cpu-isolation-of-containers-at-netflix-91f014d856c7
Репозитория нет.
CPU кристалл один, но количество сервисов, которые на нём запускается на одной машине, может быть много. Это есть принцип общежития, и порой соседи друг другу мешают.
Механизмы выделения CPU в основном занимается господин Linux, используя стандартный и прекрасный алгоритм CFS (Completely Fair Scheduler), почитать о котором можно в огромном количестве мест (точкой для старта может стать эта ссылка https://opensource.com/article/19/2/fair-scheduling-linux). Netflix у себя померил и понял, что их распределение CPU далеко от идеала и сделал следующее.
Давайте вместо того, чтобы класть контейнеры как попало, будем их класть эффективнее через задачи комбинаторной оптимизации. Как этого достигать -- современные процессоры разбивают процессор на несколько NUMA сокетов (считайте, что это просто отдельная сущность, где рядом хранятся L1, L2, L3 кэши и сам CPU вместе с его hyper threading клоном). И у нас есть свойство, что ходить к соседней NUMA node для доступа к кэшам в 5 раз дороже, чем сходить в свою память. (картинка внизу показывает упрощенно архитектуру и плохую и хорошую упаковку).
Итак, у нас есть K контейнеров, каждый который потребляет сколько-то CPU и d тредов на инстансе. Это задача Mixed Integer Program и хорошо решается на не очень больших d и K. На самом деле, нам надо найти бинарную матрицу (d, K), в которой сумма в столбце будет равна количеству CPU, который просит контейнер, а в строке не более одной единицы. Последнее условие вряд ли выполняется всегда, поэтому мы скорее введём loss функцию, чтобы её уменьшать. Какие эвристики в loss функции бывают:
* Количество контейнеров на разных NUMA nodes должно быть минимально
* Не использовать hyper-thread, пока не надо, чтобы L1/L2 кэши не мешались
* Пытаться не загружать L3 кэши (например, в зависимости от важности контейнера, кому-то нужен L3 кэш очень сильно)
Теперь вместо того, чтобы CFS отрабатывал каждые несколько милисекунд, стоит перебалансировать на инстансе раз в несколько секунд, опираясь на статистику контейнеров или даже предсказательный ML (в Netflix взяли градиентный бустинг, чтобы предсказывать 95 квантиль потребления контейнера в следующие 10 минут).
Netflix утверждает, что они так смогли очень сильно сбавить высокие квантили и уменьшить дисперсию ожидания/потребления CPU. Linux не тратит CPU, чтобы шедулить процессы, теперь потребление контейнеров лучше предсказывается и легче воспроизводимо.
Дальше Netflix хочет понимать, а есть ли вообще в процессах ненужные ресурсы и перешардивать нагрузку на инстансе исходя из этого.
Это просто охеренно. Шах и мат, дискретные опты всё же нужны. Прочитайте статью полностью, я упускал некоторые детали.
Захотелось в Netflix поработать, жаль, там Java :(
Статья:https://medium.com/netflix-techblog/predictive-cpu-isolation-of-containers-at-netflix-91f014d856c7
Репозитория нет.
CPU кристалл один, но количество сервисов, которые на нём запускается на одной машине, может быть много. Это есть принцип общежития, и порой соседи друг другу мешают.
Механизмы выделения CPU в основном занимается господин Linux, используя стандартный и прекрасный алгоритм CFS (Completely Fair Scheduler), почитать о котором можно в огромном количестве мест (точкой для старта может стать эта ссылка https://opensource.com/article/19/2/fair-scheduling-linux). Netflix у себя померил и понял, что их распределение CPU далеко от идеала и сделал следующее.
Давайте вместо того, чтобы класть контейнеры как попало, будем их класть эффективнее через задачи комбинаторной оптимизации. Как этого достигать -- современные процессоры разбивают процессор на несколько NUMA сокетов (считайте, что это просто отдельная сущность, где рядом хранятся L1, L2, L3 кэши и сам CPU вместе с его hyper threading клоном). И у нас есть свойство, что ходить к соседней NUMA node для доступа к кэшам в 5 раз дороже, чем сходить в свою память. (картинка внизу показывает упрощенно архитектуру и плохую и хорошую упаковку).
Итак, у нас есть K контейнеров, каждый который потребляет сколько-то CPU и d тредов на инстансе. Это задача Mixed Integer Program и хорошо решается на не очень больших d и K. На самом деле, нам надо найти бинарную матрицу (d, K), в которой сумма в столбце будет равна количеству CPU, который просит контейнер, а в строке не более одной единицы. Последнее условие вряд ли выполняется всегда, поэтому мы скорее введём loss функцию, чтобы её уменьшать. Какие эвристики в loss функции бывают:
* Количество контейнеров на разных NUMA nodes должно быть минимально
* Не использовать hyper-thread, пока не надо, чтобы L1/L2 кэши не мешались
* Пытаться не загружать L3 кэши (например, в зависимости от важности контейнера, кому-то нужен L3 кэш очень сильно)
Теперь вместо того, чтобы CFS отрабатывал каждые несколько милисекунд, стоит перебалансировать на инстансе раз в несколько секунд, опираясь на статистику контейнеров или даже предсказательный ML (в Netflix взяли градиентный бустинг, чтобы предсказывать 95 квантиль потребления контейнера в следующие 10 минут).
Netflix утверждает, что они так смогли очень сильно сбавить высокие квантили и уменьшить дисперсию ожидания/потребления CPU. Linux не тратит CPU, чтобы шедулить процессы, теперь потребление контейнеров лучше предсказывается и легче воспроизводимо.
Дальше Netflix хочет понимать, а есть ли вообще в процессах ненужные ресурсы и перешардивать нагрузку на инстансе исходя из этого.
Это просто охеренно. Шах и мат, дискретные опты всё же нужны. Прочитайте статью полностью, я упускал некоторые детали.
Захотелось в Netflix поработать, жаль, там Java :(
Medium
Predictive CPU isolation of containers at Netflix
By Benoit Rostykus, Gabriel Hartmann
Вот туть еще про разработку для кубера, так то ребятки говорят что еще 7 не хватает, но это пойнт для срачика имхо