Какие метрики нужно отслеживать Проще ответить «все», но если отслеживать слишком много метрик, то можно получить огромный набор информации, в котором будет сложно найти нужные сигналы. Подход к мониторингу в Kubernetes должен быть многоуровневым и охватывать следующие аспекты:
• физические или виртуальные узлы;
• компоненты кластера;
• дополнения к кластеру;
• приложения, взаимодействующие с конечными пользователями.
Это упрощает корректное определение сигналов в системе мониторинга. Вы можете подходить к решению проблем более целенаправленно. Например, при переходе ваших pod в состояние ожидания можете сначала проверить загруженность узлов, и если все в порядке, то перейти к компонентам кластера.
Ниже перечислены метрики, которые имеет смысл отслеживать в своей системе.
• Узлы:
• использование процессора;
• использование памяти;
• использование сети;
• использование диска.
• Компоненты кластера:
• латентность etcd.
• Дополнения к кластеру:
• контроллер автомасштабирования;
• контроллер Ingress.
• Приложение:
• использование и загруженность памяти в контейнере;
• использование процессора в контейнере;
• использование сети и частота возникновения сетевых ошибок в контейнере;
kube-state-metrics — дополнение для Kubernetes, которое занимается мониторингом объектов, хранящихся в кластере. Если cAdvisor и сервер метрик используются для предоставления подробной информации о потреблении ресурсов, то kube-state-metrics помогает определить состояние объектов Kubernetes, развернутых в кластере.
Во-вторых, Custom Metrics API позволяет собирать произвольные метрики. Таким образом, системы мониторинга могут предоставлять собственные адаптеры, расширяя тем самым стандартный набор метрик ресурсов. Например, один из первых подобных адаптеров появился в Prometheus, что позволило задействовать HPA на основе пользовательских метрик. Это делает возможным более гибкое масштабирование с учетом конкретной ситуации, поскольку теперь вы можете учитывать метрики, не встроенные в Kubernetes, — например, размер очереди.
Visual Studio (VS) Code for Kubernetes, которое можно бесплатно установить из магазина VS Code. Оно автоматически распознает все кластеры в вашем файле kubeconfig и предоставляет навигационную панель с древовидным представлением их содержимого.
Здесь можно использовать универсальную утилиту командной строки kubectl, которая поддерживает такие действия, как kubectllogs, kubectlexec и kubectlport-forward и т.д., но, чтобы научиться ею пользоваться и разобраться со всеми ее параметрами, нужен довольно серьезный опыт.
Большинство сервисов нужно развертывать в виде ресурса Deployment. Объекты Deployment создают идентичные реплики для масштабирования и обеспечения избыточности.
По умолчанию секретные данные в Kubernetes хранятся в незашифрованном виде. Если вам нужно шифрование, то можете воспользоваться интеграцией с провайдером ключей; вы получите ключ, с помощью которого будут шифроваться все секретные данные в кластере. Это защищает от непосредственных атак на базу данных etcd, но вам все равно необходимо позаботиться о безопасном доступе через API-сервер Kubernetes.
Сохранив пароль к Redis в виде объекта Secret, вы должны привязать его к приложению, которое развертывается в Kubernetes. Для этого можно использовать ресурс Volume (том). Том — это, в сущности, файл или каталог с возможностью подключения к запущенному контейнеру по заданному пользователем пути. В случае с секретными данными том создается в виде файловой системы tmpfs, размещенной в оперативной памяти, и затем подключается к контейнеру. Благодаря этому, даже если злоумышленник имеет физический доступ к серверу (что маловероятно в облаке, но может случиться в вычислительном центре), ему будет намного сложнее заполучить секретные данные.
