Gateway API in Kubernetes with Cilium

Cilium используется сразу в нескольких важных ролях:

☝️ Замена kube-proxy с использованием eBPF для улучшения производительности и безопасности
0️⃣ Container Network Interface (CNI) для взаимодействия Pod’ов в рамках кластера
🔜 Advanced Load Balancing and Layer 2 Network Solutions: для эффективного управления траффиком и построения надежной сетевой инфраструктуры
🍀 Gateway Class Provider for Gateway API: для масштабируемых и универсальных решений роутинга

📍Gateway API предоставляет новый подход для маршрутизации трафика сервисов в Kubernetes. Появились новые абстракции GatewayClass, Gateway, HTTPRoute, TCPRoute и другие. Это похоже на обновленную, более сложную версию Ingress, предлагающую более широкий спектр функций и более совершенный пользовательский интерфейс в управлении сетью сервисов Kubernetes.

ℹ️ Подробнее как Cilium реализует Gateway API можно почитать тут — https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/

#cilium

CNCF: Observability Whitepaper

🤩 В документе представлена разница между сигналами мониторинга и способами их обработки. Также перечислены различные методы, которые компании успешно использовали для решения распространенных проблем. Документ также представляет несколько инструментов, которые относятся к области observability, и объясняет, как они могут быть включены в ваш стек технологий. Кроме того, документ указывает на известные проблемы, которые до сих пор не решены, или на то, что некоторые способы мониторинга все еще не очень широко используются на рынке.

✅ Необходимо помнить, что observability — это не просто использование всех модных инструментов, нужно понимать, какие данные выходят из системы и как их интерпретировать, чтобы не получить огромный кусок никому не нужных данных. Текущие инструменты позволяют наблюдать за приложение и средой непосредственно в production окружении.

1️⃣ Метрики: в CNCF две популярные модели данных — Prometheus и OpenTelemetry. Стоит обратить внимание на раздел Metric Cardinality: слишком подробные метрики могут привести к непредсказуемому росту метрик и размера данных используемых для их хранения.
2️⃣ Логи можно преобразовать в метрики и трассировки для наблюдения изменений в течение времени. Логи также нужно визуализировать и анализировать. Не храните персональные данные и сенситивную информацию в хранилище логов.
3️⃣ Трейсы: OpenTelemetry или .NET используют W3C в качестве стандартного формата распространения. По этому пути идут все больше облачных провайдеров, и при отсутствии других задач рекомендуется использовать стандарт W3C.
4️⃣ Профилирование: текущие инструменты становятся все более популярными в облачных средах; они добавляют небольшие накладные расходы, что делает профилирование на production как никогда более доступным вариантом.
5️⃣ Дампы: в Linux kernel 2.6+ появился новый метод работы с дампами ядра — так называемые обработчики дампов ядра. Другими словами, это означает, что вместо того, чтобы делегировать сбор файла операционной системе, выходные данные процесса после падения передаются на стандартный ввод приложения, который уже отвечает за запись файла.

🌐 Нам нужна экосистема управления пакетами в Kubernetes

🤔 Почему при написании Helm-чартов приходится задумываться об отступах? Почему конфигурация для nodeAffinity, tolerations, serviceMonitors и других ресурсов различна для каждого чарта? И почему в чартах часто отсутствуют даже базовые компоненты? Это должно быть стандартизировано.

🔄 Почему так многие чарты не включают CRD? Это усложняет установку и управление CRD отдельно.

🔍 Зачем чарты генерируют неоднозначный вывод? Мне нужна предсказуемость — для конкретного входного набора и версии чарта должен получаться одинаковый вывод с helm template.

👩‍💻 Зачем разбираться в Golang, чтобы расшифровать ошибки типизации в файле values.yaml?

🛻 Почему Helm так часто используется как инструмент развертывания? Мне не хочется отслеживать состояние развертывания в самом кластере Kubernetes, когда существуют более эффективные варианты.

🤔 А какой, по вашему мнению, существенной функциональности не хватает в Kubernetes?

🤑 Инструменты для оптимизации затрат в облаках

Robusta KRR: Собирает данные о потреблении ресурсов подов из Prometheus и предлагает оптимальные значения requests и limits для CPU и памяти.

Goldilocks by Fairwinds: Аналогичный инструмент, который помогает оптимизировать настройки ресурсов подов в Kubernetes.

Opencost: Мониторинг затрат в облаке для провайдеров AWS, GCP и Azure.

Kube-downscaler: Инструмент с открытым исходным кодом, который автоматически масштабирует нагрузку в Kubernetes в соответствии с расписанием. Это позволяет снизить затраты за счет оптимизации использования ресурсов в периоды низкой активности.

🔍 Платные решения:
ScaleOps: Kubernetes Resource Optimization
StormForge: Automated Kubernetes Resource Management
Harness: Cloud Cost Management Software

😮 Исходники Omni от Siderolabs (Talos) теперь в открытом доступе вместе с возможностью self-hosted.

🍟 Сервис позволяет быстро и на любых ресурсах (bare-metal, VM, cloud resources) развернуть Kubernetes-кластер. Правда по лицензии нельзя использовать для продажи Managed-сервиса, но можно использовать для своих нужд.

🛡 Built for security from the start, with a minimal attack surface.
🔓 Image based and immutable, upgrades are simple and atomic.
📍 API managed. No SSH – all management is done via a secure gRPC API.
🪖 Installs vanilla Kubernetes, hardened to support CIS and STIG guidelines.

Благодаря встроенному SideroLink (TM) Talos Linux устанавливает безопасное, зашифрованное WireGuard соединение с Omni на самом раннем этапе процесса загрузки, позволяя транслировать логи, просматривать данные о производительности, изменять конфигурации и удаленно диагностировать проблемы.

https://www.youtube.com/live/wd3lI3qf-3w?si=rls_G04EoOVU1Pjy

💬 Greenplum: Репозитории заархивированы

Недавно стало известно, что большая часть репозиториев на GitHub Greenplum была заархивирована. В связи с этим у многих возникли вопросы о будущем проекта.

🔍 Комментарий от Arenadata DB:
Разработка Greenplum в рамках open source, скорее всего, будет приостановлена. Дальнейшее развитие проекта будет происходить силами нового правообладателя проекта — компании Broadcom, и сосредоточится на коммерческой версии VMware Tanzu Greenplum.

❓ Нигде не удалось найти прямых подтверждений этому. На сайте Pivotal все еще указаны лицензии по использованию Open Source вплоть до 7-й версии, а также висит следующее уведомление:

🔈 NOTICE:
As part of VMware’s integration with Broadcom, the Tanzu Network domain will remain available to customers until June 7th, 2024, at which point it will redirect to Broadcom’s Support Portal. The associated Tanzu Network registry will remain in read-only mode starting on June 7th, 2024 and will be available until July 15th, 2024 to continue to support using existing OCI artifacts without impact as you transition to Broadcom systems. Please refer to this knowledge base article (ID#: 367105) for all dates and additional information about automation resources.

👍 Что это значит?
Есть вероятность, что просто из-за смены владельца репозитории могут быть перенесены в другое место.