🚀 Управлении ресурсами Kubernetes: Как Finalizers помогают в удалении

Понимание того, почему объекты Kubernetes иногда остаются неудаленными, даже после выполнения kubectl delete, может быть для эффективного управления вашими кластерами. Внутреннее устройство команды delete в Kubernetes не всегда гарантирует мгновенное удаление, и одной из причин могут быть Finalizers.

В обычных случаях, при отсутствии мешающих факторов, команда delete удаляет объект из кластера без проблем.


🔑 Finalizers - это ключи ресурсов, которые указывают на необходимость выполнения дополнительных операций перед удалением объекта. Например, некоторые Finalizers на объектах PersistentVolume (PV) и PersistentVolumeClaim (PVC) используются для предотвращения случайного удаления.

При наличии Finalizers, объект не удаляется моментально. Kubernetes заблокирует удаление из-за Finalizers и установит временную метку для удаления, но объект будет оставаться до тех пор, пока не будет удален его Finalizer.

Вы можете удалить Finalizer, чтобы разрешить удаление объекта. Это делается через патчинг объекта с помощью kubectl. Как только Finalizer убран, объект будет удален.


🔗 Owner References описывают, какие объекты связаны друг с другом. Это позволяет удалять зависимые ресурсы при удалении родительского объекта. К примеру, при удалении Deployment или StatefulSet, связанные Pod также будут удалены.

По умолчанию, установлена опция --cascade=true, что позволяет удалить объект и его зависимости. Но можно также использовать опцию --cascade=orphan, чтобы удалить только объект, оставив зависимости.


🧩 Знание работы Finalizers и Owner References важно для управления ресурсами Kubernetes. Внимательно исследуйте причины наличия Finalizers перед ручным удалением. Ссылки на владельца помогают удалять связанные ресурсы, но будьте осторожны с финализаторами.

#kubernetes

deployKF builds world-class ML Platforms on any Kubernetes cluster, within any cloud or environment, in minutes.

☝️ deployKF includes leading ML & Data tools from Kubeflow and more
🐫 deployKF has centralized configs that manage all aspects of the platform
🧵 deployKF supports in-place upgrades and can autonomously roll out config changes
🍀 deployKF lets you bring your own cluster dependencies like istio and cert-manager, if desired
🐳 deployKF uses ArgoCD Applications to provide native GitOps support

https://www.youtube.com/watch?v=VggtaOgtBJo

Согласованность баз данных в контексте доступности и задержек.

🚀 ⏳ Давайте представим, что вы создаете сложную систему, и важно, чтобы все пользователи видели одинаковую информацию. Однако существует постоянный баланс между скоростью обновления данных и уверенностью в том, что они актуальны для всех.

📊 Что такое согласованность? Это просто вопрос о том, насколько точно данные в базе отражают реальное положение дел. Это то, что мы ищем, но за ней стоят некоторые нюансы.

🛠️ Чем выше степень согласованности, тем больше времени требуется для обновления данных. И тем менее надежной становится система, особенно при сбоях. Это приводит нас к теореме PACELC.

🤔 Суть теоремы в том, что в распределенных системах у нас есть компромисс. Когда что-то идет не так, и сеть разделяет систему, мы должны выбирать между доступностью (данные всегда доступны, даже если немного устарели) и согласованностью (данные всегда актуальны, но это занимает больше времени).

👩‍💻 Так что каждый разработчик должен учитывать этот баланс между скоростью и надежностью при работе с базой данных. Это фундаментальное понимание, которое помогает создавать эффективные и надежные системы.

6 Archetypes of Broken Ownership

Если принцип «You build it, you run it!» требует авторитета, знаний и ответственности, что произойдет, если что-то из этого отсутствует?

👑 Отсутствие авторитета:

Если вы не контролируете ситуацию, вы не сможете эффективно нести за нее ответственность. Важен авторитет и возможность влияния.

🤓 Отсутствие знаний:

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

📄 Отсутствие опыта:

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

🔦 Понимание, ответственность и опыт — ключи к успешному управлению.

📊 Prometheus - популярное решение для мониторинга. Но чем больше метрик мы начинаем хранить, тем больше памяти требуется. Все бы хорошо, но Prometheus работает в режиме одиночного процесса, что усложняет его использование.

🛠️ Однако за последний год была проделана огромная работа по сокращению потребления памяти Prometheus, в некоторых случаях даже на 50%.

🧠 Какие данные Prometheus хранит в памяти.

🔍 Как профилирование помогло выявить, где можно сэкономить больше всего памяти.

🔥Как однажды небольшая ошибка в конфигурации вызвала серьезный сбой крупнейшей установки Prometheus.

🏗️ Почему пришлось пересматривать структуру данных для лейблов, идентифицирующих временные ряды (time series data).

🌐 И как все эти изменения повлияли на связанные проекты, такие как Cortex и Thanos.

Эти улучшения делают Prometheus более эффективным и доступным, даже с огромными объемами метрик. 🚀📈

kubectl get -o yaml vs. kubectl describe: 🤖💬

Чем отличаются команды kubectl get -o yaml и kubectl describe? 🧐 Давайте разберемся!

kubectl get -o yaml:
Выводит всю информацию в формате YAML или JSON.
Полезно для машинной обработки данных или в скриптах. Предоставляет полное представление ресурса, а также текущий статус.

kubectl describe:
Выводит краткий обзор в более читаемом формате для человека, включая события ресурса (Events)
Удобно для быстрого понимания состояния ресурса и событий.

Часто я использую yq ... | yq для более удобной читаемости. 🤓📜

Kyverno: Kubernetes Native Policy Management

🚀 Kyverno -- это мощный инструмент для управления политиками в среде Kubernetes. Он может проверять, изменять и генерировать конфигурации с помощью контроля доступа и фонового сканирования.

🛡️ Декларативные политики -- Kyverno позволяет определять политики как код, добавляя их к ресурсам Kubernetes, через декларативные конфигурации YAML, что упрощает понимание и управление политиками.

🧞‍♂️ Генерация манифестов -- Kyverno может генерировать манифесты ресурсов на основе определенных политик, что весьма удобно для создания стандартных конфигураций и предотвращения человеческих ошибок.

🧠 Гибкая обработка данных -- Поддерживает изменение ресурсов на лету, применяя политики к запущенным приложениям без их перезапуска, что позволяет эффективно адаптироваться к изменяющимся требованиям.

🤖 Webhook-контроллеры -- Kyverno работает как webhook-контроллер, интегрируясь с Kubernetes API Server, что обеспечивает реактивную обработку событий и обеспечивает безопасную и надежную работу политик.

🛡 Управление ролями -- Kyverno позволяет определять правила доступа на основе политик для более точного контроля над ресурсами.

Kyverno — это не просто инструмент для применения политик, но и платформа для управления политиками как часть процесса разработки и эксплуатации приложений в Kubernetes.

🚀 Apache Kafka: Новый Клиент Franz для Windows и Linux!

🎉 Нативный клиент для Apache Kafka теперь появился и для Windows и для Linux, помимо macOS

📊 Легкий доступ к топикам напрямую через интуитивно понятный интерфейс.

🏋️‍♂️ Простое управление группами потребителей (consumer groups) для оптимального потока данных

😶‍🌫️ Подключение к Managed Kafka / Red Panda

🔍 Быстрый поиск и фильтрация данных для удобства использования.

📈 Визуализация данных, помогающая быстро понять текущее состояние системы.

🤿 Погружение в kube-scheduler

📆 Как работает планировщик Kubernetes можно подробно почитать тут. Этапы планирования Pod'а описаны на рисунке.

🔮 Заскедуленный в данный момент Pod входит в так называемый цикл планирования, как только он выводится из очереди планировщика (после этапов Filtering и Scoring). Очередь сортируется по приоритету Pod'ов, и вы можете узнать больше о том, как работает, здесь. Каждый цикл планирования выполняется последовательно для каждого Pod'а и пытается назначить текущий Pod какому-либо узлу (Node) в кластере.

🧐 О том как работают некоторые стадии в цикле планирования можно почитать здесь:
CycleState Object
Filter Stage
PreFilter Stage
PostFilter Stage
Binding Cycle

🏕 Что интересно, так это то, что все в Kubernetes планируется нативным же образом через планировщик, например:
• Запросы ресурсов (Filter plugin)
• Taints и tolerations (Filter plugin)
• Pod preemption (PostFilter plugin)

🧐И самое любопытное, интерактивное представление о работе Kubernetes планировщика в Kube Scheduler Simulator

#kubernetes #kubescheduler

👁 Уже все наверное написали про Kubernetes 1.29 релиз под названием Mandala
Прокомментировал основные изменения.

KEP-2395: Removing In-Tree Cloud Provider Code

😋 Целью этих изменений является предоставление облачным провайдерам возможность разрабатывать и выпускать выпуски независимо от основного цикла выпуска Kubernetes. Отделение кода поставщика облачных услуг позволяет разделить ответственность между «ядром Kubernetes» и поставщиками облачных услуг. Кроме того, это гарантирует, что все поставщики облачных услуг в экосистеме будут последовательно и расширяемо интегрироваться с Kubernetes.
❓ Ждем семейство дистрибутивов Kubernetes?

KEP 1287: In-Place Update of Pod Resources

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

KEP 753: Sidecar Containers

◀️Про Sidecar контейнеры я уже писал ранее.

Stable
• KEP 3299: KMS v2 Improvements OR KMSv2
• KEP 2485: ReadWriteOncePod PersistentVolume Access Mode
• KEP 727: Kubelet Resource Metrics Endpoint
“The Kubelet Summary API is a source of both Resource and Monitoring Metrics. Because of it’s dual purpose, it does a poor job of both.”

Beta
• KEP 2799: Reduction of Secret-based Service Account Tokens

Alpha
• KEP 3866: nftables kube-proxy backend

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+ появился новый метод работы с дампами ядра — так называемые обработчики дампов ядра. Другими словами, это означает, что вместо того, чтобы делегировать сбор файла операционной системе, выходные данные процесса после падения передаются на стандартный ввод приложения, который уже отвечает за запись файла.