Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:

- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.

Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.

Возможности

- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.

Архитектура

1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.

В отличие от клиентов на базе Electron, которые могут тормозить при работе с большими наборами данных, Zedis создан на основе GPUI (того же механизма рендеринга, который используется в редакторе Zed). Это обеспечивает стабильную работу со скоростью 60 кадров в секунду и минимальным потреблением памяти даже при просмотре миллионов ключей.

Эта коллекция Ansible содержит проверенные в боевых условиях средства защиты для Linux, SSH, nginx и MySQL

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

Hands-on челлендж:
В кластере есть Pod, который не может нормально стартануть. Он пытается подняться, но постоянно падает. Причина: в спецификацию недавно добавили новый контейнер, и после этого init-последовательность стала некорректной. Задача - найти, что именно сломали, и починить, чтобы Pod снова запускался.

Идеально для практики:
- init containers и порядок старта
- логи Pod / events
- kubectl describe / logs
- диагностика CrashLoopBackOff и зависаний