kube-state-metrics — дополнение для Kubernetes, которое занимается мониторингом объектов, хранящихся в кластере. Если cAdvisor и сервер метрик используются для предоставления подробной информации о потреблении ресурсов, то kube-state-metrics помогает определить состояние объектов Kubernetes, развернутых в кластере.
Во-первых, каноническая реализация Resource Metrics API — сервер метрик, который собирает метрики таких ресурсов, как процессор и память. В качестве источника он использует API kubelet, сохраняя результаты в память. Собранные метрики применяются в планировщике и контроллерах для горизонтального и вертикального автомасштабирования (Horizontal Pod Autoscaler (HPA) и Vertical Pod Autoscaler (VPA)).
Во-первых, каноническая реализация Resource Metrics API — сервер метрик, который собирает метрики таких ресурсов, как процессор и память. В качестве источника он использует API kubelet, сохраняя результаты в память. Собранные метрики применяются в планировщике и контроллерах для горизонтального и вертикального автомасштабирования (Horizontal Pod Autoscaler (HPA) и Vertical Pod Autoscaler (VPA)
Мониторинг по принципу белого ящика (white-box monitoring) дает возможность оценивать работу приложения в контексте его состояния, позволяя узнать, сколько всего было выполнено HTTP-запросов, сколько из них вернуло ошибку с кодом 500, какова их задержка и т.д. Такой мониторинг дает возможность понять, почему система работает именно так, а не иначе. Например, если на диске закончилось свободное место, мы можем спросить, почему это произошло.
Мониторинг по принципу белого ящика (white-box monitoring) дает возможность оценивать работу приложения в контексте его состояния, позволяя узнать, сколько всего было выполнено HTTP-запросов, сколько из них вернуло ошибку с кодом 500, какова их задержка и т.д. Такой мониторинг дает возможность понять, почему система работает именно так, а не иначе. Например, если на диске закончилось свободное место, мы можем спросить, почему это произошло
Мониторинг таких компонентов, как процессоры, оперативная память, накопители и т.д., традиционно осуществляется с точки зрения внешнего наблюдателя по принципу черного ящика (black-box monitoring). Тот же принцип можно применять и для мониторинга на инфраструктурном уровне, но это не позволяет получить достаточно информации о работе приложения. Например, чтобы проверить работоспособность кластера, можно попробовать развернуть pod; если нам это удастся, то мы будем знать, что планировщик и механизм обнаружения сервисов внутри нашего кластера работают исправно, поэтому можно предположить, что и с другими компонентами все в порядке.
Kubernetes — эффективная система, которая может показаться сложной. Однако процесс развертывания обычного приложения легко упростить, если следовать общепринятым рекомендациям. • Большинство сервисов нужно развертывать в виде ресурса Deployment. Объекты Deployment создают идентичные реплики для масштабирования и обеспечения избыточности. • Для доступа к объектам Deployment можно использовать объект Service, который, в сущности, является балансировщиком нагрузки. Service может быть доступен как изнутри (по умолчанию), так и снаружи. Если вы хотите, чтобы к вашему HTTP-приложению можно было обращаться, то используйте контроллер Ingress для добавления таких возможностей, как маршрутизация запросов и SSL. • Рано или поздно ваше приложение нужно будет параметризировать, чтобы сделать его
Это один из примеров использования ConfigMap для конфигурации приложения, но в реальных условиях изменения в данный ресурс можно вносить на регулярной основе: еженедельно или еще чаще. У вас может возникнуть соблазн делать это напрямую, редактируя сам файл ConfigMap, но это не самый удачный подход. Тому есть несколько причин: прежде всего, изменение конфигурации само по себе не инициирует обновление существующих pod. Чтобы применить настройки, pod нужно перезапустить. В связи с этим развертывание не зависит от работоспособности приложения и может происходить по мере необходимости или произвольным образом. Вместо этого номер версии лучше указывать и в имени самого ресурса ConfigMap. Например, frontend-config-v1, а не frontend-config. Если вам нужно внести изменение, то не обновляйте существующую конфигурацию, а создайте новый экземпляр ConfigMap с версией v2 и затем отредактируйте Deployment так, чтобы он его использовал. Благодаря этому развертывание происходит автоматически, с использованием соответствующих проверок работоспособности и пауз между изменениями. Более того, если вам нужно откатить обновление, то конфигурация v1 по-прежнему находится в кластере и, чтобы переключиться на нее, достаточно еще раз отредактировать Deployment.
Ресурсы кластера по умолчанию недоступны снаружи. Чтобы с ними мог работать кто угодно, нам нужно создать объект Service и балансировщик нагрузки; это позволит присвоить контейнерам внешний IP-адрес и направить к ним трафик
