Предстоящий релиз Valkey 9.0 несёт в себе значительные улучшения в отказоустойчивости больших кластеров, позволяя масштабироваться до 2000 узлов и достигать производительности свыше 1 миллиарда запросов в секунду, и всё это с гарантированно ограниченным временем восстановления. В этой статье мы рассмотрим, как работает система кластеризации Valkey, а также архитектурные усовершенствования и тщательное тестирование, которые сделали возможным такой уровень масштабирования.

Terraform Actions — это новая концепция, представленная в Terraform 1.14, которая позволяет выполнять операции вне стандартного рабочего процесса CRUD (Create-Read-Update-Delete). Это расширяет возможности Terraform, позволяя взаимодействовать с ресурсами способами, для которых раньше требовались другие инструменты, например Ansible.

Привет, Хабр!

Google, без преувеличения, изменил мир IT, подарив нам Kubernetes – систему, ставшую де-факто стандартом оркестрации контейнеров. И когда выбираешь управляемый Kubernetes от его же создателей, такой как Google Kubernetes Engine (GKE), ожидания, естественно, высоки. Уж кто-кто, а "первоисточник" должен уметь "готовить" свое детище идеально, предоставляя не только удобство, но и прозрачные, глубоко интегрированные и безопасные решения "из коробки". Особенно когда речь заходит о такой фундаментальной вещи, как сетевое взаимодействие и его безопасность.

GKE предлагает два режима работы кластеров: routes-based и VPC-native. Именно VPC-native кластеры позиционируются Google как обеспечивающие более тесную интеграцию с сетью VPC. Как утверждает Google, одно из преимуществ таких кластеров заключается в том, что IP-адреса подов (pods) нативно маршрутизируемы внутри сети VPC кластера и других сетей VPC, подключенных к ней через VPC Network Peering (подробнее см. документацию GKE по IP-алиасам и VPC-native кластерам). Это вселяет уверенность, что возможности VPC, включая мощный механизм GCP Firewall, будут доступны и для наших подов так же легко и нативно, как для обычных виртуальных машин.

Однако, погружаясь в детали настройки контроля сетевого доступа для подов к ресурсам внутри VPC, но внешним по отношению к самому Kubernetes (например, к базам данных Cloud SQL или другим бэкендам), начинаешь сталкиваться с нюансами. Нюансами, которые заставляют усомниться в "бесшовности" этой интеграции. Эта статья – не попытка принизить достижения Google или GKE. Скорее, это повод для всех нас, инженеров, задуматься о тех важных деталях реализации, которые часто остаются "под капотом". Повод погрузиться глубже, понять, как все устроено на самом деле, и какие компромиссы или сложности скрываются за маркетинговыми лозунгами. Ведь чем сложнее архитектура безопасности, тем выше вероятность ошибки конфигурации, особенно если ее компоненты и их взаимодействие не до конца понятны. Если даже у такого гиганта, как Google, в его флагманском продукте для Kubernetes есть подобные неочевидные моменты, то нам, инженерам, работающим с этими системами ежедневно, тем более важно понимать все тонкости для обеспечения надежности и безопасности наших собственных окружений.