Terraform best practices от Google

Недавно гугл опубликовал список best practices для Terraform.
Сам материал отлично структурирован и хорошо подходит для стандартизации использования терраформа внутри организации.

Рассматриваются следующие разделы:
✅ общие рекомендации и структура кода
✅ модули
✅ организация root проекта
✅ специфика GCP и ресурсов в нем
✅ контроль версий и многое другое

От себя хочу добавить, что большинство упомянутых подходов можно внедрить используя различные линтеры и/или инструменты для написания кастомных политик.
Полный список можно посмотреть например в awesome-terraform.

Для локальной и удаленной разработки мне понравилось использовать pre-commit-hook для terraform. Инструмент легко настраивается один раз, конфиг представляет собой простой yaml файл, а проверки можно запускать и во время локального коммита, так и в CI. Таким образом можно избежать сценария - у меня локально работает, а CI падает.

#terraform

Cloud native visuals by Kubesimplify

Kubesimplify выпустили бесплатную книжку, которая в основном состоит из диаграмм и схем в различных домейнах.
- Беглый Linux и основы сетей
- Kubernetes
- Containers, VMs, Virtualization
- ...

Рекомендую сохранить в закладки - может пригодится и вам и коллегам, которым нужно дать представление о какой-то технологии или подходе.
Еще такие книжки можно использовать в качестве вдохновения для создания своих визуальных материалов.

Ссылка на книгу

#books

Kubernetes resources under the hood

Отличный обзорный цикл статей про работу с ресурсами в Kubernetes. Рассматриваются следующие аспекты:
📌 виды ресурсов
📌 QoS для подов
📌 особенности работы с CPU в Linux, CFS шедулер
📌 различные сценарии с использованием resources requests/limits
📌 CPUs best-practices

👀 tl;dr by Tim Hockin:
1. Always set memory limit == request 2)
2. Never set CPU limit

Kubernetes resources under the hood — Part 1
Kubernetes resources under the hood — Part 2
Kubernetes resources under the hood — Part 3

#kubernetes

Tim Hockin недавно поделился диаграммами, которые описывают флоу работы различных проб в Kubernetes.

Как всегда подробнее про пробы можно прочитать в официальной документации Kubernetes и также рекомендую ознакомиться с жизненным циклом пода.

Также по теме жизненного цикла пода есть отличные детальные статьи:
📌 What happens when ... Kubernetes edition!
📌 Kubernetes Pod Lifecycle
📌 What Happens When Deleting a Pod

#kubernetes

What David Flanagan Learned Fixing Kubernetes Clusters

Отличная статья про то, как ломались и чинились куб кластера на ютуб канале Дэвида (рекомендую подписаться, если нравится смотреть технический контент).
- классическая история про корявый символ “c”
- интересный случай, в котором убрали бит выполнения с различных бинарников Kubernetes и не только
- ну и куда без сетевых проблем 🤡

Полное интервью

#kubernetes

Platform Engineering Is Not about Building Fancy UIs

TL;DR: воспринимайте платформу для разработчиков как настоящий продукт: поговорите с потенциальными кастомерами, посмотрите, что занимает больше всего времени и что болит сильнее всего(создание новых сервисов, интеграции, деплой, конфиг менеджмент…), приоритезируйте и оцените, что реально автоматизировать. Repeat!

Статья довольно короткая, но емкая, рекомендую ознакомиться с первоисточником.

How Cloudflare runs Prometheus at scale

Утро началось с чтения отличной статьи про то, как решать проблему metrics high cardinality в экосистеме Prometheus.

Ключевые моменты:
📌 CF использует Prometheus server на каждый датацентр (подробного объяснения нет, но возможно это обусловленно геораспределенной архитектурой, большим объемом данных и из соображений безопасности помимо очевидного распределение нагрузки)
📌 В конфигурации Prometheus можно задавать несколько лимитов - на количество семплов метрик, лейблов, максимальную длину имени лейбла и тд)
📌 Валидация в CI изменений касающихся мониторинга. (расчет капасити с учетом изменений например максимального количества семплов)
📌 Кастомные патчи поверх open-source версии Prometheus (возможность выполнять частичный scrape данных. На данный момент в Prometheus имплементирована логика либо все, либо ничего в соответствии с конфигом)

Небольшой список инструментов по топику:
🛠 Karma - дашборд для Prometheus Alertmanager. Умеет в группировку алертов, сайленсы, отображение исторических данных, отслеживать Dead Man’s Switch
🛠 pint - валидатор правил для Prometheus
🛠 kthxbye - демон для автоматического продления просроченных сайленсов

Let's talk about Kubelet authorization

Интересная статья про авторизацию кубелета. В основе процесса лежит следующая конфигурация api-server:

--authorization-mode=Node,RBAC

Node режим отвечает как раз за авторизацию запросов Kubelet. Он также управляет ограничением доступа к секретам, которые нужны подам, запущенным на других нодах.

❌ После получения reject на доступ, управление передается следующему режиму - RBAC. Поэтому если права группы system:nodes были модифицированны, то это позволит обойти ограничения Node режима.

Важно упомянуть, что приведенная схема относится к ванильному Кубернетесу и может меняться в зависимости от провайдера. Согласно автору, модификацию на доступ можно встретить в AKS - там кубелеты могут запрашивать секреты на уровне кластера.

☝️В EKS таких модификаций я не нашла.

Two types of software engineers

Статья настолько короткая, что ее можно прочитать за 2 минуты.

Хорошая и тоже короткая мысль из нее:

According to my theory, there are two types of software engineers:
💻 Type 1, when presented with a problem, thinks: "easy, people can just do X."
💻 Type 2, when presented with the same problem, thinks: "very hard, because it requires people to do X."

When you ask ChatGPT to come up with some creative name for the channel 🙈🙈🙈

Cloud Native Rejekts 2023

В ожидании записей с KubeconEU 2023 решила посмотреть доступные стримы с Cloud Native Rejekts. Это конфа, в которую могут попасть непринятые выступления с кубкона. Некоторые доклады прям 🔥

🙌 Getting hands-on with the new Kubernetes Gateway API
🛠 Ephemeral containers in action - running a Go debugger in Kubernetes
🔥 Face off: VMs vs Containers vs Firecracker
👶 SLSA, SigStore, SBOM and Software Supply Chain Security. What does that all mean really?
👀 Lightweight mTLS without Proxies, Sidecars or Complexity

С KubeconEU пока доступны плейлисты с записями выступлений с co-located events: ArgoCD, Cilium, Linkerd, Istio и несколько других.

ребрендинг 😎

If someone’s having to read your docs, it’s not “simple”

Написание документации - это важная часть работы любого инженера. Если вам по работе приходится писать туториалы, онбоардинги и тд., то этот простой совет для вас:

💡Избегайте использовать слова - легко, просто, тривиально, только (easy, painless, straightforward, trivial, simple and just).

Мотивация довольно простая: эти слова чаще всего не несут никакой смысловой нагрузки и перегружают текст ненужными словами. Тем более, если вы пишете документацию, то это уже не просто и легко, а требует инструкций и объяснений. 🤷

Infrastructure as Code is Not the Answer!

Статья Luke Shaughnessy напоминает о том, что внедрение Infrastructure as a code(IaaC, инфраструктура как код) - это не серебряная пуля, которая полностью закрывает вопрос управления инфраструктурой.

У подхода есть следующие плюсы:
✅ It’s reproducible!
✅ It’s self-documenting!
✅ It’s visible!
✅ It prevents mistakes!
✅ It lowers cost!
✅ It prevents drift!
✅ It prevents toil and increases joy!
✅ Self-Service!

При внедрении любого подхода или инструмента, важно иметь экспертизу, стратегию имлементации, а также драйвера или команду, которая будет заниматься поддержкой и автоматизацией.

Мы в текущей организации обкатываем SIG подход для terraform. Основная идея определить список гайдлайнов, заниматься поддержкой общих модулей и стандартизацией версий терраформа и провайдеров, а также организацией кода.

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

7 Things You Didn't Know About Prometheus | Little-Known Features and Implementation Details

🌴 Почти пятничный контент - новое видео от одного из разработчиков Prometheus.

Юлиус рассказывает несколько малоизвестных особенностей инструмента и объясняет, как устроен скрейпинг метрик, почему имя метрики хранится как лейбл и про персистентность for в правилах для алертов.

Failure Mitigation for Microservices

Интересная статья от Doordash о видах отказов в микросервисной архитектуре и способах их предотвратить.

Рассматриваются следующие виды:
🚒 Каскадный отказ (Cascade failure) - цепная реакция, в которой падение одного сервиса ведет к падению другого и так приводит к падению всей системы
🚒 Шторм ретраев (Retry storm) - повторение запросов приводит к дополнительной нагрузке на уже деградировавшую систему
🚒 Смертельная спираль (Death spiral) - упавшая часть нод вызывает перенаправление дополнительного трафика на оставшиеся здоровые, тем самым вызывает их падение из-за увеличившейся нагрузки
🚒 Метастабильный отказ (Metastable failure) - падения, которые не могут быть устранены самостоятельно(автоматически) из-за наличия положительного фидбека в системе

Общие контрмеры:
👨‍🚒 Сброс нагрузки (Load shedding) - механизм, который отклоняет входящие запросы, если количество текущих или одновременных запросов превышает лимит.
👨‍🚒 Circuit breaker - обычно это специальный прокси, который следит за количеством ошибок за промежуток времени и если оно превышает заданный порог, то брейкер начинает откидывать все запросы. После заданного промежутка, он постепенно разрешает больше трафика до тех пор, пока сервис не возвращается к исходному состоянию
👨‍🚒 Автоматическое масштабирование (Auto-scaling) - некий контроллер следит за потреблением ресурсов узлов и при необходимости запускает новые ноды для распределения нагрузки

Авторы предупреждают о минусах масштабирования, таких как ожидание активации нод, перенос проблемы на следующий сервис и усложнение пост-мортем анализа из-за действий автоматики.

Одним из предлагаемых решений является использование автомасштабирования по расписанию, учитывая особенности трафика - день/ночь, будни/выходные и т.д.

Load Balancing

Это хорошая 101 статья, в которой рассматриваются наиболее популярные алгоритмы балансировки запросов - round-robin, weighted round-robin, least-connections и PEWMA. Автор также приводит графики сравнения алгоритмов по latency и количеству неуспешных запросов.

В конце статьи есть небольшой playground, в котором можно помоделировать балансировку разными алгоритмами с несколькими входными данными. 🔥

Пока готовилась к собесам нашла удобный и практичный ресурс- nslookup.io. Там есть статьи с объяснением основных концепций DNS, разных типов записей и типов операций - делегация доменов, работа с почтой и тд. Удобно использовать как и для углубления в домен/закрытия пробелов или для быстрого повторения перед собесами.

У меня еще в туду висит Implement DNS in a Weekend от Julia Evans. 😎