Regulex：JavaScript Regular Expression Visualizer
https://jex.im/regulex/
#regex

Ask HN: Small scripts, hacks and automations you're proud of?
Article, Comments

https://github.com/SixArm/sixarm-unix-shell-functions
#github #shell #sh #func

https://github.com/moul/docker-diff
#docker #image #diff #github

https://github.com/XenitAB/spegel
#registry #k8s #kubernetes #OCI #github

https://habr.com/ru/company/nixys/blog/721404/
#tf #terraform

Kubernetes Controllers: For, Owns, Watches

Всем привет!

В сети не всегда просто найти хорошую статью про написание собственных Kubernetes Operators/Controllers. Особенно, если интересует не «общая картинка», а какие-то частности.

В статье Автор разбирает разницу между конструкциями for(), owns() и get() при регистрации controller через SetupWithManager.

Для этого рассматривается пример:
🍭 Создается Custom Resource
🍭 Controller узнает об этом и создает pod (nginx:latest), присваивает ему label – foo:bar
🍭 Controller должен гарантировать наличие указанных label. Т.е. add/update/delete не должны «срабатывать»

Далее расписывается логика реконсиляции controller’a. Наглядно описывается как можно это реализовать не делая еще один Controller, который бы смотрел за каждым pod и его labels – как раз тот самый owns().

В завершении – описание функции watches(), которая лежит в основе for() и owns(). В статье много примеров и кода для собственного воспроизведения примера.

P.S. Про awesome подборку написания Kubernetes Operators мы писали тут.

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

Специально для этого сделали пакет ngrok-go

А есть опенсорсные аналоги ngrok? Так чтоб у себя на сервере поднять и через апишку сабдомены заводить

#golang

https://blog.ngrok.com/posts/ngrok-go

https://superorbital.io/journal/testing-production-controllers/
#k8s #kubernetes #controller #testing

https://medium.com/@bob.s.walters/using-istio-with-nginx-ingress-for-a-b-service-shifting-7b39596db2fe
#istio #ingress #nginx

https://itnext.io/using-istio-with-nginx-ingress-ccb8e28d9aff
#istio #ingress #nginx

Забавный датасет в формате API на тему "Рика и Морти"

Есть доступ через REST и GraphQL.

ИМХО можно использовать в примерах и hello world приложениях в качестве "какого-нибудь API"

https://rickandmortyapi.com/

Kube-apiserver в роли port scanner

Всем привет!

Еще одна потрясающая статья от Rory McCune, посвященная «своеобразному» использованию возможностей Kubernetes. Нет, это не уязвимость, это не bug, это не ошибка.

Kubernetes устроен таким образом, что он может осуществлять сетевые запросы на внешние адреса в некоторых ситуациях. Например, в случае с Validating Webhooks. Таким образом можно реализовать некий аналог SSRF и превратить Kubernetes в «сканер портов».

Rory проделал следующее:
🍭 Создается namespace
🍭 Регистрируется webhook. Никакой сервер, обрабатывающий запрос не регистрируется. Вместо этого указывается потенциальная «жертва»
🍭 Создается pod в указанном namespace. Готово! В сообщении об ошибки получаем всю необходимую информацию

PoC того, что описано выше можно найти в repo. Если интересно посмотреть небольшую демонстрацию, ее можно найти в блоге Rory.

P.S. Лучше не проверять этот, пусть и крайне базовый PoC на каких-либо настоящих сервисах и/или в production-окружениях.

В рамках изучения Cilium Service Mesh и Istio Ambient Mesh (прошлые посты 1,2) я наткнулся на занимательную статью "Exploring Cilium Layer 7 Capabilities Compared to Istio". Там сравниваются не Service Mesh реализации, а L7 возможности стандартного CNI Cilium (v1.12) и sidecar реализации Istio. И из этой статьи можно узнать много всего интересного о деталях реализации CNI Cilium и Istio, а именно:
- L7 фильтрация в ресурсе CiliumNetworkPolicy реализована как расширение/фильтр (Cilium.L7Policy) для Envoy proxy
- Как выглядит/хранится L7 правило внутри CNI Cilium
- CNI Cilium использует для этого Envoy filter, а Istio использует RBAC filters из апстрима Envoy
- чем является identity в Cilium, как он вычисляется (база это IP, labels) и хранится (это никакой не криптографический приметив, а просто целое число). А в Istio для этого служит service account token - там вообще все сроиться вокруг сертификатов, что как вы понимаете надежнее

Также там поднимается вопрос/проблема, что при модели Envoy per Node ресурсов потребляется меньше, но в случае его отказа страдают сразу все микросервисы на Node. Есть и еще одна интересная проблема с Network cache-based identity, что как я написал выше используется в Cilium, но это заслуживает отдельной заметки ;)

Еще одно достойное применение ИИ - написание регулярок вместо меня.

https://regex.ai/