Red Hat OpenShift - это платформа на базе Kubernetes, которая помогает корпоративным пользователям развертывать и обслуживать контейнеризированные приложения.
Red Hat OpenShift - это семейство дистрибутивов Kubernetes, разрабатываемое компанией Red Hat.
OpenShift предоставляет ряд преимуществ по сравнению с автономной установкой Kubernetes или управляемой службой Kubernetes (например, Amazon EKS, Google Kubernetes Engine или Azure Kubernetes Service). К ним относятся более надежные функции многопользовательской работы, расширенная безопасность и мониторинг, интегрированные сети и хранилища, конвейеры CI/CD, управление образами контейнеров и другие инструменты разработчика.
Мониторинг кластеров OpenShift жизненно важен как для администраторов, так и для разработчиков. Это помогает обеспечить бесперебойную работу всех развернутых рабочих нагрузок и правильное распределение среды, чтобы разработчики могли продолжать развертывать и масштабировать приложения.
Кластер Kubernetes состоит из узлов двух типов:
- Один или несколько узлов управления, на которых размещаются компоненты для администрирования кластера.
- Рабочие узлы, на которых размещаются и запускаются рабочая нагрузка контейнера.
Мы рассмотрим три большие категории показателей:
- Показатели состояния кластера
- Показатели ресурсов и квот контейнеров и узлов
- Рабочие показатели уровня управления
Показатели состояния кластера
Серверы API Kubernetes отслеживают различные объекты Kubernetes, такие как модули, и передают информацию о их количестве, работоспособности и доступности. Эта информация используется внутренними процессами и компонентами Kubernetes для планирования новых модулей и контроля за их запуском и обслуживанием. Эти показатели состояния кластера предоставляют высокоуровневое представление о состоянии вашего кластера и могут помочь выявить проблемы с узлами или модулями. Они также могут предупредить вас о необходимости исследования узкого места или масштабирования вашего кластера.
Метрика Node condition
Этот показатель состояния кластера предоставляет обзор работоспособности узла. Он выполняет проверку следующих состояний узла:
- OutOfDisk
- Ready (node is ready to accept pods)
- MemoryPressure (node memory is too low)
- PIDPressure (too many running processes)
- DiskPressure (remaining disk capacity is too low)
- NetworkUnavailable
Метрика Desired vs. current pods
Желаемые и текущие поды. Мониторинг запущенных подов. Сколько вы разрешили в манифесте запускать подов и сколько запущено. Это важно, для того чтобы понимать какая нагрузка в настоящий момент на ваш кластер/систему. kube_deployment_spec_replicas и kube_deployment_status_replicas.
Метрика Available and unavailable pods
Под может быть запущен, но недоступен, что означает, что он не готов и не может принимать трафик. Это нормально при определенных обстоятельствах, например, при новом запуске модуля или при внесении изменений и развертывании спецификации этого модуля. Но если вы видите всплески количества недоступных модулей или модулей, которые постоянно недоступны, это может указывать на проблему с их конфигурацией или в общем с самим кластером.
Ресурсные метрики
Отслеживание использования памяти, процессора и диска в узлах и подах может помочь выявить и устранить проблемы на уровне приложений. Однако мониторинг использования ресурсов объектами Kubernetes не так прост, как мониторинг традиционного приложения. В Kubernetes вам все еще необходимо отслеживать фактическое использование ресурсов вашими рабочими нагрузками, но эта статистика становится более полезной, когда вы рассматриваете ее в контексте запросов ресурсов и ограничений, которые определяют, как Kubernetes управляет ограниченными ресурсами и планирует рабочие нагрузки в кластере. Таким образом, мониторинг использования ресурсов в Kubernetes требует учета как потребностей приложений, так и ресурсов, доступных в кластере.
Метрики Requests and limits
В манифесте развертывания вы можете объявить запрос и ограничение для процессора (измеряемого в ядрах), памяти (измеряемой в байтах) и хранилища (также в байтах) для каждого контейнера(пода), запущенного в модуле. Запрос - это минимальный объем процессора или памяти, который узел выделит контейнеру; ограничение - это максимальный объем, который контейнеру будет разрешено использовать. Запросы и ограничения для всего модуля рассчитываются из суммы запросов и ограничений для входящих в него контейнеров. Запросы и ограничения не определяют фактическое использование ресурсов модуля, но они существенно влияют на то, как Kubernetes планирует модули на узлах. В частности, новые модули будут размещаться только на том узле, который может удовлетворить их запросы.
- Memory requests - kube_pod_container_resource_requests_memory_bytes
- Memory limits - kube_pod_container_resource_limits_memory_bytes
- Allocatable memory - kube_node_status_allocatable_memory_bytes
- CPU requests - kube_pod_container_resource_requests_cpu_cores
- CPU limits - kube_pod_container_resource_limits_cpu_cores
Метрика Memory utilization
Отслеживание использования памяти на уровне подов и узлов может дать важную информацию о производительности вашего кластера и способности успешно выполнять рабочие нагрузки.
Метрика Disk utilization
Как и память, дисковое пространство является несжимаемым ресурсом. Если kubelet обнаруживает нехватку дискового пространства на своем корневом томе, это может вызвать проблемы у планировщика с назначением модулей этому узлу. Если оставшаяся емкость диска узла превысит определенный порог ресурса, он будет помечен как находящийся под давлением диска. Kubelet узла отслеживает использование диска для двух файловых систем: nodefs, в которой хранятся локальные тома, журналы демона и т.д.; и imagefs, который является необязательным и используется для хранения образов контейнеров.
- imagefs.available
- imagefs.inodesFree
- nodefs.available
- nodefs.inodesFree
Метрика CPU utilization
Отслеживание объема CPU, используемого вашими модулями, по сравнению с их настроенными запросами и ограничениями, а также загрузка CPU на уровне узлов даст вам важную информацию о производительности кластера. Подобно тому, как под превышает свои пределы использования CPU, нехватка доступного CPU на уровне узла может привести к тому, что kubelet узла ограничит объем CPU, выделяемый каждому модулю, работающему на этом узле.
Метрика Network throughput
Независимо от того, запускаете ли вы OpenShift в облаке, локально или и то, и другое, ваша среда состоит из объектов, которые должны взаимодействовать друг с другом - и с внешним миром — по сети. Это означает, что проблемы с подключением к сети на разных уровнях могут оказать существенное влияние на работоспособность и производительность вашего кластера. Например, если ваши серверы etcd не смогут взаимодействовать друг с другом, они потеряют кворум, что приведет к возможной потере вашего кластера. Отслеживание пропускной способности сети на ваших узлах и за их пределами может помочь выявить проблемы при взаимодействии с уровнем управления. Или мониторинг сетевой активности, агрегированный вашими службами, может помочь выявить возможные проблемы с конфигурацией.
....продолжение следует
