На просторах Github мы наткнулись на репозиторий KubernetesCRInjection. Он определенно будет полезен, если вы пишите свой Kubernetes controller и хотите избежать возможных уязвимостей еще на стадии его проектирования.

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

Примеры того как можно классифицировать такие инъекции и реальные примеры таких уязвимостей можно в репозитории.

https://github.com/duke-git/lancet
#github #go #lib

Как небольшой «тюнинг» Talos Linux увеличил производительность NVMe SSD в 2.5 раза для k8s
https://habr.com/ru/articles/852536/

Спойлер:
iommu.strict=0

Шикарный пример пряморукой визуализации. Товарищ наглядно изобразил, как устроены задержки при межсерверной коммуникации внутри и между зонами доступности на примере амазоновского us-east-2 датика.
Цель проекта? Да пёс его знает. Красиво и наглядно показывает, что коммуникация внутри AZ всегда быстрее, даже если все машины физически в одном месте.

https://benjdd.com/az/

Циферки брал вот так: https://www.bitsand.cloud/posts/cross-az-latencies

Я вот как-то писал про свою личную OPS практику - периодический рестарт программ в проде (https://tttttt.me/itpgchannel/370)

Вот, хороший текст, подтверждающий эффективность такого подхода:

https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug

"We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one"

И я, кстати, совершенно не кривил душой, говоря про это.

Вот, например, я периодически рестартую свои haproxy и ssh туннели для обхода блокировок (https://tttttt.me/itpgchannel/2262) в своей #lab #home_lab - https://github.com/pg83/lab/blob/master/lab/cg.py#L455-L457

https://matt.blwt.io/post/regular-restarts-are-good-actually/

TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".

Я написал очень длинный и очень интересный текст про Юникод. Поскольку в Telegram пост такого размера не помещается, выложил на сайт:

https://blo.gepar.do/v0/unicode.html

Все бегом читать :)

Я думаю, многие слышали кучу наставлений, что CPU limits в kubernetes не нужны. Началось это все со знаменитого поста Tim Hockin.
Но вот нюанс, с похожей ситуацией и я столкнулся, если ваше приложение ориентируется на cpuset cgroup, то придется делать под Guaranteed (нет, это нужно не только для static полиси).
Мораль такова: что не все, что большие мужи говорят - стоит принимать за истину.

Про переписывание истории

В баше (а точнее, в GNU Readline, который используется башом), есть довольно странная фича: историю команд можно редактировать!

Делается это так:
* нажимаем клавишу ↑, доматываем до команды, которую хотим отредактировать
* редактируем команду
* нажимаем клавишу ↓, доматываем до конца
* готово :)

Наглядную демонстрацию можно видеть на видео выше.

Я на эту «фичу» неумышленно натыкался много раз, и, сам того не зная, редактировал историю. А потом недоумевал, почему у меня при вызове history часть строк оказывались пустыми.

Как это отключить? Можно почитать, например, здесь. Если коротко, то надо в домашней папке создать файл с названием .inputrc и поместить в него такие строчки:

$include /etc/inputrc
set revert-all-at-newline on